Authorization, Clearing, Settlement: The Three Clocks of a Payment

Every card payment passes through three phases, and each runs on its own clock.

The phases exist because they optimise for different things. Authorization optimises for latency: the cardholder is standing at the till. Clearing optimises for completeness: the exact final amount, with all data attached. Settlement optimises for efficiency: rather than millions of tiny transfers, banks exchange one netted position each.

Almost every confusing behaviour of card payments, from holds that linger to refunds that crawl, is one of these clocks showing through.

The authorization message is a small, structured request that crosses the whole four-party model and comes back, in roughly the time it takes to read this sentence.

The terminal or checkout builds the request: card credentials, amount, merchant identity, and context like whether the card was present. The acquirer forwards it to the network; the network reads the bank identification number and routes to the issuer.

The issuer does the real work in tens of milliseconds: is the card valid and not reported stolen, is there available balance or limit, does the fraud model like this transaction, do any rules like spending controls apply. It answers with an approval code or a decline reason, and the answer retraces the path.

Approved does not mean paid. It means the issuer has reserved the amount against the cardholder's available balance and promised to honour a matching clearing record when it arrives.

The hold placed at authorization is a reservation, not a debit. It reduces the cardholder's available balance immediately, but nothing has been charged. The charge happens only when a clearing record arrives and is matched against the hold.

That matching step is where everyday oddities come from:

• The vanishing hotel hold. Hotels and fuel pumps authorize an estimated amount before the final one is known. If the final clearing amount differs, or the merchant never clears at all, the hold lingers until it expires on the issuer's schedule, often several days.
• The double charge that isn't. A retried authorization can create two holds for one purchase. Only one clearing record will arrive; the orphan hold evaporates on expiry, but until then the money looks spent twice.
• Tips and adjustments. A restaurant clears for more than it authorized, within scheme tolerances. The systems are built for the amounts to disagree.

In practice: an authorization is a claim that expires. Merchants who wait too long to clear, common in slow fulfilment, risk the hold expiring and the payment declining at capture, which is why e-commerce platforms re-authorize before shipping late orders.

Clearing is the unglamorous phase where the transaction stops being a reservation and becomes a payable item.

At the end of the day, the acquirer collects the day's captured transactions into files and submits them through the network to each issuer: final amounts, merchant details, currency, and the data needed to match each record to its authorization. The network validates, sorts and forwards, and calculates the fees that ride along with each record.

Two consequences of clearing being a batch process are worth pinning:

• The capture decision belongs to the merchant. Authorization happens at order time, but the merchant chooses when to capture, at shipment for goods, at checkout for coffee. Auth-then-capture-later is a deliberate two-step, not a failure.
• Currency conversion and fees crystallise here. The rate applied to a foreign transaction and the interchange attached to it are determined when the record clears, not when the card was tapped, which is why the amount on a statement can differ slightly from the amount on the receipt.

Settlement is where money finally moves between banks, and its defining trick is netting.

Suppose an issuer's cardholders bought 10 million worth from merchants of a given acquirer today, and that acquirer's bank issued cards whose holders bought 8 million from merchants acquired by the first bank. Gross, that is 18 million of transfers. Net, one bank owes the other 2 million. The network computes these net positions across all members and instructs transfers of only the differences, through designated settlement banks and accounts.

Netting is why settlement can be cheap at billions-of-transactions scale, and it is also why settlement is a scheduled, end-of-day affair: you cannot net a flow you have not finished collecting.

Note what settlement does not include: the merchant. Settlement gets money to the acquirer. The merchant is paid by its acquirer or PSP on a separate payout schedule, daily, weekly, or with a rolling delay held back as a cushion against refunds and disputes.

The asymmetry that annoys every consumer has a clean mechanical explanation.

Some issuers now post refunds as soon as they see them and a few markets are faster, but the default experience is the batch clock, undisguised. The one-line summary: charges get the real-time rail because risk demands it; refunds get the batch rail because nothing about them is urgent to the system, only to you.

Follow 100 through the machine to fix the sequence.

1. Tuesday 09:00. Cardholder taps for a 100 purchase. Authorization approved in under a second; the issuer holds 100 of the cardholder's limit. No money has moved.
2. Tuesday 22:00. The merchant's PSP captures and submits the day's batch. The 100 record clears toward the issuer overnight.
3. Wednesday. The network computes net positions; the issuer's settlement account pays out; the acquirer is funded. Interchange and scheme fees are deducted along the way, so roughly 98 to 99 arrives at the acquiring side for a typical European consumer card.
4. Thursday or later. The PSP pays the merchant according to its payout schedule, minus its own fee.
5. Next month. The cardholder pays the issuer 100 with the card bill.

Five dates, one purchase. The merchant's finance team reconciles step 4 against step 1, and the difference between what was authorized and what arrived is the subject of the next lesson: the fee stack.

It is fair to ask why payments still work this way when a bank transfer app moves money in seconds.

What the three-phase design buys is scale and offline-tolerance. Authorization is tiny and fast because it carries only a decision; the heavy data rides the batch. Netting collapses interbank obligations by orders of magnitude. The credit model means a payment can be accepted even when systems downstream are degraded, because the promise, not the money, is what moves at the till.

What it costs is latency for anyone waiting on actual funds, an entire reconciliation industry to match records across the three phases, and windows of credit risk between every pair of parties.

Real-time payment systems, built this century, collapse authorization and settlement into one instant, irrevocable transfer. They are genuinely different rails with different trade-offs: instant finality, but no built-in dispute machinery and no credit cushion. Cards did not choose their architecture out of ignorance of that alternative; they chose batch netting because in their world, disputes, credit and scale came first. Which trade you want is a business decision, not a technology fashion.