# B2B Virtual Card Payments: A Seller's Guide

> How B2B virtual card payments work, why buyers' AP teams prefer them, what they cost you as the seller, and how to reconcile them without manual keying.
- **Author**: Aarthi Poonia
- **Published**: 2026-07-30
- **Category**: Payments, B2B
- **URL**: https://dodopayments.com/blogs/b2b-virtual-card-payments

---

You send a $48,000 annual invoice to an enterprise customer on net-45 terms. Three weeks later, instead of an ACH credit, an email arrives from their accounts payable platform with a 16-digit card number, a CVV, an expiry date, and instructions to charge it for exactly $48,000. Your finance lead now has to key that number into a terminal, and your effective margin on the deal just dropped by whatever your card processing rate is.

B2B virtual card payments are single-use or supplier-locked card numbers that a buyer's AP department issues to pay a specific invoice, usually with hard controls on amount, date window, and merchant. They settle over ordinary card rails, which means you receive funds fast, and it means you pay card processing fees on money that would previously have arrived by bank transfer at near-zero cost.

That cost shift is the whole story, and most coverage of virtual cards is written from the buyer's side. This guide is written from the seller's.

## Virtual card vs ACH vs wire vs check

Here is how the four dominant B2B rails compare on the dimensions that actually affect a seller's decision.

| | Virtual card | ACH | Wire | Check |
| --- | --- | --- | --- | --- |
| Speed to funds | Authorised instantly, funded on your normal card payout cycle | One to a few business days | Same day domestically | Days to weeks including mail and clearing |
| Cost to seller | Card processing fees on the full invoice amount | Low flat fee per transaction | Low flat fee, often absorbed by the buyer | Bank deposit cost plus significant manual handling |
| Cost to buyer | Typically net negative: issuers pay rebates on spend | Low flat fee | Moderate flat fee | Printing, postage, and labour |
| Reconciliation effort | High by default: funds and remittance advice arrive separately | Moderate: remittance data can travel in the addenda record | Moderate: reference fields are short and often truncated | High: manual matching from a paper stub |
| Fraud exposure for the seller | Chargeback rights apply; the buyer can dispute | ACH return windows apply but disputes are narrower | Very low once received; effectively final | Cheque fraud and stop-payment risk |
| Payment certainty | High within the card's controls, declines outside them | High once cleared | Very high | Low |

Read the "cost to buyer" row next to the "cost to seller" row. That asymmetry is not incidental, it is the product. Card issuers fund buyer rebates out of the fees paid by accepting merchants, so a virtual card programme converts a buyer's accounts payable function from a cost centre into a revenue line, and the money comes from you.

For a broader comparison of bank-based rails, see [EFT vs ACH vs wire transfer](https://dodopayments.com/blogs/eft-vs-ach-vs-wire-transfer) and our [guide to ACH payments for SaaS](https://dodopayments.com/blogs/what-is-ach-payment-saas-guide).

## What B2B virtual card payments actually are

A virtual card is a card number generated on demand and bound to a set of rules, rather than a plastic card tied to an account. The number is real and runs on existing card networks, so you need no new acceptance infrastructure to take one.

The controls attached to it are what make it a business instrument rather than just a card:

- **Amount limits.** Usually locked to the exact invoice total, sometimes with a small tolerance band.
- **Validity window.** A short date range, often measured in days or weeks, after which the number stops authorising.
- **Merchant locking.** Restricted to a single supplier, sometimes to a single merchant category code.
- **Single use.** Many programmes burn the number after one successful authorisation.

Because a number can be created per invoice, a compromised number is worth very little. That is the same security logic behind [payment tokenisation](https://dodopayments.com/blogs/payment-tokenization), applied at the procurement layer rather than the checkout layer.

Virtual cards are usually issued from a commercial card programme through the buyer's AP automation platform or their bank. The buyer approves an invoice in their workflow, the platform generates a number scoped to that invoice, and it is transmitted to the supplier by email, portal, or a direct file feed.

## Why AP departments push B2B virtual card payments

Buyers are not adopting virtual cards to be difficult. From the AP side the case is genuinely strong, and understanding it tells you where you have leverage in a negotiation.

- **Rebates.** Card issuers share a portion of the spend back with the buyer. For a company running significant payables through cards, this turns AP into a contributor to the bottom line.
- **Float.** A card payment settles on the issuer's billing cycle, so the buyer gets additional days of working capital beyond the invoice terms without being late.
- **Control.** A number that only works once, for one amount, with one supplier, removes an entire class of internal fraud and unauthorised spend. Compare that to a shared corporate card or a bank transfer that requires manual approval chains.
- **Speed of onboarding.** Adding a new supplier to an ACH programme means collecting and verifying bank details, which is itself a common fraud vector. Issuing a virtual card requires none of that.
- **Automatic reconciliation on their side.** Because the number is unique to the invoice, the buyer's system can match the card statement line to the invoice with no ambiguity.

Note the last point carefully. The buyer gets perfect reconciliation precisely because the identifier that makes matching easy lives in their system, not yours. Your side of the same transaction is where the friction lands.

## What these payments cost you as the seller

Three distinct costs apply, and only the first is obvious.

**Processing fees.** You pay your normal card rate on the full invoice amount, tax included. On a $48,000 invoice this is a meaningful number, and unlike a consumer transaction there is no conversion uplift to justify it. Commercial and purchasing cards generally carry higher network costs than consumer debit, so a blended rate quoted for consumer volume may not be what you actually pay. Our breakdowns of [card processing fees for small business](https://dodopayments.com/blogs/credit-card-processing-fees-small-business) and [processing fees compared](https://dodopayments.com/blogs/payment-processing-fees-compared) cover how the components stack, and [how interchange works](https://dodopayments.com/blogs/interchange-fees-explained) explains where the money goes.

One lever exists here. Card networks define enhanced data levels, commonly called Level 2 and Level 3, that require the merchant to submit additional fields such as tax amount, customer reference code, and line-item detail. Transactions that qualify are eligible for more favourable commercial card rates. Whether your provider supports submitting that data, and whether your invoicing system can produce it, materially affects the cost of accepting virtual cards. Ask before you assume.

**Dispute exposure.** A wire, once received, is effectively final. A card payment carries the buyer's dispute rights for the full chargeback window, which means a commercial disagreement can be resolved by your customer's bank rather than by your contract. That is a real transfer of risk, and it is worth pricing into large deals. See [chargeback prevention](https://dodopayments.com/blogs/chargeback-prevention-saas) and the [disputes documentation](https://docs.dodopayments.com/features/transactions/disputes) for how the process runs.

**Manual handling.** If a human reads a PDF and types a card number into a terminal, you have added labour cost, key-entry error risk, and a PCI scope problem to every invoice. This is the cost most finance teams underestimate because it does not show up on a processor statement.

The honest framing for a seller is this: virtual cards buy you faster and more certain collection in exchange for a percentage of revenue and additional dispute risk. If your alternative is chasing a net-60 payer and carrying the [days sales outstanding](https://dodopayments.com/blogs/dso-days-sales-outstanding-saas), the trade can be worth it. If your alternative is a reliable ACH payer on net-15, it usually is not.

## The reconciliation problem: remittance advice arrives separately

This is the operational failure mode that surprises sellers most, and it is structural rather than a defect in any particular platform.

When a buyer pays by virtual card, two things travel on different paths. The money moves over the card network as an authorisation and capture, carrying almost no descriptive data. The remittance advice, the document that says which invoices this payment covers, arrives by email or sits in a supplier portal. Nothing automatically joins them.

The consequences compound at scale:

- A single card payment may cover several invoices, and the card capture carries no invoice numbers.
- Short-pays and deductions appear only in the remittance advice, so your ledger shows a payment that does not match any open invoice.
- The [statement descriptor](https://dodopayments.com/blogs/statement-descriptor) the buyer sees is yours, but what you see is a card authorisation with no purchase order reference.
- If the remittance email lands in a shared inbox nobody owns, cash sits unapplied and your AR ageing lies to you.

Fixing this is mostly process, not technology. Insist on a machine-readable remittance file rather than a PDF, require a purchase order or invoice reference to be passed in the enhanced data fields, and treat unapplied cash as an alerting condition rather than a monthly cleanup task. Our [remittance advice guide](https://dodopayments.com/blogs/remittance-advice-guide-templates) covers the formats, and [payment reconciliation for SaaS](https://dodopayments.com/blogs/payment-reconciliation-saas) covers building the matching job.

If you are running this at volume, the receivables workflow around it matters as much as the payment rail itself. See [accounts receivable for SaaS](https://dodopayments.com/blogs/accounts-receivable-saas-guide) and the wider [order to cash process](https://dodopayments.com/blogs/order-to-cash-process).

## Straight-through processing and how to get it

Straight-through processing means the virtual card is charged programmatically, without a human reading a number and typing it anywhere. It is the difference between virtual cards being an efficiency gain and being a tax on your finance team.

Getting there requires three things.

First, the card details must arrive in a structured feed rather than an email body. Most AP platforms support a supplier-side integration or a secure file drop for exactly this. Ask for it during onboarding; it is rarely offered by default.

Second, the charge must be initiated through an API against your provider rather than a virtual terminal. That keeps the card number out of your inbox, out of your CRM, and out of PCI scope. If you cannot avoid touching raw numbers, read our note on [raw card APIs and PCI scope](https://dodopayments.com/blogs/raw-card-api-pci-compliance) before you build anything.

Third, the result must post back to your ledger automatically. Webhook-driven posting closes the loop so that a successful capture clears the invoice without anyone re-keying it. Dodo Payments emits `payment.succeeded` and related events following the Standard Webhooks specification, documented under [webhooks](https://docs.dodopayments.com/developer-resources/webhooks), and [webhooks for payment notifications](https://dodopayments.com/blogs/webhooks-payment-notifications) walks through consuming them.

The security posture matters here too, since you are handling card data associated with unusually large amounts. [Payment security best practices](https://dodopayments.com/blogs/payment-security-best-practices) is the relevant checklist.

## Spend controls, expiry, and declines

Virtual card controls exist to protect the buyer, and they routinely cause declines that look like your problem.

The common failures:

- **Amount mismatch.** The card is locked to the approved invoice total. If you add a shipping charge, apply a late fee, or recalculate tax after the buyer approved the invoice, the authorisation declines. Bill the exact approved amount or get the card reissued.
- **Expiry.** Single-use numbers are often valid for a short window. If the number sits in an unmonitored inbox over a weekend, it can expire before anyone charges it.
- **Partial capture not permitted.** Some programmes require a single full-amount capture. Splitting a payment across two captures, which is normal for staged delivery, can fail outright.
- **Merchant category restriction.** If the card is locked to a category code that does not match how your acquirer classifies you, it declines regardless of amount.
- **Currency mismatch.** A card issued in USD charged in EUR may decline or convert unpredictably.

None of these produce a helpful error at the terminal. You will see a generic decline. Our reference on [card decline codes](https://dodopayments.com/blogs/credit-card-decline-codes) helps translate what you do get, and [payment retry logic](https://dodopayments.com/blogs/payment-retry-logic) covers what to do next. Blind retries against a virtual card are counterproductive and can look like [card testing activity](https://dodopayments.com/blogs/card-testing-fraud) to fraud systems, so escalate to the buyer instead of retrying.

## When a virtual card is the wrong instrument

Be willing to say no. Virtual cards are a poor fit in several common situations, and buyers usually have an alternative available.

- **Very large single payments.** On a seven-figure contract, a percentage-based fee is not a rounding error. Wire is the correct rail, and most procurement teams accept that.
- **Recurring subscription billing.** A single-use number cannot support a renewal. If you are billing monthly or annually on a card, you need a stored credential, not a virtual card per cycle. See [recurring payments](https://dodopayments.com/blogs/recurring-payments-guide) and [per-seat B2B billing](https://dodopayments.com/blogs/pay-per-seat-billing-b2b).
- **Thin-margin resale.** If you are passing through hardware or third-party licences at low markup, card fees can exceed the margin on the line.
- **Usage-based billing with variable totals.** Amount-locked cards fight against invoices whose final value is only known at period close.
- **Where a direct debit mandate already exists.** If the buyer has authorised [direct debit](https://dodopayments.com/blogs/what-is-direct-debit), the marginal benefit of a card is small and the marginal cost is not.

A reasonable commercial position is to accept virtual cards below a threshold and require bank transfer above it, stated in your terms rather than negotiated per invoice. Some sellers offer a small discount for ACH instead, which is cleaner than a surcharge and avoids the regulatory complexity that surcharging carries in many jurisdictions.

## Accepting B2B virtual card payments in practice

Operationally, a virtual card is a commercial card transaction. Anything that accepts commercial credit and debit cards can accept one, which is why no special integration is strictly required.

What does need attention is the surrounding B2B context. Cross-border business sales need the buyer's tax identifier captured so the correct treatment is applied, which Dodo Payments handles through [B2B tax ID validation at checkout](https://docs.dodopayments.com/features/b2b-payments). Card acceptance itself, including which networks and card types are supported, is documented under [cards](https://docs.dodopayments.com/features/payment-methods/cards), and the full method matrix including regional options sits in [payment methods](https://docs.dodopayments.com/features/payment-methods).

If your buyers span regions, offering the right local alternative alongside cards reduces how often a virtual card is the only option on the table. That argument is made in detail in [the best payment methods for SaaS](https://dodopayments.com/blogs/best-payment-methods-for-saas) and [why localised payment methods lift conversion](https://dodopayments.com/blogs/why-localized-payment-methods-are-important-for-higher-conversions).

For sellers without their own merchant account, [accepting cards without a merchant account](https://dodopayments.com/blogs/accept-credit-cards-without-merchant-account) explains the merchant of record route, and pricing is published at [dodopayments.com/pricing](https://dodopayments.com/pricing).

## FAQ

### What is a B2B virtual card payment?

It is a payment made with a card number generated by a buyer's accounts payable system for a specific invoice, usually locked to one amount, one supplier, and a short validity window. It settles over normal card rails, so any seller who already accepts commercial cards can accept one without new infrastructure.

### Why do buyers prefer virtual cards over ACH?

Because card issuers pay rebates on the spend, the buyer earns extra days of float on the issuer's billing cycle, and a single-use number scoped to one invoice removes a class of internal fraud. Onboarding is also faster, since no bank account details need to be collected and verified.

### Do virtual card payments cost the seller more than a bank transfer?

Yes, in almost every case. You pay card processing fees on the full invoice amount including tax, where an ACH credit or wire typically costs a small flat fee. Submitting Level 2 and Level 3 enhanced data can qualify commercial card transactions for more favourable rates, so ask your provider whether it supports those fields.

### Why is reconciliation harder with virtual cards?

Because the funds and the remittance advice travel separately. The card capture carries almost no descriptive data, while the document listing which invoices the payment covers arrives by email or sits in a supplier portal. Insisting on a machine-readable remittance file and an invoice reference in the enhanced data fields is the practical fix.

### Can I refuse to accept a virtual card?

You can, and for large or thin-margin transactions it is often the right call. State an acceptance threshold in your payment terms rather than negotiating per invoice, and offer a clear bank transfer alternative. Some sellers offer a discount for ACH instead of surcharging cards, which avoids the surcharging rules that apply in many jurisdictions.

## Conclusion

Virtual cards solve a real problem for buyers and shift its cost to sellers. You get faster, more certain collection and no bank-detail exchange. You pay card processing on the full invoice, absorb dispute rights that a wire would never have carried, and inherit a reconciliation gap because the money and the remittance advice arrive by different paths.

Two moves recover most of the value. Get the card details into a structured feed and charge them through an API so no human touches a number, and require an invoice reference in the enhanced data fields so cash applies itself. Then set an acceptance threshold above which you ask for a bank transfer, and put it in your terms rather than defending it deal by deal.

If you would rather not run a merchant account, dispute handling, and cross-border tax logic yourself, [Dodo Payments](https://dodopayments.com) accepts commercial cards as the merchant of record and validates buyer tax IDs at checkout, so a virtual card payment lands as a normal card transaction with the compliance handled.
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)