Crypto Payment System Architecture: The 6 Layers and How Money Moves Through Them

If you're building crypto payment infrastructure, it's tempting to treat it as one thing: a system that moves stablecoins from A to B. In practice, that "one thing" is six distinct layers stacked on top of each other, each with its own job and its own security boundary — and two distinct money flows running across them.

It also helps to clear up common misconceptions between layers early. One example: assuming MPC signing by itself makes a wallet self-custodied — when custody actually depends on who holds the key shares needed to meet the signing threshold, not which technique split the key. Another: a customer paying you and you paying someone else look like the same thing, a stablecoin transfer. They aren't. Getting them backwards — treating a payout like a pay-in, or skipping a check because "it's just receiving money" — is how tainted funds end up credited or how a payment leaves before anyone should have approved it.

We break this down as part of our broader crypto payment security and compliance playbook, the same six-layer model this series uses to map each layer's responsibility and security boundary.

Here's each layer in turn: the blockchain and stablecoin foundation, the wallet and custody layer, on-ramp/off-ramp, business logic, compliance, and the application layer — along with the security boundary that matters at each one. Then we walk both money flows step by step, and call out the checkpoints that are easy to build wrong.

1. The Blockchain and Stablecoin Foundation

The blockchain layer is the base of the whole payment system, and the root source of many of stablecoins' advantages.

What makes it different from a bank wire is simple: value transfer and clearing/settlement happen on the same, commonly accepted ledger. In traditional finance, transfer and clearing are two separate steps run by different intermediaries, followed by cross-institution reconciliation. On a blockchain, a confirmed transfer is a completed settlement — there's no separate clearing step and no after-the-fact reconciliation. That "shared ledger, transfer equals settlement" mechanism is exactly what delivers minute-level finality, disintermediation, 24/7 availability, and traceability.

On that shared ledger, a stablecoin is an issuer-minted ERC-20 token that adds admin functions — mint, burn, blacklist, and pause — which keep it from being a fully decentralized asset, since the issuer retains control over the token. We unpack what that issuer control means for a business in stablecoin payments explained.

Multi-chain and cross-chain

Stablecoins live across many chains, each with its own niche. Ethereum is the default for DeFi and institutional settlement, Solana suits high-throughput payments, TRON dominates low-fee remittance and emerging markets, and L2s like Base and Arbitrum offer low-cost payment lanes. As of May 2026, Ethereum holds about 52% of stablecoin supply and TRON about 28% — no single chain dominates outright, so most companies end up needing multi-chain support.

When you need to move stablecoins between chains, three approaches are common: third-party bridges, an issuer's native cross-chain protocol (such as Circle's CCTP, which uses burn-and-mint for native USDC transfer), or moving between chains via deposits and withdrawals at a centralized exchange. Cross-chain isn't a core capability of a payment system — pick as needed. What matters is the security of each approach: third-party bridges and their locked liquidity pools have long been high-value targets, while the exchange route carries counterparty and freeze risk.

2. The Wallet and Custody Layer

The wallet and custody layer handles storage and signing of funds, and it's the core of payment-system security.

The first decision here: do you hold the keys yourself, or hand them to a third party?

• Self-custody — the keys needed to meet the signing threshold are entirely in your own hands, whether you hold private keys directly or use MPC to spread the key as shares across your own people and infrastructure. No external party can move funds alone. The upside is no dependence on a third party and no counterparty risk; the cost is that all security responsibility is yours, and a lost or stolen key or share means funds are gone for good.
• Third-party (centralized/qualified) custody — a licensed custodian holds the keys, or the shares meeting the threshold, and you operate funds through accounts and APIs. You outsource key security to specialists, usually with insurance and compliance credentials and a lighter operational load, at the cost of counterparty risk (the custodian getting hacked, going bankrupt, or freezing your account) and partial loss of control.
• Hybrid/co-custody — you and the custodian each hold part of the MPC key shares, neither side's shares are enough to sign alone, balancing control with professional custody.

One misconception is worth clearing up here: MPC is only a technique that lets a key exist as distributed shares and removes a single point of failure — it doesn't by itself determine the nature of custody. To tell which type you actually have, look at one thing: who holds the key shares needed to meet the signing threshold.

Neither self-custody nor third-party custody is strictly better. Many payment companies land on a hybrid strategy: self-custodying hot wallets for speed, and using third-party custody or co-custody for large reserves.

The three-tier wallet architecture

It's also easy to conflate a wallet's temperature (hot / warm / cold) with its authorization model (MPC / multisig) — but they're two independent dimensions. Temperature decides whether the wallet is online and how quickly funds can move; the authorization model decides how many parties need to sign. Industry practice combines both into a three-tier structure:

Separate from key storage, there's a related question: how do you manage receiving addresses? HD (Hierarchical Deterministic) wallets solve this by generating a unique address per receipt, keeping funds isolated to avoid cross-contamination — which matters for KYT risk control and fund tracing. We go deeper on how HD derivation, self-custody, MPC, and multisig fit together in crypto payment key management.

3. The On-Ramp / Off-Ramp Layer

The on/off-ramp layer is the bridge between traditional finance and the on-chain world.

• On-ramp (fiat → stablecoin) — a user pays in fiat by bank transfer or card, passes KYC, and then the issuer mints or the user buys the stablecoin via an exchange.
• Off-ramp (stablecoin → fiat) — the stablecoin is burned or sold via an exchange, and fiat is paid out to the user through a bank.

Three ramp channels are common, each with a different cost and barrier:

• Direct issuer mint/burn — lowest cost, since mint and redemption are usually free or near-free with bank wire fees as the main expense, but it typically requires institutional standing and compliance credentials.
• Exchange deposits and withdrawals — low barrier and broad coin coverage, but higher cost (card is the most expensive channel, bank transfer lower), and it introduces the exchange's counterparty and freeze risk.
• OTC desks — for large, institutional-grade conversions, priced by negotiated quote with spreads set by trade size and liquidity, usually tighter than retail channels for large tickets. OTC desks operate 24/7, support wire/SWIFT, and settle same-day, making them the workhorse for large ramps.

Here's the catch: the on-chain and fiat legs of a ramp run on different clocks. On-chain settlement may be minute-level, but the fiat leg is still bound by the operating hours and cutoffs of SWIFT, SEPA, and local clearing — so the real speed of a ramp is set by the slower fiat leg, not the faster one. On the compliance side, the ramp is the key gate for KYC/KYB, sanctions screening, and source-of-funds review, all of which need to happen before funds are released. The pay-in and pay-out walkthroughs further down trace the screening checkpoints inside each flow.

4. The Business Logic Layer

The business logic layer wraps the underlying capabilities into an actual payment product. Its main components:

• Payment routing engine — picks the optimal path automatically based on coin, chain, amount, and gas price.
• FX engine — real-time quotes, slippage control, price-lock windows.
• Invoicing and order management — payment request creation, status tracking, timeout handling.
• Reconciliation and settlement — automatic matching of on-chain transactions to business orders, with discrepancy handling.

If your company does more than pass a transaction through — if you custody and hold customer balances, taking on some bank-like functions — this layer needs withdrawal-approval controls too. Customer withdrawals go through risk approval, limits, and multi-person review; customer funds are segregated from your own operating funds; and solvency is guaranteed at all times, meaning there's always a matching reserve for what customers can withdraw. That's both a risk-control practice and, in most countries and regions, a compliance requirement for holding customer funds.

5. The Compliance Layer

The compliance layer cuts across every transaction, intercepting in real time as a transaction happens rather than reviewing it after the fact. Its capabilities include KYC/KYB (customer onboarding), KYT (real-time transaction monitoring), sanctions screening, and SAR (suspicious activity reporting). We break down how those capabilities actually work — and the stablecoin freeze risk that sits alongside them — in on-chain compliance for crypto payments.

6. The Application Layer

The application layer is the interface for end users and merchants: merchant SDKs, payment pages, admin consoles, and API gateways. There are two deployment models here — software-only, where the company integrates banks and on-chain nodes itself, and bundled rails, where a platform provides an all-in-one service.

The Pay-In Flow: From Payment Request to Settlement

With the layers in place, here's how money actually moves across them. A complete stablecoin receiving flow works like this:

1. The merchant creates a payment request via API.
2. The system generates an HD-derived address — a unique address per receipt.
3. The user transfers stablecoin to that address.
4. The system watches on-chain and waits for 3-6 block confirmations (double-spend protection).
5. KYT risk scoring assesses the risk of the sending address and its path.
6. Once risk clears, the payment is credited.
7. Sweep: the funds scattered across derived addresses are collected into a collection wallet, then allocated to the operating (hot) or reserve (cold) pool by policy.
8. Optional: the funds are automatically converted and settled into fiat or another currency.
9. The merchant is notified via webhook.

Every one of those steps is a security checkpoint in its own right: the confirmation count is the key parameter against double spends, the KYT risk score decides whether to accept the incoming funds at all, and the sweep decides in what risk state those funds enter the main pool.

If you want to look at what a specific on-chain transaction actually did before it's credited or swept, a tool like Phalcon Explorer lets you dive into transaction details directly.

The Sweep Step Is Easy to Get Wrong

This step is easy to overlook but important. Each receipt lands in a separate derived address, and the money doesn't consolidate itself — you have to actively sweep it to a collection wallet. There are two things to get right here.

First, re-screen before sweeping. Even though the incoming funds already passed KYT at credit time, the sweep is the gate where funds enter the main pool, and high-risk funds are hard to isolate once mixed in — so re-confirm before they go in.

Second, gas management. A derived address usually holds only stablecoin and no native token for gas, so the sweep needs a gas station or a fee-sponsorship mechanism to top up gas — or the funds are stuck in the derived address.

The Pay-Out Flow: Why Sending Is Riskier Than Receiving

Sending is riskier than receiving, because funds are irreversible once they leave on-chain. A complete pay-out flow works like this:

1. A batch payout request is submitted.
2. Recipient sanctions screening (KYA).
3. Transaction KYT check.
4. Above a threshold, this triggers multi-person approval.
5. MPC signing (or multisig).
6. The transaction is broadcast on-chain.
7. Status is updated after on-chain confirmation.
8. The requester is notified via webhook.

Key Controls Before Funds Leave

Key controls here include rate limits (per-day and per-transaction caps), whitelisting (payouts only to pre-approved addresses), and multi-person approval (large transactions need several signers to confirm).

The point of these controls isn't any single one of them — it's that together they set up several lines of defense before funds leave, so that even if an insider is compromised or a system is breached, the loss is contained.

Several of these controls, like multi-person approval and MPC signing, are part of the broader practices a payment system needs around its signing environment — we cover those in key management and signing infrastructure.

Putting the Six Layers Together

Line the six layers up — blockchain and stablecoin foundation, wallet and custody, on-ramp/off-ramp, business logic, compliance, and application — and a pattern falls out: each layer has its own responsibility and its own security boundary. The two money flows then cut across all six, which is why a missing checkpoint in either flow shows up as a gap in a specific layer rather than a vague "payment risk." Confusing one layer for another (a custody model for an authorization model, a ramp's on-chain speed for its real end-to-end speed) is where the gaps tend to open up. For a deeper walkthrough of how these boundaries translate into actual controls, download the full enterprise playbook (PDF).

FAQ

What are the six layers of a crypto payment architecture? The blockchain and stablecoin foundation, the wallet and custody layer, the on-ramp/off-ramp layer, the business logic layer, the compliance layer, and the application layer. Each has its own responsibility and security boundary.

What's the difference between self-custody and third-party custody in the custody layer? In self-custody, the keys needed to meet the signing threshold are entirely in your own hands, so no external party can move funds alone — but you carry all the security responsibility. In third-party custody, a licensed custodian holds the keys and you operate through accounts and APIs, trading some control for professional key security, usually with insurance and compliance credentials.

Does MPC signing make a wallet self-custodied? Not by itself. MPC is a technique for splitting a key into distributed shares and removing a single point of failure — it doesn't determine custody. What determines custody is who holds the key shares needed to meet the signing threshold: entirely the company, entirely a custodian, or split between both.

Why can an on-ramp or off-ramp take longer than on-chain settlement? Because the on-chain and fiat legs run on different clocks. On-chain settlement can be minute-level, but the fiat leg is still bound by the operating hours and cutoffs of SWIFT, SEPA, and local clearing, so the real speed of a ramp is set by the slower fiat leg, not the blockchain.

Why is a crypto pay-out flow riskier than a pay-in flow? Because funds are irreversible once they leave on-chain, a pay-out flow runs its checks — KYA sanctions screening, KYT, approval, and signing — before the transaction is broadcast.

Why does the sweep step need re-screening if funds already passed KYT? Because the sweep is the gate where funds move from an isolated derived address into the main pool, and high-risk funds are hard to isolate once they're mixed in — so re-confirming risk before the sweep, not just at credit time, closes that gap.

What happens if a derived address doesn't have gas to complete the sweep? The stablecoin funds get stuck in that derived address, which is why the sweep step needs a gas station or fee-sponsorship mechanism to top up gas before the sweep can execute.