Virtual Cards

Single use, controls, tokenisation and business use cases

A credential with an operating lifecycle

A virtual card provides card credentials without requiring a physical card. It can be used for online purchases, supplier payments or employee spending. Funding may be debit, prepaid or credit according to the product. Virtual presentation does not determine the legal account, cardholder or liability arrangement.

Identify the issuer, processor, programme manager and relevant network or token services. The programme needs permissions for issuance, credential access, controls and servicing. An API response containing a card number is not evidence that every rule and downstream system is ready.

Controls act on defined transaction information

Amount, merchant, merchant category, geography, time and velocity controls generally influence authorisation decisions according to the programme's capabilities. Enforce them at the appropriate decision service rather than relying on the app screen. Version changes and confirm effective status.

A merchant category code describes the merchant category, not each item purchased. Allowing restaurants does not reliably enforce a rule against buying alcohol. Merchant identifiers can also differ across branches, channels and payment intermediaries. Test actual acceptance patterns and explain the control's limits.

Single use needs a precise meaning

Single use might mean one approved authorisation, one merchant or a limited amount and time envelope. These are different policies. Hotels, partial shipments, incremental authorisations, reversals and delayed clearing can create several related events for one purchase.

Define how those events consume and restore limits. Stopping future authorisations does not automatically reject every valid presentment or undo an existing obligation. Scheme, contract and product rules govern treatment, matching, disputes and any clearing controls; avoid a universal promise that all excess presentments either always post or always disappear.

Just-in-time funding also needs a defined financial effect. Some designs reserve funds; others post a transfer or use an approved credit arrangement. Assess stand-in decisions during outages, duplicate requests, concurrent spending and recovery. Reconcile approved exposure with holds and actual postings without pretending every design moves money onto a separate card account.

Tokens, sensitive data and lifecycle changes

EMVCo distinguishes constrained payment tokens from primary card numbers. A virtual card number is not automatically a network token. Inventory associated tokens and use the relevant lifecycle operations when suspending, replacing or closing credentials.

Minimise sensitive data in logs, exports and support tools. Determine actual PCI DSS scope; tokenisation or outsourcing does not provide an automatic exemption. PCI SSC's outsourcing guidance explains continuing responsibilities when processing is outsourced.

Fictional example: supplier payment

A firm authorises a virtual card for an invoice of 4,900 at a specified supplier. A second request for 50 arrives under a different merchant identifier. Investigate the actual decision and supplier terms. A correctly enforced merchant or amount rule does not decide whether the surcharge is commercially owed.

Match authorisations, clearing, adjustments and the invoice. Keep procurement disputes separate from credential compromise, while linking evidence where both matter. A declined repair-payment card likewise does not necessarily mean the insurance claim was refused.

Takeaway

Measure correct control decisions, unexplained reconciliation differences, legitimate declines and unresolved disputes. Virtual cards are useful when issuance, authorisation, financial records and servicing preserve the promised scope.

Continue to SME Digital Banking.