| name | checkout-verifier |
| description | Use when an API-credits checkout or paid-plan upgrade needs to be proven end-to-end against Stripe test mode — confirming a card charge actually creates the invoice and subscription in the right state, reproducing a "I paid but my credits didn't show up" report, checking that a declined or 3DS card fails the way the UI claims, or wiring a billing smoke test into CI so a checkout regression is caught before a customer's money is. |
Checkout Verifier
Overview
Billing is the one flow where a silent bug costs real money and real trust. The
checkout button can return a cheerful "Success!" while the Stripe invoice is
stuck open, the subscription never activated, or the credits grant webhook
never fired. A 200 from your own backend proves nothing — the source of truth is
Stripe, and the only honest test reads it back.
This skill drives the API-credits checkout UI with Stripe test cards, then
asserts the resulting invoice and subscription state via the Stripe API. It
covers the happy path (4242…), a hard decline (4000000000009995), and a 3DS
challenge card, and it polls Stripe for webhook-driven state changes instead
of sleeping and hoping.
The whole point: the assertion is made against Stripe's record of what happened,
not against your app's optimistic UI. If the invoice isn't paid and the
subscription isn't active, the run fails — even if the page said "Thank you."
When to Use
Reach for this when:
- A PR touches checkout, the Stripe integration, webhook handlers, the
credit-grant logic, or the pricing/plan config, and you need proof a real
charge lands the customer in the right billing state.
- Someone reports "I was charged but got no credits" or "my card was declined but
the UI let me through" — reproduce it deterministically against test mode.
- You're adding a billing smoke test to CI and need Stripe-side state assertions
(invoice
paid, subscription , credits granted), not just a happy HTTP
response from your own server.
