The payments primer
A card payment feels like a single event. You tap, and a second later the terminal says approved.
Underneath that second, five or six organisations have passed messages to each other. Not one of them has moved any money. That happens over the following days, on the banking system's schedule rather than yours.
Most payments problems live in the gap between those two things. A charge the customer swears they cancelled. An order that shipped but never funded. A deposit that matches no invoice anyone can find, with no obvious way to work out what it covers. Each of them is baffling until you work out which step you are looking at.
This primer teaches you the steps.
What you will be able to do
By the end of it you should be able to:
- Say what happened to a payment, in words the next person will read the same way. "Approved but never captured" should name one specific event for you, rather than a vague sense that something went wrong.
- Pick the right way to give a customer their money back, and know what each option costs you.
- Explain where the money is when it has not arrived, and know which company can move it.
- Read a dispute, work out what the cardholder is claiming, and know what evidence answers that claim.
- Notice when a card-shaped assumption is about to break against a rail that does not work like cards, whether that is ACH, an instant push rail, SEPA, or a wallet that is not the card it looks like.
You will not need message formats or an integration for any of that. Mostly it is vocabulary, plus knowing what happens in what order.
Who does what
Five parties matter. Each gets a page here, except the two at the ends, which share merchant and cardholder. Learn what each one is on the hook for and most of payments stops being mysterious.
| Party | Its job |
|---|---|
| Customer | Holds the card and can dispute the result for months afterwards |
| Merchant | Sells the thing, and carries the risk when the sale goes wrong |
| Merchant's bank | Sponsors the merchant into the card system and takes the loss if the merchant vanishes |
| Card network | Writes the rules, routes the messages, and settles who owes whom |
| Customer's bank | Decides whether to approve, and hands over the money |
A working payment is a lap of that circuit and back.
The dotted line is the answer coming back. That round trip takes about a second, and at the end of it nobody has been paid. Once the merchant confirms the sale really happened, the money makes the same journey in the other direction over the following days.
Both banks have proper names once you start reading the rules. The customer's bank is the issuer, because it issued the card. On the other side, the acquirer acquires the transaction on the merchant's behalf. In practice there is also a stack of vendors sitting between the merchant and its acquirer: gateways, processors, payment service providers. Knowing which of them to call when something breaks will save you more time than anything else in this primer.
Messages move first, money moves later
There are two diagrams up there rather than one. That split is the idea the whole primer is built around.
The first is a conversation. The merchant asks the customer's bank: if I claim this money later, will you stand behind it? The bank answers, and sets the amount aside. No money moves. That exchange is an authorization, and it is what the terminal means when it says approved.
The money is the second diagram, and it runs on the banking system's schedule. The merchant confirms the sale, the day's transactions leave in a batch, the banks work out overnight what they owe each other, and the funds land days later. What lands is less fees, netted against refunds, on a timetable your contract sets as much as the network does.
Almost every "where is our money" question turns out to be about the distance between those two. Somebody is looking at the first diagram and expecting the second to have already happened.
Stretch that second half out and it is four separate events. Giving them their right names is most of the battle:
- Authorization: the bank agrees to stand behind the amount and holds it.
- Capture: the merchant says the sale is real and claims the money.
- Clearing and settlement: the banks price the transaction and move funds between themselves.
- Funding: the merchant's provider finally pays the merchant. Funding is a different event from settlement, and treating them as one wastes a great many afternoons.
Two more questions sit around those four. Authentication is about who was on the other end of the card. Stored cards covers whether you may keep that card on file for next time. And if the customer pays in a currency you do not bank in, cross-border covers what happens to the difference.
Money can also travel backwards, either because the merchant sends it (refunds and their cheaper cousins) or because the customer's bank takes it (disputes). Those are not the same thing. A dispute costs you a good deal more.
How this is organised
Three sections, each answering a different question about the same event.
| Section | The question it answers | Start at |
|---|---|---|
| Roles | Who are the parties, and what is each one responsible for? | Acquirer |
| Flows | What happens, in what order, and how long does each step take? | The transaction lifecycle |
| Rails | Which network carries the money, and what rules come with it? | Cards |
Any real payment touches all three at once: a card payment (rail) runs an authorization (flow) between an issuer and an acquirer (roles). The sections exist because so much confusion comes from answering one of those questions when somebody asked another.
If you are new, read them in order. Each flow page assumes the one before it.
How to read it
Most of the primer is ordinary prose, because you have to understand why something works before you can reason about a case nobody wrote down.
Procedures get a different treatment:
Do one thing per sentence.
- Read the rule.
- Follow the steps in order.
Anything set apart like that is meant to be followed as written.
Where a page states a deadline or a fee, it links the network's own published document. Some figures depend on your provider's contract rather than on network rules. There the page says so, rather than quoting a number that would only ever be right for one merchant.
Each page ends with the terms it introduced. If you arrive in the middle, or a word turns up in a meeting before you have read the page that owns it, the glossary has all of them with a link to the page that teaches each.
Test yourself
Reading about payments produces a comfortable feeling of understanding that does not survive a real incident. The quiz is there to puncture it early.