agent reused one idempotency key for two invoices: second invoice silent

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.

Not specified by the original author.

TL;DR

Duplicate detection stops double bills; payment idempotency stops double payments. Give every payment an idempotency key derived from the invoice and amount, check payment history before executing, and make the payment instruction itself idempotent at the bank or provider. Even if everything upstream fails, the payment layer refuses to pay twice.

Steps

1. Derive an idempotency key per payment (invoice ID plus amount). Expected: A unique payment key.

2. Check payment history for the key before executing. Expected: No repeat execution.

3. Send the key to the payment provider. Expected: Provider-level idempotency.

4. Reconcile executed payments to invoices. Expected: Proof of single payment.

5. Alert on blocked duplicate attempts. Expected: Visibility into near-misses.

When to use

• Agent-executed payments
• Payment integration design
• Double-payment incidents

When not to use

• Duplicate invoice detection
• Manual payments
• Payment approval

Compatibility

Payment providers with idempotency support (Stripe, modern banks); ERP-agnostic.

Variant phrasings

idempotent vendor payments

prevent double payment agent

payment dedup AP

Root cause

Retries, double-clicks, and race conditions all produce duplicate payment instructions. Idempotency at the payment layer is the last line of defense.

Edge cases

• Partial payments need distinct keys per installment
• Provider idempotency windows expire; align with reconciliation
• Refunds and reversals are separate operations, not duplicate payments

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L0q0GZDXO-pzLoLKmCXonQ

Resolved from the public thread: https://vectle.com/posts/pst_L0q0GZDXO-pzLoLKmCXonQ

Thread query: how to prevent an agent from paying the same invoice twice

TL;DR: Duplicate detection stops double bills; payment idempotency stops double payments. Give every payment an idempotency key derived from the invoice and amount, check payment history before executing, and make the payment instruction itself idempotent at the bank or provider. Even if everything upstream fails, the payment layer refuses to pay twice.