Reserve a Card Payment Now and Charge Later: What Should Your Order App Do?

If your team must confirm an order before taking the final card payment, ask whether separate authorization and capture fits the process. The app must distinguish a held amount from a captured payment, track when the hold expires and define who may finalize the amount. “Card accepted” is too vague to tell staff that money has been collected.

This guide uses Stripe's manual-capture documentation as a product example. It does not establish a legal right to hold or charge a customer's money, a universal deposit policy or the availability of this feature on every payment method. Have the applicable terms and customer explanation reviewed separately.

What decision belongs in the brief?

Start with the reason for waiting. Perhaps staff need to confirm which ordered goods can actually be supplied before finalizing the charge. Write down the event that permits capture, the person responsible and what happens if the order cannot proceed. Do not use a delayed charge as a substitute for deciding whether an order has been accepted.

Stripe's guide describes authorizing an eligible payment method now and capturing the funds later. For its documented manual setting, authorization does not itself capture the amount. An authorized PaymentIntent reaches a state called requires_capture, which is not a completed collection.

Keep the order's commercial state and the provider's payment state separately visible. Staff may confirm an order while its payment still needs capture. Conversely, a payment action should not silently mark goods packed or delivered.

A hold needs an expiry, not a permanent green tick

Stripe exposes a card authorization's expiry through the payment's capture_before field. Its guide says an uncaptured authorization that expires releases the funds and changes the payment to canceled. Do not assume every hold lasts a fixed number of days: validity depends on the applicable transaction and network conditions.

Ask the integration to show the relevant deadline and an owner for expiring holds. Define an internal reminder and a way to find orders that cannot be completed before expiry. A reminder does not extend the authorization, and an order marked confirmed does not preserve it.

If a hold expires, show that the earlier authorization no longer supports capture. Agree a supported next step with the payment provider and the person responsible for billing. Do not silently create another charge or claim that the original hold can simply be reused.

What if the final amount is smaller?

Use a hypothetical order containing an unavailable item to decide this before development. Should the remaining goods be supplied now, should staff contact the customer or should the order be canceled? The fulfillment choice and the payment operation must fit together.

Stripe documents partial capture, but also warns that most payments permit only one capture of an authorization. For those payments, taking a smaller amount does not leave a reusable pot for a second charge of the difference. Some card payments qualify for multicapture; that is a specific capability to verify, not a default promise.

Therefore “charge each parcel when it ships” needs an explicit supported design. Do not accept it merely because the developer demonstrated one partial capture. Also keep any increase above the authorized amount out of the first version unless its separate eligibility and customer flow have been reviewed.

Cancellation is not the same action as a refund

Stripe documents canceling the PaymentIntent to cancel an authorization. A canceled uncaptured hold and a refund after collection are different payment histories. Give staff actions and confirmation messages that match the current provider state.

If capture was attempted but the response was lost, reconcile the existing payment before deciding whether cancellation or refund is relevant. A local timeout does not establish that capture failed. Keep the unresolved outcome visible rather than offering an unrelated new charge.

Explain the hold to the customer before confirmation in wording approved for your payment setup. Stripe notes that some issuer statements and interfaces do not clearly distinguish authorizations from captured payments. Do not promise how a bank will display the hold or an exact release time that this documentation does not establish.

What should the developer demonstrate?

Use test payments to show a successful authorization without a paid label, capture after the agreed order event, cancellation before capture, expiry, a lower final amount and an uncertain capture response. Include the partial-delivery case if your orders use one. Check staff and customer screens against the provider record, not just against each other.

For the first release, a simpler immediate-payment workflow may be preferable if the business cannot monitor expiring authorizations. Bring the actual order timeline to a web-app project discussion. Choose separate capture because the supported workflow needs it, not because a temporary hold looks like a free extension of payment certainty.