Check the payment state before recovering an expired checkout

Record what expired before assigning a cause

Keep the actual message rather than shortening every failure to session expired. Record when checkout was opened, when the error appeared, the last action, whether the payment control had been used, and whether an external payment or authentication step had already occurred. Label an elapsed time reported from memory as an estimate. Neither the duration nor the word expired identifies the component that rejected the request.

Record the affected route without private query tokens, the browser and the observed state of the cart and form. Was information still present, or had the page returned to an earlier step? Use the original incident and available logs; do not recreate an uncertain payment by submitting it again. Preserve only non-sensitive diagnostic details in the working note.

Ask the maintainer to identify which layer produced the message from the corresponding request or log entry: the store's session handling, a request-security check, or the payment integration. A security-token message is not evidence that the payment provider declined the transaction. A provider-session error is not evidence that the store's cart cookie reached its limit.

Resolve the first payment attempt before recovery

WooCommerce's order-troubleshooting guide directs merchants to identify the payment gateway on the order or in its notes and not retry until the gateway shows that the earlier attempt created no charge. Search the authorized store and provider records for the same incident, using the available order and payment references and timestamps. A missing order note can mean communication failed; it is not proof that payment was never attempted.

If a successful provider charge exists while the store order remains pending or disagrees, treat that as a payment-to-order reconciliation problem. Have the integration owner investigate the callback or notification path and reconcile the records before fulfillment. A fresh checkout submission does not repair the existing mismatch.

If the provider state is pending, otherwise unresolved, or cannot be matched confidently, keep recovery with the named payment owner and do not ask the buyer to try another method. If the provider confirms no charge and no unresolved payment remains, the owner can decide how to restart the checkout using the supported flow for that installation. Absence of a charge is a prerequisite for that decision, not a command to retry every failed method.

Use session and cache evidence without inventing a timeout

WooCommerce's caching guidance describes cart cookies and the wp_woocommerce_session_ cookie, but its documented lifetime is not a promised duration for completing payment. It does not define the lifetime of every request token, provider session or extension-specific security check. Do not tell buyers they have a fixed checkout window based on that cookie documentation.

The same guidance says Cart, Checkout and My Account must remain dynamic. Caching tools may already exclude them, and database session exclusions depend on the host or plugin. Have the responsible maintainer inspect the actual route and rules that served the affected page. A recent cache change is a fact to investigate; it is not sufficient evidence that caching caused the expiry.

If the failing request identifies a specific extension or provider component, its configuration, installed version and applicable documentation are the next evidence. Record the actual error code or non-sensitive log reference before changing a timeout. Do not disable all caching or remove security checks to make the message disappear. A targeted correction needs a demonstrated relationship to the rejected request.

Make the recovery instruction match what is known

When the merchant cannot yet determine the payment outcome, the buyer-facing instruction should reflect that uncertainty and direct the buyer to the existing support route without asking for card data. Do not present an expiry message as confirmation that no money moved. Once the outcome is established, the support owner can give the specific recovery instruction for that order or checkout.

For automatically detected input errors, W3C's Error Identification guidance requires identifying the item and describing the error in text. Apply that distinction when the problem really is an input error. A session-level failure should not be disguised as a demand to correct an unrelated address or payment field. Record whether the message identifies what failed and whether the next step is consistent with the known payment state; that observation is not a complete accessibility audit.

After an authorized repair, observe the affected non-payment interaction and inspect the relevant records. Do not repeatedly submit a live payment to demonstrate that the error disappeared. Where payment outcome remains necessary to establish recovery, keep that portion unresolved until the authorized owner has genuine evidence.

For a Prism checkout-review consultation, describe the platform, the exact non-sensitive error, its stage and whether payment state has been resolved. Confirm investigation and implementation responsibilities, scope, fees and terms before work. The consultation does not itself reconcile the order or authorize a retry.

Expired-session recovery record

Use one record for one genuine incident. Retain detailed logs and customer records in authorized systems. Enter safe references and observations only, never cookie values, security tokens or payment-link credentials. Unknown payment state means no retry; a completed timing row does not override that rule.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.