Capture
Capture represents the merchant's formal confirmation that purchased goods have been shipped, services have been rendered, or digital access has been granted. By submitting a capture request, the merchant converts an active authorization hold into an enforceable financial claim, queuing the transaction for interbank clearing.
Importantly, capture does not move currency immediately. It is the final transactional stage under direct merchant control; once captured, the transaction transitions into automated interbank clearing cycles governed by card scheme timetables.
The clearing pipeline
When an application submits a capture API call, the processor aggregates the transaction into an open batch rather than transmitting it directly to the card network switch. Individual captures accumulate throughout the trading day until the processor executes a batch close at a predetermined cut-off time.
Only after the batch closes does the processor format and dispatch clearing records to the card networks. The contractual funding schedule (e.g. T+2 settlement) begins at the moment of batch close rather than at the initial customer authorization timestamp.
The batch close and daily cut-off windows
Each payment processor defines daily cut-off times, typically aligned with its central operational time zone or regional clearinghouse cycles. Any transaction captured prior to the cut-off enters the current clearing cycle; transactions captured even moments later roll over into the following day's batch.
This mechanism explains a common merchant reconciliation discrepancy: two customer orders placed twenty minutes apart on the same evening may fund across separate banking days simply because one order cleared the cut-off while the other slipped into the subsequent cycle.
While modern cloud payment gateways automate batch closure on scheduled intervals, legacy point-of-sale systems often require manual end-of-day terminal settlement. If retail store staff forget to close the terminal batch at the end of a shift, transactions remain stranded in terminal memory, delaying interbank clearing indefinitely.
Verify batch reconciliation against capture logs every business day.
- Retrieve the automated batch settlement report from the processor dashboard at the close of the trading day.
- Cross-reference the aggregate batch settlement sum against internal order management system capture totals.
- If capture totals diverge from the batch report, or if a batch report fails to generate, escalate to processor support immediately.
Partial, multi-capture, and over-capture scenarios
Real-world commerce frequently requires capturing amounts that differ from the initial authorization hold:
| Commercial scenario | Recommended operational workflow |
|---|---|
| Order fulfilled below authorized total | Execute a partial capture for the fulfilled amount; issue an authorization reversal for the uncaptured balance |
| Multi-package split shipments | Submit multiple partial captures against the single authorization if supported by processor; otherwise authorize per shipment |
| Hospitality or restaurant gratuity adjustments | Leverage the over-capture tolerance permitted under scheme rules for tipping categories; otherwise seek re-authorization |
| Incidental charges during lodging or car rental | Submit an incremental authorization prior to checkout, then capture the final aggregated total |
A partial capture claims less than the initial authorization total. In split-fulfillment workflows where items ship from different distribution centers on different days, merchants execute partial captures as individual packages dispatch. If a payment processor does not support multiple captures against a single authorization code, the merchant must re-authorize remaining amounts as secondary shipments dispatch.
An over-capture tolerance permits specific merchant categories (such as restaurants, beauty salons, and taxi services) to capture a final amount slightly higher than the initial authorization to accommodate voluntary tips without triggering authorization declines. Outside explicitly approved scheme categories, attempting to capture an amount greater than the authorized hold violates scheme rules and risks automated clearing rejection.
Operational penalties of delayed capture
Delaying capture beyond scheme authorization windows represents a pervasive source of operational loss:
- The transaction risks an interchange downgrade, shifting from prime qualification tiers to standard or penalty tiers that carry substantially higher processing fees.
- As the authorization hold approaches its expiration deadline, issuing banks release reserved funds back to the cardholder, increasing the probability of clearing rejections.
- Under updated Visa regulations, late presentment and missing authorization are evaluated under unified dispute conditions. If an issuer rejects a late clearing presentment, the merchant loses both the delivered merchandise and the sales revenue.
Force captures and the zero floor limit fee
A force capture (also called an offline capture or post-authorization entry) forces a clearing record into a batch without an accompanying electronic authorization code. This mechanism exists primarily to settle transactions approved manually via voice authorization during telecommunications outages.
Force captures carry severe operational liabilities:
- Visa assesses a zero floor limit fee on every settled transaction that cannot be matched back to a valid electronic authorization record.
- Because no electronic hold validated the card's status or available balance, force captures carry high default decline rates and offer virtually zero defense against subsequent fraud chargebacks.
Restrict force captures strictly to documented exceptional workflows.
- Document the specific operational justification within the order audit trail.
- Record the voice authorization approval code and representative identifier provided by the issuing bank.
- Flag the transaction for mandatory review on daily exception reports.
Terms introduced
- Batch: the day's captured transactions, submitted for clearing together.
- Cut-off time: the daily deadline for joining the current batch.
- Partial capture: claiming less than the authorized amount.
- Over-capture tolerance: the allowance to claim slightly more than was held.
- Force capture: a capture with no matching authorization.
- Zero floor limit fee: Visa's per-item charge for a settled transaction with no matching authorization.
How providers do it
While capture represents the same financial step across every provider—turning a temporary authorization hold into an irreversible clearing record for settlement—the underlying API mechanics and operational limits vary considerably.
The architectural design of an order management system often hinges on whether a provider permits multiple partial captures against a single authorization. If an e-commerce platform fulfills orders through split warehouse shipments, using a provider that allows only one capture per authorization forces engineering teams to initiate secondary authorizations for subsequent packages—introducing the risk of mid-fulfillment card declines.
| Provider | Multiple partial captures | Uncaptured auth expires | Status |
|---|---|---|---|
| Stripe | Generally one capture per PaymentIntent; multiple captures require customized account flags or separate authorizations | Bounded by payment method and card brand rules | unconfirmed |
| Adyen | Disabled by default; requires explicit merchant configuration and backend enablement | Configurable per merchant account, subject to scheme windows | confirmed for the setting |
| Worldpay Express | Dependent on merchant account configuration and gateway profile | Dictated by underlying card scheme parameters | unconfirmed |
| Global Payments | Varies by terminal application and acquiring platform specifications | Standard scheme expiration rules apply | unconfirmed |
| Braintree | Supported on PayPal, Venmo, and card transactions where enabled on the merchant account | Configurable within card network authorization constraints | confirmed for availability |
| Checkout.com | Fully supported using capture_type: NonFinal until final capture | Follows card scheme expiration guidelines | confirmed |
| Square | Single capture per authorization | 36 hours for in-person POS transactions, 7 days for e-commerce | confirmed |
Square's 36-hour in-person authorization window is a notable platform constraint rather than a card scheme limitation. Any operational workflow that places an authorization hold at an in-person register and defers capture until customer pickup must conclude within a day and a half. The tabs below outline the specific API endpoints and parameter payloads required for each provider.
- Stripe
- Adyen
- Worldpay Express
- Global Payments
- Braintree
- Checkout.com
- Square
What they are: a PSP. They hold the acquiring relationship, so capture semantics come from them rather than from a bank.
Their model has no separate "batch" a merchant can see. Capture submits the charge, and batching and clearing happen inside Stripe. There is no batch close to miss, which removes a whole class of failure. It removes a lever too.
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Auth-only | PaymentIntent with capture_method: manual | confirmed |
| Sale | PaymentIntent with capture_method: automatic | confirmed |
| Capture | Capture the PaymentIntent | confirmed |
| Partial capture | Capture with a lower amount_to_capture | confirmed |
| Release an uncaptured auth | Cancel the PaymentIntent | confirmed |
| Question | Answer | Status |
|---|---|---|
| How long can an auth stay uncaptured? | Bounded, and shorter than the scheme maximum for some methods | unconfirmed; check current docs per payment method |
| Multiple partial captures against one auth? | Generally one capture per PaymentIntent | unconfirmed |
| Over-capture allowed? | Limited, method-dependent | unconfirmed |
Last verified: never.
What they are: the acquirer as well as the processor, so capture behaviour is theirs end to end rather than a bank's showing through.
Capture is immediate by default. The captureDelay setting on the merchant account changes
that for every payment on the account, and a request can override it per transaction. So the
question "does this account capture on dispatch" has an answer per merchant account, set in
the Customer Area, that no one on the engineering side may have looked at.
| Standard term | Their term | Status |
|---|---|---|
| Sale | Default captureDelay, which captures immediately | confirmed |
| Auth-only | captureDelay set to manual | confirmed |
| Capture after a fixed delay | captureDelay set to a number of days | confirmed |
| Capture | POST /payments/{pspReference}/captures | confirmed |
| Release an uncaptured auth | POST /payments/{pspReference}/cancels | confirmed |
| Question | Answer | Status |
|---|---|---|
| Partial capture? | Supported. Whatever is left over is cancelled automatically | confirmed |
| Multiple partial captures against one auth? | Off by default. Adyen has to enable it on the account | confirmed |
| How long can an auth stay uncaptured? | Varies by payment method | unconfirmed; the Customer Area reports an expired authorisation after the fact, which is too late to plan against |
| Is there a batch cut-off to miss? | No batch the merchant operates. Clearing happens inside Adyen | unconfirmed |
The second row is the one to check before designing split shipments. If multiple partial captures are not switched on, the first capture ends the authorization and the rest of the order needs a fresh one, with the decline exposure the core page describes.
Last verified: 2026-09-09 against Adyen's public capture documentation.
What they are: the gateway and processing platform. Express is an XML interface built around named transaction types rather than a resource you modify, so the core page's language of capturing an authorization is a different shape here.
| Standard term | Their term | Status |
|---|---|---|
| Auth-only | CreditCardAuthorization, a pre-auth requiring an amount above zero | confirmed |
| Capture an earlier auth | A completion, citing the original TransactionID | confirmed |
| Stored card token | PaymentAccountID, usable in place of card data | confirmed |
| Hosted checkout session | TransactionSetupID, which expires ten minutes after it is created | confirmed |
| Question | Answer | Status |
|---|---|---|
| Partial capture? | unconfirmed; check the interface specification for the version the integration targets | |
| Multiple completions against one auth? | unconfirmed | |
| Who closes the batch, and at what cut-off? | unconfirmed; card-present estates on Express often close at the terminal, which is the failure the core page describes | |
| How long can an auth stay uncaptured? | unconfirmed |
Where to look
Worldpay publishes the Express interface specification as a versioned PDF, and it is the authority for every field name above. Check which version the integration targets before relying on a description of one.
Last verified: 2026-09-09 against Worldpay's published Express interface specification.
What they are: acquirer and processor. Which of their platforms an integration runs on decides what capture is called, so confirm that first.
| Standard term | Their term | Status |
|---|---|---|
| Capture | Capture, against the id returned by the authorization | confirmed for GP API |
| Refund | Refund on GP API, rebate on the older GP-ECOM platform | unconfirmed |
| Question | Answer | Status |
|---|---|---|
| Over-capture tolerance? | GP API allows capture up to 115% of the authorized amount | confirmed |
| What happens if the amount is omitted? | The full authorized amount is captured | confirmed |
| Partial capture, and more than one? | unconfirmed; ask per platform | |
| Who closes the batch, and at what cut-off? | unconfirmed; terminal estates on Portico may settle at the till | |
| How long can an auth stay uncaptured? | unconfirmed |
That 115% is a platform rule, and it is not the same thing as the network's over-capture tolerance for tips and fuel. Staying inside one does not put you inside the other.
Last verified: 2026-09-09 against Global Payments' developer portal.
What they are: the gateway and PSP. Capture is a Braintree operation, and the batch behind it belongs to whichever acquirer is processing the volume.
| Standard term | Their term | Status |
|---|---|---|
| Sale | Transaction sale with submitForSettlement set at creation | confirmed |
| Auth-only | Transaction sale without it, leaving the transaction authorized | confirmed |
| Capture | Submit for settlement | confirmed |
| Partial capture, more than once | Submit for partial settlement, which creates a child transaction per capture | confirmed |
| Release an uncaptured auth | Void | confirmed |
| Question | Answer | Status |
|---|---|---|
| Multiple partial settlements? | Available for PayPal and Venmo, and for card transactions only where the merchant has been enabled for it | confirmed |
| What does the parent transaction look like meanwhile? | It sits in settlement pending until every child settles or the authorization expires | confirmed |
| When does the batch close? | unconfirmed; ask for the cut-off in the merchant's timezone | |
| How long can an auth stay uncaptured? | unconfirmed; card brand and merchant account both affect it |
Child transactions are the thing to design reporting around. One order that ships in three parts produces one authorization and three settled transactions with their own ids, so a reconciliation keyed on the original transaction id finds nothing settled against it.
Last verified: 2026-09-09 against Braintree's public developer documentation.
What they are: acquirer and processor together, so capture is settled with one party.
| Standard term | Their term | Status |
|---|---|---|
| Sale | POST /payments with capture left at its default | confirmed |
| Auth-only | POST /payments with capture: false | confirmed |
| Capture | POST /payments/{id}/captures | confirmed |
| Release an uncaptured auth | POST /payments/{id}/voids | confirmed |
| Question | Answer | Status |
|---|---|---|
| Partial capture? | Yes. Any capture below the authorized amount is a partial capture | confirmed |
| Multiple partial captures? | Yes, with capture_type: NonFinal on all but the last. The default, Final, voids whatever is left | confirmed |
| Which card brands support it? | American Express, Discover, Mastercard and Visa | confirmed |
| Is there a ceiling on partial actions? | 150 per payment, counting partial captures and partial refunds together | confirmed |
| How long can an auth stay uncaptured? | unconfirmed |
The capture_type default is a trap for split shipments. Send the first shipment's capture
without setting NonFinal and the balance of the authorization is voided, so the second
shipment needs a new authorization and can be declined.
Last verified: 2026-09-09 against Checkout.com's public documentation.
What they are: a payment facilitator, so both the capture semantics and the deadline behind them are Square's own.
| Standard term | Their term | Status |
|---|---|---|
| Sale | CreatePayment with autocomplete left true | confirmed |
| Auth-only | CreatePayment with autocomplete: false | confirmed |
| Capture | CompletePayment | confirmed |
| Release an uncaptured auth | CancelPayment | confirmed |
| Question | Answer | Status |
|---|---|---|
| How long can an auth stay uncaptured? | 36 hours for a card-present payment, 7 days for card-not-present | confirmed |
| What happens at the deadline? | Square cancels the payment. Setting delay_action to COMPLETE makes it capture instead | confirmed |
| Partial capture? | unconfirmed | |
| Multiple partial captures? | unconfirmed |
The 36-hour window is much shorter than the scheme maximum, and it is a Square rule rather
than a network one. Any workflow that authorizes at the till and captures when the goods are
collected has to fit inside a day and a half, or set delay_action and accept that the charge
completes whether or not anyone confirmed the collection.
Last verified: 2026-09-09 against Square's public developer documentation.