---
title: "How to accept bank transfers and settle in stablecoins using virtual accounts"
seoTitle: "Accept ACH and wire, settle in USDC: how it works"
description: "Accept ACH, wire, and SWIFT and settle in USDC or USDT: the flow, the token, chain, and custody choices, and when a virtual account beats a memo code."
date: "2026-08-18"
category: "stablecoins"
author: "BlindPay Team"
howto:
  name: "How to accept bank transfers and settle in stablecoins with a virtual account"
  steps:
    - name: "Onboard and verify the customer"
      text: "Create the customer and complete KYC for individuals or KYB for businesses, including the compliance profile fields the banking partner reviews."
    - name: "Link a settlement wallet"
      text: "Add the blockchain wallet where converted stablecoins will land. Its network decides which stablecoins you can settle in."
    - name: "Create the virtual account"
      text: "Request the account with the settlement token and the wallet. It goes through compliance review and bank review before approval."
    - name: "Share the account details"
      text: "Once approved, give the payer the routing and account number, plus SWIFT details for foreign senders."
    - name: "Receive the deposit"
      text: "The payer sends ACH, wire, or SWIFT. Each deposit creates its own payin record and fires a webhook."
    - name: "Settle to the wallet"
      text: "The deposit converts to USDC or USDT and is sent on-chain to the linked wallet. A completion webhook confirms delivery."
faq:
  - q: "How long does settlement take when a virtual account converts to stablecoins?"
    a: "Most of the time is on the bank side. Domestic wires typically settle the same business day and ACH in one to three business days, and BlindPay watches for ACH and wire deposits for up to 5 business days. Once the deposit lands, conversion and the on-chain transfer to the wallet take seconds to minutes depending on the network."
  - q: "Which bank rails can pay into a stablecoin virtual account?"
    a: "It depends on the provider and the account type. BlindPay US virtual accounts receive ACH, domestic wire, and SWIFT, with the exact mix set by the account type. SWIFT deposits from foreign banks require an approved virtual account, since there is no memo-code fallback for international wires."
  - q: "Who holds the funds in a stablecoin virtual account?"
    a: "The fiat lands at the provider's banking partner and is converted by the provider. The stablecoins then go to the wallet linked to the account. At BlindPay that is an external blockchain wallet the customer controls, so once the stablecoins land, the provider no longer holds them. Other providers may settle into a wallet they custody, so ask."
  - q: "What happens if the payer sends the wrong amount?"
    a: "With a virtual account, there is no expected amount. Whatever arrives becomes a payin and converts, from a $0.01 micro-deposit upward, and at least $0.01 of stablecoin always reaches the wallet. Matching that amount against an invoice, and chasing any shortfall, is a job for your own ledger rather than the account."
  - q: "Can the same customer turn stablecoins back into fiat?"
    a: "Yes. The same wallet that receives virtual account settlements can fund payouts to bank accounts. BlindPay pays out over Pix, SPEI, ACH, RTP, SEPA, SWIFT (POBO/COBO), and other local rails to 100+ countries, with a quote that locks the rate and fees before the stablecoins move, and no pre-funding required."
---

To accept bank transfers and settle in stablecoins, give each customer a virtual account: a bank account number in their name that converts every incoming deposit into USDC or USDT and sends it on-chain to a linked wallet. The payer sends an ordinary ACH, wire, or SWIFT transfer. The provider handles the conversion. The customer ends up holding stablecoins.

No checkout page. No crypto on the payer's side.

## Key takeaways

- There are two ways to take a bank transfer and settle in stablecoins: standing virtual account details, or one-time payment instructions with a memo code.
- Virtual accounts win for repeat payers, foreign senders, and anyone who forgets memo codes (everyone).
- The wallet you link decides which stablecoins and chains you can settle in. Pick it before you create the account.
- Most of the settlement time is the bank leg. The on-chain leg takes seconds to minutes.

## How do virtual accounts turn bank deposits into stablecoins?

A virtual account turns bank deposits into stablecoins by pairing a bank account number with a destination wallet. When a deposit lands on the account number, the provider records it, converts the dollars into a stablecoin, and sends the stablecoin to the wallet in an on-chain transaction.

That's the on-ramp, reduced to one object. The deeper walkthrough of approval states and deposit handling is in [stablecoin virtual accounts explained](/resources/more/stablecoin-virtual-accounts-explained), and what happens on the blockchain at each step is in [what happens on-chain in a stablecoin payment](/resources/more/what-happens-on-chain-in-a-stablecoin-payment).

## Virtual account or payment instructions: which one should you use?

Use a virtual account when the same payer sends money more than once or pays from abroad. Use one-time payment instructions when a payer sends a single transfer and you don't want to wait for account approval.

With one-time instructions, you create a quote for a specific payment, then show the payer a shared bank account plus a memo code they must include so the deposit can be matched. With a virtual account, the payer gets bank details in your customer's own name, and the account number does the matching.

| | Virtual account | One-time payment instructions |
| --- | --- | --- |
| What the payer gets | Routing and account number in your customer's name | Shared bank details plus a memo code |
| Reusable | Yes, same details every time | No, one set per payment |
| How a deposit is matched | By the receiving account number | By the memo code the payer types |
| Setup | Account review before first use | Available immediately |
| International SWIFT | Yes, on account types that support it | Not at BlindPay: SWIFT deposits require a virtual account |
| Failure mode | Account rejected or approval delayed | Memo missing or mistyped, deposit waits to be matched |
| Best for | Recurring payers, payroll funding, B2B, foreign clients | Occasional one-off deposits |

At BlindPay, the two paths are connected. Once a customer has an approved virtual account, ACH and wire payins show that account's own details and the memo code is ignored ([payins](/docs/payins)). RTP deposits are the exception: they always use the shared memo-code account, because no virtual account carries an RTP rail.

## What does the end-to-end flow look like?

The flow has six steps, and only the last two involve money.

1. **Onboard and verify the customer.** KYC for individuals, KYB for businesses. At BlindPay, the customer's `kyc_status` must be `approved` before you can request an account, and business customers need fields like `account_purpose`, `source_of_wealth`, `business_industry` (a NAICS code), and at least one owner filled in ([create a virtual account](/docs/virtual-accounts-create)).
2. **Link a settlement wallet.** Add the [blockchain wallet](/docs/blockchain-wallets) where the stablecoins will land. It must belong to the same customer.
3. **Create the virtual account.** One API call, with the settlement token and the wallet:

```bash
curl --request POST \
  --url https://api.blindpay.com/v1/instances/in_000000000000/customers/re_000000000000/virtual-accounts \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "banking_partner": "cfsb",
  "token": "USDC",
  "blockchain_wallet_id": "bw_000000000000"
}'
```

4. **Wait for approval.** Production accounts move from `pending_review` (compliance) to `verifying` (bank) to `approved`, and `virtualAccount.complete` fires with the routing and account numbers. Development accounts are approved instantly.
5. **Receive the deposit.** The payer sends ACH, wire, or SWIFT. Each deposit creates a payin and fires `payin.new`.
6. **Settle to the wallet.** The deposit converts and the stablecoins go on-chain to the linked wallet. The payin reaches `completed` and `payin.complete` fires.

After step 4, nothing else needs an API call. Every future deposit repeats steps 5 and 6 on its own.

## Which design decisions do you need to make?

Six decisions shape a stablecoin collection flow. Most depend on the provider, so the table shows what to ask any provider next to how BlindPay answers.

| Decision | What to ask any provider | BlindPay |
| --- | --- | --- |
| Custody | Do stablecoins settle to a wallet I control, or one you hold? | Virtual accounts settle to an external blockchain wallet the customer controls |
| Which stablecoin | USDC, USDT, or both? Can I switch later? | USDC or USDT, and `token` can be updated on an existing account |
| Which chain | Which networks can receive settlement? | USDC on Ethereum, Polygon, Base, Arbitrum, Stellar, and Solana. USDT needs a wallet on Polygon, Ethereum, or Solana |
| Fees | Monthly cost per account? Per-deposit fee? Where does it show up? | $1.50 per month per account. Per-deposit fees below $100.00 go to your invoice; at $100.00 or more they're deducted from the delivered stablecoin |
| Minimum deposit | Are small deposits ignored or processed? | Every deposit is processed, including $0.01 micro-deposits, and at least $0.01 is always delivered |
| Settlement time | How long for each rail, and what restarts the clock? | ACH and wire deposits can take up to 5 business days to arrive; the on-chain leg takes seconds to minutes |

Two of these are worth a second look.

**Custody.** Settling to a wallet your customer controls means the stablecoins stop being the provider's liability the moment they land. It also means your customer is responsible for that wallet's keys. [Non-custodial payments explained](/resources/more/non-custodial-payments-explained) covers the trade-off in full.

**Token and chain.** They're linked. At BlindPay, choosing USDT means the wallet must be on Polygon, Ethereum, or Solana. Stellar wallets receive USDC only, and need a USDC trustline before they can. If you're unsure which token, [USDC vs USDT for payments](/resources/more/usdc-vs-usdt-for-payments) compares them. For speed and low network fees, Solana is a common pick: BlindPay payins, payouts, and virtual accounts all run on it.

## What does compliance look like?

Compliance happens at three points: when the customer is onboarded, when the account is approved, and when each deposit arrives.

- **Customer onboarding.** KYC or KYB, plus sanctions screening. The provider has to know who the account belongs to.
- **Account approval.** Banks want to know what the account is for. At BlindPay that means the purpose of the account, source of funds, and source of wealth, backed by documents like recent bank statements or financial statements ([virtual account requirements](/docs/kb/virtual-accounts)).
- **Each deposit.** A deposit can be held for review. At BlindPay, a payin in review shows `on_hold` and resumes when cleared.

Two rules apply beyond the first deposit. First, the money has to belong to the customer the account was issued to. Collecting for your customer's own clients through their account is nesting, which BlindPay does not allow ([nested payments](/docs/kb/nested-payments)). Second, when stablecoins move between providers, travel rule obligations can require originator and beneficiary information to travel with the transfer. How that applies depends on the jurisdiction and the wallets involved, so ask your provider how they handle it. The [stablecoin regulation tracker](/resources/more/stablecoin-regulation-tracker-2026) follows the rules by market.

## What does this look like for a payroll platform?

**Illustrative example.** A contractor payroll platform has three US client companies. Each client is onboarded as a BlindPay customer, passes KYB, and gets its own virtual account settling USDC to its own wallet on Solana.

| Client | Funds payroll by | Deposit | What lands |
| --- | --- | --- | --- |
| Client A | Domestic wire, Monday morning | $48,000.00 | USDC in Client A's wallet, minus the deposit fee |
| Client B | ACH, twice a month | $12,500.00 each | USDC in Client B's wallet after each ACH settles |
| Client C | ACH from a payroll provider that verifies with a $0.01 test | $0.01, then $9,000.00 | Two payins: at least $0.01 of USDC, then the full deposit minus fees |

Nobody types a memo code. Every deposit arrives already labeled by the account it hit. The platform then pays each client's contractors from that client's wallet, over local rails in each contractor's country. (Amounts are illustrative; fees depend on your plan.)

Notice Client C's penny. That's an account-verification micro-deposit, and it shows up as its own payin. Reconcile it, don't flag it.

## Where does BlindPay fit?

[BlindPay virtual accounts](/virtual-accounts) give each customer a US bank account in their own name that receives ACH, wire, and SWIFT and settles automatically to USDC or USDT in the customer's wallet. The same API pays out over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) to 100+ countries, with live quotes, no pre-funding, and KYC, KYB, and sanctions screening built into the flow.

## What to do next

Create a free development instance, add a Solana Devnet wallet, and create one virtual account with `token: "USDB"`, BlindPay's test stablecoin (production accounts use USDC or USDT). It's approved instantly, and every test payin completes about 30 seconds after you create it, so you can wire up `payin.new` and `payin.complete` handling before your first real customer applies. The [payin quickstart](/docs/quickstart-payin) and [create a virtual account](/docs/virtual-accounts-create) have the full requests.

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