A customer that once paid your invoices by ACH or check may eventually announce that future payments will arrive as a one-time virtual card number generated through an accounts-payable automation platform. For the buyer, that change can improve payment controls, automate AP workflows, strengthen audit trails, and support commercial-card economics.

For the supplier, the picture is more complicated. The payment may arrive electronically and authorize quickly, but the supplier may also pay commercial-card processing fees, manually key the credential into a virtual terminal, and spend additional time matching the settlement to the correct invoice.

That is why accepting virtual cards from AP automation platforms should be treated as a payment-economics decision, not simply a technical card-acceptance question.

A supplier should evaluate the entire cycle. The relevant questions include what the card costs to process, whether enhanced commercial-card data can be submitted, how quickly cash arrives, whether employees have to handle credentials manually, how refunds and exceptions work, and whether ACH or another payment rail remains available.

The buyer’s economics and the supplier’s economics are also different. A buyer may participate in a commercial-card rebate or incentive program, but that does not mean the supplier automatically receives, shares, or has a contractual right to that rebate.

The strongest virtual card acceptance strategy therefore evaluates processing cost + operational effort + cash-flow benefit + reconciliation quality + security + customer relationship value rather than focusing on a single fee.

What Is a Virtual Card Payment?

A virtual card is an electronically generated payment credential associated with an underlying card account or commercial payment program. Unlike a traditional plastic card, the credential can be issued digitally and configured for a particular purchasing or accounts-payable purpose.

Commercial virtual cards are frequently used for supplier payments because the issuing system can apply tighter controls than a traditional reusable physical card. Depending on the issuer and AP automation platform, a virtual credential may be restricted by amount, transaction count, merchant, merchant category, validity period, or other program parameters.

Visa explains that business virtual cards are digital payment credentials that companies can use for supplier payments and other business expenses, with controls intended to improve security and payment management. For additional background, see Visa’s official guide to virtual cards for business.

Mastercard describes modern virtual cards as credentials linked to underlying funding accounts that can be configured with controls governing how, where, and when they are used. Those controls may include single-use or multi-use settings and predefined transaction limits.

These credentials should not be confused with every other digital representation of a card. A virtual card number generated for an accounts-payable payment is different from a network token used in a digital wallet, even though both may replace exposure of an underlying physical-card number.

Likewise, virtual cards differ from ACH, checks, and wires because they travel through card-payment infrastructure. The supplier typically processes the credential through its merchant account, processor, gateway, virtual terminal, ERP payment integration, or another supported card-not-present acceptance channel.

A useful distinction is:

• Physical commercial card: A tangible business card used by an employee or purchasing representative.
• Purchasing card: A commercial card commonly used to control organizational purchases.
• Corporate card: A business card often used for corporate expenditures, including travel and expense.
• Virtual card: A digitally generated credential linked to a card program.
• Single-use virtual card number: A virtual credential designed for a limited payment purpose or transaction.
• Network token: A substitute credential generally provisioned and managed through tokenization systems.
• ACH: A bank-account payment moving through the ACH Network.
• Check: A paper or electronically processed check payment.
• Wire: A bank-to-bank funds transfer through a wire system.
• AP automation platform: Software coordinating invoice approval, payment selection, remittance, and related accounts-payable workflows.

For suppliers building remote-payment workflows, a background understanding of virtual-terminal and keyed merchant-account configurations can help explain why remote card credentials require different operational controls than physical card-present payments.

What Is a Single-Use Virtual Card Number?

A single-use virtual card number, sometimes referred to as a VCC or VCN, is a virtual credential generated for a limited payment purpose. An AP automation program might assign the credential to one invoice, one supplier, one approved payment amount, or a defined period.

The exact controls depend on the issuer, card program, and AP platform. A supplier should therefore avoid assuming that every temporary-looking card credential follows the same rules.

For example, one customer could send a virtual card authorized for exactly one approved invoice amount. Another program might provide a credential that can accommodate multiple invoices or a controlled range of authorized spending.

The important operational point is that a VCC is not simply an ordinary card number delivered by email. Its authorization controls may be tied to the buyer’s approved AP transaction.

That means attempting the wrong amount, processing it after its validity period, or making repeated attempts after a decline may produce failures that would not necessarily occur with a normal reusable corporate card.

Virtual Cards vs Purchasing Cards, Corporate Cards, ACH, and Checks

Virtual card acceptance B2B workflows make more sense when suppliers understand how virtual credentials differ from other accounts payable payment methods.

Payment Type	Physical Card Needed?	Typical B2B Use	Key Supplier Consideration
Virtual card	No	AP invoice settlement, supplier payments, controlled purchasing	Card-not-present processing cost and remittance matching
Purchasing card	Often, but programs vary	Procurement and controlled business purchasing	Commercial-card acceptance rules and enhanced data
Corporate card	Commonly	Business expenses, travel, purchasing	Card acceptance cost and employee/cardholder workflow
ACH	No	Vendor invoices, recurring B2B payments, high-value transfers	Bank-payment cost, return handling, remittance process
Check	Yes, as a paper instrument	Traditional invoice settlement	Mailing, deposit, clearing, fraud, and manual reconciliation

A purchasing card is a commercial card product designed around business procurement controls. A corporate card may serve broader company expenses, including purchasing and travel.

A virtual card is defined more by how the credential is generated and controlled than by the presence of plastic. Depending on the commercial program, the underlying product may still be associated with purchasing, corporate, or other commercial-card categories.

ACH is entirely different. It transfers money through bank-account payment infrastructure rather than card-network authorization and clearing.

Nacha documentation shows that the ACH Network supports business-to-business payment formats and remittance information, including CTX-based B2B use cases.

Checks operate differently again, relying on check processing and banking systems instead of card authorization or ACH credit/debit processing.

Suppliers comparing these methods should therefore compare more than headline transaction fees. Settlement characteristics, remittance data, payment certainty, staff effort, security controls, customer preferences, returns, disputes, and invoice matching all matter.

For a deeper comparison of the two electronic rails most likely to be considered for invoice payments, see this guide to ACH payments versus credit card payments.

How AP Automation Platforms Use Virtual Cards

AP automation platforms help buyers move invoices from approval to payment with fewer manual steps. Virtual cards are one possible payment rail within that broader workflow.

A simplified process is:

1. The supplier sends an invoice.
2. The buyer validates and approves it.
3. The AP system selects or is instructed to use a virtual card.
4. A card issuer or integrated card program generates or assigns payment credentials.
5. The supplier receives secure instructions and remittance details.
6. The supplier processes the payment.
7. Card clearing and settlement occur.
8. The supplier applies the payment to accounts receivable.
9. The buyer and supplier reconcile their respective records.

The exact architecture varies. The AP software company may not itself be the card issuer, acquirer, or network. Multiple parties can participate behind the interface.

Buyers may favor AP automation virtual cards for several reasons. Digital card credentials can support transaction controls, detailed records, faster payment execution, auditability, centralized payment management, automation, and commercial-card incentives.

Mastercard’s guidance on B2B virtual card acceptance describes how virtual-card acceptance is increasingly being embedded into AP, AR, procurement, and ERP environments, including support for automated reconciliation and richer remittance information.

Mastercard has also highlighted how richer virtual-card transaction data can include commercial references such as invoice numbers or cost centers and support automated reconciliation workflows.

Working-capital strategy can be another factor. The supplier may receive card settlement relatively quickly after processing while the buyer operates within the terms of its commercial-card arrangement.

None of these benefits mean every AP automation platform works identically. Issuers, networks, platforms, buyers, card products, contracts, and supplier arrangements can all produce different economics.

Why Suppliers Receive Virtual Cards Instead of ACH

When a buyer moves a supplier from ACH or check to AP automation card payments, the decision may have little to do with the supplier’s preferred payment method.

The buyer may have standardized its AP department around a commercial-card program. It may prioritize suppliers that accept cards, select payment methods algorithmically, or use different rails depending on invoice amount, supplier enrollment, internal policy, cash-flow objectives, or payment-program economics.

Virtual cards can also give the buyer tighter payment controls than unrestricted reusable credentials. A payment can potentially be tied to a particular supplier, amount, or validity period.

The supplier should nevertheless ask whether ACH remains available. A payment rail that works economically for one customer may be expensive for another.

For example, a $600 professional-services invoice and a $60,000 wholesale order can produce very different margin consequences when both are charged through percentage-based card pricing.

Suppliers should therefore avoid creating one universal payment policy simply because a major customer introduces virtual cards. Customer-specific profitability analysis is often more useful.

How Suppliers Accept Virtual Cards

Accepting virtual cards generally does not require the supplier to possess a special physical card. The supplier needs a merchant acceptance channel capable of processing the card product and transaction type.

A practical virtual-card acceptance workflow is:

1. Confirm that the payment notice is legitimate: Verify the sender or portal against known buyer information.
2. Match the payment to the customer obligation: Confirm invoice number, purchase order, amount, and customer.
3. Retrieve credentials through the approved channel: Prefer a secure portal or integrated system rather than unnecessarily distributing card details.
4. Process the transaction through an approved channel: This may be a virtual terminal, gateway, ERP integration, accounts-receivable system, or automated virtual card processing solution.
5. Submit eligible commercial data where supported: Confirm Level 2 or Level 3 capabilities with the processor.
6. Record transaction references: Keep the processor transaction ID and remittance references without retaining prohibited sensitive authentication data.
7. Match settlement to the invoice.
8. Post the payment to the general ledger and customer account.
9. Dispose of payment credentials that no longer need to be retained.

The payment is generally a card-not-present commercial-card transaction when the card itself is not physically presented, even if an employee enters the number into a terminal interface manually.

Manual Keyed Entry

Many suppliers receive a payment notice and then have an employee manually enter the VCC into a browser-based virtual terminal or gateway.

This is convenient because it uses existing merchant-account infrastructure, but it adds staff work. Someone must open the notice, verify the invoice, obtain the credential, enter the number, check the amount, submit the transaction, save the transaction reference, and then apply settlement later.

Manual entry also increases opportunities for data-entry mistakes. A mistyped expiration date, incorrect amount, or mismatched credential can turn an otherwise routine payment into an exception.

Most importantly, manually entering the number does not convert the payment into a card-present transaction. There is no physical chip, tap, or swipe proving the card was presented at the merchant location.

That card-not-present classification can affect interchange qualification, processor pricing, fraud controls, and documentation requirements.

Why Keyed-Entry Transactions Can Cost More

Keyed-entry transaction costs are one of the main reasons suppliers notice a financial difference after customers migrate from ACH or check to virtual cards.

Card pricing is not determined by one universal “virtual card rate.” The actual cost can involve the card product, transaction environment, merchant category, network interchange rules, enhanced data, timing, processor markup, gateway fees, and contractual pricing model.

Current Visa commercial interchange documentation separately identifies commercial card-not-present categories and other commercial-card programs, illustrating why suppliers should evaluate the actual qualification category rather than assume every commercial transaction receives the same rate.

Mastercard similarly explains that interchange qualification can depend on merchant category, authorization-to-clearing timing, transaction information, enhanced transaction data, and other criteria.

A manually keyed commercial virtual card can therefore cost more than an ACH payment for several reasons:

• It travels through card-network economics rather than the ACH rail.
• The card may be a commercial product with its own interchange category.
• Card-not-present qualification can differ from card-present qualification.
• Processor markup may apply.
• Gateway or virtual-terminal fees may apply.
• Required enhanced data may be missing.
• A transaction can fail to qualify for an intended commercial-card category.

Suppliers evaluating their broader pricing structure may also find this explanation of interchange-plus merchant pricing useful for understanding the distinction between underlying interchange and processor markup.

Keyed Entry vs Automated Virtual Card Processing

Area	Manual Keyed Entry	Automated/Straight-Through Processing
Staff effort	Employee retrieves and enters payment	Workflow can process with minimal intervention
Error risk	Higher exposure to typing and matching errors	Reduced manual entry where properly integrated
Invoice matching	Often requires staff review	Can use structured remittance matching
Card-data exposure	More employee interaction with credentials	Can reduce human credential handling
Processing speed	Depends on staff availability	Can trigger automatically
Integration complexity	Relatively simple	Requires compatible systems and implementation

Manual processing may be perfectly reasonable for a supplier receiving five virtual cards per month. The economics change when hundreds or thousands of invoice payments arrive in the same format.

Straight-Through Processing

Straight-through processing, or STP, attempts to remove repetitive manual steps from receiving and applying AP automation virtual cards.

The exact mechanism varies by provider. Some systems integrate through APIs, gateway functionality, ERP connectors, or specialized accounts-receivable automation tools.

The business case is not simply speed. STP can reduce the number of employees who see card credentials, eliminate repeated typing, reduce payment-entry errors, and improve invoice matching.

However, automation is not equivalent to zero oversight. Finance teams still need exception queues, transaction reporting, reconciliation controls, refund procedures, access management, and periodic reviews.

A webhook notifying an ERP that a card transaction succeeded can be useful, for example, but the accounting process should also reconcile against processor settlement or provider status. A missed callback should not permanently leave an invoice in the wrong state.

The Real Cost of Accepting a Virtual Card

The useful way to measure virtual card acceptance costs is to include every meaningful direct and operational expense.

Depending on the merchant contract, some components may be bundled. Other arrangements expose them separately.

A supplier should calculate actual costs from merchant statements instead of assuming that the headline processor rate represents the complete expense.

For example, suppose a distributor receives significant AP automation card volume. The finance team should identify:

• total virtual card sales volume;
• total processing charges attributable to that volume;
• authorization or gateway charges;
• relevant monthly platform costs;
• labor spent entering cards;
• labor spent resolving declines;
• labor spent matching payments;
• cost of refunds and exceptions;
• days-sales-outstanding changes;
• any identifiable Level 2 or Level 3 qualification improvements.

The supplier can then calculate:

Effective Acceptance Cost = Total Acceptance Cost ÷ Virtual Card Volume × 100

This percentage is an internal analytical metric, not an interchange rate.

Gross Payment vs Net Deposit

A common reconciliation surprise occurs when the invoice amount and bank deposit differ.

If a customer pays a $10,000 invoice using a commercial virtual card, the processor may record a $10,000 gross sale but deposit a smaller net amount if processing charges are deducted from settlement.

Other processors bill fees separately, which could leave the deposit closer to the gross transaction amount and collect charges later.

Finance teams should therefore reconcile three values:

Invoice Amount → Gross Card Transaction → Net Processor Settlement

The difference between gross and net should post to the appropriate merchant-processing expense account rather than being treated as an unexplained short payment from the customer.

This distinction becomes especially important when one settlement batch contains many customers or transaction types.

Virtual Card Interchange and Level 2/Level 3 Commercial Data

Commercial-card interchange can be more complicated than ordinary retail card acceptance because transaction data may influence qualification for certain programs.

Networks maintain their own criteria, products, and qualification rules, and these rules can change. A supplier should therefore validate current requirements through its processor or acquirer rather than copying an old list of “required Level 3 fields” from a generic article.

Visa states that its interchange reimbursement fees are transfer fees between acquiring and issuing financial institutions, while merchants negotiate merchant discount arrangements with their financial institutions.

That distinction matters when someone tells a supplier to simply “negotiate the interchange.” The supplier may have more direct negotiating leverage over processor or acquirer pricing than over underlying network interchange categories.

Level 2 Commercial Card Data

Level 2 data adds commercial information beyond ordinary basic card transaction information. The specific data and qualification requirements depend on the network, processor, card type, and transaction.

Visa’s Supplier Matching Service identifies Level II capability as the ability to send information including sales tax and customer code data.

In practical B2B workflows, Level 2-related information may help connect the card payment with customer or purchase records while supporting commercial-card processing requirements.

The supplier should confirm:

• whether its gateway can transmit Level 2 data;
• whether the processor maps the data correctly;
• which commercial-card transactions are eligible;
• which fields are required for that network and product;
• whether tax treatment is coded correctly;
• how qualification is visible in merchant reporting.

Simply placing an invoice number in a free-text note does not necessarily mean the processor has submitted qualifying commercial data.

Level 3 Commercial Card Data

Level 3 data generally contains richer purchase detail, potentially including line-item information.

Visa describes Level III summary information as data applying to an entire transaction, such as an order date or invoice number, while Level III line-item capability can include fields such as product code, description, quantity, and unit cost.

Depending on the network and implementation, other enhanced fields may be relevant. Suppliers should obtain current specifications from their processor or acquirer before configuring them.

A wholesaler with an ERP already storing SKU, quantity, price, tax, freight, purchase order, and invoice details may be in a better position to automate enhanced-data submission than a business relying on standalone manual terminals.

That does not automatically mean the transaction will qualify for the least expensive commercial interchange category. Card product, merchant category, clearing timing, data validity, and other network rules may still matter.

Level 2 vs Level 3

Area	Level 2	Level 3
Transaction detail	Enhanced summary/commercial data	More detailed summary and/or line-item data
Typical B2B use	Commercial purchasing	Detailed procurement and larger B2B workflows
Integration requirements	Moderate, depending on system	Often greater due to line-item data requirements
Potential interchange qualification	May affect eligible transactions	May affect eligible transactions
Operational complexity	Lower than Level 3 in many setups	Higher where detailed fields must be mapped

Can Level 2 or Level 3 Lower Virtual Card Costs?

Potentially, but never universally.

Properly submitted enhanced commercial data may help eligible transactions qualify for different commercial-card interchange categories. Mastercard expressly identifies submission of enhanced transaction data as one factor that can affect interchange qualification.

However, not every virtual card qualifies for Level 2 or Level 3 treatment, and no supplier should assume an automatic rate reduction.

A strong implementation requires technical support from the gateway and processor, correct data mapping, eligible card products, proper clearing, and accurate transaction information.

Understanding Downgrades

A transaction can fail to qualify for an expected card category when required conditions are not satisfied. This is commonly described operationally as a downgrade.

Causes may include missing enhanced data, incorrect fields, timing problems, mismatched transaction information, or other qualification requirements.

A processor-specific “downgrade fee” should not be assumed. The economic effect depends on the merchant’s pricing model and the category into which the transaction ultimately falls.

The practical fix is transaction-level reporting. Finance teams should compare expected qualification with actual qualification and investigate recurring causes rather than simply accepting a higher effective rate.

Virtual Cards vs ACH and Checks

Virtual cards and ACH can both replace paper checks, but they solve different problems.

Issue	Virtual Card	ACH
Supplier acceptance cost	Commercial-card pricing applies	Often a different, potentially lower-cost structure
Buyer convenience	Strong fit with commercial-card AP programs	Strong fit with bank-based AP workflows
Settlement characteristics	Card authorization, clearing, and processor funding	ACH bank transfer and settlement
Remittance data	Can be paired with rich AP/card references	B2B ACH can support structured remittance
Reconciliation	Strong when payment and invoice references are linked	Strong when remittance is transmitted correctly
Returns/disputes	Card refund and dispute framework	ACH return/reversal framework
Security model	Card credentials and merchant acceptance controls	Bank-account and ACH authorization controls

ACH often carries lower direct acceptance costs for large B2B invoices, but “ACH is cheaper” should not be turned into an absolute rule.

A supplier may have ACH platform fees, failed-payment handling, remittance problems, manual cash application, delayed collection, or additional bank-service costs. Cards may produce higher direct processing expense but faster operational confirmation.

Nacha’s B2B ACH materials demonstrate that ACH can support sophisticated business remittance data rather than serving merely as a basic bank transfer.

For a supplier, the more useful comparison is:

Processing Fees + Staff Labor + Collection Delay + Reconciliation Cost + Fraud/Exception Cost

Virtual Cards vs Checks

Checks avoid card interchange but create different expenses.

Paper payment may require printing and mailing on the buyer side and mail receipt, lockbox handling, deposit processing, exception management, and clearing on the supplier side.

Checks can also produce reconciliation problems when remittance documents are separated from deposits or when information is incomplete.

Virtual cards can move payment instructions electronically and potentially attach better structured remittance information. The tradeoff is merchant processing cost.

Working-Capital Tradeoffs

A card processing fee may be economically acceptable if virtual cards materially shorten a supplier’s collection cycle.

Suppose a customer historically pays by check well after an invoice becomes payable but its virtual card process initiates payment as soon as internal AP approval is complete. Receiving cash earlier can reduce days sales outstanding and improve liquidity.

That benefit should be measured rather than assumed.

Ask:

• How many days earlier does cash actually arrive?
• What is the supplier’s cost of capital?
• Is the improvement consistent?
• Does card payment reduce collection calls?
• Does it eliminate lockbox work?
• Does faster cash compensate for the acceptance cost?

A high-margin professional-services firm may answer differently from a thin-margin distributor.

Virtual Card Rebates: Who Actually Benefits?

“Virtual card rebates” are one of the most misunderstood parts of AP automation card programs.

Commercial-card issuers and AP programs may offer incentives to buyers or cardholders based on card spend or contractual program economics. The structure varies by issuing bank, AP provider, card network arrangement, transaction volume, program type, agreement, and other factors.

The supplier processing the card should not assume it receives that rebate.

The buyer is generally participating in the card program that generated the credential. The supplier is participating on the acceptance side and pays its own merchant-processing costs under a separate relationship.

Those two economics are connected within the larger card ecosystem, but they are not the same contract.

The fact that a buyer receives economic value from card use does not create an automatic supplier right to a percentage of the buyer’s rebate.

Why Buyers Like Virtual Card Rebates

A buyer may have several reasons for routing eligible AP spend through a commercial-card program.

Card use can potentially support payment controls, AP automation, centralized records, working-capital strategy, procurement reporting, and commercial incentives.

Rebate arrangements can make card-based supplier payments financially attractive to the buyer, particularly where large amounts of previously check- or ACH-based AP spend can move through a card program.

However, suppliers should not build financial models using an assumed buyer rebate percentage. Program economics vary substantially and may involve contractual thresholds, exclusions, card products, spend categories, and issuer-specific terms.

A productive supplier conversation is therefore not, “You earn a card rebate, so you owe us half.”

A better conversation is, “This payment method changes our cost of servicing your account. Can we structure payment terms, pricing, automation, or rail choice so the relationship remains economical for both sides?”

Can Suppliers Negotiate Virtual Card Rebates?

Suppliers generally have more realistic leverage over commercial terms than over the buyer’s cardholder rebate agreement.

Possible negotiation areas include:

• using ACH for invoices above an agreed threshold;
• adjusting payment terms;
• negotiating faster payment in exchange for accepting card;
• revisiting product or service pricing;
• offering separately negotiated early-payment discounts;
• reviewing processor/acquirer markup;
• enabling Level 2 or Level 3 data;
• automating virtual-card processing;
• establishing customer-specific payment policies;
• discussing mutually agreed fee allocation where lawful and contractually permitted.

A supplier should never assume it is entitled to “negotiate virtual card rebates” directly from the buyer’s issuing bank simply because it accepts the payment.

A Framework for Negotiating Payment Economics

Suppliers should enter payment-method negotiations with data.

A structured approach is:

1. Calculate actual virtual-card cost: Pull merchant statements and identify processing expense associated with the customer’s payments.
2. Measure DSO impact: Determine whether virtual cards actually accelerate cash collection.
3. Quantify labor: Measure entry, reconciliation, exception, and refund work.
4. Compare alternatives: Estimate equivalent ACH, check, or other available payment economics.
5. Identify high-volume relationships: Prioritize customers where payment method materially affects margin.
6. Discuss mutually beneficial terms: Consider payment timing, invoice size, discounts, or payment-rail options.
7. Review processor pricing: Supplier-side pricing may be negotiable even when the buyer’s payment method is not.
8. Document the arrangement: Update contracts, payment instructions, and AR policies as appropriate.

Early-Payment Discounts vs Card Costs and Buyer Rebates

These concepts should remain separate.

A supplier-funded early-payment discount is a commercial discount the supplier offers in exchange for faster payment.

A card-processing fee is part of the supplier’s cost of accepting a card transaction.

A buyer commercial-card rebate is an incentive or economic benefit associated with the buyer’s card program.

A surcharge or convenience fee is a charge imposed under a particular payment arrangement and can be subject to network rules, state law, processor requirements, contractual restrictions, and disclosure requirements.

Calling all four items a “rebate” creates confusion during negotiations and can produce bad accounting decisions.

Surcharging B2B Virtual Cards

Suppliers should not automatically add a percentage to a virtual card invoice simply because card acceptance costs more.

Surcharging depends on factors that may include card type, network requirements, jurisdiction, disclosures, the merchant’s acceptance agreement, processor support, and applicable law.

Visa publishes specific merchant surcharging requirements and instructs merchants to consider its current rules before implementing a surcharge program.

The safest operational approach is to review the current network rules, processor agreement, and applicable law before imposing any additional card-related charge.

Negotiating Processor Rates and Separating Platform Costs

When customer payment methods cannot be changed, suppliers should examine their own acceptance infrastructure.

A processor pricing review should include:

• commercial-card volume;
• average virtual card ticket;
• card-not-present share;
• authorization fees;
• gateway fees;
• virtual-terminal fees;
• processor markup;
• monthly account fees;
• Level 2/Level 3 capability;
• interchange qualification reporting;
• refund fees;
• reporting and integration features.

Processor markup can sometimes be negotiable, especially when the merchant has meaningful volume or a stable processing history. Underlying network interchange should not be described as a supplier-negotiated processor markup.

The supplier should also distinguish its own merchant costs from the customer’s AP automation platform fees.

A buyer may pay subscription, transaction, program, or other charges associated with its AP system. Those expenses do not automatically appear on the supplier’s merchant statement.

Likewise, the supplier’s gateway, processor, acquiring, and card acceptance expenses should not be assumed to represent what the buyer pays its AP provider.

Invoice-to-Payment Reconciliation

Reconciliation is where a well-designed virtual card program can become easier than a poorly managed check process—and where a poorly implemented virtual card program can create unnecessary accounts-receivable work.

The desired process is:

Invoice → Virtual Card Payment → Authorization → Settlement → AP Remittance → AR Matching → GL Posting

Each stage should produce identifiers that allow finance staff or software to connect records.

Useful fields can include:

• customer account;
• invoice number;
• purchase order;
• gross payment amount;
• virtual card transaction reference;
• processor transaction ID;
• remittance reference;
• settlement batch;
• settlement date;
• processing fee;
• net deposit.

One Card Payment for One Invoice

Single-use virtual cards can simplify reconciliation when one credential corresponds directly to one invoice.

If invoice 48193 is $8,750 and the customer sends a VCC authorized for $8,750 with invoice 48193 in the remittance, matching is straightforward.

The card transaction ID can be associated with that invoice, while any difference between the gross card amount and net merchant settlement can be posted to processing expense.

However, suppliers should not assume every AP automation platform follows one-card-per-invoice logic. Some programs may combine invoices or support different payment structures.

One Payment Covering Multiple Invoices

When one virtual card covers several invoices, remittance information becomes essential.

Suppose a customer processes $32,400 covering six invoices. An AR team cannot reliably determine application solely from the transaction amount.

The remittance should identify the included invoices and payment allocations. If the instructions are incomplete, place the payment in an appropriate unapplied-cash workflow until the allocation is confirmed instead of guessing.

Automation works best when both the payment and remittance record share a stable identifier.

Partial Payments and Amount-Limited Cards

Many virtual card programs can apply amount controls. If the credential is authorized for less than the outstanding invoice, the supplier should determine whether the difference is an intentional partial payment, credit adjustment, deduction, or error.

Do not automatically submit another charge against the same credential without authorization.

When a VCC declines, verify:

• invoice amount;
• amount entered;
• card validity;
• credential details;
• whether it may already have been used;
• customer/AP instructions;
• whether merchant restrictions apply.

Repeated blind retries can worsen the exception and may trigger additional controls.

Partial capture should be used only where the issuer/platform arrangement and processor support it.

Declined, Expired, Duplicate, and Refunded Virtual Cards

Virtual cards create several exception types that AR teams should plan for before volume becomes significant.

A single-use credential may expire or become unusable if it is not processed within the issuer’s or platform’s permitted period. There is no universal validity window applicable to every AP automation virtual card.

Possible causes of a decline can include:

• amount mismatch;
• expired credentials;
• incorrect card information;
• merchant restrictions;
• a credential that has already been used;
• issuer decline;
• processing or integration error.

A supplier should check the information it can safely verify and then contact the payer or AP program when the reason is unresolved.

Duplicate Payment Risk

One important exception occurs when the supplier processes the VCC while a buyer’s AP process also releases ACH or another payment.

Now the same invoice may be paid twice.

The supplier’s reconciliation system should identify duplicates by invoice, amount, customer, and payment date rather than relying only on deposit totals.

Once confirmed, the overpayment should move through the company’s documented refund or customer-credit process.

Refunds to Virtual Cards

Refunds involving a single-use credential can be more complicated than ordinary consumer card refunds because the visible credential may no longer appear active for new purchases.

The supplier should nevertheless follow the processor and network process for refunding the original card transaction.

Do not solve the problem by crediting an unrelated card supplied by someone in an email.

If the original refund process cannot be completed normally, escalate through the processor or acquirer and coordinate with the customer’s AP contact using established channels.

Credit Memos

A credit memo and a card refund are related accounting events but are not identical.

The credit memo changes the amount owed on the customer account. The refund reverses or returns payment value.

Accounting records should connect both events to the original invoice and payment so that AR balances, bank reconciliation, merchant settlement, and customer statements remain consistent.

Chargebacks, Documentation, and Virtual Card Fraud Risk

Commercial virtual cards remain card transactions, so suppliers should maintain evidence supporting legitimate B2B sales.

Potential disputes can involve unauthorized use, duplicate transactions, incorrect amounts, delivery disagreements, or disputes over goods and services.

Relevant documentation may include:

• signed or accepted contract;
• purchase order;
• invoice;
• delivery confirmation;
• service-completion evidence;
• correspondence;
• payment notice;
• remittance record;
• transaction reference;
• refund or credit records.

Documentation does not guarantee a dispute victory, but poor documentation can make it difficult to explain what happened.

Fake Virtual Card Notifications

One of the most preventable risks is treating every “virtual card payment” email as legitimate.

Attackers can imitate AP departments, spoof portals, send phishing links, impersonate customers, or attempt business email compromise.

Before retrieving credentials or changing any payment workflow, verify the request using known customer information.

Useful checks include:

• expected invoice;
• expected customer;
• known AP contact;
• approved portal;
• trusted domain or communication channel;
• payment amount consistent with the invoice;
• independently verified instructions when something changes unexpectedly.

Never use a phone number contained only in a suspicious payment-change email to verify that same email.

For broader card-not-present controls, this resource on online payment security practices provides additional operational context.

PCI DSS and Secure Handling of Virtual Card Credentials

A virtual card number is still payment account data. Calling the credential “single use” does not remove the need to protect it while employees and systems process it.

Suppliers should minimize how many systems and people interact with the number.

Discourage practices such as:

• copying full VCC numbers into accounting notes;
• keeping spreadsheets of card credentials;
• saving screenshots;
• forwarding payment emails broadly;
• storing card details in CRM free-text fields;
• sharing payment credentials over internal chat unnecessarily.

Use processor-approved portals, secure virtual terminals, tokenization, controlled integrations, and access restrictions instead.

CVV and Single-Use Cards

Some virtual credentials may include a card verification value or security code used during authorization.

PCI guidance is clear that card verification codes are sensitive authentication data and must not be stored after authorization.

That prohibition still matters when the number is temporary or single use.

An employee should not copy a CVV into an invoice note, spreadsheet, ticket, screenshot, ERP attachment, or customer record “in case it is needed later.”

Least-Privilege Access and Audit Logging

Only employees who genuinely need access to payment credentials should be able to retrieve them.

A virtual-card workflow can separate responsibilities so that accounting users can see invoice and settlement information without necessarily seeing the full credential.

Audit logs should capture operational information such as:

• employee or system user;
• customer;
• invoice;
• processing date;
• amount;
• transaction reference;
• authorization result;
• settlement result.

Logs should not become an excuse to retain unnecessary full card numbers or sensitive authentication data.

ERP Integration and Automated Cash Application

Virtual card programs become much more scalable when payment data connects with the systems AR teams already use.

Potential integrations include:

• ERP;
• accounting software;
• accounts receivable platforms;
• CRM;
• order-management systems;
• payment gateways;
• customer or supplier portals.

The goal is to prevent payment data from becoming isolated inside a merchant dashboard that accountants must manually compare against invoices.

A strong automated cash-application process looks like this:

Payment Received → Invoice Identified → Payment Applied → Difference Flagged → Account Updated

Structured remittance information is critical.

If the system receives a $14,275 settlement but knows neither the customer nor invoices involved, automation has little to work with.

Supplier Portals

A secure portal can centralize payment notices, remittance details, transaction status, and exception handling.

This can reduce reliance on unencrypted email and provide AR employees with a consistent place to verify whether a virtual card is legitimate.

The portal should support appropriate authentication, role-based permissions, audit logs, and secure credential presentation.

APIs and Webhooks

AP automation platforms, gateways, and accounting systems may use APIs or webhooks to pass payment status information.

For example:

Card Processed → Payment API Reports Success → ERP Updates Invoice Status → Settlement Reconciliation Confirms Funding

A webhook should not be the only source of truth.

Callbacks can occasionally be delayed, duplicated, or missed. Systems should support idempotent processing, provider status lookups, and periodic reconciliation against authoritative processor or platform records.

Creating a Virtual Card Acceptance Policy

A documented supplier virtual card acceptance policy helps prevent individual AR employees from improvising whenever a customer changes payment methods.

The policy can define:

• which customers may use VCCs;
• whether invoice amount affects accepted payment rails;
• approved processing channels;
• required remittance information;
• Level 2/Level 3 procedures;
• credential security;
• decline handling;
• refund procedures;
• duplicate-payment treatment;
• reconciliation ownership;
• customer profitability reviews;
• processor-pricing reviews;
• automation thresholds.

The purpose is not to prohibit virtual cards. It is to ensure the business knows when acceptance makes economic and operational sense.

Customer-by-Customer Profitability

Two customers with identical annual sales may produce different net economics when one pays by ACH and another pays exclusively with virtual cards.

A supplier should therefore incorporate payment cost into account profitability.

Customer	Invoice Volume	Virtual Card Volume	Processing Cost	DSO Benefit	Net Economic Impact
Customer A	Measure actual	Measure actual	Merchant statement data	Measure actual days	Calculate
Customer B	Measure actual	Measure actual	Merchant statement data	Measure actual days	Calculate
Customer C	Measure actual	Measure actual	Merchant statement data	Measure actual days	Calculate

No fixed monetary value should be assigned to faster payment without analyzing the supplier’s actual working-capital situation.

Accounts Receivable Dashboard

Useful virtual card metrics include:

• virtual card volume;
• ACH volume;
• check volume;
• average invoice value;
• processing fees;
• effective acceptance cost;
• unmatched payments;
• declined VCCs;
• expired credentials;
• duplicate payments;
• days outstanding;
• manual handling time;
• Level 2/Level 3 qualification where reporting supports it;
• refund volume;
• reconciliation exceptions.

The dashboard should show whether virtual card acceptance is becoming more efficient or simply more expensive.

Common Virtual Card Acceptance Mistakes

Virtual cards are manageable when suppliers understand what they are accepting. Most problems come from treating the payment method as either “just another credit card” or “free electronic payment.”

Common mistakes include:

• assuming virtual cards have no acceptance fee;
• treating every VCC program as identical;
• assuming a temporary credential is automatically single use;
• manually keying substantial volume without reviewing labor and processing cost;
• ignoring Level 2 or Level 3 capabilities;
• expecting to receive part of a buyer’s rebate automatically;
• repeatedly retrying constrained virtual cards after a decline;
• storing card credentials in email folders or spreadsheets;
• storing CVV after authorization;
• failing to reconcile gross card amount to net settlement;
• accepting suspicious AP payment notices without verification;
• refunding an unrelated card;
• assuming ACH always has the lowest total operational cost;
• ignoring the potential value of faster collection;
• using surcharges without reviewing network, processor, contractual, and legal requirements.

Avoiding these errors requires coordination across treasury, finance, accounts receivable, IT, accounting, and customer management.

Virtual Card Acceptance Checklist

Area	What to Verify
Virtual card acceptance enabled	Merchant account and gateway support required commercial products
Card-not-present pricing understood	Supplier knows effective cost
Level 2/3 support	Processor and gateway can submit qualifying data where applicable
Secure processing channel	Approved virtual terminal, portal, gateway, or integration
AP remittance data	Invoice and customer references available
Invoice matching	Gross payment can be applied correctly
Decline workflow	Staff know when to stop and contact payer
Refund workflow	Refunds tied to original transaction
PCI DSS controls	Cardholder data protected
CVV not retained	Sensitive authentication data removed after authorization
Customer economics reviewed	Margin and cash-flow effects measured
ACH alternative available	Customer payment choices documented
Processor pricing reviewed	Markup and gateway costs understood
Automated processing opportunity	STP considered where volume justifies integration

Questions to Ask Your Payment Processor

A processor should be able to explain how your actual commercial-card volume is handled.

Ask:

• How are commercial virtual cards priced on our account?
• Are our virtual card transactions classified as card-not-present?
• Do you support Level 2 commercial card data?
• Do you support Level 3 commercial card data?
• Which of our transactions are eligible for enhanced commercial-card qualification?
• Which fields must our integration send?
• Can we identify qualification or downgrade categories in reports?
• Can virtual-card processing be automated?
• Can payment data automatically match invoices?
• How are refunds to single-use credentials handled?
• What gateway and virtual-terminal fees apply?
• Can processor markup be reviewed based on our volume?
• Can VCC transactions be reported separately?
• What settlement data can be exported to our ERP?
• How should we securely receive and process the credentials?

Questions to Ask AP Automation Customers

The customer relationship matters just as much as the merchant-processing relationship.

Ask the buyer:

• Why are we being moved to virtual-card payment?
• Is ACH still available?
• How will remittance advice be delivered?
• Is each VCC associated with one invoice?
• Can one card cover multiple invoices?
• Is the payment amount restricted?
• How long is the credential valid?
• What should we do if the card declines?
• Who owns payment exceptions?
• How are duplicate payments resolved?
• How are refunds coordinated?
• Can payment terms be adjusted based on the selected rail?
• Can higher-value invoices be paid differently?
• Is automated processing supported?
• Who should our AR team contact when remittance is incomplete?

These conversations are more useful when supported by actual transaction data rather than assumptions about card economics.

Frequently Asked Questions

What is an AP automation virtual card?

An AP automation virtual card is a digitally generated card credential used within a buyer’s accounts-payable workflow to pay an approved supplier obligation. The credential is typically linked to a commercial-card program and may contain controls on amount, usage, merchant, or validity depending on the issuer and platform.

The supplier processes it through an eligible card-acceptance channel and then reconciles the resulting settlement with the corresponding invoice and remittance information.

What is a single-use virtual card number?

A single-use virtual card number is a digitally generated credential designed for a limited transaction or payment purpose. It may be connected to one invoice, one supplier, an approved amount, or a defined validity period.

Exact restrictions differ by issuer and AP automation platform, so suppliers should not assume every temporary virtual credential follows identical rules.

How do suppliers accept virtual card payments?

Suppliers typically receive payment instructions through a secure AP portal, approved message, or integrated workflow and process the credential through a virtual terminal, payment gateway, ERP integration, or automated virtual-card system.

The supplier should confirm the customer, invoice, amount, and remittance information first, then record the transaction reference and reconcile settlement to the invoice.

Are virtual card payments considered card-not-present?

When the supplier receives virtual card credentials remotely and enters or submits them without physical card presentation, the payment is generally processed as a card-not-present transaction.

Typing a virtual card into a browser-based virtual terminal does not make the payment card-present. The processing environment can affect pricing, fraud controls, and interchange qualification.

Why can keyed virtual-card transactions cost more?

Keyed AP automation card payments can involve card-not-present commercial-card interchange, network charges, processor markup, gateway expenses, and manual staff work.

The cost depends on card product, network rules, merchant category, transaction data, clearing timing, processor configuration, and other factors. There is no single universal “keyed virtual card fee.”

What are Level 2 and Level 3 data for virtual-card payments?

Level 2 and Level 3 refer to enhanced commercial transaction information that can accompany eligible card payments.

Level 2 commonly adds commercial summary data, while Level 3 can add more detailed purchase and line-item information. Required fields and qualification criteria vary by network, processor, card type, and program.

Can Level 3 data reduce virtual-card processing costs?

Correct Level 3 data may help certain eligible commercial transactions qualify for different interchange categories, but savings are not guaranteed.

The merchant must have compatible gateway or processor technology, submit required information correctly, and satisfy the relevant network and card-product criteria. Suppliers should have their processor analyze actual commercial-card volume before estimating a financial benefit.

Who receives the rebate on an AP virtual-card program?

Commercial-card rebates or incentives are commonly structured within the buyer’s cardholder or AP program.

The supplier accepting the payment does not automatically receive the buyer’s rebate. Issuer, AP provider, card program, spend, contract, and other factors determine the buyer’s economics.

Can suppliers negotiate virtual-card rebates?

A supplier generally should not assume it can claim part of the buyer’s card rebate.

More practical negotiations may concern payment method, ACH alternatives, payment terms, faster-payment arrangements, invoice size, product pricing, processor markup, Level 2/3 enablement, automation, or other mutually agreed commercial terms.

Can a supplier refuse virtual-card payments and request ACH?

That depends on the supplier’s customer agreement, commercial relationship, payment terms, and buyer policy.

Suppliers can ask whether ACH remains available and negotiate payment methods before agreeing to new terms. Major customers may have standardized AP programs, so the supplier should evaluate both the customer relationship and the financial impact before deciding.

Is ACH cheaper than accepting a virtual card?

ACH frequently has a lower direct transaction cost than percentage-based card acceptance, particularly for large B2B invoices, but that is not a universal total-cost conclusion.

The supplier should also consider ACH platform costs, returns, reconciliation effort, collection timing, staff labor, and customer requirements. The best rail depends on actual account economics.

How do suppliers reconcile virtual cards to invoices?

The strongest workflow links invoice number, customer, purchase order, gross card amount, processor transaction ID, remittance reference, settlement batch, processing fee, and net deposit.

One-card-per-invoice payments can be easy to match. Payments covering multiple invoices require reliable remittance advice or automated cash-application logic.

What happens if a single-use virtual card declines or expires?

First verify the invoice, amount, credential details, processing attempt, and buyer instructions. A card could decline because of an amount mismatch, expiration, prior use, merchant restriction, issuer decision, or another operational reason.

Avoid repeated blind attempts. Contact the customer’s AP team or the relevant platform when the issue cannot be safely resolved.

How should a refund be handled on a virtual card payment?

A refund should normally be linked to the original transaction and handled through the supplier’s processor or acquirer using the applicable network process.

Do not send a refund to an unrelated card merely because the original VCC appears expired or single use. Escalate unusual refund cases through the processor and verified buyer contact.

Are virtual card numbers subject to PCI DSS?

Virtual card credentials remain payment account data and should be protected through appropriate PCI DSS controls.

Suppliers should minimize retention and access, use approved payment systems, avoid card-number spreadsheets and screenshots, and never store CVV or other prohibited sensitive authentication data after authorization.

Conclusion

Accepting Virtual Cards From AP Automation Platforms can improve electronic payment speed, reduce reliance on checks, strengthen remittance workflows, and support highly controlled B2B payment processes. For buyers, virtual cards can also fit AP automation, procurement controls, working-capital strategies, and commercial-card programs.

For suppliers, however, successful authorization is only the beginning.

A virtual card payment may introduce card-not-present processing costs, commercial-card interchange considerations, gateway charges, manual keyed-entry work, reconciliation requirements, and refund or decline procedures that did not exist when the customer paid by ACH or check.

The supplier should therefore measure the complete economics:

Processing Fees + Internal Labor + Reconciliation Cost + Collection Timing + Exception Cost + Customer Relationship Value

Level 2 and Level 3 commercial data may improve qualification for eligible transactions, but the required fields and outcomes depend on current network and processor rules. Suppliers should verify capabilities and actual transaction results rather than assuming guaranteed savings.

Rebate discussions require similar discipline. Buyers may receive incentives through their commercial-card or AP programs, but suppliers should not assume they automatically share those rebates. 

Negotiating processor pricing, payment terms, faster-payment arrangements, ACH alternatives, invoice thresholds, enhanced-data processing, or automation is usually more realistic.

Finally, virtual card security deserves the same seriousness as other card payment environments. Credentials should move through secure systems, employee access should be limited, unnecessary card data should not be retained, and CVV must not be stored after authorization.

The best virtual card strategy is neither “accept every VCC without question” nor “force every customer to ACH.” It is a customer-by-customer payment policy built on measurable processing costs, reliable remittance, secure automation, faster cash application, and sustainable B2B economics.

This article is for general payments, financial, operational, and contractual information only. Payment-network requirements, interchange programs, processor pricing, AP platform functionality, tax treatment, surcharge rules, and applicable laws can change or vary by transaction and jurisdiction. 

Businesses should confirm current requirements with their processor, acquirer, card network, financial institution, AP provider, accounting adviser, and legal counsel where appropriate.