Authorization, Capture, and Settlement: Payment Lifecycle for Operators

The checkout screen says “approved,” and the operator assumes the money is theirs. It isn’t. An approval is the issuer confirming the funds exist and earmarking them — a promise to pay, not a payment. Nothing has settled. The cardholder’s available balance dropped, but your bank account has not moved, and depending on what you do next, it may never move at all.

That gap — between the green “approved” and money actually in your account — is where a surprising amount of operational pain lives. Holds expire before you ship. Captures fail silently after an approval. The same order gets captured twice. The amount that settles doesn’t match what you captured. None of these are exotic edge cases; they are the routine failure modes of running card payments, and every one of them lives in the steps that happen after the customer sees “approved.”

This guide is the mechanics of those steps. It is a companion to the payment-stack actors guide, which maps who does what — issuer, acquirer, gateway, PSP, and who holds your money. That guide owns the actor map and the custody question; this one owns the lifecycle: what happens, in what order, from authentication through settlement, and why “approved” does not mean “paid.”

The lifecycle: authentication → authorization → capture → clearing → settlement

A card payment is not one event. It is a sequence, and the steps are genuinely different operations with different effects on money. Conflating them — especially treating authorization as settlement — is the root of most of the confusion.

• Authentication (optional): proving the cardholder is who they say they are, typically via 3DS2. It runs before authorization and is distinct from it — authentication verifies identity; authorization checks funds. It can carry a fraud-liability effect, but that is scheme- and contract-defined; this guide only draws the line and defers the depth to the authentication tax.
• Authorization: the issuer earmarks funds and returns an approve or decline. This is the authorization — a hold, not a transfer.
• Capture: you claim some or all of the approved amount. This is the instruction that money should actually move. Without a capture, an approval eventually expires and nothing is ever charged.
• Clearing: the captured transactions are exchanged and reconciled between acquirer and issuer through the network.
• Settlement: funds actually move and land in your account. This is settlement — usually batched, and usually a day or several days after capture.

The single distinction to hold: authentication ≠ authorization ≠ capture ≠ settlement. Each is a separate step, and money is only earmarked at authorization, instructed to move at capture, and actually moved at clearing and settlement.

Why “approved” does not mean money has moved

The core teaching of this guide fits in one sentence: an authorization is a hold on the issuer’s side, not a transfer to you. When the issuer approves, it confirms the funds are there and reduces the cardholder’s available balance by the authorized amount. That is all. No money has left the cardholder’s account, and certainly none has reached yours.

Money begins moving only when you capture, which feeds the transaction into clearing, and it actually arrives at settlement — typically days later. Until then, “approved” is an IOU from the issuer that you have a few days to act on. If you never capture, the hold simply lapses and the IOU evaporates; the customer was never charged.

This is also why the custody question matters, and why it lives in the companion guide. In the gap between capture and settlement, your money is sitting in someone else’s account — the acquirer’s or the PSP’s — and they control when it reaches you. The payment-stack actors guide owns that custody point in full; here it is enough to know that “approved” and “settled” are separated by both time and a custodian who is not you.

Authorization holds, capture windows, and expiry

An authorization hold is not permanent. It reduces the cardholder’s available credit or balance for the authorized amount, and it survives only for a limited window. If you do not capture within that window, the authorization expires: the hold is released back to the cardholder, and a late capture attempt may fail outright, or succeed only as a weaker, more expensive transaction (a downgrade that can cost interchange and, where applicable, lose a guarantee or liability protection tied to the original authorization).

The hard caveat lives here, and it is non-negotiable: capture windows vary by scheme, card type, acquirer, PSP, region, and merchant category — there is no universal number, so never hardcode one. When a provider documents a default, treat it as that provider’s example, not a rule. Stripe, for instance, documents card-not-present holds of seven days for Mastercard, American Express, and Discover and five to seven days for Visa, with different windows for card-present transactions and other payment methods — but those are Stripe’s documented defaults, cited here as a provider example and explicitly not a scheme-wide guarantee. Your own window depends on your scheme mix, card types, acquirer, region, and MCC, and it is a number you confirm with your provider, not one you read off an article.

The operational takeaway: track the capture window that actually applies to your transactions, per scheme and per provider, and capture (or re-authorize) before it lapses.

Full vs partial capture

You do not have to capture the full authorized amount. You can capture less — a partial capture — which is the right move when you ship part of an order, fulfill part of a basket, or find an item is out of stock after authorizing the full cart. With many providers, a single partial capture automatically releases the unclaimed remainder of the hold; the exact behavior, and whether multiple captures against one authorization are allowed, varies by provider, so confirm it rather than assuming.

Mind the distinction with partial authorization, which is a different thing entirely. Partial authorization is the issuer approving less than you requested — typically because the card has insufficient funds to cover the full amount. Partial capture is you claiming less than the issuer authorized. One is an issuer decision on the way in; the other is a merchant decision on the way out. They are easy to conflate and operationally unrelated.

Incremental authorization

The opposite case — the final amount grows after the initial auth — is handled by incremental authorization. Instead of running a second, disconnected authorization (which can leave two holds on the card and complicate the eventual capture), incremental authorization raises the existing hold so the final capture stays within an authorized amount.

This is the pattern for open-ended charges: hotel stays where the guest adds nights or room service, car rentals with fuel and mileage, rideshare fares, bar tabs, and fuel pumps that authorize an estimate before the pump total is known. The caveat is the same shape as everywhere else: support varies by scheme, card type, merchant category, and acquirer or PSP, and incremental authorization is not universally available. Some networks restrict it to specific merchant categories. Confirm support with your provider before building a flow that depends on it.

Reversals, voids, and refunds

These three get conflated constantly, and the distinction is operationally load-bearing. An authorization reversal or a void releases an uncaptured hold — no money has moved, so nothing is returned to the cardholder; the earmark is simply dropped and the available balance restored. The two terms overlap heavily and many providers use them interchangeably for the same pre-capture intent.

A refund is a different operation: it returns funds that were already captured and settled. That is a new money movement — money going back out — not the cancellation of a hold. The difference matters for timing (a reversal restores available balance quickly; a refund can take days to land), for customer experience (a phantom hold after a cancellation is a support ticket waiting to happen), and for cost.

The rule of thumb: before capture, reverse or void; after capture, refund. Picking the wrong one either fails or costs you unnecessarily.

Delayed capture and fulfillment

For physical goods, the natural pattern is authorize at order, capture at ship. You authorize when the customer places the order to confirm the funds and reserve them, and you capture when the goods actually leave — because capturing before fulfillment can mean charging for something you cannot ship, and many card-scheme expectations favor capturing at fulfillment for physical goods.

The risk in this pattern is the window. If fulfillment takes longer than the authorization survives, the hold expires before you capture. When that happens, you re-authorize — run a fresh authorization before capturing — because the original hold is gone and a late capture against it may fail or downgrade. The longer your fulfillment time, the more this matters: a same-day-ship merchant rarely brushes the window; a made-to-order or backorder merchant lives against it and needs a deliberate re-auth path.

Settlement and reconciliation

Capture is not settlement. Capturing instructs the money to move; settlement is when it lands. Captured transactions are typically batched and settled together on the provider’s schedule, and the timing varies — by provider, region, and your contract — so, as everywhere in this guide, do not assume a universal number.

The subtler trap is that the amount you captured may not equal the amount that settles. Fees, FX conversion, scheme costs, refunds, chargebacks, and other adjustments are netted out between capture and settlement, so the deposit in your account is a net figure, not a clean sum of your captures. Reconciling captured-versus-settled is a real operational job, and when the two do not line up, the cause is usually one of those adjustments — or a genuine break.

This guide deliberately stops at the concept that settlement ≠ capture. The taxonomy of what breaks and how to triage it lives in the PSP reconciliation failure runbook, and the structure of the settlement files themselves — how to read what Stripe or Adyen actually sends you — lives in the Stripe/Adyen settlement-file reference. The cash-flow cost of the days your money spends in transit between capture and settlement is quantified in the working-capital cost of payments.

Common operator failure modes

The recurring ways the lifecycle bites operators, with the usual cause and the move. This is operator synthesis — calibrate it to your own provider and contracts.

What to monitor

The lifecycle gives you a clean set of metrics. Watch these and most of the failure modes above surface before a customer or your finance team finds them:

• Capture success rate — the share of authorizations that result in a successful capture; a drop flags the auth-approved-but-capture-failed problem.
• Auth-to-capture time — how long between approval and capture, against your applicable window; rising time means rising expiry risk.
• Expired-auth rate — authorizations that lapsed before capture; directly measures the fulfillment-window mismatch.
• Reversal latency — time from cancellation to reversal sent; this is the customer-hold-after-cancel metric.
• Capture-vs-settlement variance — the gap between what you captured and what settled, beyond expected fees; spikes flag reconciliation breaks.
• Duplicate-capture incidents — counts of double captures or double auths; should be near zero if idempotency is working.

Operator checklist

Practical items to settle before you build, not after the first incident:

• Separate authorization and capture deliberately — decide where auto-capture is fine and where you need a manual capture step (physical goods, delayed fulfillment), rather than defaulting into one mode.
• Track capture windows per scheme and provider — store the window that applies to your transactions and act before it lapses; never hardcode a single universal number.
• Send reversals promptly on cancellation — wire a reversal or void into every cancellation path so customers do not sit on phantom holds.
• Use idempotency keys — on both authorization and capture, to prevent duplicate holds and duplicate charges from retries.
• Reconcile captured vs settled — match every capture to its settlement and net out fees/FX/adjustments; investigate anything left over.
• Re-authorize on expiry — have an explicit path to run a fresh authorization when a hold lapses before fulfillment, instead of attempting a doomed late capture.
• Monitor the metrics above — capture success rate, auth-to-capture time, expired-auth rate, reversal latency, capture-vs-settlement variance, and duplicate incidents.

Scope note

Timing, capture windows, and feature support vary by scheme, card type, acquirer, PSP, region, merchant category, and contract — there is no universal number, and any specific window in this guide (such as the Stripe defaults) is cited as that provider’s documented example, not a scheme-wide rule. This is operational guidance, not legal advice, and it makes no liability claims on your behalf; the authentication liability effect mentioned under the lifecycle is scheme- and contract-defined and covered in 3DS2 and the authentication tax, not here.

This guide is also card-focused. Non-card rails — account-to-account transfers, wallets, real-time payment schemes — have different lifecycles and are out of scope. Verify the specifics that apply to your stack with your PSP and acquirer. For the levers that lift authorization rates — retries, network tokens, BIN-level tuning — see authorization optimization; for the revenue math of those rate gains, see auth-rate point economics. This guide owns the mechanics; those own the optimization.

Related references

• The Payment Stack: Issuer, Acquirer, Gateway, PSP — who does what, and who holds your money in the capture-to-settlement gap.
• Authorization Optimization — the levers that raise auth rates (retries, tokens, BIN tuning).
• Auth-Rate Point Economics — the revenue math of moving the authorization rate.
• 3DS2 and the Authentication Tax — the authentication step and its scheme- and contract-defined liability effect.
• PSP Reconciliation Failure Runbook — the break taxonomy and triage when settlement does not reconcile.
• Stripe/Adyen Settlement-File Reference — how to read the settlement files your provider sends.
• The Working-Capital Cost of Payments — the cash-flow cost of the float between capture and settlement.

For term definitions — authorization, capture, settlement, partial authorization, incremental authorization, authorization reversal, and void — see the Payments Glossary.