Checkout Recovery

Overview

Start with the actual order state

Recovery should not assume that a customer leaving the page means no payment happened. The browser may close after a wallet transfer was broadcast, or an invoice request may succeed even though its response was lost. When the customer returns, the merchant should retrieve the authoritative order and payment state. It should then choose a next step based on whether the request is still usable, expired, paid, partially paid or awaiting confirmation. A button that always creates a new invoice can turn a simple interruption into duplicate payment instructions.

Common recovery paths

If the customer left before choosing a payment method, restoring cart and order details may be enough. If an unpaid invoice remains valid, show the existing instructions and remaining time. If the request has expired, explain why it cannot be reused and offer a new one tied to the same commercial order when the business rules allow. If a transfer is pending, show that status and avoid inviting the buyer to pay twice. A wrong-network or underpaid transfer may require separate investigation rather than an automatic retry.

Design for clarity and control

A recovery message should identify the order without exposing sensitive data and should distinguish an action the customer can take from a state only the payment system can resolve. Preserve the relevant checkout step across a safe reload or authenticated return. Record which payment attempt belongs to the order and whether an earlier attempt is still active. Notify support when manual intervention is necessary rather than silently marking the checkout successful.

What successful recovery means

The goal is a verified completed purchase with no duplicate collection or fulfillment. Track how many interrupted journeys resume, how long resolution takes and whether recovery increases errors or support cases. The companion term Checkout Error explains the conditions that may trigger recovery.