Understand checkout recovery states

Checkout can remain pending while Customer App reads a cart, resumes an external payment handoff, confirms a single cart or group, searches for an order, or reconciles provider and Ordering state. A pending, failed-looking, or closed provider surface does not establish whether payment, wallet, order, or refund effects occurred.

The safe customer posture is: wait, check Orders, and do not repeat while settlement is unknown. Reloading, reopening Checkout, switching payment method, using Back, returning the app to the foreground, or repeating Place/Confirm is not a diagnostic. Those events can start additional recovery or provider work.

Recognize the recovery state

Visible state	Safe interpretation
Checkout loading	Cart, account, configuration, payment, wallet, or order state is unresolved
Pending/processing	A placement, provider, confirmation, or order lookup can still be in flight or awaiting reconciliation
Failed-looking message	One layer reported an error; it does not prove that no payment, wallet, order, or provider effect occurred
Provider surface open	External or embedded provider work is pending; Customer App settlement remains separate
Provider surface closed	The surface closed or Back was handled; cancellation, failure, confirmation, and no-effect are not distinguished
Customer App returns to Checkout	Focus/foreground/navigation state changed and can start a new read or recovery branch
Order appears in Orders	Ordering presents an order associated with the current account; provider and group settlement may still have separate states
No order appears	Absence in one view does not prove that placement or payment did not occur

Do not interpret a toast, disabled button, navigation, provider message, native SDK result, or changed cart status as an exactly-once operation receipt.

Automatic recovery triggers

The current source can re-read and reconcile Checkout when it mounts, receives focus, returns to the foreground, handles Back/close for some provider surfaces, or processes return/query state. A pending cart can then enter provider-specific work or a confirmation request.

These triggers are not customer retries, but they can repeat financial recovery without a common operation-generation receipt. Do not deliberately activate them to test the state. In particular:

• do not reload or restart the app;
• do not leave and reopen Checkout;
• do not background and foreground the app repeatedly;
• do not use Back or close a provider surface as a cancellation test;
• do not alter a return link or query; and
• do not switch payment method to see whether the prior attempt disappeared.

Provider and confirmation stages

Stage	What it can mean	What it does not prove
Redirect or embedded handoff	Customer App transferred work to an external payment context	Provider acceptance, Ordering confirmation, or order creation
Native payment SDK result	A platform/provider SDK returned a local result	Correct amount/account/cart, final capture, or Ordering order
Provider close or PayPal Back	The provider surface closed and can trigger local confirmation logic	Customer cancellation, no charge, or successful confirmation
Single-cart confirmation	Ordering attempts to reconcile one pending cart	Provider settlement, order existence, session freshness, or exactly-once execution
Group confirmation	Ordering attempts to reconcile multiple carts	Complete membership, all-member success, one group order, or rollback
Order lookup/navigation	Customer App looks for or opens a returned order	Provider, wallet, refund, message, job, or socket completion

Provider return is input to Ordering reconciliation, never the authoritative customer completion state by itself.

Lost response and unknown settlement

A request can commit remotely while its response is lost. Conversely, a local provider success can exist without accepted Ordering settlement. Current safe guidance is limited: Orders reflects Ordering state only. If the outcome remains unresolved, contact an approved support channel and do not repeat the financial action.

A future accepted recovery contract must provide a durable, authoritative operation handle and status-only receipt bound to the exact account, project, session, cart or group, method, amount, and operation generation. This is a required future contract, not a current Customer App capability.

While unknown:

• do not submit Place, Confirm, payment, or wallet work again;
• do not change method or financial inputs;
• do not create another cart to test whether the first one settled;
• do not assume an error rolled back payment, wallet, refund, order, job, or provider effects; and
• do not assume an order card means every financial/group effect completed.

Single and grouped checkout

Single-cart and grouped confirmation have different membership and settlement boundaries. A grouped result can be partial: some carts can become orders while others remain pending, failed, missing, or financially unresolved.

Navigation to grouped details, a group identifier, a completed-looking group status, or one successful member does not prove exact membership or all-member completion. Preserve every member outcome separately and never present mixed results as group success.

Wallet, refund, and order side effects

Placement and recovery can cross several independently settling systems:

• a wallet reservation, debit, compensation, or refund can differ from cart and order state;
• an order can be created before navigation or the final client response;
• provider authorization, capture, reversal, and local payment events can diverge;
• jobs, plugins, messages, sockets, and analytics can complete later; and
• session/account/project changes can make a late response unsafe to apply.

Customer App presentation does not prove that those effects are atomic, reversible, exactly once, or complete.

Safe next steps

1. Stop interacting with Checkout while it shows pending or an ambiguous error.
2. Wait for the current operation to settle without reloading, reopening, backgrounding, changing method, or closing/reopening a provider as a test.
3. Check the ordinary Orders surface once from the current account and project.
4. If an authorized current order is present, use its status only as the Ordering order state; keep provider, wallet, refund, and group outcomes separate.
5. If the outcome remains unknown, use an approved support channel and describe only the state class. Do not send payment data, provider messages, links, tokens, cart/order references, or screenshots.

These are conservative no-repeat boundaries, not a retry or payment procedure.

Troubleshoot safely

Symptom	Safe response
Pending message remains	Wait; do not follow any reload advice shown by older UI copy
Failed-looking message appears	Treat settlement as unknown; do not immediately try again
Provider closes or returns unexpectedly	Do not infer cancel/success; keep Checkout untouched and reconcile Orders
App returns to Checkout after foreground	Do not trigger another focus cycle; recovery may already be running
Orders shows no new item	Preserve unknown state; absence is not proof of no charge/order
One grouped member appears	Do not infer group completion; retain per-member uncertainty
Wallet or provider state conflicts with Orders	Do not calculate or initiate compensation/refund; escalate through an approved channel
Account/project changed during recovery	Discard the previous view and do not apply or repeat its late result

Accessibility and privacy

Loading, pending, failed-looking, provider handoff, unknown, confirmed order, partial group, wallet/refund conflict, disabled, and no-repeat states need clear semantic text and announcements. Busy controls must expose disabled/busy state; Back and provider close need consequences; focus must not jump to an enabled Place action after foreground recovery.

Large text, keyboard, screen reader, reduced motion, safe areas, and iOS/Android Back behavior must preserve the warning and safe Orders handoff without causing duplicate action. Do not expose payment, wallet, provider, account, cart, group, order, link, token, or raw error data in labels, logs, screenshots, or support notes. These are verification requirements, not current certification.

Recertification triggers

Revalidate this reference after changes to pending/failed status, mount/focus/ AppState/Back/query recovery, provider redirects or embedded surfaces, native SDKs, provider-close behavior, single/group confirmation, order lookup, idempotency/locks/operation receipts, wallet/refund/compensation, job/plugin/ message/socket effects, account/project/session cleanup, Orders handoff, accessibility, or App/components/API authority pins.

Related guides: Review your cart before checkout · Understand payment-method availability · Understand multi-business checkout · View active and past orders · Understand grouped order states · Understand offline and reconnect behavior