Virtual cards are getting smarter.
That is good.
Your controls better not stay dumb.
Mastercard recently announced enhancements to its virtual card platform, including new security controls, an embedded payments network, and single API access for enterprises, financial institutions, and platforms. Mastercard said the new controls are designed to help reduce risk across the payment lifecycle and give businesses more confidence, flexibility, and efficiency in managing payments. Mastercard’s virtual card platform announcement is available here.
That is a useful signal.
Virtual cards are not just a corporate travel trick anymore. They are moving deeper into B2B payments, procurement, supplier payments, accounts payable automation, embedded finance, platform payouts, insurance payments, healthcare payments, marketplaces, and software-driven payment workflows.
That makes sense.
Virtual cards can give companies more control than traditional card payments. They can be issued for specific suppliers, invoices, amounts, time windows, categories, or use cases. They can reduce exposure compared with sharing static card credentials. They can be embedded into workflows. They can improve visibility. They can support automation. They can make B2B payments less dependent on manual processes that feel like they were designed during a printer shortage.
Lovely.
But a smarter card number does not automatically create a smarter control environment.
If the workflow around the virtual card is sloppy, the payment rail will not save you.
It may just make the mess move faster.
Virtual cards are often described as a control mechanism.
That is fair.
A virtual card can limit where funds are spent. It can limit how much can be spent. It can expire after a certain period. It can be tied to an invoice, supplier, purchase order, employee, department, or platform event. It can reduce the need to expose a reusable card number across multiple vendors.
Those are real advantages.
But the virtual card is only one control inside a larger process.
Who can request it? Who can approve it? Who sets the limit? Who changes the limit? Who decides which supplier gets paid by virtual card? Who verifies the supplier? Who reconciles the payment? Who handles declines? Who reviews exceptions? Who monitors unusual usage? Who has authority to override controls?
If those questions are not answered clearly, the virtual card is not your control environment.
It is just the most modern-looking part of it.
B2B payments are not always risky because the rail is risky.
They are risky because the workflows around them are messy.
Vendor onboarding happens in one system. Purchase approvals happen in another. Payment files get generated somewhere else. Supplier bank details change through email. Exceptions get handled in Slack. Accounting reconciles after the fact. Procurement has a policy. AP has a workaround. Treasury has concerns. The platform has an integration.
Everyone technically participated.
Nobody fully owns the risk.
Virtual cards can help simplify parts of this environment, especially when embedded into procurement or payment platforms. But they do not eliminate the need for role clarity, approvals, vendor controls, and reconciliation.
A virtual card can prevent a supplier from charging more than the allowed amount.
It cannot tell you whether the wrong supplier was approved in the first place.
It can restrict a transaction to a merchant category.
It cannot tell you whether a fraudulent email convinced someone to change where the payment should go.
It can expire after use.
It cannot fix a procurement process that treats every exception like a creative writing exercise.
The rail can help.
The process still matters.
Virtual cards become especially interesting when they are embedded into software workflows.
That is also when they become more complicated.
If an ISV, procurement platform, marketplace, travel platform, AP automation tool, or embedded finance provider can generate virtual cards through an API, the payment experience can become faster and cleaner. A user approves a purchase, the system generates a card, the supplier gets paid, the transaction maps back to the invoice, and everyone pretends payments are finally civilized.
That is the happy path.
The real question is what happens outside the happy path.
What happens when a card is issued for the wrong amount? What happens when the supplier cannot accept it? What happens when the charge declines? What happens when the invoice changes? What happens when the card is used by the wrong merchant? What happens when the transaction posts late? What happens when the supplier refunds only part of the amount? What happens when a user overrides the control? What happens when the platform logic issues a card without the approval the policy required?
Embedded payments are powerful because they hide complexity.
They are dangerous for the same reason.
If the software workflow becomes the control layer, then the software workflow needs to be designed like a control layer. That means audit trails, approvals, permissions, exception handling, data retention, reconciliation, and clear operational ownership.
Otherwise, the platform is just automating confusion.
Virtual cards can make payment execution cleaner.
They do not eliminate reconciliation.
Finance still needs to match the virtual card transaction to the purchase order, invoice, supplier, approval, department, general ledger account, and settlement record. They still need to handle partial payments, refunds, credits, declines, adjustments, timing differences, fees, and duplicate attempts.
B2B payment reconciliation is where confidence goes to die if the data model is weak.
A virtual card transaction can carry useful metadata, but only if the system captures, preserves, and maps it correctly. If the card is generated in one platform, charged through another, settled through an issuer or processor, and reconciled in an ERP, the data needs to survive the trip.
If it does not, the business gets a familiar ritual.
Finance downloads reports.
Someone exports CSV files.
Someone compares columns.
Someone says the system should have matched this automatically.
Someone else creates a spreadsheet called virtual_card_recon_final_final_use_this_one.xlsx.
The future of payments, apparently.
Strong virtual card programs think about reconciliation before launch, not after the first month-end close makes everyone reconsider their career choices.
Advanced controls are only useful when they are understood and configured correctly.
Spending limits, merchant restrictions, expiry windows, supplier controls, approval rules, card-use restrictions, and velocity settings all sound great. But controls can be too loose, too tight, incorrectly mapped, poorly monitored, or overridden so often that the exception becomes the actual process.
A limit that is always increased is not a limit.
An approval that happens after the card is issued is not much of an approval.
A supplier restriction that can be bypassed through manual processing is not a supplier control.
An exception queue nobody reviews is not an exception queue.
It is a risk landfill.
The more powerful the virtual card platform becomes, the more important governance becomes. Someone needs to know what controls exist, why they were configured that way, who can change them, how changes are approved, how exceptions are reviewed, and whether the controls are still appropriate as the business grows.
Controls are not decorations.
They are operating commitments.
Virtual cards can reduce certain fraud risks.
They do not eliminate fraud.
Bad actors adapt. They may target vendor onboarding. They may manipulate payment instruction changes. They may compromise user accounts. They may create fake suppliers. They may exploit weak approval workflows. They may socially engineer employees. They may abuse refunds, credits, or exceptions. They may identify places where the virtual card control ends and the human workaround begins.
That last place is usually where the good stuff is.
Fraudsters love controls that look strong on paper but collapse when someone says "urgent."
Virtual card programs need monitoring. Not just decline monitoring. Real monitoring. Unusual card issuance patterns. Repeated limit increases. New suppliers receiving high-value cards. Cards used outside expected timing. Supplier disputes. Refund anomalies. User behavior changes. Approver overrides. Concentration by department, vendor, or card requester.
A virtual card is not the end of fraud strategy.
It is another signal source.
Use it.
Virtual cards are getting smarter.
Good.
They can improve B2B payments, reduce credential exposure, support embedded workflows, add useful controls, and make payment execution cleaner.
But a smarter rail does not fix a sloppy process.
If your approval workflow is weak, your vendor controls are vague, your reconciliation is fragile, your exception handling is improvised, or nobody knows who owns the payment after the API call succeeds, virtual cards will not save you.
They will just give your messy process a better card number.
Payments Therapist helps ISVs, platforms, PayFacs, B2B payment companies, and embedded finance teams understand where payment products, controls, reconciliation, vendor dependencies, and operational reality do not line up.
Virtual cards can be powerful.
Just make sure the controls around them are not dumb.