Crypto Payment Gateway Development

Crypto Payment Gateway Development

The main mistake when designing a crypto payment gateway is trying to fit the traditional fiat payment model onto blockchain. Fiat payments have authorization, capture, refund, and chargebacks. Blockchain has only confirmed transactions and no forced reversal. Everything else must be built around this fundamental difference. This architectural gap determines how addresses are designed, confirmations are processed, and funds are swept. Ignoring it leads to double-spend vulnerabilities and loss of funds.

We develop crypto payment gateways with this architectural difference in mind. Our team has blockchain development experience and has delivered over 20 projects for accepting cryptocurrency payments in B2B and B2C. We offer a turnkey solution from architecture design to deployment and support. Every project undergoes a technical security audit and load testing before launch.

One common pain point is high transaction costs and long confirmation waits, especially in networks with congested mempools. Properly configuring sweeps and choosing send timings can cut gas fees by up to 30%. Gas optimization is a key focus during design. Contact us—we will help you reduce costs.

How to Properly Configure HD Wallet Derivation?

Two approaches with fundamentally different trade-offs. HD wallet derivation reduces confusion risk by 100 times compared to a shared deposit address without a memo.

1. One address per order (HD wallet derivation) For each new payment we derive a unique address from the master xpub key using path m/44'/60'/0'/0/{orderId}. The customer sees a unique address for their order—no amount confusion, no conflicts between concurrent payments. The private key for sweeping is derived offline, only at withdrawal time.

   import { HDNodeWallet, Mnemonic } from "ethers"; function derivePaymentAddress(xpub: string, index: number): string { const node = HDNodeWallet.fromExtendedKey(xpub); return node.deriveChild(index).address; } 

   Problem: thousands of addresses to monitor. Solution—webhook subscriptions via Alchemy/Moralis/QuickNode for Activity on specific addresses, or a custom node using eth_getLogs over a block range.

   Shared deposit address with memo/tag One address, customer includes a unique payment ID in the data field. Simpler infrastructure but creates a UX problem: the user must remember the memo. Works in B2B, often fails in B2C.

   Why Multi-Currency Support Is Critical for a Gateway?

   Minimum production set today: ETH, USDT (ERC-20), USDC (ERC-20), BNB, USDT (BEP-20), BTC, TRC-20 USDT. Each network requires a separate monitoring worker.

   For ERC-20 tokens, monitoring via the Transfer(address indexed from, address indexed to, uint256 value) event:

   const transferTopic = ethers.id("Transfer(address,address,uint256)"); const logs = await provider.getLogs({ address: USDT_CONTRACT, topics: [transferTopic, null, ethers.zeroPadValue(depositAddress, 32)], fromBlock: lastCheckedBlock, toBlock: "latest", }); 

   How to Implement a Confirmation Worker Step by Step

   1. Receive new transaction notification via webhook or polling.
   2. Calculate confirmation count (difference between current block and transaction block).
   3. If below threshold—set status to CONFIRMING.
   4. When threshold reached—set to CONFIRMED and trigger sweep.
   5. After successful sweep—mark as CREDITED.

   Critical component: service tracking transaction status. Logic:

   PENDING → CONFIRMING (1 confirmation) → CONFIRMED (N confirmations) → CREDITED 

   Confirmation count depends on amount and network:

   Network	Small (<$100)	Medium ($100–$10k)	Large (>$10k)
   Ethereum	2 blocks	6 blocks	12 blocks
   BSC	15 blocks	30 blocks	60 blocks
   Bitcoin	1 confirmation	3 confirmations	6 confirmations
   Tron	20 blocks	40 blocks	60 blocks

   Reorgs are a real issue on BSC and fast-block EVM networks. The worker must detect reorgs (transaction blockhash changed) and roll back payment status.

   Typical gas costs for sweep transactions (gas price in Gwei):

   Network	Gas limit for token transfer	Average gas price (Gwei)
   Ethereum	65,000 – 80,000	20–50
   BSC	65,000 – 80,000	5–10
   Polygon	65,000 – 80,000	30–100
   Arbitrum	65,000 – 80,000	0.1–1

   Hot Wallet and Sweeping

   After payment confirmation, funds on the deposit address need to be swept to a hot wallet. For EVM networks this is a separate transaction with gas that must be funded:

   async function sweepDeposit(depositIndex: number, amount: BigInt) { const depositKey = derivePrivateKey(masterKey, depositIndex); const depositWallet = new ethers.Wallet(depositKey, provider); // First send ETH for gas await hotWallet.sendTransaction({ to: depositWallet.address, value: GAS_BUDGET, // ~0.001 ETH }); // Then sweep tokens const token = new ethers.Contract(TOKEN_ADDRESS, ERC20_ABI, depositWallet); await token.transfer(hotWalletAddress, amount); } 

   For ERC-20, there is a permit pattern (EIP-2612) — if supported, you can sweep without prior ETH gas transfer via transferFrom with a signature.

   Security

   Segregation of keys: master xpub (for address derivation) is stored in the application. Private keys are derived only for sweep operations, and only in an isolated signing service. Hot wallet — separate HSM or KMS (AWS KMS, GCP Cloud HSM).

   Double-spend protection: do not credit until confirmation threshold is reached. Do not trust pending transactions—mempool can be replaced via RBF (Replace-by-Fee) on Bitcoin.

   Rate limiting on deposit addresses: one address should receive one payment. After receiving the first transaction, mark the address as "used"; new transactions on it are handled separately with an alert.

   Webhook signatures: all outgoing payment notifications are signed with HMAC-SHA256 using a secret. The recipient verifies the signature—protection against webhook forgery.

   How to Choose a Production Stack?

   Recommended configuration:

   • Backend: Node.js/TypeScript or Go for workers (high concurrency)
   • Queue: Redis + BullMQ or RabbitMQ for event processing
   • DB: PostgreSQL for payments, separate audit table (append-only)
   • Node monitoring: Alchemy/QuickNode with failover to backup provider
   • Alerts: Grafana + PagerDuty for worker stalls, anomalous amounts, confirmation errors

   The stack is chosen based on expected load. For pilot projects a minimal configuration suffices; for production a fault-tolerant cluster is needed. Order gateway development with security guarantees—we will propose the optimal solution for your business.

   What Is Included

   • API documentation (webhook notifications, REST endpoints for creating payments and checking status)
   • Monitoring access and transaction dashboard
   • Team training on gateway administration
   • 1-month support after launch

   Development Timelines

   MVP with 3-4 networks and a basic dashboard: 1-2 weeks if blockchain infrastructure is ready. Full-featured gateway with adaptive confirmation and sweep system: from 4 weeks. Contact us for an accurate estimate of your project. For a consultation, contact us—get a free estimate.

   Basic architectural principles are described in BIP32 and EIP-2612.