You tap your card. The terminal says "Approved" in two seconds. The money doesn't actually move for one to three business days. Between those two events is a system that handles $10 trillion per day, runs on protocols from the 1970s, and is held together by an extraordinary amount of institutional trust.
Most engineers who build on top of payment APIs treat this as a black box: charge goes in, money comes out, Stripe handles the rest. That's fine, until you need to understand why a merchant's funds are on hold, why a chargeback reverses something from three weeks ago, or why "instant payments" is a hard engineering problem rather than a product feature you can switch on.
The actors
Five parties are involved in every card payment.
The cardholder is you. You have a card issued by your bank. The merchant is who you're paying. They have a point-of-sale terminal or an online payment form. The acquiring bank (sometimes called the "acquirer") is the merchant's bank, the institution that has agreed to process card payments on the merchant's behalf and deposit funds into the merchant's account. The card network (Visa, Mastercard, Amex) is the message bus connecting everything. It's not a bank. It doesn't hold your money. It routes authorization messages and settles net positions between banks according to its own rules. The issuing bank is your bank, the one that issued your card and holds your account.
Each party has a specific role and specific contractual relationships with the others. A Visa transaction is a Visa transaction because everyone in the chain has agreed to follow Visa's rules in exchange for access to Visa's network.
Authorization
When you tap your card, the terminal sends an authorization request to the acquiring bank: "Can this card pay $47.50?" The message travels from the acquiring bank through the card network to the issuing bank, the bank that knows whether you have $47.50 available and whether anything looks suspicious about this transaction.
The issuing bank runs its checks: is the card valid and not reported stolen? Does the account have sufficient funds or credit? Does this transaction look like fraud (wrong country, unusual merchant category, velocity that doesn't match your history)? It responds with an authorization code (approved) or a decline reason. This entire round trip, terminal to acquirer to network to issuer to network to acquirer to terminal, takes roughly two seconds.
Here is the key detail: no money has moved. The issuing bank has reserved the funds (ring-fenced in your account, can't be spent elsewhere) but they haven't gone anywhere. The authorization is a promise, not a transfer. What the merchant has received is essentially an IOU from your bank.
Clearing
At end of day, the merchant batches all of their authorized transactions and sends a clearing file to their acquiring bank. This is the "I'd like to collect on those promises now" step. The acquiring bank forwards the clearing data to the card network. The network routes each transaction to the relevant issuing bank.
The issuing bank matches the clearing record against the earlier authorization, verifying that the amount matches, the merchant is the same, nothing looks manipulated, and confirms the transaction. This is when the transaction becomes official in the interchange system. The funds move from "reserved" to "committed to outgoing."
Clearing typically happens once per day, in a batch. Some networks and acquirers clear more frequently for high-volume merchants, but the default is daily. You might authorize a transaction at 9am, but the clearing doesn't go out until midnight.
Settlement
Settlement is the actual movement of money between banks. After clearing, the card network calculates net positions: across all the day's transactions, how much does each issuing bank owe each acquiring bank?
This netting matters. If bank A's cardholders spent $10 million at merchants who bank with bank B, and bank B's cardholders spent $9.5 million at merchants who bank with bank A, the network doesn't arrange $19.5 million worth of transfers. It nets them to a single $500,000 transfer from bank A to bank B. That dramatically reduces the volume of actual interbank transactions.
The interbank transfers themselves happen via settlement systems. In the US, this runs through the Federal Reserve or private clearinghouses. Settlement typically happens once per business day at a fixed time. Funds arrive in the acquiring bank's account, and the acquiring bank then deposits into the merchant's account, minus their processing fees.
The total elapsed time from authorization to funds-in-merchant-account is typically one to three business days, depending on the acquiring bank's policies and the settlement timing of each leg.
Chargebacks
A chargeback is what happens when a cardholder disputes a transaction. The issuing bank reverses the funds provisionally: the money goes back to the cardholder immediately, without waiting for the dispute to be resolved. The merchant's acquiring bank is notified, and the amount is clawed back from the merchant's account.
The merchant then has a window (typically 30 to 120 days, depending on the reason code and network rules) to respond with evidence: shipping confirmations, signed receipts, communication logs, whatever demonstrates the transaction was legitimate. If the evidence is compelling, the issuing bank may reverse the chargeback and return the funds to the merchant. If not, the chargeback stands, and the merchant eats the loss plus a chargeback fee, typically $15 to $100 per incident, regardless of the transaction size.
The entire flow runs roughly in reverse of authorization: issuer initiates, network routes, acquirer notifies merchant. Chargebacks are the most expensive operational cost of accepting card payments for many merchants. A high chargeback rate (above roughly 1% of transactions) triggers additional scrutiny from card networks and can result in a merchant losing the ability to accept cards entirely.
Why it takes days
The delay isn't a technical limitation in the sense of "computers aren't fast enough." It's a consequence of architecture choices that made sense when this system was designed in the 1970s and that are now expensive to change.
Batch processing was rational when it was the only economical option. Running clearing and settlement continuously would have required continuous staffing and real-time reconciliation across thousands of institutions, prohibitively expensive before modern computing infrastructure.
Net settlement reduces the number of actual interbank money movements. Each settlement cycle handles an enormous number of transactions with a fraction of the transfers a gross-settlement system would require. The tradeoff is waiting for the cycle to close before anything moves.
Cut-off times compound the delay. Each leg of the system (merchant to acquirer, acquirer to network, network to issuer, settlement) has its own cut-off time. A transaction that narrowly misses one cut-off waits for the next cycle.
Cross-border transactions add correspondent banking delays. If your issuing bank and the merchant's acquiring bank don't have a direct settlement relationship, which is common for cross-currency transactions, there are intermediate banks in the chain, each adding their own processing time and cut-off windows.
Newer rails do it differently
When someone says "we want instant payments," they're asking to redesign this entire settlement chain. Some newer systems have done exactly that. UK Faster Payments, SEPA Instant Credit Transfer in Europe, and RTP (Real-Time Payments) in the US all move money in seconds rather than days.
They do it by giving up netting. Instead of batching transactions and settling net positions once per day, they settle each transaction individually and immediately: gross settlement in real time. This means each transaction requires an actual interbank transfer. The system works only if participating banks maintain pre-funded positions in settlement accounts so they can cover outgoing transfers without waiting for incoming ones.
This requires all participating banks to update their systems, maintain liquidity buffers, and process transactions at any hour. The US banking system has thousands of institutions of wildly varying technical sophistication. Getting all of them onto a new rail is not a product problem. It's a multi-decade infrastructure migration across an entire industry.
The two-second "Approved" on your terminal has always been fast. Making the money actually move that fast is a different problem entirely, one the industry is still solving, institution by institution.
Back to writing