Payment failed page design: keep the cart

A decline is routine for your payment provider and alarming for a buyer who has just typed their details. If the page says Error code 402 or Something went wrong, the buyer cannot tell whether their card, their address or your shop failed, so they blame the shop. If the cart is empty when they return, they must rebuild the order, and some will not. If they press Pay again while the first attempt is still processing, the screen may show no sign that anything is pending, and a second attempt can follow the first. Each of these is a page problem, not a bank problem.

• The message says the payment did not go through, in words a buyer uses.
• The cart still holds every item, with the same total as before.
• The message sits beside the payment form, where the buyer's eye already is.
• Pay is disabled while the payment processes, and the button says so.
• Another card or payment method is on the same screen, not behind a link.

A decline needs three facts on the screen: the payment did not go through, the order is not placed, and the buyer can try again. Wrong: Transaction failed with code 402. Right: Your card was not accepted. Your cart is still here. Try another card or pay another way. The first version blames nothing and tells the buyer nothing to do. The second tells them their items are safe. The third names the next move. If your payment provider sends a reason you can show safely, such as an expired card, add it. Do not guess a reason when the provider gives none, because a wrong reason sends the buyer to the wrong fix.

A decline that sends the buyer to a new page with an empty cart asks them to start again. Some shops do this without meaning to. A common cause is clearing the cart when the order is created, before the payment succeeds. Keep the cart until the payment is confirmed, and keep the delivery details in the session. Then check the result by reloading the page the decline lands on, and going back once. The cart should show the same items and total, and the delivery fields should still hold what was typed. The card number itself should not come back on the page.

A buyer who sees no change after pressing Pay presses it again. If the first attempt is still running, two requests can reach the payment provider, and the buyer may see two charges or a confusing decline for the second one. Disable the Pay button as soon as it is pressed, change its label to a processing state, and keep it disabled until the result returns. The server should also refuse a second payment for the same order while the first is pending, so a refresh cannot start another. Check this part with a test order in your store's test mode.

A simulated visitor fills the checkout with a delivery address and an item, then reaches the payment step. The report shows the page it reached, the total at that step and a screenshot, so you can check the form the buyer will retry on. It never submits a payment, so a declined card is outside what it can show. You will need to trigger a decline yourself. If your payment provider has a test mode with a card set to decline, running that card through your own store shows the page as a buyer sees it.

Checkout flow testing

Each new payment method brings its own refusal messages, and a page written for cards may show a blank or wrong line for a wallet or a bank transfer. After a change to the payment provider or the methods offered, trigger a decline on each method in test mode and read the page each one produces. With paid credits, a test account lets visitors reach checkout behind a login, so the steps before payment can be rerun.