Walk me through what happens between a customer tapping a card and the merchant getting paid.

The four roles

Four parties are involved, plus a network in the middle that is the reason it is called a four-party model. The cardholder holds a card issued by the issuer, their bank, which holds the money and carries the credit risk. The merchant has a contract with an acquirer, the bank or processor that accepts card transactions on its behalf and is financially responsible for that merchant. The scheme — Visa or Mastercard, for example — is not a party to the money; it operates the network that routes messages, publishes the operating rules both banks have agreed to, and calculates what each bank owes the others.

The contrast worth naming is the three-party model, where one company both issues cards and acquires merchants, as American Express traditionally did. There is no interchange between separate banks there because there are no separate banks; the same entity sits on both sides.

Authorisation moves no money

The tap produces an authorisation request. The terminal reads the chip over the contactless interface, generates a cryptogram, and sends a message to the acquirer, which routes it through the scheme to the issuer. The issuer decides: is the card valid, is the cryptogram genuine, are there funds or credit available, does this look like fraud, does it need a stronger customer authentication step. It replies with an approval or a decline, and the whole round trip is expected to complete in the time it takes the terminal to beep.

What an approval does is place a hold. The issuer reduces the cardholder's available balance by the authorised amount while leaving the posted balance untouched, because nothing has moved. This is the single most-missed point in the answer: an approved authorisation is a promise that the issuer will honour a later collection of that amount, not a transfer. The merchant has an approval code and a reserved amount, and no funds.

Some environments authorise later or not at all at the point of tap. Transit gates commonly accept the tap offline against the card's own risk parameters and authorise afterwards, accepting the risk in exchange for throughput. Hotels and fuel pumps authorise an estimate and then adjust it, which is why a pre-authorisation frequently bears no resemblance to the final bill.

Capture, clearing, settlement

Capture is the merchant saying how much to actually collect. In the dual-message flow used for most credit transactions, capture is a separate step, usually batched at end of day, and the captured amount may legitimately differ from the authorised amount — lower for a partial shipment, or split across several captures for an order that ships in parts. A merchant that never captures has effectively cancelled the sale, though the hold may linger unless it is explicitly reversed. Single-message flows, common for PIN debit and some domestic schemes, combine authorisation and the financial request into one message, so capture is not a separate decision.

Clearing is the exchange of those captured records between acquirer and issuer through the scheme. The scheme validates the presentments against the authorisations, applies the interchange and scheme fees defined in its rules, and produces the net position of every participant: this issuer owes that much, that acquirer is owed this much. Clearing is a batch process that runs on defined windows, not continuously.

Settlement is the actual movement of funds between the banks' settlement accounts, executed once per settlement cycle on the net positions clearing produced. Netting is the point: two banks with hundreds of thousands of transactions between them exchange one payment, not hundreds of thousands.

None of that is the merchant being paid. The acquirer receives settlement funds and then pays the merchant according to the merchant agreement, minus fees, on its own funding schedule — and possibly less a rolling reserve if the merchant is judged risky. So the delay a merchant experiences is the sum of several independent lags: waiting for the batch to be captured, waiting for the next clearing window, waiting for a settlement cycle that only runs on banking days, and waiting for the acquirer's payout schedule. A Friday-evening tap can sit behind all four. Quote no specific number of days in an interview unless you are describing a scheme and market you actually know, because it varies by both.

Only the last two arrows below move money; everything above them is messaging.

sequenceDiagram
    participant C as Cardholder
    participant M as Merchant
    participant A as Acquirer
    participant S as Scheme
    participant I as Issuer
    Note over C,I: Authorisation - seconds, no money moves
    C->>M: Tap
    M->>A: Auth request
    A->>S: Route
    S->>I: Auth request
    I-->>M: Approval and hold, back via scheme and acquirer
    Note over M,I: Capture and clearing - batch windows
    M->>A: Capture amount
    A->>S: Presentment
    S->>I: Net position and fees
    Note over A,I: Settlement and payout
    I->>A: Net funds
    A->>M: Payout less fees, acquirer schedule

Holds that go wrong

Two failure modes come out of the gap between authorisation and capture, and both are visible to customers.

An authorisation that is never captured and never reversed leaves the hold suppressing the cardholder's available balance until the issuer expires it, which is why a cancelled hotel booking can tie up money for days. The fix is an explicit authorisation reversal the moment you know you will not collect, which releases the hold immediately instead of waiting for expiry. How long an uncaptured authorisation survives is set by scheme rules and varies by merchant category, so treat the window as something to look up rather than a number to state.

Capturing after the authorisation has expired is the mirror image. The collection may well go through, but it no longer sits behind a valid authorisation, so the protections that the approval bought the merchant are weakened and the transaction is far more exposed to being disputed. Long-lived authorisations are a business risk, not just an untidy state machine.

Chargebacks

A chargeback is the dispute mechanism that runs backwards along the same rails. The cardholder complains to the issuer — goods never arrived, the amount is wrong, they did not make the transaction — and the issuer, if the complaint fits a reason code in the scheme's rules, reverses the transaction through the scheme. Funds are taken back from the acquirer, which debits the merchant, typically along with a fee. The merchant may then represent the transaction with evidence such as delivery confirmation or proof that authentication was performed, and if the issuer rejects that, the scheme's escalation path leads to pre-arbitration and ultimately a ruling by the scheme itself.

The important structural point is that liability follows the rules, not the cash. Whether the issuer or the merchant absorbs a fraudulent transaction depends on things like whether the chip was read, whether the card was present, and whether strong customer authentication was applied and passed. That is why the merchant's incentive to authenticate is not merely to prevent fraud but to move who pays for it. Reason codes, evidence requirements and filing deadlines are all defined in each scheme's operating regulations and differ between schemes and regions; naming the mechanism precisely and declining to invent the deadlines is the credible answer.

The whole flow makes sense once you hold onto one distinction: authorisation is a reservation against an account, clearing decides what the banks owe each other, settlement moves that money, and paying the merchant is a separate commercial step the acquirer performs afterwards. Candidates who collapse any two of those four cannot explain where a payment is stuck when someone asks.