Payment confirmation page: wait for the result

Some cards ask the buyer to approve the charge in their bank's app or on a bank page. They leave your site to do it, then return. Your server may still be waiting for the bank's answer when the buyer lands back, so the page has nothing final to show. A spinner that never resolves, a Pay button that reappears or a blank page all read the same to the buyer: the charge may not have happened, and the safe guess is to pay again. A second payment is how a buyer can end up charged twice, and it can start on your confirmation page.

• Success appears only after the server confirms the payment, not on the redirect alone.
• A pending payment shows a status line and no Pay button.
• The order number and total on the page match the receipt email.
• A refresh shows the same confirmation, and never a second payment prompt.
• A return from a bank approval page lands on the same order, with the same total.

A redirect back from the payment step tells the buyer where they are, not what happened. The page should ask the server for the status of this order, and show success only when the status is final. Wrong: the page shows Thank you for your payment because the visitor arrived there. Right: the page checks the order, sees that the payment is confirmed, then shows the order number and the total. If the check finds the order still pending, the page says so and keeps checking, or invites a refresh. A confirmation that appears before the server agrees will be wrong for some buyers, and they are the ones who pay again.

Approval steps send the buyer to a different page, sometimes in a new tab, and the way back is where things get lost. The return address may not carry the order reference, so the confirmation page cannot find what to show. The buyer may have returned to the original tab and found it still on the payment form. Check the return on a phone, because the bank's app may open in front of your page and the browser may reload it. Each path should land on the same order, with the same total. If it lands on a blank form, the buyer is invited to pay again, and that is the fault to fix first.

A confirmation that shows a different total from the one charged is a support request waiting to happen. Tax and shipping are a common gap: the cart shows one number, the confirmation shows another, and the charge matches a third. Check that the total on the confirmation page matches the total at the payment step, and that the receipt email shows the same order number and amount. Currency is the other gap, when a shop shows prices in one currency and charges in another. Name the currency beside every amount, so a buyer comparing the two numbers can see they match.

A visitor stops before Pay, so nothing on this confirmation page is reached by a simulated test. The owner has to place one real order with a card they own, complete the bank approval step if the card asks for one, then refund the order. Check the confirmation page on a phone and a laptop, reload it, press back and forward, and open the receipt email. Note whether the confirmation shows once, whether the order opens without a login, and whether the total matches. A simulated test can still show the total and the Pay button on the step before, which is where a mismatch often starts.

Checkout flow testing

A change to the payment provider, the checkout script or the return address changes what the buyer sees after approval. A confirmation that worked for cards with no extra step can break for a card that needs one. After each change, complete one real order with a card that requires approval, refund it, and check the return. With paid credits, a test account lets visitors reach checkout behind a login, so the steps before payment can be rerun.