Card authorization vs capture is the difference between reserving money and starting the transfer of that money. Authorization checks the payment and places a hold on available funds. Capture tells the payment system to collect the authorized amount. On many purchases the two steps happen almost together, but hotels, rentals, marketplaces and merchants that ship later may separate them.
That gap explains why a card balance can fall before a transaction is complete, why a pending charge can disappear, and why a merchant can still fail to receive funds after an approval.
Authorization is a reservation, not settlement
When a card payment is authorized, the issuer approves the request and reserves funds or credit for it. Adyen’s payments lifecycle documentation describes authorization as the stage after payment details and risk checks are accepted. The money is reserved for a limited validity period in which the merchant can capture or cancel the payment.
The customer may see a pending transaction immediately. That does not mean the merchant has received a payout. It means the issuer has reduced what the customer can spend while the authorization remains open.
A useful mental model is a labeled envelope. Authorization puts the amount in the envelope for this purchase. Capture asks the payment chain to take the amount from that envelope. Settlement and payout happen later.
If you want the wider route from card tap to merchant account, see Where Your Money Goes After You Tap to Pay.
Capture turns the hold into a collection request
Capture is the merchant’s instruction to collect some or all of an authorized amount. Automatic capture is the default for many payment methods, so a normal checkout can make authorization and capture appear to be one event.
Separate capture changes the sequence. Stripe’s manual-capture documentation says a payment can reserve funds first and be captured later when the payment method supports it. Adyen’s capture guide gives order fulfillment as the typical example: authorize at checkout, capture when the item ships, or cancel if it cannot be supplied.
Capture is still not the same as payout. A processor can accept the capture request, send it to the scheme and later receive a failure. Adyen documents separate capture and capture-failed events for that reason. A merchant system should therefore treat “capture submitted,” “capture succeeded” and “paid out” as different states.
Why merchants delay capture
Delayed capture is useful when the final amount or fulfillment is uncertain:
- A hotel may authorize before a stay and capture the final bill at checkout.
- A rental company may authorize an estimated amount and adjust it under card-network rules.
- An online store can authorize when an order is accepted and capture only when stock ships.
- A marketplace may wait for a concrete fulfillment milestone.
This does not give a merchant an unlimited claim on the customer’s balance. Every authorization has an expiry. Stripe says the exact limit depends on payment method, card network, channel and transaction type, and exposes a capture_before value for eligible card payments. Its documentation says online card holds are typically valid for seven days, while some eligible extended authorizations can last longer. The correct implementation reads the transaction’s actual deadline rather than hard-coding a general number.
Adyen also notes that validity depends on the payment method and scheme. A generic “holds always last seven days” rule is therefore unsafe.
What happens when the hold expires
If the merchant does not capture in time, the authorization can expire and the issuer releases the reserved amount. The customer then sees the money return to the available balance or the pending item disappear.
Expiry is not the same as a refund. A refund reverses money after a captured payment. An expired or canceled authorization releases a reservation before collection is completed.
There is another complication: an issuer’s display is not a complete merchant ledger. Some payment systems can process a late or unmatched capture under scheme rules. Customer support should avoid promising that a released hold makes a later debit impossible. The merchant’s processor record, network rules and issuer record all matter.
Partial capture and the unused amount
A merchant may capture less than the amount authorized when the payment method and processor support it. For example, an order authorized for €80 might ship with only €62 of goods.
What happens to the remaining €18 is product-specific:
- Stripe says a partial capture normally releases the remainder, and most payments allow only one capture unless multicapture is available.
- Adyen supports single and, when enabled and supported, multiple partial captures. Its guide explains that an unclaimed balance can be canceled or remain available for another capture depending on configuration and scheme support.
An integration must not assume that every authorization can be split repeatedly. Check the processor’s capabilities for the exact payment method, country and account.
A payment state model that avoids expensive mistakes
Do not store a single paid=true flag. At minimum, keep the provider’s payment ID, your order ID, authorized amount, capturable amount, captured amount, currency, authorization deadline and the latest confirmed status.
A practical flow is:
- Create the payment once and keep its provider identifier.
- Confirm authorization from the API response and signed webhook.
- Store the actual capture deadline.
- Capture only after the business milestone occurs.
- Handle capture success and capture failure separately.
- Reconcile the provider record before retrying an uncertain operation.
- Mark an order paid only from the state your fulfillment policy requires.
Use webhooks with a reconciliation path, because a timeout can hide whether a capture request reached the processor. For mutation retries, idempotency keys help prevent a network retry from creating a second operation.
What customers should understand
A pending card transaction usually represents an authorization hold. It reduces available funds, but it can still expire, be canceled, be adjusted or be captured for a supported amount. A completed transaction indicates a later stage, but issuer labels vary.
If a pending amount lasts longer than expected, the customer needs the merchant name, amount, date and any reference the merchant can provide. The merchant should check its processor’s authorization and capture records before telling the customer to wait or pay again.
