Stripe
Twin of the Stripe payments API.
Twin of the Stripe payments API. Form-encoded with bracket notation, exactly as the real SDKs send.
| Covers | api.stripe.com |
| Auth | Secret keys, restricted keys, Stripe Apps and Connect OAuth |
| Webhooks | Yes |
| Operations | 194 |
Coverage
Customers, payment methods, setup and payment intents, charges, refunds, disputes, invoices, subscriptions, checkout, entitlements, balance and test clocks, plus the Stripe Apps and Connect OAuth issuer.
One API version is served, 2026-07-29.dahlia.
Credentials
Secret keys and restricted keys both authenticate, and any well-formed key works
by default, so your existing sk_test_… needs no change. Restricted keys carry
permissions: a key without the permission a route needs gets Stripe’s real
refusal rather than a 401.
To test rejection, set auth.mode to enforced and use the key published in
config.api_keys. See Credentials.
Time controls
Use the shared sandbox clock for normal time control. Use Stripe Test Clocks only when your application calls Stripe’s Test Clock API or when you need to advance subscription billing for specific customers without moving the rest of the sandbox. A customer attached to a Stripe Test Clock uses that clock for subscription billing.
Vendor specific details
- A trailing slash is fatal.
/v1/customers/returns 404. - The
Stripe-Versionheader selects nothing. One dialect is served, so a test pinning an older version still gets2026-07-29.dahlia. Idempotency-Keyreplays withIdempotent-Replayed: true, but only refusals the endpoint produced are stored under the key. Parameter validation runs earlier and stores nothing, so a retry with a bad parameter is validated again rather than replayed.- Documented test cards work as documented, with no seeding. Last4
0002declines,9995is insufficient funds,0341attaches then declines, and5126makes the refund fail.
Most Stripe SDKs retry 5xx and connection errors internally, reusing your idempotency key, so an armed 500 can be absorbed inside a single SDK call and never reach your code. Arm a 429 instead when you want your own retry logic to run.
Its own notes
Once a sandbox is running, this twin serves its own operating notes at
{control_url}/veris/manual: the credentials it accepts, the API versions it
serves, and the fault statuses you can arm against it. They are generated from
the same source as its behaviour, so they cannot drift.