# Why UNIQUE(event_id) Is the Double-Charge Defense Your Agent Rail Can't Skip > Source: > Published: 2026-08-28 23:48:20+00:00 *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: 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: No double bill. Ever. The database enforces it, not a promise in the handler. 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." 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*