---
title: "Virtual accounts for B2B receivables: how to collect US invoices as USDC or USDT"
seoTitle: "Virtual accounts for B2B receivables in USDC or USDT"
description: "How a non-US business collects US invoices by ACH, wire, or SWIFT into a virtual account and receives USDC or USDT, with reconciliation and controls."
date: "2026-10-12"
updated: "2026-10-12"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to collect US invoices as stablecoins with a virtual account"
  steps:
    - name: "Complete KYB and the virtual account review"
      text: "Your business passes KYB, then provides the virtual account profile: industry, entity type, nature of business, account purpose, source of funds, and source of wealth, with supporting documents such as financial statements or recent bank statements."
    - name: "Link the settlement wallet and choose the token"
      text: "Register a blockchain wallet you control and request the virtual account with USDC or USDT as the settlement token. USDT settlement requires the wallet to be on Polygon, Ethereum, or Solana."
    - name: "Wait for approval and the account details"
      text: "The account moves from pending_review to verifying to approved. The virtualAccount.complete webhook fires when the bank approves it and the routing and account numbers are issued."
    - name: "Put the account details on every invoice"
      text: "Print the routing number, account number, and beneficiary name on invoices and in your billing portal, and ask payers to include the invoice number in the payment reference."
    - name: "Reconcile each deposit as a payin"
      text: "Each deposit creates a payin. Listen for payin.new and payin.complete webhooks, match each payin to an open invoice by amount, date, and reference, and mark the invoice paid."
faq:
  - q: "Can a non-US company collect invoice payments from US customers in stablecoins?"
    a: "Yes. A US virtual account gives your business its own routing and account number. Your US customers pay the invoice by ACH or wire like any vendor payment, and each deposit is converted to USDC or USDT and delivered to the wallet you linked. The payer never touches crypto, and you receive stablecoins instead of waiting for a cross-border wire to your home bank."
  - q: "Do my customers need a crypto wallet to pay into a virtual account?"
    a: "No. The payer sees ordinary US bank details: a beneficiary name, a routing number, and an account number. They pay from their normal business bank account by ACH or wire. The conversion to USDC or USDT happens after the deposit lands, and only your business receives stablecoins in a wallet it controls."
  - q: "How do I match virtual account deposits to invoices?"
    a: "Each deposit creates a payin with its own id, amount, and timestamp. Match payins to open invoices by amount, date, and the payment reference. Ask payers to put the invoice number in the reference field. For international wires, the payin also carries the sender name, sender bank, sender account, and the reference the sender attached."
  - q: "Can I use one virtual account to collect payments for my clients?"
    a: "Only for your own revenue. A virtual account that collects money belonging to parties BlindPay has not onboarded is a nested structure, which BlindPay prohibits. If you collect your own invoices for services you delivered, that is fine. If a client needs to collect from its own customers, the compliant path is for that client to onboard as its own BlindPay instance."
  - q: "How long does it take to get a virtual account approved?"
    a: "It depends on the account type. BlindPay documents a 24 hour issuance SLA for one US account type and 3 to 5 business days for the business account types, after a two-stage review: compliance first, then the bank. Approval is not guaranteed at either stage, so apply before you need to send invoices with the new details."
  - q: "Which stablecoin should I receive invoice payments in?"
    a: "USDC or USDT, chosen when you create the virtual account. USDC works with any supported settlement wallet. USDT settlement requires the linked wallet to be on Polygon, Ethereum, or Solana. Pick the token your treasury or payout flow already uses, so you avoid a second conversion before you spend or pay out the funds."
---

A virtual account lets a business outside the US collect invoices from US customers as stablecoins. The account has its own routing and account number in your company's name. Customers pay by ACH or wire as they would any vendor, and each deposit is converted to USDC or USDT and sent to the wallet you linked.

This is the receivables version of the [bank transfer to stablecoin flow](/resources/more/accept-bank-transfers-settle-in-stablecoins). Same mechanics, but the job is narrower: get paid by US companies on time, know which invoice each deposit pays, and keep the money in a form you can move again the same day.

**Key takeaways**

- Your US customers pay a normal US bank account. They never see a wallet or a stablecoin.
- Each deposit becomes a payin that settles to USDC or USDT in a wallet you control.
- Reconciliation works on the payin: amount, date, and reference. Wires also carry sender details.
- The account is for your own revenue. Collecting for third parties is nesting.
- Approval runs through compliance and a bank, so apply before the invoice cycle that needs it.

## Why do non-US businesses struggle to collect from US customers?

Because US companies pay vendors through US rails, and a foreign bank account sits outside them. ACH is how most US businesses pay each other, and a vendor without US account details gets pushed to slower, pricier options.

The volume is large and growing. Nacha reported close to 8.1 billion business-to-business ACH payments in 2025, up almost 10% from 2024 ([Nacha, January 2026](https://www.nacha.org/news/same-day-ach-and-business-business-payments-propel-ach-network-volume-growth-2025)). A software agency in Buenos Aires or a manufacturer in São Paulo that asks a US client for an international wire is asking that client to leave the default rail. Some will. Many pay late.

International wires also cost the receiver. Fees get deducted along the correspondent chain, which is why an invoice for $10,000 often arrives short. [Hidden fees in international wires](/resources/more/hidden-fees-international-wires-our-sha-ben) breaks down where that money goes.

## What is a virtual account for receivables?

It is a US bank account number issued in your business's name, whose deposits settle to stablecoins instead of sitting as dollars at a bank.

> **Definition:** A **stablecoin virtual account** is a dedicated bank account, with its own routing and account number, whose incoming bank transfers are automatically converted to a stablecoin such as USDC or USDT and delivered to a linked wallet. For receivables, it replaces "wire us at our foreign bank" with US account details a US payer already knows how to use.

From the payer's side, nothing is unusual. They add a vendor with a beneficiary name, routing number, and account number, then pay the invoice. From your side, every deposit arrives as a tracked payment object with a status, not as a line on a bank statement you have to read. [What is a virtual account](/resources/more/what-is-a-virtual-account) covers the general concept.

## How does the collection flow work, step by step?

Five steps. The first three happen once, the last two happen on every invoice.

1. **Pass KYB and the account review.** BlindPay reviews virtual account requests separately from KYB. You provide industry, entity type, nature of business, account purpose, source of funds, and source of wealth, backed by documents such as financial statements or the last 3 months of bank statements ([virtual account documents](/docs/kb/virtual-accounts)).
2. **Link a settlement wallet and pick the token.** Register a blockchain wallet you control and request the account with `USDC` or `USDT` ([create a virtual account](/docs/virtual-accounts-create)).
3. **Wait for approval.** The account moves from `pending_review` (compliance) to `verifying` (bank) to `approved`. The `virtualAccount.complete` webhook fires when the numbers are issued.
4. **Invoice with the new details.** Put the beneficiary name, routing number, and account number on every invoice and in your billing portal.
5. **Reconcile each payin.** Each deposit creates a payin. Match it to the open invoice and mark it paid.

[Virtual account requirements](/resources/more/virtual-account-requirements-kyc-kyb) explains what the bank reviews in step 1 and why it asks.

## Which payment methods can your customers use?

US payers can use ACH and domestic wire. Depending on the account type, payers outside the US can send an international SWIFT wire to the same account, which BlindPay only accepts into an approved virtual account ([bank transfer in](/docs/payins)).

| Payer | Method | Typical use | What you see |
| --- | --- | --- | --- |
| US company, routine invoice | ACH | Recurring and lower-value invoices | A payin per deposit |
| US company, urgent or large invoice | Domestic wire | Same-day needs, large amounts | A payin per deposit |
| Non-US company | International SWIFT wire | Customers outside the US paying in USD | A payin with sender name, bank, account, and reference |

Timing depends on the rail and the payer's bank. BlindPay's docs list receive-side settlement of up to 5 business days for ACH, wire, and SWIFT deposits, so plan cash forecasts on the slow end.

## How do you reconcile deposits against invoices?

Match on the payin, not on a bank statement. Each payin has an id, an amount, a status, and timestamps, and it fires `payin.new` when created and `payin.complete` when it finishes.

A simple rule set works for most teams:

- **Exact amount plus open invoice.** If one open invoice matches the deposit amount for that customer, mark it paid.
- **Reference.** Ask payers to put the invoice number in the payment reference. For international wires, the payin carries `sender_name`, `sender_bank_name`, `sender_account_number`, and `transaction_reference`, so you can match without asking who paid ([POBO and COBO](/docs/kb/pobo-cobo)).
- **Exceptions queue.** Partial payments, combined payments for several invoices, and short-paid wires go to a human.

Illustrative example: an agency has three open invoices to US clients for $4,000, $4,000, and $12,500. A $12,500 ACH deposit matches one invoice and closes automatically. Two $4,000 deposits arrive the same day from different clients, so the agency uses the reference to tell them apart. Without a reference, both go to the exceptions queue. [Virtual account reconciliation](/resources/more/virtual-account-reconciliation) has a longer worked example.

## What compliance rules apply to a receivables account?

The account is for your own revenue. Money for services you delivered is fine; money that belongs to someone else is not.

BlindPay's rule is that you may not use a virtual account to move payments for any party whose identity or activity BlindPay cannot see ([nested payments](/docs/kb/nested-payments)). An agency collecting its own invoices passes. A platform collecting on behalf of dozens of its own clients, who were never onboarded, is a nested structure, and those payments can be delayed, frozen, or the account terminated. The compliant path is for each of those businesses to onboard directly, or as its own instance.

Fraud is the other control. Business email compromise was the top avenue for attempted and actual payments fraud in 2024, per the [AFP 2025 Payments Fraud and Control Survey](https://www.financialprofessionals.org/about/learn-more/press-releases/Details/survey-79-percent-of-organizations-were-victims-of-attempted-or-actual-payments-fraud-activity-in-2024). Payment details that never change are easier to defend. Tell clients that your account details will not change by email alone, and confirm any change by phone.

## How does BlindPay handle B2B receivables?

BlindPay issues US virtual accounts in the customer's own name, with individual routing and account numbers. Each deposit creates a payin, and BlindPay converts it and sends USDC or USDT to the wallet linked at creation ([virtual accounts](/docs/virtual-accounts)). USDT settlement requires a wallet on Polygon, Ethereum, or Solana.

Fees on deposits are tracked per payin: deposits below $100.00 accrue to your monthly invoice, while larger deposits are charged at the time of the transaction. [Virtual account fees](/resources/more/virtual-account-fees) lists every cost between the payer's bank and the wallet. Once the stablecoins land, you can hold them or pay them out again through the same API, which is where the speed gain shows up. If custody matters to your finance team, [how to verify a payment provider is really non-custodial](/resources/more/how-to-verify-non-custodial-payment-provider) is the test plan, and [blockchain payments vs crypto payments](/resources/more/blockchain-payments-vs-crypto-payments) explains why the payer never handles crypto.

## What should you do next?

List your top 20 US customers by invoice volume, check how each one pays vendors today, and start with the ones that already pay by ACH. Apply for the account a full invoice cycle before you plan to switch details.

Read the [create a virtual account guide](/docs/virtual-accounts-create) to see the exact fields your business needs before the review starts.