How do you plan store regression tests in Playwright: cart, session, payment and order status after a failure?

Sources checked on 10 November 2026 against the Playwright and Stripe documentation.

This guide is for a CTO, team lead or the person responsible for the quality of an online store who wants every release to check the purchase path automatically. It does not compare tools and does not cover mobile app tests. It describes which store scenarios are worth a regression suite and how to set them up in Playwright.

In short: start with the five areas where a failure costs sales or creates a wrong order. In CI, test payments on simulated provider responses, and check the provider's payment screen by hand in the sandbox. End every scenario by checking the order state on the server. The thank-you page only shows that the browser reached the return address, not that the payment was recorded.

A regression plan is not a list of every possible test but the set that must pass before every release. In a store, what matters most is the path from product to paid order and how it behaves when something fails.

The table shows the minimum scope. Each row is several tests, not one long scenario from the home page to the confirmation.

Payment regression only runs on a test environment with the payment provider's test-mode keys. Do not run tests on production that pay with a real card or create real orders.

Playwright creates a separate browser context for each test, so each test has its own cookies and local storage. Use that: a test should not depend on a cart left behind by a previous one. See Playwright browser contexts.

You can sign in once in a setup project and save the session state to a file. The Playwright documentation recommends adding the directory with that file to .gitignore and discourages keeping it in a repository. When tests change server-side state, such as a signed-in customer's cart, the documentation suggests one account per parallel worker. See Playwright authentication.

• Test products: a few products with known price and stock, including one with low stock and one with variants.
• Test accounts: one account per parallel worker if tests change a signed-in customer's cart.
• Own stock and catalogue data: a test that changes a price or stock level uses products no other test touches.
• Server-side reset: every attempt, retries included, creates or clears the cart and the data it needs through the API before it starts. A separate browser context and a separate account do not isolate data shared on the server.
• Test keys: only in CI environment variables, never in test code.
• Data clean-up: mark test orders so they can be filtered out of reports.

Cart tests check that what the customer sees matches what the server recorded. After every action, compare the total on the page with the cart API response, not only with the text on screen.

Session tests check transitions between states: guest, signed-in customer, expired session. Typical defects are the cart disappearing after sign-in, items duplicating when the guest cart is merged with the account cart, and delivery details lost after the session expires.

1. Add and change quantity: total, discount and shipping cost match the server.
2. Price or stock change mid-way: change the price or zero the stock via the API and check the message in the cart and at payment.
3. Page refresh: the cart survives a reload and closing the tab.
4. Sign-in during checkout: the guest cart merges with the account cart without duplicate items.
5. Expired session: after the session expires, the customer returns to the cart with a clear message, not to an empty page.

Stripe says that interfaces such as Stripe Checkout and the Payment Element have security measures that prevent automated testing, and recommends simulating responses with mock data to test your application's behaviour. See Stripe automated testing. So in CI, Playwright tests your application on simulated provider responses: success, decline, 3D Secure required and the gateway return. It does not automate the provider's payment screen.

Check the provider's screen by hand in the sandbox, especially after payment changes. That is what test data is for. Stripe example: card 4242 4242 4242 4242 succeeds, 4000 0000 0000 0002 returns a generic decline, 4000 0000 0000 9995 a decline for insufficient funds, and 4000 0027 6000 3184 always requires 3D Secure authentication. See Stripe test cards. Other providers have their own test modes and data, so check your provider's documentation.

Stripe notes that card state from one test can affect later tests that use the same card, so in manual checks use a separate card for each independent scenario. A separate, infrequent API contract check can use the sandbox, within its rate limits.

For each payment result, write down the expected customer message and the expected payment state in the store. The test checks both.

The most often skipped scenario is a payment that succeeded while the browser never came back to the store. Stripe says plainly that you cannot rely on fulfilment from the landing page only, because a customer can pay and lose their connection before that page loads. Fulfilment requires webhooks. See Stripe order fulfilment.

In Playwright you simulate this with request interception. page.route with route.abort lets you stop the return page from loading, and route.fulfill lets you substitute a response. Then deliver the payment confirmation as a simulated provider event and check through the API or admin panel that the order is still marked as paid. See Playwright network handling.

Stripe also notes that the same webhook may arrive more than once and that event order is not guaranteed. See Stripe webhooks. Test a repeated event with a redelivery in the sandbox, or in an integration test with a correctly signed test event. The assertion is about one business effect: one order, one payment and one reservation.

Add two ordering scenarios as well. In the first, the browser returns before the webhook: the return page shows a pending state, and the order becomes paid only once the payment is confirmed. In the second, an older event arrives after a newer one and does not roll the order state back. For payment methods with a delayed result, only the event carrying the final result sets the paid state, for example checkout.session.async_payment_succeeded in Stripe Checkout.

This area turns business rules into tests. Before you write a test, the team must agree what status the order should have in each case. If the rule does not exist, the test will reveal that, but it should not invent the rule.

The table shows an example rule. Your platform may use different status names; what matters is that each row has one expected result.

By default Playwright does not retry failing tests. With retries enabled, a test that fails first and then passes is marked as flaky. See Playwright test retries.

The Playwright documentation recommends setting trace to on-first-retry in CI. The trace then records the first retry of a failed test, not the first attempt. The retry may pass, in which case the trace shows a passing run; compare it with the log and screenshot from the first attempt. See the Playwright trace viewer.

Treat a flaky payment test as a signal, not noise. It often means a race between the customer's return and the webhook, which is exactly the defect that can reach production.

• On every pull request: a short cart suite and one successful payment on a simulated provider response.
• Before release: the full plan with declines, 3D Secure, gateway return and statuses after failures, on simulated responses; after payment changes, also a manual check of the provider's screen in the sandbox.
• After release: monitor the purchase path in production, without test payments on production keys.

The plan covers the browser purchase path. It does not replace unit tests of pricing and discount logic, performance tests before a sales peak, or mobile app tests, which need other tools.

Pre-release regression does not replace watching production either. We cover how to measure the purchase path during peaks in the guide on commerce observability during sales peaks.