Can a confirmed crypto payment disappear?

A reorganization — reorg — is what happens when a network decides that a different branch of recent history is the real one. Blocks that were on the losing branch are discarded, and any transaction that lived only in those blocks is no longer in the chain. For a merchant this is the one blockchain failure mode that is genuinely worth understanding, because it is the only one that can turn a shipped order into an unpaid one.

Everything below is about that decision. The mechanics of why chains fork are covered in how confirmations work, and the question of how many to require lives in tiered confirmations.

What does a reorg actually do to a payment?

It removes the record, not the money.

This is the distinction that makes reorgs confusing. Nothing was refunded and nobody reversed anything. The payer's wallet signed a transaction, that transaction was included in a block, and then the network chose a branch of history that did not contain that block. From the chain's point of view the payment now has never happened. The coins are wherever the winning branch says they are, which is usually still in the payer's wallet.

Most of the time the same transaction is picked up again shortly afterwards and everything resolves itself, because the transaction was valid and the network has no reason to reject it. The dangerous case is narrow: the payment was orphaned, your processor had already told you it was confirmed, and you acted on that.

Can a payment Paymos already confirmed disappear?

The confirmation can, yes. The credit cannot.

Confirming before protocol finality is a deliberate trade. Waiting for absolute finality on every network would make some payments unusably slow, so Paymos confirms at a depth chosen per network and per amount, which means it is possible — rarely — to confirm a payment whose block is later discarded.

What Paymos does not do is push the consequence of that trade onto the merchant. When a confirmed payment's block turns out to be gone, the merchant's credit stays exactly as it was. The platform records the shortfall against its own accounts as a reorg loss. In the ledger code the rule is written into a comment next to the posting itself: the merchant is not touched, their credit survived, and it must not be reversed and must not double.

Who pays for the difference?

Paymos does, and it is worth being precise about what that means.

The processor made a judgement call — confirm at this depth, on this network, for this amount — in order to give the payer a fast checkout. When that judgement is wrong, the coins are genuinely not there, and somebody's balance has to absorb the gap. Putting it on the merchant would mean a merchant's liability depends on a risk decision they never made and cannot see.

So the loss is booked to the platform. This is a policy, not a law of nature, and it is fair to ask any processor the same question directly: when you confirm early and the chain disagrees, whose balance moves? A processor that has not thought about it will not have an answer, and one that has will be able to name the account.

Why is the transfer not simply deleted?

Because deleting it is how double-credit bugs are born.

When a block is discarded, the natural instinct is to remove the record — the payment did not happen, so drop the row. Paymos does the opposite: transfers are sticky. The reorg path marks the transfer as a phantom and never deletes it.

The reason shows up when the transaction comes back. If the original record were gone, the re-inclusion would arrive looking like a brand-new payment, and the merchant would be credited a second time for a single transfer. Keeping the same transfer identity means the re-inclusion is recognised as the same payment returning, not as another one arriving. A separate record for one payment is forbidden outright, and it is forbidden for exactly this reason.

When does Paymos decide a block is really gone?

Only when protocol finality says so.

Chains switch tips routinely. A node can see one block at the head, then another a second later, without anything being wrong and without any transaction being lost. Treating every tip switch as a reorg would mean flagging phantom payments constantly, and the alerts would be worthless within a week.

So a transfer is marked phantom only when finality confirms the block is not in the finalized chain — the point past which the protocol itself says history does not change. And if a reorg ever reaches below that height, the pipeline does not try to reconcile it. It halts that network's cursor and stops, because a protocol violation is not a case to be handled automatically.

What tells you it happened?

On payment channels, a webhook. payment_channel.deposit.reorged is one of the three deposit events, alongside confirming and confirmed, and it is delivered on the same subscription.

The practical advice is to treat it as an operational alert rather than an accounting event. Your balance did not change, so there is nothing for your books to do. What the event tells you is that a specific order was settled on evidence that has since disappeared — which matters if the order is a physical shipment you can still stop, and matters much less if it was a download.

What happens if the transaction comes back?

The loss is reversed, and the merchant is untouched in that direction too.

A re-included transfer returns under its original identity, and the platform's reorg loss is reversed against the same accounts that absorbed it — the coins came back, so the loss nets to zero and the fee is re-recognised. The merchant's balance does not move, because it never moved in the first place. Being credited once and staying credited once, through an orphan and a return, is the whole design goal.

What should your order system do about this?

Less than you would expect, and the trap is doing more.

Your side of a crypto payment already has the shape it needs: an order is unpaid, then confirmed, then fulfilled. A reorg does not add a fourth state to that flow, because your balance never changes and there is nothing to reconcile. What it can add — if your goods are expensive and physically shippable — is a reason to keep a short window between confirmation and dispatch, so an alert has somewhere to land.

If your goods are not expensive or not physical, the correct engineering response is to do nothing at all. Building reorg handling into a checkout that sells downloads is work that will never pay for itself, and the loss it protects against is not yours anyway.

How do you test it before it matters?

Simulate it. The sandbox deposit simulation takes a stage, and reorged is one of the three values it accepts, alongside confirming and confirmed.

That is worth doing once, for a reason that has nothing to do with reorgs: it is the cheapest way to find out whether your webhook handler survives an event it was not expecting. Most integrations are written against the happy path and meet their first unusual event in production. This one you can meet on a Tuesday afternoon with nothing at stake.