Show HN: Paste an OpenAPI spec, get duplicate-charge replay tests

Reads your OpenAPI file or endpoint list, flags every operation that can double-charge or duplicate on a retry, and generates a runnable replay suite in ten stacks. Deterministic, in your browser, no sign-in.

Free for the three highest-risk operations. Full audit AUD 99 once. CI integration AUD 49/month.

The retry is the bug. A client timeout plus a second call with the same key is how a charge becomes two. The suite tests that path, the race and the changed amount, not only the clean second click.

The reading names the business operation, its effect, the key the spec declares and the reason for the risk. The free view gives you the three highest-risk operations in full and a runnable starter suite for them.

OpenAPI 3 JSON or YAML, or one operation per line. For a list, append the key like this: POST /v1/charges | idempotency: Idempotency-Key:required | Charge a card.

Nothing is uploaded. Parsing, findings and test generation happen in this browser. How the reading works.

A retry is safe when the server already knows the logical action. The client assigns one key to one business operation, the server stores the key with the result before it responds, and a second call with that key returns the stored result instead of doing the work again.

That is the whole mechanism. The suite makes the invisible part visible: which operations declare a key, what a replay should return, and what happens when the payload changes.

The failure in the second timeline is not a careless client. It is a server that did not persist the key and the result atomically, or a document that never said what the retry should return, so the client cannot tell the difference.

The seven cases and how the reading works

t0 client timeout retry, same key

Stored result, one charge

charge ch_8f21 created key + body stored

no response received the client retries

200, same ch_8f21 one row in the ledger No stored result, two charges

charge ch_8f21 created key ignored by the retry

no response received the client retries

201, new ch_a9c4 two rows in the ledger

one recordduplicateclient-side failure

What the reading does

Paths, methods, schemas and parameters are resolved from the spec. Every write is classified by effect: money, record or read. Orders, customers and webhook endpoints are records; charges, refunds, payouts, captures and subscriptions move money.

The reader looks for a declared key (header or body), whether it is required, whether the spec documents the original result on replay, and whether it documents a conflict when the key is reused with a different payload. Missing pieces become findings with a fix.

For every write operation the generator builds replay, timeout-retry, 5xx-retry, concurrent, changed-payload, missing-key and downstream-count cases, in the stack your team already runs. Fresh key per case, mock and broken mock included.

A suite in the wrong stack is not run. Choose the stack on the result page; the download contains the plan, the runner, the mock, the CI job and the evidence bundle.

The reading is a software check, not a compliance certification. Where the buyer's work touches a regulated control, the product quotes the requirement as read in the held edition and links it. These are the editions read for this build.

All 18 controls, by market, with the requirement and the compliance framework page. The five editions contain 1,379 controls; the 18 here are the ones that bear on retries, duplicate processing, change testing and incident evidence.

One API, one team. One-off, not a subscription.

No. Parsing, classification, findings and test generation run in this page. The only request this site makes on your behalf is the Stripe session check after a payment. There is no analytics script on the tool pages.

Use the endpoint list: one method and path per line, with the key appended after a pipe. You get the same replay, conflict, missing-key, concurrency and timeout cases; the request bodies are generic and need a sandbox example. The endpoint-list method.

No. It is evidence for the operations it covers, against the target it ran against, on that day. It does not inspect the server code, the database or production traffic. The method page states the limits.

Three is enough to judge the reading and run a starter suite. The paid audit is for the whole API and the change evidence. A tool that hides the output until after payment cannot be judged, and one that gives everything away has no product.

It reads the spec you paste. If the spec declares the key the PSP uses, the reading names it. The tests run against your service or a sandbox, not against the PSP's production API. The Stripe case.