Authorization checks whether a card payment can be approved and places a temporary hold; capture tells the payment system to collect the approved amount and send it into clearing and settlement. A void cancels an uncaptured authorization. The right choice depends on fulfillment timing, authorization expiry, partial orders, and the processor’s transaction rules.
Table of Contents
- Payment authorization vs. capture: the short answer
- What happens during authorization?
- What happens during capture?
- Authorization vs. capture in common merchant scenarios
- Voids, refunds, reversals, and expiration are not interchangeable
- The settlement handoff: what merchants should monitor
- A practical authorization-and-capture operating procedure
- API and data design considerations
- Limitations and merchant-specific variables
- Conclusion
- Frequently Asked Questions
Payment authorization vs. capture: the short answer
Authorization and capture are separate operational decisions, even when a checkout makes them look like one event. During authorization, the issuer approves or declines the request and the available credit or funds may be reserved. During capture, the merchant confirms the amount to collect. The capture then starts the clearing and settlement path for the approved transaction. Visa describes capture as the request that initiates clearing and settlement of a previously approved authorization. [1]
That distinction matters because an approval is not the same as revenue received. Mastercard’s transaction-notification documentation says authorization and clearing are separate lifecycle steps, and that a transaction is final only once it has cleared. An authorization can be canceled, reversed, or allowed to expire without producing a clearing record. [3]
For an immediate-delivery purchase, a combined sale or automatic-capture flow may be sensible. For a hotel stay, delayed shipment, restaurant tip, preorder, repair estimate, or other order whose final amount or fulfillment date is not yet known, separate authorization and capture may give the merchant more control. It also creates a deadline: the merchant must capture or void before the authorization window and processor rules make that action unavailable.
What happens during authorization?
Authorization is the approval request, not the final collection. The merchant or its gateway sends transaction details through the acquiring side and card network to the issuing bank. The issuer evaluates the request under its own account, risk, and available-funds rules, then returns an approval, decline, or other response. Mastercard describes its Authorize operation as verifying card details, checking available credit, and attempting to reserve the requested funds. [2]
An approved authorization normally creates a hold or reserved amount. The customer may see that hold in an app or statement, but the merchant should not treat the amount as settled cash. Mastercard states that an authorization does not debit the payer’s account in the same way as a capture; it reserves the order amount so a later capture can debit the card and transfer funds to the merchant. [2]
The authorized amount is also a control boundary. A capture request generally cannot exceed what remains authorized unless a particular network and processor support a permitted overcapture scenario. Stripe’s capture API, for example, requires the amount captured to be less than or equal to the capturable amount for the PaymentIntent. [6] Merchants should therefore model the authorized amount, captured amount, remaining amount, and any released amount as separate fields rather than overwriting one “paid” value.
An authorization is not a promise that the customer’s funds will remain available forever. The hold has a validity window that varies by card network, transaction type, card-present versus card-not-present context, merchant category, acquirer, and processor configuration. Stripe documents different windows for card brands and transaction classifications, while Mastercard Gateway says the validity period is determined by the acquirer, card type, and order-certainty configuration. [4] [2]
The practical question is not simply, “Was it approved?” It is, “When does this authorization expire, and what does this processor require before then?” Store the expiration timestamp when the platform provides it. If the integration does not expose one, obtain the rule from the acquirer or payment service provider instead of hard-coding a universal number.
What happens during capture?
Capture is the merchant’s instruction to collect all or part of the approved amount. It normally follows a business event such as shipment, completion of a service, check-in, delivery, or confirmation of the final order total. Visa’s acceptance documentation says the Capture API initiates clearing and settlement of a previously approved authorization and should be submitted as soon as the client fulfills the customer’s order, subject to its stated timing limit. [1]
A full capture collects the entire amount still authorized. A partial capture collects less, leaving a balance that may need to be released or voided. The exact behavior is processor- and network-specific. Stripe explains that partial capture releases the remaining amount and that most payments allow only one capture, although some card payments support multicapture. [4] Mastercard Gateway also describes capturing less than the authorized amount and voiding the outstanding authorization when no further capture is intended. [2]
Capture is therefore not the same as settlement deposit. It is the transaction operation that hands the approved amount into clearing. Clearing and settlement records are then produced through the acquiring and network processes. Visa says the client receives settlement and related reports directly or through a sponsor bank, while the acquirer performs settlement and returns end-of-day reports. [1] Mastercard notes that clearing data is available only after the transaction is processed and settled and that most transactions in its notification service appear within approximately five days, with some taking longer. [3]
For accounting, separate at least three milestones:
- Authorized: the issuer approved a request and an amount may be held.
- Captured or submitted: the merchant requested collection and the transaction entered the clearing path.
- Settled or funded: the downstream settlement and merchant-bank posting process completed according to the provider’s reporting and funding cycle.
A customer receipt, a gateway status, and a bank deposit may occur at different times. Reconciliation should match the gateway transaction identifier, authorization identifier, capture identifier, amount, currency, and settlement or batch reference where available. Do not mark an order “paid in full” solely because an authorization succeeded.
Authorization vs. capture in common merchant scenarios
Immediate-delivery ecommerce
A digital download or an item that is handed to the customer immediately may use an automatic capture flow. The merchant receives an authorization response and the platform submits the collection operation without waiting for a later fulfillment event. This can simplify order logic, but it does not remove the need to handle declines, asynchronous statuses, duplicate requests, refunds, and settlement reconciliation.
Physical goods with shipment confirmation
Suppose a merchant authorizes $180 for a cart containing two products. One item ships today for $120, while the second is backordered. The merchant should not assume that the original $180 authorization will remain usable until the backordered item is ready. It should check whether the processor supports partial capture, capture the amount permitted for the shipped goods, and release or void the remaining authorization when no further capture is planned. A new payment for a later shipment may be necessary, subject to customer communication and the payment method’s rules.
If the merchant captures the full $180 before shipping anything, it has made a different operational choice. That choice may create fulfillment, refund, customer-service, and accounting obligations that are not solved by the original authorization. The payment design should follow the actual delivery and cancellation policy rather than treating authorization as permission to collect any time.
Hotels, rentals, and deposits
A hotel may authorize an estimated amount before arrival and capture a final amount at checkout. A rental business may authorize a deposit and later capture eligible charges. The estimate and final amount may differ, but the merchant must stay within the permitted authorization rules, monitor the expiry timestamp, and understand whether incremental authorization, multiple captures, or a new authorization is supported. Stripe specifically uses hotel authorization followed by later capture as an example of manual capture. [4]
This model is operationally useful but not universal. Payment methods differ in whether they support separate authorization and capture, and a card-not-present window may not match an in-person window. Stripe notes that some methods support separate capture while others, such as ACH and iDEAL in its documentation, do not. [4] Confirm capability for each payment method rather than applying card logic to every wallet, bank debit, or buy-now-pay-later method.
Restaurants and variable totals
A restaurant or service business may authorize an initial amount and later capture a final amount that includes an approved adjustment. The available mechanism depends on the network, transaction type, terminal or gateway, and acquirer. The merchant should not increase the captured amount simply because its internal invoice changed. If the final amount cannot be captured under the original authorization, follow the provider’s documented incremental-authorization or new-payment flow.
Voids, refunds, reversals, and expiration are not interchangeable
A void cancels or reverses an authorization before it becomes a settled collection. Visa describes its Void API as reversing an outstanding or previously approved transaction and says voids can also be submitted in timeout situations. [1] Mastercard Gateway says a void on an authorization immediately releases reserved funds when supported, and that a void is available only before the acquirer sends the transaction to the bank for end-of-day processing. [2]
A refund returns money after a capture or settlement has occurred. It is not a substitute for voiding an authorization that will never be captured. Mastercard’s documentation explicitly distinguishes the two: once a transaction has been sent for processing, the merchant must use a refund rather than a void. [2] The customer’s bank may display the release or refund on its own timeline, so “void submitted” should not be presented as a guaranteed instant removal from every customer statement.
A reversal may describe the release of all or part of an outstanding authorization. Product terminology varies. Some gateways call the merchant operation a void and the network message a reversal. The implementation should follow the provider’s status model and retain the original transaction identifiers.
Expiration occurs when the permitted authorization window ends without a valid capture. Stripe states that if an authorization expires before capture, the funds are released and the payment status becomes canceled. [4] Mastercard Gateway likewise describes configured authorization validity periods and an automatic expiry field where supported. [2] Expiration is not a planned fulfillment method. It can leave the order unpaid while the customer still sees a temporary hold that later disappears.
The operational rule is straightforward: if the order will not be captured, void or cancel it promptly; if it has already been captured, refund it through the supported refund operation; if it is approaching expiry, escalate or reauthorize according to the provider’s documented flow.
The settlement handoff: what merchants should monitor
The handoff from capture to settlement is where payment operations often lose visibility. A capture response may mean that the gateway accepted the capture request. It does not necessarily mean that the merchant’s bank account has already been credited. The records may move through gateway, processor, acquirer, network, and merchant-bank reporting systems before funding is visible.
Provider status names can make this timing visible. Stripe, for example, uses a requires_capture state for a separately authorized PaymentIntent and treats succeeded as the completed payment flow; those labels are provider-specific and should not be copied into another gateway without a mapping. [5]
A reliable order and ledger model should retain an immutable event history. At minimum, record authorization requested, authorization approved or declined, capture requested, capture accepted or failed, void requested, void completed or failed, refund requested, refund completed or failed, settlement reported, and funding posted. Preserve timestamps in a consistent timezone and store the provider’s raw status alongside the merchant-friendly status.
Use exception queues for conditions that need human review. Examples include an approved authorization with no capture near expiry, a capture amount that differs from the fulfillment amount, a partial capture with a nonzero remainder, a capture reported without its expected authorization link, and a settlement record that cannot be matched to an order. Mastercard warns that authorization and clearing are not always one-to-one: an authorization may never clear, one authorization may produce multiple clearing records, and the cleared amount may differ from the original authorization. [3]
Do not use a single webhook or browser redirect as the only source of truth. A network request can time out, and a notification can be delayed or duplicated. Query the provider’s transaction record when the result is uncertain, use idempotency controls where available, and reconcile against settlement reports. These are controls, not guarantees that every payment will settle successfully.
A practical authorization-and-capture operating procedure
Start by choosing the transaction model for each product or service. Document whether the order is captured immediately, captured after fulfillment, captured in parts, or canceled when the customer abandons it. The model should reflect when the merchant is actually entitled under its own terms to request collection; this article does not provide legal or accounting advice.
Next, define the state transitions and ownership. The checkout service can request authorization, the order service can signal fulfillment, and a payment worker can submit capture or void requests. Keep the fulfillment decision separate from the payment API call so a transient timeout does not create an accidental duplicate operation.
Then set deadline controls. Save the authorization expiration time, subtract a safety margin appropriate to the provider’s behavior, and alert before the deadline. The margin should be tested, not assumed. A job that runs once per day may be too coarse for a short authorization window or a high-volume shipping operation.
For each capture attempt, validate the remaining capturable amount, currency, order status, and fulfillment amount. If the order is split, decide whether the processor supports multiple captures and how the remaining authorization will be released. If the capture response is unknown, retrieve the transaction before retrying. A second capture request can create a reconciliation problem if the first request succeeded but its response was lost.
For cancellation, use the correct operation. Void uncaptured funds while the authorization is still outstanding. Refund captured funds. If the provider reports that a void is unavailable because the transaction entered processing, stop retrying the void and follow the documented refund or reversal path.
Finally, reconcile daily or at the cadence appropriate to the business. Compare authorized, captured, voided, refunded, settled, and funded amounts. Investigate aged authorizations instead of allowing them to expire silently. The goal is not to make every status change instantaneous; it is to make every difference explainable.
API and data design considerations
A payment integration should expose authorization and capture as explicit actions. Avoid naming an order field simply paid=true when the underlying system can be authorized, partially captured, voided, refunded, or settled. Better fields include authorized_amount, captured_amount, voided_amount, refunded_amount, amount_capturable, authorization_expires_at, and a provider transaction reference.
Use idempotency keys or the provider’s equivalent for capture and void requests when supported. The key should be stable for one business operation and not reused for a different amount or order. Store request and response payloads under appropriate security controls, and avoid logging sensitive authentication data.
PCI SSC describes PCI DSS as baseline technical and operational requirements for entities that store, process, or transmit cardholder data or sensitive authentication data. It also notes that scope and validation depend on the payment environment and payment-brand programs. [7] A hosted payment page, tokenization, or a gateway-managed card form may change the data flows, but it does not automatically eliminate every security responsibility. Confirm the applicable requirements with the payment provider and a qualified security adviser.
For API teams, the most valuable test cases are timing and failure cases rather than only happy-path approvals. Test an authorization that expires, a capture that times out after the provider accepted it, a partial capture, a void after a partial capture, a duplicate webhook, a declined reauthorization, and a settlement record that arrives later than the order update. Test each supported payment method separately because authorization and capture capabilities are not uniform.
Limitations and merchant-specific variables
There is no universal authorization period, universal definition of “settled,” or universal rule for partial capture. Card brand, card-present status, merchant category, transaction indicators, issuer behavior, acquirer configuration, processor product, currency, country, and payment method can change the result.
Processor dashboards may also use labels differently. One system may call an approved but uncaptured payment “authorized,” another may call it “pending,” and a third may expose separate gateway and network statuses. Read the provider’s API and reporting definitions, and map them into an internal state model without losing the original values.
The rules can also change. Before launch or a material product change, verify current network and provider documentation, especially for extended authorizations, estimated orders, incremental amounts, multicapture, wallet payments, card-on-file transactions, and cross-border processing. This educational article is not legal, tax, investment, compliance, underwriting, accounting, or payment-network advice.
Conclusion
Payment authorization answers, “Can this amount be approved and held now?” Capture answers, “Should the approved amount be collected and handed into clearing?” A void releases an uncaptured authorization, while a refund addresses a captured payment. Merchants that connect these actions to fulfillment events, expiry deadlines, settlement reports, and explicit ledger states can make their payment operations more predictable without confusing an approval with settled revenue.
Frequently Asked Questions
Is payment authorization the same as capture?
No. Authorization approves and may reserve an amount; capture requests collection of all or part of that amount and begins the clearing and settlement path. An authorization can expire, be voided, or never clear. The merchant should only treat funds as settled after the relevant settlement or funding record is available.
When should a merchant void instead of refunding a payment?
Void an outstanding authorization when the merchant will not capture it and the provider still permits a void or reversal. Use a refund after the transaction has been captured or sent into processing. Exact cutoffs and status names vary, so follow the acquirer or gateway’s documented operation and verify the resulting status.
How long does a card authorization last before capture?
There is no single universal period. The window depends on network, transaction type, card-present or card-not-present context, payment method, acquirer, and processor configuration. Save the expiration timestamp when available and confirm the applicable rule with the provider. Capture or cancel before the authorization expires rather than relying on a generic number.
