Payments, from the metal up
You tap. The terminal beeps. Somewhere a kitchen starts making your order. The whole thing felt instant, but in those three seconds your card and about half a dozen computer systems in different companies, sometimes different countries, held a very fast, very formal conversation. I work on some of these systems for a living. This is that conversation, in order.
A contactless card has no battery. The terminal's NFC field powers a tiny chip on the card, and the two begin exchanging small binary messages defined by the EMV contactless specifications. The terminal asks what the card can do, the card answers with its capabilities, and then the important part happens: the card signs the transaction. Using a secret key that was burned into the chip when it was made, the card computes a cryptogram over the amount, the currency, a counter and an unpredictable number the terminal supplied. This cryptogram is the reason a tap is not just "reading the card number". The number alone is almost useless. The proof that the real chip was present for this exact amount at this exact moment is everything.
The terminal also runs its own quick risk checks. This is where the no-PIN experience comes from: below a limit set by the regulator and the issuer (in India, small contactless payments skip the PIN), the terminal decides the tap alone is enough. Above it, you get the PIN prompt.
Everything the terminal learned is now packed into an ISO 8583 message, a format from 1987
that still carries most of the world's card traffic. It is a strange and wonderful thing: a bitmap declares
which of 128 numbered fields are present, then the fields follow, each with its own encoding rules. Field 2
carries the card number, field 4 the amount, field 55 the EMV cryptogram and its companions. The message type
for "please authorize this" is 0100. When people who work in payments dream badly, they dream in
field numbers.
One important modern twist: field 2 often does not contain your real card number anymore. If your card is tokenized, a stand-in number travels instead, and only the token service can map it back. A database breach at a merchant leaks tokens, not cards. This is one of the quietest, most effective security upgrades payments has ever shipped.
The merchant's acquirer receives the 0100 and has to deliver it to whichever bank issued your
card. The first six to eight digits of the card number, the BIN, identify the issuer, and BIN
tables tell the acquirer which network to hand the message to. The network, the rails in the middle, routes it
onward to the issuing bank. If the card was tokenized, the network's token service swaps the token for the
real number on the way through. All of this happens in tens of milliseconds, and all of it is invisible until
a BIN table goes stale somewhere and a perfectly good card starts getting declined at one particular shop.
Routing bugs are humbling that way: nothing is down, and yet money does not move.
The issuer now has milliseconds to answer one question: is this real, and can this person pay? It validates the cryptogram against hardware security modules that hold the card keys. It checks the card is active and not reported lost. It checks the balance or the credit limit. It runs fraud models: is this amount, at this merchant, in this city, at this hour, consistent with this card's life? Each check is fast. The discipline is keeping all of them fast together, every time, because the terminal, the acquirer and the network each have timeouts, and a slow answer is treated as no answer.
The verdict travels back as an 0110 response with a two-digit code. 00 means
approved. Everything else is a flavor of no, and matching those flavors to what a cardholder actually sees on
the screen is its own small field of engineering. If the issuer is unreachable, the network can sometimes
stand in and answer on its behalf within agreed limits, which is why your card occasionally
works even while your bank's app is down.
Here is the thing that surprises people: no money moved yet. An approval is a promise, a hold against your limit. The movement starts later. The merchant's system captures the approved transaction, usually in an end-of-day batch, and the acquirer submits clearing records through the network. Clearing is where the amounts are finalized, currency conversion happens if it must, and the network calculates interchange, the fee that flows between the banks. Your tap has stopped being an event and become a row, one of millions, in files that banks exchange on a schedule.
Settlement is the anticlimax the whole system exists for. On a schedule, typically the next working day, the network nets out what every bank owes every other bank, and a small number of large transfers replace millions of small ones. The merchant is paid by the acquirer, minus fees. Your issuer turns the hold into a real debit. And a reconciliation process, the least glamorous and most load-bearing job in payments, checks that what the terminal saw, what the acquirer processed and what the network settled are the same set of transactions down to the last one. When they are not, a human gets paged. Sometimes that human was me.
The architecture is old and looks it. It is also quietly brilliant. Authorization is separated from money movement, so the fast path stays fast and the money path stays careful. Cryptography lives in the chip, so stolen numbers age badly. Every party trusts the message, not the other party's honesty. And the whole thing degrades gracefully: issuers go down, stand-in catches; networks slow, timeouts and reversals clean up; a batch fails, reconciliation finds it. The three seconds you experienced were the demo. The system's real work is making sure the following twenty-four hours agree with it.
One ordering note, because it trips people up. At a terminal the card authenticates itself the instant you tap, before anything is routed anywhere. Online there is no chip in the room, so authentication happens after the gateway is chosen, as a 3-D Secure challenge, and only then does the authorization request go out. Same seven steps, two different places where the cardholder proves who they are.
The site this article lives on tells the same story: scroll the home page and a pulse travels INITIATE to SETTLED down the left rail. This piece is what the pulse is doing.