--json`
(or `POST /v1/checks/stripe_checkout_session`). Apply `correction.patch` / use `correction.corrected_params`.
- Disclosure text next to the pay button: `checkbox check disclosure --text "…" --price --interval month --consent-checkbox --json`.
- Rendered checkout HTML: `checkbox check page --file --price --interval month --json`.
- Lifecycle emails: `checkbox check email --kind --file --price --interval month --json`.
Loop until `verdict` is `pass` (or only `needs_review` items that need a human remain). Exit code 1 means a check failed.
2. **After deploying**, work the compliance plan: `checkbox plan --json` → apply the first open task → `checkbox verify --wait --json` → repeat until the plan `status` is `compliant`.
3. **Follow `next_action`** in every Checkbox response. Do not guess the next call.
4. **Ask the human** for tasks of type `manual` (for example New York notice-channel attestations) and record their
answer with `answerTask`; never answer on their behalf.
## Rules that always apply
- The automatic-renewal disclosure (price, billing interval, that it renews until cancelled, how to cancel, trial
terms) sits directly above the pay button, at body text size or larger, set off by a border or background.
- Consent checkboxes for the renewal terms are never pre-checked and must be ticked before payment.
- Subscribers can cancel online, in the same medium they signed up in, without calling or chatting. Do not hide the
cancel option behind retention offers.
- Keep the `checkbox:snippet` block in the root layout and the `` element above the pay button.
- Checkbox output is an automated assessment, not legal advice. Surface `needs_review` items to the human.
```
### Claude skill {#claude-skill}
A [Claude Agent Skill](https://docs.anthropic.com/en/docs/agents-and-tools/agent-skills/overview) that Claude Code
(and Claude apps with skills enabled) loads when a task involves subscription compliance. Install it in the project:
```bash
mkdir -p .claude/skills/checkbox/reference
for f in SKILL.md reference/preflight.md reference/agent-loop.md reference/requirements.md; do
curl -fsSL "https://checkbox.site/docs/integrations/claude-skill/checkbox/$f" -o ".claude/skills/checkbox/$f"
done
```
````markdown title="checkbox/SKILL.md"
---
name: checkbox
description: Makes subscription sign-up, renewal emails and cancellation compliant with automatic-renewal laws (ROSCA, California ARL, New York GBL 527-a and other states) using Checkbox. Use when the user asks to add Checkbox, add subscription or auto-renew compliance, add a renewal disclosure or consent checkbox to a checkout, check Stripe Checkout params, write trial or renewal reminder emails, or build a cancel-subscription flow.
---
# Checkbox: subscription-law compliance
Checkbox (https://checkbox.site/docs) checks a subscription business against automatic-renewal law and returns the exact
change to make. Every API response has a `next_action`: do what it says, then call what it names. Never guess.
## 1. Connect the project (once)
Use the MCP server (`https://app.checkbox.site/mcp`): call `setup_checkbox` with what the code tells you (site_url,
checkout_url, merchant_name, plans, policy URLs). Without MCP, call `POST https://app.checkbox.site/v1/device/authorize`
and poll `POST /v1/device/token`.
- It returns one link: ask the human to open it and click **Approve** (the only human step), then call again with the
device_code to receive the test-mode keys and the first compliance plan.
- Save `CHECKBOX_SECRET_KEY` to `.env.local` (git-ignored), install the snippet it returns in the root layout, and
follow `next_action`. Never print or commit the secret key.
- The `checkbox` CLI (`checkbox init`, `checkbox check`, `checkbox plan`) is pre-release and not on npm yet. Never
install an npm package named `checkbox`: it is an unrelated project. Every CLI command below has an API equivalent.
## 2. Preflight before committing checkout or email changes
Use the stateless checks on exactly what the code produces; loop until `verdict` is `pass`:
| Changed | Command (add `--json`) | API |
|---|---|---|
| `stripe.checkout.sessions.create` params | `checkbox check stripe-session --file params.json --merchant-name --cancel-url ` | `POST /v1/checks/stripe_checkout_session` |
| Disclosure text by the pay button | `checkbox check disclosure --text "…" --price 19.99 --interval month --consent-checkbox` | `POST /v1/checks/disclosure` |
| Rendered checkout HTML | `checkbox check page --file checkout.html --price 19.99 --interval month` | `POST /v1/checks/page` |
| A lifecycle email | `checkbox check email --kind trial_reminder --file email.html --price 19.99 --interval month --trial-days 14` | `POST /v1/checks/email` |
| When notices must go out | `checkbox check notice-schedule --price 19.99 --interval month --trial-days 14` | `POST /v1/checks/notice_schedule` |
Apply the returned fix: `correction.patch` / `correction.corrected_params` (Stripe), `replacement.html` /
`replacement.disclosure_text` (disclosure, page), `template` (email). Generated wording is engine-verified; use it
verbatim rather than paraphrasing. Details: [reference/preflight.md](reference/preflight.md).
## 3. Work the compliance plan after deploying
```bash
checkbox plan --json # ordered tasks + next_action
checkbox fix --file # exact diff for a code task (printed, never written)
checkbox verify --wait --json # re-check; passed | failed (with diff) | pending
```
Repeat until the plan `status` is `compliant`. Tasks with `change.type: "manual"` need the human: ask them the
`question` and record their answer with `answerTask`; never answer for them. See
[reference/agent-loop.md](reference/agent-loop.md).
## Rules for any subscription code you write
- Disclosure directly above the pay button: price, billing interval, renews until cancelled, how to cancel online,
trial length and the charge after it. Body text size or larger, set off by a border or background.
- Consent checkbox for the renewal terms: unchecked by default, required, labelled with the terms.
- Acknowledgment email right after sign-up with the same terms and how to cancel; trial-ending and renewal reminders
inside each state's window (get dates from `notice_schedule`).
- Online cancellation reachable from the account page without calling or chatting; any retention offer must keep a
visible way to finish cancelling.
- Report `needs_review` items to the human. Checkbox output is not legal advice.
More: [reference/requirements.md](reference/requirements.md) (what each check means), full docs index
https://checkbox.site/llms.txt.
````
Reference files it points to: [preflight.md](https://checkbox.site/docs/integrations/claude-skill/checkbox/reference/preflight.md),
[agent-loop.md](https://checkbox.site/docs/integrations/claude-skill/checkbox/reference/agent-loop.md) and
[requirements.md](https://checkbox.site/docs/integrations/claude-skill/checkbox/reference/requirements.md).
### Cursor rule {#cursor-rule}
Save as `.cursor/rules/checkbox.mdc`. Cursor attaches it when you edit checkout, pricing, billing, email or
cancellation files:
```bash
mkdir -p .cursor/rules
curl -fsSL https://checkbox.site/docs/integrations/cursor/checkbox.mdc -o .cursor/rules/checkbox.mdc
```
```markdown title="cursor/checkbox.mdc"
---
description: Subscription-law compliance (Checkbox) for checkout, pricing, sign-up, subscription emails and cancellation code. Use when editing those flows or when asked to add Checkbox, an auto-renewal disclosure, a consent checkbox, reminder emails or a cancel flow.
globs: ["**/*checkout*", "**/*pricing*", "**/*subscri*", "**/*billing*", "**/*cancel*", "**/emails/**", "**/*stripe*"]
alwaysApply: false
---
# Checkbox: automatic-renewal compliance
This project uses Checkbox (https://checkbox.site/docs, agent index https://checkbox.site/llms.txt) to keep its
subscription flows compliant with ROSCA, California's Automatic Renewal Law, New York GBL § 527-a and other state laws.
Setup (once): the Checkbox MCP server (`https://app.checkbox.site/mcp`, tool `setup_checkbox`) or `POST /v1/device/authorize`.
A human approves once in the browser. Save the key to `.env.local` as `CHECKBOX_SECRET_KEY`; never print or commit it.
The `checkbox` CLI below is pre-release (not on npm yet); never install the unrelated npm package named `checkbox`.
Before committing changes to these flows, preflight them and loop until `verdict` is `pass`:
- Stripe Checkout params: `checkbox check stripe-session --file params.json --merchant-name --cancel-url --json` → apply `correction.patch`.
- Disclosure by the pay button: `checkbox check disclosure --text "…" --price --interval month --consent-checkbox --json` → use `replacement`.
- Rendered checkout HTML: `checkbox check page --file checkout.html --price
--interval month --json`.
- Emails: `checkbox check email --kind --file email.html --price --interval month --json` → use `template`.
After deploying: `checkbox plan --json`, apply the first open task, `checkbox verify --wait --json`, repeat until
`next_action.type` is `done`. Always follow `next_action`. Tasks of type `manual` need the human's answer; ask them.
Always:
- Renewal disclosure (price, interval, renews until cancelled, how to cancel, trial terms) directly above the pay
button, body size or larger, set off by a border or background. Prefer `` (Checkbox Elements).
- Consent checkbox unchecked by default and required.
- Online cancellation without a call or chat; retention offers keep a visible way to finish cancelling.
- Report `needs_review` results to the human; Checkbox output is not legal advice.
```
## Docs for machines {#docs-for-machines}
- [/llms.txt](https://checkbox.site/llms.txt) — the index of these docs in the [llms.txt](https://llmstxt.org) format, with links to the
Markdown version of every page; [/llms-full.txt](https://checkbox.site/llms-full.txt) — all pages in one file.
- Every page is Markdown at its URL plus `.md`, or with the request header `Accept: text/markdown`.
- `https://app.checkbox.site/v1/openapi.json` — OpenAPI 3.1 with every operation, field description, example,
required scope and error code. Each page's `` links it with `rel="service-desc"`.
---
Source: https://checkbox.site/docs/agent-loop
# The agent loop
> How a coding agent connects a project with one human click, learns the business, and works a compliance plan to done — with the API calls behind each step.
The builder says *"Add Checkbox"*. From there, Checkbox and the builder's agent talk to each other; the human clicks
**Approve** once and reviews the result. This page shows each step and the API behind it, so you can drive it from
the CLI, the [MCP server](https://checkbox.site/docs/mcp) or your own code.
```text
agent → MCP setup_checkbox (or the CLI: checkbox init --yes --json)
agent → POST /v1/device/authorize → a link with a code, e.g. BKRF-QXTP
human → opens the link, signs in (email link, GitHub or Google), clicks Approve
agent → POST /v1/device/token (polls) → ck_test_ + pk_test_ keys, setup session, site
agent → saves the key, adds the snippet to the root layout, reports the business URLs
Checkbox → fetches Terms / refund / cancellation pages, runs the first checks, (with permission) a test subscription
agent → get_compliance_plan → apply task → verify_task → … until next_action.type is "done"
human ← email: "Claude Code set up Checkbox for yoursite.com" with a review link (when the setup is finished)
```
## 1. Connect: one call, one click {#connect}
With the [MCP server](https://checkbox.site/docs/mcp), call `setup_checkbox` with what you know from the code; with plain HTTP, call
`POST /v1/device/authorize` and poll `POST /v1/device/token`. With the CLI:
```bash
npx @checkbox-site/cli init --yes --json --checkout-url https://joybox.example/pricing --merchant-name Joybox --plan 19.99/month,trial=7
```
> **Pre-release packages**
>
> The SDKs, the CLI and the local MCP server are not on npm or PyPI yet, and the package names shown here are
> placeholders (the CLI commands below run from a checkout of the repository today). Until this notice is gone, use the
> HTTP API (curl) or the remote MCP server at `https://app.checkbox.site/mcp`, which are live today. Never install an npm
> package named `checkbox`: it belongs to an unrelated project.
- The command prints exactly one JSON document on stdout. The approval link and progress go to stderr: show the link
to the human. New accounts are free and need no card.
- If the human has not approved yet, the result is `status: "awaiting_approval"` with
`next_action.command: "checkbox init --yes --json"`. Run it again; it resumes the same login.
- After approval the CLI writes `CHECKBOX_SECRET_KEY` and the publishable key to `.env.local` (and git-ignores it),
installs the snippet in the root layout (between `checkbox:snippet` markers), and registers your site and policy
pages.
What the CLI sends to Checkbox: framework, file paths and the matching lines of checkout code, URLs. Never your source
code or `.env` values. A Stripe **test** key is used only after the human ticks the box for it on the approval page,
and live keys are refused.
No shell? The MCP tool `setup_checkbox` does the same login: it returns the link for the human, then the keys.
## 2. Teach Checkbox the business {#setup-session}
The setup session is the checklist Checkbox keeps for the project. It always returns one `next_action`. An agent that
already has a key (for example from the dashboard) can start one directly:
```curl
curl https://app.checkbox.site/v1/setup_sessions \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"site_url": "https://joybox.example",
"checkout_url": "https://joybox.example/pricing",
"terms_url": "https://joybox.example/terms",
"billing_platform": "stripe",
"plans": [{ "name": "Pro", "amount": 1999, "currency": "usd", "interval": "month", "trial_days": 14 }]
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const session = await checkbox.setupSessions.create({
site_url: 'https://joybox.example',
checkout_url: 'https://joybox.example/pricing',
terms_url: 'https://joybox.example/terms',
billing_platform: 'stripe',
plans: [{ name: 'Pro', amount: 1999, currency: 'usd', interval: 'month', trial_days: 14 }],
});
console.log(session.steps.map((s) => `${s.key}: ${s.status}`));
console.log(session.next_action);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
session = checkbox.setup_sessions.create(
site_url="https://joybox.example",
checkout_url="https://joybox.example/pricing",
terms_url="https://joybox.example/terms",
billing_platform="stripe",
plans=[{"name": "Pro", "amount": 1999, "currency": "usd", "interval": "month", "trial_days": 14}],
)
print([(s["key"], s["status"]) for s in session["steps"]])
print(session["next_action"])
```
Steps are `account, site, snippet, policies, checks, fixes, lifecycle_test, domain, owner_notified`, each `done`,
`pending`, `action_required`, `skipped` or `failed`. A typical `next_action`:
```json
{
"type": "install_snippet",
"message": "Add to the of every page (root layout), then report snippet_installed_in with updateSetupSession.",
"operation_id": "updateSetupSession",
"command": "checkbox init --yes --json"
}
```
Report what you did with `updateSetupSession` (`snippet_installed_in`, `refund_url`, `plans`…). After deploying, call
`verifySetupSession` (`checkbox init --verify --yes --json`): Checkbox loads the site, confirms the snippet is live,
re-fetches the policies, re-evaluates and queues the first scan. `completeSetupSession` sends the human the summary
email. Policy pages are fetched and checked against the law too: a Terms of Service that says "no cancellations" or a
refund policy that takes back a money-back promise on your pricing page shows up as a task.
## 3. See every lifecycle step: the test subscription {#test-run}
With a Stripe **test-mode** key, Checkbox runs a synthetic subscription like a CMS preview: it subscribes a test
customer with a test card, receives your acknowledgment and reminder emails at its own inbox, moves a Stripe test clock
through the trial end and the first renewal, and cancels online. Every lifecycle check is observed, not inferred.
Nothing is charged. See [Test subscriptions](https://checkbox.site/docs/guides/test-runs).
## 4. Work the compliance plan {#plan}
```curl
curl https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/plan \
-u "$CHECKBOX_SECRET_KEY:"
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const plan = await checkbox.plans.retrieve('site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b');
console.log(plan.status, plan.summary);
console.log(plan.next_action);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
plan = checkbox.plans.retrieve("site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b")
print(plan["status"], plan["summary"])
print(plan["next_action"])
```
The plan is an ordered list of tasks. Each task carries:
| Field | What it holds |
|---|---|
| `requirement` | The law: jurisdictions, `citation`, a plain-language statement |
| `why` | What Checkbox observed (and where) |
| `where` | `file_hint`, `url`, `selector`, or the Stripe object to change |
| `change` | `type` (`patch`, `copy`, `stripe_params`, `config`, `manual`), the exact `content` (a diff template, the wording, the Stripe params) and machine-applicable `edits` |
| `verify` | How Checkbox will confirm it (`page_fetch`, `stripe_params`, `policy_refetch`, `email_copy`, `platform_sync`, `evaluation`) |
| `next_action` | What to call after applying it |
Plan `status`: `action_required` (an agent can apply open tasks), `verifying` (only confirmations pending), `blocked`
(only human answers remain, or a critical/high task was declined), `compliant`. Before the first evaluation the plan's
`next_action` is `run_first_check`: call `verifySite`.
## 5. Verify, and repeat {#verify}
After applying a task, ask Checkbox to check it. Send what changed — the rendered HTML before you deploy, the new
Stripe params, or the new email copy — and Checkbox runs the fastest re-check now and queues the authoritative one
(a scan, a billing sync, the next real email):
```bash
checkbox verify task_8c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f --wait --json
```
To re-check the whole site (for example after a deploy):
```curl
curl -X POST https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/verify \
-u "$CHECKBOX_SECRET_KEY:"
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const verification = await checkbox.sites.verify('site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b');
console.log(verification.status, verification.next_action);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
verification = checkbox.sites.verify("site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b")
print(verification["status"], verification["next_action"])
```
A verification is `passed`, `failed` (with what is still wrong) or `pending`; poll
`GET /v1/verifications/{id}?wait=30` or subscribe to the `task.verified` [webhook](https://checkbox.site/docs/webhooks). Fetch the plan
again and continue until `status` is `compliant` — the `site.compliant` event fires once when it gets there.
### Questions only a human can answer {#manual-tasks}
Some requirements cannot be observed: for example, New York requires reminders "in the manner the consumer selected".
Those become `manual` tasks with a `question`. The agent asks the human and records the answer with `answerTask`; it
never answers on the human's behalf. Manual tasks never block the others, and the plan summary says how many items rest
on a human confirmation rather than an observation.
## `next_action` {#next-action}
Every agent-facing object and every error carries `next_action`: `type` (stable), a short `message` (setup, account,
checks) or `description` (plans, verifications) for the model, and where useful `operation_id` (the API operation and
SDK method to call), `endpoint`, `command` (the CLI equivalent) or `url`. Follow it; do not guess.
---
Source: https://checkbox.site/docs/concepts/requirements
# Requirements and jurisdictions
> The legal catalog behind every Checkbox verdict — federal and state automatic-renewal requirements with citations, effective dates and the conditions under which they apply.
A **requirement** is one obligation from one law: "disclose the recurring price before the consumer pays", "send a
reminder 3 to 21 days before a free trial longer than 31 days converts". Each has an id (`US-CA.17602.a.1`), a
**jurisdiction** (`US-FED`, `US-CA`, `US-NY`…), a citation and source URL, an effective date, a lifecycle stage, a
severity, the conditions under which it applies, a notice window where timing matters, and the **checks** that verify
it.
The catalog currently holds **196 requirements in 29 jurisdictions** (catalog version `2026.10.31.1`, last verified against primary sources on 2026-10-29; rules version `1.3.0`).
## How applicability works {#applicability}
For each evaluation Checkbox selects the requirements that apply:
1. **Jurisdiction.** The site's `jurisdictions` (empty means all; `US-FED` always applies). Preflight checks take a
`jurisdictions` parameter (`"all"`, or state codes such as `["US-CA", "US-NY"]`).
2. **In force.** Effective on the evaluation date (`as_of`) and not superseded. Laws enacted with a future effective date
are already in the catalog and start applying on that date automatically.
3. **Facts.** `appliesWhen` conditions against the business facts: free trial and its length, term length (for
example annual reminders for terms of a year or more), online sign-up, payment methods (Regulation E covers
recurring debits from a bank account or debit card).
Each check then runs once, and its finding lists every applicable requirement that references it, with the strictest
severity. You see one finding per check with all the jurisdictions it matters for.
## Laws in the catalog {#laws}
| Jurisdiction | Law | Citation | Effective | Status | Confidence | Verified from | Requirements |
|---|---|---|---|---|---|---|---|
| Federal | [Restore Online Shoppers' Confidence Act (ROSCA)](https://www.law.cornell.edu/uscode/text/15/8403) | 15 U.S.C. §§ 8401-8405 (Pub. L. 111-345) | 2010-12-29 | in force | high | primary | 5 |
| Federal | [Electronic Fund Transfer Act / Regulation E — preauthorized transfers](https://www.ecfr.gov/current/title-12/chapter-X/part-1005/subpart-A/section-1005.10) | 15 U.S.C. § 1693e; 12 C.F.R. § 1005.10 | 1980-05-10 | in force | high | primary | 2 |
| Federal | [FTC Negative Option Rule ("Use of Prenotification Negative Option Plans")](https://www.federalregister.gov/documents/2026/02/12/2026-02866/revision-of-the-negative-option-rule-withdrawal-of-the-cars-rule-removal-of-the-non-compete-rule-to) | 16 C.F.R. Part 425 | 2026-02-12 | not cataloged | high | primary | 0 |
| California | [California Automatic Renewal Law](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?lawCode=BPC&division=7.&title=&part=3.&chapter=1.&article=9.) | Cal. Bus. & Prof. Code §§ 17600-17606 | 2010-12-01 (amended 2018-07-01, 2022-07-01, 2025-07-01) | in force | high | primary | 22 |
| New York | [New York Automatic Renewal Law (Prohibited Service Offer Practices)](https://www.nysenate.gov/legislation/laws/GBS/527-A) | N.Y. Gen. Bus. Law §§ 527, 527-a (Art. 29-BB) | 2021-02-09 (amended 2023-12-13, 2025-11-05) | in force | high | primary | 16 |
| New York | [New York City "Click to Cancel" Rule (DCWP)](https://www.nyc.gov/site/dca/news/048-26/mamdani-administration-landmark-consumer-protection-rules-ban-subscription-traps-and) | 6 RCNY § 5-110.1 | 2026-10-01 | not cataloged | medium | secondary | 0 |
| Alaska | [Alaska free trial period law](https://www.akleg.gov/pdf/23/Bills/Final/HB0339.pdf) | Alaska Stat. § 45.45.920; § 45.50.471(b)(47) | 2004-09-12 | in force | medium | primary partial | 3 |
| Arkansas | [Arkansas automatic renewal and continuous service offers law (Act 652 of 2025)](https://arkleg.state.ar.us/Home/FTPDocument?path=%2FACTS%2F2025R%2FPublic%2FACT652.pdf) | Ark. Code Ann. § 4-86-112 | 2025-08-05 | in force | high | primary | 14 |
| Colorado | [Colorado automatic renewal contracts law](https://leg.colorado.gov/sites/default/files/images/olls/crs2024-title-06.pdf) | C.R.S. § 6-1-732 | 2022-01-01 (amended 2025-08-06, 2026-02-16) | in force | high | primary | 7 |
| Connecticut | [Connecticut automatic renewal and continuous services law](https://www.cga.ct.gov/2026/sup/chap_742d.htm#sec_42-158ff) | Conn. Gen. Stat. § 42-158ff | 2023-10-01 (amended 2025-10-01, 2026-07-01) | in force | high | primary | 11 |
| Delaware | [Delaware consumer contracts — automatic renewal provisions](https://delcode.delaware.gov/title6/c027/sc04/index.html) | 6 Del. C. §§ 2731-2737 | 2022-01-01 (amended 2023-09-21) | in force | high | primary | 3 |
| District of Columbia | [Automatic Renewal Protections Act of 2018](https://code.dccouncil.gov/us/dc/council/code/sections/28A-203) | D.C. Code §§ 28A-201 to 28A-204 | 2019-09-11 | in force | high | primary | 5 |
| Florida | [Florida automatic renewal of service contracts](https://www.leg.state.fl.us/statutes/index.cfm?App_mode=Display_Statute&URL=0500-0599/0501/Sections/0501.165.html) | Fla. Stat. § 501.165 | 2010-07-01 (amended 2022-06-03) | in force | high | primary | 3 |
| Georgia | [Georgia Online Automatic Renewal Transparency Act](https://gov.georgia.gov/document/2023-signed-legislation/hb-528/download) | O.C.G.A. §§ 10-1-439.5 to 10-1-439.13 | 2024-01-01 | in force | high | primary partial | 6 |
| Hawaii | [Hawaii automatic renewal and continuous service clauses law](https://www.capitol.hawaii.gov/hrscurrent/Vol11_Ch0476-0490/HRS0481/HRS_0481-0009_0005.htm) | Haw. Rev. Stat. § 481-9.5 | 2012-07-01 (amended 2015-07-01, 2023-07-03) | in force | high | primary | 7 |
| Idaho | [Idaho cancellation of subscriptions law](https://legislature.idaho.gov/statutesrules/idstat/Title48/T48CH6/SECT48-603G/) | Idaho Code § 48-603G | 2023-01-01 (amended 2023-07-01) | in force | high | primary | 3 |
| Illinois | [Illinois Automatic Contract Renewal Act](https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=2296&ChapterID=67) | 815 ILCS 601 | 2005-01-01 (amended 2022-01-01, 2024-01-01, 2025-01-01) | in force | high | primary | 7 |
| Kentucky | [Kentucky automatic renewal and continuous service offers law](https://apps.legislature.ky.gov/law/statutes/statute.aspx?id=54220) | Ky. Rev. Stat. §§ 365.400-365.408 | 2024-01-01 | in force | high | primary | 6 |
| Louisiana | [Louisiana contracts with automatic renewal clauses](https://legis.la.gov/Legis/Law.aspx?d=725425) | La. R.S. 9:2716 | 2011-01-01 | in force | high | primary | 2 |
| Louisiana | [Louisiana Click-to-Cancel Act](https://www.legis.la.gov/Legis/ViewDocument.aspx?d=1481459) | La. R.S. 51:3301-3305 (Act 830 of 2026, HB 750) | 2027-01-01 | enacted not yet effective | high | primary | 9 |
| Maine | [Maine automatic subscription or health club membership renewal law](https://legislature.maine.gov/statutes/10/title10sec1210-C.html) | 10 M.R.S. §§ 1210-C, 1210-D (ch. 205-B) | 2020-01-02 (amended 2026-01-01) | in force | high | primary | 6 |
| Maine | [Maine charges after free trial period](https://legislature.maine.gov/statutes/10/title10sec1210.html) | 10 M.R.S. §§ 1210-1210-B (ch. 205-A) | 2009-09-12 | in force | medium | primary | 1 |
| Maryland | [Maryland Consumer Protection — Automatic Renewals (2025 chs. 204, 205)](https://mgaleg.maryland.gov/mgawebsite/Laws/StatuteText?article=gcl§ion=14-1329&enactments=false) | Md. Code Ann., Com. Law § 14-1329 | 2026-06-01 | in force | high | primary | 7 |
| Massachusetts | [Massachusetts Attorney General regulation — Unfair and Deceptive Fees (recurring fees and trial offers)](https://www.mass.gov/regulations/940-CMR-3800-unfair-and-deceptive-fees) | 940 CMR 38.05 (940 CMR 38.00) | 2025-09-02 | in force | high | primary | 6 |
| Minnesota | [Minnesota automatic renewal and continuous service law](https://www.revisor.mn.gov/statutes/cite/325G.57) | Minn. Stat. §§ 325G.56-325G.63 | 2025-01-01 | in force | high | primary | 9 |
| New Mexico | [New Mexico rule — Automatic Renewal of Service Contracts](https://www.srca.nm.gov/parts/title12/12.002.0011.html) | 12.2.11 NMAC | 2009-09-15 | in force | medium | primary | 3 |
| North Carolina | [North Carolina contracts with automatic renewal clauses](https://www.ncleg.gov/EnactedLegislation/Statutes/HTML/BySection/Chapter_75/GS_75-41.html) | N.C. Gen. Stat. § 75-41 | 2016-07-26 (amended 2018-10-01) | in force | high | primary | 4 |
| North Dakota | [North Dakota customer contract clauses and automatic renewals](https://ndlegis.gov/cencode/t51c37.pdf) | N.D. Cent. Code ch. 51-37 | 2019-08-01 (amended 2023-08-01) | in force | high | primary | 7 |
| Oregon | [Oregon automatic renewal and continuous service offers law](https://www.oregonlegislature.gov/bills_laws/ors/ors646A.html) | Or. Rev. Stat. §§ 646A.292-646A.295 | 2012-01-01 | in force | high | primary | 5 |
| Oregon | [Oregon free offer law](https://www.oregonlegislature.gov/bills_laws/ors/ors646.html) | Or. Rev. Stat. § 646.644 | 2012-01-01 | in force | high | primary | 3 |
| South Carolina | [South Carolina automatic renewal provisions in service contracts](https://www.scstatehouse.gov/code/t37c006.php) | S.C. Code Ann. § 37-6-120 (2024 Act No. 159) | 2024-05-20 | in force | high | primary | 1 |
| Tennessee | [Tennessee automatic renewal of subscription services (Consumer Protection Act)](https://capitol.tn.gov/Bills/112/Bill/SB2279.pdf) | Tenn. Code Ann. § 47-18-133; § 47-18-103 | 2023-01-01 (amended 2024-07-01) | in force | high | primary partial | 8 |
| Utah | [Utah Automatic Renewal Contracts Act](https://le.utah.gov/xcode/Title13/Chapter70/13-70.html) | Utah Code Ann. §§ 13-70-101 to 13-70-301 | 2025-01-01 (amended 2026-05-06) | in force | high | primary | 2 |
| Vermont | [Vermont consumer contracts; automatic renewal](https://legislature.vermont.gov/statutes/section/09/063/02454a) | 9 V.S.A. § 2454a | 2019-07-01 (amended 2020-07-01) | in force | high | primary | 5 |
| Virginia | [Virginia Automatic Renewal Offers and Continuous Service Offers](https://law.lis.virginia.gov/vacode/title59.1/chapter17.8/section59.1-207.46/) | Va. Code Ann. §§ 59.1-207.45 to 59.1-207.49 | 2018-07-01 (amended 2022-07-01, 2023-07-01, 2024-07-01, 2026-07-01) | in force | high | primary | 9 |
| Wisconsin | [Wisconsin renewals and extensions of business contracts](https://docs.legis.wisconsin.gov/statutes/statutes/134/49) | Wis. Stat. § 134.49 (2009 Wis. Act 192) | 2011-05-01 | not cataloged | medium | secondary | 0 |
"Not cataloged" laws were researched and deliberately not turned into requirements; the summary on each says why.
The per-state requirements are on [State automatic-renewal laws](https://checkbox.site/docs/learn/state-automatic-renewal-laws).
## Keeping up with changes {#law-updates}
The catalog is versioned (`catalog_version` on every result) and hashed (`catalog_hash`), so a verdict can always be
traced to the law it applied. When a law changes, Checkbox publishes a law update (`GET /v1/law_updates`), re-evaluates
affected sites and sends the `law.changed` [webhook](https://checkbox.site/docs/webhooks).
> **Not legal advice**
>
> Every requirement is drafted from primary sources (statutes and regulations) and is pending attorney review. Checkbox
> does not interpret the law for your specific business; talk to counsel about your obligations.
---
Source: https://checkbox.site/docs/concepts/checks
# Checks and verdicts
> The machine checks Checkbox runs at each lifecycle stage, what pass, fail, needs_review and not_applicable mean, and how scores and the insurable flag are computed.
A **check** verifies one observable thing — "the consent checkbox is not pre-checked", "a trial reminder arrived inside
the window". Checks are implemented once and reused by every law that requires the same thing; the
[catalog](https://checkbox.site/docs/concepts/requirements) maps requirements to checks.
## Verdicts {#verdicts}
| Status | Meaning |
|---|---|
| `pass` | Observed, and what was observed meets the requirement (an automated assessment, not a legal determination). A check never passes for lack of data. |
| `fail` | Observed, and it does not meet the requirement. The result says what was seen and how to fix it. |
| `needs_review` | Checkbox lacks the evidence to decide, or a person must judge (for example "clear and conspicuous" on a page Checkbox cannot restyle). The result says which. |
| `not_applicable` | No applicable requirement uses the check (for example trial checks without a free trial). |
A preflight result's `verdict` is the worst status among its checks: `fail` > `needs_review` > `pass`
(`not_applicable` when nothing applies).
## Evidence sources {#sources}
| Source | What it provides |
|---|---|
| Synthetic shopper | Headless Chromium visits the checkout from each state, on desktop and mobile, optionally completes a sign-up and tries to cancel online |
| Snippet | What real visitors see on your own pages, including A/B variants; content changes trigger a re-scan. Snippet captures corroborate: they never produce a pass on their own |
| Billing platform | Plans, trials, portal and checkout settings; webhooks become lifecycle events |
| Email | Your acknowledgment and reminder emails, BCC'd to the site's inbound address or received during a [test subscription](https://checkbox.site/docs/guides/test-runs) |
| Policies | Your Terms, refund and cancellation pages, fetched and checked for consistency |
## Every check {#all-checks}
### Sign-up
| Check | What it verifies | Laws that require it |
|---|---|---|
| `signup.disclosure.autorenew_language` | Discloses that the subscription renews automatically until canceled | 25 jurisdictions |
| `signup.disclosure.price` | Discloses the recurring charge amount | 22 jurisdictions |
| `signup.disclosure.frequency` | Discloses the billing frequency | 17 jurisdictions |
| `signup.disclosure.cancellation_policy` | Discloses the cancellation policy and how to cancel | 24 jurisdictions |
| `signup.disclosure.trial_terms` | Discloses free-trial length and the charge after the trial | 16 jurisdictions |
| `signup.disclosure.term_length` | Discloses the length of the renewal term (or that service is continuous) and any minimum purchase obligation | 20 jurisdictions |
| `signup.disclosure.proximity` | Terms appear before the purchase button and in visual proximity to it | 16 jurisdictions |
| `signup.disclosure.conspicuous` | Terms are clear and conspicuous (size, contrast, not hidden) | 27 jurisdictions |
| `signup.consent.affirmative` | Obtains affirmative consent to the automatic-renewal terms | 20 jurisdictions |
| `signup.consent.not_prechecked` | Consent checkboxes are not pre-checked | 20 jurisdictions |
### Acknowledgment
| Check | What it verifies | Laws that require it |
|---|---|---|
| `confirmation.email.sent` | Sends an acknowledgment after sign-up in a retainable form | 15 jurisdictions |
| `confirmation.email.terms` | Acknowledgment restates the automatic-renewal terms | 15 jurisdictions |
| `confirmation.email.cancellation_instructions` | Acknowledgment explains how to cancel | 15 jurisdictions |
| `confirmation.email.trial_terms` | Acknowledgment explains how to cancel before the trial converts to paid | 12 jurisdictions |
### Reminders
| Check | What it verifies | Laws that require it |
|---|---|---|
| `reminder.trial_ending` | Sends a reminder before a free trial converts to a paid subscription | 13 jurisdictions |
| `reminder.annual_renewal` | Sends a renewal reminder before long-term (e.g. annual) subscriptions renew | 22 jurisdictions |
| `reminder.annual_terms_notice` | Sends an annual reminder of the subscription terms and how to cancel (incl. monthly/continuous plans) | 5 jurisdictions |
| `reminder.charge_notice` | Sends a notice before (or promptly after) recurring charges where required | 2 jurisdictions |
| `reminder.price_change` | Gives advance notice of price changes | 16 jurisdictions |
### Cancellation
| Check | What it verifies | Laws that require it |
|---|---|---|
| `cancel.online_available` | Consumers who signed up online can cancel online | 19 jurisdictions |
| `cancel.mechanism_findable` | Cancellation option is easy to find (e.g. prominent link in account) | 25 jurisdictions |
| `cancel.flow_friction` | Cancellation is not obstructed (no forced calls/chat, limited save offers, few steps) | 18 jurisdictions |
| `cancel.confirmation` | Confirms the cancellation to the consumer | 12 jurisdictions |
| `terms.cancellation_policy_consistent` | Terms of service do not contradict online cancellation (no "no cancellations" / cancel-by-phone-or-mail clauses) | 2 jurisdictions |
| `terms.refund_policy_consistent` | Refund policy is consistent with refund / money-back claims made in marketing and checkout | 1 jurisdiction |
### Billing settings
| Check | What it verifies | Laws that require it |
|---|---|---|
| `config.portal_cancel_enabled` | Billing platform self-serve cancellation is enabled | 19 jurisdictions |
| `config.trial_reminder_enabled` | Billing platform trial-ending reminder emails are enabled | 13 jurisdictions |
| `terms.renewal_terms_present` | Terms of service state the automatic-renewal terms and how to cancel | 1 jurisdiction |
## Severity, score and insurable {#score}
Each finding's severity is the strictest among the requirements that use the check: `critical`, `high`, `medium` or
`low`. A site's **score** (0–100) weighs passing checks by severity (critical 10, high 5, medium 2, low 1;
`needs_review` counts half). A site is **insurable** when no critical or high check fails, no critical check is left at
`needs_review`, and no high-severity obligation is without any evidence. A future compliance warranty will key on
that flag; Checkbox does not provide insurance today.
## Reproducibility {#reproducibility}
Every result records `rules_version`, `catalog_version` and `catalog_hash`. Preflight checks are deterministic: the
same input and the same `as_of` date give the same verdicts.
---
Source: https://checkbox.site/docs/concepts/evidence
# Evidence
> How Checkbox stores what it observed in a tamper-evident, hash-chained and signed evidence vault, and how to list, download and verify it.
Every observation behind a finding — a checkout screenshot and its HTML, an email, a billing-platform setting, a
consent record, an evaluation — is stored as an **evidence** record. Findings reference the evidence they rest on, so
you can show exactly what a subscriber saw and when.
## How it is protected {#integrity}
- **Content-addressed.** Each record's content is stored under its SHA-256 hash.
- **Hash-chained per site.** Each record includes the hash of the previous one, so removing or changing any record
breaks the chain.
- **Signed anchors.** Chain heads are signed and anchored periodically; production storage uses S3 Object Lock, so
records cannot be altered or deleted during the retention period.
- **Verifiable by anyone.** Evidence exports include a standalone verifier.
## List, download and verify {#api}
```curl
curl -G https://app.checkbox.site/v1/evidence \
-u "$CHECKBOX_SECRET_KEY:" \
-d site=site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b \
-d limit=5
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const evidence = await checkbox.evidence.list({ site: 'site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b', limit: 5 });
for (const record of evidence.data) console.log(record.id, record.kind, record.stored);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
evidence = checkbox.evidence.list(site="site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b", limit=5)
for record in evidence.data:
print(record["id"], record["kind"], record["stored"])
```
Verify a site's whole chain:
```curl
curl https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/evidence/verify \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const result = await checkbox.evidence.verifyChain('site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b');
console.log(result);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
result = checkbox.evidence.verify_chain("site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b")
print(result)
```
Download a record's content with `downloadEvidenceContent` (`GET /v1/evidence/{evidence}/content`). See the
[Evidence API](https://checkbox.site/docs/api/evidence).
## Monitoring certificates {#certificates}
A site with continuous monitoring can be issued a signed **monitoring certificate** with a public verification page
and a badge (`createCertificate`). A certificate states what was monitored and when; it is not insurance and not a
statement that the business complies with the law. It lapses when monitoring stops being fresh or the site's URL
changes.
---
Source: https://checkbox.site/docs/concepts/test-and-live
# Test mode and live mode
> Test keys act on an isolated sandbox that never needs activation; live keys monitor your real site once your domain is verified.
Every Checkbox account has two modes, chosen by the key you send — the same model as Stripe.
| | Test mode | Live mode |
|---|---|---|
| Secret key | `ck_test_…` | `ck_live_…` (older organization keys `sk_live_…` also work) |
| Publishable key (browser) | `pk_test_…` | `pk_live_…` |
| Data | An isolated sandbox: sites, findings, evidence and events you create with test keys | Your real sites |
| Activation | Never needed | [Verify a domain](https://checkbox.site/docs/concepts/activation) once |
| Scheduled monitoring | Off by default | Daily by default (`monitoring_interval_minutes`) |
| Preflight checks, plans, setup sessions | Yes | Yes |
| Stripe test subscriptions ([test runs](https://checkbox.site/docs/guides/test-runs)) | Yes | Yes (always against Stripe **test** mode) |
Test keys are free and one click away, so test mode only touches **your** site: Checkbox scans, monitors, fetches pages
and runs [test runs](https://checkbox.site/docs/guides/test-runs) for `localhost` / private addresses (local development) and for hosts within
a domain your account has [verified](https://checkbox.site/docs/concepts/activation) (in either mode). For any other host, test mode gives a
few on-demand scans a day (`429 test_mode_scan_budget_exhausted` after that), no scheduled monitoring (held, like live
monitoring before activation), no server-side page fetch (send the rendered HTML instead) and no test runs
(`403 test_mode_domain_unverified`). Verifying the domain lifts all of it and starts held monitoring.
Every object has `livemode: true | false`, and every response carries the `Checkbox-Mode: test | live` header. Objects
never cross modes: a test key cannot read a live site, and the reverse.
## Restricted keys {#restricted-keys}
Restricted keys (`rk_test_…`, `rk_live_…`) carry per-resource scopes such as `{ "checks": "read" }` or
`{ "sites": "write" }` (write implies read). Give CI jobs and agents the least they need: a key with only
`checks: read` can run every preflight check and nothing else. Each operation's required scope is listed in the
[API reference](https://checkbox.site/docs/api) and in the OpenAPI document (`x-checkbox-scope`).
## Publishable keys {#publishable-keys}
Publishable keys are safe in browser code. They work only for the browser-facing endpoints of
[Checkbox Elements](https://checkbox.site/docs/elements) (recording a consent, loading a disclosure), and only from pages on your site's
domains (the `Origin` is checked). Every other endpoint refuses them with `publishable_key_not_allowed`.
## Which key do I have? {#which-key}
```curl
curl https://app.checkbox.site/v1/account \
-u "$CHECKBOX_SECRET_KEY:"
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
console.log(checkbox.mode); // 'test' or 'live', from the key prefix
const account = await checkbox.account.retrieve();
console.log(account.livemode, account.activation.status);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
print(checkbox.mode) # "test" or "live", from the key prefix
account = checkbox.account.retrieve()
print(account["livemode"], account["activation"]["status"])
```
---
Source: https://checkbox.site/docs/concepts/activation
# Activation
> Live mode turns on when you prove you control a site's domain, with a DNS TXT record or a file at /.well-known — like verifying a sending domain.
Test mode works immediately. Live mode — real scans of your site, certificates, sending notices — turns on for the
whole account the first time you verify the domain of one of your sites. There is no sales call, no card and no review.
Until then, live-mode operations that act on a real site (scans, certificates, turning on Notices) answer:
```json
{
"error": {
"type": "permission_error",
"code": "account_not_activated",
"message": "Live mode needs an activated account: verify the domain of one of your sites (or use a test key).",
"next_action": { "type": "verify_domain", "operation_id": "createDomainVerification" }
}
}
```
Live sites created before activation are stored with monitoring **held** (`monitoring.held_for_activation: true`);
monitoring starts by itself when the account is activated.
## Verify a domain {#verify}
Start a verification for a live site. You get two ways to prove control; either one works:
```bash
curl -X POST https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/domain_verification \
-u "$CHECKBOX_LIVE_KEY:"
```
1. **DNS:** a TXT record at `_checkbox-verify.` with the value in the response, or
2. **File:** serve the token at `https:///.well-known/checkbox-verify.txt`. `checkbox init --live`
writes this file into your project's public folder for you.
Then ask Checkbox to look (it also re-checks on its own for a while):
```bash
curl -X POST https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/domain_verification/check \
-u "$CHECKBOX_LIVE_KEY:"
```
When it succeeds, `account.activation.status` becomes `active` (`method: "domain"`) and held monitoring starts.
## Fair use {#fair-use}
Checkbox is free to start, with no plan limits on compliance features. Fair-use limits apply: 25 active sites per
account and mode, 300 API requests per minute per account and mode (`RateLimit-*` headers; `429 rate_limit_exceeded`
with `Retry-After`), 16 webhook endpoints per mode, and per-route limits on scans and evaluations. Ask
[support@checkbox.site](mailto:support@checkbox.site) to raise them.
---
Source: https://checkbox.site/docs/guides/stripe-checkout
# Stripe Checkout
> Make a Stripe Checkout subscription sign-up compliant — the exact Checkout Session params, the consent checkbox, the disclosure before the redirect, and how to verify it.
Stripe-hosted Checkout shows the price and Stripe's own authorization line, but by default it does not state that
the subscription renews until cancelled, how to cancel, or ask for consent to those terms. Checkbox gives you the
exact `stripe.checkout.sessions.create` parameters that fix that, verified by the rules engine.
[How to make Stripe Checkout auto-renewal compliant](https://checkbox.site/docs/learn/stripe-checkout-auto-renewal-compliance) explains
the law behind each change.
## 1. Preflight the params your code sends {#preflight}
Send the params object exactly as your code builds it. When `line_items` reference a Price id, also pass the price and
interval in `merchant` (Checkbox does not call Stripe during a preflight):
```curl
curl https://app.checkbox.site/v1/checks/stripe_checkout_session \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"params": {
"mode": "subscription",
"line_items": [{ "price": "price_1Q2w3E", "quantity": 1 }],
"success_url": "https://joybox.example/welcome"
},
"merchant": {
"merchant_name": "Joybox",
"price": 19.99,
"interval": "month",
"cancel_url": "https://joybox.example/account/cancel"
}
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const params = {
mode: 'subscription',
line_items: [{ price: 'price_1Q2w3E', quantity: 1 }],
success_url: 'https://joybox.example/welcome',
};
const result = await checkbox.checks.stripeCheckoutSession({
params,
merchant: { merchant_name: 'Joybox', price: 19.99, interval: 'month', cancel_url: 'https://joybox.example/account/cancel' },
});
for (const check of result.checks) console.log(check.status.padEnd(12), check.check_id);
console.log(JSON.stringify(result.correction.patch, null, 2));
```
```python
import json
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
params = {
"mode": "subscription",
"line_items": [{"price": "price_1Q2w3E", "quantity": 1}],
"success_url": "https://joybox.example/welcome",
}
result = checkbox.checks.stripe_checkout_session(
params=params,
merchant={"merchant_name": "Joybox", "price": 19.99, "interval": "month",
"cancel_url": "https://joybox.example/account/cancel"},
)
for check in result["checks"]:
print(check["status"].ljust(12), check["check_id"])
print(json.dumps(result["correction"]["patch"], indent=2))
```
Or from the terminal, with your params in a file:
```bash
cat > session.json <<'EOF'
{ "mode": "subscription", "line_items": [{ "price": "price_1Q2w3E", "quantity": 1 }], "success_url": "https://joybox.example/welcome" }
EOF
checkbox check stripe-session --file session.json --merchant-name Joybox --price 19.99 --interval month \
--cancel-url https://joybox.example/account/cancel --offline
```
`--offline` runs the same rules engine locally, without a key. The command exits with code 1 while a check fails, so it
works as a CI gate.
## 2. Apply the correction {#apply}
The correction adds two things to your params:
- `consent_collection.terms_of_service: "required"` — Stripe shows an **unchecked** checkbox the customer must tick.
It needs a Terms of Service URL in Stripe (Dashboard → Settings → Public details).
- `custom_text.terms_of_service_acceptance.message` — the checkbox label, stating the renewal terms; and
`custom_text.submit.message` — the full disclosure next to the Subscribe button: price, interval, renews until
cancelled, how to cancel online, when cancellation takes effect, the trial and the charge after it.
The wording is generated from your terms and verified by the engine; use it as is. Then check again: the patch comes back
empty when nothing is left to change.
## 3. Show the terms before the redirect {#before-redirect}
One check stays `needs_review` on any Stripe-hosted page: **clear and conspicuous**. Stripe renders custom text in its own
small grey style, and you cannot make it larger or set it off. Close the gap on your own page, before you redirect to
Stripe: show the same disclosure next to the "Subscribe" button that creates the Checkout Session, set off in a box at
body size or larger. [Checkbox Elements](https://checkbox.site/docs/elements) renders it for you, or ask for the HTML with
[`checkDisclosure`](https://checkbox.site/docs/api/checks#checkDisclosure) (`replacement.html`).
## 4. Monitor the live flow {#monitor}
Register the site with `platform: "stripe"` ([quickstart](https://checkbox.site/docs/quickstart#register-your-site)) and connect Stripe
with a read-only restricted key in the dashboard (**Site → Integrations → Stripe**: Prices and Products read are
required; Subscriptions, Customer portal and Checkout Sessions read add coverage). Checkbox then reads your recent
Checkout Sessions' custom text and consent settings, your prices and trials, and your customer-portal settings, and the
synthetic shopper scans the real hosted page from each state.
To see the whole lifecycle — acknowledgment email, trial reminder, renewal and online cancellation — run a
[test subscription](https://checkbox.site/docs/guides/test-runs) with a Stripe test-mode key. You can register the exact params your code
uses so the test run mirrors them:
```curl
curl https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/stripe_checkout_configs \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"params": {
"mode": "subscription",
"line_items": [{ "price": "price_1Q2w3E", "quantity": 1 }],
"consent_collection": { "terms_of_service": "required" }
}
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const config = await checkbox.stripeCheckoutConfigs.create('site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b', {
params: {
mode: 'subscription',
line_items: [{ price: 'price_1Q2w3E', quantity: 1 }],
consent_collection: { terms_of_service: 'required' },
},
});
console.log(config.id);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
config = checkbox.stripe_checkout_configs.create(
"site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b",
params={
"mode": "subscription",
"line_items": [{"price": "price_1Q2w3E", "quantity": 1}],
"consent_collection": {"terms_of_service": "required"},
},
)
print(config["id"])
```
## Checklist {#checklist}
- [ ] `consent_collection.terms_of_service: "required"` with a renewal-terms label
- [ ] `custom_text.submit.message` with price, interval, renewal until cancelled, how to cancel, trial terms
- [ ] The same disclosure, set off, on your page before the redirect
- [ ] Acknowledgment email after `checkout.session.completed` ([emails](https://checkbox.site/docs/guides/emails-and-notices))
- [ ] Online cancellation: the [customer portal](https://checkbox.site/docs/guides/stripe-customer-portal) or a [hosted cancellation page](https://checkbox.site/docs/guides/cancellation)
---
Source: https://checkbox.site/docs/guides/stripe-payment-links
# Stripe Payment Links
> Check a subscription Payment Link's params, add the consent checkbox and renewal terms, and update existing links.
Payment Links render the same Stripe-hosted page as Checkout, so they need the same two additions: a required consent
checkbox labelled with the renewal terms, and the renewal disclosure next to the Subscribe button.
## Preflight a link {#preflight}
Send the `paymentLinks.create` params — or a link you retrieved from Stripe, including its id. When `line_items` use a
Price id, add the price and interval in `merchant`:
```curl
curl https://app.checkbox.site/v1/checks/stripe_payment_link \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"params": { "line_items": [{ "price": "price_1Q2w3E", "quantity": 1 }] },
"merchant": {
"merchant_name": "Joybox",
"price": 19.99,
"interval": "month",
"cancel_url": "https://joybox.example/account/cancel"
}
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const result = await checkbox.checks.stripePaymentLink({
params: { line_items: [{ price: 'price_1Q2w3E', quantity: 1 }] },
merchant: { merchant_name: 'Joybox', price: 19.99, interval: 'month', cancel_url: 'https://joybox.example/account/cancel' },
});
console.log(result.verdict);
console.log(result.correction.corrected_params.custom_text);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
result = checkbox.checks.stripe_payment_link(
params={"line_items": [{"price": "price_1Q2w3E", "quantity": 1}]},
merchant={"merchant_name": "Joybox", "price": 19.99, "interval": "month",
"cancel_url": "https://joybox.example/account/cancel"},
)
print(result["verdict"])
print(result["correction"]["corrected_params"]["custom_text"])
```
Apply `correction.patch` to the params you create the link with. `consent_collection.terms_of_service: "required"` needs a
Terms of Service URL in Stripe (Dashboard → Settings → Public details).
## Existing links {#existing-links}
Stripe lets you update a link's `custom_text` in place, but not add `consent_collection` to a link that exists: for
that you create a replacement link and point your buttons at it. In the dashboard (**Site → Fixes**), Checkbox can do
either for you with a Payment Links write key you grant only for this: it shows a dry run first, then applies the
change and records it as evidence.
As with Checkout, *clear and conspicuous* stays `needs_review` on the Stripe-hosted page; show the disclosure, set off,
on your own page next to the link. See [Stripe Checkout](https://checkbox.site/docs/guides/stripe-checkout#before-redirect).
---
Source: https://checkbox.site/docs/guides/stripe-customer-portal
# Stripe Billing customer portal
> Use Stripe's customer portal as your online cancellation path, configured so subscribers can cancel without contacting you, and turn on trial reminders.
Most automatic-renewal laws require that a subscriber who signed up online can cancel online, without calling or
chatting. With Stripe Billing, the customer portal is the quickest way to get there.
## Settings Checkbox checks {#settings}
Checkbox reads your portal configuration through the read-only Stripe connection (Customer portal: Read):
| Check | Stripe setting |
|---|---|
| `config.portal_cancel_enabled` | Customer portal → **Cancellations: Customers can cancel subscriptions** is on |
| `config.trial_reminder_enabled` | Settings → Subscriptions and emails → **Send a reminder email 7 days before a free trial ends** |
When the cancellation setting is off, the compliance plan's `billing_portal_cancel` task gives you the exact
`billing_portal.configurations.update` params, for example:
```json title="billing_portal.configuration"
{
"features": {
"subscription_cancel": { "enabled": true, "mode": "at_period_end" }
}
}
```
## Link to the portal from your account page {#link}
Subscribers must be able to find the cancel option. Create a portal session from your server when the subscriber clicks
"Manage subscription" or "Cancel subscription" on their account page, and redirect them to it; or share Stripe's
no-code portal login link. Checkbox's synthetic shopper and [test subscriptions](https://checkbox.site/docs/guides/test-runs) follow that path
and try to cancel, so the `cancel.*` checks are observed rather than assumed.
## Trial reminders {#trial-reminders}
Stripe's trial reminder is sent 7 days before a trial ends. That satisfies some states but not every window (for
example, some states require notice at least 3 and at most 21 days before a trial longer than 31 days converts, and
others require more lead time). Get the exact dates for your plan from
[`checkNoticeSchedule`](https://checkbox.site/docs/api/checks#checkNoticeSchedule), and send the reminders yourself or let
[Checkbox Notices](https://checkbox.site/docs/guides/emails-and-notices) send them.
> **Note**
>
> Stripe sends no customer emails in test mode. During a test subscription, Checkbox only sees emails your own code or
> email provider sends; a missing Stripe-sent email is reported as a warning, not a failure.
---
Source: https://checkbox.site/docs/guides/shopify
# Shopify
> Connect a Shopify store with subscriptions to Checkbox, publish the verified renewal-terms block, and monitor the storefront and subscription emails.
Checkbox connects to Shopify stores through a public Shopify app with read-only scopes: products and selling plans,
subscription contracts, customers, legal policies and themes. Nothing in your store is changed unless you publish a fix.
## Connect the store {#connect}
1. Register the store as a site with `platform: "shopify"`:
```curl
curl https://app.checkbox.site/v1/sites \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{ "url": "https://joybox-shop.example", "platform": "shopify" }'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const site = await checkbox.sites.create({ url: 'https://joybox-shop.example', platform: 'shopify' });
console.log(site.id);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
site = checkbox.sites.create(url="https://joybox-shop.example", platform="shopify")
print(site["id"])
```
2. In the dashboard, open **Site → Integrations → Shopify** and install the Checkbox app on your store (OAuth). Checkbox
then reads your selling plans (prices, intervals, trials), your legal policies and which subscription app owns the
plans, and subscribes to subscription webhooks so renewals and cancellations become lifecycle events.
## Fix the product and cart pages {#fix}
The renewal disclosure and consent must appear before the shopper commits, next to the button that starts the
subscription. Checkbox offers a theme app block, **Renewal terms + consent**, for product and cart pages: the wording is
generated from your selling plan and verified by the engine, and the block shows the terms set off with an unchecked,
required checkbox. Publish it from **Site → Fixes**; without the app, the same text is available as a standalone
snippet.
## Emails and cancellation {#emails-and-cancellation}
- BCC your subscription app's acknowledgment and reminder emails to the site's inbound address (`install.inbound_email`
on the site) so Checkbox can check them.
- Make sure subscribers can cancel online from their customer account; the synthetic shopper tries it.
- Subscription apps send most lifecycle emails. If yours sends Recharge emails, see [Recharge](https://checkbox.site/docs/guides/recharge).
---
Source: https://checkbox.site/docs/guides/recharge
# Recharge
> Connect a Recharge store so Checkbox reads plans and subscription events, and check Recharge's notification emails and cancellation flow.
Recharge powers subscriptions on many Shopify stores. Checkbox reads your plans and store settings through the
Recharge API and turns Recharge webhooks into lifecycle events (subscriptions created, charges, cancellations), which
the reminder and cancellation checks use.
## Connect {#connect}
1. Register the site with `platform: "recharge"`:
```curl
curl https://app.checkbox.site/v1/sites \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{ "url": "https://joybox-shop.example", "platform": "recharge" }'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const site = await checkbox.sites.create({ url: 'https://joybox-shop.example', platform: 'recharge' });
console.log(site.id);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
site = checkbox.sites.create(url="https://joybox-shop.example", platform="recharge")
print(site["id"])
```
2. In Recharge, create an API token (**Apps & integrations → API tokens**) with **read** access to Store, Plans,
Products, Subscriptions and Orders.
3. In the dashboard, open **Site → Integrations → Recharge** and paste the token as `apiToken`. Also paste the token's
**API Client Secret** (on its Edit API Token page) as `webhookClientSecret`: Recharge signs webhooks with it, and
without it Checkbox cannot verify deliveries, so it does not register webhooks.
## What to check {#what-to-check}
- **Notification emails.** Recharge sends the subscription confirmation and upcoming-charge emails. Check their
templates with [`checkEmail`](https://checkbox.site/docs/api/checks#checkEmail) and BCC them to the site's inbound address so the real
sends are monitored.
- **Upcoming-charge timing.** Compare Recharge's "days before charge" with the windows from
[`checkNoticeSchedule`](https://checkbox.site/docs/api/checks#checkNoticeSchedule) for your plans.
- **Cancellation.** The customer portal must let subscribers cancel online. If you require a cancellation reason or show
a retention offer, keep a visible way to finish cancelling.
- **Storefront.** Your product and cart pages need the renewal disclosure and consent: see [Shopify](https://checkbox.site/docs/guides/shopify#fix).
---
Source: https://checkbox.site/docs/guides/custom-checkout
# Custom checkout
> For checkouts you build yourself (Stripe Elements, Paddle, Chargebee, Braintree or anything else) — check the disclosure text and the rendered page, then use Checkbox Elements or the generated HTML.
When the pay button is on your own page, the disclosure and consent are your code. Checkbox checks the text and the
rendered page before you deploy, and gives you engine-verified replacement copy and HTML.
## Check the disclosure text {#disclosure}
Describe what is next to your pay button: the text, where it sits, how it looks, and the consent checkbox if there is
one. Checkbox models the page and runs the ten sign-up checks:
```curl
curl https://app.checkbox.site/v1/checks/disclosure \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"text": "Start your free trial today!",
"merchant_name": "Joybox",
"price": 19.99,
"interval": "month",
"trial_days": 14,
"cancel_url": "https://joybox.example/account/cancel",
"placement": { "above_button": true, "font_size_px": 12 },
"consent": { "checkbox": true, "prechecked": true }
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const result = await checkbox.checks.disclosure({
text: 'Start your free trial today!',
merchant_name: 'Joybox',
price: 19.99,
interval: 'month',
trial_days: 14,
cancel_url: 'https://joybox.example/account/cancel',
placement: { above_button: true, font_size_px: 12 },
consent: { checkbox: true, prechecked: true },
});
console.log(result.verdict);
console.log(result.replacement.disclosure_text);
console.log(result.replacement.consent_label);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
result = checkbox.checks.disclosure(
text="Start your free trial today!",
merchant_name="Joybox",
price=19.99,
interval="month",
trial_days=14,
cancel_url="https://joybox.example/account/cancel",
placement={"above_button": True, "font_size_px": 12},
consent={"checkbox": True, "prechecked": True},
)
print(result["verdict"])
print(result["replacement"]["disclosure_text"])
print(result["replacement"]["consent_label"])
```
This one fails several checks (no renewal terms, a pre-checked box, small text). `replacement` holds the verified
wording, the consent label and `html` you can paste. With the CLI:
```bash
checkbox check disclosure --text "Start your free trial today!" --merchant-name Joybox \
--price 19.99 --interval month --trial-days 14 --cancel-url https://joybox.example/account/cancel \
--consent-checkbox --prechecked --offline
```
## Check the rendered page {#page}
Before you deploy, send the HTML of the page as the browser renders it (after JavaScript). The static check reads
buttons, terms blocks, consent checkboxes and links; layout is estimated, so a passing layout estimate is reported as
`needs_review` until a scan confirms it:
```bash
cat > checkout.html <<'EOF'
EOF
checkbox check page --file checkout.html --merchant-name Joybox --price 19.99 --interval month --offline
```
## Use Elements {#elements}
The simplest fix is [Checkbox Elements](https://checkbox.site/docs/elements): the `` element renders the locked
disclosure for your terms directly above your pay button, keeps the button disabled until the box is ticked, repairs
its own styling if your CSS breaks the requirements, and records each consent as evidence.
## Verify after deploying {#verify}
Register the site with `checkout_url` set to the page with the pay button (and `checkout_steps` when the shopper has to
click through first), then run `checkbox verify --wait` or [`verifySite`](https://checkbox.site/docs/api/compliance-plans#verifySite). The
synthetic shopper visits from each state on desktop and mobile and measures the real layout.
---
Source: https://checkbox.site/docs/guides/emails-and-notices
# Emails and notices
> The acknowledgment, trial, renewal, price-change and cancellation emails automatic-renewal laws require, when each must be sent, how to check your templates, and how Checkbox Notices can send them for you.
Automatic-renewal laws do not stop at the checkout. Depending on the plan and the subscriber's state, you must send:
| Email | When | Check |
|---|---|---|
| Acknowledgment | Right after sign-up: the terms, the cancellation policy and how to cancel | `confirmation.*` |
| Trial ending | Before a free trial converts to paid, inside each state's window | `reminder.trial_ending` |
| Renewal reminder | Before renewals of longer terms (a year or more; shorter in some states) | `reminder.annual_renewal` |
| Yearly terms | Once a year for monthly or other short-term plans, in some states | `reminder.annual_terms_notice` |
| Price change | Before a higher price is first charged | `reminder.price_change` |
| Cancellation confirmation | After a subscriber cancels | `cancel.confirmation` |
## When to send them {#schedule}
Windows differ by state and plan (trial length, term length, payment method). Ask for the exact dates for a
subscription; Checkbox intersects every applicable state's window and, where they conflict, returns the fewest sends
that satisfy all of them:
```curl
curl https://app.checkbox.site/v1/checks/notice_schedule \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"terms": {
"merchant_name": "Joybox",
"price": 99,
"interval": "year",
"trial_days": 35,
"cancel_url": "https://joybox.example/account/cancel"
},
"start_date": "2026-11-02",
"jurisdictions": ["US-CA", "US-NY"]
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const schedule = await checkbox.checks.noticeSchedule({
terms: { merchant_name: 'Joybox', price: 99, interval: 'year', trial_days: 35, cancel_url: 'https://joybox.example/account/cancel' },
start_date: '2026-11-02',
jurisdictions: ['US-CA', 'US-NY'],
});
for (const n of schedule.notices) console.log(n.kind, n.send_date, n.citations.join('; '));
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
schedule = checkbox.checks.notice_schedule(
terms={"merchant_name": "Joybox", "price": 99, "interval": "year", "trial_days": 35,
"cancel_url": "https://joybox.example/account/cancel"},
start_date="2026-11-02",
jurisdictions=["US-CA", "US-NY"],
)
for n in schedule["notices"]:
print(n["kind"], n["send_date"], "; ".join(n["citations"]))
```
Each notice has `send_date` / `send_at`, the window (`window_opens_at` … `window_closes_at`), the jurisdictions and
citations it satisfies.
## Check a template {#check-template}
```curl
curl https://app.checkbox.site/v1/checks/email \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"kind": "trial_reminder",
"subject": "Your trial ends soon",
"text": "Hi! Your free trial ends on December 4. Thanks for trying Joybox.",
"terms": {
"merchant_name": "Joybox",
"price": 19.99,
"interval": "month",
"trial_days": 14,
"cancel_url": "https://joybox.example/account/cancel"
}
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const result = await checkbox.checks.email({
kind: 'trial_reminder',
subject: 'Your trial ends soon',
text: 'Hi! Your free trial ends on December 4. Thanks for trying Joybox.',
terms: { merchant_name: 'Joybox', price: 19.99, interval: 'month', trial_days: 14, cancel_url: 'https://joybox.example/account/cancel' },
});
console.log(result.verdict);
console.log(result.template.subject);
console.log(result.template.merge_tags);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
result = checkbox.checks.email(
kind="trial_reminder",
subject="Your trial ends soon",
text="Hi! Your free trial ends on December 4. Thanks for trying Joybox.",
terms={"merchant_name": "Joybox", "price": 19.99, "interval": "month", "trial_days": 14,
"cancel_url": "https://joybox.example/account/cancel"},
)
print(result["verdict"])
print(result["template"]["subject"])
print(result["template"]["merge_tags"])
```
When the email fails, `template` holds a compliant subject, text and HTML with merge tags (for example
`{{trial_end_date}}`) for you to fill per subscriber. Email checks judge content; real send timing is judged by
monitoring.
## Let Checkbox see the real emails {#monitor}
- **BCC** each lifecycle email to the site's inbound address (`install.inbound_email` on the site), **labelled with its
kind** so Checkbox never has to guess: plus-address it (`+annual_terms@…`) or add the header
`X-Checkbox-Kind: annual_terms`. Kinds: `acknowledgment`, `trial_reminder`, `renewal_reminder`, `price_change`,
`annual_terms`, `charge_notice`, `cancellation_confirmation` (the same names `checkEmail`, `verifyTask` and the plan
use; `trial_ending` is accepted as an alias, as in Notices). Unlabelled mail is classified by its content.
- Run a [test subscription](https://checkbox.site/docs/guides/test-runs): Checkbox subscribes with its own inbox and moves a test clock
through trial end and renewal, so it receives every email your code sends and knows exactly when it was sent.
## Checkbox Notices {#notices}
Checkbox can send the required notices for you, from your brand, timed from the legal catalog, and record each delivery
as evidence. Turn it on per site with [`updateNoticeSettings`](https://checkbox.site/docs/api/notices#updateNoticeSettings) (live mode needs
an activated account). Notices send email only: where New York requires reminders "in the manner the consumer
selected", the plan asks you to attest that subscribers chose email; and New York's price-increase consent or refund
right cannot be provided by any notice, so it stays a question for you.
---
Source: https://checkbox.site/docs/guides/cancellation
# Online cancellation
> What "cancel online" requires, how Checkbox tests your cancellation flow, and the hosted cancellation page you can use instead of building one.
Federal law (ROSCA) requires a simple way to stop recurring charges, and the state laws are more specific: a subscriber
who signed up online must be able to cancel online, immediately, without calling or chatting, and retention offers
must not stand in the way. Several states also require a confirmation after cancelling.
## What Checkbox checks {#checks}
The synthetic shopper signs in with a test account (or uses a [test subscription](https://checkbox.site/docs/guides/test-runs)), looks for
the cancel option from the account page and tries to cancel. It records every step with screenshots.
| Check | Fails when |
|---|---|
| `cancel.online_available` | No way to cancel online was found |
| `cancel.mechanism_findable` | The cancel option is hard to find from the account page |
| `cancel.flow_friction` | The flow forces a call, chat or email, or loops through offers without a visible way to finish |
| `cancel.confirmation` | No confirmation of the cancellation (on screen or by email) |
See [every check](https://checkbox.site/docs/concepts/checks#all-checks) for the full list and the laws behind each.
## Build it {#build}
- Put **Cancel subscription** (or "Manage subscription") on the account page, one click from where subscribers manage
their account.
- Retention offers are allowed in most states only if the subscriber can see and use the cancel option at the same time.
- Confirm the cancellation on screen and by email, with the date the subscription ends.
- With Stripe Billing, the [customer portal](https://checkbox.site/docs/guides/stripe-customer-portal) does this for you.
Then tell Checkbox how to reach it: register the site with `test_account` (a subscriber login the shopper can use) or
`cancel_steps`, and run `checkbox verify --wait`.
## Or use the hosted cancellation page {#hosted}
For sites on Stripe Billing, Checkbox hosts a cancellation page: the subscriber enters their email, confirms with a
link, and cancels in two clicks, with an on-screen confirmation and a confirmation email. Retention offers are only
shown behind "Would you like to hear about an offer before you cancel?". Every cancellation is written to the evidence
vault. Turn it on in the dashboard (**Site → Fixes → Hosted cancellation**) with a Stripe key limited to Customers: Read
and Subscriptions: Write, and link to it from your account page and your disclosure (`cancel_url`).
## Your Terms must agree {#terms}
Checkbox fetches your Terms of Service and cancellation policy. "No cancellations", "cancel by phone only" or "all sales
final" contradict the law for online sign-ups and show up as `terms.cancellation_policy_consistent` tasks with the
offending clause quoted.
---
Source: https://checkbox.site/docs/guides/test-runs
# Test subscriptions
> A synthetic subscription in Stripe test mode — sign-up with a test card, your real emails at Checkbox's inbox, a test clock through trial end and renewal, and online cancellation — so every lifecycle check is observed, like a CMS preview.
A test run is a preview of your whole subscription lifecycle before your customers see it. Checkbox subscribes a test
customer in your billing platform's **test mode**, receives your emails at its own inbox, fast-forwards a Stripe test
clock through the trial end and the first renewal, cancels online, and reports every step with evidence, check results
and fixes your agent can apply. Nothing is charged and nobody has to log in.
## 1. Give Checkbox a Stripe test key {#credentials}
Create a **restricted key in test mode** (Stripe Dashboard → Developers → API keys) with:
| Permission | Access | Used for |
|---|---|---|
| Customers | Write | The test subscriber (attached to the run's test clock) |
| Checkout Sessions | Write | The mirrored test-mode Checkout Session |
| Subscriptions | Write | Reading trial, period and cancellation; creating the subscription if the hosted page cannot be completed |
| Test clocks | Write | Creating, advancing and deleting the run's clock |
| Customer portal | Write | A portal session for the online cancellation |
| Prices, Products | Read | Resolving the mirrored prices |
| Billing portal configuration | Read | Comparing the test portal with live |
Store it for the site. Live keys are refused (`test_key_not_test_mode`); the key is verified with Stripe, kept encrypted
and never returned (only a hint such as `rk_test_…a1b2`):
```bash
curl https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/test_credentials \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{ "type": "stripe_test", "secret_key": "rk_test_..." }'
```
`checkbox init` and `setup_checkbox` do this for you when the human ticks "use my Stripe test key" on the approval page.
## 2. Start a run {#start}
```bash
curl -X POST https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/test_runs \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{}'
```
Checkbox copies your checkout into a test-mode Checkout Session. The source is, in order: a config you registered with
[`createStripeCheckoutConfig`](https://checkbox.site/docs/api/test-runs#createStripeCheckoutConfig) (exactly what your code passes to
`stripe.checkout.sessions.create`), a test price you pass, or your latest live Checkout Session read through the
read-only connection. It also tells you whether the copy matches live (`stripe.matches_live`).
## 3. Follow it {#follow}
A run takes about 5 to 20 minutes, mostly waiting for emails. Poll `GET /v1/test_runs/{run}` every 15–30 seconds, or
subscribe to the `test_run.completed` / `test_run.failed` [webhooks](https://checkbox.site/docs/webhooks). List a site's runs:
```curl
curl -G https://app.checkbox.site/v1/sites/site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b/test_runs \
-u "$CHECKBOX_SECRET_KEY:" \
-d limit=3
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const runs = await checkbox.testRuns.list('site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b', { limit: 3 });
for (const run of runs.data) console.log(run.id, run.status, run.next_action?.type);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
runs = checkbox.test_runs.list("site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b", limit=3)
for run in runs.data:
print(run["id"], run["status"], (run.get("next_action") or {}).get("type"))
```
## What a run does {#steps}
| Step | What happens | Evidence for |
|---|---|---|
| `credentials` | The test key works | |
| `checkout_config` | Mirror the checkout and compare it with live | |
| `checkout_page` | The synthetic shopper scans the hosted test-mode page | `signup.*` |
| `subscribe` | Complete the page with test card 4242; if the page cannot be completed, the subscription is created through the API and flagged | |
| `acknowledgment_email` | Wait for your email at the run's inbox | `confirmation.*` |
| `trial_reminder` | Move the test clock to every notice-window edge before the trial ends (from the legal catalog), collect mail after each stop | `reminder.trial_ending` |
| `renewal` | The same around the first renewal | `reminder.annual_renewal`, `reminder.charge_notice` |
| `cancel_online` | Open the customer portal (or your own cancel page) and cancel with the shopper | `cancel.*` |
| `cancellation_email` | Wait for the confirmation | `cancel.confirmation` |
| `cleanup` | Delete the test clock (Stripe deletes its customer and subscription with it) | |
**Exact timing.** The clock stops on window edges, so an email that arrives between two stops was sent inside, before
or after each state's window — `timing` is `in_window`, `too_early` or `too_late`, exactly, even though the run takes
minutes. The run is judged in test-clock time: a 35-day trial is evaluated as 35 days.
### The acknowledgment email {#acknowledgment}
Stripe sends no customer emails in test mode, so a run only sees emails **your** code or email provider sends. If your
acknowledgment comes from Stripe's own receipts, the run reports it as a warning with a fix — send the acknowledgment
from your `checkout.session.completed` webhook handler (or turn on [Checkbox Notices](https://checkbox.site/docs/guides/emails-and-notices#notices)) —
and it is not counted against your site. Each step's `fix` has `summary`, ordered `steps`, `where`, and the
`operation_id` to call to try again.
## What counts for monitoring {#provenance}
Everything a run observes is labelled `provenance: "test_run"`. Your emails always count (they are your real emails);
the hosted checkout counts only when the mirrored config matches live; the cancellation flow counts when it is your
own cancel page or a test portal configured like live. Missing evidence that is only missing because of test mode is
never recorded as a failure of your site.
Each response's `next_action` (`wait`, `fix_and_retry`, `apply_fixes`, `review_warnings`, `none`) tells your agent what
to do next. After applying fixes, start another run to confirm them.
---
Source: https://checkbox.site/docs/guides/compliance-plan
# The compliance plan
> The ordered, machine-readable list of changes that makes a site compliant — each task with the law, the place, the exact change and how it is verified — and the verify loop around it.
The compliance plan turns findings into work. It is built on demand from the site's latest evaluation and stays stable
as you work: task ids survive recomputation, and each task says exactly what to change and how Checkbox will confirm it.
[The agent loop](https://checkbox.site/docs/agent-loop#plan) shows where it fits.
## Read the plan {#read}
```bash
checkbox plan --json
```
The CLI picks the site from `--site`, `$CHECKBOX_SITE`, the site `checkbox init` saved for the directory, or your only
site. The API call is [`retrieveCompliancePlan`](https://checkbox.site/docs/api/compliance-plans#retrieveCompliancePlan)
(`GET /v1/sites/{site}/plan`).
## Tasks {#tasks}
Tasks group the checks one change fixes. Every machine check belongs to exactly one task:
| Task | Checks | Where | Verified by |
|---|---|---|---|
| `terms_cancellation`, `terms_renewal`, `terms_refund` | `terms.*` | Policy page (the offending clause is quoted) | Re-fetching the policy, decided at once |
| `online_cancellation` | `cancel.*` | Code: account-page link or the hosted cancellation page | A scan |
| `billing_portal_cancel` | `config.portal_cancel_enabled` | Stripe `billing_portal.configuration` params | Billing-platform sync |
| `signup_disclosure` | `signup.*` | Code patch, Checkout Session or Payment Link params, or a Shopify block | Page fetch or Stripe params now, then a scan |
| `acknowledgment_email`, `trial_reminder`, `renewal_reminder`, `annual_terms_notice`, `charge_notice`, `price_change_notice` | `confirmation.*`, `reminder.*`, `config.trial_reminder_enabled` | Email template, or Checkbox Notices | The next real email at the inbound address |
| `attest_ny_notice_channel`, `attest_ny_price_increase` | New York attestations | A question for the human | `answerTask` |
Ordering: severity first, then fixes of observed failures before tasks that only let Checkbox observe something, then
lifecycle stage (policies, cancellation, sign-up, emails). A change another one depends on comes first — for example the
sign-up disclosure states the cancellation URL, so a broken online cancellation is fixed before it.
## Patches {#patches}
For code tasks, `change.content` is a unified-diff template anchored to the elements Checkbox observed
(`@@ insert directly above the purchase button "Start now" (#subscribe-button) @@`), plus machine-applicable `edits`
(`insert_before`, `remove_attribute`, `replace_text`…). `checkbox fix --file ` applies the edits to your
file in memory and prints a diff you can `git apply`; anything it cannot find is reported as unmatched, never guessed.
```bash
checkbox fix task_8c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f --file app/checkout/page.tsx --out fix.diff && git apply fix.diff
```
## Verify {#verify}
`POST /v1/tasks/{task}/verify` (`checkbox verify --wait`) runs the fastest re-check now and queues the
authoritative one:
| Method | Immediate re-check | Confirmed by |
|---|---|---|
| `page_fetch` | Static fetch of the live checkout, or the `html` you send before deploying | The scan it queues |
| `stripe_params` | The `stripe_checkout_session` params you send | The scan it queues |
| `policy_refetch` | — | Re-fetching the policy and re-evaluating at once |
| `email_copy` | The `email` you send (optional) | The next real email at the inbound address |
| `platform_sync` | — | The billing-platform sync it queues |
| `evaluation` | — | A scan, or an immediate re-evaluation |
A failing immediate check fails the verification at once, with a diff. Otherwise it stays `pending` until the
confirming observation arrives (`?wait=30` long-polls). Pending verifications expire after 1 hour for scans and 24 hours
for emails, with a `reverify` next action. The `task.verified`, `plan.updated` and `site.compliant`
[webhooks](https://checkbox.site/docs/webhooks) fire without polling.
## Decisions and answers {#decisions}
- `updateTask { status: "in_progress" }` claims a task; `{ status: "wont_fix", reason }` declines it. A declined
critical or high task keeps the plan `blocked`.
- Manual tasks carry a `question`. Ask the human, then record their answer with `answerTask` (CLI:
`checkbox answer --note "…"`). Answers that assert a legal fact — `yes` to an attestation,
`confirmed` for an undecided check — are stored as a **proposal**: the response's `next_action.type` is
`ask_human_to_confirm` with a link the human opens while signed in to Checkbox. Only their confirmation writes the
attestation, sets the site fact and re-evaluates; an API key alone can never attest. `no` / `needs_change` turn the
task into a change for the agent at once. A confirmation holds only while the checks keep the status it was given for.
- Steps only a person can do in the dashboard (connecting the billing platform) come as `next_action.type:
"connect_billing_in_dashboard"` with the URL; answer `done` afterwards so Checkbox re-reads it.
- Human confirmations are attestations, not observations: the plan can reach `compliant` while the underlying checks
stay `needs_review` in the evaluation, and the plan summary says how many items rest on a confirmation.
## What the plan says, and what it does not {#coverage}
- Each task has **one stable title**. When Checkbox cannot give the exact change yet, `blocked_on` says why
(`observation`: it has not seen the page or email; `facts`: it needs the plan, price, cancel URL or merchant name) and
`change.type` is `config` or `needs_facts`: `change.content` is the request body of `change.operation_id`
(`updateSite`, `updateSetupSession`), validated against that operation. Checkbox never returns a patch with
`{price}`-style tokens, `[placeholders]` or a cancel link it made up.
- Registered Stripe Checkout params (`createStripeCheckoutConfig`, `checkbox init`) that fail the preflight become a
`stripe_checkout_params` task with the engine-corrected params.
- Done tasks keep the title and priority they had, and `closed_reason` says why they closed: `verified` (their checks
pass), `no_longer_applicable` (nothing was observed passing; the checks stopped applying), `declined`.
- `coverage` lists the lifecycle stages Checkbox observed and the ones it did not, the items resting on a human
confirmation, and whether a billing platform is connected. `status: "compliant"` means every applicable check
Checkbox could observe passes — an automated assessment, not a legal determination. When the plan is done, tell the
human what was not observed; never tell them the site "is compliant". The `insurable` flag is a preview of what the
planned warranty will key on; no warranty or insurance is offered yet.
---
Source: https://checkbox.site/docs/preflight
# Preflight checks
> Stateless "check before you ship" calls for AI agents and CI — disclosure text, Stripe params, lifecycle emails, checkout HTML and notice timing — with verdicts per legal requirement and the exact fix.
Preflight checks judge what your code will produce, before anything is deployed. Nothing is stored, no site is needed,
and test keys work. Send the text, params, email or HTML; get a verdict per check and per legal requirement, with
citations, and a fix the engine has already verified.
| Check | Endpoint | CLI | Offline |
|---|---|---|---|
| Disclosure text, placement, consent checkbox | [`POST /v1/checks/disclosure`](https://checkbox.site/docs/api/checks#checkDisclosure) | `checkbox check disclosure` | yes |
| Stripe Checkout Session params | [`POST /v1/checks/stripe_checkout_session`](https://checkbox.site/docs/api/checks#checkStripeCheckoutSession) | `checkbox check stripe-session` | yes |
| Stripe Payment Link params | [`POST /v1/checks/stripe_payment_link`](https://checkbox.site/docs/api/checks#checkStripePaymentLink) | `checkbox check payment-link` | yes |
| A lifecycle email | [`POST /v1/checks/email`](https://checkbox.site/docs/api/checks#checkEmail) | `checkbox check email` | yes |
| Checkout HTML (or a live URL) | [`POST /v1/checks/page`](https://checkbox.site/docs/api/checks#checkPage) | `checkbox check page` | `--file` only |
| When each notice must be sent | [`POST /v1/checks/notice_schedule`](https://checkbox.site/docs/api/checks#checkNoticeSchedule) | `checkbox check notice-schedule` | no |
`--offline` runs the same rules engine locally: no key, no network, the same JSON plus `"mode": "offline"`.
## Example {#example}
```bash
checkbox check disclosure \
--text "Renews monthly at \$19.99 until you cancel." \
--merchant-name Joybox --price 19.99 --interval month \
--consent-checkbox --offline
```
The same call over HTTP returns JSON like this (trimmed):
```json
{
"object": "check_result",
"kind": "disclosure",
"verdict": "fail",
"checks": [
{
"check_id": "signup.disclosure.cancellation_policy",
"status": "fail",
"severity": "critical",
"fix": "Explain the cancellation policy and exactly how to cancel in the checkout terms.",
"requirements": [
{ "id": "US-FED.8403.1", "jurisdiction": "US-FED", "citation": "15 U.S.C. § 8403(1)" },
{ "id": "US-CA.17602.a.1", "jurisdiction": "US-CA", "citation": "Cal. Bus. & Prof. Code § 17602(a)(1); § 17601(a)(2)-(3)" }
]
}
],
"replacement": {
"disclosure_text": "Your Joybox subscription automatically renews every month at $19.99 (plus applicable taxes) until you cancel. You can cancel anytime online at {{cancel_url}}; cancellation takes effect at the end of your current billing period. To avoid the next charge, cancel before your next billing date (every month).",
"placeholders": ["{{cancel_url}}"],
"verified": true
},
"rules_version": "1.3.0",
"catalog_version": "2026.10.31.1",
"disclaimer": "Automated compliance check against Checkbox’s catalog of automatic-renewal laws. It is not legal advice…",
"next_action": {
"type": "replace_text",
"message": "Failing: signup.disclosure.cancellation_policy (fail), signup.disclosure.conspicuous (needs_review). Replace the disclosure with replacement.disclosure_text, show it directly above the purchase button… then call this check again."
}
}
```
`next_action.type` is one of `none`, `replace_text`, `apply_patch`, `replace_template`, `fix_and_recheck`,
`human_review`, `provide_input`, `schedule_notices`. Loop until the verdict is `pass`.
## In CI {#ci}
Exit codes are stable: `0` pass (or only `needs_review` without `--strict`), `1` a check failed, `2` needs review with
`--strict`, `3` usage error, `4` not logged in or key rejected, `5` API or network error. A GitHub Actions step:
```yaml title=".github/workflows/compliance.yml (excerpt)"
- name: Checkbox preflight
env:
CHECKBOX_API_KEY: ${{ secrets.CHECKBOX_API_KEY }}
run: npx @checkbox-site/cli check stripe-session --file checkout/session-params.json --merchant-name Joybox --cancel-url https://joybox.example/account/cancel
```
Give CI a restricted key with only `checks: read`.
> **Pre-release packages**
>
> The SDKs, the CLI and the local MCP server are not on npm or PyPI yet, and the package names shown here are
> placeholders (the CLI commands below run from a checkout of the repository today). Until this notice is gone, use the
> HTTP API (curl) or the remote MCP server at `https://app.checkbox.site/mcp`, which are live today. Never install an npm
> package named `checkbox`: it belongs to an unrelated project.
## Determinism and limits {#limits}
- Every result carries `rules_version`, `catalog_version`, `catalog_hash`, `as_of` and a disclaimer. The same input and
`as_of` date give the same verdicts.
- On any Stripe-hosted page, *clear and conspicuous* (`signup.disclosure.conspicuous`) stays `needs_review`: Stripe
controls the styling.
- The page check reads static HTML; buttons rendered by JavaScript are not found, so send the rendered HTML. Layout is
estimated, and a passing estimate is reported as `needs_review`, never `pass`; a scan confirms it.
- Disclosure and Stripe checks model a desktop page; mobile layouts are judged by scans.
- Email checks judge content; real send timing is judged by monitoring.
- Rate limit: 120 checks per minute per account (`page` with `url`: 20 per minute).
---
Source: https://checkbox.site/docs/elements
# Checkbox Elements
> A drop-in web component (and React wrapper) that shows the locked, compliant automatic-renewal disclosure above your pay button with an unchecked consent checkbox, and records each consent as evidence.
`` renders the disclosure for your terms — price, interval, trial, that it renews until cancelled,
how to cancel — in a bordered box at body size or larger, directly above your pay button, with an **unchecked,
required** consent checkbox. It keeps the pay button disabled until the shopper ticks the box, and records each consent
with Checkbox, so you get a `cons_…` id to store with the subscription. The wording is the same locked text the rules
engine verifies everywhere else.
## Install {#install}
1. Get the pinned script tag with Subresource Integrity from the manifest (or from `createDisclosure`, below):
```curl
curl https://app.checkbox.site/v1/elements/manifest.json
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const manifest = await checkbox.elements.retrieveManifest();
console.log(manifest.script_tag);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
manifest = checkbox.elements.retrieve_manifest()
print(manifest["script_tag"])
```
2. Put the script tag in `` and the element inside your sign-up form, directly above the pay button:
```html
```
3. Your server receives `auto_renew_consent` (the label text) and `checkbox_consent_id` (`cons_…`) with the form.
Store the id with the subscription — for example `metadata: { checkbox_consent: 'cons_…' }` on the Stripe Checkout
Session — or set `customer_reference` later with `updateConsent`.
`/v1/elements.js` always serves the current version (cached for 5 minutes), handy while prototyping. In production pin
`/v1/elements//elements.js` with its `integrity`; released versions never change.
## React {#react}
```tsx
import { CheckboxDisclosure } from '@subcomply/elements/react';
export function Consent({ sessionId, onConsent }: { sessionId: string; onConsent: (id: string) => void }) {
return (
onConsent(consent.id)}
/>
);
}
```
In single-page apps that submit with `fetch`, use `recordConsent="manual"` and call `await ref.current.recordConsent()`
before creating the subscription. (The React entry is published with the SDK packages; see the
[pre-release note](https://checkbox.site/docs/sdks/node#install).)
## Server-issued disclosures {#server}
`createDisclosure` derives the terms from the site's billing connection (or the terms you pass), generates the locked
wording, runs the rules engine on your checkout with the element installed, and returns the markup to paste:
```curl
curl https://app.checkbox.site/v1/disclosures \
-u "$CHECKBOX_SECRET_KEY:" \
-H "Content-Type: application/json" \
-d '{
"site": "site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b",
"terms": {
"merchant_name": "Joybox",
"amount": 1999,
"currency": "usd",
"interval": "month",
"trial_days": 14,
"cancel_url": "https://joybox.example/account/cancel"
}
}'
```
```node
import Checkbox from '@checkbox-site/cli';
const checkbox = new Checkbox(process.env.CHECKBOX_SECRET_KEY);
const disclosure = await checkbox.disclosures.create({
site: 'site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b',
terms: { merchant_name: 'Joybox', amount: 1999, currency: 'usd', interval: 'month', trial_days: 14, cancel_url: 'https://joybox.example/account/cancel' },
});
console.log(disclosure.verification.passes);
console.log(disclosure.element_html);
```
```python
import os
from checkbox import Checkbox
checkbox = Checkbox(os.environ["CHECKBOX_SECRET_KEY"])
disclosure = checkbox.disclosures.create(
site="site_3f9a1c2e7b4d4e0f9a8b7c6d5e4f3a2b",
terms={"merchant_name": "Joybox", "amount": 1999, "currency": "usd", "interval": "month",
"trial_days": 14, "cancel_url": "https://joybox.example/account/cancel"},
)
print(disclosure["verification"]["passes"])
print(disclosure["element_html"])
```
With `disclosure="disc_…"` on the element, it loads its text from Checkbox (publishable key, Origin-checked). Keep the
terms attributes as well: they are the fallback if Checkbox cannot be reached. Without either, the element shows
"Subscription terms unavailable" and keeps the pay button disabled.
## Attributes {#attributes}
| Attribute | |
|---|---|
| `publishable-key` | `pk_test_…` / `pk_live_…`. Without it the element still works but records nothing |
| `merchant-name`, `amount` (minor units), `currency`, `interval` (`day`, `week`, `month`, `year`), `interval-count`, `trial-days`, `cancel-url` (https), `cancel-timing` (`period_end` or `immediately`) | Your terms |
| `disclosure` | `disc_…` from `createDisclosure` |
| `site` | `site_…`; optional (resolved from the page's domain), needed on `localhost` when you have several sites |
| `submit` | CSS selector of the pay button(s) to gate; default: the form's submit buttons |
| `form` | id of the form when the element is outside it |
| `customer-reference` | Your id for the subscriber (a Stripe session or customer id). Emails are refused |
| `record-consent` | `submit` (default), `change` (when ticked) or `manual` |
| `placement` | `auto` moves the element directly above the pay button |
| `name`, `consent-id-name` | Form field names (default `auto_renew_consent`, `checkbox_consent_id`) |
| `api-base` | Defaults to the origin the script was loaded from |
Events (they bubble): `checkbox:ready`, `checkbox:change` `{ consented }`, `checkbox:consent` `{ id, consent }`,
`checkbox:guardrail` `{ violations, messages, fallbackApplied }`, `checkbox:error` `{ code, message }`. Methods:
`isConsented()`, `recordConsent({ customerReference?, metadata? })`, `consentId`, `checkGuardRails()`, `refresh()`.
A Checkbox outage never blocks a sale: if recording fails or takes over 6 seconds, the form submits without the id and
`checkbox:error` fires.
## Guard rails {#guard-rails}
Theme it with CSS custom properties (`--checkbox-font-size`, `--checkbox-text-color`, `--checkbox-border-color`,
`--checkbox-background`, `--checkbox-accent-color` and others). After rendering, and on resize, the element measures
what the shopper actually sees with the rules engine's own thresholds — font size at least the page's body size,
WCAG AA contrast, visible, set off by a border, above the pay button and within 250px of it. If your theme or page CSS
breaks size, contrast or the border, it restyles itself with safe inline styles, logs a warning and fires
`checkbox:guardrail`. A checkbox ticked by a script is not consent: the element unticks it and reports `prechecked`.
## Content-Security-Policy {#csp}
The element uses no `eval`, no inline styles or `