Virtual Cards for UK Businesses: Control Spending and Automate Payments

How virtual card issuing works

Virtual card issuing creates digital payment credentials, typically a card number, expiry date and security code, without producing a physical card. A provider issues these credentials directly or through an issuing partner, linking them to a business funding account or an agreed credit facility. Depending on the product, purchases draw on a prefunded balance, debit an account or become repayable under credit terms. Creating a virtual card does not itself provide credit.

Issuing the card and making a payment are separate steps. Once the card is active and sufficient funds or available credit exist, an employee or authorised system can use its credentials with a merchant. Employees can enter the details online or, where the provider supports it, add the card to a compatible digital wallet for contactless payments.

The merchant's payment provider routes an authorisation request through the card network to the issuer. Approval normally reserves the purchase amount; capture and settlement subsequently complete the financial transaction. An approved authorisation therefore does not mean the supplier has already received the money. If an authorisation expires or is reversed before capture, the reserved funds are released without a completed payment.

Businesses can use different card types for different purchasing needs:

• Single-use cards: Intended for one payment, such as an employee purchase or a supplier invoice. Check how the provider defines successful use, particularly where a merchant splits an order into several charges.
• Reusable cards: Support multiple payments, making them suitable for ongoing employee expenses, repeat supplier purchases or subscriptions. A dedicated subscription card can keep one recurring payment relationship separate from other expenditure.

Availability and operating rules vary by provider; do not assume every UK programme supports both types.

The delivery model also matters. A managed expense platform gives finance teams a ready-made interface for requesting, issuing and administering cards. A virtual card API lets developers embed those actions into existing purchasing, accounts payable or enterprise resource planning systems. The API connects business software to the provider's issuing infrastructure; it does not make the business the card issuer. Some providers offer both approaches.

Virtual cards remain card payments and require the supplier to accept the relevant card network and payment method. They cannot automatically replace bank transfers or Direct Debit mandates: a supplier requesting payment to a bank account must agree to accept a card instead. Establish which expenses and invoices are eligible before deciding how to allocate cards and apply spending controls.

Control spending before payments happen

Use virtual cards to turn an approved budget into payment credentials with explicit rules. Instead of issuing one shared corporate card, create a card for a person, supplier, subscription, project or purchase order. Link it to the correct legal entity, funding source, cost centre and accountable owner before the number is released. Coordinate individual card limits with shared departmental, project and company budgets so multiple cards cannot independently draw on the same remaining allocation.

Configure controls from the underlying commercial decision. A purchase-order card might allow one merchant, one currency and a maximum total amount until an expiry date. An employee travel card might have a daily limit, permitted merchant categories and a defined travel period. A subscription card can be reusable but restricted to the named supplier and an expected monthly amount. Single-use credentials are useful where the provider and merchant flow support them, but they are not suitable for every recurring or delayed-capture transaction.

Make issuance conditional on an approval record. The request should include purpose, supplier, expected amount, currency, evidence and approvers. Apply the existing delegation-of-authority matrix, segregation of duties and enhanced approval for unusual merchants, new bank or supplier relationships, high values or sensitive categories. Do not let an API caller bypass policy merely because card creation is technically instant.

Maintain clear lifecycle states such as requested, approved, issued, active, suspended, expired and cancelled. Changes to limits, merchant rules or owners should be logged with the previous value, reason and approver. Require stronger approval when a change increases exposure. Automatically suspend unused cards, cards linked to departed employees and credentials associated with a closed project or supplier. Suspension or cancellation does not necessarily prevent an already authorised purchase from being captured, so continue monitoring outstanding authorisations.

Use authorisation events to show attempted spend in near real time, but distinguish an authorisation from a final cleared transaction. Hotels, travel merchants and other businesses may use deposits, incremental authorisations or delayed capture. Tips, foreign-exchange differences and offline processing can also make the final amount differ. Define tolerance and exception handling instead of assuming a precise authorisation always equals the final expense.

For shared-budget tracking, reserve pending authorisations and replace those reservations with cleared amounts without double-counting. Define when reversed holds and refunds restore available budget, and check whether the provider restores card limits in the same way. Confirm when periodic limits reset and how outstanding authorisations carry across periods.

Card controls reduce risk but do not replace supplier due diligence, invoice review, fraud monitoring or accounting controls. Merchant category data can be broad or inaccurate, and a merchant may not accept virtual credentials. Document what happens when a legitimate payment is declined, including who can grant a temporary override and how quickly the exception is reviewed.

Monitor declined attempts, limit changes, dormant cards, unusual merchant activity and spend outside expected periods. Review whether each control prevents real exceptions without creating excessive operational work. The objective is to reduce unauthorised or out-of-policy spending and maintain an auditable link between purchases and approved budgets.

Automate payments and reconciliation

Connect virtual card issuance to the approved accounts-payable or expense workflow so payment credentials are created from trusted business data. A typical supplier flow begins with an approved invoice or purchase order, generates a card with the required amount and restrictions, transmits the credentials through a secure channel, and records authorisation, clearing and settlement events against the original document.

Keep payment creation separate from approval. The ERP or procurement system should send the legal entity, supplier, invoice, currency, amount, due date, cost centre and approval reference. The card platform then applies policy and returns an internal card or payment identifier. Do not expose the primary account number in logs, email or general accounting fields. Where a supplier needs credentials, use a provider-supported secure delivery or payment method.

• Use one card per invoice, supplier or subscription when that structure improves matching and control.
• Set the limit to the approved amount plus only a documented tolerance for tax, tips or foreign exchange.
• Schedule activation and expiry around the payment date rather than leaving credentials open indefinitely.
• Cancel or suspend the card when the invoice is withdrawn, duplicated or paid through another rail, and investigate any outstanding authorisations.

Reconciliation should use lifecycle data, not only a bank debit. Match the approved document to the card, authorisation, presentment, clearing entry, fee and funding movement. Store the provider transaction ID, merchant name, amount, currency, timestamps and status alongside the internal invoice and ledger references.

Under accrual accounting, recognise the underlying expense or asset and supplier payable when the relevant recognition criteria are met, independently of card clearing. Record settlement of the supplier payable separately, against the prefunded balance, bank account or card-provider liability as appropriate. Any later repayment to the card provider settles that liability without recording the expense again.

Design for partial captures, multiple presentments, tips, foreign-exchange differences, reversals and refunds. A supplier may clear less than the authorised amount or split fulfilment across several transactions. Keep unmatched value in an exception queue with a reason, owner and ageing deadline.

Prevent the same invoice from being paid by card and bank transfer by marking it as committed to the payment workflow. Card cancellation or a failed workflow status alone does not prove that payment cannot still clear. Before allowing payment through another method, resolve uncertain outcomes and outstanding authorisations with the provider and supplier.

For subscriptions, assign a reusable card to the specific supplier, set a periodic limit and compare each cleared amount with the contract. Alert on price changes, unexpected frequency, duplicate charges or use after cancellation. Rotate or replace credentials without losing the supplier and ledger relationship.

Measure straight-through reconciliation, manual touches, declined payments, duplicate-prevention events, time from approval to payment and unresolved value. Virtual cards can automate suitable card-accepting suppliers, but they do not replace every bank transfer or Direct Debit. Route each obligation through the payment method that the supplier accepts and that provides the required cost, timing and control.

Integrate a virtual card API reliably

Place an internal card service between business workflows and the issuing provider. The ERP, expense platform or procurement application should request a business action such as "create a supplier card for invoice 4817", while the card service validates approval, applies policy and translates the request to the provider API. This prevents provider-specific fields and credentials from spreading through finance systems.

Complete provider onboarding before development is treated as production-ready. Confirm the contracting entity, funding or credit arrangement, supported card programmes, currencies, countries, merchant controls, transaction limits and production approval process. A sandbox can demonstrate request shapes but does not prove that a particular UK entity, use case or spending pattern will be approved.

Use stable internal identifiers for cardholders, suppliers, cards, approvals and transactions, and store the corresponding provider IDs. Do not use a card number as the primary system key. Keep sensitive card data out of logs, analytics, support tickets and ordinary databases. Prefer provider-hosted display or secure reveal components so only authorised users and systems can access credentials.

Make every operation that can create or move value idempotent. Generate the key from the internal business action and reuse it after a timeout or safe retry, subject to the provider's idempotency rules. Before creating another card, query the original request or provider object. A lost response may hide a successful issuance, and a blind retry can create duplicate credentials or duplicate supplier payments.

Maintain a persistent payment record for each invoice, including any authorised instalments, so duplicate prevention survives API retries and provider idempotency expiry. Resolve uncertain outcomes and outstanding card exposure before retrying payment or switching to a bank transfer.

Model the lifecycle explicitly. A request can be pending, approved, issued, active, suspended, cancelled, expired or failed; a transaction can be authorised, reversed, cleared, refunded or disputed. Permit only valid transitions and retain an append-only event history. Map provider statuses to internal states while preserving original status values and only the payload fields permitted for retention. Apply redaction, restricted access and defined retention periods.

Verify webhook signatures or certificates and check timestamps where supported. For event notifications, durably store or queue each valid event before acknowledging successful receipt, then process it asynchronously. Assume duplicates and out-of-order events. Use polling to recover stale pending items and confirm financially material states, while respecting rate limits. Send messages that cannot be processed to a dead-letter queue with an owner and retry policy.

Handle real-time authorisation callbacks separately: return an approval or decline within the provider's required deadline. Document what happens on timeout or service failure, configure fallback rules where supported, and assign responsibility for the resulting risk. Monitor response latency, missed deadlines and fallback decisions.

Test normal and adverse paths: declined issuance, duplicate requests, limit breaches, partial clearing, refunds, expired cards, credential rotation, webhook delay, provider outage and funding shortfall. Use contract tests against provider versions and monitor deprecation notices. Track latency, error classes, stale states, webhook failures and reconciliation breaks.

Set recovery-time and data-loss objectives. Test restoring internal records from backups, replaying retained events without duplicate effects and reconciling against provider records before normal processing resumes.

Finally, design an exit route. Document how card and transaction data can be exported, what cannot be migrated, how open authorisations and refunds will be handled, and how credentials will be cancelled. A reliable integration protects sensitive data, prevents duplicate effects and preserves a recoverable transaction history that reconciles to finance records.

Address UK regulatory, security and data requirements

Identify the legal roles before launching a virtual card programme. In the UK, issuing payment instruments is a payment service, and a prepaid structure may also involve electronic money. The regulated issuer may be a bank, authorised payment institution or electronic money institution, while the business operates the expense workflow or embeds the provider's API. Using an API does not transfer the issuer's permissions to the business or automatically make the business the regulated issuer.

Check the contracting legal entity and its current permissions on the FCA Financial Services Register. Confirm which entity issues the card, holds prefunded money or extends credit, performs customer due diligence, handles complaints and reports incidents. If the business will act as an agent, distributor, programme manager or outsource a material function, document the arrangement and obtain specialist perimeter advice. Credit offered to individuals or other protected recipients may create additional consumer-credit requirements.

Understand how money is protected. Authorised payment institutions and electronic money institutions must safeguard relevant customer funds under the applicable rules; small payment institutions can opt into safeguarding. Safeguarding differs from the Financial Services Compensation Scheme protection associated with eligible bank deposits. Ask where prefunding is held, when funds become available, how shortfalls and insolvency are handled, and which party performs reconciliation. Do not describe a safeguarded account as a bank account unless it is one.

Additional FCA safeguarding requirements took effect on 7 May 2026, covering reconciliation, reporting, audits and resolution packs. Obtain evidence of the provider's compliance where applicable. These provider obligations do not automatically apply to an ordinary business customer using its cards.

PCI DSS applies to primary account numbers that represent participating payment brands, including electronic-only virtual PANs. Single-use credentials do not automatically remove the standard. Reduce exposure by using provider-hosted card display, tokenisation and masked references, and confirm the applicable PCI validation route with the issuer or card programme. Never place full credentials in email, chat, logs, analytics or ordinary ERP fields.

Confirm how the issuer applies Strong Customer Authentication and any permitted exemptions to relevant electronic transactions. A corporate card is not automatically exempt: the secure corporate-process exemption requires dedicated processes or protocols available only to non-consumer payers and FCA satisfaction that they provide equivalent security. Recurring payments and merchant-initiated transactions can follow different rules and evidence requirements. The integration must pass accurate cardholder and transaction data, support challenges where required, and avoid labelling a transaction merely to bypass authentication.

Employee, supplier and transaction records are personal data where they identify people. Define controller and processor roles, processing purposes, the applicable lawful basis, access, retention and deletion under UK GDPR. Put the required processor terms in place, review subprocessors, and assess whether transfers to separate organisations outside the UK are restricted transfers requiring an approved mechanism. Provide employees with clear information about monitoring and do not retain detailed spend data without a business need. Assess whether a data protection impact assessment is required.

Assign responsibility for assessing personal-data breaches. Controllers must report notifiable breaches to the ICO without undue delay and, where feasible, within 72 hours of awareness; processors must notify the controller without undue delay. Include these responsibilities in the incident-response process alongside issuer notification.

Complete legal, information-security and finance sign-off against the actual money and data flows. Certifications and provider assurances are evidence, not a substitute for secure configuration, tested controls and an allocation of responsibility that the business can operate.

Choose a solution and pilot the rollout

Choose between a managed expense platform and a virtual card API by deciding where the business wants control. A managed platform can provide cardholder onboarding, approvals, mobile access, receipt collection and accounting exports with less development. An API is better suited to embedding issuance inside an existing procurement, supplier-payment or product workflow, but it makes the business responsible for integration, operations and user experience.

Give shortlisted providers the same fact pack: UK legal entities, use cases, cardholders, suppliers, currencies, expected cards and transactions, average and peak values, funding preference, accounting systems and launch timetable. Ask for written confirmation that the business model, merchant categories and countries are eligible. Sandbox access or a sales demonstration is not approval for a production card programme.

Calculate total cost for the intended workflow. Include implementation, security review, ERP integration, card and transaction fees, foreign exchange, funding cost, support, manual exceptions and ongoing maintenance. Apply any rebate or reward only if it is contractually available at the expected mix and volume. Compare the cost with time saved, duplicate payments prevented, improved budget compliance and faster reconciliation; do not treat gross card spend as a benefit.

Confirm that pilot suppliers accept the proposed commercial card and disclose any additional charges. Check how they receive and process credentials, match payments to invoices and handle refunds. Include manual supplier processing in the assessment of cost and time saved.

Run a narrow pilot with one legal entity, one use case and a controlled group of employees or suppliers. Select transactions that are representative but financially limited. Define success before launch: issuance time, supplier acceptance, authorisation rate, policy declines, manual approvals, reconciliation match rate, accounting close time, user support and unresolved value. Include a control group or baseline from the current process.

Turn these metrics into agreed go/no-go thresholds, including a minimum reconciliation match rate and maximum unresolved value and age. Name the people authorised to approve expansion, pause the pilot or trigger rollback. Define rollback conditions, such as duplicate payments, a material security incident or reconciliation failures exceeding the agreed tolerance.

1. Complete legal, security, data-protection, finance and procurement approval.
2. Configure roles, limits, merchant restrictions, funding and emergency suspension.
3. Test issuance, secure credential access, authentication challenges, authorisation, clearing, refund, dispute and cancellation.
4. Verify that authorisation reversals and refunds receive different accounting treatment, and test capture of outstanding authorisations after card cancellation.
5. Test duplicate requests, delayed webhooks, provider outage, expired cards and reconciliation breaks. Resolve uncertain payment outcomes before allowing fallback to bank transfer.
6. Train users and support teams, publish the exception route and test a rollback plan that preserves tracking of outstanding transactions.
7. Review at least one complete statement or funding cycle and confirm the agreed go/no-go criteria before expanding.

Do not judge the pilot only by successful authorisations. Investigate legitimate declines, merchants that reject virtual cards, incorrect merchant-category blocking, unmatched presentments, foreign-exchange differences and cards left active after their purpose ends. Confirm that finance can reproduce the balance and every accounting entry from provider records.

Expand in stages by use case, entity or spend category. Keep change approval for limits and routing, monitor inactive cards and overrides, and review provider performance against service levels. Maintain an exit plan covering data export, outstanding authorisations, refunds, disputes and credential cancellation. The preferred solution is the one that delivers preventive control and reliable reconciliation at an operating cost the business can sustain.