Crypto Payment Gateway: What Sits Between the Customer and Your Bank

A crypto payment gateway looks like one product and is five components. Knowing which component causes which failure makes provider comparison considerably more concrete. It is worth pinning this to something concrete, and a crypto acquiring provider publishes the numbers the argument turns on.

Component one: address generation

For each payment, the gateway needs a way to identify which incoming transaction belongs to which order.

Most gateways derive a unique address per payment from a hierarchical deterministic wallet. Some use a shared address with a memo or tag, which works on chains that support it and creates attribution problems on chains that do not.

Unique address per payment is the better design. It makes attribution unambiguous and it means a customer paying the wrong amount or paying twice is still attributable.

Component two: monitoring

The gateway watches the chain for incoming transactions to its addresses. This sounds trivial and is where reliability differences originate.

A gateway running its own full nodes sees transactions directly. A gateway depending on a third party data provider inherits that provider’s outages and its view of the chain. During congestion or a reorganisation, the difference becomes visible.

Ask whether the provider runs its own nodes for the chains it supports. The answer correlates well with how the gateway behaves on a bad day.

Component three: confirmation policy

How many confirmations before the payment is treated as settled. Too few and a reorganisation can reverse a payment you have already fulfilled. Too many and the customer waits.

A sensible policy scales with amount: small payments accepted at one confirmation or even at broadcast with a risk score, large payments requiring more. A flat policy of six confirmations on every payment regardless of size is safe and it is a poor customer experience for a twenty euro purchase.

Ask whether the policy is configurable per amount band.

Component four: conversion

The received crypto becomes fiat. Either the gateway holds inventory and quotes from it, or it routes to an exchange.

Inventory-based is faster and the quote is firm. Exchange-routed is subject to the liquidity available at the moment of conversion, which matters for large payments in less liquid assets. The institutional version of the same problem runs through crypto rails built for fintech companies, with an extra reporting layer on top.

For typical e-commerce amounts this is invisible. For large B2B invoices it is not, and you should ask what happens to a payment large enough to move the market in the asset received.

Component five: settlement

Fiat leaves the gateway and arrives at your bank. Same considerations as any offramp: rail, currency, cut-off times, and whether the receiving account can be in your company name.

The settlement schedule is a working capital question. Daily settlement is better than weekly for cash flow, and weekly is cheaper for the provider, so it is often the default. Ask whether daily is available and at what volume.

Where each component fails

Address generation: attribution errors, usually with memo-based systems. Monitoring: missed or delayed payments during congestion or provider outages. Confirmation policy: either reversals if too loose or abandoned carts if too strict. Conversion: unfavourable rates on large or illiquid payments. Settlement: bank returns and cut-off delays.

Asking a provider about each component separately produces much better information than asking about the product as a whole.

What integration actually involves

Three options in increasing order of effort.

Hosted checkout. Redirect the customer to the provider’s page. Fastest, least control, provider handles the entire payment experience.

Embedded widget. The payment interface inside your page. Moderate effort, better experience, you still do not handle funds.

Direct API. You call for a payment request, display it yourself, and consume webhooks. Most control, most work, and you are responsible for the edge cases.

For most merchants the hosted checkout is correct at launch and the API is a later optimisation. Starting with the API because it seems more professional is a common way to delay launch by a month.

A cryptocurrency payment gateway that settles to a bank account should offer all three and be candid about which one its other clients actually use.