I’ve worked in payments for a long time, and card transactions still surprise smart people. A hold that won’t release. An amount that changes after you’ve paid. A refund that takes a week.
So I’m going to write about them, in short posts. Each tries to say what to expect, why it happens, and where to look when you need the detail. They’re for people around payments, whether you build it, design it, or sell it, and want a working picture rather than a specification. I don’t know yet how far this will go, so I’ll start at the beginning.
The tap
A customer taps a card at a coffee shop. The terminal beeps, and they walk away with a coffee.
The terminal reads the card data and passes it to the merchant’s payment system. That system sends a request to the acquirer, the bank or provider that serves the merchant. The acquirer uses the first digits of the card number to identify the network and the bank that issued the card, then sends the request through the network to the issuer.
The issuer checks a few things. Is the card valid and active? Is the PIN or cryptogram correct? Are the funds or credit there? Does anything look like fraud? It answers yes or no, and the answer travels back the same way.
That is authorization. It settles one question: should we allow this?
The money comes later
No money has moved yet. The issuer has only reserved the amount. The real movement happens afterwards:
- Clearing: the merchant submits the transaction for payment, and it flows through the network to the issuer.
- Settlement: the network works out who owes whom, and funds move between acquirer and issuer. The acquirer then pays the merchant, and the issuer bills or debits the cardholder.
So every card payment runs on two timelines:
- Seconds: the decision.
- Days: the money.
Holds that linger, amounts that change after you pay, and refunds that take days all come from the gap between them. I’ll keep coming back to it.
Leave a Reply