Skip to content

Card Payments — The Basics

A plain-language guide to how card payments work, mapped onto the adunopay topology.

1. The mental model: the "four-party model"

Almost all card payments (Visa, Mastercard) run on what the industry calls the four-party model. Despite the name, it's really four roles plus the scheme sitting in the middle as a clearing house.

Role Example What they do
Cardholder / Client John Doe Pays with a card (or phone).
Issuer Credit Suisse The client's bank. Issues the card, holds the client's money, decides whether to approve a payment.
Merchant A restaurant Sells goods/services, wants to get paid.
Acquirer Worldline The merchant's bank for card payments. Acquires transactions, pays the merchant.
Scheme Mastercard / Visa The network/rails connecting every issuer to every acquirer. Sets rules, routes messages, organises settlement.

Clearing up a common confusion

A couple of these are actually the same role under two names — this is the single most important thing to understand:

  • "Bank of the client" = Issuer. Credit Suisse issuing John's card is the issuer. There is no separate "client bank" — it's the same entity.
  • "Bank of the merchant" ≈ Acquirer. For card money, the acquirer is effectively the merchant's bank: it's who pays the restaurant. The restaurant may also have an everyday business account at a bank like ZKB, but that bank is not part of the card flow — the acquirer (Worldline) pushes the funds, and they typically land in the merchant's everyday account at the end.

German terminology

  • Acquirer / Acquiring — left untranslated in German industry usage. ⚠️ Akquisition is wrong here (it means sales/M&A customer acquisition). Descriptively: the acquirer nimmt Transaktionen an (accepts) and zieht Gelder ein (collects funds).
  • Issuer — also often left as Issuer, but a real translation exists: Kartenherausgeber / Herausgeber.

Where does adunopay fit?

adunopay (and Softpay, Silverflow, boncard in the diagram) is a Payment Service Provider (PSP) / Acquirer-Processor. The PSP is the glue that sits between the merchant and the acquirer/scheme. It provides:

  • the terminal / app the merchant taps the card on (Android ECR + Softpay SDK),
  • the technical connection into the schemes and the acquirer (Silverflow → Mastercard/Visa),
  • onboarding, reporting, settlement and reconciliation (the green "Informatique" backend: MAS ERP, adunopay Postgres DB, Boncard worker, etc.),
  • and in Switzerland, connections to local schemes like TWINT and Lunch-Check via boncard.

Think of the PSP as the merchant's single point of contact that hides all the complexity of the schemes and acquirers behind one integration.

2. Topology — who talks to whom

A simplified version of the full adunopay topology, focused on the card-payment roles rather than every internal service.

flowchart LR
    Client["👤 Client<br/>(John Doe)"]

    subgraph Terminal["At the restaurant (MPOS terminal)"]
        Card["💳 Card / Phone"]
        App["Android ECR + Softpay SDK<br/>(adunopay app)"]
    end

    subgraph PSP["adunopay (PSP / Processor)"]
        Backend["Softpay / Silverflow<br/>backend"]
        ERP["MAS ERP + adunopay DB<br/>onboarding · reporting ·<br/>reconciliation"]
    end

    subgraph Schemes["Card Schemes (the rails)"]
        MC["Mastercard"]
        VISA["Visa"]
    end

    Issuer["🏦 Issuer<br/>Client's bank<br/>(Credit Suisse)"]
    Acquirer["🏦 Acquirer<br/>Merchant's card-bank<br/>(Worldline)"]
    MerchBank["🏦 Merchant's everyday bank<br/>(ZKB)"]

    Client -->|taps card| Card
    Card --> App
    App <-->|"auth request/response"| Backend
    Backend --> ERP
    Backend <-->|transaction auth| Schemes
    Schemes <-->|"approve / decline"| Issuer
    Schemes <-->|"clearing & settlement"| Acquirer
    Acquirer -->|"pays out (minus fees)"| MerchBank
    Issuer -.->|"debits client"| Client

    classDef bank fill:#e8eaf6,stroke:#3f51b5;
    classDef psp fill:#e8f5e9,stroke:#43a047;
    classDef scheme fill:#fff3e0,stroke:#fb8c00;
    class Issuer,Acquirer,MerchBank bank;
    class Backend,ERP psp;
    class MC,VISA scheme;

Key idea: the merchant never talks to the issuer directly. Everyone talks to the scheme, which fans out to every issuer and acquirer. The PSP gives the merchant one door into that network.

No bilateral contracts — the scheme is the hub

With thousands of issuers and thousands of acquirers worldwide, bilateral contracts would be N×N. Instead each member signs one contract with each scheme and agrees to the scheme rulebook. Credit Suisse and Worldline have never signed anything with each other and don't need to. The scheme is both:

  • the directory — routing happens via BIN (first digits of the card → identifies the issuer) and ICA/CID (identifies the acquirer), not bank account numbers, and
  • the clearing house — it nets and guarantees settlement (see §3).

Counterparties never exchange IBANs; nobody needs the other's bank details.

3. The two phases — and when money actually moves

The biggest source of confusion: money does not move when the payment is approved. There are two separate phases, often hours or a day apart.

Phase When What happens Does money move?
1. Authorization Instantly, at the table Issuer checks the card is valid and funds exist, then reserves (holds) the amount on the client's account. ❌ No. Only a hold.
2. Clearing & Settlement Batched, end of day / next day The actual money is transferred: issuer → scheme → acquirer → merchant. ✅ Yes.

So when John sees "approved" on the terminal, the restaurant has a promise, not the cash. The cash arrives the next day(s), and the restaurant receives the amount minus the Merchant Discount Rate (MDR) — the fee shared between acquirer, scheme and issuer (the issuer's slice is the interchange fee).

How settlement money actually flows

The funds do not travel as a direct Credit-Suisse → Worldline bank transfer. They flow through the scheme's settlement system, which nets every member's position across the day:

Issuer ──pays net position──▶ Scheme settlement bank ──pays net position──▶ Acquirer

The issuer pays into the scheme's settlement bank; the scheme pays out to the acquirer. That's a core part of what scheme fees buy: the scheme guarantees settlement.

Is the acquirer a "bank"? Not necessarily a deposit-taking bank, but it must be a regulated financial institution to be a scheme "principal member" — either a credit-institution licence or a Payment / E-Money Institution licence (PSD2 in the EU). The bar is licensed scheme member, not high-street bank.

4. Payment flow — sequence diagram

Starting from John confirming the payment in the restaurant.

sequenceDiagram
    autonumber
    actor Client as 👤 Client (John)
    participant POS as 🖥️ Terminal<br/>(adunopay app)
    participant PSP as adunopay / Silverflow
    participant Scheme as Mastercard/Visa
    participant Issuer as 🏦 Issuer (Credit Suisse)
    participant Acquirer as 🏦 Acquirer (Worldline)
    participant Merchant as 🏦 Merchant bank (ZKB)

    Note over Client,Issuer: ── PHASE 1: AUTHORIZATION (seconds, at the table) ──
    Client->>POS: Taps card, confirms CHF 50
    POS->>PSP: Auth request (card data, amount)
    PSP->>Scheme: Route auth request
    Scheme->>Issuer: Auth request
    Issuer->>Issuer: Checks funds & fraud rules
    Issuer-->>Scheme: APPROVED + hold CHF 50
    Note right of Issuer: 💰 CHF 50 reserved on<br/>John's account (not yet moved)
    Scheme-->>PSP: Approved
    PSP-->>POS: Approved
    POS-->>Client: ✅ Receipt — done in ~2s

    Note over PSP,Merchant: ── PHASE 2: CLEARING & SETTLEMENT (batch, next banking day) ──
    PSP->>Scheme: Acquirer submits captured batch (after cutoff)
    Scheme->>Issuer: Clearing file (please pay)
    Issuer->>Scheme: 💸 Transfers CHF 50 (minus interchange fee)
    Note right of Issuer: 💰 CHF 50 actually debited<br/>from John's account now
    Scheme->>Acquirer: 💸 Settles funds (minus scheme fee)
    Acquirer->>Merchant: 💸 Pays out CHF 50 − MDR
    Note right of Merchant: 💰 Money lands in the<br/>restaurant's everyday account

Reading the money trail

Follow the CHF 50:

  1. Authorization — nothing moves. The issuer just holds CHF 50 on John's account so he can't spend it twice.
  2. Clearing — the scheme tells the issuer "this purchase is final, pay up." The issuer debits John's account and sends the money toward the scheme, keeping a small cut (the interchange fee).
  3. Settlement — the scheme passes the money to the acquirer (keeping the scheme fee).
  4. Payout — the acquirer pays the merchant's bank account, keeping the acquirer margin. The restaurant receives CHF 50 − MDR.

Net effect: John's account −50. Restaurant's account +~48.X. The ~1–2 CHF difference is the fees split between issuer, scheme and acquirer.

5. Settlement timing

Settlement is not triggered by a wall-clock midnight:

  • The acquirer submits clearing at a configured cutoff time (in a scheme- or acquirer-defined reference timezone — not a universal local midnight).
  • The cutoff defines the settlement "business day": a sale at 23:58 vs 00:02 relative to the cutoff can settle a whole day apart.
  • Schemes settle on banking days only — weekend/holiday transactions roll forward to the next banking day.
  • Large acquirers/schemes may run multiple settlement cycles per day, so "once a day" is the common case, not a rule.

The merchant's payout timing (T+1, T+2…) is counted from that cutoff, not from the moment of sale. The precise cutoff time and timezone are defined in the acquirer/processor contract — that's the authoritative source for a given setup.

6. Swiss / adunopay specifics

The full topology shows more than the classic Visa/Mastercard flow:

  • TWINT & Lunch-Check (via boncard) are local Swiss schemes. They follow the same authorize-then-settle idea but are account/wallet-based rather than classic card rails.
  • Softpay turns a plain Android phone into a payment terminal ("tap-to-pay on phone"), so the "terminal" is software, not dedicated hardware.
  • Silverflow is the modern acquirer-processor — adunopay's technical gateway into Mastercard/Visa.
  • The green Informatique backend (MAS ERP, adunopay Postgres DB, Boncard worker, Fibu sync to Topal ERP / Bank Frick) is what handles onboarding, reporting, reconciliation and chargebacks — i.e. everything around the live transaction.

Terms

Every term used on this page is defined once in the Glossary — including issuer, acquirer, scheme, PSP, authorization, clearing, settlement, cutoff, MDR, interchange fee, and chargeback. Key terms are also linked inline above on first use.