When to use it
You added Stripe Checkout (or similar) to a form backend shared by several sites and need evidence that every path works before switching keys to live.
Tester brief
Task: end-to-end test of the payment flow for <SITE> against the TEST environment only.
Use only test keys (sk_test_…) and Stripe's published test cards. If you see a live key, stop and report.
Scenarios (record request, response, webhook event and notification for each):
1. Deposit paid -> lead marked deposit_paid, notification sent once
2. Balance paid -> lead fully paid, receipt sent
3. Card declined -> no state change, alert sent, link still usable
4. Session expired -> status expired; resending creates a new session
5. Duplicate clicks on the pay button -> exactly one payment row
6. Webhook replayed -> idempotent
Clean up all test data you created at the end. Report a table of scenario -> pass/fail -> evidence.
Reviewer
A second session reads the tester’s report and the diff of any fixes and answers one question: would I switch this to live? It must not run payments itself.
Approval rules
{
"rules": [
{ "id": "no-live-keys", "risk": "critical", "description": "Live Stripe keys are never used by agents",
"tool": "^Bash$", "command": "sk_live_|rk_live_" }
]
}
The built-in payments rule already holds every Stripe CLI/API call for approval; for a test run you can approve them in batches from your phone.
Done when
- All six scenarios pass on every site, with evidence
- Test data is cleaned up
- The go-live checklist (live keys, webhook endpoints, statement descriptor) is written, not executed
Lessons from real runs
- Automating test payments needs a PaymentMethod created from a test token; some shortcut test IDs are rejected by Checkout confirmation endpoints.
- Notifications are part of the flow: count them. “Paid but nobody was told” is a failure.