Virtual account vs wallet address vs payment link: how to collect in stablecoins

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

  • Start from the payer. Bank account only: virtual account. Already holds stablecoins: wallet address or payment link.
  • Virtual accounts are the only one of the three where the payer never touches crypto.
  • Reconciliation gets harder as accounts get more shared. One virtual account per payer is the cleanest.
  • Onchain transfers can't be reversed. Plan refunds as new outbound payments.
  • Payment links are a wallet UX layer on top of an address, not a separate rail.

All three sit in the collection layer of stablecoin infrastructure. Below is how they differ and how to pick.

What is a virtual account in stablecoin collection?

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.

What is a deposit wallet address?

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:

  1. The network has to match. USDC on Solana sent to an Ethereum address doesn't arrive. Tell payers the token and network, not just the address.
  2. The address can be shared or unique. A shared address is simple to publish and hard to reconcile. A unique address per payer or per invoice fixes that, at the cost of managing more addresses.
  3. Someone controls the keys. If the address belongs to a custodial provider, it holds the funds. If it's your own wallet, you do.

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.

How do the three methods compare?

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.

QuestionVirtual accountDeposit wallet addressPayment link or hosted checkout
Payer needs crypto?NoYesYes
What the payer usesBank transfer (ACH, wire, SWIFT)Any wallet on the right networkA wallet that reads the link or QR code
Speed to fundsRail-dependent: minutes to daysSeconds to minutes after confirmationSeconds to minutes after confirmation
ReconciliationStrong if one account per payerWeak if shared, strong if unique per payerStrong with a unique reference per request
Wrong-network riskNone for the payerRealLower, since the link sets the network
RefundsReturn rules of the bank railNew outbound transferNew outbound transfer
KYC on the account holderYes, before issuanceDepends on providerDepends on provider
Setup per payerAccount issuance and reviewAddress generationOne link per payment
Recurring paymentsYes, same details every timeYesUsually one link per payment
Best forB2B invoices, payroll funding, payers with bank accountsPartners and treasuries that hold stablecoinsCheckout 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.

Which method should you choose, in order?

Answer these questions in order and stop at the first clear answer.

  1. Do your payers hold stablecoins? If most don't, you need a virtual account. Nothing else works for them.
  2. Do payers pay you more than once? Recurring payers suit a virtual account or a dedicated address: the same details every time.
  3. Does each payment need to match an order? Use a payment link with a unique reference, or one account or address per payer.
  4. Who is paying, a person at checkout or a finance team? People at checkout want a QR code and a timer. Finance teams want bank details or an address they can save.
  5. What happens when someone sends the wrong amount or network? Write the refund rule before launch, not after the first mistake.
  6. Who must pass KYC? Virtual accounts verify the holder before issuance. Check what your address or link provider requires.
  7. Can your ledger handle more than one? If yes, offer two methods and route payers by type.

How does reconciliation differ between the three?

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.

Where do costs show up in each method?

Costs land in different places, so compare them per method rather than per provider headline.

  • Virtual accounts often carry a monthly fee per account plus a conversion fee on each deposit. The payer may also pay their own bank's wire fee, which can shrink the amount that arrives.
  • Wallet addresses cost the payer a network fee to send. You pay nothing on the way in unless the address belongs to a provider that charges per deposit.
  • Payment links and hosted checkout usually charge a percentage per payment, like a card processor, plus the payer's network fee.

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.

What are the limits of each method?

Each method has a failure mode worth knowing before launch.

  • Virtual accounts need KYC or KYB and a review before the account exists, so they aren't instant. Coverage is limited to the countries and rails the provider supports, and bank rails have cut-off times.
  • Wallet addresses put network choice on the payer. A wrong-network transfer may be recoverable or lost, depending on who controls the receiving keys.
  • Payment links depend on the payer's wallet supporting the standard. A link that opens nothing on a payer's phone is a dead end.
  • All three end in stablecoins. If you need local currency in a bank account, you still need an off-ramp after collection.

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.

How does BlindPay handle collection?

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

What to do next

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.

FAQ