Virtual card controls
Virtual card controls are programmable restrictions applied to virtual payment card credentials that govern where, when, how much, and for what purpose the card can be used. They enforce spend policy at the moment of transaction authorization rather than through post-hoc review.
Virtual cards become spend control instruments when configured with rules that the card network enforces at the point of authorization. These controls operate at the infrastructure level. When a merchant attempts to charge the card, the authorization request is evaluated against the card's configured rules in real time, and approved or declined within milliseconds.
The primary control dimensions include: merchant controls (restricting the card to specific merchant category codes, merchant IDs, or merchant countries); amount controls (setting per-transaction limits, daily limits, or total lifetime spend caps); temporal controls (restricting usage to specific dates or time windows, or creating single-use cards that expire after the first successful transaction); and currency controls (specifying which currencies the card can transact in).
For procurement and supplier payment use cases, virtual card controls enable a powerful workflow: a finance team creates a supplier-locked virtual card for exactly the invoice amount, with a validity window matching the payment terms. The supplier can only charge the card once, for only the specified amount, within the payment window.
Virtual card controls transform a payment instrument into a policy enforcement mechanism. By embedding spend rules into the card itself, organizations ensure compliance automatically at scale, without relying on employee adherence to policy guidelines or manual review of expense submissions.
- Control rule design must balance precision with operational practicality for cardholders
- Edge cases in MCC assignment can block legitimate spend if controls are too restrictive
- Control updates must propagate to card credentials in real time without disrupting transactions
- Multi-currency spend against fixed-amount controls requires FX handling
- Employee friction from declined transactions must be managed with clear escalation paths
A global procurement team managing 400 supplier relationships replaces purchase order check payments with supplier-locked virtual cards. Each PO generates a virtual card locked to the specific supplier, capped at the PO amount, and valid for 30 days. Duplicate invoice fraud drops to zero, payment reconciliation time reduces by 70%.
Related Concepts
Nium's card issuing API exposes granular spend control parameters at card creation and can update control rules on existing cards in real time. Spend management platforms build virtual card control workflows on Nium's infrastructure, generating supplier-locked or category-restricted cards programmatically and receiving real-time authorization webhooks.
Answers you didn't know you needed.
Can virtual card controls be updated after the card is issued?
Yes. Through Nium's card management API, control parameters (spend limits, MCC restrictions, validity periods) can be updated on issued virtual cards in real time. This enables dynamic policy adjustment without needing to cancel and reissue cards.
What happens when a virtual card control prevents a legitimate transaction?
When a transaction is declined due to a control rule, the cardholder receives a decline notification. The spend management platform can provide a resolution path: request a limit increase, expand MCC permissions, or issue a supplementary card, through its own workflow.
How do single-use virtual cards work for supplier payments?
A single-use virtual card is configured to authorize only one transaction before becoming permanently inactive. For supplier payments, this means the card can only be used to settle the specific invoice it was created for, preventing any subsequent charges on the same credentials.
What is a ghost card and how does it differ from a virtual card?
A ghost card is a card number assigned to a department or cost center for recurring purchases from a specific vendor, without being tied to an individual. A virtual card is typically single-use or short-lived and tied to a specific transaction or project. Both can be issued programmatically through Nium's API.
How do I configure virtual card controls through Nium?
Nium's Card Issuing API provides spend control configuration endpoints, allowing program operators to set and dynamically modify merchant category restrictions, amount limits, velocity controls, geographic restrictions, and time-based rules for virtual cards programmatically, in real time, without reissuing cards.