---
title: "Virtual account vs wallet address vs payment link: how to collect in stablecoins"
seoTitle: "Virtual account vs wallet address vs payment link"
description: "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."
date: "2026-10-06"
updated: "2026-10-06"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What is the difference between a virtual account and a wallet address?"
    a: "A virtual account is a set of bank details, such as a routing and account number, that receives fiat transfers like ACH or wire and converts them to stablecoins. A wallet address receives stablecoins directly on a blockchain, so the payer must already hold USDC or USDT on the right network. One is for payers with bank accounts. The other is for payers with crypto."
  - q: "What is a stablecoin payment link?"
    a: "A stablecoin payment link is a URL or QR code that encodes a payment request: the recipient address, the token, the amount, and often a reference. Standards like Ethereum's EIP-681 and the Solana Pay specification define the format, so a wallet can open it and prefill the transfer. Hosted checkout pages wrap the same idea in a web page with a timer and status."
  - q: "Does the payer need crypto to pay into a virtual account?"
    a: "No. The payer sends a normal bank transfer from any bank account, using the routing and account number the virtual account provides. The provider converts the deposit into USDC or USDT and sends it to the wallet linked to the account. The payer may not know stablecoins are involved at all, which is the main reason businesses use virtual accounts."
  - q: "Which collection method is easiest to reconcile?"
    a: "A virtual account per customer is usually easiest, because every deposit into that account belongs to one payer, with no memo to match. Payment links with a unique reference come next. A shared wallet address is the hardest: many payers send to one address, and you have to match transfers by amount, time, or sender address, which breaks when two payers send the same amount."
  - q: "Can a stablecoin payment to a wallet address be refunded?"
    a: "Not by reversing it. Onchain transfers are final once confirmed, so a refund is a new transfer from the recipient back to the payer, and the recipient has to know a safe address to send it to. Bank transfers into a virtual account follow the rules of the rail, and providers may return a deposit they can't accept to the sender."
  - q: "When should a business use more than one collection method?"
    a: "When its payers differ. A marketplace may give each seller a virtual account for bank payers, show a payment link at checkout for buyers who hold USDC, and keep a deposit address for partners who settle in stablecoins. Each method ends in the same place, a stablecoin balance, so the ledger can treat them as three inputs to one account."
---

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](/resources/more/what-is-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](https://www.nacha.org/content/what-is-ach)). Wires usually run over Fedwire, where payments credited to Federal Reserve master accounts are final ([Federal Reserve Financial Services](https://www.frbservices.org/financial-services/wires)). Some accounts also accept SWIFT from foreign banks.

[Stablecoin virtual accounts explained](/resources/more/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](/resources/more/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](/resources/more/how-merchants-accept-stablecoin-payments) walks through the merchant side of address-based collection.

## What is a stablecoin payment link?

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](https://eips.ethereum.org/EIPS/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](https://docs.solanapay.com/spec) 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.

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

## 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](/resources/more/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?](/resources/more/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](/docs/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](/docs/virtual-accounts-create) guide, and send your first test deposit today.