All packsSaaS Billing + Tax CoreSolve
stripe idempotency key retry double charge
An idempotency key that actually matches the request
A reused idempotency key on a changed request throws Stripe's idempotency_error; a random key on a retry does nothing at all. The pack hashes params into the key (D12).
This is one of the things SaaS Billing + Tax Core already handles. Charge per-seat subscriptions: upgrades, downgrades, failed cards, invoices and sales tax.
Is this you?
Idempotency keys are supposed to make retries of the same mutating call safe, but a key that's just a random string per call defends against nothing (every attempt gets a new key, so retries aren't deduplicated), and a key that's static per operation-and-account breaks the moment the request parameters actually change -- Stripe returns an idempotency_error rather than silently doing the wrong thing, but only once someone hits it in production.
Why this one is easy to get wrong
"Add an idempotency key" reads like a checkbox -- generate some unique string and pass it -- rather than a design question about what should and shouldn't be treated as the same request. Getting it right requires understanding that the key needs to change when the meaningful parameters change and stay the same when they don't, which isn't obvious from the Stripe SDK signature alone.
What you get instead
D12 builds every mutating Stripe call's idempotencyKey from a short hash of its own parameters: ${op}:${accountId}:${hash(params)}. A changed request naturally gets a fresh key (no idempotency_error on legitimate different retries), while an identical retry reuses the same key and dedupes correctly. Keys expire server-side after 24h; maxNetworkRetries: 2 on the client handles transient network duplicates on top of that.
Source: ARCHITECTURE.md D12 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 18 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
3 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →