A storefront can look finished before it is ready to accept real orders.
The product pages work. The cart updates. A test payment succeeds.
But what happens when two customers buy the last item, a payment notification arrives twice, or the shipping service stops responding?
For developers and business owners planning an online store, these are useful questions to answer before launch.
Here are seven checks to include in your e-commerce launch review.
1. Calculate prices on the server
The browser can display a price, but it should not decide what the customer pays.
When creating a checkout session, the backend should:
- Load current product and variant prices.
- Validate quantities.
- Apply eligible discounts.
- Calculate delivery charges and applicable taxes.
Do not accept a total from the frontend as authoritative.
Try this: Modify the price in a checkout request. The server should calculate the correct amount independently or reject the request.
2. Verify payments and handle duplicate notifications
A customer reaching a success page is not enough evidence to mark an order as paid.
Use the payment provider's supported server-side verification flow. For webhook integrations, verify signatures and match the payment to the expected order, amount and currency.
Design for repeated notifications too. Stripe's webhook documentation explains that duplicate events can occur and that event delivery order is not guaranteed.
Processing the same successful payment again should not:
- Create another order.
- Reduce stock twice.
- Trigger a second shipment.
This is the practical purpose of idempotency: repeating an operation does not repeat its business effect.
Try this: Replay a valid payment event. Check that the order and fulfilment records remain consistent.
3. Decide how inventory is reserved
Checking stock when an item enters the cart is not enough.
Imagine two customers checking out while only one unit remains. If both requests read the same stock value before either updates it, both may appear valid.
Choose an inventory policy explicitly:
- When is stock reserved?
- When does the reservation expire?
- What happens if payment completes after expiry?
- When is reserved stock released after a failed payment?
Use atomic conditional updates or appropriate database transactions to enforce that policy. A separate “read stock, then subtract” sequence can race.
Try this: Send simultaneous checkout requests for the last available unit.
4. Check who can access each order
Authentication answers: “Who is this user?”
Authorisation answers: “Can this user access this particular order?”
Every order-detail, invoice, cancellation and refund endpoint needs the appropriate server-side permission checks.
Hiding buttons in the interface does not protect the API.
The OWASP Authorisation Cheat Sheet recommends denying access by default and validating permissions on every request.
Try this: Sign in as Customer A and request Customer B's order. Repeat the check for endpoints that modify the order.
5. Plan for delivery-service failures
Payment, order processing and shipment creation are separate steps.
If the shipping provider times out after payment succeeds, retain the paid order and show its actual fulfilment status.
Record the failed shipment attempt so it can be retried or reviewed.
Before retrying, consider whether the provider created the shipment but its response was lost. Use provider-supported idempotency or reconcile with existing shipments to avoid duplicates.
Your team should be able to identify:
- Orders awaiting shipment creation.
- Failed shipment attempts.
- Orders requiring manual review.
Try this: Simulate a shipping timeout and verify that the team can identify and recover the affected order.
6. Test the complete mobile journey
Review more than the homepage.
On a real phone, go through the entire shopping journey:
- Open a product page.
- Select a size, colour or other variant.
- Add the product to the cart.
- Change the quantity.
- Enter a delivery address.
- Apply a coupon.
- Complete payment.
- Return to the order page.
Check whether validation messages are understandable, form fields have labels, and the cart survives recoverable errors.
Try this: Complete checkout on a small screen using a slower connection.
7. Make failures traceable
When a customer asks, “I paid, but where is my order?”, support needs a way to investigate.
Connect order records, payment references and shipment references.
Record useful status changes and failures without logging secrets or unnecessary personal data.
Give the team a clear recovery process for:
- Paid orders awaiting confirmation.
- Unsuccessful shipment attempts.
- Refunds needing attention.
Try this: Pick a failed test order and see whether another team member can explain what happened.
Your pre-launch checklist
Before accepting real orders, check that:
- [ ] Prices and discounts are validated on the server.
- [ ] Payments are verified through the provider's supported flow.
- [ ] Repeated payment events do not repeat business actions.
- [ ] Inventory updates handle concurrent purchases.
- [ ] Customers can access only the orders they are permitted to access.
- [ ] Shipment failures have a recovery path.
- [ ] Mobile checkout has been tested.
- [ ] Support can trace failed transactions.
A successful test purchase is a useful milestone. Testing failures, permissions and recovery gives you more evidence that the store is ready for everyday use.
Which edge case would you add to this checklist? Share it in the comments.
About the author
I'm Anandhu R S, a full-stack developer and founder of Kode Company, based in Trivandrum, Kerala.
We provide web development, e-commerce development, CRM, SaaS and custom software services for businesses.
Planning an online store or upgrading an existing one?
Email us at kodecompany.info@gmail.com to discuss your requirements.
Kode Company — Build. Solve. Evolve.
Top comments (1)
one more for the list: prices that change between cart and payment. the number the customer saw when they added the item and the number charged at checkout are fetched at different moments, and if a discount expires or a price updates in between, you get a support ticket none of the seven checks cover. worth deciding which price wins and showing it before the pay button.