Virtual accounts for stablecoin payins: what they are and how to use them

A virtual account is a dedicated deposit account number for one customer. When a bank transfer arrives, the provider matches it to that customer, converts it to a stablecoin such as USDC or USDT, and delivers it to the customer's linked wallet. BlindPay issues virtual accounts through its API.

Key takeaways

• A virtual account is a real account number tied to one customer, so deposits identify themselves.
• BlindPay's US accounts accept ACH, wire, and SWIFT. Colombia uses Bre-B and Mexico uses SPEI.
• Approval has two stages in production, a compliance review and a bank review. Do not promise a payer a go-live time.
• Each deposit creates a payin, which gives you a record to reconcile.
• Use a virtual account for repeat payers. Use one-time instructions for a single payment.

For the wider picture of payins, start with what a stablecoin payin API is.

What is a virtual account?

A virtual account is a bank account number issued in your customer's name that points to your provider's banking setup. Anyone can send money to it like to any other account. In BlindPay's case, the customer gets their own routing and account number for US accounts.

For a plain-English intro, see what a virtual account is. The account number is the integration. You do not build a checkout flow or show payment instructions for each deposit.

How do virtual accounts work for stablecoin payins?

You create the account once, give the details to the payer, and the provider converts each deposit. The steps:

1. Onboard the customer. Their kyc_status must be approved (or approved_rfi) before you can request an account.
2. Link a blockchain wallet as the settlement destination.
3. Create the virtual account. It starts in pending_review.
4. After compliance and bank review, the status becomes approved and the virtualAccount.complete webhook fires.
5. The payer sends a transfer. BlindPay creates a payin, converts the deposit, and sends the stablecoin to the linked wallet.

A virtual account belongs to one customer and settles to one wallet. See Create a virtual account for required fields.

What account types does BlindPay offer?

The table below summarizes the types in the BlindPay docs.

The SLA column is the issuance SLA, not how fast a deposit arrives.

Virtual account vs deposit address vs one-time payment instructions?

Pick the collection method by payer behavior. A virtual account suits repeat payers. A deposit address suits payers who already hold stablecoins. One-time instructions suit a single invoice or checkout.

At BlindPay, a payin quote returns one-time instructions. For ACH and wire, the memo code is shown only when the customer has no enabled virtual account. With one, BlindPay shows the dedicated account details instead. The one-time vs virtual account guide goes deeper.

Should I use one virtual account per customer or per brand?

Use one per onboarded customer. The model is one customer, one account. That keeps the owner of each deposit visible to the provider and to you.

A customer can hold more than one account in some cases. On BlindPay's jpmorgan banking partner, a customer can hold several accounts at once. For other banking partners, a customer cannot have two non-deleted, non-rejected accounts on the same partner. Read the virtual accounts docs before you design the layout.

How do virtual accounts help reconciliation?

Because each account belongs to one customer, a deposit tells you whose money it is without a reference code. Each deposit also becomes a payin with amounts, fees, status, and a transaction hash.

A practical reconciliation loop:

1. Receive payin.new and payin.update, and dedupe by webhook message ID.
2. Store the payin ID and the customer ID against your ledger entry.
3. Mark the entry final only on a completed status. Read the status field, not the event name.
4. Run a daily job that lists payins and compares totals with your ledger.

For wire deposits, the payin can carry sender details such as sender_name and transaction_reference. See how virtual accounts automate reconciliation for a worked example.

What are the limits and eligibility rules?

Eligibility depends on the customer, the account type, and the banking partner. Do not assume every customer qualifies.

• KYC or KYB first. The customer must be approved before you request an account.
• Business fields. Businesses need fields such as account purpose, business type, NAICS industry code, and registered owners. See virtual account requirements.
• Two review stages. Compliance review moves an account from pending_review to verifying, then the bank decides. Either stage can reject.
• Colombia (Bre-B). Only customers with a Colombian ID card or NIT qualify. Each deposit is limited to about COP 12,000,000, depending on the payer's bank. Bre-B deposits cannot be reversed.
• Mexico (SPEI CLABE). Available for customers of any country. One CLABE per customer.
• Fees on small deposits. Every deposit is processed and delivers at least $0.01 of stablecoin.
• Development behavior. On a development instance, accounts skip review and are created as approved. The routing number is always 110000000 and the account number is fake.

BlindPay's virtual account knowledge base lists the documents the evaluation asks for.

How do I evaluate providers?

Check the same items for every provider and write down what the provider's own documentation says, not what a sales deck says. Use this list:

1. Which account types and payer countries are live today?
2. Does the account carry the customer's name, or a pooled name?
3. How long does issuance take, and what can cause rejection?
4. Which rails does each account support, including international?
5. Where do stablecoins go, and can the customer control that wallet?
6. How are deposit fees charged, and how are small deposits handled?
7. What webhooks cover account approval and each deposit?
8. Can you test in a sandbox without real bank numbers?

Use the 12-point virtual account provider checklist and test first with this sandbox guide.

Where does BlindPay fit?

BlindPay offers virtual accounts that convert deposits to stablecoins and deliver them to a linked wallet. These facts come from the BlindPay docs.

• US accounts support ACH, wire, and SWIFT, and are issued in the customer's name. Named payouts originate under the end user's name.
• Colombia (Bre-B) and Mexico (SPEI CLABE) accounts are not named accounts. Payers see a pooled recipient name, but each key or CLABE is unique to one customer.
• Production accounts get real, bank-issued routing and account numbers.
• US accounts cost $1.50 per month per account. Deposit fees depend on the deposit amount and show on the payin as billing_fee_amount or transaction_fee_amount.
• Webhooks: virtualAccount.new, virtualAccount.complete, and the payin.* events.

See the virtual accounts product page, pricing, and the integrate-virtual-accounts prompt for an AI-assisted build.

Sources

• BlindPay docs, Virtual accounts, Create a virtual account, and Virtual account documents
• BlindPay docs, Webhook events
• Nacha, ACH network rules
• Federal Reserve Financial Services, Fedwire Funds Service
• Banco Central do Brasil, Pix
• Banco de Mexico, SPEI

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