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.

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.

A related but separate question is whether you can submit more than one capture against a single authorization — repeated claims against the same hold, as when a multi-item order ships in stages. That is not partial capture and not incremental authorization (covered above); it is a question about clearing. Each capture generates its own clearing record, so can I capture twice is really can I submit multiple clearing records against one authorization — and for Visa, that is not left to provider discretion. It is written into the rulebook, narrowly, with real conditions attached.

Visa's rulebook covers this in two adjacent sections that govern different constructs. Section 5.7.3.1, Prohibition against Split Transaction, governs how many Transaction Receipts a single transaction may be split across. It states: "A Merchant must not split a Transaction by using 2 or more Transaction Receipts, except for the following:" — followed by a named exception list (advance payments, individual airline and cruise-line tickets, installment transactions, original credit transactions, a split between a Visa card and another form of payment, and region-specific carve-outs for service fees and US railway tickets). Split shipment is not on that list — this section is not what makes split shipment permitted.

Section 5.7.3.2, Single Authorization Request for Multiple Clearing Transactions, governs a different construct: not how many receipts one transaction is split across, but how many Clearing Records may follow a single Authorization. It opens: "A Merchant may obtain a single Authorization and submit multiple Clearing Records only if one of the following:" — and names three routes. The first is a merchant-category gate: airlines, cruise lines, and US railway merchants. The second is the one that matters for a typical e-commerce split shipment — a card-absent merchant that ships goods, and only if every one of several conditions holds: the purpose is to support a split shipment of goods, and each shipment's transaction receipt carries the same payment credential and expiration date and the same merchant outlet name. Two further, customer-facing conditions sit alongside those. Visa's rule states: "The Merchant discloses to the Cardholder the possibility of multiple shipments on its website and/or application or in writing." And separately: "With each shipment, the Merchant notifies the Cardholder of the Transaction amount of the shipment." A card-absent merchant that does not ship physical goods — most subscription and services businesses — is not covered by this branch at all. The third route is regional and narrower still: in the LAC region, a domestic installment transaction in Brazil. Where a merchant qualifies under any of the three, the rulebook then requires the mechanism: "The Acquirer must use a Multiple Clearing Sequence Number." That field's format is not documented in this rulebook — it sits in VisaNet's technical specifications — and the rulebook sets no cap on how many clearing records may follow one authorization: it sets conditions, not a count.

The two sections sit next to each other in the rulebook and address related conduct — one is about splitting a transaction's receipts, the other about splitting one authorization's clearing — but the rulebook does not state that 5.7.3.2 is an exception carved out of 5.7.3.1's prohibition; they are separate provisions governing separate constructs. Reading them as a general default followed by a related permission, as the framing above does, is this article's own way of relating the two sections, not something the rulebook itself states.

There's a dispute knock-on worth knowing here. Visa's dispute rules treat every clearing record sharing one Multiple Clearing Sequence Number as a single transaction for two specific counting thresholds. Under Dispute Condition 10.4 (Other Fraud – Card-Absent Environment), a dispute is invalid on an account number where the issuer has already raised more than 35 disputes in the previous 120 days, and a footnote to that rule states: "Individual Transactions that contain a Multiple Clearing Sequence Number that result from the same Authorization are treated as one Transaction toward the 35 Transaction limit." Under Dispute Condition 13.1 (Merchandise/Services Not Received), an issuer must supply a cardholder letter once the cardholder has disputed three or more non-receipt transactions at the same merchant on the same card within a 30-calendar-day window, and the identical footnote wording applies there too, substituting a 3 Transaction limit for the 35 Transaction limit. Five split shipments from one order count as one transaction against both thresholds, not five.

All of this is Visa's rule, from Visa's own current public rulebook — not "the card networks," and not a scheme-wide constant. PaymentBrief could not check this against Mastercard's own rulebook, as with the capture tolerances below, so no Mastercard equivalent is confirmed, and none should be assumed. Whether your acquirer or PSP actually exposes multiple captures under one authorization, and enforces these conditions for you or leaves the burden on you, is a separate, provider-specific question worth confirming directly. For Visa specifically, whether the network allows this has a documented answer, turning on merchant category and, for split shipment, on disclosing the possibility upfront and notifying the customer of each shipment's amount.

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.

Over-capture and capture tolerance

Not every final amount is known at the moment you authorize, and networks account for that with a mechanic distinct from incremental authorization: a capture tolerance — sometimes called an authorization-to-clearing tolerance — that lets you settle for slightly more than you authorized, with no new authorization message at all, for certain merchant categories where a small overrun at the end is routine: a bigger tip than estimated, a top-up at the pump, an extra day's mileage.

Visa's own rules put numbers on this, and Visa's current public rulebook confirms them directly. The Visa Core Rules and Visa Product and Service Rules (18 April 2026 edition) sets out a table of permitted variations between the authorized amount and the clearing amount, by merchant category. Visa's 2019 guidance on estimated and incremental authorizations for card-absent grocery merchants describes this as "the existing 15% authorization-to-clearing tolerance" that merchants can rely on to true up a shortfall — a tip added after authorization, for instance — without sending another authorization, and the current rulebook confirms 15% for that category (listed there as "other cardholder-initiated transactions in the card-absent environment"). The same 15% figure, scoped to travel categories, appears in Visa's 2016 best-practices guide for U.S. lodging, car rental, and cruise line merchants, and it is still current: an incremental authorization is only required once the final purchase amount exceeds the sum of authorized amounts by more than 15% for lodging and cruise lines, or by more than 15% or USD 75 — whichever is greater — for car rental. Below that line, the merchant can settle as-is.

Restaurants are the category to watch, because the number has recently moved. A 2006 Visa merchant guide described restaurant authorizations as "automatically valid for the transaction amount plus 20 percent," and that 20% figure held worldwide until 20 February 2026. Effective 21 February 2026, Visa's current rulebook splits it by region: U.S. restaurants, fast food, and caterers (MCCs 5811, 5812, and 5814) now get up to 30%, while the same categories outside the U.S. (Asia Pacific, Canada, CEMEA, Europe, and Latin America and the Caribbean) stay at 20%. Taxicabs, drinking places, and beauty/barber/spa merchants remain at 20% worldwide, unchanged. If you operate U.S. restaurant or foodservice acceptance, the tolerance to build against today is 30%, not the older 20% figure still circulating in older merchant guides and secondary write-ups.

The shape across current sources: U.S. restaurants get roughly three-tenths over; non-U.S. restaurants, taxicabs, and a handful of other card-present categories get roughly a fifth over; lodging, cruise, and car rental get roughly a seventh over, with a dollar floor for car rental. These are Visa's own published, currently-effective figures — not universal card-scheme constants, and not Mastercard's. Confirm the figure against your acquirer's current Visa Core Rules extract before building anything against it; scheme rules are revised, as the February 2026 restaurant change itself shows.

What could not be verified for Mastercard. PaymentBrief could not confirm Mastercard's own tolerance percentages from Mastercard's primary rulebook, its Transaction Processing Rules. Point-of-sale vendor support documentation (Toast) states that Mastercard reinstated a 20% tip tolerance for card-not-present restaurant transactions in 2017 — structurally the same shape as Visa's non-U.S. restaurant allowance, though not necessarily the same percentage as Visa's current U.S. figure — but that is a third party's restatement, not Mastercard's own rule text, and it is not safe to assume Mastercard's lodging or car-rental tolerance mirrors Visa's 15%/USD 75 figures. Treat Visa's numbers in this section as Visa's numbers only.

Why the mechanism exists: hotel stays, car rentals, restaurant tabs, and fuel fills share the property that the final bill genuinely isn't known when the card is first authorized. Re-running a full authorization for every few dollars of drift would be operationally wasteful and risks a decline on an otherwise-good card. The tolerance is a narrow buffer that avoids that round trip for small amounts.

What happens when you exceed it is the operational bite: once the final capture sits outside the tolerance band, the authorization no longer covers the capture. Visa's own estimated-and-incremental guidance ties this directly to dispute exposure — it flags Dispute Condition 11.3, No Authorization/Late Presentment, as the liability merchants face when estimated and incremental authorizations aren't coded or sequenced correctly. The mechanism is the same for a plain over-tolerance capture: the amount above what was authorized (tolerance included) was never actually authorized, so it is chargeback-exposed on that basis alone, independent of any dispute about the goods or service delivered.

Tolerance and incremental authorization are not alternatives you pick between once — they run sequentially, and they don't fully compose. Tolerance is for the last small drift at the very end. Incremental authorization is for the larger or earlier-known growth — an extended stay, an added rental day, items added mid-order. Visa's grocery guidance is explicit that once a merchant has used an incremental authorization anywhere in a transaction, "the ability to use the 15% tolerance is no longer applicable" for the rest of that transaction; from that point, any further gap needs another incremental authorization or a fresh one, not a lean on tolerance.

Vertical playbooks: lodging, car rental, fuel, and delivery

The sections above name hotel, car rental, fuel, and delivery only as one-line examples of where incremental authorization and capture tolerance apply. Here is how each actually runs — and, the detail that gets lost, which layer of the stack owns the behavior. The eligibility and thresholds below are Visa's own published network rules; whether your PSP actually exposes an incremental-authorization API, or auto-reverses an early return, is a separate, PSP-specific decision layered on top.

Lodging. At check-in, the pre-authorization estimate is what the merchant genuinely expects the guest to spend for the stay, plus applicable taxes — Visa's rule is explicit that this must be a real estimate, not a padded arbitrary number, and must exclude speculative charges like a damage buffer. As charges accrue during the stay, the merchant raises the hold with incremental authorizations rather than running disconnected new authorizations. At check-out, the final capture is measured against the running total of all linked estimated-plus-incremental authorizations: inside 15% over, it settles as-is; beyond that, it needs another incremental authorization first. If the final charge comes in under the authorized total — an early departure, or lower spend than estimated — Visa's rule requires the merchant to reverse the unused difference within 24 hours of check-out. A genuine no-show charge is a distinct billing event from a stay charge; billing both a no-show and a completed stay for the same dates on the same reservation is named in Visa's own compliance-violation list, precisely because it double-charges one booking.

Car rental. The initial-hold basis mirrors lodging in structure but with more moving parts: the cost of the intended rental period, plus taxes and an estimated mileage charge — again explicitly excluding a damage or insurance-deductible buffer at authorization time. Fuel, extra mileage, and any damage assessed at return are what typically push the final amount past the original hold. The same greater-of-15%-or-USD-75 test governs whether an incremental authorization is required before settling, and the same 24-hour reversal obligation applies if the car comes back early or under the estimated total. The gap between return and final charge is exactly that processing window: the renter drives off, but fuel-level and mileage reconciliation and any damage inspection can take hours, and Visa's rule expects the resulting incremental authorization or reversal to follow promptly rather than linger.

Fuel. Automated Fuel Dispensers (AFDs) are the outlier in this playbook: Visa's current guidance keeps them on a different authorization framework entirely, not incremental or estimated authorizations. An AFD sends a capped "initial authorization" for a fixed ceiling before the pump total is known, the transaction simply stops if the pump hits that ceiling, and — unlike a hotel or rental — there is no incremental top-up; a wrong estimate means a new transaction, not a raised hold. Visa has also been narrowing who may use this pattern: effective April 2025, only AFDs retain it, while several unattended categories that used to share it — laundries, quick copy, car washes, video rental, vending — are being migrated onto estimated-and-incremental authorizations instead. Status-check and completion messaging matter here precisely because of the capped-ceiling design: get it wrong and either a phantom hold sits at the ceiling amount against the cardholder's available balance, or the pump transaction never reconciles to its authorization — the same misuse-of-authorization and unmatched-clearing exposure this guide's fee discussion covers generically, arriving here through a fuel-specific mechanism.

Delivery and grocery. This is the newest entrant to Visa's eligible-category list, not a longstanding one: card-absent grocery and supermarket transactions only became eligible for estimated-and-incremental authorization treatment in October 2019, alongside parking and EV charging. That timing explains why a delivery or grocery order's final capture routinely differs from the order total: weight-priced items and substitutions are resolved at pack time, after the initial authorization was taken against the cart estimate. Visa's guidance for this category has one point that does not generalize from the restaurant case: the estimated authorization must not include a speculative tip amount, and if the picked or substituted order runs a little over, the merchant can lean on the same tolerance described above rather than sending a new message — but only once. If an incremental authorization has already been used anywhere in that order's lifecycle, the tolerance is off the table for the rest of it.

Layer ownership, restated. Every specific figure and eligibility category above — the tolerance percentages, the USD 75 car-rental floor, October 2019 for grocery, April 2025 for the AFD narrowing — is a network rule, Visa's, not a PSP default and not an issuer courtesy. What an issuer does with a hold that oversits — release it early, or run it to expiry — is issuer behavior, separate from these figures. What a given PSP exposes to you as an API is a PSP-feature-layer decision on top of the network rule: Stripe's Terminal incremental-authorizations feature and Adyen's capture endpoints, both already cited earlier in this guide, are two PSP-specific implementations of the same underlying network mechanics, not evidence that every PSP offers the same call shape. And how promptly your own team sends the reversal, reads the pump-completion message, or reconciles a mileage adjustment is merchant practice — the layer where most of the failure modes in this guide's table already live.

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.