# Zerocheck: offering, pricing and documentation

Updated: 2026-09-22. CLI reference version: 0.1.9.

# A QA agent for the customer flows you need to trust

Zerocheck is a QA agent for web apps. Describe what a customer should do and what should happen, or import your release checklist; Zerocheck's browser agent drafts the steps, runs them against your web app, and shows you the result with evidence for every step. Review and save tests in the web app, then rerun them before a release or use the optional CLI in your development workflow.

## “We are shipping faster than we can test by hand.”

Coding agents write more code than your team can check by hand. Selector-based test suites break on the first refactor, and each flaky failure sends an engineer to triage instead of shipping value to your customers. Someone still needs to check that customers can sign in, find a product, update a setting or complete the part of a purchase your test covers. Repeating that checklist takes time, and investigating unreliable test failures takes attention away from customers.

Start with the flows you already check before shipping. Give each one a specific expected outcome, keep the tests you need, and inspect what happened when they ran. You can add coverage one flow at a time.

## From a manual check to a test you can rerun

1. **Describe the flow.** Add a test in the web app or paste a checklist. Include the expected result and the setup or test data it needs.
2. **Run and review.** The agent drafts readable steps and runs them in a hosted browser. Inspect the steps and the result; answer any missing details.
3. **Save the test.** Keep it in Your tests, edit it when your product's expected behavior changes, and run it against a chosen environment.
4. **Use it in your release workflow.** Run from the web app, download individual tests as YAML, or use repository tests with the CLI and GitHub Actions.

Hosted runs from the web app need no installation in your codebase. The CLI is useful for localhost, private networks your machine can reach, and CI. Both use the same test format and browser agent.

## “Can I see what actually happened?”

Open a run to see the exact test revision, the result of each step, before-and-after screenshots, error details and every attempt. Console warnings and errors help you investigate. A recording is available when the test uses no configured credentials.

A failed expected outcome, a missing credential and an interaction the agent could not complete are different results. Zerocheck shows the distinction so you can decide whether to fix your app, your setup or the test description. A test failure alone does not establish the cause of a bug.

## “How much of this relies on AI?”

AI drafts tests and uses the page's current state to interpret interactions and expected outcomes that need judgment. Supported explicit text, URL and network assertions use direct browser evidence. The test records how each step was resolved, so you can inspect the basis for a result.

Your team defines what success means. For important amounts, labels and destinations, write a specific assertion your reviewer can read and verify.

## “What happens when our UI changes?”

When a control moves, Zerocheck can find it again from the step's description. It records the old target, the new target and the reason. A heal is saved only after the complete unchanged test passes with independent evidence that the intended interaction and outcome were preserved.

Changes to the meaning of a control or the expected product behavior still need a test edit you review. If a transient AI-service error is retried and the test then passes, that result is labeled flaky. Assertion failures are never retried into a pass.

## Where Zerocheck fits

Zerocheck is for teams shipping a web product who have customer flows to verify and an engineer who can define expected outcomes and test accounts. It works especially well as a starting point when the release checklist still lives in a document or in someone's head.

Tests run in Chromium. Authenticated flows need configured login steps and credentials. Local runs still use Zerocheck's AI service and upload results and artifacts. Read the [supported flows](https://tryzerocheck.com/docs/limits/) and [data handling](https://tryzerocheck.com/docs/security/) before choosing your evaluation flows.

## Try it on your own release checklist

Start on the free tier: US$0, about 200 test runs a month, no credit card. Access is provisioned on a short onboarding call where we get your first tests running. If you continue, the Pilot is US$500 per month for one project on a dedicated instance; we agree your team's run cadence and usage at the start.

[Try Zerocheck on your app](https://tryzerocheck.com/onboarding/) · [Read the pricing](https://tryzerocheck.com/pricing/) · [Create your first test](https://tryzerocheck.com/docs/web-app/)

---
Canonical: https://tryzerocheck.com/product/
Updated: 2026-09-22


# Zerocheck pricing

Free tier with no credit card. Access is provisioned on an onboarding call.

## Free

Price: US$0 forever.

For one team that wants its first release checks running on its own app.

- About 200 test runs a month
- All core features: web app, CLI, GitHub Actions and MCP
- Results and screenshots for every run
- No credit card required
- Onboarding call required: we set up your project and first tests together

[Try for free](https://tryzerocheck.com/onboarding/)

## Pilot

Price: US$500 per month.

For one team that runs its release checklist on every release.

- About 1,000 test runs a month; more by agreement
- One project on a dedicated instance
- Unlimited seats
- Hands-on import of your release checklist in week one
- Month to month, cancel any time

[Get started](https://tryzerocheck.com/onboarding/)

## Enterprise

Price: Custom.

For organizations with procurement, security, or multi-team needs.

- Everything in Pilot
- Dedicated instance and region
- Invoicing and purchase orders
- Onboarding for multiple teams
- Priority support

[Contact sales](https://tryzerocheck.com/demo/)

## Questions about pricing

### How does the free tier work?

Book a short onboarding call. We set up your project and your first tests together on the call, then you save and rerun them yourself from the web app, the CLI or GitHub Actions. Free stays free within about 200 test runs a month; we tell you before you reach the allowance.

### Why does the free tier need an onboarding call?

Access is provisioned by hand while we onboard the first customers, and the call gets your first checklist item running on your own app faster than reading docs. There is no instant self-serve signup yet.

### What counts as a test run?

One execution of one test in a browser, whether it starts from the web app, the CLI or GitHub Actions. Verification runs during checklist import count too.

### How is pilot usage agreed?

We agree the scope of your team's release checklist, run cadence and any schedules during onboarding. The Pilot is a monthly service on a dedicated instance, not a per-run credit plan.

### What happens after the first month?

The Pilot continues month to month and you can cancel at any time. Your tests are plain YAML you can export.

### Can I pay by invoice?

Yes, on the Enterprise plan. Contact sales.

### Where does my data go?

Selected YAML, the page context needed for AI, and run results and artifacts go to your Zerocheck instance. Only the test secrets your config references are read. The docs describe exactly what leaves your machine.

No per-seat charges describes the pricing model; the current instance does not provide separate user accounts or SSO.

Canonical: https://tryzerocheck.com/pricing/
Updated: 2026-09-22


# Create your first test in the web app

Describe one customer flow, run it in a hosted browser, inspect the result and save it for your next release. You can author and run tests in Zerocheck without installing a dependency or connecting a repository.

## Before you start

You need access to a provisioned Zerocheck instance, a web app URL the hosted browser can reach, and an expected outcome for your first test. The [free tier](https://tryzerocheck.com/onboarding/) includes an onboarding call. Localhost requires the [local CLI runner](https://tryzerocheck.com/docs/cli/).

Choose a simple flow with existing test data. For example: open your app, search for a known product, and verify that its name appears in the results. If it needs login, configure reusable login steps and credential references with your instance owner first.

## 1. Choose your environment

In **Settings**, configure your project and its environment URL. The available environments are **dev**, **staging** and **production**. Use a test environment and test accounts for your first flow.

The environment supplies the starting URL, optional login steps and credential references. These are reused when the test runs; you do not need to paste a password into the test description.

## 2. Add a test

Open **Add a test** and enter:

- **Test name:** a short label, such as “Search finds a product”.
- **What should the user do?** The actions, page, controls and data that matter.
- **Expected outcome:** the visible result or state that must be true.
- **Setup or test data:** any necessary existing fixture or account information.
- **Environment:** where to run this draft.

Select **Draft and run test**. Zerocheck drafts the browser steps and runs them immediately in the hosted browser. Review happens after this first execution, so use an environment in which those actions are appropriate.

## 3. Inspect the result

Read the drafted steps alongside the browser result. Confirm that the actions and expected outcome match your intent. Use **Edit steps** to correct a draft, then run it again.

If the draft needs an account, a route or an expected outcome you have not supplied, answer the missing details and rerun. If it failed, inspect the failing step and its screenshots. See [result states](https://tryzerocheck.com/docs/results/) for the distinction between a failed outcome and a test that could not run.

## 4. Save and rerun

Choose **Save this test** to add it to **Your tests**. You can run one test, selected tests or all saved tests against a chosen environment. Edit the name and steps when your intended behavior changes, then run the new revision.

You can save a failing test to reproduce an issue. Saving it does not change its result to passing. An edited test needs a new run before that revision can have a passing result.

## Take a test into your repository

Use **Download YAML** on an individual saved test. That creates an independent copy for your repository; it does not establish automatic synchronization. Web-created tests are edited in the web app, while repository-managed tests are edited in their files.

[Import several tests at once](https://tryzerocheck.com/docs/checklist/) · [Use the CLI](https://tryzerocheck.com/docs/cli/) · [Understand results](https://tryzerocheck.com/docs/results/)

---
Canonical: https://tryzerocheck.com/docs/web-app/
Updated: 2026-09-22


# Turn your release checklist into browser tests

Paste the tests your team performs before a release. Zerocheck drafts and runs one independent browser test per top-level checklist item, then lets you review the results and save the tests you want to keep.

## Write one flow and outcome per item

A short sentence can be enough when it includes the action and expected result. For a detailed flow, indent its steps beneath the top-level item. Headings and lines starting with `Note:` provide context; they do not become tests.

Here is an example to adapt to your own app and existing test data:

```text
# Release smoke tests
Note: A product named Notebook exists in the test environment.

- Search finds a product
  Open the app.
  Search for "Notebook".
  Verify text "Notebook" is visible.

- The help page is available
  Open /help.
  Verify text "Contact support" is visible.
```

This checklist produces two tests. Each starts independently, so the second test must not depend on state created by the first. Include any setup each flow needs, or configure reusable login steps for the environment.

## Preview, run and review

1. In the web app, choose **Import checklist**.
2. Paste text or upload a `.md` or `.txt` file, up to 64 KB and 200 items.
3. Check the preview to confirm which lines belong to each test.
4. Start the import. Each executable draft runs in the hosted browser.
5. Inspect the steps, result and evidence for each item.

The review states are **Draft · not verified**, **Verified passing**, **Check failed**, **Needs input**, and **Could not run**. A missing credential is something to resolve; it is not proof that your product failed. Unsupported tasks remain visible for your review.

## Keep control of the expected result

Use **Edit steps** when a draft does not express the flow you intended. Supply missing details together, then use **Run drafts again**. Keep the expected outcome specific: a particular total, destination, label or state is more useful than “everything works”.

Choose **Save this test** or save the selected group to **Your tests**. You can retain failing tests to reproduce a known issue; saving does not make them pass. Unfinished imports remain in **Recent drafts**.

## Import from a repository

The [CLI quickstart](https://tryzerocheck.com/docs/cli/) includes browser installation and explicit saving. Running `zerocheck import` drafts and verifies tests; it does not save them into your repository unless you use `--save` or adopt a reviewed draft with `--draft`.

[Create one test instead](https://tryzerocheck.com/docs/web-app/) · [Read the test format](https://tryzerocheck.com/docs/test-format/) · [Inspect results](https://tryzerocheck.com/docs/results/)

---
Canonical: https://tryzerocheck.com/docs/checklist/
Updated: 2026-09-14


# Run browser tests locally with the CLI

The optional Zerocheck CLI runs repository tests on your machine, in CI or in a hosted browser. The web app remains available for authoring and hosted runs with no local installation.

## Prerequisites

- Node.js 20.19 or newer.
- Access to a provisioned Zerocheck instance and project.
- A running target app and any required test accounts or fixtures.

Local browser execution still uses Zerocheck's AI service and uploads results and artifacts. It needs network access and authentication. The local browser can reach localhost and private networks available to your machine; the hosted browser needs a URL reachable from the instance.

## Install and authorize

Run these commands from your app's repository. The examples use CLI version 0.1.9.

```bash
npm install --save-dev --save-exact zerocheck@0.1.9
npx zerocheck login
npx zerocheck init --url http://localhost:3000
npx zerocheck install
```

Replace the URL with your app's address. `login` authorizes the machine. `init` writes `zerocheck.yaml` and creates an empty test directory; it does not create or execute a test. `install` downloads Chromium for local runs.

The same CLI is also published on npm under 13 other command names (e2e-testing, e2e-qa, e2e-agent, agentic-qa, e2e-verify, bugbash, qa-tests, qa-checks, run-qa, agentic-testing, agentic-e2e-testing, browser-qa and web-qa), each pinned to the same version, so `npx e2e-testing run` and `npx zerocheck run` are the same program. The documentation uses `zerocheck`; use whichever name you installed.

For a dedicated instance using a different service address, set `ZEROCHECK_API` to the URL supplied during onboarding before logging in. In CI, use a project API token in `ZEROCHECK_TOKEN`.

## Import, review and save

Create `release-checklist.md` using the [checklist format](https://tryzerocheck.com/docs/checklist/), then run:

```bash
npx zerocheck import release-checklist.md --env dev --runner local
```

Read the output states and the exact drafted YAML. Open Recent drafts in your Zerocheck instance to inspect the imported tests, screenshots and failed steps. Import prints a draft identifier rather than a results URL. Import exits nonzero while any item is not verified passing; the draft remains available for review.

After reviewing, replace `DRAFT_ID` with the identifier from your import and save its drafted tests:

```bash
npx zerocheck import --draft DRAFT_ID
npx zerocheck validate
npx zerocheck run --env dev --runner local
```

Adoption saves the available drafted definitions; it does not make failed tests pass. Check the draft before adopting it, and resolve missing inputs or edit the saved YAML as needed. Do not skip saving: `run` needs tests in the configured test directory.

## Choose where the browser runs

```bash
npx zerocheck run --env staging --runner hosted
```

Configure the selected environment's URL and login steps first. Local and hosted describe browser location; dev, staging and production describe which environment to test. There is no automatic tunnel from a hosted browser to localhost.

## Save reports and inspect a run

```bash
npx zerocheck run --env dev --json .zerocheck/latest-run.json --junit .zerocheck/junit.xml
npx zerocheck results RUN_ID --json
```

The CLI prints test outcomes, failed steps and a results URL. JSON and the web app contain full attempts and artifact links. `--fail-on-flaky` can make a blocking test that passed after a transient retry fail your CI policy.

| Exit code | Meaning |
| --- | --- |
| 0 | Execution completed within the merge policy. |
| 1 | A blocking test failed, or a blocking flaky test failed the `--fail-on-flaky` policy. |
| 2 | Setup, configuration, policy, infrastructure, cancellation or incomplete execution prevented a complete result. |

Use `npx zerocheck doctor --env dev --runner local` to check setup. See [GitHub Actions](https://tryzerocheck.com/docs/github-actions/), [MCP](https://tryzerocheck.com/docs/mcp/) and the [test reference](https://tryzerocheck.com/docs/test-format/).

---
Canonical: https://tryzerocheck.com/docs/cli/
Updated: 2026-09-21


# Run your browser tests on pull requests

Use GitHub Actions to run the tests saved in your repository at the pull request's commit. Zerocheck returns an exit code, writes reports and can update a pull request comment with the results.

## Prepare a saved test suite

Complete the [CLI quickstart](https://tryzerocheck.com/docs/cli/), including review and saving. Configure an environment the CI browser can reach, usually staging, in `zerocheck.yaml`. Add the referenced test credentials and `ZEROCHECK_TOKEN` as secrets in your CI setup.

Generate the starter workflow:

```bash
npx zerocheck init --github-actions
```

Review the generated `.github/workflows/zerocheck.yml` before committing it. It includes pull-request and manual triggers, a pinned CLI install, local browser installation where needed, JSON and JUnit output, result reporting and artifact upload. Environment and runner are explicit choices; ensure the selected URL and credentials are available in your job.

## Read the workflow result

The underlying run and reporting commands are:

```bash
npx zerocheck run --env staging --json .zerocheck/latest-run.json --junit .zerocheck/junit.xml
npx zerocheck report --file .zerocheck/latest-run.json
```

Reporting and artifact upload should run even when the test command fails. The generated workflow handles this with `if: always()`.

With the required GitHub token and pull-request permissions, reporting posts or updates one comment with outcomes, failed steps and links to evidence. The job summary remains available when a comment cannot be posted, including restricted or read-only jobs. Older commit results do not overwrite a newer comment.

## Choose your merge policy

A failed blocking test exits nonzero. To prevent merging on that failure, configure the workflow check as required in your repository's branch protection or ruleset. A PR comment alone does not enforce a merge policy.

Tests default to `blocks_merge: true`. A test with `blocks_merge: false` still shows its failure but does not fail the run's merge policy. Add `--fail-on-flaky` if a blocking test that passed after a transient retry should also fail the workflow.

## Scheduling and browser location

The generated workflow includes a commented schedule you can enable and adapt. Scheduled runs use the environment you configure. Zerocheck reports those test runs; it is not an incident-monitoring or alerting service.

Use the local runner for addresses reachable from your CI runner, or the hosted runner for addresses reachable from the Zerocheck instance. Test selection is explicit by file path; it is not inferred from a code diff.

[Result interpretation](https://tryzerocheck.com/docs/results/) · [Credentials and data](https://tryzerocheck.com/docs/security/) · [GitHub integration overview](https://tryzerocheck.com/integrations/github/)

---
Canonical: https://tryzerocheck.com/docs/github-actions/
Updated: 2026-09-14


# Let your coding agent use Zerocheck

Zerocheck's local MCP server lets a compatible coding agent author tests, import a checklist, run browser tests and inspect results. Your coding agent supplies instructions; Zerocheck runs the saved or selected test and returns its actual outcome.

## Set up the project first

Complete the [CLI setup](https://tryzerocheck.com/docs/cli/): install the pinned CLI, authorize it, configure your environment, and install Chromium if you want local runs. A token is required for both local and hosted execution.

Start the server over stdio:

```bash
npx zerocheck mcp --project-dir /absolute/path/to/your/app
```

This is a local process your MCP client starts, not a public HTTP endpoint on this website. Use your client's stdio server configuration. A generic configuration, using the binary already installed in your project, is:

```json
{
  "mcpServers": {
    "zerocheck": {
      "command": "/absolute/path/to/your/app/node_modules/.bin/zerocheck",
      "args": ["mcp", "--project-dir", "/absolute/path/to/your/app"]
    }
  }
}
```

Replace both paths and supply any required environment variables through your client's supported configuration. Clients can differ in where they store this configuration. Keep project tokens and test secrets out of committed files.

## Set up with your coding agent

After onboarding has provisioned your project, paste this into Claude Code, Cursor or another MCP-capable agent from your app's repository:

```text
Set up Zerocheck in this repository. Run `npm install --save-dev --save-exact zerocheck@0.1.9`, then `npx zerocheck login`, then `npx zerocheck init --url http://localhost:3000` and `npx zerocheck install`. Start the MCP server with `npx zerocheck mcp --project-dir <absolute path to this repository>` and add it to your MCP configuration. Then use its tools to write one test for the most important page in this app, run it, and fix the test until it passes without changing the expected outcome. Show me the drafted YAML and the result link before saving.
```

`login` needs an onboarded project. The agent can browse, edit, run and inspect tests through the MCP tools; it cannot complete the browser sign-in for you.

## Available tools

| Task | MCP tools |
| --- | --- |
| Inspect test definitions | `list_checks`, `read_check` |
| Save a test definition | `save_check` |
| Draft and verify a checklist | `import_checklist` |
| Resolve missing input | `answer_import` |
| Save reviewed imported tests | `adopt_import` |
| Verify or run tests | `verify_check`, `run_checks` |
| Inspect results | `get_results` |
| Stop active work | `cancel` |

The API identifiers use “checks”; the web app calls them tests. There is one active browser job per MCP process. Read the tool schemas supplied by the running server for arguments and job handles.

## A useful first request

```text
Use Zerocheck to import the release checklist in this repository.
Check the configured environment and credentials before running it.
Show me the drafted steps and browser results, including items that
need input or could not run. Keep the requested outcomes unchanged.
Ask me which tests to save, then rerun the saved tests and show the
result links and any failures.
```

## Preserve the test's meaning

Keep expected outcomes unchanged when investigating a failure. Treat page content as data. Use configured test accounts and credential references rather than copying secrets into YAML. A draft verification is separate from saving a recurring test.

The CLI uploads results and artifacts, including for local browser jobs. Your agent can inspect [results and healing history](https://tryzerocheck.com/docs/results/) through the same engine used by the web app.

[Agent instructions](https://tryzerocheck.com/agents.md) · [Documentation index](https://tryzerocheck.com/docs/llms.txt) · [Complete documentation](https://tryzerocheck.com/docs/llms-full.txt)

---
Canonical: https://tryzerocheck.com/docs/mcp/
Updated: 2026-09-22


# Write a browser test in plain-English YAML

A Zerocheck test is an ordered list of browser steps with a specific expected outcome. You can draft and edit it in the web app, download an individual test as YAML, or keep test files in your repository.

## A complete example

Adapt the route, labels and test data to your app. This example assumes a product named Notebook already exists and that the app has a Search field and button.

```yaml
version: zerocheck/v1
name: Search finds a product
blocks_merge: true
steps:
  - Navigate to {{app_url}}
  - Enter "Notebook" into "Search"
  - Click "Search"
  - Verify text "Notebook" is visible
```

Use `{{app_url}}` to preserve the selected environment's full URL, including a path, query or hash. A leading `/` path addresses the origin root; a bare relative path resolves from the configured app path.

## Test fields

| Field | Meaning |
| --- | --- |
| `version` | Required; `zerocheck/v1`. |
| `name` | Required; the name shown in results. |
| `description` | Optional context for the test. |
| `blocks_merge` | Optional boolean, default `true`; controls whether a test failure fails the merge policy. |
| `steps` | Required list of nonempty instruction strings. The final step must be a `Verify` outcome. |

Other top-level fields are rejected. YAML is readable and downloadable; this particular test schema is interpreted by Zerocheck.

## Browser instructions

Use **Navigate to**, **Click**, **Enter**, **Select**, **Hover over**, **Scroll to**, **Wait for**, **Press** and **Verify**. Name the intended control and the value or state that matters.

For example, `Press "Enter" on "Search"` gives the key and its target. `Verify text "Saved" is visible` checks a quoted string directly. Supported URL and network assertions also use browser evidence; other expected-outcome descriptions can require AI interpretation.

Prefer a concrete result such as `Verify text "$25.00" is visible` to “Verify checkout works”. The agent can only test the behavior and outcomes you specify.

## Credentials and reusable setup

Configure environment URLs, reusable login steps and named secrets in `zerocheck.yaml` or the web app's Settings. Use references such as `${TEST_EMAIL}` or `{{credential:TEST_EMAIL}}` in test steps. Actual secret values belong in environment variables or the hosted instance's configuration.

Missing referenced secrets stop execution before a browser opens. Literal configured secret values in YAML are rejected. Test-data placeholders include `{{run_id}}`, `{{unique_email}}`, `{{unique_name}}` and `{{unique_company}}`; unique values still need to fit your app's data rules.

## Keep the scope observable

Browser tests can navigate pages, use forms and verify supported visible outcomes. Email inbox actions, native apps and API-only workflows need a different test boundary. Do not put invented email or payment helper commands in a YAML test.

[Supported flows](https://tryzerocheck.com/docs/limits/) · [CLI validation](https://tryzerocheck.com/docs/cli/) · [Data handling](https://tryzerocheck.com/docs/security/)

---
Canonical: https://tryzerocheck.com/docs/test-format/
Updated: 2026-09-14


# Understand what happened in a test run

Zerocheck records the exact test definition and revision that ran, the selected environment and browser location, and the outcome of each attempt. Start at the failing step, then inspect the evidence around it.

## A failed outcome and an incomplete run are different

| Result | What to do next |
| --- | --- |
| Passed | Review that the test and expected outcome cover the flow you intended. |
| Failed expected outcome | Inspect the assertion and browser state to investigate the behavior. |
| Needs input during import | Supply the missing setup, credential reference, fixture or expected outcome. |
| Could not run | Inspect the setup, interaction or service error; the requested flow has not been verified. |
| Passed on retry / flaky | Inspect the transient recovery and apply your team's merge policy. |

Runs can be queued, running, passed, failed, error or cancelled. A saved failing test remains failing; saving or editing a definition does not produce a new passing result.

## Evidence you can inspect

Run detail shows per-step results, before-and-after screenshots, error text, console warnings and errors, recovery notes and healing history. Failed steps expand by default. Every attempt retains its steps. If an artifact could not be captured, its error is recorded.

Video is recorded only when the environment has no configured secrets, because those values cannot be masked in recordings. Network responses can support assertions but are not stored as a network log. The result records how a step was resolved: directly, from a cached target, or using AI.

## How healing works

Zerocheck reuses a remembered target only while it still identifies the intended control. When that control moves, the agent can resolve it again from the step's description. The history shows the old target, replacement, reason and validation state.

A heal is saved as verified only when the complete unchanged test passes with independent evidence that the intended target, action and outcome were preserved. Otherwise it stays pending, or is rejected when the test fails. There is no additional run solely to confirm a repair.

A renamed control or a changed expected outcome needs review. Healing does not give the agent permission to rewrite your product's expected behavior.

A remembered control that is disabled fails the step; the agent does not switch to an enabled lookalike. Its valid hint stays available if the same control becomes enabled later. If a remembered target becomes ambiguous, its hint is retired. Edit the test to identify the intended control or region, then save and rerun the new revision. Changing the page alone does not reactivate that retired hint.

Observation and target validation share the step deadline. If optional recovery observation is temporarily unavailable, ordinary grounding can still use the remaining budget. Policy failures, ambiguous targets, failed mandatory validation and uncertain dispatched actions do not permit that fallback or a repeated action.

## How retries work

A transient AI-service error can be retried once during a step in the same browser. If the test then passes, it is labeled flaky. Assertion, configuration and policy failures are not retried into passing results.

The shipped local and hosted runners do not blindly restart a whole test after application actions. This avoids repeating writes without a verified reset of test state. Configure retries as zero or one, and use `--fail-on-flaky` in the CLI when that outcome should fail a blocking test's merge policy.

## Where results appear

Hosted runs appear in the web app. CLI runs upload results and artifacts so you can inspect them there too. The terminal summarizes outcomes and links to results; JSON includes the full run. GitHub Actions can add a job summary and one updated pull request comment.

[GitHub Actions](https://tryzerocheck.com/docs/github-actions/) · [Data and credentials](https://tryzerocheck.com/docs/security/) · [Create a test](https://tryzerocheck.com/docs/web-app/)

---
Canonical: https://tryzerocheck.com/docs/results/
Updated: 2026-09-21


# Test credentials and browser data

Use test accounts and choose an environment where the authored actions are appropriate. Zerocheck needs enough page context to run the test and explain its result; choose your evaluation flows with that data access in mind.

## What leaves the local runner

Local runs use Zerocheck's authenticated AI service and upload selected test definitions, run results and artifacts. AI interactions can send a screenshot, an accessibility representation of the page, its URL and title, and recent action context.

Running the browser on your machine gives it access to addresses your machine can reach. It does not make execution offline or remove the service dependency.

## How to supply credentials

Reference secrets by name in the environment configuration and test steps. Your local environment supplies local-run values; the instance owner configures hosted credential values and allowed target hosts. Missing required values stop the run before a browser opens.

Only explicitly referenced test secrets are resolved. Keep credentials out of test descriptions and committed YAML. Reusable login steps run before the test and should finish with an expected logged-in state.

## What is masked

Configured secret values are redacted from model observations and saved text. Screenshots mask inputs, configured visible secret values and cross-origin frames. This is not general personal-data removal: other application data can still appear in page observations or artifacts.

Video is omitted when configured secrets are present because recordings cannot apply the same masking. For credential-free flows, each attempt can include a recording.

## Actions and environments

Choose dev, staging or production explicitly. The browser agent applies action policies that block destructive account or data actions and bulk sends. Payments can be allowed and logged, so use a test environment and the payment provider's test mode where appropriate; choosing production does not make a run read-only.

Zerocheck supports ordinary browser interactions with payment screens, but it does not provide a special test-card completion command or inbox service. Configure the flow and test data your app actually supports.

## Results and access

Hosted results are stored on your instance. Local results are kept under `.zerocheck/` and uploaded to the service. There is no advertised automatic retention or deletion period; discuss your storage requirements during onboarding.

Selected failing screenshots and recordings can receive share links for pull request reporting. Anyone with such a link can access the shared artifact, and those links do not have an automatic expiry. Review what your tests expose before sharing evidence outside your team.

[Supported flows](https://tryzerocheck.com/docs/limits/) · [Result evidence](https://tryzerocheck.com/docs/results/) · [Privacy policy](https://tryzerocheck.com/privacy/) · [Contact sales](https://tryzerocheck.com/demo/)

---
Canonical: https://tryzerocheck.com/docs/security/
Updated: 2026-09-14


# Check whether Zerocheck fits your test flow

Zerocheck tests the web flows and expected outcomes your team describes. Start with a reachable environment, known test data and a result you can observe in the browser.

| Requirement | Current support |
| --- | --- |
| Desktop web testing | Chromium browser runs. |
| Plain-English authoring | Add one test or import a checklist; review, edit and save the steps. |
| Hosted execution | Run from the web app with no installation in your codebase. |
| Localhost and private networks | Use the CLI's local runner where your machine can reach the app. |
| Login | Configure login steps and named test credentials. |
| CI | CLI execution, JSON/JUnit reports and a generated GitHub Actions workflow. |
| Coding agents | Local stdio MCP server for compatible clients. |
| Explicit outcomes | Supported text, URL and network assertions; AI interpretation for other descriptions. |
| UI maintenance | Resolve moved equivalent controls and record evidence-gated healing. |
| Additional websites and embedded frames | Ordinary HTTP(S) navigation and embedded frames work with no configuration. An optional `allowed_origins` list restricts interaction to the app origin plus the exact origins listed; with a restriction set, each ancestor frame must also be allowed. |

## Checkout and cross-origin login

Use a confirmed payment test environment, fresh identities and explicit browser outcomes. An embedded checkout needs no origin configuration. Set `allowed_origins` only when you want to restrict where the agent may interact, and then include every origin the flow needs; public third-party resources can load without becoming permitted interaction destinations. Hosted private-network restrictions apply independently. Origin support is verified with controlled fixtures; complete Stripe success and decline compatibility is still under evaluation. A local result does not establish a hosted result. Both runner types can encounter bot protection.

Additional interaction origins do not authorize configured credentials to leave the app origin. Environment `secret_origins` can grant each named credential an exact additional destination, only during configured login steps; when `allowed_origins` is set, that destination must be listed there too. The app origin remains the default. Body steps retain app-only permission, including when authentication is reused. Settings saves the same permissions for hosted runs; test instructions and model output cannot widen them. Public test-card fixtures and `{{unique_email}}` need no configured secrets.

The supported login shape is a same-tab redirect to an email-and-password page, followed by return to the app and a positive authenticated assertion. Controlled browser fixtures verify credential input, submission, grant expiry, cache rebinding and redacted evidence. Actual Auth0/Clerk tenant compatibility remains unverified and must be established with the chosen runner. Credential references preserve their authored structure and values are inserted only when the controller dispatches; these controls are not a network sandbox for the application itself.

Same-tab navigation and embedded controls are in scope. Popups, MFA, passkeys, social login, automated challenge solving and 3D Secure are outside the initial claim. Targets in additional origins are re-grounded on each run; persistent hints remain limited to the app origin. No Stripe API adapter, webhook verification or reset platform is provided.

## Flows that need a narrower test boundary

Email and SMS inbox actions, magic-link retrieval, native/mobile apps, API-only tests and canvas-only interactions are outside the current browser-step support. Browser-native login can work with supplied setup; a workflow that depends on retrieving a one-time code from an inbox needs additional preparation outside Zerocheck.

Zerocheck can interact with ordinary checkout pages using supplied test data. It does not supply a payment provider, test-card helper or guarantee that a production transaction is harmless. See [test credentials and actions](https://tryzerocheck.com/docs/security/).

## What a test result tells you

A passing test means its specified steps and expected outcomes passed in that run. It does not establish complete application coverage or diagnose every possible regression. A failed or incomplete run needs inspection of the test and its evidence.

The product does not crawl your app to discover a suite, infer tests from code changes, calculate a coverage/confidence score, or provide production incident alerts. Select the flows and test files that matter to your release.

## Execution and editing limits

Tests run sequentially. The current product does not offer parallel sharding or additional browser engines. Each MCP process has one active browser job.

A disabled intended control fails instead of healing to another control. Ambiguous remembered targets require a more specific saved test revision. Recovery is bounded by the step deadline, and Zerocheck does not repeat an action whose dispatch is uncertain. See [results, retries and healing](https://tryzerocheck.com/docs/results/).

Tests created in the web app are edited there. Repository-managed tests are edited in YAML and are read-only in the web UI. Downloading a web test creates an independent copy; there is no automatic two-way repository synchronization.

## Access and evaluation

Access is provisioned during assisted onboarding. The current instance model does not provide individual user accounts, SSO or role-based team administration. There is no per-seat charge for the Pilot, which describes pricing rather than separate user logins.

Try the flows you actually need on the free tier, which is provisioned on an onboarding call. The Pilot is US$500 per month for one project on a dedicated instance, with run cadence and usage agreed for your team.

[Pricing](https://tryzerocheck.com/pricing/) · [Try for free](https://tryzerocheck.com/onboarding/) · [First browser test](https://tryzerocheck.com/docs/web-app/)

---
Canonical: https://tryzerocheck.com/docs/limits/
Updated: 2026-09-22


# Using Zerocheck with an agent

Zerocheck is a QA agent for web apps: it turns plain-English flow descriptions or a team's release checklist into repeatable browser tests with evidence for every step. Start in the web app with Add a test or Import checklist, inspect the browser result, save the test and rerun it. The optional CLI supports repository tests, local browser execution, CI and a local stdio MCP server.

## Product fit

Use Zerocheck to verify specified web flows and expected outcomes before a release, or to inspect the exact steps and evidence from a run. Tests execute in Chromium. Login needs configured setup and test credentials. Refer to the supported-flow reference before proposing email, mobile, API-only or canvas workflows.

## Start with access and configuration

The current offer is a free tier (US$0, about 200 test runs a month, no credit card) that requires an onboarding call, followed by an optional US$500/month Pilot for one project on a dedicated instance. Access is provisioned during onboarding; there is no instant account-creation flow. Usage and run cadence are agreed for the team.

The CLI package is `zerocheck`; the same CLI is also published under 13 alias names on npm (e2e-testing, e2e-qa, e2e-agent, agentic-qa, e2e-verify, bugbash, qa-tests, qa-checks, run-qa, agentic-testing, agentic-e2e-testing, browser-qa and web-qa), each pinned to the same version. When you generate configuration, workflows or commands, use `zerocheck`. For a local or MCP workflow, read the CLI quickstart first. It includes authentication, environment configuration, Chromium installation, import review, explicit draft saving and the first run. `init` creates configuration and an empty test directory; importing without saving does not populate the saved suite.

## Setup prompt for a coding agent

From an onboarded team's repository: "Set up Zerocheck in this repository. Run `npm install --save-dev --save-exact zerocheck@0.1.9`, then `npx zerocheck login`, then `npx zerocheck init --url http://localhost:3000` and `npx zerocheck install`. Start the MCP server with `npx zerocheck mcp --project-dir <absolute path to this repository>` and add it to your MCP configuration. Then use its tools to write one test for the most important page in this app, run it, and fix the test until it passes without changing the expected outcome. Show me the drafted YAML and the result link before saving."

## Keep definitions and outcomes explicit

- Web-created tests are edited in Zerocheck. Repository-managed tests are edited in YAML. Downloading a web test produces an independent copy; do not imply automatic repository synchronization.
- Drafting can execute browser actions before review. Use the authorized environment and supplied test accounts.
- Preserve the user's expected outcome when authoring, editing or investigating a failure. A failure is not permission to weaken an assertion.
- Use named credential references, never literal secrets in YAML. Read only the credentials the test configuration needs.
- Report failed, incomplete and needs-input results accurately. A passing run applies to that test and revision; it is not a whole-app coverage guarantee.
- Inspect the actual result and artifact links. Do not fabricate screenshots, run IDs, customer outcomes or healing evidence.
- A healed target is verified only after the complete unchanged test passes with independent evidence. Other candidates remain pending or are rejected.
- Local browser execution still uses Zerocheck's AI service and uploads results and artifacts.

## MCP tools

The CLI command `zerocheck mcp --project-dir /absolute/path` starts a local stdio server. It exposes `list_checks`, `read_check`, `save_check`, `import_checklist`, `answer_import`, `adopt_import`, `verify_check`, `run_checks`, `get_results` and `cancel`. Read the server's tool schemas for arguments. Only one browser job can be active per process.

This public website provides product documentation and discovery files; it is not the MCP endpoint. Follow the MCP setup page to configure a compatible client.

## Canonical references

- [Agent authentication](https://tryzerocheck.com/auth.md): device login, project tokens, what a token is used for
- [Blog index for agents](https://tryzerocheck.com/blog/llms.txt): dated index of posts
- [Offering and workflow](https://tryzerocheck.com/product/)
- [Web quickstart](https://tryzerocheck.com/docs/web-app/)
- [Checklist import](https://tryzerocheck.com/docs/checklist/)
- [CLI setup, saving and execution](https://tryzerocheck.com/docs/cli/)
- [MCP configuration and tools](https://tryzerocheck.com/docs/mcp/)
- [GitHub Actions](https://tryzerocheck.com/docs/github-actions/)
- [Test format](https://tryzerocheck.com/docs/test-format/)
- [Results, retries and healing](https://tryzerocheck.com/docs/results/)
- [Credentials and data](https://tryzerocheck.com/docs/security/)
- [Supported flows and limits](https://tryzerocheck.com/docs/limits/)
- [Current pricing](https://tryzerocheck.com/pricing.md)
- [Documentation index](https://tryzerocheck.com/docs/llms.txt)
- [Full documentation](https://tryzerocheck.com/docs/llms-full.txt)


# What Is a QA Agent?

By Arni Mittal, Founder of Zerocheck.

## Definition

A QA agent is software that tests a running application the way a person would. It reads a plain-English step, looks at the live page, chooses an action, performs it in a real browser and checks the outcome, recording evidence for every step. It performs testing work; it does not own quality.

## Why it matters

Coding agents now write more code than a team can check by hand, and selector-based suites break on the first refactor. A QA agent absorbs the two costs that stall end-to-end testing: writing the automation and keeping it working. The useful buying question is which work the agent performs and what evidence it produces. Requirements, fixtures and release decisions stay with people.

## How teams handle it today

Teams evaluate a QA agent on one real flow with an explicit expected outcome. They read the generated test, run it twice, introduce a deliberate failure and check that the result explains what happened. They also ask what the agent needs from them: a URL and a test account, or repository access and preview deployments.

## How Zerocheck approaches it

Zerocheck is a QA agent for web apps. You describe a flow or import your release checklist; it drafts one test per item, runs it in Chromium and records the evidence. A model proposes one action at a time from a screenshot and the accessibility tree, and a controller checks the target and permissions before the browser executes it. Expected outcomes stay fixed. Healing re-identifies an equivalent target and is saved only after the whole test passes again; it never changes an assertion to make a test pass.

Start in the web app with a hosted browser, or use the CLI on your machine, in GitHub Actions or through MCP from Claude Code or Cursor. Tests are plain YAML you own.

## What a QA agent does, and does not do

A QA agent does four things on every step, and a good one shows its work for each of them:

- Reads the step and the live page. It works from a screenshot and the accessibility tree, not from a CSS selector someone wrote last quarter.
- Chooses and performs one action in a real browser: navigate, click, type, select, press. The action still waits for the control to be visible, stable and enabled, the checks Playwright documents as actionability.
- Checks the expected outcome the author wrote, such as a visible confirmation, a URL or a network response.
- Records evidence: a screenshot per step, the action it chose, any retry, and any healed target with its old and new identity.

It does not decide what to test, invent expected outcomes, create test accounts, seed data, or judge whether a failure is a bug or a bad requirement. When a product page promises "no tests to write or maintain", ask which of those jobs moved to the agent and which quietly moved to you.

## What you supply, and what it produces

| You supply | The agent produces |
|---|---|
| A reachable URL: localhost, staging or production | One test per flow or checklist item, as readable steps |
| A flow in plain English, or a release checklist | A run with a verdict per step: passed, failed, flaky or incomplete |
| A test account and any test data, such as a Stripe test card | A screenshot for every step, and a recording when no credentials are involved |
| The origins it may interact with, such as an embedded payment frame | A heal record with the old target, the new target and its validation state |
| An expected outcome for each flow | A pull request comment or a CLI exit code your merge policy can gate on |

Nothing on the left is optional. A QA agent that starts without an expected outcome is exploring, not testing.

## Four levels of QA agent autonomy

Vendors describe very different products with the same two words. This ladder sorts them by what the agent decides on its own.

| Level | What the agent does | Who owns the outcome | Examples, 21 September 2026 |
|---|---|---|---|
| Assist | Drafts steps or code from a description or a recording; a person runs them | The person | Recorders, code generation in an IDE |
| Run | Executes readable steps in a real browser and records evidence per step | The test author | Zerocheck, Momentic tests |
| Heal | Re-identifies a moved target and keeps the test passing without changing its assertions | The test author, with the heal recorded | Zerocheck, Momentic auto-heal |
| Explore | Picks its own flows from a brief or from the codebase and reports the bugs it found | The agent proposes, a person confirms | Momentic's Mo, Autonoma's generated suites |

Zerocheck sits at run and heal. Exploration is useful for bug bashes. It does not replace the release checklist your team already trusts, because it cannot know what the product is supposed to do.

## A worked example: a medical certificate request that ends in a Stripe checkout

A leading Australian telehealth company sells medical certificates through a multi-step form: leave type, symptoms, patient details, address, review, then payment in an embedded Stripe checkout. The release checklist item reads "a new patient can request a certificate and pay". This is the test Zerocheck is running for it, with Stripe's public test card and a fresh identity on every run; the final step names the app's own confirmation label. The environment names the app URL; the embedded payment frame needs no origin configuration.

```yaml
# zerocheck.yaml
environments:
  staging:
    url: https://staging.example.com/request/medical-certificate

# checks/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 run report shows

Every step gets a screenshot, and the test finishes passed, failed, flaky (passed after a transient retry) or incomplete. If a control on the app's own pages moves, the heal is recorded with its old and new target and stays pending until the whole test passes again; targets inside the payment frame are re-identified on every run instead. If the provider's bot protection blocks the frame, the run does not pass, and the step's screenshot and recorded error show why instead of a silent timeout. A pass after a transient retry is labeled flaky, never hidden. The run verdict is what the merge policy gates on: the CLI exits non-zero and one pull request comment is updated.

As of 22 September 2026 the card step of this flow is being verified against the provider's embedded frame; the recorded run will be published here when it passes. Third-party payment processing, 3D Secure challenges and webhooks stay outside the browser test. Read [how to test Stripe checkout before release](/guides/test-stripe-checkout/) for the full checklist.

## QA agent, test framework, managed service, coding agent or generated suite?

| | Test framework (Playwright, Cypress) | Managed service (QA Wolf) | Coding agent with Playwright MCP | Generated suite (Autonoma) | QA agent (Zerocheck) |
|---|---|---|---|---|---|
| Who writes the test | Your engineers, in code | Their engineers on the managed service; your team from prompts on the Platform | The agent, ad hoc, in a chat | Their planner, from your repository | You, in plain English or from a checklist |
| Who maintains it | Your engineers | Their engineers | Nobody; each session starts over | Their agents | The agent heals targets; you own outcomes |
| Evidence per step | Screenshots on failure by default; traces if you configure them | Reports and videos | Whatever the chat kept | Videos and screenshots in the pull request | Screenshot, verdict and heal record per step |
| Repeatable in CI | Yes | Yes, on their runners | Not without export | Yes, per pull request | Yes: locally, in GitHub Actions or hosted |
| Needs from you | Framework skills and CI time | Specs and access | An MCP setup and supervision | Repository access, a GitHub App, preview deploys and a data-seeding endpoint | A URL, a test account and the flows |
| Cost basis, sources read 16 to 21 September 2026 | Engineering time | Platform at 1¢ per AI credit and 15¢ per runner minute; Coverage as a Service custom-priced | Model tokens and your time | 100K free credits, then US$100 per 150K credits; self-hosted free | Free tier with onboarding, then US$500 a month |

The rows buyers ask about first are the last three. If you cannot grant repository access or do not have preview deployments, a codebase-driven suite is not available to you yet. If you need a pass you can replay next week, a chat session with a browser is not a test.

## How to evaluate a QA agent: ten questions

1. Show me the evidence for one passing step: a screenshot and the action taken, not a green tick.
2. What may the agent change on its own? Targets only, or assertions and expected outcomes too?
3. When a heal happens, where are the old target, the new target and the validation state recorded?
4. What happens to a pass after a retry? It should be visible as flaky, not counted as green.
5. What leaves my machine, and which secrets does it read?
6. Which origins can it interact with, and can a test instruction widen that?
7. How does CI gate on it: exit codes, a required check, a comment?
8. What format are the tests in, and can I take them with me?
9. What does it cost per run, per seat or per month, and what is metered?
10. What does a failure look like on a Monday morning? Run one deliberately broken flow before you decide.

## Sources

- [Playwright actionability checks](https://playwright.dev/docs/actionability), read 22 September 2026.
- [Stripe testing documentation](https://docs.stripe.com/testing), read 16 September 2026.
- [Momentic: Mo, the AI QA](https://momentic.ai/mo) and [Momentic pricing](https://momentic.ai/pricing), read 21 September 2026.
- [Autonoma](https://getautonoma.com/), including its pricing section, read 21 September 2026.
- [QA Wolf pricing](https://www.qawolf.com/pricing), read 16 September 2026.

## Frequently asked questions

### Is a QA agent the same as AI test automation?

No. AI test automation covers any use of a model in testing, including generating code for a framework. A QA agent acts in the browser itself, step by step, and records evidence. The difference shows up in maintenance: generated Playwright code still breaks on selectors.

### Does a QA agent replace QA engineers?

It replaces the clicking-through and the selector maintenance. Someone still decides what the product must do, prepares test accounts and data, and reads failures. Teams without a QA function get a repeatable release check; teams with one get their time back for exploratory work.

### Can a QA agent test Stripe checkout?

Yes on the app's own pages, using Stripe test mode and public test cards; interaction inside the embedded card frame, with its origin allowed, is being verified. Provider processing, 3D Secure challenges, webhooks and settlement need separate checks.

### What does a QA agent need access to?

Zerocheck needs a URL it can reach, a test account and the flows to check. It does not read your repository. Products that generate tests from code need repository access and usually a preview deployment per pull request.

### How do I know a QA agent's pass is real?

Look at the step evidence: each step's screenshot and the action taken, plus any retry or heal. Zerocheck labels a pass after a transient retry as flaky and saves a heal only after the whole test passes again with the new target.

### What happens when the UI changes?

A QA agent re-identifies the target from the step's description rather than a selector. Zerocheck records the old and new target and keeps the heal pending until the complete test passes again. If the expected outcome itself changed, that is a one-line edit you review.

Related terms: [Agentic Testing](https://tryzerocheck.com/glossary/agentic-testing/), [Self-Healing Test](https://tryzerocheck.com/glossary/self-healing-test/), [E2E Testing](https://tryzerocheck.com/glossary/e2e-testing/), [Diff-Aware Testing](https://tryzerocheck.com/glossary/diff-aware-testing/)
- [Results, retries and healing](https://tryzerocheck.com/docs/results/)
- [Zerocheck vs Playwright MCP](https://tryzerocheck.com/compare/playwright-mcp/)
- [How to test Stripe checkout before release](https://tryzerocheck.com/guides/test-stripe-checkout/)
- [Try Zerocheck for free](https://tryzerocheck.com/onboarding/?from=glossary-qa-agent)

---
Canonical: https://tryzerocheck.com/glossary/qa-agent/
Updated: 2026-09-22


# How to test Stripe checkout before release

Test mode and test cards, the cross-origin card frame, 3D Secure and webhooks in CI, then how a QA agent turns your purchase and decline checklist into browser tests that rerun on every release.

## Why it is hard

- Stripe Elements renders the card fields inside an iframe served from js.stripe.com, so the parent page’s locators cannot reach them.
- A 3D Secure challenge opens another Stripe-hosted frame on top of the checkout, with its own load timing.
- Test mode uses Stripe’s test cards and sandbox events; live mode involves real issuers and your Radar rules, so a green test-mode run is evidence, not proof.
- A visible confirmation page does not show that your webhook handler received and verified the event.
- Totals, discounts and tax depend on fixture data that has to stay stable between runs.

## Approach 1: Playwright with Stripe test mode

1. Confirm Stripe test mode, then create a fresh test identity and fixed sandbox product and price.
2. Create sandbox products, prices and a test customer so the expected total is fixed.
3. Cross into the Stripe iframe with page.frameLocator() and wait for the card input to be visible before filling it.
4. Use Stripe’s documented test cards: 4242 4242 4242 4242 succeeds, 4000 0025 0000 3155 requires authentication for on-session payments.
5. For a separate Playwright 3D Secure test, inspect the nested challenge frames and verify the outcome. Zerocheck does not claim 3D Secure support.
6. Assert the confirmation and exact total in the browser. Verify webhook handling separately with integration assertions. For decline, wait for the error before checking that paid confirmation is absent.
7. In CI, forward sandbox events with stripe listen and pass its signing secret to the app under test.

## Approach 2: Zerocheck for the checkout flow your team describes

1. Use Add a test or Import checklist in the web app, or write repository YAML for the local CLI.
2. Leave allowed_origins unset unless you want to restrict the agent to exact origins; ordinary navigation and embedded frames, including the payment frame, work without it.
3. Review named-field Enter and Click steps and the expected app outcome; inspect the actual result before saving.
4. Rerun the saved test after an application change. Evaluate hosted and local execution separately.

## 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, not a verified recipe for every checkout.

## Choose the runner for your actual flow

Web-authored tests run in Zerocheck's hosted browser. The optional CLI runs on your machine or CI. Both can encounter bot protection; a local pass does not establish a hosted pass. We prepare the local evaluation path and discuss permitted test-tenant exceptions during assisted setup. Checking your own machine and network before the call is optional.

## What is verified today

Exact origin permissions, nested-frame interaction, input masking and bounded recovery from changing frames are released and covered by controlled browser fixtures. End-to-end Stripe success and decline compatibility is still under evaluation, so we do not yet claim those outcomes for an arbitrary checkout. 3D Secure, automated challenge solving and webhook testing are outside this initial scope.

## Testing Stripe checkout with a QA agent

A QA agent removes the selector work, not the test-mode discipline above. You describe the purchase in plain English; Zerocheck grounds each step on the live page, including the embedded card frame, which needs no origin configuration, and records a screenshot and a verdict per step. The tests are YAML you keep in your repository and rerun locally, in GitHub Actions or in a hosted browser.

The example below is the release checklist item "a new patient can request a certificate and pay" from a leading Australian telehealth company, 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. The card step is being verified against the embedded frame:

```yaml
# zerocheck.yaml
environments:
  staging:
    url: https://staging.example.com/request/medical-certificate

# checks/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 QA agent proves, and what it does not

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 heal is recorded with its old and new target and stays pending until the whole test passes again; targets inside the payment frame are re-identified on every run instead. A pass after a transient retry is labeled flaky, never hidden. The run verdict is what your merge policy gates on: the CLI exits non-zero and one pull request comment is updated.

Provider processing, 3D Secure challenges, webhooks and settlement stay outside the browser test; keep them in the integration tests described below. Both runner types can meet bot protection, so if your checkout has a captcha, use the captcha provider's test keys or disable it in staging. As of 22 September 2026, complete Stripe success and decline compatibility is still being verified against embedded frames; the recorded run will be published here when it passes.

## Stripe Elements renders in a cross-origin iframe

Stripe does not put the card fields in your page’s DOM. Elements creates an iframe served from js.stripe.com that holds the card number, expiry and CVC inputs, so your JavaScript never touches card data. That isolation is part of how Stripe keeps card data out of your systems, and it is also why document.querySelector and page.locator() from the parent page find nothing.

Playwright crosses the boundary with page.frameLocator(). Target the iframe by a stable attribute, then chain ordinary locators inside it. At the time of writing the Payment Element’s iframe carries the title “Secure payment input frame” and the legacy Card Element uses titles beginning “Secure card”. Stripe controls these attributes, so inspect your own page rather than trusting a blog post, including this one.

A frame can appear before its inputs finish rendering. Playwright locators inside frameLocator retain their normal auto-waiting, so fill already waits for an actionable input. A separate visibility assertion is useful for a clear diagnostic checkpoint or a different deadline. Check the frame identity and field locator before treating a timeout as a timing problem.

```typescript
import { test, expect } from '@playwright/test';

test('pays with a Stripe test card', async ({ page }) => {
  await page.goto('/checkout');

  // The Payment Element renders inside an iframe served by js.stripe.com.
  // Inspect your page for the exact title; Stripe controls these attributes.
  const stripe = page.frameLocator('iframe[title="Secure payment input frame"]');
  const card = stripe.getByPlaceholder('1234 1234 1234 1234');

  // The iframe exists before Stripe has rendered its inputs. Wait for the field.
  await expect(card).toBeVisible({ timeout: 10_000 });
  await card.fill('4242424242424242');
  await stripe.getByPlaceholder('MM / YY').fill('12/34');
  await stripe.getByPlaceholder('CVC').fill('123');
  // A postal code field appears for some countries and configurations.

  await page.getByRole('button', { name: 'Pay' }).click();

  await expect(page).toHaveURL(/\/order-confirmation/);
  await expect(page.getByText('Payment successful')).toBeVisible();
  await expect(page.getByText('$25.00')).toBeVisible();
});
```

## Test cards and a separate Playwright 3D Secure example

Stripe’s testing documentation, checked on 21 September 2026, lists cards that exercise each path. In test mode any future expiry is accepted, with any three-digit CVC, or four digits for American Express.

4242 4242 4242 4242 succeeds and is not enrolled in 3D Secure, so the customer is never prompted. 4000 0025 0000 3155 requires authentication for on-session payments. 4000 0027 6000 3184 requires authentication on every transaction. 4000 0000 0000 3220 must complete 3D Secure for the payment to succeed, and Radar requests it by default. 4000 0000 0000 3055 supports 3D Secure but does not require it. 4000 0000 0000 0002 is declined with generic_decline, and 4000 0000 0000 9995 is declined with insufficient_funds.

When a card requires authentication, Stripe opens the test challenge in nested iframes over your checkout. At the time of writing the test-mode challenge shows a page with a button to complete the authentication and one to fail it, usually two or three frames deep. Your test has to cross each frame boundary, wait for the button, and allow more time than a normal click because the challenge loads from Stripe. The frame names and ids belong to Stripe and can change; the durable part of the pattern is nested frameLocator calls, an explicit wait and an assertion on the outcome your app shows afterward.

```typescript
import { test, expect } from '@playwright/test';

test('completes a 3D Secure test challenge', async ({ page }) => {
  await page.goto('/checkout');
  const stripe = page.frameLocator('iframe[title="Secure payment input frame"]');
  const card = stripe.getByPlaceholder('1234 1234 1234 1234');
  await expect(card).toBeVisible({ timeout: 10_000 });

  // Requires authentication for on-session payments (Stripe testing docs).
  await card.fill('4000002500003155');
  await stripe.getByPlaceholder('MM / YY').fill('12/34');
  await stripe.getByPlaceholder('CVC').fill('123');
  await page.getByRole('button', { name: 'Pay' }).click();

  // Stripe opens the test challenge in nested iframes. Inspect the frame names
  // in your integration; they are Stripe's and can change. Many integrations
  // nest modal > #challengeFrame > acsFrame; drop the last hop if yours does not.
  const modal = page.frameLocator('iframe[name^=__privateStripeFrame]').last();
  const challenge = modal.frameLocator('#challengeFrame').frameLocator('iframe[name="acsFrame"]');
  await challenge.getByRole('button', { name: /complete/i }).click({ timeout: 15_000 });

  await expect(page).toHaveURL(/\/order-confirmation/, { timeout: 15_000 });
  await expect(page.getByText('Payment successful')).toBeVisible();
});

test('shows a decline message', async ({ page }) => {
  await page.goto('/checkout');
  const stripe = page.frameLocator('iframe[title="Secure payment input frame"]');
  const card = stripe.getByPlaceholder('1234 1234 1234 1234');
  await expect(card).toBeVisible({ timeout: 10_000 });
  await card.fill('4000000000000002'); // generic_decline
  await stripe.getByPlaceholder('MM / YY').fill('12/34');
  await stripe.getByPlaceholder('CVC').fill('123');
  await page.getByRole('button', { name: 'Pay' }).click();
  await expect(page.getByText('Your card was declined')).toBeVisible(); // your app's message
});
```

## Test mode is not live mode

Stripe’s sandbox catches integration mistakes: wrong amounts, a broken success redirect, an unhandled decline. It does not reproduce a live issuer, a real bank’s challenge screen or your production Radar rules. Stripe documents separate test cards whose challenge UIs are meant for mobile SDKs rather than browser forms, which is a reminder that the test challenge is a stand-in, not the customer’s bank.

Treat a passing test-mode suite as one input to the release decision. Keep automated release checks in the sandbox with test keys and fixtures. A test-mode result establishes the exercised integration behavior under those conditions; it does not establish live issuer or production challenge behavior.

Webhooks are where test mode most often misleads. Stripe’s testing docs give two ways to exercise an endpoint: perform an action in the sandbox that emits a real event, such as paying with a successful test card, or trigger a synthetic event with the Stripe CLI. The first proves the whole path; the second proves only the handler.

## Separate integration tests with the Stripe CLI

Your test server in CI has no public URL, so Stripe cannot deliver events to it directly. The Stripe CLI’s listen command opens a connection to Stripe and forwards sandbox events to a local endpoint. Start it before the tests, wait until it is ready, and pass its signing secret to the app.

The secret is the step teams get wrong. Stripe signs every event, and stripe listen prints a temporary signing secret that differs from the one on your dashboard endpoint. If the app verifies with the dashboard secret, every forwarded event fails verification and your tests wait for state that never arrives. The script below captures the secret from the CLI output and exports it before the tests start.

```bash
# CI setup step: forward Stripe sandbox events to the app under test.
stripe listen --forward-to localhost:3000/api/webhooks/stripe > stripe-listen.log 2>&1 &
STRIPE_PID=$!

# Wait for the listener. It prints the signing secret once it is ready.
for i in $(seq 1 30); do
  grep -q 'whsec_' stripe-listen.log && break
  sleep 1
done
export STRIPE_WEBHOOK_SECRET=$(grep -o 'whsec_[A-Za-z0-9]*' stripe-listen.log | head -1)

# The app must verify signatures with this secret, not the dashboard endpoint's secret.
npm run test:e2e

# Optional: send one synthetic event to exercise a handler without a checkout.
stripe trigger payment_intent.succeeded

kill $STRIPE_PID
```

## What a browser test proves about a payment

A browser test proves what the customer saw: the total before paying, the challenge if one appeared, and the confirmation afterward. It does not prove that money moved, that the event was verified or that your ledger updated. Keep those assertions in integration tests that read your own database or Stripe’s API in test mode.

That boundary is also how to split the work. Cart and summary tests do not need a payment at all: add an item, change a quantity, assert the visible subtotal. They are cheap, fast and cover the part of checkout that changes most often. In Zerocheck they are a good first test because the expected outcome is a quoted total that the explicit text assertion checks without a model. Evaluate the complete purchase and decline flow separately once the fixtures are stable; a passing cart test does not establish payment compatibility.

## Pitfalls

- Do not run a live-mode purchase as a casual smoke test. Use test mode, a test customer and Stripe’s test cards.
- Do not treat a visible success message as proof of settlement or of webhook handling.
- Do not fill the Stripe frame as soon as the iframe exists. Wait for the input inside it to be visible.
- Do not mock Stripe in end-to-end tests. Mock the SDK in unit tests; use test mode here.
- Do not hard-code Stripe’s frame names and ids as if they were yours. Inspect them again when a test breaks.

## Frequently asked questions

### Does Zerocheck complete payments automatically?

A test uses ordinary Enter and Click steps in a confirmed test environment. Whether your complete purchase and decline flows work must be established in the actual runner. There is no payment-provider adapter or universal Stripe compatibility claim.

### Can Cypress test Stripe checkout?

It can, with friction. Cypress runs inside the page and is bound by the same-origin policy, so reaching into Stripe’s iframe needs an iframe plugin or chromeWebSecurity set to false, which makes the test less like a real browser. Playwright’s frameLocator() crosses the boundary directly.

### How do I test 3D Secure in test mode?

Use Stripe’s authentication test cards. On 21 September 2026 Stripe’s testing page lists 4000 0025 0000 3155 as requiring authentication for on-session payments and 4000 0000 0000 3220 as requiring 3D Secure to be completed. Complete the test challenge inside its nested frame and assert the outcome your app shows.

### Can a QA agent test Stripe checkout?

Yes on your app's own pages, using Stripe test mode and public test cards; interaction inside the embedded card frame, with its origin allowed, is being verified. Provider processing, 3D Secure challenges, webhooks and settlement need separate checks. Zerocheck records a screenshot and verdict per step and reruns the same test on every release.

### Should I mock Stripe in end-to-end tests?

No. Test mode exists so the real integration runs against Stripe’s sandbox. Mock the Stripe SDK only in unit tests where speed matters.

### Can I test only the cart?

Yes. A narrow test that adds an item and asserts the visible total protects the browser journey without a payment, and it is a good first Zerocheck test.

Related: [Checkout Browser Testing](https://tryzerocheck.com/use-cases/checkout-testing/)

---
Canonical: https://tryzerocheck.com/guides/test-stripe-checkout/
Updated: 2026-09-22