Most crypto payment gateways are either:
- Custodial (they hold funds)
- Single-chain
- Or just hosted checkout wrappers
We took a different approach.
Instead of building another wallet or custody layer, we built a non-custodial multi-chain settlement infrastructure that processes thousands of transactions daily across:
- EVM networks
- Tron
- Solana
- Bitcoin
Here’s what we learned architecting it.
The Core Design Principle: No Custody
We made one architectural decision early:
The platform should never hold merchant funds.
That means:
- No private key storage
- No merchant balances stored on the platform
- No withdrawal queues
- No internal ledger custody
Instead, funds settle directly to merchant-controlled addresses.
This immediately changes:
- Risk surface
- Compliance scope
- Security architecture
- Operational complexity
It also forces better engineering decisions.
Multi-Chain Is Not Just “Add Network”
Supporting EVM + Tron + Solana + Bitcoin is not configuration work.
Each chain has fundamentally different models.
1️⃣ EVM Networks
EVM chains allow:
- Smart contracts
- Deterministic address generation
- Minimal proxy deployments
- CREATE2 address predictability
For EVM-based payments, you can:
- Use forwarding contracts
- Use deterministic per-order addresses
- Optimize deployment cost via proxy patterns
- Track confirmations via event logs
EVM gives you programmability and abstraction flexibility.
2️⃣ Tron (TRC-20 / TRX)
Tron looks similar to EVM but differs in:
- Energy + bandwidth resource model
- Fee delegation patterns
- Contract execution behavior
- Different RPC behavior and tooling
Naively deploying contracts per order becomes expensive.
Scalable design requires:
- Address pooling + controlled forwarding logic
- Contract reuse strategies
- Merchant resource management
3️⃣ Solana
Solana is completely different:
- Account-based model
- Program Derived Addresses (PDA)
- No EVM-style contracts
- Different confirmation tracking logic
- SPL token standards
You cannot copy EVM logic.
You must design around:
- Account mapping
- Program-level authority
- Deterministic derivation
- Signature and confirmation monitoring
The SDK abstraction layer becomes critical.
4️⃣ Bitcoin (UTXO Model)
Bitcoin is the most different:
- No smart contracts like EVM
- UTXO-based
- No contract-based forwarding
- HD wallet derivation required
To support per-order deposits without custody:
- Use xPub-based deterministic derivation
- Map addresses per order
- Monitor mempool + confirmations
- Handle change outputs carefully
Bitcoin forces a completely different system design.
The Abstraction Layer Is the Real Product
The hardest problem isn’t chain logic.
It’s giving merchants:
- One SDK
- One API
- One webhook format
- One confirmation model
While internally handling:
- Different RPC stacks
- Different confirmation thresholds
- Different fee models
- Different address generation logic
- Different transaction parsing logic
The abstraction layer becomes the infrastructure product.
What Scale Taught Us
Processing thousands of daily transactions revealed:
Confirmation Handling Is Chain-Specific
Bitcoin confirmation logic ≠ Solana confirmation logic ≠ EVM block confirmation.
You need configurable thresholds and event normalization.
Fee Optimization Matters
- Gas volatility on EVM
- Energy costs on Tron
- Priority fees on Solana
- Fee rate estimation on Bitcoin
Static fee logic fails at scale.
Dynamic fee estimation and monitoring are required.
Deterministic Mapping Prevents Chaos
For multi-chain payments:
- Order → Unique address
- Address → Merchant mapping
- Payment → On-chain validation
- Validation → Webhook trigger
If mapping isn’t deterministic and indexed correctly, reconciliation becomes painful.
Webhook Reliability Is Infrastructure
Once payment is detected and confirmed:
- Retry logic
- Idempotency
- Signature verification
- Delayed confirmation handling
are not optional.
Payments are infrastructure.
Reliability > features.
Flat Fee vs Percentage: Why Fixed Pricing Makes Sense
Blockchain transaction costs do not scale linearly with transaction value.
Charging 3% on a $10,000 USDT payment makes little engineering sense.
Flat pricing aligns better with blockchain economics and simplifies merchant cost modeling.
Non-Custodial Reduces Systemic Risk
By not holding funds:
- No platform balance risk
- No mass withdrawal events
- No custody security liability
- Reduced regulatory exposure
This shifts the system closer to infrastructure rather than financial intermediary.
Where This Model Works Best
- Global SaaS
- High-volume digital commerce
- Marketplaces
- Gaming ecosystems
- Web3-native apps
- Emerging market payments
If your customers are multi-region, multi-chain support becomes mandatory.
Final Thoughts
Building a multi-chain payment processor is not about supporting tokens.
It’s about supporting fundamentally different settlement architectures under one unified system.
- EVM gives programmability
- Tron gives USDT liquidity
- Solana gives high throughput
- Bitcoin gives global recognition
Unifying them without custody is the real engineering challenge.
That’s the direction we chose.
About PayerOne
PayerOne is building non-custodial, multi-chain payment infrastructure supporting EVM networks, Tron, Solana, and Bitcoin.
We process thousands of transactions daily with direct wallet settlement and fixed transaction pricing.
Website: https://payerone.com
Documentation: https://www.payerone.com/developer
Top comments (0)