Why is pending not a payment failure?

Pending means the payment has not reached a terminal outcome. Some other system or person still has to act, such as a bank approving a transfer, a customer completing authentication, a fraud check finishing, or a processor sending a later event. Treat it as a normal waiting state, not as proof that the payment broke.

When is it safe to fulfil an order?

It depends on the payment method, your risk tolerance, and what state guarantees funds. For card payments, authorisation may be enough to reserve goods, while capture or settlement may be required before delivery. For slower methods, pending can last longer, so fulfilment rules should be tied to explicit state transitions, not the initial API response.

Can a failed payment be retried?

Sometimes. A failure caused by invalid details, a permanent decline, or a cancelled mandate should usually stop. A failure caused by temporary network trouble, insufficient funds, expired authentication, or a customer needing to choose another method may be recoverable. Your system should store the reason and decide whether to retry, ask for action, or abandon the attempt.

Every State a Payment Can Be In

Every state a payment can be in is the lifecycle model for a single payment attempt, from creation through submission, waiting, approval, settlement, failure, cancellation, refund, dispute, or retry. It treats payment processing as a state machine driven by customer actions, application calls, processor decisions, and banking network events.

The problem is that a payment is not the same thing as a successful charge. Your application may create a payment record before any money can move, then hand it to a processor, then wait while card networks, banks, fraud systems, authentication flows, or settlement systems do their work. If you collapse all of this into paid or not paid, you will fulfil orders too early, show misleading errors, or lose track of what actually happened.

Concretely, model one payment as a state machine. It might start as created, become submitted when your code sends it to the processor, move to pending while an external actor decides, then become authorised, captured, settled, failed, cancelled, refunded, disputed, or retried. Transitions are caused by different parties: your code captures, the customer authenticates, the processor declines, the bank settles, and webhooks often tell you about changes after the original API call has returned.

The trade-off is more application complexity. You need durable payment records, idempotent handlers, clear transition rules, and UI copy for states that are neither success nor failure. Pending is commonly misunderstood as an error, but it usually means the result is not known yet. Failed is also not always final. Whether to retry depends on the failure reason, the payment method, customer intent, and processor guidance.

Engineers meet this in checkout flows, subscription billing, order fulfilment, ledger reconciliation, support tooling, and webhook consumers. The key design question is what your system is allowed to do in each state. For example, you may reserve inventory after authorisation, ship only after capture or settlement, ask for another payment method after a recoverable failure, and stop after a permanent decline or cancellation.

Go deeper

PaymentsEvery State a Payment Can Be InDraw the state machine a single payment moves through, and say why pending is not a failure and why failed is not always final.Open the lesson

Common questions

Why is pending not a payment failure?: Pending means the payment has not reached a terminal outcome. Some other system or person still has to act, such as a bank approving a transfer, a customer completing authentication, a fraud check finishing, or a processor sending a later event. Treat it as a normal waiting state, not as proof that the payment broke.
When is it safe to fulfil an order?: It depends on the payment method, your risk tolerance, and what state guarantees funds. For card payments, authorisation may be enough to reserve goods, while capture or settlement may be required before delivery. For slower methods, pending can last longer, so fulfilment rules should be tied to explicit state transitions, not the initial API response.
Can a failed payment be retried?: Sometimes. A failure caused by invalid details, a permanent decline, or a cancelled mandate should usually stop. A failure caused by temporary network trouble, insufficient funds, expired authentication, or a customer needing to choose another method may be recoverable. Your system should store the reason and decide whether to retry, ask for action, or abandon the attempt.

Every term