Plasma breaks callbacks.
It’s not the HTTP call. It’s what your system assumes will happen around it.
The payment settles. USDT moves. PlasmaBFT finality closes before the merchant backend finishes booting its own certainty. The chain is done. The callback queue isn’t.
A webhook hits. Then it hits again.
Same tx hash. Same amount. Same reference. Two deliveries, seconds apart. Both look valid. Both arrive after finality. And there’s still nothing written locally that says “we already processed this,” because the old flow expected a little lag to exist.
Inventory releases once. Then—yeah—again.
The relayer did its part. The sponsored lane accepted the send. PlasmaBFT sealed it. The callback service retried because the first attempt didn’t get a 200 fast enough. No big red error. Just a retry counter ticking from 1 to 2 while everyone assumes “it’ll be fine.”
Ops only notices when counts don’t line up.
Support swears the customer only paid once. The merchant dashboard shows two fulfillments. The warehouse log shows two picks with the same reference ID. Nobody thinks it’s fraud, so nobody gets to dismiss it.
On systems with more settlement slack, callbacks drift. You have time to mark state before the second delivery lands. On Plasma, retries can arrive before your idempotency key even makes it to storage. The handler is “idempotent,” technically. It just wasn’t idempotent in the first three seconds.
The logs are clean. The second callback isn’t malformed. It isn’t out of order. It isn’t malicious.
It’s just early.
I’ve seen teams chase this for hours. Grep for duplicates. Blame the queue. Blame the network. Then someone finally lines up timestamps and sees it: the first callback returned late, the idempotency write happened later, and the retry slipped into the gap.
The ordering is what changed.
After that, the argument gets annoying. Not emotional. Annoying. Because everyone is holding a true statement.
So “done” has to mean one thing, in one place. If you haven’t observed PlasmaBFT finality and written the idempotency key, the callback can’t be allowed to trigger fulfillment. If the reference isn’t locked before the relayer signs, retries will keep finding air.
Some teams harden it and move on. They commit the idempotency key before responding. They treat a slow 200 as dangerous. They let inventory wait a beat longer, even if it feels bad.
A lot keep patching. Checks after the fact. Nightly reconciliation. “We’ll clean it up.” It works until volume spikes and two callbacks arrive inside the same breath again.
The chain isn’t confused.
Your integration is late.
