How do you test an online checkout before launch?

Your new checkout looks finished: a customer can add an item, enter an address, and press Pay. But what will they see if the card is declined, the page stops loading, or the order confirmation never reaches your team? A successful test purchase answers only one part of that question.

Test the whole order journey before launch, including failures and the work after payment. Start with a small set of realistic orders. For each one, compare what the shopper sees with the payment provider’s status and the order record your staff receives. A checkout is ready when your team can explain what happened, help the shopper recover, and avoid processing an uncertain order twice.

This guide is for a shop or service business that has already decided to accept orders online. If you are still weighing a full checkout against an inquiry or reservation path, see our guide to online orders without online checkout.

Why a failure test belongs in the launch plan

The Financial Consumer Agency of Canada’s summary of the Canadian Internet Use Survey reports that 12% of Canadians who did not shop online in 2022 said ordering online was too difficult. The survey covers people aged 15 and older in Canada’s provinces, not a Gatineau sample. It asked non-shoppers to select their reasons; it did not isolate checkout software or test any particular business. This is a self-reported barrier, not a failure rate per transaction or a prediction of lost sales. It is a reminder to test more than the polished success screen.

Write a short test record before touching the site: what the shopper tried, the amount and delivery choice they expected, the payment result, the order state, the messages sent, and what staff should do next. Use test products and fictional customer details. If a payment provider offers a sandbox, use its documented test methods; do not experiment with real card details or place live orders just to create a failure.

Agree on what an order means

Ask the owner and whoever fulfils orders to define the states in plain language. Is an order merely submitted, awaiting payment, paid, ready for pickup, or cancelled? Which state allows staff to reserve stock, send a confirmation, or ship? What happens when payment succeeds but the shopper closes the tab before seeing the thank-you page?

The answer depends on your platform and payment method. For example, Stripe’s Checkout fulfilment guidance says a return to the success page is an unreliable trigger for fulfilment; the integration should process payment events server-side and account for delayed payment outcomes. That is Stripe-specific implementation guidance, but the owner-level question applies across providers: what trustworthy event changes the order state, and can staff see it? Ask your developer or platform vendor to demonstrate the answer with a test order.

Make one person responsible for reconciling exceptions. An email receipt, a payment record, and an order in the shop dashboard may arrive at different times. Staff need a clear rule for which record to check before sending goods or telling a customer the purchase failed.

Walk through the ordinary purchase first

Choose a simple item and a realistic delivery or pickup address. On a phone and a desktop browser, start from the page a customer would actually find. Check that the description, availability, quantity, delivery options, tax treatment, total, and next action remain understandable from product page through payment. If the final amount changes, the reason should be visible before the customer commits.

Finish the test with the provider’s approved success scenario. Confirm that the site gives the customer a clear result, the order record has the correct items and amount, staff receive what they need, and the customer gets the promised confirmation. Follow the order into the fulfilment queue rather than stopping at the thank-you screen. If the business offers pickup, test the instructions a real customer would use to collect the order. If it ships, test the address and delivery handoff.

Then repeat with a different quantity, an out-of-area address, and a pickup choice if those options exist. You are looking for mismatches between the public promise and the actual staff process. Our delivery and returns guide covers what the business should publish about those options; this test checks whether the working checkout follows that published policy.

Deliberately make payment and forms fail

Use the payment provider’s sandbox to try its documented decline and authentication scenarios. Stripe’s testing documentation is one example: it provides test values for successful payments, declines, and additional authentication without moving funds. Another provider may use different test tools, so follow the provider actually connected to your checkout.

After a decline, check that the shopper sees a useful next step and can try another approved payment method without losing the order details. Do not tell them “order confirmed” while payment is unresolved. If a payment is still pending, give an honest status and a contact path; do not imply a failed payment is final until the provider’s status supports it. Test refreshing the page, returning from the payment provider, and pressing the submit button again. Have the implementer show how duplicate submissions and repeated provider events avoid creating a second charge or fulfilment request.

Break the form too: leave a required address field empty, enter an invalid postal code, and remove an item that has become unavailable. The error should name the problem and show how to fix it without clearing unrelated fields. W3C’s form notification guidance calls for clear error and success feedback, including messages associated with the relevant fields. Test by keyboard and with a screen reader as well as by tapping the phone screen. A red border alone does not tell everyone what happened.

Finally, interrupt the journey. Close the browser after payment, lose connectivity before the final page, and let a session expire if the platform supports it. The business should be able to look up the resulting order and payment states and give a consistent answer. Do not ask a customer to retry an uncertain payment before staff check the provider record.

Check what staff will actually receive

A checkout can collect money while leaving the team unable to act. Open the order in the same system staff use day to day. Can they distinguish a paid order from an abandoned cart or pending payment? Do they have the right pickup or shipping details without needing sensitive card data? Is there a way to correct a wrong address, cancel an order, and record a refund under the business’s policy?

Test notification failures rather than treating email as the source of truth. If the owner misses an email, the dashboard or queue should still show the order. If two staff members open the same request, they should be able to see whether it is already being handled. Reconcile a test order against the provider’s payment record and the business’s order record. Record any manual step that must happen daily; a system is only usable when someone owns that step.

Keep support instructions close to the checkout. A customer who sees a confusing status should know how to ask for help and what order reference to provide, without sending card details by email. State realistic response hours, especially for an unstaffed shop. A fallback phone or contact route is useful when the checkout itself is unavailable.

Set a launch decision and a routine for later

Before going live, assign an owner to each failed test and repeat it after the fix. Keep the test cases, expected results, and screenshots of your own test environment as a handover record. Recheck after material changes to payment settings, tax rules, delivery areas, themes, plug-ins, or order emails. A test that passed last month does not prove today’s configuration works.

For a small catalogue and low order volume, an established hosted checkout may be easier to maintain than a custom payment flow. Compare the platform’s recurring cost, supported payment methods, export options, staff workflow, and who handles updates. If the business cannot yet explain its order states or fulfilment rules, settle those decisions before commissioning custom development. There is no benefit in adding complexity that nobody can monitor.

A professional can help turn the test record into platform configuration, accessible error states, reliable payment-event handling, and a staff handoff that matches the published offer. Red Comet discusses website design and development for businesses planning an online customer journey. Bring your real order and exception cases to that conversation; the goal is a purchase path your customers can understand and your team can operate.

Sources

• Financial Consumer Agency of Canada, National Financial Literacy Strategy Finding details: online ordering difficulty, modified June 26, 2026; finding from Statistics Canada’s 2022 Canadian Internet Use Survey, collected December 2022 to April 2023.
• Stripe, Fulfil orders, current platform guidance on Checkout payment events and fulfilment.
• Stripe, Testing, current sandbox and payment test guidance.
• W3C Web Accessibility Initiative, User Notification, guidance on form success and error feedback.