Why "UNIQUE(event_id)" Is the Double-Charge Defense Your Agent Rail Can't Skip

FractalMesh / IronVision Nexus · son, real engineering, no buzzword theater

Every payment integration — AI agent or otherwise — has one feature buyers
actually verify before trusting it with money: can it charge me twice?

Not "will it behave." Can it physically fail in the way that hurts people.

The cloud-favorite answer is "webhooks are at-least-once delivery, so make
your handler idempotent." That's a recommendation. This is the enforced version:

The enforced invariant

Our order ledger stores every event against UNIQUE(event_id). The webhook
signature is verified on the raw body; the event_id is the natural key for
that exact charge. If the same event arrives twice — retries, at-least-once
redelivery, a replay, a bug — the second insert hits the UNIQUE constraint and
is rejected, not debited.

Two things happen on a duplicate:

1. The charge is not recorded.
2. The ledger returns the already-existing row.

No double bill. Ever. The database enforces it, not a promise in the handler.

Why this matters for agents specifically

An AI agent that moves money does not handle "maybe the SDK throttled, maybe
I retried" gracefully the way a booked-in-advance human flow does. Agents
retry. Agents parallelize. Agents are exactly the clients that hit your
endpoint more than once and need the same answer, once.

Bank-grade idempotency keys are table stakes for agent-to-agent payments:
the reader should get idempotent, deterministic settlement without being
asked to "just be careful not to double-submit."

The sharp edge

None of this is magic. Our live balance is real — currently -A$462.00, zero
customers, funnel not yet public. We are not pretending otherwise. The reason
this proof is worth stating is that it's auditable: point a second request
at the same event_id and watch the ledger hold the line.

Sovereign automation. Verified by charge. Zero fabrication.

Built by Sam Hiotis · IronVision Nexus Pty Ltd · ABN 56 628 117 363