How to test a Magento 2 checkout, step by step

What a checkout test proves

A checkout test shows that a customer can go from a product page to a confirmed order, with the right price, the right shipping and a payment that actually captures. It answers a different question from uptime monitoring: the site can answer every page and still be unsellable — in our failure data, 77% of broken checkouts happened while the homepage loaded normally.

A manual test is the most realistic check you can run. It is also the one that happens least often, because it needs a person. That is what the automation step at the end fixes.

The ten-step manual test

Run the steps in this order; a failure early makes the later ones meaningless, so stop at the first broken step and keep a screenshot or a note of where it stopped.

1. Open a product page as a guest and confirm price, stock and add-to-cart. 2. Add the product and check the cart line: same product, same price, usable quantity. 3. Fill a realistic address for a country you sell to. 4. Confirm the shipping methods appear and the cheapest one is selectable. 5. Confirm the totals: subtotal, shipping, tax. 6. Select a payment method and confirm the payment form loads — a blank card form is a failure, not a slow page. 7. Place the order. 8. Confirm the order in the admin with the right total and status. 9. Confirm the confirmation email arrives. 10. Cancel or refund the order and confirm stock returns.

Steps 7 to 10 are where cheap checks stop. A page-level monitor never places the order, so it cannot see a pending-payment trap or an order email that never sends — two of the most common silent failures we record. Related: orders stuck in pending payment and payment notifications.

Set up a test product and a payment method

You need two things before step one. A test product that is always in stock, cheap, and excluded from feeds and sitemaps — a hidden simple product works. And a payment method you can use repeatedly without moving real money: a sandbox mode of your live gateway, an offline method, or a small-value method you refund immediately.

Check that the test product is visible to the customer group you are testing, guest or logged in. A test product only admins can see produces the failure code PRODUCT_NOT_FOUND on every run and teaches you nothing. The full list is in the failure codes guide.

Keep it healthy: before a launch and after releases

Run the ten steps before every launch, theme change and Magento patch, and after every extension install. The usual suspects are a checkout theme that drops a step, a shipping or payment module that stops loading, and a cache or indexer left in a bad state after deployment. Upgrading Magento 2.4 without breaking checkout covers the release side; a slow checkout is a broken checkout covers timing.

For Luma, Hyvä and one-step checkouts the steps are the same. What changes between themes is the selector and the moment the payment form appears — which is why a script written for one theme breaks on another.

Automate the part that repeats

A person can run the ten steps weekly. A scheduled check runs them every 5 to 30 minutes, from outside the store, and tells you which step failed with a screenshot and a network log. MageSentinel ships this flow for Magento 2 — Luma, Hyvä and one-step checkouts — and on plans with test orders it places a real order, confirms it in the admin and cancels it.

Solo is €7.90 a month for one store, Starter €39 for five, Agency €149 for twenty, checks every 30 minutes (every 15 on Agency, every 5 on Scale), with a 14-day free trial and no card. Start with the free Magento checkout test: it runs the steps once on your store and shows where it stops. More on the tool side: Magento checkout monitoring.