Crypto-to-fiat payments: how the money actually moves

"Send crypto, receive local money" sounds like a single action. It never is. Behind that sentence sits a sequence of separate transfers, each one owned by a different party, priced differently, and able to fail on its own. If you are designing or evaluating a crypto-to-fiat product, the first useful thing you can do is stop treating it as one payment and start treating it as a route.

The four legs of a crypto-to-fiat payment

Almost every crypto-to-fiat flow in production today decomposes into the same four legs, regardless of the chain or the currencies involved.

1. 1Collection — the sender moves a crypto asset from a wallet they control into an address associated with the payment. On-chain, this is the only leg the sender can see and verify directly.
2. 2Conversion — the received asset is exchanged for a settlement asset, usually a dollar-denominated stablecoin. This is where market price, slippage and routing quality live.
3. 3Settlement — the settlement asset is delivered to a regulated institution that can hold value and initiate a fiat payment. This is the handover from blockchain to banking.
4. 4Payout — that institution pushes local currency into the recipient's bank account, mobile money wallet or cash pickup point, over domestic payment rails such as SEPA, ACH, Faster Payments, UPI or a local mobile money scheme.

The interesting design consequence: legs 1 and 2 are deterministic and verifiable by anyone with a block explorer. Legs 3 and 4 are not. They are private, batched, subject to banking hours, and gated by identity checks. Any product that promises one uniform experience across all four is hiding that seam — and the seam is exactly where user trust is won or lost.

Why the conversion leg needs its own attention

A user sending SOL, ETH or any volatile asset is exposed to price movement between the moment they see a quote and the moment the asset is actually converted. Seconds matter. Three mechanisms are commonly used to manage that exposure:

• Quote expiry — the quote is valid for a short window (often 10 to 60 seconds) and must be refreshed if the user hesitates.
• Slippage tolerance — the conversion is allowed to execute within a defined band of the quoted price, and reverts rather than filling at a materially worse rate.
• Stablecoin-first collection — the sender pays directly in a stablecoin, removing the volatile leg entirely at the cost of requiring the sender to already hold it.

None of those mechanisms eliminates market risk; they allocate it. Somebody absorbs the difference between quoted and executed price — the sender, the platform, or a liquidity provider. Being explicit about who absorbs it is a product decision, not an implementation detail.

The handover problem: on-chain finality is not payment finality

When a Solana transaction is finalized, the transfer is irreversible and publicly provable. It is tempting to treat that as "payment complete". It is not. The recipient has been paid only when local currency is available in their account, which depends on a bank's own clearing cycle and on the payout institution's risk checks.

This creates a state that most traditional payment systems never have: funds that are definitively received on one side and definitively not yet delivered on the other, with a public record of the first fact. Product teams need explicit states for this, not a single "processing" spinner. At minimum:

• Awaiting deposit — the payment has been created, nothing has arrived on-chain yet.
• Deposit confirmed — the on-chain transfer is finalized and verifiable by transaction signature.
• Converted — the asset has been exchanged for the settlement stablecoin at a recorded rate.
• Settled to partner — the stablecoin has reached the regulated institution handling payout.
• Payout initiated — a fiat payment instruction has been submitted to a domestic rail.
• Paid out — the recipient's account has been credited, per the partner's confirmation.
• Returned or failed — with a reason the sender can act on.

Who is allowed to do what

The legs differ not just technically but legally. Converting one crypto asset into another via a public protocol, with the output returning to the user's own wallet, is a different activity from holding customer funds or paying a third-party recipient in fiat. The latter is regulated money transmission in most jurisdictions and requires licensing, KYC/AML programmes, sanctions screening and transaction monitoring.

That is why serious crypto-to-fiat products are structured as orchestration layers: the platform routes, quotes, tracks and reports, while licensed institutions hold funds, verify identity and execute fiat payouts. The split is not a workaround. It is the only structure that lets a software team move quickly on routing and user experience without taking on obligations it is not authorised to carry.

What an orchestration layer should own

• Quoting and route selection across conversion venues.
• On-chain verification of received deposits.
• State machine, idempotency and reconciliation across all four legs.
• Transparent fee presentation before the user commits.
• Status, receipts and audit records for every transfer.

What a licensed partner should own

• Custody of customer funds.
• Identity verification, sanctions screening and ongoing monitoring.
• Fiat account infrastructure and access to domestic payment rails.
• Regulatory reporting in each market served.

Fees: four legs, four costs

Users compare crypto-to-fiat services on a single number — how much local currency lands. Getting to that number honestly means naming each cost:

• Network fee — paid to the blockchain to include the deposit transaction. On Solana this is small and predictable; on other chains it can dominate small transfers.
• Conversion spread — the difference between the mid-market rate and the executed rate, including routing inefficiency and slippage.
• Platform fee — the orchestrator's own charge for routing, tracking and support.
• Payout fee and FX margin — charged by the institution delivering local currency, often with a separate margin on the fiat exchange rate.

A quote that shows only "total fee" invites distrust, because users eventually compare the landed amount to a public mid-market rate and find the gap. Itemising the four costs, and showing the FX rate used, is both more honest and easier to defend.

What this means for anyone building today

If you are building in this space, sequence your work along the legs rather than across the whole promise. Get collection and on-chain verification genuinely correct first, because they are the parts you can prove. Build the state machine and reconciliation next, because they are what makes the later legs operable. Integrate a regulated payout institution last, with the labelling honest at every stage about what is live and what is simulated.

LamportPay is built on exactly that sequence. The wallet connection and the SOL-to-USDC conversion leg run against live Solana infrastructure, with output returning to the user's own connected wallet and strict limits on amount. The settlement, identity and fiat payout legs are demonstrated as a simulation, because they require a regulated payout infrastructure partner that is not yet in place. The demo shows the whole route so the architecture can be evaluated; the labels tell you which part is real.