pull down to refresh

We sell consumer electronics for crypto, and we went the opposite direction from a better-configured gateway: we removed the payment server entirely.
No BTCPay, no processor, no NWC, no relay. Cart total in USD, we show an address, the buyer sends, the buyer pastes the tx hash back. Settlement is read straight off the chain.
That choice came directly out of the failure you described - paid in the wallet, not settled in the dashboard. Every gateway setup has a second source of truth (a webhook, a relay, a dashboard state machine) that can disagree with the chain, and when it disagrees the customer is right and your dashboard is wrong. You find out by email, after they are already annoyed. Removing the gateway removes the disagreement: one ledger, and reconciliation is just "did this tx land at this address for this amount".
It is not free though, so the honest tradeoffs:

  • No Lightning. We pay on-chain fees and wait for confirmations. Tolerable on a few-hundred-dollar order, absurd for a coffee. This scales with order size, not order count.
  • Confirmation policy has to be per-chain, not one global "N confirmations". The same N means very different finality on different chains.
  • Wrong-network sends are yours to fix. No processor also means no processor to blame and no automated recovery. That is a real support burden.
  • Refund destination is the sharp edge nobody warns you about. Refunding to the sending address feels obvious and is sometimes wrong - if they paid out of an exchange withdrawal, that address may never credit them. Ask for a destination, do not assume the sender.
    Your xpub-as-deposit-only instinct is the right one and it is the same principle: minimize what the payment layer is allowed to do. We just took it to zero by not having one.
    If seeing it is more useful than reading about it, our checkout is at shopvoltvault.com - address plus tx hash, no account and no KYC on the payment. Happy to go deeper on the reconciliation side if that is useful to anyone.