Crypto payment gateway: what actually breaks

The five failure modes that cost you money

Underpayments. A customer owes $200 in USDT and sends $198.60 because their exchange deducted a withdrawal fee they didn't notice. This happens constantly. A bad gateway marks the order failed and strands the money. A good one has a tolerance setting (accept anything within 1 to 2%) and a defined flow for the rest: prompt for the difference, partial-credit the order, or auto-refund. Ask the sales engineer what happens at $198.60. If they don't have an immediate answer, they haven't handled volume.

Rate lock windows. You price in dollars, the customer pays in crypto. Between checkout and payment, the price moves. Gateways lock the rate for a window, usually 10 to 20 minutes. Too short and customers who fumble with their wallet get an expired invoice at the exact moment they were ready to pay. Too long and the gateway is taking FX risk it will claw back from you somewhere. Find out the window, and find out who eats the difference when a payment lands after expiry.

Payment matching. Each order needs its own deposit address or payment ID, or you cannot tell which customer paid. Sounds basic. Some gateways reuse addresses per merchant and match by amount, which collapses the first time two customers owe $50.00 in the same hour.

Late or missing webhooks. Your fulfillment runs on the gateway telling you a payment confirmed. Check three things: webhooks are signed (unsigned webhooks will eventually get spoofed), retries happen on failure with a documented schedule, and there's a reconciliation API so you can poll for anything a webhook missed. During chain congestion, confirmation times stretch from minutes to hours. Your gateway should report "detected" and "confirmed" as separate events so you can show the customer something honest in between.

Refunds. There are no reversals on-chain, so a refund means collecting a return address from the customer and pushing a new transaction. Check whether the gateway has a refund flow with an audit trail or whether "refunds" means you manually sending crypto from a wallet with no record tying it to the order. The second one is how bookkeeping dies.

Network choices matter more than coin choices

Supporting "USDT" means nothing until you know which network. USDT on Ethereum can cost the customer $5 to $30 in gas at busy times. The same USDT on Tron costs cents. If your gateway only supports the expensive network, customers on small orders abandon at the fee screen. For a $40 average ticket, network support is a conversion question, not a technical one.

What to actually evaluate

Ignore the coin count on the pricing page. Ask for: the underpayment policy in writing, the rate lock window, per-order addresses, signed webhooks with retries, a refund flow, and stablecoin support on at least one cheap network. Then send a real $5 payment through a test account, underpay it on purpose, and watch what happens.

We built Flint's checkout around these exact cases, because we processed enough volume to hit every one of them. Run the underpayment test on us too.