Test checkout page: do the totals stay the same?

Checkout is a series of small screens, and each one recalculates the money. A discount code is usually checked when it is entered, then again when shipping is chosen, because the shipping rate can change which rule applies. A rule that counts only the discounted items can fail the minimum spend, and the code disappears without a sentence to say why. A free shipping banner on the cart can use a subtotal that ignores the code. Going back a step can reset a quantity or clear an address. The visitor reads each screen as the price.

• Apply a discount code at the cart. Does the code still show on the shipping step and on the payment step?
• Go back from the payment step to the cart. Are the quantities, the address and the code still there?
• Compare the free shipping banner with the subtotal at the shipping step. Do they count the same items and discount?
• Set one item to zero stock in a staging copy, then reach payment. Is the item removed, with a message beside it?

The cart and the shipping step often run separate calculations. The cart applies the code to the items. The shipping step adds a delivery rate, recalculates the subtotal, and asks the code to justify itself again. If the rule says the code needs a minimum spend measured on items, and the shipping step measures the total, the two can disagree. The visitor sees the discount vanish after they chose the courier, and they assume the store changed its mind.

Look at the discount line on each step, then at the request the page sent when you moved on. Each step should carry the code and return the same discount. A discount line that is present in the cart, missing at shipping and back at payment is a rule that depends on the step, and that dependence is the fault to fix.

A shopper goes back to check something. They open the cart to check a size, go back to the address to fix a door number, or press the browser's back button from the payment step to see the price again. Each return is a test of whether the page kept its state. Some pages keep the cart in the visitor's browser, and some keep it on the server, and the two can show different quantities after a return.

Go back from payment to the cart, then forward again, and read every field. The quantity, the address, the delivery method and the code should match what you left. A cart that shows one item in the header and two on the summary is the same bug as a lost discount, and it needs the same fix: one place that holds the state, read by every step.

A free shipping banner states a threshold, such as free delivery over a set amount. The banner and the total often read different numbers, one before the discount and one after. A shopper who sees the banner, adds an item to reach the threshold, and still pays shipping at the end is unlikely to go back and check which number the store used. They simply leave.

Test the threshold with the code on and off. Add items until the banner says free shipping, then apply the code and reach the shipping step. The shipping line should match the banner's own rule. The same check catches a sold out item: set one to zero stock in a staging copy, and see whether the message appears beside that item or only at the top of the payment step.

Each new shipping rate, tax rule or discount can change what the summary shows at the next step. Run the same cart with the same code after every change, on a phone and a laptop, and again on each preview before a sale starts. On a protected preview, the run needs a site password from you, and it stops at the payment step either way.