An online shop is ready to trade when a customer can place an order and the business can fulfil it reliably. A polished product page and a successful test payment cover only part of that process.
Before launch, test the order from both sides: what the customer sees on a phone and what staff receive when they need to pack, dispatch or investigate it. Use the payment provider’s supported test environment and test payment details.
Show the amount before payment
Check that product prices, basket totals and delivery charges use the intended currency consistently. For a South African shop, default to rand pricing and make any limitations on supported currencies clear.
Ask the person responsible for pricing and tax to approve what the customer sees. Test discounts, different quantities and delivery charges together. The amount sent to the payment provider must match the order recorded by the shop.
Do not leave the customer to discover an additional charge after they have started paying. If delivery cannot be calculated immediately, explain the next step before asking for payment.
Test actual delivery rules
Try addresses inside and outside your delivery area, including an address that needs a manual quote. Check collection separately from courier delivery. Make sure staff can see which option the customer selected.
For each route, confirm what happens when an item is unavailable, an address is incomplete or a delivery calculation fails. The customer needs a clear way forward, and staff need enough information to resolve the order.
Separate payment status from page navigation
A customer returning to a success page is not sufficient proof that a payment completed. Payment gateways provide server-side confirmation mechanisms that need to be validated according to their integration documentation.
For example, Yoco’s webhook verification documentation explains how to check event signatures and timestamps. Your developer should follow the current guidance for the provider you use and confirm the expected payment, amount and order reference before updating the order.
Design the update so a repeated notification cannot create duplicate fulfilment. Keep enough of an audit record for staff to match an order to its payment without exposing sensitive payment information.
Test interruptions deliberately
Try cancelling payment, declining it and closing the browser before returning to the shop. Test a delayed confirmation and a repeated notification. Confirm what happens when the customer presses the payment button twice.
The interface should distinguish a confirmed payment from one still being checked. Give the customer an order reference and a useful contact route. Avoid prompting another payment while the first may still be processing.
Check the staff workflow
Ask someone who did not build the shop to find a test order, confirm its status and prepare it for fulfilment. They should be able to see the items, delivery option and customer contact details without searching through developer logs.
Agree how refunds, cancellations and stock changes are handled. Send test customer and staff emails, and verify the links from a phone. A confirmation that never reaches the right inbox can leave a correctly paid order unattended.
Keep the completed checks with the launch record. Repeat the payment and fulfilment tests when changing a gateway, courier integration or checkout feature. For help with a specific buying flow, speak to webrack.