What Merchant Integrations Now Look Like, and What Still Breaks

Crypto payment integrations converged on a common shape. The happy path is straightforward everywhere. The differences are in the failure cases, which is where the work is. It is worth checking what actually changed by comparing against a crypto acquiring provider, which operates under the new requirements.

What became standard

Signed callbacks. Every provider signs webhook payloads. Verification is a few lines and skipping it means anyone who learns your endpoint can mark orders paid.

Protection against duplicate processing. Delivery is at least once, not exactly once. Handlers must be idempotent on the payment identifier.

Quote expiry. Payment requests carry a window, and the provider’s behaviour after expiry is documented.

Hosted checkout as the default path. Most merchants use it and the API is a later optimisation.

What still causes support load

Payments arriving after expiry. Every provider handles it, differently: credit at the new rate, honour the old rate, or hold for review. A decision you need before launch, because it occurs in the first week.

Underpayment. Usually because the sender’s wallet deducted the network fee. Set a tolerance band and state on the payment page that fees are payable in addition.

Duplicate payments. Two transactions to the same address. Refund, credit, or balance. Decide.

The callback that never arrives. Your endpoint was down or delivery failed. You need a reconciliation job polling for payments whose status you have not updated. This is the most commonly skipped component and the one that produces the worst customer experience.

Wrong network deposits. Recovery varies from a documented process to nothing.

The reconciliation job

Deserves its own emphasis because almost nobody builds it initially.

Run hourly. Query the provider for payments in a window, compare against your own records, and update anything that diverged. Firms holding money for clients face a stricter version, which crypto rails built for fintech companies is structured to meet.

Without it, a customer who paid sees an unpaid order and contacts support, and support has no way to resolve it except manually.

Testing before launch

Use the sandbox for the happy path, then deliberately test expired payment, underpayment, overpayment, duplicate callback, and callback to a failing endpoint with recovery.

If a provider’s sandbox cannot simulate those, ask how their other merchants test them. The answer is informative.

The non-technical part that matters most

Customer-facing copy explaining what happens during confirmation.

A status of pending is not an adequate explanation to someone who has just sent money. Telling them what the wait is for and roughly how long measurably improves completion, more than any technical optimisation. The provision that only matters in a failure is the one worth checking first, and a provider you can actually reach states its position.