Payments testing
Skill Marcdaou/claude-qa-suite/qa-suite/skills/payments-testing
Claude Code plugin marketplace: qa-suite — end-to-end QA (API, E2E, SEO, security, payments) for Next.js + Supabase + Stripe apps
npx -y skills add Marcdaou/claude-qa-suite --skill payments-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Test Stripe payment flows in test mode using the Stripe API/MCP — the successful charge/checkout path that should create a booking, and the decline/failure paths (generic decline and 3DS/SCA-required) that the app must handle gracefully. Use this skill whenever the user wants to test payments, verify checkout, confirm a charge succeeds or a declined card is handled, or check Stripe integration before launch. Trigger on casual asks like "does paying actually work" or "test a declined card" too. Stripe TEST MODE only.
SKILL.md
4.1 KB, as published. Nobody here has run it
Payments Testing
A payment test answers a sharp question: when a real card is charged, does the app do the right thing — and when a card is declined, does it fail safely instead of booking anyway or 500ing? This skill drives Stripe in test mode through the connected Stripe API/MCP tools, runs a small fixed set of scenarios, and returns a pass/fail report. It only ever uses test-mode keys and Stripe's magic test cards; it never touches live data.
Before running
Confirm you're in test mode. Use the Stripe MCP account/info tool to verify the
active key is a test key (sk_test/test-mode). If it looks like live mode,
stop and tell the user — never run charge tests against live.
Scenarios
Run these three, in order. Each uses a Stripe magic test card via a test PaymentMethod / PaymentIntent created through the Stripe MCP API tools.
| # | Scenario | Test card | Pass condition |
|---|---|---|---|
| 1 | Successful charge | 4242 4242 4242 4242 | PaymentIntent reaches succeeded; the app records a booking tied to it (confirm via the booking record / API). |
| 2 | Generic decline | 4000 0000 0000 0002 | PaymentIntent is requires_payment_method / declined with card_declined; the app does not create a confirmed booking and surfaces an error. |
| 3 | 3DS / SCA required | 4000 0025 0000 3155 | PaymentIntent returns requires_action (authentication needed); the app routes the user into the 3DS challenge rather than treating it as success or failure. |
The failure scenarios are the point: a booking app that confirms a reservation on a declined or unauthenticated payment is losing money or giving away stays. Verify the app's reaction, not just Stripe's status — check the booking record after each.
How to run via Stripe MCP
- Verify test mode (above).
- For each scenario, create a test PaymentIntent through the Stripe API/MCP write
tools with the scenario's test PaymentMethod and a small amount (e.g. a real
listing's price, or
5000= $50.00). Confirm it and read back the resulting status. Seereferences/stripe-mcp.mdfor the exact tool sequence and the expected status for each card. - Cross-check the app: after a successful charge, confirm a booking exists for it; after a decline/3DS, confirm no confirmed booking was created. Use the api-testing runner or a direct read if available.
- Clean up any test objects you created where appropriate.
Output — pass/fail report
ALWAYS report in this shape so it's scannable:
# Payments Test — <app> (Stripe TEST mode)
Mode verified: <test key id / confirmation>
| # | Scenario | Stripe status | App reaction | Result |
|---|--------------------|----------------------|---------------------|--------|
| 1 | Successful charge | succeeded | booking created | PASS |
| 2 | Generic decline | card_declined | no booking, error shown | PASS |
| 3 | 3DS / SCA required | requires_action | ... | ... |
## Failures & fixes
<for any FAIL: what happened, why it's a risk, the fix>
A scenario only passes when both Stripe's status and the app's reaction are correct. If you can't verify the app's reaction (no booking read available), mark it "unverified" rather than PASS.
When to hand off to the agent
For a full payments pass, delegate to the payments-test-runner agent — it verifies test mode, runs all three scenarios via Stripe MCP, cross-checks the booking records, and returns the report.