Guides

Delayed capture, explained: authorize now, capture later

How delayed capture works: the gap between authorizing a card and capturing the money, how long an authorization hold lasts, and when to use it over escrow.

A blueprint schematic in mint line-work on deep violet: a card marked AUTHORIZATION with a dashed box around the reserved amount, an arrow crossing a ruled seven-day scale labelled HOLD OPEN, and a second card marked SETTLEMENT holding a coin, with violet dimension lines naming the two steps.

Most card payments happen in a single motion: the customer taps, the money moves, done. But there’s a whole class of transactions where you want to check the card is good now and only take the money later — once the order is confirmed, the goods have shipped, or the final amount is settled. That’s delayed capture: authorize now, capture later. Two steps where a normal sale has one.

It’s the mechanism behind hotel deposits, pre-orders, equipment rentals, and every “we’ll only charge you when it ships” flow. And it rests on one fact that trips people up: a card authorization is not money you’re holding. It’s a promise with an expiry date.

How authorization and capture actually work

A card “sale” is really two operations the single-step version fuses together.

Authorization asks the customer’s bank a question: does this card exist, and are the funds there? If yes, the issuing bank returns an approval code and places a hold on that amount — the customer’s available balance drops, but no money has actually moved to you. Nothing has settled. You’ve reserved the funds, not received them.

Capture is the second step: you tell the processor to actually pull the authorized amount and settle it into your account. Capture is when the money moves. Only captured transactions get funded; an authorization that’s never captured funds nothing.

In a normal one-tap purchase these fire back-to-back, so you never see the seam. Delayed capture is just deciding to leave a gap between them — authorize at checkout, capture when you’re ready. In that gap you can confirm stock, verify the buyer, wait for a rental to be returned, or settle a final bill that wasn’t known up front.

The honest read: authorization is a soft reservation, capture is the real charge. Treat the two as different events with different guarantees, because they are.

When to use delayed capture

Delayed capture earns its keep whenever the charge shouldn’t be final at the moment of checkout.

  • Deposits and holds. A rental, a booking, a high-trust service — authorize a deposit to prove the card is real and the funds exist, then capture only if you actually need to (damage, a no-show, the final total). Most of the time you release it without ever charging.
  • Pre-orders and made-to-order. Card networks generally frown on charging for goods you haven’t shipped. Authorize at purchase, capture when the item leaves the warehouse — so the money moves against a real fulfilment, not a promise.
  • Marketplaces. A buyer pays once, but the goods come from a seller who hasn’t confirmed or shipped yet. Authorizing up front verifies the buyer’s funds; capturing on seller confirmation means you’re not sitting on money for an order that might never fulfil. (Once captured, that one payment often has to split across several recipients — a separate problem from the capture timing.)
  • Verify before you fulfil. Sometimes the point isn’t the money at all — it’s confirming the card is valid and funded before you hand over access, ship, or begin work. Authorize, run your checks, then capture.

The through-line: capture is the commitment. Delaying it lets the money follow the real-world event instead of racing ahead of it.

Delayed capture vs escrow vs manual payout

It’s tempting to reach for delayed capture whenever you want to “hold funds.” Usually that’s the wrong tool — because of the expiry.

Think of it as a spectrum of hold models:

  • Delayed capture holds an authorization — a temporary reservation on the customer’s card that the issuer releases on its own timetable. It’s short: typically around 7 days for standard card-not-present transactions, and while some issuers and networks allow longer for travel, hospitality, and rental (often up to roughly 30 days), you don’t get to choose the number — the issuer and network do. Miss the window and the hold drops, the funds free up, and you’re re-authorizing. So it’s a verify-then-charge window, not a vault.
  • Escrow holds settled money. You’ve captured the funds and a neutral party parks them until the deal’s conditions are met — which can be weeks. Escrow exists precisely because a card authorization can’t survive that long.
  • Manual payout captures the money into your own balance and releases it deliberately, on your rules — pay the seller on delivery, on approval, on a schedule. You’re holding real funds and deciding when they leave.

The rule of thumb: if you need to hold value for longer than a few days, don’t stretch an authorization to do it — capture the money and hold it on purpose. Delayed capture answers “should I charge yet?” It does not answer “can I sit on this for a month?” Reauthorizing an expired hold to fake long-term custody is fragile and, on some networks, against the rules.

Where Fynex fits

Fynex isn’t your card processor, and it doesn’t run the authorization itself — that lives with the acquirer and the networks. Fynex is the layer that thinks about what happens around the money once it’s real: when a payment is captured, what it owes, and where it should go.

That’s the honest boundary. Delayed capture is a card-rail mechanic; Fynex sits one level up, at finance operations. Once funds are captured, Fynex holds client money safeguarded at an FCA-authorised EMI, applies your split rules as lines, and routes each payout over the genuinely cheapest compliant rail — while reconciling every leg back to the original transaction into Xero or QuickBooks, with auto-invoicing and agentic collections handling the paperwork around it. And because it’s an AI-native finance layer rather than a bank, anything that actually moves money — every capture-to-payout decision — waits for a human to approve it. As a PCI DSS Level 1, Merchant-of-Record layer, it’s built to sit in the flow without becoming the thing you have to babysit.

Accounts hold money. Rails move it. Fynex is the layer that thinks — so the moment a delayed capture becomes a real, settled payment, the reconciliation, the split, and the payout are already worked out.

The takeaway

Delayed capture is a small idea with a sharp edge: authorization and capture are two events, and the gap between them is yours to use — to verify, to confirm, to wait for the thing that makes the charge fair. Use it for deposits, pre-orders, rentals, and marketplace flows where the money should follow fulfilment.

Just respect the clock. An authorization is a short-lived hold, not a vault — typically days, on the issuer’s terms, not yours. If you need to hold value longer, capture it and hold it deliberately. And once it’s captured, that’s where the finance-ops work — the split, the payout, the reconciliation — actually begins. (For the payout side of that, see how push-to-card payouts work.)

FAQ

Frequently asked questions

Delayed capture is splitting a card payment into two steps: you authorize the card now — checking the funds exist and placing a hold — and capture the money later, once you've confirmed the order, shipped the goods, or settled the final amount. The single-step 'sale' does both at once; delayed capture holds the authorization open in between. It's how deposits, pre-orders, and 'verify before you charge' flows work without taking the money up front.
Not long, and not indefinitely — that's the key constraint. An authorization hold typically expires within about 7 days for standard card-not-present transactions, though some issuers and networks allow longer for travel, hospitality, and rental (often up to ~30 days). The exact window is set by the issuer and card network, so treat any number as 'typically', not a guarantee. If you don't capture before it expires, the hold drops off, the customer's funds are released, and you have to re-authorize to charge.
No. A card authorization isn't money you're holding — it's a temporary hold on the customer's funds that expires in days. Escrow actually parks settled money with a neutral third party for as long as the deal needs, which could be weeks. Delayed capture is a short verify-then-charge window; escrow is a long-term custody arrangement. If you need to hold funds for longer than an authorization survives, you capture the money and hold it deliberately — you don't lean on the auth.
That's normal and expected. You can usually capture the full authorized amount or less — a hotel authorizes an estimate and captures the actual bill at checkout; a retailer authorizes a basket and captures only the items that shipped. Capturing more than you authorized is where it gets restricted, and often means a fresh authorization. The releases and partial captures depend on the processor and network rules, so confirm the exact behaviour with whoever runs your card processing.
Book a demo