Why Shopify checkouts need automated testing
Shopify runs the checkout itself, and that part is rarely the problem. What breaks a checkout is usually something layered on top of it:
- A theme update hides or restyles the Add to cart or Checkout button
- A newly installed app adds a script that throws an error on the cart page
- A checkout extension or a discount from Shopify Functions misbehaves for certain carts, quantities or destinations
- An app you forgot about updates itself and conflicts with another app
- A shipping-rate app or carrier integration stops returning rates for some addresses
None of these take the store down. The home page loads, product pages render, and an uptime monitor stays green. You find out when someone looks at conversion data, or when a customer emails.
Automated checkout testing replays the steps a shopper takes on your real store, on a schedule, and tells you which step stopped working.
Four kinds of checkout checks
"Will it place real orders?" is the first question, and the answer depends on how far you want a test to go. There are four distinct approaches. They prove different things and have different side effects, so it helps to keep them separate.
1. Pre-payment flow checks
What it is: the test goes from product page to cart to checkout, fills in contact and shipping details with made-up data, picks a shipping method, and stops at the payment step without submitting anything.
What it proves: the parts of the flow that break most often after theme and app changes are working: products can be added, the cart shows the right items and totals, a discount code applies, shipping rates load for the address you used, and the payment section appears.
Prerequisites: a published product that's in stock, and test data that looks like a real address in a region you ship to.
Side effects: none in your order list. Shopify may record an abandoned checkout for the test's email address, so use an address on a domain you control.
Limitations: reaching the payment step doesn't verify that a payment would be accepted. It says nothing about your payment provider, card authorisation or 3D Secure. Express buttons such as Shop Pay, Apple Pay and Google Pay can be checked for presence, but not completed.
This is what most scheduled checks should be, and it's what Tracefox tests do by default.
2. Zero-total order checks
What it is: the test applies a discount that brings the whole order to zero and then completes checkout, so the order confirmation page is part of the check.
What it proves: the submit step and the order confirmation page work, and the order is created.
Prerequisites: the total has to be zero after everything, not just the products. On Shopify, percentage and fixed-amount discounts apply to products, not shipping, and an order can't go below zero (Shopify Help: percentage and fixed amount discounts). To reach zero you also need free shipping, either a free shipping rate for the test address or a free shipping discount set to combine with the product discount (discount combinations). Taxes are calculated on the discounted amount (Shopify Help: discounts), so a zero subtotal should mean zero tax, but check the final total in your store, including any duties.
When the total is zero, checkout normally asks for no payment details. Shopify's documentation doesn't spell this out, so confirm it on your own store before relying on it.
Side effects: this is a real order. It appears in your admin and reports, takes stock from available inventory (inventory states), triggers order notifications, and can reach fulfillment apps, ERPs and analytics. Before scheduling it, turn off automatic fulfillment for the test product or route it to a manual location, and plan to cancel and archive each test order (canceling and deleting orders). Protect the discount code: anyone who finds it gets free products.
Limitations: because no payment is taken, a zero-total order doesn't test your payment provider at all.
3. Sandbox payment tests
What it is: a test order paid with a test card, using either Shopify's Test payment gateway (card number 1 approves, 2 declines, 3 returns a gateway error) or Shopify Payments test mode with its published test cards (Test payment gateway, testing Shopify Payments).
What it proves: that checkout accepts a card payment from the provider's sandbox, and how your store handles approvals and declines.
Prerequisites: a paid Shopify plan. To activate the Test payment gateway you first deactivate your real card provider, and the purchase must be above the equivalent of 1 USD.
The important part: what happens to real customers. While the Test payment gateway or Shopify Payments test mode is on, your store can't take real card payments. Shopify says no real payments are captured in test mode, that orders paid through Apple Pay or Google Pay during that time can go through without anyone being charged, and that test mode shouldn't be turned on in a store that's in production (testing Shopify Payments). So don't run sandbox payment tests on your live store during trading hours, and never on a schedule there. Use a development store, a copy of your store, or a short maintenance window.
Third-party gateways behave differently again: orders placed through a third-party provider in test mode are not treated as test orders and can't be deleted afterwards (canceling orders).
Side effects: test orders still send notifications and can trigger fulfillment, so use @example.com addresses and turn off auto-fulfillment first (processing a test order). Shipping labels you buy for test orders are charged.
Limitations: a successful test-card payment shows the sandbox works. It doesn't show that real cards will be authorised by customers' banks, and Shopify doesn't document 3D Secure test cards for Shopify Payments test mode.
4. Controlled live transactions
What it is: a real order with a real card, cancelled and refunded straight away. Shopify lists this as one of its three ways to test checkout (placing a test order).
What it proves: the live payment path end to end, including your real provider. It's also the only way to test manual payment methods such as cash on delivery.
Side effects: everything a real order does, plus cost: card processing fees aren't returned when you refund (refunds), and the refund can take days to reach the card.
Limitations: it's one card, one bank and one moment. Do it by hand after payment changes, not as an automated schedule.
What to put in a scheduled test
A good scheduled test follows the real buying path for your most important product and stops before payment:
- Open the product page of a top-selling, always-in-stock product
- Choose a variant if the product has one
- Add to cart and check the cart shows the item
- Go to checkout
- Enter contact and shipping details (made-up name, an address in a region you ship to, an email on your own domain)
- Check that shipping methods load and pick one
- Apply a discount code and check the order summary shows it, if discounts matter to you
- Check that the payment section appears, then stop
Then add variations as separate tests: a mobile-sized viewport, an international address, a second product type, or a logged-in customer if your store requires accounts.
How often to run it
A failure is found on the next run, so the schedule sets how long a breakage can go unnoticed: up to a week on weekly, a day on daily, an hour on hourly. Busier stores lose more per hour of broken checkout, so they usually justify a tighter schedule.
Whatever the schedule, also run the test by hand right after:
- Installing or updating an app
- Publishing a theme change
- Changing payment, shipping or tax settings
- Changing a checkout extension or a discount function
Setting it up with Tracefox
- Create the test. Enter your store URL and Tracefox generates a test that adds a product to the cart and checks that checkout opens. You can extend it with steps for the shipping form and discount codes, add steps by hand, or record the flow with the Chrome extension on Pro and Business.
- Choose a viewport for the test: desktop, or mobile or tablet on Pro and Business. Each test runs on one viewport; make a second test for another.
- Run it once by hand and check the screenshot of each step.
- Set a schedule within your plan: weekly, daily or hourly.
- Set up alerts: email on every plan, Slack on Pro and Business, webhooks on Business.
Tests run in Chromium. When a step fails, you get the name of the step, the error, a screenshot of each step, and a video of the run. Scheduled failures are re-run once before you're alerted, to rule out a one-off blip. Runs come from a monthly allowance shared by all tests in your workspace; see pricing for current plans and allowances.
What Tracefox doesn't do: it doesn't run Safari or real phones (check Apple Pay and Safari on a device), it doesn't handle 3D Secure, and it checks only the steps in your tests.
More detail: How Tracefox works · Automated checkout testing · Shopify checkout monitoring.
If you build this yourself
You can write the same checks with Playwright or Cypress. The usual problems:
- Selectors break when the theme changes, and someone has to update the code.
- Real orders pile up if a test completes checkout without the discount, shipping and fulfillment setup described above.
- Flaky failures (a slow page, a popup) cause false alerts, and people start ignoring them. Re-running a failure once before alerting helps.
The bottom line
Schedule pre-payment flow checks for the steps that break most often. Add a zero-total order check only if you need the confirmation step covered and have set up the discount, shipping and fulfillment rules for it. Keep sandbox payment tests and live transactions for development stores and for one-off checks after payment changes, done by hand.
Shopify details checked against the Shopify Help Center on 17 October 2026. Shopify changes its checkout and payment settings regularly, so check the linked pages before you change a live store.
Ready to set up a check? Start Tracefox free or read the automated checkout testing overview.