How Capture Works
Capture is the second step in a two-step payment flow. After authorization places a hold on a cardholder's funds, the merchant must send a capture instruction to actually transfer those funds into their own account. Without capture, no money moves — the hold simply expires and the customer is never charged.
Understanding capture is essential for ecommerce merchants who want to control when they charge customers, minimize disputes, and optimize their payment operations.
Authorization Creates the Hold
The payment flow begins when a customer checks out. The merchant's payment gateway sends an authorization request to the card network and issuing bank. If approved, the bank places a hold on the cardholder's funds for the requested amount — but does not transfer any money yet.
Merchant Triggers the Capture
Once the merchant is ready to charge — typically after verifying inventory and preparing to fulfill the order — they send a capture request to their processor. This can happen immediately after authorization (auto-capture) or days later (delayed capture). The capture amount can be equal to or less than the authorized amount.
Processor Accepts the Capture
The acquiring processor validates the capture request against the original authorization: Is the authorization still active? Is the capture amount within the allowed range? If both checks pass, the processor marks the transaction for inclusion in the next settlement batch.
Transaction Enters the Settlement Batch
Most processors close a settlement batch once per day, typically at midnight. All captured transactions from that day are grouped into the batch and submitted to the card network for clearing.
Funds Are Settled to the Merchant
After clearing, the acquirer initiates a transfer to the merchant's bank account. This settlement process takes 1-3 business days depending on the processor and the merchant's agreement. The cardholder also sees the hold converted to a confirmed charge on their statement.
Why Capture Matters
Capture is a direct revenue event. A payment that has been authorized but not captured represents zero revenue — the hold will eventually expire and the customer will never be charged. For high-volume merchants, even small failures in capture logic can result in significant lost revenue.
The financial stakes are concrete. Research from the Merchant Risk Council shows that authorization-to-capture drop-off — where authorizations are obtained but captures fail or are forgotten — affects approximately 3-5% of transactions at merchants using manual capture workflows. On a $10 million monthly GMV operation, that translates to $300,000–$500,000 in monthly revenue leakage.
Beyond direct revenue, capture timing affects customer experience and chargeback exposure. Capturing too early — before fulfillment — increases dispute rates because customers may claim they were charged before receiving goods. Capturing too late risks authorization expiry, forcing re-authorization at a time when the customer's card may have been replaced or their balance depleted.
Card networks set strict hold windows: Visa allows up to 7 days for most merchants, Mastercard up to 30 days. Missing these windows is one of the most common and avoidable merchant errors in payment operations. A 2023 survey by Stripe found that 18% of mid-market merchants had experienced at least one authorization expiry incident in the prior six months due to delayed capture workflows.
Capture vs. Authorization
Authorization and capture are two distinct steps, though they're often combined into a single "sale" transaction in most consumer-facing checkouts. Separating them gives merchants more control but requires careful operational management.
| Aspect | Authorization | Capture |
|---|---|---|
| What it does | Reserves funds on the cardholder's account | Transfers funds to the merchant |
| Money moves? | No — temporary hold only | Yes — initiates settlement |
| Timing | Instant (1-3 seconds) | Immediate or up to network hold limit |
| Reversibility | Void — free, instant, no chargeback risk | Refund — fees apply, takes 3-5 days |
| Expiry | Visa: ~7 days, Mastercard: ~30 days | No expiry once captured |
| Amount flexibility | Fixed at request time | Can be less than authorized amount |
| When to use | Every payment, always first | After fulfillment is confirmed |
For digital goods — software licenses, streaming access, instant downloads — auto-capture (simultaneous auth and capture) makes sense because fulfillment is instant. For physical goods, subscriptions with trial periods, and travel bookings, delayed capture is almost always the better approach.
Types of Capture
Not all capture flows are identical. The right approach depends on your business model, fulfillment process, and customer expectations.
Full Capture
The most common type. The merchant captures the exact amount that was authorized. Used by most online retailers for standard purchases where the order amount is fixed at checkout and fulfilled promptly. Simple to implement and supported by all processors.
Partial Capture
The merchant captures less than the authorized amount, and the remaining hold is automatically released back to the cardholder. Common use cases include partial order fulfillment (one item in a two-item order is out of stock), final hotel bills lower than the pre-authorization, and downgraded service tiers. Most card networks allow a single partial capture per authorization. Some processors support multiple partial captures against one auth for merchants who ship in batches.
Delayed Capture
The merchant authorizes at checkout but waits to capture until fulfillment is confirmed — sometimes hours, sometimes days later. Hotels authorize at check-in and capture at checkout. Print-on-demand merchants authorize immediately but capture only after the product ships. Delayed capture significantly reduces disputes because the charge aligns with actual delivery. The trade-off is operational complexity: merchants must track hold expiry dates and trigger captures before the window closes.
Auto-Capture (Sale Mode)
Authorization and capture happen simultaneously in a single API call. This is the default for most payment gateway integrations and the simplest to implement. Appropriate when fulfillment is instant and the final amount is always equal to the checkout amount. Not suitable for merchants who need to adjust amounts post-authorization or who have high cancellation rates.
Best Practices
For Merchants
- Match capture timing to fulfillment. Capture when you are confident the order will ship or the service will be delivered. Capturing before fulfillment is the single biggest driver of "item not received" disputes.
- Track authorization expiry dates. Maintain a system — even a simple database field — that records when each authorization expires. Build automated alerts for holds approaching their expiry window (48-72 hours before expiry is a reasonable trigger).
- Use partial capture for split shipments. If you regularly ship orders in multiple packages, configure your system to capture only for the items in each shipment. This reduces disputes and avoids overcharging customers for goods they haven't received.
- Void instead of refund when possible. If an order is cancelled before capture, void the authorization rather than capturing and then refunding. Voids are free; refunds cost processing fees (typically $0.15-$0.30 plus interchange costs) and take days to appear on the customer's statement.
For Developers
- Use idempotency keys on capture requests. Network timeouts can cause duplicate capture attempts if your system retries without checking whether the first request succeeded. Idempotency keys prevent double-captures that trigger overpayment disputes.
- Handle partial capture responses correctly. Your integration should check whether the captured amount matches the requested amount. Some processors return a success status even on partial captures — without explicit validation, you may under-bill customers silently.
- Build expiry monitoring into your data pipeline. Store
authorization_id,authorized_at, andnetwork_hold_expiryfor every uncaptured transaction. Run a daily job to identify at-risk holds. - Test delayed capture end-to-end. Most development setups run authorize-and-capture in the same test flow. Specifically test delayed capture scenarios — particularly what happens when the capture fires after the authorization has expired in your sandbox environment.
Common Mistakes
Capturing before fulfillment confirmation. Many merchants configure auto-capture on checkout completion, before inventory is verified or the order is accepted. If the item is then found to be out of stock, the merchant must issue a refund — which costs fees, frustrates the customer, and increases chargeback risk. Best practice is to defer capture until fulfillment is confirmed.
Not accounting for authorization hold expiry. Merchants running delayed capture workflows sometimes lose track of how long their authorizations remain valid. A Visa hold on a standard merchant expires after 7 days — if capture runs on day 8, the authorization is gone. The processor may accept the request as a "force capture," but it often results in interchange downgrade (higher processing costs) and elevated chargeback exposure.
Ignoring partial capture on split fulfillment. Merchants who ship orders in multiple packages but capture the full amount upfront regularly trigger "item not received" disputes for goods still in transit. Splitting captures to match each shipment reduces this friction significantly.
Over-capturing the authorized amount. Attempting to capture more than the authorized amount — without obtaining an incremental authorization first — typically results in a processor rejection or, worse, a silent approval that leads to a dispute. Always re-authorize if the order amount increases post-checkout.
Using refunds when voids are still available. If a cancellation comes in before capture, some teams still initiate a refund out of habit. A void transaction before capture is free and immediate; refunds after capture cost money and take days. Train support and fulfillment teams to always check capture status before processing any cancellation.
Capture and Tagada
Tagada is a payment orchestration platform that sits between your checkout and your payment processors. One of its core capabilities is managing capture workflows across multiple processors without requiring changes to your existing integrations.
With Tagada, merchants can configure capture rules centrally: auto-capture for digital goods SKUs, delayed capture for physical goods with a 48-hour window, and partial capture enabled by default on all orders. These rules apply regardless of which processor handles a given transaction, so merchants with multi-processor setups don't have to duplicate configuration logic across each payment gateway.
Capture monitoring built in
Tagada tracks the expiry window for every uncaptured authorization across all your processor connections. When an authorization is at risk of expiring — by default, 48 hours before the network hold limit — Tagada surfaces an alert in the dashboard and can trigger an automatic capture or re-authorization depending on your rules. This eliminates the revenue leakage that comes from manual capture workflows, without requiring you to build expiry monitoring infrastructure yourself. Tagada is not a bank or a processor; it orchestrates across your existing processor relationships.
For merchants scaling across multiple markets, Tagada's payment orchestration layer handles the nuance that different card networks have different hold windows by geography and merchant category code. Rather than maintaining a matrix of expiry rules per processor per region, Tagada manages it centrally — and surfaces capture performance metrics alongside your authorization rate data so you can see both sides of the payment lifecycle in one view.
Merchants who have migrated from single-processor setups to Tagada's orchestration layer consistently report improved capture rates — not because the payment rails change, but because systematic expiry monitoring and multi-processor capture routing eliminate the manual gaps that cause silent revenue leakage.