Payment result page: say what happened

Many result pages answer with a code, a red box or a spinner that never ends. A declined card that returns to an empty cart makes the buyer think the order vanished. A payment still being checked, shown under the words thank you, makes them think it went through, so they order again. A page that needs a reload to finish makes them press refresh, and the browser asks whether to send the attempt once more. You usually see only the success page, because that is the outcome you test for first.

• The first line says what happened: paid, declined, still being checked, or not yet known.
• A declined or failed payment keeps the cart and the address, so the buyer can try again.
• A payment still being checked never uses the words thank you or order confirmed.
• A refresh or the back button does not place a second order or repeat the charge.
• The page names a next step and gives an email address for the store.

A buyer reads the first line before anything else, so each outcome gets its own. Wrong: Thank you for your order, shown on every result, with the details below. Right: Your payment went through, and the order number is below, on a success page that is different from the one a declined card sees. Wrong: Error, with a code and nothing else. Right: Your card was declined. Try another card, or use a different payment method.

The result page should also say whether money has moved, but only when the payment provider has confirmed it. Guessing is worse than saying the answer is not known yet, because a buyer who is told the wrong thing will act on it. A line such as your payment is still being checked, and you will get an email when it clears, tells the truth while the provider is still deciding.

Some payments are confirmed after the buyer has already been sent back to your site. The redirect can arrive before the provider has settled the amount, so a page that shows the order as done is showing a guess. Read the states your store can receive, and send each one to a page that says only what is known. The page that shows order confirmed should be reached only after the provider has said the payment succeeded, not after the buyer returns.

The fault is easy to miss in a quick test, where the result arrives before any delay shows. It shows up later as a buyer who got a thank you page and no receipt, then writes in to ask if the order exists. Check your order list for each state you send through a test before you trust the page, and check it again after each change.

A buyer who sees no reply after pressing Pay taps again, or presses refresh. If the result is a form that posts again when reloaded, the second press sends the attempt a second time. The back button is the other route: it can bring back the card form with the old amount, and pressing Pay again sends the attempt once more. Each of these should lead to the same result, or to a page that shows the outcome without sending anything.

Test this on your own staging store with a payment provider's test mode, pressing Pay twice and then reloading the result page. A simulated visitor can press Pay on an empty card form, which shows the validation message, but it cannot reach the processing state, so only your own staging test can show whether a reload repeats the charge. Check the order list after each attempt, because that record is what a buyer will ask about.

Checkout flow testing

A store adds a wallet, a bank redirect or a deferred payment option, and each one can return a state the page was never built for. Check each outcome after every change to the payment setup, and read its first line on a phone. Rerun the empty card attempt after each change to the payment form. With paid credits, visitors can reach a payment page behind a site password.