On an ecommerce site, the buy button isn't the last step. Payment, inventory, order, and delivery information are separate processes that follow one another. When these steps show different results, the customer can't tell what happened, and the business ends up resolving the same order by hand.
A customer likes your product and adds it to the cart, only to see an unexpected fee at checkout. Another customer can't tell whether their order went through after their card was charged. In situations like these, the problem isn't only design — the parts of the buying journey weren't planned together. Building an ecommerce site is a bigger job than putting products online.
01The product page should help customers decide
Size, options, product specifications, and delivery information need to be clear. If the photo shows one thing and the selected variant shows another, trust takes a hit. Answering the questions a customer is likely to ask before buying, right on the page, reduces uncertainty.
Instead of giving every product the same description, write out its actual differences. Text written for search engines should also help the customer decide — don't stack in keywords unrelated to the product.
02Reduce uncertainty before purchase
Product scope, price, delivery format, and extra fees need to be clear before the customer decides. Check that choosing a variant correctly changes stock and price. The total shown in the cart and the final payment screen must use the same calculation rules. Country-specific tax rules should be defined by the business's finance and tax advisors.
Quantity, discounts, delivery fees, and the final total need to stay consistent, and customers should be clearly notified when stock changes. Changing quantity, filling in an address, and correcting mistakes should all work smoothly on mobile. In a store selling many product variants, for example, the wrong variant ending up in the cart can later create support and returns overhead — which is why testing should cover the point where the selection is first made, not just the payment page.
03Don't treat the payment return as the only proof
A customer landing on a success page in their browser doesn't always mean the payment is verified. The payment provider's notification and the server-side order status need to be considered together. Notifications can arrive more than once; the same event shouldn't create a second order or delivery. Stripe's webhook documentation, for example, explains repeated notifications and signature verification; whichever provider you choose, its own flow needs to be implemented as well.
04Separate inventory and delivery states
"Paid," "preparing," "shipped," and "digital delivery pending" are different stages. If the system fails to prepare a file, it shouldn't say "delivered." Scenarios like the last unit being sold twice in simultaneous orders also need to go through acceptance testing. We covered how these edge cases are tested in our professional testing article.
05Complete the flow for customers who run into trouble
Retrying after a failed payment, checking order status, and opening a support request should all be easy. Return and withdrawal rules are set by product type and the country's applicable law; clarify these rules with your legal counsel. The software should implement the defined process with traceable records and should never show a success message to the user for a transaction that hasn't actually completed. In our ecommerce service we design the order flow together with these problem scenarios.
06Don't forget the experience after the order
The order number, status information, and the business's contact channel need to be accessible. On the admin side, preparation, delivery, and related document workflows need to be trackable. If warehouse or accounting systems are connected, it should be clear which system is the single source of truth.
07Quick checklist
- Does the product page clearly display product, variant, and delivery information before the customer buys?
- Are the cart total and the payment screen total calculated with the same rules?
- Is the order verified through the payment provider's server-side notification?
- Does a repeated notification avoid creating a second order or delivery?
- Can the last unit in stock not be sold twice in simultaneous orders?
- Do order states mean the same thing to the customer and the business?
- Can a customer safely retry after a failed payment?
Written by
The Paradigma7 team
Product, engineering and operations
We are an Ankara-based team building software for Europe. Nothing here is theory: these are the processes we actually run on client projects.
About us