Three ways to collect money that ends in stablecoins: a virtual account, a deposit wallet address, or a payment link. Compare rails, refunds, KYC, and fit.
There are three common ways to collect money that ends up as stablecoins. A virtual account gives the payer bank details and converts their transfer. A wallet address takes stablecoins directly from a payer who already holds them. A payment link prefills a stablecoin transfer for a wallet. The right one depends on what your payer already has.
Teams usually pick one and force every payer through it. That works until the first customer who only has a bank account meets a checkout that only takes USDC. The three methods solve different problems, and plenty of products need two of them.
Key takeaways
All three sit in the collection layer of stablecoin infrastructure. Below is how they differ and how to pick.
A stablecoin virtual account is a set of bank details issued for one customer that receives fiat transfers and automatically converts each deposit into USDC or USDT, sent to a linked wallet. The payer sees a normal bank account. The business ends up with stablecoins.
In the US, the payer uses the routing and account number to send ACH or a wire. ACH is the batch network the US uses for payroll and bill pay (Nacha). Wires usually run over Fedwire, where payments credited to Federal Reserve master accounts are final (Federal Reserve Financial Services). Some accounts also accept SWIFT from foreign banks.
Stablecoin virtual accounts explained covers the mechanics in depth. If you're choosing between a reusable account and per-payment instructions, see virtual account vs one-time deposit instructions.
A deposit wallet address is a blockchain address where a payer sends stablecoins directly. No conversion happens on the way in, because the payer already holds USDC or USDT.
Three details trip people up:
How merchants accept stablecoin payments walks through the merchant side of address-based collection.
A stablecoin payment link is a URL or QR code that encodes a payment request: recipient, token, amount, and often a reference ID. A wallet opens it and prefills the transfer, so the payer only confirms.
Two open standards define the format on major chains. Ethereum's EIP-681 specifies a URL format for payment requests that opens the user's wallet with the transaction parameters filled in. The Solana Pay specification does the same for Solana and adds optional reference fields that can serve as IDs before the transaction exists, which helps match a payment to an order.
Hosted checkout pages build on the same idea: a web page shows the amount, a QR code, a countdown, and a status that flips to paid when the transfer confirms. Underneath, it's still a transfer to an address.
The table compares the three on what matters after launch: who can pay, how you match the money, and what happens when something goes wrong.
| Question | Virtual account | Deposit wallet address | Payment link or hosted checkout |
|---|---|---|---|
| Payer needs crypto? | No | Yes | Yes |
| What the payer uses | Bank transfer (ACH, wire, SWIFT) | Any wallet on the right network | A wallet that reads the link or QR code |
| Speed to funds | Rail-dependent: minutes to days | Seconds to minutes after confirmation | Seconds to minutes after confirmation |
| Reconciliation | Strong if one account per payer | Weak if shared, strong if unique per payer | Strong with a unique reference per request |
| Wrong-network risk | None for the payer | Real | Lower, since the link sets the network |
| Refunds | Return rules of the bank rail | New outbound transfer | New outbound transfer |
| KYC on the account holder | Yes, before issuance | Depends on provider | Depends on provider |
| Setup per payer | Account issuance and review | Address generation | One link per payment |
| Recurring payments | Yes, same details every time | Yes | Usually one link per payment |
| Best for | B2B invoices, payroll funding, payers with bank accounts | Partners and treasuries that hold stablecoins | Checkout for buyers who hold stablecoins |
Look at the "payer needs crypto?" row first. It removes one or two options for most products before anything else matters.
Answer these questions in order and stop at the first clear answer.
Reconciliation is easiest when the destination identifies the payer, and hardest when many payers share one destination.
A virtual account per customer is the cleanest case: every deposit belongs to its owner, and the provider's deposit event carries the account ID. A shared address forces matching by amount, timestamp, or sender address, and sender addresses change when payers use exchanges. Payment links sit in between, as long as each request carries a unique reference you store before the payer pays.
For the virtual account case in detail, see virtual account reconciliation.
Costs land in different places, so compare them per method rather than per provider headline.
Run the numbers at your real payment size. A flat monthly fee is noise on large B2B deposits and a real cost on hundreds of small ones.
Each method has a failure mode worth knowing before launch.
Onchain transfers are final, so none of the crypto-in methods has a chargeback. That protects the merchant and removes a buyer protection, which matters for consumer checkout. Are stablecoin payments reversible? explains what that means in practice.
BlindPay covers the first two methods through its API. It doesn't offer payment links or a hosted checkout.
Virtual accounts. BlindPay issues US virtual accounts in the customer's name with their own routing and account number. They accept ACH, wire, and SWIFT, depending on the account type, and each deposit creates a payin that settles USDC or USDT to the linked wallet. USDT settlement needs the linked wallet on Polygon, Ethereum, or Solana. The customer must have approved KYC first, then each account goes through compliance and bank review. Accounts cost $1.50 per month each. RTP deposits don't land in a virtual account; an RTP payin uses shared bank details with a memo code instead.
Wallet addresses. For customers who already hold stablecoins, there are two options. An external blockchain wallet is an address your customer controls, which keeps that flow non-custodial. A managed wallet (beta) is an address BlindPay creates and holds the keys for, so it's custodial.
The other direction. An offramp wallet is the mirror of a virtual account: a deposit address where every USDC or USDT that lands pays out automatically to a linked bank account. Payouts run over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO).
List your payers by type: bank account only, or already holding stablecoins. If the first group is bigger, create a customer and a test virtual account on a free development instance with the create a virtual account guide, and send your first test deposit today.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.
Seven stablecoin payment platforms compared for US fintechs in 2026: what makes an API production-ready, how each provider handles compliance, settlement speed against ACH, and how to run the evaluation.