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.

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.