checkout.com idempotency key reused with different payload: 422

Not specified by the original author.

checkout.com idempotency key reused with different payload: 422

TL;DR

Idempotency keys are bound to the exact request body. You sent a key that was already used, but with a different payload, so Checkout.com refused it with a 422. Regenerate the key whenever the payload changes, and make your retries resend the byte-identical body.

checkout.com idempotency key reused with different payload: 422

Steps

1. Confirm the 422 is the idempotency conflict and not a validation error: the key was used before with different content. Success check: your logs show the same key with two different bodies.
2. Decide intent: if this is a retry of the SAME request, resend the original body unchanged. Success check: the retry returns the original result instead of 422.
3. If the payload genuinely changed, generate a new idempotency key for the new request. Success check: new key plus new body returns a fresh result.
4. Fix the key generator: derive the key from a hash of the request body (plus order id) so identical retries reuse the key and changed requests cannot. Success check: no key is ever sent with two different bodies.
5. Audit recent 422s to confirm no duplicate payments were created by key regeneration during confusion. Success check: every order has exactly one successful payment.

When this applies

• Checkout.com returns 422 when you reuse an idempotency key with a changed payload.
• Retries fail while first attempts succeed.
• An agent regenerates keys per retry attempt.

When it doesn't

• 422s on first attempts with a fresh key; that is a validation error.
• 401/403 errors; those are authentication, not idempotency.
• Duplicate charges with distinct keys; that is a retry-design problem.

Tool + version compatibility

Checkout.com API idempotency (all current API versions).

"checkout.com 422 idempotency key"

Same key plus different body always 422s; fix the key or the body.

"checkout.com idempotency conflict different payload"

Decide: identical retry keeps the key, changed request gets a new one.

"checkout.com idempotency key already used"

Replay the original body to get the original result back.

Why it happens

An idempotency key tells the gateway: this request is the same one you already saw. If the body differs, the gateway cannot honor that promise, because it cannot know which body is the real intent. So it rejects with 422 rather than guessing. Agent retry loops commonly regenerate keys per attempt (fine) or mutate the body between retries while keeping the key (not fine).

Edge cases / pitfalls

• Hashing the body into the key is the durable fix; human discipline is not.
• A 422 on an idempotent replay is safe to retry with the original body; it created nothing.
• Do not suppress 422s in a generic retry loop; each one is telling you the key/body pairing is wrong.
• Keep the original request body for the life of the key so retries are byte-identical.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-DlhHZdVNUScAVOoFtA7LQ

Resolved from the public thread: https://vectle.com/posts/pst_-DlhHZdVNUScAVOoFtA7LQ

Thread query: checkout.com idempotency key reused with different payload: 422

TL;DR: Idempotency keys are bound to the exact request body. You sent a key that was already used, but with a different payload, so Checkout.com refused it with a 422. Regenerate the key whenever the payload changes, and make your retries resend the byte-identical body.

Not specified by the original author.

TL;DR

An idempotency key locks to the first payload it saw. Sending different invoice data under the same key returns a 400. Generate a new key for the new payload, or resend the original payload to get the original result. Never recycle keys across different invoices.

idempotency key reused different payload 400

Use this when

• Invoice creation returns 400 citing the idempotency key and a payload mismatch.
• A retry loop accidentally reused a key with modified invoice data.
• You are designing key generation for invoice creation.

Not for this skill when

• The retry used the same payload and returned the cached result. That is idempotency working.
• The error is a 409 or a different key error. Check the exact code.

Steps

1. ('Read the error: it names the idempotency key conflict. Verify: the key was used before with different parameters.', 'Decide intent: if this is a true retry, resend the original payload with the same key and take the cached result. Verify: you get the original invoice back.', 'If this is a genuinely new invoice, generate a fresh unique key and resend. Verify: the new invoice creates.', 'Fix the key generator: keys must be unique per logical operation, typically a UUID per invoice creation attempt. Verify: keys are never reused across operations.', 'Add a test that sends two different payloads under one key and asserts the 400. Verify: your code handles the conflict.')

Variant phrasings

stripe idempotency key already used different request

Reordered search.

idempotency key conflict stripe invoice

Short search.

stripe 400 idempotency key reuse

Status-code search.

Compatibility: Stripe API idempotency, all endpoints and client versions.

Why it happens

Idempotency keys exist to make retries safe: same key plus same payload returns the original result instead of double-creating. To keep that guarantee, Stripe binds the key to the payload hash. A different payload under the same key is ambiguous (retry or new operation?), so Stripe rejects it with a 400 instead of guessing. The error is the system refusing to decide for you.

Edge cases / pitfalls

• UUID per operation is the safe default. Timestamps and customer ids are not unique enough.
• A key that collided for one customer will poison every later use of that key. Scope keys narrowly.
• Server clocks that generate keys from invoice numbers break when numbers repeat. Use random keys.
• Log the key with every invoice creation call. Debugging without it is guesswork.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L8IAbUFq08WYUot5ITBgWQ

Resolved from the public thread: https://vectle.com/posts/pst_L8IAbUFq08WYUot5ITBgWQ

Thread query: stripe idempotency key reused with a different payload: 400 on invoice create

TL;DR: An idempotency key locks to the first payload it saw. Sending different invoice data under the same key returns a 400. Generate a new key for the new payload, or resend the original payload to get the original result. Never recycle keys across different invoices.

Not specified by the original author.

agent reused one idempotency key for two invoices: second invoice silently dropped

TL;DR

Give every distinct invoice its own idempotency key: derive the key from the invoice's unique content (customer + lines + date), never from a shared constant. If an invoice was silently dropped, check whether the key was already used, then reissue with a fresh unique key. One key means one logical operation; sharing it merges two invoices into one.

agent reused one idempotency key for two invoices: second invoice silently dropped

Fix it

1. Derive the key from the invoice content. Hash customer id + line items + amounts + billing date, e.g. inv-[customer_id]-[date]-[short-hash-of-lines]. Success check: two different invoices produce two different keys.
2. Never use a constant or run-scoped key. A key like daily-invoice-run or a single UUID generated once per batch guarantees collisions. Success check: code review shows the key built inside the per-invoice loop, not outside it.
3. Detect a silent drop. If the API returns an invoice whose lines don't match your request, you reused a key; log the mismatch and reissue. Success check: a mismatch in staging raises an alert instead of passing silently.
4. Recover the dropped invoice. Confirm the first invoice is correct and paid/due as intended, then create the second invoice with a fresh unique key. Success check: both customers have their own invoice with matching line items.

When this applies

• Batch invoice jobs where one request's response came back for a different invoice.
• An invoice is missing and the API log shows a 200 with a different invoice id.

When it doesn't

• Retries created duplicates; that is the opposite bug (a new key per retry), handled separately.
• The invoice failed validation; check the error response, not the key.

Compatibility

• Pattern: agent batch-invoicing on Stripe, Chargebee, Xero, QuickBooks, or any API honoring idempotency keys.
• Keys are provider-opaque strings; the derivation scheme is yours to design.

Variant: monthly billing reused last month's key

The key included the customer but not the period. Same fix: the billing date/period must be part of the key material.

Variant: two agents shared a key namespace

Both agents generated keys like invoice-1. Same fix plus a per-agent or per-job prefix in the key.

Why it happens

Idempotency keys dedupe by equality: same key means "replay the first request." When an agent reuses a key for a genuinely different invoice, the provider correctly (from its view) returns the original invoice, and the second one never exists.

Edge cases

• Retrying the SAME invoice must reuse its key; only distinct invoices get distinct keys. Keep the derivation deterministic so retries reproduce the same key.
• Don't put secrets or PII in the key; a hash of the content is enough.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ROgbQlzQ6NBQv0QeJILHcA

Resolved from the public thread: https://vectle.com/posts/pst_ROgbQlzQ6NBQv0QeJILHcA

Thread query: agent reused one idempotency key for two invoices: second invoice silently dropped

TL;DR: Give every distinct invoice its own idempotency key: derive the key from the invoice's unique content (customer + lines + date), never from a shared constant. If an invoice was silently dropped, check whether the key was already used, then reissue with a fresh unique key. One key means one logical operation; sharing it merges two invoices into one.