Chapter 4 — A Payment in Motion: The Canonical Payment Flow

You're late!

Picture this: It's Monday morning, 8:55am. You're running late for your 9am meeting, and you desperately need coffee. You rush into WhiteBottle Coffee — your usual neighborhood spot — and breathe a sigh of relief seeing the line move quickly.

When it's your turn, you:

1. Grab your cappuccino
2. Hold your phone near the terminal
3. Hear the satisfying beep
4. Finally, seeing Approved flash on the screen, and you're out the door.

Coffee in hand. Crisis averted.

But here's the thing: in that split second between your payment and that approval beep, something remarkable just happened. Whether you tapped a card, waved your phone, scanned a QR code, or clicked "Pay" on an app — a cascade of checks, messages, and promises fired across multiple institutions faster than you could blink.

How did that happen so fast? And more importantly: Did money actually move that quickly?

The short answer: it didn't.

That instant approval was just the beginning of a journey that can take hours or days, involving banks (we’ve covered a part of this — settlements — in Part I), networks, clearing systems, and a complex dance of IOUs that most people never see. And this journey isn't unique to cards. Every electronic payment — bank transfers, mobile wallets, buy-now-pay-later, even crypto on-ramps — follows a version of the same fundamental pattern.

By the end of this chapter, you will have a big-picture map of the canonical payment flow — The universal sequence that underpins virtually every electronic payment on the planet.

In Part III, we'll zoom into how cards handle each stage. In later parts, we'll see how other rails put their own spin on it. But the skeleton? It's the same everywhere. And that’s what we will cover, now.

The four stages every payment passes through

Regardless of the method of transit — what we call the rail (card networks, ACH, real-time payment schemes, mobile money, SEPA transfers) — every electronic payment moves through the same four conceptual stages:

1. Authorization: Can this payment happen?
2. Clearing: What are the details everyone needs to agree on?
3. Settlement: When does real money actually move between institutions?
4. Reconciliation: Did everything add up correctly?

Some rails compress these stages. A real-time payment like FedNow or UPI can authorize and settle in seconds. A card payment spreads them across days. A direct debit might not even have a traditional authorization step — it relies on a pre-signed mandate instead. But the concepts are always there, even when the timing and mechanics differ.

Think of these four stages as the skeleton of every payment.

The muscles, skin, and clothing change depending on the rail. The bones don't.

Let’s walk through each one.

Diagram 1: The Canonical Payment Flow — the four-stage sequence that underpins every electronic payment in this book. Authorization happens in milliseconds; clearing at end of day; settlement in one to two business days; reconciliation is continuous. The same skeleton applies across cards, ACH, real-time payments, and every other rail — only the timing and participants change.

Authorization: "Can this payment happen?"

Authorization is the moment the payment system asks — and answers — a simple question: should we allow this transaction?

When you paid for your coffee at WhiteBottle, the terminal collected your payment credentials and sent a request upstream:

1. This person wants to pay $4.50.
2. Do they have the money?
3. Is this legitimate?

What happens next depends on the rail. In a card payment, that request races through the merchant's acquiring bank (the acquirer), across a card network like Visa, to your issuing bank (the issuer) — which checks your balance, runs fraud models, and sends back an approval or decline, in under two seconds. In a bank transfer, your bank verifies sufficient funds and validates the recipient. In a mobile wallet like M-Pesa, the telecom operator checks your wallet balance. In a buy-now-pay-later flow, a lender makes an instant credit decision.

Inside the issuing bank, that request hits a split-second checklist:

The issuer's two-second decision: three gates — validity, funds, fraud — then a hold. Fail any gate and the terminal reads Declined.

The specifics vary enormously, but the function is universal:

1. Verify the payer can pay
2. Confirm the transaction looks legitimate
3. Reserve or commit the funds.

A few things are true about authorization across almost every rail:

1. It's the fastest stage: Authorization typically happens in milliseconds to seconds. It has to — you're standing at a counter, or staring at a checkout screen, waiting for an answer.
2. No money moves yet: In most systems, authorization creates a hold or a commitment, not an actual transfer. Your available balance drops, but the funds haven't left your account. They're earmarked, promised, reserved — but still sitting in your bank.
3. It's a promise, not a guarantee: An approved authorization means "yes, right now, this looks good." It doesn't mean the payment can't be reversed, disputed, or adjusted later. The finality comes downstream.

We'll dig deep into how card authorization specifically works — the fraud checks, the message formats, the split-second decision logic — in Part III of this book. For now, just know that Authorization is the entry-point. Every payment starts here.

Clearing: "Let's agree on the details"

Authorization answered the question "can this happen?"

Clearing, on the other hand, answers a different question: "what exactly happened, and who owes whom?"

Clearing is the information exchange phase. No money moves during clearing — not a cent. But without it, settlement can't happen, because nobody would agree on the numbers.

Here's the analogy: if authorization is the handshake that says "deal," and settlement is the wire transfer that delivers the cash, then clearing is the invoice. Every party in the transaction sits down and agrees on the details:

1. Who paid what
2. For how much
3. What fees apply.

In card payments, clearing happens in batches. At the end of the business day, a merchant's system bundles all approved transactions into a file and sends it to their bank. That bank routes each transaction through the card network to the customer's bank. Fees like interchange are calculated. Pending holds become posted charges.

It's methodical, it's overnight, and it runs on scheduled file transfers that would feel right at home in the 1990s.

Clearing isn't limited to cards. When a company sends payroll via ACH, the batch file of payment instructions submitted to the clearing house is the clearing step. When a SEPA credit transfer moves through the eurozone, the payment instruction flowing between banks through the clearing system serves the same function. Even in real-time payment systems like FedNow or India's UPI, there's still a clearing step — it's just compressed into the same moment as settlement, happening so fast it's invisible.

In other words, Clearing is where everyone gets on the same page about what's owed.

The timing varies — overnight batches for cards, seconds for real-time rails — but the function is the same.

A few things can go wrong during clearing:

1. Transactions can go missing from batch files.
2. The authorized amount might not match the final amount (think restaurant tips added after the initial approval).
3. Currency conversions for cross-border payments introduce exchange rate risk between authorization and clearing, since rates are never static.

And if a merchant waits too long to submit their clearing files, the authorization hold may expire — a problem called late presentment — leaving the merchant scrambling to collect.

Settlement: "Now the money actually moves"

Settlement is the moment the payment system puts its money where its mouth is.

For the first time in the process, real funds move between financial institutions.

Here's something that might surprise you: your $4.50 coffee doesn't travel as a standalone payment from your bank to WhiteBottle's bank. That would be wildly inefficient. Instead, most payment systems settle on a net basis.

Think of it like splitting a dinner bill among a group of friends — except the group is every bank in the country, and the dinner bill is every transaction from the past 24 hours. A card network like Visa adds up everything each bank's customers spent across all merchants, subtracts refunds and reversals, and arrives at a single number: the net amount each bank owes or is owed. One transfer per bank per cycle — not millions of individual payments.

This netting is dramatically efficient. An issuing bank with 100,000 transactions in a day doesn't make 100,000 separate payments. It makes one.

The actual money moves through what's sometimes called a settlement system — often involving a country's central bank or a designated settlement bank. Card networks use their own settlement infrastructure. On the other hand, ACH payments settle through the Federal Reserve or The Clearing House. The following list shows a range of settlement systems worldwide:

SEPA transfers settle through the European Central Bank's TARGET system. Real-time payment systems like FedNow settle instantly, transaction by transaction, through central bank accounts — skipping the netting step entirely because speed matters more than batching efficiency.

The standard timeline for card settlement is T+2 — two business days after the transaction.

Your Monday coffee gets settled on Wednesday. Some modern fintech companies offer faster settlement by advancing funds to merchants before the network cycle completes, absorbing the timing risk in exchange for a fee. Meanwhile, real-time payment rails settle in seconds. ACH typically settles in one to two business days, with same-day ACH available for a premium.

As we have covered in the previous chapter, settlement carries real risks:

1. Credit risk: A bank might not be able to pay what it owes.
2. Liquidity risk: A bank might have the money but not have it available at the right moment.
3. Cut-off risk: A bank might miss a settlement deadline, pushing everything to the next cycle.

Payment systems manage these risks through collateral requirements, prefunding rules, and strict deadlines — but they never fully disappear.

To complicate things further, even after settlement, a payment isn't always final.

For instance, card payments can be reversed through chargebacks (which we will cover in Part III) for 60 to 120 days. ACH payments can be returned. Only a few systems — like real-time gross settlement through central banks — offer true, irrevocable finality at the moment of settlement.

Reconciliation: "Did everything add up?"

Settlement moved the money. But did the right money move to the right places in the right amounts?

That's what reconciliation answers. It's the process of comparing records across systems to make sure they agree. Think of it as the financial equivalent of checking your parachute before you jump — you really want to know everything matches before there's a problem you can't fix.

Every participant in a payment keeps their own ledger. The merchant tracks what they sold. The merchant's bank tracks what it submitted for clearing and what it received in settlement. The network tracks what flowed through it. The customer's bank tracks what it charged and what it paid out. Reconciliation is the daily ritual of comparing all these ledgers against each other.

When the numbers don't match, someone has to investigate.

Common problems include:

1. Ghost transactions: A charge appears in one system but not another
2. Amount mismatches: The authorized amount doesn't match the settled amount
3. Duplicate transactions: The same payment recorded twice, often from a timeout and retry
4. Missing settlements: Clearing records say $10,000 should have arrived, but only $8,500 did

Reconciliation isn't glamorous. It's automated reports, exception queues, and patient investigation. But it's essential. Without it, errors compound silently until someone's budget is wrecked or a regulator comes asking questions.

This process isn't unique to cards, either. Banks reconcile their ACH files. Payment processors reconcile their real-time payment logs. Cryptocurrency exchanges reconcile their on-chain and off-chain records. Every payment rail that involves intermediaries needs reconciliation — because wherever there are multiple ledgers, there's the possibility they disagree.

The universal pattern

Let's zoom back out. Now that you have the framework, try applying it yourself: how would a bank transfer, a real-time payment, or a stablecoin transaction map onto the four stages?

Here's how it looks:

The timing compresses or expands. The participants change. The message formats differ.

But the four-stage pattern holds. Authorization, clearing, settlement, reconciliation — this is the heartbeat of modern payments.

Back to your coffee

Let's revisit WhiteBottle Coffee and trace your $4.50 cappuccino through the full lifecycle — this time, knowing what each stage means.

1. Monday, 8:57am Authorization: You hold your phone near the terminal. In under two seconds, your payment credentials travel upstream to your financial institution, which checks your balance, runs fraud checks, and sends back an approval. A hold is placed on $4.50 in your account. The screen flashes Approved. You grab your coffee and go. No money has moved.
2. Monday evening Clearing: WhiteBottle's system bundles your transaction with hundreds of others from the day and submits a clearing file. The details travel through intermediaries to your bank, which converts the pending hold into a posted charge. Fees are calculated. Still no money has moved between banks.
3. Wednesday Settlement: Your bank's net obligation: Your coffee plus millions of other transactions, minus refunds — is calculated and settled. Real funds move between your bank, the network, and WhiteBottle's bank. WhiteBottle's bank credits their merchant account, minus processing fees. For the first time, real money has changed hands.
4. Daily — Reconciliation: WhiteBottle's bookkeeper checks that every transaction from the POS matches what landed in their bank account. Your bank checks that every charge on your statement matches an actual cleared transaction. The intermediaries check that their books balance. If anything's off, an investigation begins.

Two to three days from tap to cash. This pattern repeats billions of times a day across every electronic payment system on the planet.

What's next

You now have the aerial view — the canonical payment flow that underpins all modern electronic payments.

You know that what looks like an instant transaction is really a multi-stage, multi-party orchestration of verification, information exchange, money movement, and bookkeeping.

But we've kept things deliberately high-level. We haven't named the specific players — the acquirers, issuers, networks, processors, and platforms whose roles shape how payments actually work in practice.

In Chapter 5, we'll meet the cast of characters. You'll learn who does what, who pays whom, and why the ecosystem looks the way it does. Later in this Part — in Chapter 8 — we'll explore why geography still matters: why a payment in Tokyo looks nothing like a payment in Lagos or London.

And in Part III, we'll zoom into the dominant rail — cards — and walk through exactly how authorization, clearing, settlement, and disputes work at the protocol level. Everything we've sketched here in broad strokes, Part III will render in high definition.