Setting up payments and delivery in an online store

A catalogue and attractive product cards are only part of an online store. What decides everything is what happens after the "Place order" button: how payment is taken, what happens when a payment fails, how delivery is calculated, and what the buyer sees if something goes wrong. This is where orders are lost most often, even when the storefront is fine.

An order isn't just a row in a database

Every order needs a clear history of states: created → awaiting payment → paid → cancelled → refunded, with the date and reason for each transition. Without it there's no way to tell why an order is stuck, and support spends its time on manual investigation instead of helping the customer.

Taking payment: the details usually missed

• The order total must be calculated and verified on the server, not in the browser — otherwise it can be changed by accident or on purpose.

• Payment confirmation must be verified through the provider's official notification, not just because the customer was returned to a success page — that redirect can be faked.

• The same payment notification can arrive more than once — the system must recognise that and not count the payment twice.

• The payment provider's secret keys must live only on the server and never reach code that runs in the browser.

Delivery: not only "how much"

Beyond zone rates and timeframes, think through in advance: collection points with real addresses and opening hours, weight and size limits, what happens when a delivery date moves, when the customer doesn't answer, or when they refuse the order. The more of these scenarios are settled up front, the fewer individual investigations each non-standard order needs.

What the buyer sees

• The full cost of the order — with delivery and any fees — must be visible before payment, not appear as a surprise at the last step.

• Checkout shouldn't require registration — that's one of the main reasons buyers abandon a basket.

• If payment fails the first time, the basket must be preserved rather than emptied, so nobody has to rebuild their order.

• Test the flows on mobile and on a slow connection — that's where orders are lost most often.

After launch: routine you can't skip

A daily reconciliation of paid orders, refunds and "suspicious" transactions that arrived but weren't recognised by the system is a standing practice, not a one-off check at launch. It also helps to write down in advance what a manager does by hand if the payment provider or the courier service is temporarily unavailable — these outages happen to everyone; the only question is whether there's a plan for them.

If you need payments and delivery set up without risking orders for no reason, we can review the current setup or design it from scratch around your catalogue and audience.