Automated Checkout Tests on Shopify: Where to Run Them and How

Checkout is the page a store can least afford to break and the one teams test least, because testing it seems to mean placing real orders. Teams that try to automate it run into captchas, real charges and test orders mixed in with real ones. Most of that goes away once you decide where each kind of test runs.

Two stores, two kinds of test

A separate test store for full checkout runs. Use a development store or a copy of your live store with the same theme, apps and checkout settings. Here the tests place complete orders, including payment.

The live store for smoke tests only. On production, tests check that pages load, products can be added to the cart and checkout opens. They stop before payment. Nothing gets charged, and your reports stay clean.

Keep the two stores in step. Install the same apps and checkout extensions on both, and deploy theme changes to the test store first.

Paying without paying

Shopify gives you two ways to simulate payment, both described in its help centre:

• The Test payment gateway. Turn it on under Settings > Payments. While it's active, every order is a test order. Card number 1 approves, 2 declines and 3 simulates a gateway failure; use any future expiry date and any three-digit CVV. The order total has to be more than the equivalent of US$1.
• Test mode on a payment provider. Some providers can be switched to test mode from the Shopify admin. Otherwise, connect the provider's test credentials on the test store, if it offers them.

Shopify warns that customers can't place live orders while your payment providers are in test mode. That is the main reason full checkout tests belong on a separate store.

For COD, set up the same manual payment method and rules on the test store, so the tests can check when COD is offered and when it's hidden.

Bot protection

Shopify's checkout bot protection is available only on Shopify Plus. It runs as a scheduled event of up to 60 minutes, usually for a product drop, and challenges suspected bots with reCAPTCHA or hCaptcha. Don't schedule automated checkout runs against the live store during one of these events, and don't try to get a test past the challenge. Tests on the separate store never meet it.

Flows worth covering

For an Indian D2C store, start with these:

1. Add each kind of product to the cart: a simple product, a variant and a bundle if you sell them.
2. Apply a discount code, an automatic discount and an expired code.
3. Check shipping rates and delivery estimates for a metro pincode and a remote one.
4. Check COD availability rules, including pincodes where COD should be hidden.
5. Complete a prepaid order with the test gateway.
6. Fail a payment and confirm the customer can try again.
7. Try to buy something that has just sold out.
8. Confirm checkout extensions render, such as a gift note or GSTIN field.
9. Confirm the order arrives with the right tags, notes and attributes for fulfilment.
10. Confirm the purchase event reaches your analytics once, not twice.

Run the full set on the test store before every theme or app release, and the smoke tests on the live store every few hours.

Keep the suite honest

Use stable selectors such as data attributes and accessible names, not long CSS paths. Mark known flaky tests and fix them within the week. If you use AI tools to write or repair tests, review every change to an assertion. Our post on Playwright test agents explains why.

Our QA automation practice sets this up as a three-week starter that covers 50 critical flows in Playwright and wires them into your CI. AutoGherk turns the specs behind each flow into test scenarios linked to their tickets.