The decision is about ownership, not ideology
Teams often frame crypto payments as a choice between “easy gateway” and “real blockchain”. That framing is unhelpful. Both can be production-grade. The actual question is which responsibilities should belong to the product and which should belong to a specialised provider.
Eight boundaries to evaluate
1. Customer payment UX
If a hosted checkout is acceptable, a provider can reduce implementation scope significantly. If the payment must behave like a native account deposit with a persistent or per-intent address, custom wallet infrastructure becomes more relevant.
2. Address generation
Ask whether the product needs a unique address per payment, per customer, per merchant or only a provider-generated invoice address. Address allocation is not a visual detail; it determines matching, privacy, treasury and recovery strategy.
3. Key and custody boundary
With custom wallets, you must explicitly decide who can authorise outgoing transactions, how keys are protected, how signers are isolated and what happens during incidents. Managed providers move much of this responsibility outside the application boundary.
4. Chain observation
A provider exposes an order status model. A custom system needs its own RPC/indexer strategy, checkpoints, retries, finality policy and replay mechanism. If you cannot replay missed blocks or duplicate events safely, you do not yet have a production payment observer.
5. Asset conversion and settlement
If the business ultimately wants EUR or USD, provider-native conversion and withdrawal can simplify operations. If the business wants to hold, route or programmatically use stablecoins, a custom treasury layer may provide more flexibility.
6. Product ledger
This responsibility remains inside your product in both models. Provider state and blockchain state are evidence. The product ledger is the authoritative business interpretation of that evidence.
7. Exceptions and support
Who investigates a wrong network, unsupported token, late transfer, duplicate callback, refund mismatch or settlement discrepancy? The answer should be visible in the architecture before launch.
8. Reconciliation
A gateway gives you provider reports; custom infrastructure gives you raw chain evidence. Neither automatically reconciles your invoice system, product ledger, refunds, fees and bank records.
Decision table
| Question | Prefer managed provider when… | Prefer custom wallets when… |
|---|---|---|
| Is crypto mainly a checkout method? | Yes | No — it is a core product behavior |
| Need fiat settlement? | Yes, provider support is useful | Not necessarily or separate rails exist |
| Need persistent/dedicated addresses? | Not essential | Yes |
| Need direct treasury automation? | Limited | Yes |
| Want fastest launch? | Usually | Only if infrastructure already exists |
| Can team operate keys/chain services? | Not required | Required directly or through infrastructure vendors |
Do not compare only transaction fees
Custom infrastructure may avoid a gateway processing fee, but it introduces engineering and operating cost: wallet infrastructure, monitoring, RPC/indexing, incident response, reconciliation, security reviews and support. The correct comparison is total cost of ownership at the expected volume and product complexity.
The hybrid architecture
Many mature products eventually use both approaches. A managed gateway can handle merchant checkout and fiat settlement while product-owned wallets support treasury, partner payouts or native on-chain features. The internal ledger becomes the integration boundary between these rails.
A simple recommendation rule
If removing blockchain from the product would leave the core product model unchanged, start with a managed gateway. If removing blockchain would break the product’s core account, deposit, settlement or treasury behavior, design custom wallet infrastructure.
Next steps
Start with the broader USDC payment architecture guide. If the managed model fits, continue with the CoinGate integration guide. If custom wallets fit, design the internal ledger and reconciliation process before launch.
Security and operational ownership
The custom model does not necessarily mean storing raw private keys inside application servers. Modern wallet infrastructure can provide MPC, policy controls, programmable signing or user-controlled authorization. But the product team must still decide who is allowed to initiate transactions, which actions require review, how permissions are separated and how incidents are contained.
In a managed-provider model, more controls live outside the product boundary. That reduces direct responsibility, but it creates a dependency on provider availability, API contracts, account limits and provider compliance decisions. Production architecture should therefore include provider-health monitoring and a manual operational path.
Provider migration and portability
A common mistake is to allow provider identifiers and statuses to leak into every business table. This makes switching providers disproportionately expensive. Keep a provider adapter behind a product-owned payment intent and state model. The provider should be replaceable without rewriting invoices, entitlements or the internal ledger.
Scale changes the decision
At low and medium volume, engineering simplicity often matters more than marginal transaction cost. At higher volume, transaction economics, routing control, treasury automation and liquidity strategy can justify owning more infrastructure. The architecture should therefore be reviewed against realistic volume and operational assumptions rather than a theoretical “future scale”.
Team capability is part of architecture
A technically elegant custom wallet system is still a poor decision if nobody owns chain operations, key-policy review, incident response, reconciliation and security. Conversely, an experienced FinTech or blockchain team may choose custom infrastructure precisely because those capabilities already exist. Architecture is partly a function of organizational capability.