## 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