Cards & Merchant Payments / Learning brief
From tap to payout: a merchant's story
Your notes
In simple terms / 01
What this means in plain language
One synthetic coffee purchase followed end to end: the authorisation that finishes in seconds, the clearing and settlement that move the money later, the payout the merchant actually receives after fees, and the chargeback that arrives weeks after the cup was empty.
A single card payment is three journeys on three clocks. First, authorisation: in the seconds after the tap, an authorization request travels from the terminal through the merchant's acquirer and the card network to the issuer, which approves and places an authorisation hold on the cardholder's account — a promise to pay, with no money moved. Second, clearing and settlement: typically after the day's batch closes, the acquirer submits clearing records, the network applies interchange and calculates net positions, money settles between the banks, and the acquirer pays the merchant the sale amount minus the merchant discount — a bundle of interchange, scheme fees, and acquirer margin. Third, and only sometimes: a dispute. Weeks later a cardholder can raise a chargeback with a reason code; money is pulled back from the merchant while the case runs, and the merchant answers with evidence (representment) or accepts the claim. Exact timings and fee levels are set by scheme rules and acquirer contracts, not by the model itself.
Key takeaways / 03
Three things to remember
- 01
APPROVED at the terminal means a hold and a promise — the money actually moves later, during clearing and settlement.
- 02
The merchant is paid by its acquirer after fees: sale amount minus the merchant discount, which bundles interchange, scheme fees, and acquirer margin.
- 03
A chargeback can reopen the payment weeks later; it reverses money first and is then resolved by evidence, representment, or acceptance.
Practical use cases / 04
Where you would use this
A new merchant reconciles its bank statement by matching payout batches against terminal totals, understanding why the amounts differ by the merchant discount.
A finance manager explains to an owner why yesterday's card sales are not yet in the account: authorisation happened, settlement and payout have not.
A shop responds to a duplicate-processing chargeback by checking terminal records before deciding whether to accept it or submit representment evidence.
Worked example / 05
Put the idea into a real situation
Illustrative example (SYNTHETIC / TRAINING ONLY): at 09:12, fictional customer Maya Chen taps her Bank Alfa card for a GBP 3.60 flat white at Demo Coffee Ltd, whose acquirer is Meridian Bank, over the fictional Cardnet network (standing in for Visa- and Mastercard-style networks). The 0100 authorisation request reaches Bank Alfa and the 0110 response comes back APPROVED in under two seconds; Maya's available balance drops by GBP 3.60 but no money moves. That evening the batch closes; in clearing, illustrative fees of GBP 0.02 interchange, GBP 0.01 scheme fee, and GBP 0.03 acquirer margin are taken, and Demo Coffee is later paid GBP 3.54. Three weeks on, Maya spots the same GBP 3.60 twice — the terminal had been tapped again after a timeout — and Bank Alfa raises a duplicate-processing chargeback. Demo Coffee checks its records, sees the duplicate is real, and accepts: the reversal stands, and the story ends with the books telling the truth.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageMaya presents her cardMaya Chen (cardholder) → Demo Coffee Ltd (merchant terminal)
Maya taps her card for a EUR 42.50 catering order. The terminal reads the chip or contactless data defined by EMV (the chip-card standard maintained by EMVCo) — including a one-time cryptogram that proves a real card was present.
- 02MessageThe terminal builds and sends the authorisation requestDemo Coffee Ltd (merchant terminal) → Meridian Bank (acquirer) · 0100 authorisation request (ISO 8583)
The terminal packs the card data, amount and merchant details into an authorization request — a 0100 message in ISO 8583, the card industry's messaging standard — and sends it to Meridian Bank, the acquirer that serves Demo Coffee.
- 03MessageMeridian Bank forwards the request to CardnetMeridian Bank (acquirer) → Cardnet (card network) · 0100 authorisation request (ISO 8583)
The acquirer checks the merchant is one of its own and the message is well formed, then forwards the request into the card network. The acquirer cannot approve — only the card's issuer can say yes.
- 04MessageCardnet routes the request to Bank AlfaCardnet (card network) → Bank Alfa (issuer) · 0100 authorisation request (ISO 8583)
The network reads the bank identification number (BIN) — the opening digits of the card number — recognises Bank Alfa as the issuer, and delivers the request to it.
- 05ProcessingBank Alfa checks the card, the funds and the riskBank Alfa (issuer)
The issuer decides in well under a second: is the card open, does the EMV cryptogram verify, do funds cover the amount, and does the fraud engine trust this purchase? Approve or decline — the whole flow exists for this moment.
- 06MessageBank Alfa approves and respondsBank Alfa (issuer) → Cardnet (card network) · 0110 authorisation response
The issuer answers with a 0110 response carrying an approval and an authorisation code — a short reference that will later tie the clearing record back to this exact approval.
- 07MessageCardnet relays the approval to Meridian BankCardnet (card network) → Meridian Bank (acquirer) · 0110 authorisation response
The network sends the response back along the same path it came. Request out, response back — one conversation, a few seconds end to end.
- 08MessageThe terminal shows approvedMeridian Bank (acquirer) → Demo Coffee Ltd (merchant terminal) · 0110 authorisation response
Meridian Bank passes the approval to the terminal. Maya sees 'approved'; Demo Coffee stores the authorisation code with the sale for tonight's clearing batch.
- 09PostingBank Alfa places an authorisation holdBank Alfa (issuer)
The issuer reserves EUR 42.50 against Maya's available balance so she cannot spend it twice. This hold is not a movement of money — nothing has been debited and nothing has moved between the banks. The real debit comes at clearing and settlement.
An approval is a promise, not a payment. No money has moved yet — the debit, the interbank movement and the merchant's payout all happen later, in clearing and settlement.
- RESERVE Maya Chen's card account at Bank Alfa — EUR 42.50
Read the steps as text
- 01MessageDemo Coffee closes the day's batchDemo Coffee Ltd (merchant) → Meridian Bank (acquirer) · end-of-day capture batch
At end of day the terminal sends its captured sales — each with its authorisation code — to Meridian Bank. Until this capture, Maya's EUR 42.50 exists only as an approval and a hold.
- 02MessageMeridian Bank submits clearing records to CardnetMeridian Bank (acquirer) → Cardnet (card network) · clearing record
The acquirer turns each captured sale into a clearing record and presents it to the network — the presentment. Each record references its authorisation so the issuer can match it to the hold it placed.
- 03Clearing obligationCardnet runs the clearing cycle and applies interchangeCardnet (card network)
The network validates each record and attaches interchange — the fee the acquirer pays the issuer on each transaction, set under the scheme's rules. The record now says exactly who owes whom, and how much of it is fee.
Clearing establishes obligations, interchange included. No money has moved yet — that is settlement's job.
- 04Clearing obligationCardnet calculates each bank's net positionCardnet (card network)
Across the day's records, everything each bank owes and is owed collapses into one net figure per participant — multilateral netting. Bank Alfa owes the net of what its cardholders spent; Meridian Bank is owed the net of what its merchants sold.
A net position is still an obligation, not money.
- 05SettlementNet amounts move between settlement accountsBank Alfa (issuer) → Meridian Bank (acquirer)
The scheme's settlement bank moves each participant's net amount. On this transaction Bank Alfa settles EUR 42.40 to Meridian Bank — the EUR 42.50 sale less the illustrative EUR 0.10 interchange the issuer retains — inside Bank Alfa's larger net payment. This is the moment money actually moves between the banks, typically a day or two after the sale, on a timetable each scheme's rules set.
- DR Bank Alfa settlement account — EUR 42.40
- CR Meridian Bank settlement account — EUR 42.40
- 06PostingBank Alfa posts the final debit and releases the holdBank Alfa (issuer)
The cleared record replaces the authorisation hold: the reserve is released and a posted debit takes its place. Only now has Maya's money actually left her account — the 'pending' line on her app becomes a booked transaction.
- RELEASE Maya Chen's card account at Bank Alfa — EUR 42.50
- DR Maya Chen's card account at Bank Alfa — EUR 42.50
- 07PostingMeridian Bank pays Demo Coffee, less the merchant discountMeridian Bank (acquirer)
The acquirer credits Demo Coffee EUR 41.90 — the sale less the merchant discount, the acquirer's charge that covers interchange, scheme fees and its own margin. The figures are illustrative; the actual rate comes from Demo Coffee's acquiring agreement.
- CR Demo Coffee Ltd settlement account at Meridian Bank — EUR 41.90
- 08MessageThe purchase lands on statementsBank Alfa (issuer) → Maya Chen (cardholder)
Maya's card statement shows Demo Coffee Ltd, EUR 42.50, now booked. Demo Coffee's acquiring statement shows the payout and the fees taken. Both sides can reconcile the same sale from their own end.
Read the steps as text
- 01MessageMaya disputes the chargeMaya Chen (cardholder) → Bank Alfa (issuer)
Maya tells Bank Alfa she does not recognise the EUR 42.50 booking on her statement. The issuer records the claim and, for many claim types, first asks whether she has tried to resolve it with the merchant directly.
- 02MessageBank Alfa raises a chargeback with a reason codeBank Alfa (issuer) → Cardnet (card network) · chargeback record
The issuer sends a chargeback record into the network carrying a reason code — the claim's category, such as 'transaction not recognised' or 'goods not received'. The reason code fixes what evidence can answer it. Many issuers also re-credit the cardholder provisionally while the case runs.
- 03MessageCardnet routes the chargeback to Meridian BankCardnet (card network) → Meridian Bank (acquirer) · chargeback record
The network checks the chargeback is validly formed — reason code allowed, raised within the time limit its rules set — and delivers it to the acquirer that presented the original sale.
- 04SettlementThe disputed amount settles back through the network cycleMeridian Bank (acquirer) → Bank Alfa (issuer)
A chargeback is not only a case file — it is a money movement. In the next network settlement cycle the disputed amount is charged to the acquirer's net position and credited to the issuer's, reversing the direction the original sale settled in.
The interbank leg reverses first; whether the merchant or the issuer finally bears the loss is decided later by the case.
- 05PostingMeridian Bank debits Demo Coffee and asks for evidenceMeridian Bank (acquirer)
The disputed amount is pulled from the merchant's account while the case runs — in a chargeback, the money moves first and the argument follows. The acquirer passes the case to Demo Coffee with the reason code and a deadline to respond.
- DR Demo Coffee Ltd settlement account at Meridian Bank — EUR 42.50
- 06MessageDemo Coffee responds with evidenceDemo Coffee Ltd (merchant) → Meridian Bank (acquirer)
The merchant answers the reason code with proof: the signed receipt, the terminal's EMV chip data showing the card was present, and the catering delivery note. Evidence that does not address the reason code does not count, however thick the file.
- 07MessageMeridian Bank re-presents the transactionMeridian Bank (acquirer) → Cardnet (card network) · representment record
The acquirer sends the case back through the network as a representment — literally a second presentment of the sale, now with evidence attached — asserting the original charge was valid.
- 08MessageCardnet delivers the representment to Bank AlfaCardnet (card network) → Bank Alfa (issuer) · representment record
The network checks the representment is validly formed and passes it — evidence attached — to the issuer that raised the original chargeback.
- 09ProcessingBank Alfa reviews the representmentBank Alfa (issuer)
The issuer weighs the evidence against Maya's claim and the reason code's requirements. This review decides the case for most disputes — escalation beyond it is the exception, not the rule.
- 10SettlementThe interbank chargeback settlement unwinds in the acquirer's favourBank Alfa (issuer) → Meridian Bank (acquirer)
Because the representment succeeds, the earlier acquirer-to-issuer movement reverses: in the next settlement cycle the disputed amount is charged back to Bank Alfa's net position and credited to Meridian Bank's, undoing the chargeback's original settlement. The acquirer is made whole between the banks before it re-credits the merchant.
The money returns to the acquirer's side first; only then does Demo Coffee get its debit reversed.
- 11PostingThe case closes — liability lands with the evidenceMeridian Bank (acquirer)
Bank Alfa accepts the representment: the chip data shows Maya's card was present, so the charge stands. With the interbank leg reversed, Meridian Bank re-credits Demo Coffee, and Bank Alfa reverses Maya's provisional credit and explains the outcome to her. Liability followed the evidence.
- CR Demo Coffee Ltd settlement account at Meridian Bank — EUR 42.50
Evidence & review / 07
Evidence & review
Card acceptance for a small merchant generally. Fee levels, payout timing, and dispute deadlines depend on the scheme, the acquirer contract, and the market; network rules generally set the stages, not the exact clock.
What this brief simplifies: Every person, company, bank, and network in the story is fictional (SYNTHETIC / TRAINING ONLY), and the fee split is an illustrative construction rather than a quoted price. Timings are described as scheme-dependent instead of fixed T+1/T+2 promises.
Sources for this brief2
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.