payments-testing — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited payments-testing (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
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.
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.
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. See references/stripe-mcp.md for the exact tool sequence and the expected status for each card.
after a decline/3DS, confirm no confirmed booking was created. Use the api-testing runner or a direct read if available.
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.
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.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.