Authorization, capture, void, and refund are different state changes

Payment interfaces often compress several operations into “charge” and “refund.” The underlying lifecycle is more useful. Authorization asks whether an amount may be reserved or approved. Capture submits an authorized amount for financial completion. A void or cancellation releases an uncaptured authorization. A refund returns value after capture. Choosing the wrong operation can prolong a customer’s hold, create a second movement, or leave the order and provider out of sync.

Model authorization as permission, not revenue

An approved authorization is not proof of settlement or a bank payout. Record the provider’s payment and authorization references, approved amount, currency, time, expiry information if supplied, and whether capture is automatic or manual. Do not mark revenue, ship goods, or grant irreversible access solely because the API request returned 200; use the business’s stated fulfillment rule and the provider’s authoritative state.

Adyen’s provider documentation says manual capture reserves funds at authorization and later submits a capture, while only some payment methods support separate or partial capture. It also says its capture request is asynchronous and can later produce a failure event (Adyen capture). That exact status model is Adyen-specific, but the operational lesson is general: “request accepted” and “financial outcome confirmed” deserve separate fields.

The customer-facing pending payment guide explains why a released hold can remain visible according to issuer presentation. Support should not promise that a cancellation will disappear immediately.

Capture against fulfillment

With automatic capture, authorization and capture may be close together. With manual capture, define the event that permits it: shipment handed to carrier, service delivered, pickup completed, or another documented milestone. Capture only the amount supported by fulfillment. If split shipments require multiple partial captures, confirm that the payment method, provider account, and integration support them; do not infer this from one card test.

Store the capture request reference separately from the authorization reference. Handle a capture failure as a distinct exception rather than changing the original authorization record. The order system should show what remains authorized, what was captured, and what expired or was canceled.

Cancel before capture; refund after capture

If an item is unavailable while the payment remains uncaptured, cancel or void the authorization through the provider’s supported operation. Stripe’s PaymentIntent API, for example, only permits cancellation in specified states and says cancellation of a requires_capture intent releases its remaining capturable amount (Stripe). That is Stripe behavior, not a universal status list.

After capture, use a referenced refund tied to the original transaction. Adyen’s current documentation says a refund requires a captured payment, can be partial for supported methods, and reports results asynchronously; it also documents later failed or reversed refund states (Adyen refund). Keep the refund request, provider reference, amount, reason, and later outcome distinct. A successful submission is not permission to tell the customer the credit has posted.

When the local system cannot tell whether capture occurred, query the provider before choosing. Some providers expose a reversal operation that selects cancellation or refund based on state, but its restrictions are provider-specific. Never fire both a cancel and refund “to be safe.”

A compact state ledger

For each order, preserve append-only events and calculate the current view:

• authorized amount and remaining authorization
• captured amount and capture references
• canceled or expired amount
• refund requested, refund confirmed, refund failed or reversed
• disputed amount, kept separate from merchant refunds
• provider and merchant timestamps

Use idempotency keys for every modifying request and process signed webhooks idempotently. The retry guide and webhook guide cover those controls. Reconcile lifecycle totals to provider balance activity and payouts; an order state alone does not prove cash settlement.

Test automatic capture, manual full capture, permitted partial capture, out-of-stock cancellation, full and partial refund, expired authorization, capture failure, refund failure, and duplicate request in the provider’s test environment. The exact scenarios supported depend on payment method and contract. This guide describes the test plan; it does not claim those tests were run here.

Sources

• Adyen, Capture an authorized payment — provider-specific
• Adyen, Refund a payment — provider-specific
• Stripe, Cancel a PaymentIntent — provider-specific