Pending vs Failed vs Expired vs Paid: The Payment Status Guide Merchants Need

The three layers merchants must keep separate

The first layer is customer experience: what the buyer sees in the browser. The second is transaction state: what the platform and provider have verified. The third is merchant settlement: whether the expected asset has reached the merchant workflow or wallet. These layers can complete at different times without necessarily indicating an error.

A customer can finish card authorization while the provider remains processing. The platform can confirm paid before an on-chain settlement becomes visible. The merchant store can remain pending because a webhook failed even though the platform knows the result. Support should always identify the layer before answering the customer.

Created: the session exists but no payment action is proven

Created means the platform accepted the session request and issued a reference or checkout URL. It does not mean the customer reached the provider, entered payment details or authorized anything. The correct store status is usually pending payment. Inventory reservation depends on the merchant’s own policy, but fulfillment must not occur.

Track creation success separately from payment conversion. A high number of created sessions with few redirects suggests a store or UX problem. A high number of redirects with few provider completions points later in the funnel. Combining these stages into one conversion metric hides the real loss.

Pending: work may still be happening

Pending is an active unresolved state. The customer may be completing the provider step, waiting for verification, or the provider may be processing a payment and callback. Pending should have a timestamp and an expected follow-up mechanism. A status that remains pending forever is not a workflow; it is missing expiration or reconciliation.

The customer message should say that the payment is being checked and should not encourage an immediate second attempt. Show the order reference and explain that confirmation can take additional time. The system should poll or reconcile server-side rather than depend on the customer keeping the page open.

Processing: provider activity is known but finality is not

Some routes expose processing as a separate status. It can mean authorization succeeded but compliance, conversion, transfer or final callback remains incomplete. Treat processing like pending for fulfillment unless the provider contract explicitly defines a guaranteed final state. The most important rule is to avoid interpreting positive wording as settled money.

Record when processing began and how long it normally lasts by route. If the state exceeds the normal window, open a provider or platform investigation with the session and provider reference. Support can then give the customer a precise answer instead of “try again.”

Paid: the only status that should release paid fulfillment

Paid must be based on authenticated server-side evidence. A signed webhook, verified API query or internally reconciled platform status can establish it. The customer return URL cannot. Once an order is paid, the transition should be idempotent: repeat notifications may update logs but must not repeat stock reduction, access delivery, affiliate credit or customer email.

Store the paid timestamp, amount, currency, session ID, provider reference and event identifier. If the merchant’s model waits for settlement before high-value fulfillment, represent that as a separate operational state rather than weakening the meaning of paid. Clear states make policy visible.

Failed: the attempt ended without confirmed payment

Failed means the current attempt will not complete in its existing form. The cause might be provider decline, unsupported method, verification failure or technical rejection. The customer may be allowed to start a new session, but the old session should remain traceable and should never be overwritten with the new reference.

The error message should be useful without revealing sensitive risk details. “This payment could not be completed. Choose another method or start a new secure attempt” is better than a raw provider code. Support should still retain the internal code for route analysis.

Expired: time ended, but late evidence must still be handled

Expired usually means the checkout window closed before the platform received final confirmation. It helps release reserved stock and prevents old URLs from being used indefinitely. However, expiration in the store does not make verified late payment evidence disappear. Some provider events can arrive after the expected window.

Design a late-payment path. If an expired order later receives a verified paid event, the system should flag it for safe reconciliation, restore or re-create the order where appropriate, and prevent the customer from paying twice. Never silently discard authenticated paid evidence just because the store clock reached a timeout.

Cancelled: customer intent ended the current attempt

Cancelled normally means the customer actively left or cancelled the provider flow. It is different from failed because no provider decline may have occurred. It is different from expired because the time limit did not necessarily elapse. Keep the distinction for analytics: cancellation can reveal trust or UX problems that technical failure metrics cannot.

Offer a clear return to checkout and preserve the cart. Do not label the customer as suspicious simply for cancelling. If the provider may still finish an authorization, keep reconciliation active until the route is truly terminal.

The return URL is a viewer, not a payment command

A return URL should receive the customer, read the merchant order reference and ask the server for current verified status. It can show paid, pending, failed or expired. It should never accept a query parameter such as status=paid and write that value into the order. Browser parameters are controlled by the customer and can be changed.

The page should also be safe to refresh. A paid page can show the receipt repeatedly, but fulfillment must already have occurred through an idempotent server event. A pending page can check again after a short delay without creating another payment session.

Webhooks, polling and reconciliation have different jobs

Webhooks provide fast event delivery. Polling gives the browser a way to display current status. Reconciliation repairs missing or delayed events by querying unresolved sessions later. A strong integration uses all three appropriately instead of expecting one mechanism to solve every failure.

Every webhook should be authenticated and stored with a unique event ID. Every reconciliation update should record the previous and new status. Polling endpoints should return only the minimum customer-safe information. Together, these controls create an audit trail that support can follow.

Safe retry rules prevent duplicate payment

A customer should not start a second attempt while the first remains actively pending or processing unless the platform can prove the original attempt is terminal. If a retry is allowed, create a new session linked to the same order or a new replacement order according to the store design. Never reuse a provider session in a way the provider does not support.

Show the customer the existing attempt and its timestamp. Give an explicit retry button only after failure, cancellation or confirmed expiration. For high-value orders, consider support review before a third attempt. Duplicate attempts create refunds, charge disputes and mistrust even when the gateway technically processed each payment correctly.

Map payment status to WooCommerce carefully

WooCommerce uses statuses such as pending payment, processing, completed, failed, cancelled and refunded. Map the external paid state to processing for physical orders or completed for appropriate virtual orders. Keep pending and processing-at-provider outside the paid WooCommerce flow until verified completion.

Avoid automatic cancellation rules that ignore the gateway’s expected confirmation time. If WooCommerce cancels an order at 15 minutes but a provider normally confirms at 20 minutes, late paid orders will require repair. Align expiration windows across the store, platform and provider as closely as possible.

Use status metrics to find the real conversion problem

Measure how many sessions enter each state and how long they remain there. Created-to-redirect loss suggests the customer never entered checkout. Redirect-to-pending loss may reflect provider page abandonment. Pending-to-paid duration shows processing behavior. Failed reasons reveal route, country, amount or method limitations.

Do not react to one order by rewriting the whole checkout. Review a meaningful sample by route and order value. Status data is most useful when it explains a decision: change wording, disable a weak route, adjust amount minimums, improve reconciliation or update support guidance.

Recommended status record fields

The following checklist turns the article into an operating document. Assign an owner, record completion and keep the result with the merchant configuration or incident. A checklist is valuable only when the team can show evidence for each item rather than assuming that someone tested it.

Review the list after any major route, wallet, domain, plugin or fee-policy change. Payment systems drift over time: certificates renew, providers change behavior, store plugins update and staff permissions change. Repeating the relevant controls is cheaper than discovering the gap through a customer complaint.

• Merchant order ID and platform session ID.
• Current status and previous status.
• Status source: webhook, API query, reconciliation or manual override.
• Provider reference and event ID.
• Amount, currency, fee mode and customer-visible total.
• Created, paid, expired and last-checked timestamps.
• Fulfillment timestamp and idempotency key.
• Exception reason and next review time.

Customer wording by status

The following checklist turns the article into an operating document. Assign an owner, record completion and keep the result with the merchant configuration or incident. A checklist is valuable only when the team can show evidence for each item rather than assuming that someone tested it.

Review the list after any major route, wallet, domain, plugin or fee-policy change. Payment systems drift over time: certificates renew, providers change behavior, store plugins update and staff permissions change. Repeating the relevant controls is cheaper than discovering the gap through a customer complaint.

• Pending: “We are checking the payment. Please do not pay again.”
• Processing: “The payment partner is completing the transaction. Your order remains reserved.”
• Paid: “Payment confirmed. Your order is now being processed.”
• Failed: “This attempt was not completed. You can start a new secure payment.”
• Cancelled: “The payment was cancelled. Your cart is still available.”
• Expired: “This checkout session expired. Create a new payment to continue.”

Design rules for a durable payment state machine

Use monotonic finality for the core payment result. Once authenticated evidence marks a session paid, ordinary pending, failed or expired events should not reverse it. Corrections such as refunds or chargebacks belong in separate states or records. This prevents an out-of-order callback from turning a fulfilled order back into unpaid and triggering stock or customer communication errors.

Separate payment attempt from merchant order. One order can have several attempts, each with its own session, provider reference and terminal result. The order becomes paid when one authorized attempt succeeds, while the other attempts remain failed, cancelled or expired. This model makes duplicate investigations possible and avoids overwriting the first attempt when the customer retries.

Every transition should include an idempotency key and an actor. The actor may be webhook, reconciliation job, API query or authorized admin. Manual overrides should require a reason and supporting evidence. A timestamp without source is not enough during a dispute because the team cannot tell whether a customer-controlled request, automated process or staff member changed the state.

Build time into the model. Pending should have next-check and expiry timestamps. Processing should have a route-specific escalation threshold. Failed and expired attempts should retain a late-event watch window. Paid should have fulfillment and settlement linkage. Time-based rules should be explicit jobs, not assumptions hidden inside a page request.

Test state transitions with a table. List every current state against every incoming event and define the permitted action. Most cells should be “ignore and log.” This exercise exposes unsafe transitions, such as paid plus expired becoming expired, or failed plus paid being discarded even though the paid event is authenticated.

Additional implementation controls

Expose status definitions consistently in the merchant dashboard, API documentation and support knowledge base. If the API calls a state processing while the dashboard calls it pending and support calls it approved, staff will make different decisions from the same event. The label can be customer-friendly, but the underlying operational meaning and fulfillment rule must remain identical.

Create reports for impossible or suspicious transitions, such as paid without a provider reference, fulfilled while still pending, expired after paid, or more than one paid attempt linked to the same order. These reports are more useful than scanning normal transactions because they focus attention on states that can produce financial loss.

Example: the “paid customer, pending store” incident

A customer completes a €120 payment and receives a provider confirmation. The browser closes before returning to the merchant. The platform receives the paid event, but the merchant webhook endpoint is temporarily blocked by a firewall rule. The WooCommerce order remains pending, so the customer contacts support and considers paying again.

A mature status workflow prevents duplicate payment. Support searches the merchant order, finds the platform session and confirms the server-side paid status. Reconciliation updates the store idempotently, sends the fulfillment event once and records the recovery. The customer is told not to retry. The incident becomes a webhook-delivery problem, not a mystery about whether the customer paid.

A status-handling decision tree

1. Find the merchant order and platform session; never investigate from a screenshot alone.
2. Check verified platform and provider status before reading the browser return result.
3. If paid, fulfill once and reconcile settlement separately.
4. If pending or processing, keep the order unpaid and give a precise follow-up window.
5. If failed, cancelled or expired, permit a controlled new session while preserving the old attempt.
6. If records disagree, stop automated fulfillment and escalate with all identifiers.

This decision tree gives support a repeatable method. It also exposes missing data quickly: if the team cannot find the session ID or provider reference, the integration must improve its logging.

Frequently asked questions

Can a payment be paid if the customer never returned to the store?

Yes. The provider and platform may complete server-side even when the customer closes the browser. The merchant should rely on authenticated status and reconciliation, not the return page.

Should pending orders be fulfilled?

No, unless the merchant deliberately offers service before payment. In a normal paid-commerce flow, pending is unresolved and should not release paid goods or access.

Can an expired payment later become paid?

A verified late event can arrive after a local timeout. The integration should handle this as a reconciliation case rather than ignoring the money or asking the customer to pay again.

Why do duplicate webhooks happen?

Providers retry delivery when they do not receive the expected response or when event delivery is designed for reliability. Idempotent handling makes retries safe.

What status should the customer see after returning?

Show the verified current state: paid, checking payment, failed, cancelled or expired. Do not invent finality because the browser reached a particular URL.