Payment Statuses: Pending, Authorized, Settled and Failed

Keep three kinds of state

Use a provider state for the processor's latest confirmed outcome, an internal state for your decision about the transaction, and a settlement state for cash movement. One database column called paid cannot explain all three. A customer-facing label can simplify the presentation, but the underlying records must retain the distinction.

Adyen's lifecycle documentation distinguishes authorization, capture and later outcomes. Its names are a concrete example, not a vocabulary that every processor shares. Build a mapping for each payment method and account configuration, including states that require operator action.

Define allowed transitions and evidence

For each transition, specify the accepted event or API response, its reference, the old state it can follow and the resulting accounting action. A browser return to a success page is not a substitute for server-side confirmation. Failed delivery of an event also does not prove a payment failed.

Events can arrive again or out of order. Preserve the event identity and processing result, then reconcile against the provider resource when necessary. Do not let an older pending event erase a later confirmed capture. Stripe documents these delivery behaviors as an API example; its business restrictions must be checked separately.

Handle unknown outcomes without inventing a result

A timeout is an observation about communication. It may leave the economic result unknown. Give that case an owner, preserve the attempted operation's key and query or reconcile before issuing a new independent request. Keeping unknown separate from failed prevents a second collection attempt from becoming a duplicate charge.

Terminal also needs a defined scope. A capture request can be finished while the overall payment remains exposed to a refund or dispute. Close the immediate processing task without discarding the relationship to later modifications. Operational dashboards should show aging unknown cases and unmatched settlements rather than force every record into success or failure.

Example: an older event arrives last

In this fictional sequence, payment P-41 is authorized at 10:01 and captured at 10:03. The capture event reaches the application first; the delayed authorization event arrives at 10:04. The stored capture reference and event history remain intact. The second event adds history but does not downgrade the internal state. A settlement batch received tomorrow is linked separately; it is not invented from the capture timestamp.