How to accept bank transfers and settle in stablecoins using virtual accounts

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, and what happens on the blockchain at each step is in 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.

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). 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).
2. Link a settlement wallet. Add the blockchain wallet 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:

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.

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 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 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).
• 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). 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 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.

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 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 and create a virtual account have the full requests.

For a non-US business collecting US invoices this way, virtual accounts for B2B receivables covers ACH, wire, and SWIFT collection, reconciliation, and controls.

To add these rails to a checkout you already run, see how to add Pix, SPEI, and PSE to your existing checkout.

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