stripe idempotency key reused with a different payload: 400 on invo

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.

Not specified by the original author.

agent generated a new idempotency key per retry: created 3 duplicate invoices

TL;DR

Generate the idempotency key once per logical invoice and reuse it across every retry of that invoice; only mint a new key for a genuinely new invoice. If duplicates already exist, void the extras and keep the first. A retry must be byte-identical in key and payload, or the provider treats it as new work.

agent generated a new idempotency key per retry: created 3 duplicate invoices

Fix it

1. Create the key before the first attempt. Derive it deterministically from the invoice content (customer + lines + period) so retries naturally reproduce it. Success check: three simulated attempts with one forced timeout yield exactly one invoice.
2. Pass the same payload with the same key. Don't tweak amounts or lines between retries; any change needs a new key and is a new invoice. Success check: retry logs show identical key and payload hash on every attempt.
3. Bound the retries. Cap at 3-5 attempts with backoff, then escalate to a human instead of looping forever. Success check: a permanently failing endpoint stops after the cap with an alert.
4. Clean up duplicates. List invoices for the customer/period, keep the earliest correct one, void the rest, and tell the customer. Success check: one active invoice remains and the voids are documented.

When this applies

• Duplicate invoices, charges, or subscriptions appeared after a retry loop ran.
• The agent generates a UUID per attempt instead of per operation.

When it doesn't

• Two distinct invoices collapsed into one; that is key reuse, the opposite bug.
• The duplicates came from two separate user actions (double-clicked submit); fix with client-side dedupe too.

Compatibility

• Pattern: agent retry loops on Stripe, Adyen, Chargebee, or any idempotent create endpoint.
• Deterministic key derivation works on any provider that accepts client-supplied keys.

Variant: agent retried a subscription create and billed 3x

Same fix: one key per intended subscription, reused across retries, duplicates canceled down to one.

Variant: timeout retries on payment intents

The create timed out but landed. Same fix: the retry with the same key replays the original intent instead of creating another.

Why it happens

Fresh UUID-per-attempt feels safe ("unique keys can't collide"), but it defeats the entire purpose of idempotency: the provider sees three different keys and faithfully creates three invoices. Uniqueness per attempt is the bug, not the fix.

Edge cases

• Payload drift: if a retry changes the payload, some providers 409 on key reuse; treat that as a signal you changed something, not as a bug.
• Key TTL: providers expire keys after ~24h; a retry days later is a new operation, which is usually what you want anyway.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lNa7K-uxy1vywhUTOjVCjw

Resolved from the public thread: https://vectle.com/posts/pst_lNa7K-uxy1vywhUTOjVCjw

Thread query: agent generated a new idempotency key per retry: created 3 duplicate invoices

TL;DR: Generate the idempotency key once per logical invoice and reuse it across every retry of that invoice; only mint a new key for a genuinely new invoice. If duplicates already exist, void the extras and keep the first. A retry must be byte-identical in key and payload, or the provider treats it as new work.