---
title: "What happens on-chain in a stablecoin payment? A step-by-step walkthrough"
seoTitle: "How stablecoin payments work on-chain, step by step"
description: "A stablecoin payment in five steps: bank deposit, conversion to USDC or USDT, on-chain delivery to a wallet, payout authorization, and local currency out."
date: "2026-08-13"
category: "stablecoins"
author: "BlindPay Team"
howto:
  name: "How a stablecoin payment moves from a bank deposit to a local payout"
  steps:
    - name: "A bank transfer lands in a virtual account"
      text: "The payer sends an ACH, wire, or RTP transfer to a bank account issued in the customer's name. Each deposit creates its own payin record."
    - name: "The deposit converts into USDC or USDT"
      text: "Once the deposit clears, the provider converts the dollars into a stablecoin at the rate locked in the quote."
    - name: "Stablecoins settle to the linked wallet"
      text: "One on-chain transfer delivers the stablecoins to the wallet linked to the virtual account. The transaction hash is the public receipt."
    - name: "The wallet authorizes a payout"
      text: "For a payout, a quote locks the rate and fees, and the wallet authorizes the exact amount. Managed wallets need no signature."
    - name: "Stablecoins convert back and pay out locally"
      text: "The provider pulls the authorized amount, converts it to local currency, and sends it over a rail like Pix or SPEI."
faq:
  - q: "How do stablecoin payments work?"
    a: "In four moves. A bank transfer arrives in a virtual account, it is converted into USDC or USDT, the stablecoins settle on-chain to the customer's linked wallet, and for a payout they are converted back to local currency and sent over a local rail like Pix or SPEI. The blockchain only handles the middle: short on-chain transfers that confirm in seconds to minutes and leave a public receipt."
  - q: "What happens if a stablecoin payment fails partway through?"
    a: "It depends on the step. If the deposit never arrives, the payin fails and nothing moves on-chain. If a payout quote expires before execution, request a new one; no funds moved. If the receiving bank rejects or returns a payout, BlindPay marks it refunded and sends the stablecoins back to the wallet that authorized it. A payout that ends failed, for example after a rejected compliance check, does not refund automatically and needs a follow-up with support."
  - q: "Which stablecoins are supported?"
    a: "USDC and USDT. At BlindPay, Ethereum, Polygon, and Solana support both. Base, Arbitrum, and Stellar support USDC, and Tron supports USDT only."
  - q: "Do I need to hold cryptocurrency myself?"
    a: "No. A business can receive bank transfers into virtual accounts and pay out to bank accounts without ever opening a wallet app or choosing a chain. The stablecoins settle in a linked wallet behind the scenes. Teams that do want to hold their own stablecoins can link an external wallet they control."
  - q: "How long does the on-chain part of a stablecoin payment take?"
    a: "Seconds to a few minutes, depending on the network. Stellar closes a ledger about every five seconds, and Solana finalizes in about 13 seconds. Ethereum takes around 13 minutes to reach full finality. The bank legs at each end almost always take longer than the blockchain does."
---

A stablecoin payment works in four moves. A bank transfer lands in a virtual account, it's converted into USDC or USDT, the stablecoins settle on-chain to the customer's linked wallet, and for a payout they're converted back into local currency and sent over a rail like Pix or SPEI. The blockchain handles only the middle: a couple of short transactions, each confirmed in seconds to minutes, each with a public receipt.

The end-to-end version, with bank cut-offs and payout timing, is in [how a stablecoin payment works](/resources/more/how-a-stablecoin-payment-works). This walkthrough zooms in on the part most explainers skip: what the blockchain is actually doing at each step, and what an operations team can see while it happens.

No code required. If you can read a bank statement, you can follow this.

## What does the whole flow look like?

Picture a line of five boxes, left to right. The first and last are bank accounts. The three in the middle are the payment provider's conversion step, the customer's wallet, and the provider's conversion step again. Money enters on the left as dollars, becomes a stablecoin for the middle stretch, and leaves on the right as local currency. Only two arrows in the whole picture are on-chain: the delivery into the wallet, and the pull out of it.

```
[Payer's bank]
     |  1. ACH, wire, or RTP deposit            (bank rail)
     v
[Virtual account in the customer's name]
     |  2. dollars convert to USDC or USDT      (provider)
     v
[Customer's linked wallet]  <-- 3. on-chain delivery, tx hash #1
     |
     |  4. wallet authorizes the payout amount
     |     and the stablecoins are pulled        on-chain, tx hash #2
     v
[Provider's off-ramp]
     |  5. stablecoins convert to local currency (provider)
     v
[Recipient's bank, paid over Pix or SPEI]       (bank rail)
```

## Step 1: A bank transfer lands in a virtual account

A virtual account is a real bank account number, routing and account, issued in your customer's name. Anyone can pay it like any other account. At BlindPay, each virtual account belongs to one customer and settles to one linked wallet, and a customer can hold more than one ([virtual accounts](/docs/virtual-accounts)).

Why that matters for reconciliation: every deposit into the account creates its own payin record. You match money to customers by account, not by hoping the payer typed a reference code correctly. Without a virtual account, a US payin returns BlindPay's bank details plus a `memo_code` the payer has to include.

**On-chain so far:** nothing. This step is pure banking. ACH and wire deposits can take up to five business days to arrive; RTP arrives in seconds.

The approval flow and fees are covered in [stablecoin virtual accounts explained](/resources/more/stablecoin-virtual-accounts-explained).

## Step 2: The deposit converts into USDC or USDT

Once the deposit clears, the provider converts the dollars into a stablecoin at the rate locked in the quote. USDC is issued by Circle and USDT by Tether; both are designed to be redeemable one-for-one for US dollars through their issuers.

New tokens come from one of two places. Either the issuer mints them against fresh dollars, or the provider sends tokens it already holds. BlindPay's docs describe exactly that: once the deposit is confirmed, BlindPay mints or transfers the equivalent stablecoin amount to the destination wallet ([overview](/docs/overview)).

**On-chain so far:** possibly a mint on the issuer's side. Your customer doesn't see it and doesn't need to.

## Step 3: Stablecoins settle to the linked wallet

This is the first on-chain moment your team can actually look at. One transfer moves the stablecoins from the provider to the wallet linked to the virtual account.

A transfer "confirms" when a block containing it is added to the chain. It's final when the network guarantees that block can't be undone. How long that takes depends on the network:

| Network | New block roughly every | Practical finality |
| --- | --- | --- |
| Stellar | 5 seconds | At ledger close, about 5 seconds |
| Solana | 0.4 seconds | About 13 seconds |
| Tron | 3 seconds | About a minute |
| Polygon | 2 seconds | Seconds |
| Base, Arbitrum | 2 seconds or less | Seconds for the sequencer, minutes to settle on Ethereum |
| Ethereum | 12 seconds | About 13 minutes |

Every confirmed transfer has a **transaction hash**, a unique ID anyone can paste into a block explorer to see the amount, the sending and receiving addresses, and the time. It's a receipt no one can edit.

**What BlindPay shows you:** the payin fires `payin.complete` once the stablecoins land, and the hash appears in the payin's `tracking_complete` object. One gotcha from the [payins docs](/docs/payins): during a gas spike, a broadcast transaction can be replaced by another one, so the final hash may differ from the first one you saw. Treat the payin `status` as the source of truth, not a specific hash.

The wallet itself comes in two kinds. An external wallet is controlled by your customer. A managed wallet is custodied by BlindPay (in beta). Why that choice matters for risk is in [non-custodial payments](/resources/more/non-custodial-payments-explained).

## Step 4: The wallet authorizes the payout

Paying someone starts with a quote: the rate, the fee, and exactly how much local currency arrives. At BlindPay a payout quote lasts five minutes ([payout quotes](/docs/payout-quotes)). How to read one is in [stablecoin API quotes explained](/resources/more/stablecoin-api-quotes-explained).

Then the wallet has to let the stablecoins go. How depends on the wallet:

- **Managed wallet:** nothing to sign. BlindPay moves the funds.
- **External wallet on an EVM chain** (Ethereum, Base, Polygon, Arbitrum): the wallet signs an ERC-20 `approve` for the exact quoted amount.
- **External wallet on Stellar:** a signed XDR transaction.
- **External wallet on Solana:** a token delegation, prepared, signed, and submitted.

After authorization, BlindPay pulls exactly that amount. Not a cent more.

**On-chain:** the approval (on EVM chains) and the transfer out of the wallet. If an external wallet signs the approval, that wallet pays the network fee for it in the chain's native token.

## Step 5: Stablecoins convert back and pay out locally

The off-ramp converts the stablecoins into local currency and sends them over the recipient's rail. Pix in Brazil, SPEI in Mexico, Transfers in Argentina, and RTP in the US are instant. Wire and SEPA take about one business day, ACH about two, and SWIFT (POBO/COBO) about five ([settlement times by rail](/resources/more/stablecoin-payout-settlement-times)).

**On-chain:** done. From here it's banking again, and `payout.complete` fires when the recipient's bank confirms.

That's the whole trip. On-chain time is usually minutes. The bank legs are what take hours or days.

## What happens if a payment fails partway through?

Failures cluster at the bank edges, not on-chain. Here's the map:

| Where it stops | What happened on-chain | What you see at BlindPay |
| --- | --- | --- |
| Deposit never arrives | Nothing | The payin fails. Pix and SPEI payins wait up to 30 minutes first |
| Quote expires before execution | Nothing | Request a new quote |
| Delivery transaction replaced in a gas spike | The replacement lands | Resolved automatically; the hash may change |
| Held for compliance review | For US payouts, the stablecoins are usually already collected | `on_hold` until review clears. An unanswered request for information can lead to a refund to the sender |
| Receiving bank rejects or returns the payout | A refund transfer back to the wallet | `refunded`: stablecoins return to the wallet that authorized them |
| Payout rejected in compliance review | The stablecoins may already be collected | `failed`, no automatic refund; contact support |

A confirmed on-chain transfer can't be reversed by anyone. That's why the destination and amount are locked in the quote before anything moves.

## What does this mean for a business that never wants to touch a wallet?

It means it doesn't have to. Everything above can run behind a bank-shaped API. In [BlindPay](/global-payments)'s Abstracted flavor, you issue virtual accounts, receive payins, and send payouts to bank accounts. The stablecoins settle in the linked wallet in the background, and no one on your team picks a chain, holds a key, or signs a transaction.

Teams that want the chain-level controls from steps 3 and 4 use the Advanced flavor of the same API. Same keys, same webhooks.

## What to do next

Watch one payment cross the chain yourself. Create a free development instance, where payins auto-complete about 30 seconds after you create them and settle in a test token called USDB. Then open the transaction hash from `tracking_complete` in a testnet block explorer. The [payin quickstart](/docs/quickstart-payin) walks through it step by step.

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