Checkout is one of the harder flows to test in a browser. The card fields sit in a frame your page doesn't control, and a confirmation page doesn't tell you whether your webhook handler did its job. Totals, discounts and tax also depend on test data that has to stay stable between runs.
This guide covers what Zerocheck can check in a Stripe checkout, what to set up first, and what to leave to your integration tests.
Make the release checklist specific
A useful success item is: buy Pro with a public Stripe test card and confirm the account shows Pro. A decline item is: use a fresh account and a declined test card, confirm the error, then confirm paid access was not granted. Include the exact visible outcome for your app. These are checklist examples to adapt.
Set up your test data first
Use Stripe's test mode, a test customer and the public cards listed in Stripe's testing documentation. Give each run a fresh identity, and keep products and prices fixed so the expected total doesn't change between runs.
Testing Stripe checkout with a QA agent
A QA agent removes the selector work, not the test-mode discipline. You describe the purchase in plain English; Zerocheck works out each step from the live page and records a screenshot and a result per step. Zerocheck supports embedded checkout, including Stripe's card fields, with no extra configuration. During setup, we run your purchase and decline flows with you in test mode, on your own app, so you can see the results for yourself. The tests are readable YAML: save and run them in the web app, or keep a copy in your repository and run it with the CLI.
The illustrative example below is the release checklist item "a new patient can request a certificate and pay" for a telehealth service, written for staging with Stripe's public test card and a fresh identity on every run. The final step names the app's own confirmation label:
# zerocheck.yaml
project: your-project-id
default_environment: staging
environments:
staging:
url: https://staging.example.com/request/medical-certificate
# zerocheck/tests/certificate-purchase.yaml
version: zerocheck/v1
name: New patient requests a certificate and pays
description: Staging only. Public Stripe test card. Fresh identity on every run.
steps:
- Navigate to {{app_url}}
- Verify text "Medical Certificate Request" is visible
- Click "Sick Leave"
- Click "Work"
- Click "Continue"
- Click "Common cold or flu"
- Click "Continue"
- Verify text "Leave Details" is visible
- Click "Continue"
- Enter "Automated test request with fictional data." into "Share a few details"
- Click "Continue"
- Enter "{{unique_email}}" into "Email"
- Enter "Zerocheck" into "First Name"
- Enter "Test" into "Last Name"
- Enter "01/01/1990" into "Date of Birth"
- Enter "0491570006" into "Mobile Number"
- Click "Continue"
- Enter "1" into "Street Number"
- Enter "Test Street" into "Street Name"
- Enter "Sydney" into "City/Suburb"
- Select "New South Wales" from "State/Territory"
- Enter "2000" into "Postal Code"
- Click "Continue"
- Verify text "Review Your Details" is visible
- Click "Continue"
- Verify text "Payment" is visible
- Verify text "Test Mode" is visible
- Enter "4242424242424242" into "Card number"
- Enter "12 / 34" into "Expiration"
- Enter "123" into "CVC"
- Enter "Zerocheck Test" into "Cardholder name"
- Click "Subscribe"
- Verify text "Request submitted" is visible
What the test shows, and what it doesn't
Every step gets a screenshot, and the test finishes passed, failed, flaky (passed after a transient retry) or incomplete. If a control on your own pages moves, the run records its old and new target. With the CLI, a blocking failure exits non-zero, and your CI policy decides what that stops.
Provider processing, 3D Secure challenges, webhooks and settlement stay outside the browser test, so keep them in your integration tests. Both the hosted browser and the CLI can meet bot protection, so if your checkout has a captcha, use the captcha provider's test keys or disable it in staging.
What a browser test proves about a payment
A browser test proves what the customer saw: the total before paying and the confirmation afterward. It doesn't prove that money moved, that a webhook was handled or that your ledger updated. Keep those checks in integration tests that read your own database or Stripe's API in test mode.
Test mode catches integration mistakes such as a wrong amount, a broken success redirect or an unhandled decline. It doesn't reproduce a real bank or your production fraud rules, so treat a passing run as one input to the release decision.
That boundary is also how to split the work. Cart and summary tests don't need a payment at all: add an item, change a quantity, check the visible subtotal. They're quick and cover the part of checkout that changes most often. In Zerocheck they're a good first test, because the expected outcome is a specific total. Add the complete purchase and decline flows once your test data is stable.
Hosted browser or CLI
Web-authored tests run in Zerocheck's hosted browser. The optional CLI runs on your machine or a CI runner. A pass in one doesn't guarantee a pass in the other, so try the one you plan to use. We'll do that with you during setup.
Common mistakes
- Don't run a live-mode purchase as a casual smoke test. Use test mode, a test customer and Stripe's test cards.
- Don't treat a visible success message as proof of settlement or of webhook handling.
- Don't mock Stripe in end-to-end tests. Mock the SDK in unit tests; use test mode here.