The payment lifecycle: authorization to settlement

The payment lifecycle is the fixed sequence a payment moves through from the moment it is approved to the moment funds land in a merchant's account: authorization, capture, clearing, settlement, and payout. Each step does exactly one job, and the money is in a different state after each one. Most people picture a card payment as a single event at the tap; it is actually a chain, and almost everything that goes right or wrong in payments happens because these steps are separate, not simultaneous.

Understanding the chain is the difference between a payment that reconciles itself and a support ticket. So walk it once, end to end, in order.

Authorization: a hold, not a transfer

Authorization is a question, not a movement. When a card is tapped, the request travels to the issuer, which checks that the account exists, is in good standing, and has funds or credit for the amount. If so, it places a hold — earmarking the money so it cannot be spent twice — and returns an authorization code. No money has moved. The merchant now holds a promise that the funds are good, valid for a scheme-defined window. An authorization can be reversed (a void) before anything is collected, and it expires on its own if never used. This is why the balance on a card drops the instant you pay but the statement line firms up later: the drop is the hold, not the charge. An authorization can also be declined outright — insufficient funds, a fraud rule, an expired card — and a good gateway distinguishes a soft decline worth retrying from a hard one it should not. Because the hold is the issuer's promise that the money is good, the merchant is safe to hand over goods on the strength of the authorization code alone, before a single unit of currency has actually left the customer's account.

Capture: turning the hold into a claim

Capture is the merchant saying “collect this now.” It converts the hold into an actual request for the money. Capture can be full, partial (a smaller final amount than authorized — a shipped item cheaper than the pre-auth), or delayed (authorize at order, capture at dispatch). Auth-and-capture as one step is the default at a shop till; auth-only-then-capture-later is how hotels, fuel pumps, and marketplaces work, because they do not know the final figure when the card is presented. The gap between authorization and capture is a deliberate, useful seam — it is where a merchant decides what to actually charge.

Clearing: the batch that reconciles

Captured payments do not settle one by one in real time. They are gathered into files and exchanged between the merchant's acquirer and the card schemes in batches — clearing. In this step the transactions are matched, the amounts are netted, and scheme fees and interchange are applied so everyone agrees on who owes whom how much. Clearing is a reconciliation job, not a money movement: it produces the agreed totals that the next step acts on. It is also, structurally, a batch process — which is the real reason a payment that felt instant at the till takes days to land as cash. Nothing about the batch is a limitation of computers; it is how the schemes are built to net thousands of institutions against each other efficiently, exchanging agreed totals once a cycle rather than firing a transfer for every coffee.

Authorization is a promise, capture is a claim, and settlement is the only step where money actually moves. Confusing the three is how a business books revenue it does not have yet.

— Protocore · Payments engineering

Settlement: money actually moves

Settlement is where funds genuinely change hands between banks. Using the netted totals from clearing, the scheme moves money from issuers to acquirers, each institution settling its net position rather than every individual transaction. Settlement runs to a value date — the day the funds are actually available — which is why payments carry a T+1 or T+2 rhythm: the money is real, but it arrives on the scheme's calendar, not the customer's clock. Everything before this step was bookkeeping; this is the step where the ledger entries become spendable balances. An institution that owes on net pays; one that is owed receives — and because it is net, the sums that actually move between banks are a fraction of the gross value of the day's payments, which is what makes a scheme carrying millions of transactions a manageable number of settlement movements.

Payout: from acquirer to your account

Settlement lands the money with the acquirer; payout moves it to the merchant. On a schedule — daily, weekly, or on demand — the acquirer pays the merchant's accumulated balance into their bank account, net of processing fees and any reserve held against refunds and disputes. This is the number a business actually sees, and the point where reconciliation either works or hurts: the payout is a net figure covering many transactions, so matching it back to individual orders is its own exercise. A gateway that carries each order's identity all the way through makes that trivial; one that does not turns every payout into a spreadsheet. Our gateway's flow, /products/gateway, is built so a payout reconciles against the orders that composed it.

Where crypto adds a bridge

A crypto or stablecoin payment does not replace this chain — it adds one conversion leg to the front of it. Instead of an issuer's authorization hold, the payment is confirmed on-chain: the customer signs a transfer, and finality is reached as the network adds confirmations rather than as a bank approves a hold. Once confirmed, an off-ramp converts the crypto into fiat, and from there the money re-enters the same clearing, settlement, and payout path every other payment uses. The novelty is contained to that first leg; the back half stays deliberately boring. That is the design rule — keep settlement ordinary and put the new mechanics only where they are unavoidable — because the treasury, the reconciliation, and the auditor downstream should not be able to tell how the payment started. How many confirmations count as final is a policy choice, not a law of the chain: a higher bar trades speed for certainty against a reorganisation, and the off-ramp waits for whatever depth the risk appetite sets before releasing fiat into the settlement path.

Why the seams matter operationally

Refunds, reversals, and disputes each attach to a specific stage, and getting the stage right is the whole game. Cancel before capture and you void an authorization — no money ever moved, nothing to return. Cancel after settlement and you issue a refund — a fresh payment in the opposite direction, with its own lifecycle. A chargeback reaches back through clearing to claw a settled amount. Treat these as one undifferentiated “cancel” and the ledger drifts; treat them as operations on distinct stages and every case has a correct, auditable move. The vocabulary — authorization, capture, clearing, settlement, value date — is collected at /glossary.

The single idea worth carrying away: a payment is a chain of states, not an event. Authorization reserves, capture claims, clearing agrees, settlement moves, payout delivers — and a crypto leg only bolts a conversion onto the front. Money is a promise until settlement and a fact after it, and a business that books it before the fact is counting money it does not yet have. Know which state a payment is in, and the rest of payments operations stops being mysterious.