A retry should not become a second sale.
How does the integration distinguish a retry from a changed transaction?
One sale retained · conflicting retry refused
The first create returned idempotent_replay=false. The identical retry returned true. A changed $101 payload using the same Idempotency-Key returned idempotency_conflict (409). The database still held one sale before the separate refund.
What this execution establishes
Sequential retry trace in an isolated SQLite database. It does not measure concurrent hosted throughput or network-failure performance.
Executed using the published version’s source hashes. The Virginia lifecycle cases use a disclosed 5.3% snapshot and fixture address handling; they do not claim a live geocoder or current production-rate test.
Reproduce and review
Primary source: Virginia Tax: sales tax rates and locality lookup. Source review: 2026-10-21. Transaction date: 2026-07-26.
Make it your test
Bring a timeout/retry pattern from checkout or billing.
Evaluate this in my workflow →Run the public examples again.
No account or key needed. This runs the address lookup and package writer afresh with the disclosed inputs. It does not run your own transactions or submit a return.
Evidence you can inspect. Limits you can see.
The business data is synthetic. The address example uses a small official-derived historical Illinois sample. The other executions use an isolated sandbox database, disclosed inputs and the same service implementations used by the application. No customer records, filings, payments or competitor credentials were used.
The pack distinguishes local component execution from hosted API execution. The optional replay script records your own sandbox results, including failures; it does not recreate the private reference database or certify a provider. Confirm supported coverage and effective dates before evaluating a real workflow.
Sales Tax Engine · Sales Tax Compliance · API coverage contract · Current pricing