---
title: "How to choose a virtual account provider: a 12-point checklist for developers and finance teams"
seoTitle: "How to choose a virtual account provider: 12-point checklist"
description: "Twelve criteria for evaluating a virtual account API, from rails and naming to custody, webhooks, and pricing, plus red flags and a scorecard to copy."
date: "2026-09-27"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "How long does it take to integrate a virtual account API?"
    a: "The code is usually the short part: create a customer, link a settlement destination, create the account, and handle a few webhooks. The long part is production approval. Your customers need KYC or KYB, and named accounts go through compliance and bank review. At BlindPay that review has SLAs of 24 hours or 3 to 5 business days depending on the account type."
  - q: "Do I need my own bank to offer virtual accounts?"
    a: "No. A virtual account provider brings the banking relationships and issues accounts on top of them, so your platform integrates one API instead of negotiating with banks. What you do need is a compliance program the provider can rely on: verified customers, a clear account purpose, and documents like source of funds when the bank asks for them."
  - q: "Can I switch virtual account providers later?"
    a: "Yes, but plan for it. Account numbers belong to the provider's banking partner, so switching means issuing new accounts and asking every payer to update their details. Keep your own customer and ledger ids separate from provider ids, and store provider account ids in their own table, so a second provider is a new mapping rather than a rewrite."
  - q: "What compliance documents will I need for virtual accounts?"
    a: "Expect standard KYC or KYB for each customer, plus details the bank reviews for the account itself: business type and industry, purpose of the account, expected volume, and source of funds and source of wealth. Supporting documents are usually recent bank statements, financial statements, tax returns, or contracts that show where the money comes from."
  - q: "Should one provider handle virtual accounts, payouts, and custody?"
    a: "It depends on your stack. One provider for collection and payout keeps reconciliation in one place and avoids moving money between vendors. Some teams still pair a virtual account and payout provider with a separate provider for wallet custody or stablecoin issuance. Map each money movement to a provider before you sign, and check how funds move between them."
---

When choosing a virtual account provider, check five things first: which rails and currencies the accounts can receive, whether accounts are named in your customer's name or pooled, how settlement works (fiat, stablecoin, and which chains), who holds the funds, and how long compliance and bank approval take. Then score the rest: webhooks, docs, sandbox, pricing, and support.

The demo always works. The checklist is for what happens after.

## Key takeaways

- The five criteria that rule a provider in or out are rails, naming, settlement, custody, and approval time.
- Get every answer in writing, per account type, not per marketing page.
- Banking partner redundancy and event design are the two criteria teams forget and regret.
- Score providers with weights that match your business. A payroll platform and a remittance app shouldn't weight the same things.

## What should you look for in a virtual account provider?

Look for a provider whose accounts can receive the rails your payers use, in a name your payers and compliance team accept, settling where your treasury needs the money, with an approval process you can build onboarding around. The 12 criteria below cover both the developer side and the finance side.

| # | Criterion | Why it matters | Question to ask |
| --- | --- | --- | --- |
| 1 | Currencies and rails supported | An account that can't receive your payers' rail is useless to them | Which rails can deposit into the account (ACH, wire, SWIFT, SEPA, local rails), per account type? |
| 2 | Account naming | Named accounts show your customer as beneficiary; pooled accounts show the provider | Whose name does the payer see, and do payouts go out under the customer's name? |
| 3 | Issuance speed and limits | Your onboarding flow waits on it | What's the SLA per account type, what restarts the clock, and how many accounts can one customer hold? |
| 4 | Settlement options | Decides whether you receive fiat, stablecoins, or both, and on which chains | Can deposits settle as fiat, USDC, or USDT? On which networks? Can I change the destination later? |
| 5 | Custody model | Decides who holds funds after settlement and who carries the risk | Do funds settle to a wallet or account my customer controls, or one you hold? |
| 6 | Compliance and KYC/KYB coverage | You can't issue an account to a customer the provider can't verify | Do KYC, KYB, and sanctions screening run inside your API, and which countries can you onboard? |
| 7 | Banking partner redundancy | One bank relationship is one point of failure | How many banking partners issue your accounts, and what happens to my accounts if one exits? |
| 8 | Webhooks and event design | Your ledger runs on these events | Which events fire per account and per deposit? Are they signed, retried, and replayable? |
| 9 | API docs and SDKs | Integration speed, and how many surprises you hit | Is there a public OpenAPI spec? Which languages have official SDKs? |
| 10 | Sandbox and CLI | You need to test deposits before any real bank is involved | Can I create accounts and simulate deposits on a free sandbox? Is there a CLI? |
| 11 | Pricing transparency | Hidden per-deposit fees break unit economics | What's the monthly cost per account, the fee per deposit, and where does each show up? |
| 12 | Support and SLAs | Stuck deposits become your support tickets | Who do I contact when a deposit is on hold, and what are your response times? |

## Why do banking partner redundancy and event design matter?

These two get skipped in most evaluations, and they're the ones that hurt later.

**Banking partner redundancy.** Virtual accounts sit on a bank's infrastructure. If a provider has one banking partner and that bank changes its risk appetite, every account can be affected at once. Ask how many banks issue the provider's accounts, whether customers are eligible on more than one, and what the migration plan is if a partner exits. A provider with several partners can also route customers by eligibility, for example US versus non-US businesses.

**Event design.** Your ledger is only as good as the events feeding it. You want a creation event and a completion event for every account, and a separate record for every deposit, with its own id, amounts, and fees. You want signed payloads, retries, and a replay button. The patterns for consuming them are in [stablecoin API webhooks and reconciliation](/resources/more/stablecoin-api-webhooks-reconciliation), and what the matching looks like in practice is in [how virtual accounts automate reconciliation](/resources/more/virtual-account-reconciliation).

## What are the red flags?

Walk away, or at least slow down, if you hear any of these:

- **"Global coverage"** with no list of rails per account type.
- **"Instant accounts"** for named accounts, with no mention of review. Either they're pooled, or the review happens later and can claw back what you launched.
- **No answer on whose name the payer sees.**
- **Sandbox behind a sales call.** You should be able to create a test account today.
- **Fees only on the invoice.** If a deposit record doesn't show its own fee, you can't reconcile.
- **Vague on custody.** "Your funds are safe" is not an answer to "in whose name, at which institution?"
- **No position on third-party funds.** A provider that doesn't ask whose money flows through the accounts is a provider whose accounts can get frozen.

## How do you score providers?

Copy this scorecard. Give each criterion a weight from 1 (nice to have) to 5 (dealbreaker) based on your business, score each provider from 1 (poor) to 5 (excellent), and multiply.

| Criterion | Weight (1 to 5) | Provider A score (1 to 5) | Provider A weighted | Provider B score (1 to 5) | Provider B weighted |
| --- | --- | --- | --- | --- | --- |
| Currencies and rails | | | | | |
| Account naming | | | | | |
| Issuance speed and limits | | | | | |
| Settlement options | | | | | |
| Custody model | | | | | |
| Compliance and KYC/KYB | | | | | |
| Banking partner redundancy | | | | | |
| Webhooks and event design | | | | | |
| API docs and SDKs | | | | | |
| Sandbox and CLI | | | | | |
| Pricing transparency | | | | | |
| Support and SLAs | | | | | |
| **Total** | | | | | |

**Illustrative weighting.** A remittance app with foreign senders might weight rails 5 (it needs SWIFT), naming 4, settlement 5 (it pays out in stablecoins), and sandbox 3. A US SaaS company collecting ACH from domestic customers might weight rails 3, pricing 5, and event design 5. Same checklist, different winner.

If you're also evaluating the stablecoin API behind the accounts, [how to choose a stablecoin API](/resources/more/how-to-choose-a-stablecoin-api) covers pre-funding, payout rails, and settlement speed.

## How does BlindPay map to the checklist?

Here's how BlindPay answers each criterion, from the public docs. It's one data point for your scorecard, not a verdict.

| # | Criterion | BlindPay |
| --- | --- | --- |
| 1 | Rails | US virtual accounts receive ACH, wire, and SWIFT, depending on account type. Payouts go out over Pix, SPEI, ACH, RTP, SEPA, SWIFT (POBO/COBO), and other local rails to 100+ countries, with UETR tracking and MT103 confirmations on SWIFT. No IBANs |
| 2 | Naming | Named: each account is issued in one customer's name, and payouts from it go out under that name |
| 3 | Issuance | Compliance review, then bank review. SLA of 24 hours or 3 to 5 business days by account type. A customer can hold several accounts |
| 4 | Settlement | Deposits convert to USDC or USDT and settle to one wallet per account. Token and wallet can be changed later |
| 5 | Custody | Settles to an external blockchain wallet the customer controls |
| 6 | Compliance | KYC, KYB, and sanctions screening in the API. Accounts also need purpose, source of funds, and source of wealth ([requirements](/docs/kb/virtual-accounts)) |
| 7 | Banking partners | Several banking partners, with eligibility based on the customer's country and type |
| 8 | Webhooks | `virtualAccount.new`, `virtualAccount.complete`, and `payin.new`, `payin.update`, `payin.complete` per deposit. Signed, retried, replayable |
| 9 | Docs and SDKs | Public OpenAPI 3.1 spec. Official SDKs for Node.js, Python, Go, PHP, and Swift ([SDKs](/docs/sdks)) |
| 10 | Sandbox and CLI | Free development instance where accounts are approved instantly. A [CLI](/blog/cli) (`blindpay virtual_accounts create`) and an MCP server for AI agents |
| 11 | Pricing | $1.50 per month per account. Each deposit's fee is a field on its payin; plans are on [pricing](/pricing) |
| 12 | Support | Issuance SLAs published per account type in the [virtual accounts docs](/docs/virtual-accounts) |

Two things BlindPay doesn't do, so you can plan around them: it doesn't issue virtual IBANs, and it doesn't allow accounts that collect for your customers' own unverified clients ([nested payments](/docs/kb/nested-payments)). Some teams also pair BlindPay with another provider for wallet custody or stablecoin issuance. That's a normal setup.

For the concepts behind each row, see [what is a virtual account](/resources/more/what-is-a-virtual-account), [virtual account vs virtual IBAN](/resources/more/virtual-account-vs-virtual-iban), and [virtual accounts for cross-border payments](/resources/more/virtual-accounts-cross-border-payments).

## What to do next

Send the 12 questions from the checklist table to every provider on your shortlist, and ask for answers per account type. While you wait, create a test account on a free BlindPay development instance with [create a virtual account](/docs/virtual-accounts-create) and score criteria 8 through 10 yourself. It takes an afternoon.

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