Partial capture is a payment settlement method that allows merchants to collect funds for an amount lower than the original authorization hold placed on a customer's card. Rather than voiding the authorization entirely or settling the full pre-authorized amount, the merchant submits a capture request for only what was actually fulfilled. The card network then releases the uncaptured remainder back to the cardholder automatically.
This capability is especially important for industries where the final order value is uncertain at checkout — such as ecommerce businesses that may ship partial orders, rental platforms with variable usage fees, or B2B merchants dealing with last-minute order changes.
How Partial Capture Works
Partial capture follows the standard two-step authorization-and-capture flow but diverges at the settlement stage. Understanding each step is essential before implementing it in a production environment.
Authorization Hold Placed
At checkout, the customer's card is authorized for the full expected order amount. The issuing bank places a hold, reducing the cardholder's available balance without moving any funds. No money changes hands at this stage.
Order Fulfillment Verified
Before settling, the merchant determines the actual fulfilled value. This could be due to an out-of-stock item, a last-minute quantity change, a cancellation of part of the order, or variable usage measured after service delivery.
Partial Capture Submitted
The merchant (or payment system) sends a capture request to the gateway with an amount less than the original authorization. For example: $200 authorized, $140 captured after one item ships out of two.
Remaining Hold Released
The card network instructs the issuing bank to release the uncaptured balance — in this case $60 — back to the cardholder's available credit or bank balance. The timeline for availability varies by issuer but is typically one to five business days.
Settlement and Funding
The captured amount ($140) moves through the standard settlement cycle. The merchant is funded by the acquirer, minus processing fees, on the normal payout schedule. The authorization is now closed.
Why Partial Capture Matters
Partial capture is not a niche edge case — it addresses real revenue and customer experience problems at scale. Getting it wrong has measurable financial consequences for merchants.
According to Mastercard's merchant best practices guidelines, merchants who consistently capture more than the authorized amount (over-capture) face higher chargeback rates and potential account termination. Conversely, merchants who routinely authorize for large amounts and then capture nothing — effectively using authorizations as informal holds — erode customer trust because funds appear frozen on the cardholder's statement for days.
Research from Stripe's payments data (2023) suggests that ecommerce merchants with partial-fulfillment scenarios — split shipments, backorders, substitutions — see a measurable lift in repeat purchase rates when they implement partial capture correctly, because customers see funds released promptly rather than held for the full authorization period. Visa's core rules also explicitly allow partial capture across all merchant categories, meaning there is no network-level reason not to use it when the situation calls for it.
Authorization Window
Visa and Mastercard standard card-not-present authorization holds expire after 7 days for most merchant categories. Travel and lodging merchants may hold up to 30 days. Always capture within the window or risk an expired authorization and a failed settlement.
Partial Capture vs. Full Capture
Choosing between partial and full capture depends on fulfillment certainty. The table below compares the two approaches across key dimensions.
| Dimension | Partial Capture | Full Capture |
|---|---|---|
| Amount settled | Less than authorized | Equal to authorized |
| Cardholder impact | Unused hold released promptly | Full hold charged as expected |
| Use case | Variable fulfillment, partial orders | Fixed-price, fully fulfilled orders |
| Complexity | Requires gateway support, logic in OMS | Standard behavior, no extra configuration |
| Chargeback risk | Lower when done correctly | Higher if customer disputes unfulfilled items |
| Refund scope | Capped at captured amount | Full captured amount refundable |
| Network support | Visa, Mastercard, Amex, Discover | Universal |
For merchants operating with predictable, single-shipment orders, full capture is simpler and carries no additional implementation risk. Partial capture becomes the better choice whenever the final order value is not locked at the time of payment.
Types of Partial Capture
Partial capture appears across several distinct fulfillment and business model scenarios, each with its own operational patterns.
Partial-shipment capture is the most common variant in ecommerce. A customer orders three items; only two are in stock. The merchant captures the cost of the two fulfilled items and releases the remainder. The third item may trigger a new authorization if it ships later.
Variable-usage capture is prevalent in platforms where consumption is metered after the fact — car rentals, hotel incidentals, cloud services billed by usage. The merchant authorizes an estimated maximum and captures only what was actually consumed at checkout.
Discount or promotion adjustment capture occurs when a post-authorization discount (loyalty points, coupon validation, price-match) reduces the final price below the authorized amount. Rather than voiding and re-authorizing, the merchant captures the discounted amount directly.
B2B order amendment capture applies when business buyers modify purchase orders after payment authorization but before fulfillment — a common scenario in wholesale and procurement flows where order quantities shift up to the moment of dispatch.
Best Practices
For Merchants
Communicate proactively with customers when a partial capture will occur. If a customer sees a $200 hold and then a $140 charge, they will often contact support confused about the remaining $60. A simple order confirmation email explaining the hold release eliminates the majority of these inquiries.
Align your authorization window with your fulfillment lead times. If your average fulfillment takes five days but you only have a seven-day authorization window, any processing delays risk an expired authorization. Either shorten fulfillment SLAs or use incremental authorization where your processor supports it.
Audit your capture logic regularly. Systems that always capture the full authorized amount — even when line items are cancelled — expose the merchant to chargebacks under "item not received" reason codes, which are among the most difficult to defend.
For Developers
Confirm partial capture support at the gateway level before building the feature. Send a test capture request for a lower amount than the authorization and verify the gateway response code confirms partial acceptance rather than returning an error or silently rounding up.
Store both the authorized amount and the captured amount in your order management system. Treating them as the same value is a common source of reconciliation errors, especially when partial captures combine with split-payments or multi-party payouts.
Implement idempotency keys on all capture requests. If a capture call times out and is retried, a system without idempotency protection may attempt to capture twice, resulting in a double charge or an unexpected decline.
Handle the edge case where the requested capture amount exceeds the authorized amount. Some gateways will reject the request outright; others will cap at the authorization and return a warning. Your error handling must account for both behaviors.
Common Mistakes
Capturing after authorization expiry. Attempting to capture against an expired authorization may result in a soft decline, a forced capture that bypasses the hold, or a force-capture that increases chargeback exposure. Always track authorization expiry dates in your system.
Conflating void and partial capture. A void cancels the authorization entirely; a partial capture settles a portion and releases the rest. These are distinct operations. Using a void when you intended a partial capture means no funds are collected, and the customer may need to be re-charged through a new payment flow.
Ignoring the cardholder experience of dual holds. Some acquirers temporarily show both the original hold and the capture amount on the cardholder's statement before the hold releases, making it appear the customer was double-charged. Proactive communication and a clear refund/release policy reduces inbound support volume significantly.
Omitting partial capture from reconciliation workflows. Finance teams accustomed to full-capture flows may not account for the discrepancy between authorized and settled amounts in daily reconciliation. This creates phantom variances in treasury reporting unless the OMS explicitly tracks both figures.
Assuming multi-capture is always available. Some merchants attempt to capture in two or more increments against a single authorization — for example, once per shipment in a split-fulfillment scenario. Most processors only allow one capture per authorization. This behavior requires explicit multi-capture support from the acquirer and should never be assumed.
Partial Capture and Tagada
Tagada's payment orchestration layer handles partial capture logic centrally, so merchants do not need to implement capture amount calculations separately for each processor or gateway in their stack.
Orchestration-layer partial capture
When routing transactions through Tagada, partial capture amounts are passed in the settlement instruction alongside the original authorization reference. Tagada normalizes the request format across acquirers, handles gateway-specific edge cases (such as processors that reject sub-cent capture amounts), and logs both the authorized and captured amounts in the unified transaction record for reconciliation. This eliminates the need to maintain per-processor capture logic in your own codebase.
For merchants processing across multiple acquirers — common in cross-border ecommerce — Tagada's orchestration ensures that the same partial capture logic applies consistently regardless of which acquirer handled the original authorization. This is particularly valuable when different processors in the routing table have different behaviors for under-capture scenarios, such as varying minimum capture percentages or differing timeout handling for expired holds.