How does a stablecoin payment move? From bank deposit to local payout, step by step

A stablecoin payment moves money in three legs. Fiat is collected from the payer, the value settles on a blockchain as a dollar stablecoin like USDC or USDT, and an off-ramp converts it back into local currency and pays the recipient's bank account. A stablecoin API runs all three from one integration, so neither side has to touch crypto.

That's the short version. The longer version matters because each leg has its own timing, its own failure modes, and its own definition of "done." If your product shows "paid" at the wrong moment, support tickets follow.

What does a stablecoin payment actually move through?

Four building blocks show up in almost every provider's API. The names vary. The jobs don't.

An on-chain transfer between two wallets is a fifth piece, but in a bank-to-bank flow it's plumbing. The payer sends dollars. The supplier receives reais. The stablecoin sits in the middle for minutes.

What happens from onboarding to payout? A worked example

Take a US company paying a supplier in Brazil. Each step below is labeled: generic means the pattern holds across stablecoin APIs, BlindPay means it's how our API documents it.

Step 0: onboarding (generic, and BlindPay). Before money moves, the sender is verified. Individuals go through KYC, companies through KYB, and both get screened against sanctions lists. In BlindPay's API every payment flows through a customer that has completed KYC. BlindPay runs the verification; you collect the data. Standard KYC takes about 60 seconds, and KYB takes 3 hours to 1 business day because a person reviews it (onboarding SLAs).

Step 1: collect fiat (generic). The US company sends dollars by ACH or wire. Two ways to tell the payer where to send: a one-time instruction (a shared account plus a reference code) or a dedicated account number in the customer's name. BlindPay: without a virtual account, an ACH or wire payin returns a memo_code plus BlindPay's bank details. With one, the payer sees the customer's own routing and account number.

Step 2: convert to stablecoin (generic). When the deposit clears, the provider converts dollars to USDC or USDT and delivers them to a wallet. BlindPay: the payin fires payin.complete once stablecoins land in the destination wallet, either a managed wallet BlindPay custodies or an external wallet the customer controls (payins).

Step 3: quote the payout (generic). Before paying the supplier, you request a quote: the rate, the fee, and exactly how many reais arrive. BlindPay: a payout quote is created against the recipient's bank account and expires after 5 minutes. Amounts are integers in minor units, so 10000 is $100.00 (payout quotes).

Step 4: move the stablecoin (generic). The stablecoins leave the wallet. If the provider custodies the wallet, it moves them. If the customer holds the keys, they authorize the pull on-chain first. BlindPay: a managed wallet needs no signing. An external EVM wallet signs an ERC-20 approve for the quoted amount; Stellar and Solana have their own authorization steps (payouts).

Step 5 and 6: convert and pay out (generic). The off-ramp converts USDC to BRL and sends it over Pix. BlindPay: one call to create the payout against the quote. Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) are live payout rails, and none of them needs you to pre-fund a local account.

Step 7: confirm (generic). The provider reports status changes asynchronously. BlindPay: payout.new, payout.update, and payout.complete webhooks, signed, one endpoint per instance.

What's the difference between settlement and the recipient getting paid?

This is where most payment UIs get it wrong.

The on-chain leg settles in seconds to a few minutes, and a confirmed transfer is final. But the supplier hasn't been paid yet. They've been paid when reais land in their account, and that depends on the payout rail:

These are BlindPay's published estimates from the bank accounts reference. Rails with cut-offs (ACH, wire, SWIFT) slip to the next business day when a request arrives late, and compliance review can add time on top. So: show "sent" when the stablecoin leg confirms, show "paid" when the payout completes. Two different states. Two different events. Every rail's cut-off and settlement window is in the cut-off times reference.

Where can delays and reversals happen?

At the edges, not in the middle.

• Fiat collection. ACH and wire deposits can take up to 5 business days to arrive. Instant rails like Pix and SPEI arrive in minutes.
• Compliance review. A payin or payout can land on_hold for manual review. In BlindPay's API all USD ACH, wire, RTP, and SWIFT payouts pass through on_hold as a standard step, and SWIFT payouts to third parties wait for supporting documents. A hold can take up to 30 days to resolve.
• The receiving bank. Wrong details, a closed account, or a rejection stops the payout. At BlindPay it ends failed or refunded. A refund returns the stablecoins to the funding source instead of converting them. A failed payout does not refund automatically, so it needs a follow-up with support.
• The on-chain leg. Rarely the problem. Once confirmed, it's final. That also means a mistaken transfer to the wrong wallet cannot be pulled back, which is why quotes and destinations are locked before anything moves.

Stablecoin refunds process right away. Fiat refunds wait for the banking network to return the money, which depends on that bank's processing time.

When is a stablecoin API useful, and when are bank rails enough?

Stablecoin settlement pays off when money crosses a border or a currency. That's where correspondent banks add days, stack fees at each hop, and make you park capital in local accounts before you can pay anyone. A stablecoin in the middle replaces that chain with one on-chain hop and two local rails. It's also the reason a provider can pay out without pre-funding: the value arrives as stablecoin and leaves as local currency at quote time.

It's overkill when both sides share a country and a fast domestic rail. A Brazilian company paying a Brazilian supplier should use Pix. A US payroll run to US bank accounts should use ACH or RTP. No stablecoin needed.

There's a middle case worth naming: platforms that hold customer balances in dollars across several countries. There, the wallet leg isn't plumbing at all. It's the product. That's a different job from a payout API, and the line between the two is covered in stablecoin API vs crypto payment gateway and is Stripe a stablecoin API.

Glossary: six terms you'll see in every stablecoin API

• Payin. Money coming in: fiat from a payer, delivered as stablecoin to a wallet. Also called an on-ramp.
• Payout. Money going out: stablecoin pulled from a wallet, delivered as fiat to a bank account. Also called an off-ramp.
• Quote. A short-lived price lock covering rate, fees, and amounts. Execute before it expires or request a new one.
• Funding source. The wallet a payout pulls stablecoins from. Custodial (the provider holds the keys) or external (the customer does).
• Minor units. Amounts as integers in the smallest currency unit. 500000 is 5,000.00, never 500,000.00.
• Webhook. A signed HTTP callback the provider sends when a payment changes state, so you don't have to poll.

Where does BlindPay fit?

BlindPay is a stablecoin API for cross-border payouts and collections: USDC or USDT in, local currency out over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) to 100+ countries, with no pre-funding. KYC, KYB, and sanctions screening run inside the API. Virtual USD accounts give each customer a dedicated account number whose deposits settle to stablecoins automatically.

What to do next

Trace one payment end to end before you design a single screen. Create a free development instance, run a payin, then a payout, and watch every webhook arrive. The payout quickstart walks the whole flow, and the introduction explains the quote, authorize, execute pattern every endpoint follows.

This article is for general information only and is not legal, tax, or financial advice.