Manage authorization capture as a deadline-bound decision

A monetary hold is not an unlimited payment promise

Stripe separates authorization from capture for eligible payment methods, allowing an amount to be held before funds are captured later.[3] If the authorization expires before capture, Stripe releases the held funds and the payment changes to canceled.[3] Editorial recommendation: represent an authorization as a temporary opportunity to collect an approved amount, not as a completed collection. Assign a person or service responsibility for deciding whether to capture or cancel while that opportunity remains valid. This article concerns Stripe's documented authorization flow, not inventory reservation, stablecoin settlement, or an asserted feature of another payment product.

Use the actual deadline rather than a universal duration

For card payments, Stripe documents the Charge attribute payment_method_details.card.capture_before as the authorization expiry timestamp.[3] Its authorization windows vary by card network, transaction type, and other documented conditions; seven days is not a universal promise.[3] Editorial recommendation: retain the relevant Charge and its deadline with the business decision awaiting capture. Calculate an internal decision point before that deadline, leaving an operational margin appropriate to the integration rather than presenting an invented standard buffer as a Stripe requirement. If the expected deadline is absent or cannot be interpreted, route the payment for investigation instead of substituting a remembered duration.

Check eligibility and readiness independently

Stripe's manual capture is limited to supported payment methods; its documentation explicitly contrasts supported methods with methods such as ACH and iDEAL that do not support separate authorization and capture.[3] With manual capture, an authorized PaymentIntent moves to requires_capture, and amount_capturable identifies the amount available for capture.[3] Editorial recommendation: check method eligibility when designing the flow, then check actual payment readiness before making a capture decision. An order marked ready by an internal team does not establish that its PaymentIntent is ready. When using Checkout, Stripe instructs integrations to capture using the PaymentIntent identifier returned on the Checkout Session.[3]

Resolve the business decision before the window closes

Editorial recommendation: maintain a work queue that distinguishes payments awaiting a fulfillment decision, payments approved for capture, and payments that should be canceled. Prioritize unresolved decisions by their actual authorization deadline rather than order creation time alone. Illustrative example, not a test result: a merchant authorizes a card while confirming service availability, then captures only after the service can be supplied and while the authorization remains valid. If availability cannot be confirmed in time, escalate to the responsible operator instead of assuming the monetary hold can be extended. Stripe documents canceling the corresponding PaymentIntent as the way to cancel an authorization.[3]

Treat partial capture as a final allocation unless eligible otherwise

Stripe captures the full authorized amount by default; amount_to_capture can specify a smaller amount, and partial capture automatically releases the remainder.[3] Most payments support only one capture, although some eligible card payments support multicapture; a normal partial capture therefore does not leave an ordinary second opportunity to collect the difference.[3] Editorial recommendation: resolve the amount and fulfillment scope before submitting a partial capture. For a split delivery, do not design the second shipment around an assumed reusable balance. Route any requirement for multiple captures into a separately verified eligibility review rather than quietly applying an exception to every authorization.

Specify paths for expiry, uncertainty, and changed scope

Editorial recommendation: if the authorization has expired, stop treating the old hold as collectible and decide whether a new customer payment flow is appropriate. If a capture request has an uncertain outcome, inspect the current payment state before choosing another action; do not let an internal timeout decide whether money was collected. If the approved order amount changes, obtain an explicit amount decision rather than copying the original authorization amount automatically. Stripe notes that some issuers' statements and payment interfaces do not clearly distinguish authorizations from captured payments.[3] Explain that distinction to customers without promising an unsupported release-display time or representing the hold as a settled charge.

Validate the deadline workflow with a proposed checklist

Editorial recommendation—proposed test checklist, not executed results: exercise an eligible manual-capture flow through requires_capture; verify that the stored deadline comes from the relevant card Charge; confirm the selected amount against amount_capturable; and check the application's behavior when the deadline is missing, approaching, or already passed. Include a partial capture and confirm the released remainder is not scheduled for an ordinary second capture, consistent with Stripe's documented default behavior.[3] Also exercise cancellation, unsupported-method handling, and a capture request whose response is interrupted. Record actual provider states and application decisions during execution. This checklist supplies acceptance criteria, not a claim of successful tests or a guarantee that every payment method behaves like a card.

Sources and dates

Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.

Stripe: Separate authorization and capture [3] ↗
Source date: Not stated · Verified: 2026-09-20