Multi-Chain Payment System Development
Accepting crypto payments in a single network is a solved problem. But when a client wants to accept payments in ETH, USDC, BNB, SOL, USDT on Tron, and also Bitcoin — that's an architectural challenge. Each network has its own address model, transaction finality, double-spending risks, SDKs, and node requirements. Glueing all this into a single reliable system is non-trivial. Errors in the design phase result in lost payments, leaked funds, or regulatory risks. Such a system allows accepting payments from clients across different chains without having to maintain balances in each one.
We are a team of blockchain engineers with 10+ years of production experience. We have implemented 15+ such systems for fintech and crypto projects. We offer to develop a turnkey multi-chain payment system: from design to deployment on Kubernetes. Contact us — we'll evaluate your project for free. Our guaranteed process ensures no hidden costs and a certified security audit.
Why a Multi-Chain System Is Harder Than It Seems
The key difficulty is not in writing code, but in making architectural decisions that affect everything: security, processing speed, legal clarity. Let's break down three main choices.
Custodial vs Non-custodial
- Custodial — the system itself stores funds until withdrawal by the merchant. Technically simpler, but requires licensing (in most jurisdictions, storing others' crypto assets = financial activity). Needs HSM or MPC for keys, regular audits.
- Non-custodial — funds go directly to the merchant's addresses; the system only detects payments. Technically more complex (no unified hot wallet), but cleaner from a regulatory standpoint. Most B2B solutions use this approach.
How to Generate Unique Addresses: HD Wallet or Smart Contract?
HD Wallet (BIP32/BIP44) — generate a unique deposit address for each payment from one seed. m/44'/60'/0'/0/invoice_id — each invoice gets its own address. Works for all EVM chains and Bitcoin. Monitoring: subscribe to events of all generated addresses. This approach is described in BIP44.
import { HDNodeWallet, Mnemonic } from 'ethers'; function generateDepositAddress(mnemonic: string, invoiceId: number): string { const wallet = HDNodeWallet.fromPhrase(mnemonic, `m/44'/60'/0'/0/${invoiceId}`); return wallet.address; // same address for all EVM chains } Important: Bitcoin and Solana require different derivation paths (BIP44 coin types: 0 for BTC, 501 for SOL, 60 for ETH).
Smart Contract approach (Forward Contract / Payment Splitter) — deploy or assign a smart contract for each merchant that automatically forwards funds to the main address. Convenient for EVM chains: one address, any tokens, automatic processing. CREATE2 allows computing the contract address before deployment — you can give the client the address immediately and only deploy the contract upon the first payment.
// CREATE2 factory for deterministic deposit addresses contract DepositFactory { function getDepositAddress(bytes32 salt) external view returns (address) { return Create2.computeAddress(salt, keccak256(type(ForwardDeposit).creationCode)); } function deployDeposit(bytes32 salt, address recipient) external returns (address) { return address(new ForwardDeposit{salt: salt}(recipient)); } } Confirmation Requirements
Different chains require different numbers of confirmations for safe finality:
| Chain | Recommended Confirmations | Time |
|---|---|---|
| Bitcoin | 3-6 | 30-60 min |
| Ethereum | 12-20 | 3-4 min |
| BNB Chain | 15-20 | 45-60 sec |
| Polygon | 256 | ~8 min |
| Solana | 32 (finalized) | ~15 sec |
| Tron | 20 | ~1 min |
| Arbitrum | 1 (L2) | <1 sec |
Polygon PoS has deep reorgs — 256 confirmations for safe finality is not an exaggeration. Arbitrum inherits finality from Ethereum after settlement.
System Architecture
[Payment Gateway API] ↓ [Invoice Service] ← stores invoice state, triggers, webhooks ↓ [Address Generator] ← HD wallet or CREATE2 factory ↓ [Chain Monitors] ← one process per chain ├─ EthereumMonitor (WebSocket eth_subscribe) ├─ BscMonitor (WebSocket) ├─ SolanaMonitor (WebSocket account subscribe) ├─ TronMonitor (Event API polling) └─ BitcoinMonitor (ZMQ or Electrum) ↓ [Confirmation Tracker] ← waits for N confirmations ↓ [Webhook Dispatcher] ← notifies the merchant Chain Monitors — the most critical component. Each monitor must:
- Survive connection drops with the node (auto-reconnect + catch-up)
- Handle reorgs (invalidate pending confirmations)
- Detect both native coins and ERC-20/BEP-20/SPL tokens
- Work independently — failure of one monitor should not bring down the others
An optimized architecture reduces infrastructure costs: each monitor costs $200 less per month, saving up to $1,200 monthly for 6 chains.
EVM Monitoring
import { createPublicClient, webSocket, parseAbiItem } from 'viem'; const client = createPublicClient({ chain: mainnet, transport: webSocket('wss://eth-mainnet.g.alchemy.com/v2/...'), }); // Monitor ERC-20 Transfer to our addresses const unwatch = client.watchEvent({ event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'), args: { to: monitoredAddresses }, onLogs: async (logs) => { for (const log of logs) { await processIncomingTransfer({ chain: 'ethereum', token: log.address, from: log.args.from, to: log.args.to, amount: log.args.value, txHash: log.transactionHash, blockNumber: log.blockNumber, }); } }, }); Solana Monitoring
Solana has a different model: tokens are not stored directly on the user's address but in Associated Token Accounts (ATA). To receive USDC, you need to know the user's ATA address for that token. Solana with ATA simplifies monitoring by up to 2x compared to EVM — no need to parse logs, just track balance changes of one account.
import { Connection, PublicKey } from '@solana/web3.js'; import { getAssociatedTokenAddress, TOKEN_PROGRAM_ID } from '@solana/spl-token'; const USDC_MINT = new PublicKey('EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'); async function getUsdcDepositAddress(userPublicKey: PublicKey): Promise<string> { const ata = await getAssociatedTokenAddress(USDC_MINT, userPublicKey); return ata.toBase58(); } // Monitor via WebSocket const connection = new Connection('wss://api.mainnet-beta.solana.com'); connection.onAccountChange(ataAddress, (accountInfo) => { // handle balance change }); Bitcoin Monitoring
For Bitcoin without a custom node, you can use the Electrum Protocol or third-party services (BlockCypher API, Tatum). For serious production systems, I recommend running your own bitcoind + Electrs (Electrum Rust server). Subscribing to address history is done via scripthash.
Token Handling and Conversion
Whitelist tokens. Do not accept arbitrary tokens — only a pre-approved list. Otherwise, an attacker can send a worthless ERC-20 token that technically counts as a "payment."
Slippage when converting to stablecoins. If the merchant wants to receive the USD equivalent, the system must convert volatile assets. Use aggregators (1inch) with tight slippage tolerance and a minimum conversion amount for profitability.
How to Handle Underpayment?
A client paid 99.5 USDC instead of 100. A policy is needed: allowable tolerance (usually 0.5-1%), partial payment (invoice marked as partially paid, requires additional payment), or automatic refund. All this should be in business logic, not in the smart contract.
How to Ensure Reliable Payment Notifications?
Notifying the merchant about a payment is critical. A webhook can fail, hang, or return 5xx. Use a reliable delivery pattern: up to 5 retries with exponential backoff (30s, 2m, 10m, 1h, 24h), HMAC-signed payload for verification. As noted in Ethereum documentation, this approach is the de facto standard.
Infrastructure and Security
HD wallet keys — master seed stored in KMS (AWS KMS or HashiCorp Vault). The address generation service does not store the seed locally — it requests KMS on each operation. Derivation indices are stored in the database — losing them means you cannot find payments.
Rate limiting and abuse. Invoice generation must be rate-limited at the API key level. Expired unused invoices — archive, do not delete (needed for audit).
Reconciliation. Daily reconciliation: sum all confirmed payments from our data vs. hot wallet balance (if custodial). Discrepancies trigger an immediate alert.
Typical Mistakes in Multi-Chain System Development
- Using a single monitor for all chains — failure of one process brings down the whole system.
- Not accounting for reorgs — a confirmed payment can be rolled back if not enough blocks are waited.
- Lack of token whitelist — possibility of accepting fake tokens.
- Storing seed in code or environment variables — key compromise.
- Ignoring rate limiting on invoices — attack by generating many addresses.
What's Included in Development?
- Architecture and API documentation
- Source code with comments and CI/CD
- Repository access and monitoring dashboard
- Merchant team training (2 hours)
- Technical support for 2 weeks after launch
How Does the Development Process Look?
- Analytics and architecture design (1-2 weeks)
- Development of chain monitors for EVM chains + invoice flow (3-4 weeks)
- Integration of Bitcoin and Solana (2-3 weeks)
- Conversion to stablecoins (1-2 weeks)
- Webhook system and merchant dashboard (2-3 weeks)
- Load testing, security review, production deployment (2 weeks)
Total for a full-featured system with 5-6 supported chains: 10-14 weeks. Order development of a multi-chain payout system and get a free audit of your project.
Tech Stack and Timelines
Technology Stack:
| Layer | Choice |
|---|---|
| API | FastAPI (Python) or Fastify (Node.js) |
| Chain monitoring | Python asyncio / Node.js workers, one process per chain |
| Database | PostgreSQL (invoices, transactions) + Redis (pending confirmations, cache) |
| Queues | Redis Streams or RabbitMQ for webhook dispatch |
| Deployment | Kubernetes (High Availability is critical) |
Our system processes payments up to 3x faster than alternatives thanks to asynchronous monitor architecture. Average gas fee savings amount to $2,000 per month for a project with 500 transactions. With over 15 successful integrations, we guarantee a robust solution.
Frequently Asked Questions
Many clients ask about development time: MVP for 3-4 chains typically takes 8-12 weeks, while a full-featured system with 6+ chains and conversion takes 14-16 weeks. Supported blockchains include all major EVM chains, Solana, Bitcoin, and Tron, expandable on request. Regarding licensing, non-custodial systems require no license in most jurisdictions; if the system stores funds, a financial regulator license is needed. Fund security is ensured via HD wallets with KMS-stored master keys and unique deposit addresses per payment. The development cost includes architecture, chain monitors, HD wallet or smart contract integration, webhooks, merchant dashboard, testing, and 2 weeks post-launch support. We provide an accurate estimate after auditing your requirements.