Corporate Expense Management with Virtual Cards: A Practical Guide

This guide outlines the transition from legacy payment systems to API-driven virtual card issuance, focusing on technical implementation, spend controls, and compliance for UK and European businesses.

Building a corporate virtual card programme gives finance teams authority over every pound spent. By moving away from physical cards and manual processes, CFOs at UK Fintech companies can stop payment delays and fraud exposure. Programmable spending lets organisations skip the manual workload of traditional expenses. Finance managers now monitor live budgets and settle vendor invoices without month-end stress. This transition creates a scalable infrastructure where every transaction follows company policy immediately.

What is a corporate virtual card programme?

A corporate virtual card programme is a centralised system for issuing, managing, and controlling digital payment credentials across an organisation. 

Unlike physical corporate cards, virtual cards exist only as data: a 16-digit number, expiry date, and CVV, created programmatically via API, assigned to specific cost centres, and cancelled the moment a transaction completes.

Programmability is the point. Finance teams define spending rules at the point of issuance, connect card data directly to ERP or accounting platforms, and receive real-time transaction alerts, all without touching a physical object or waiting for a monthly statement. This separates a modern programme from a standard prepaid card scheme: the card is a programmable spending policy, expressed as an API call.

Why are finance teams moving away from traditional corporate cards?

The case against traditional card programmes is now data-driven, not theoretical. According to UK Finance’s Annual Fraud Report 2025, total fraud losses on UK-issued cards reached £572.6 million in 2024, with remote purchase fraud cases rising 22 per cent year-on-year, the largest single driver across all card fraud categories. Physical cards, once issued, carry fixed credentials that are difficult to contain once exposed.

Beyond fraud, legacy card programmes create reconciliation complexity. Employees submit expense reports manually, finance teams chase receipts, and ERP systems receive data days or weeks after the spend occurs. For SaaS businesses managing dozens of software subscriptions or Fintech companies running high-volume vendor payments, this lag is operationally corrosive.

Virtual cards address both problems structurally. Credentials are disposable, spend parameters are pre-set, and transaction data flows directly into your systems through webhooks or API calls.

Further Reading: Best Virtual Card Platforms in Europe (2026)

How does API-first card issuance work in practice?

API-first card issuance means every card, from creation to cancellation, is controlled programmatically through REST or GraphQL endpoints. There is no manual portal step, no waiting for a card to arrive in the post, and no human intervention required between a business event (a new vendor onboarded, a project budget approved) and a card going live.

An issuance flow works as follows: your internal system sends a POST request to the card issuing platform with parameters including cardholder ID, spend limit, currency, expiry, and permitted MCCs. The platform responds with card credentials within milliseconds. Those credentials can be immediately tokenised for a digital wallet, stored securely in a vault, or transmitted directly to a vendor, all without human involvement.

Q&A: Can I restrict cards by merchant category code (MCC)? 

Yes. Most API-first issuing platforms allow you to whitelist or blacklist specific MCC ranges at the card level. For example, you might issue a card restricted to MCC 7372 (prepackaged software) for SaaS subscription renewals, or block MCC 5812 (eating places) entirely on operational expense cards. These controls are set at issuance and can be updated in real time via API.

What spending control mechanisms should a programme include?

Spend control is the operational core of any corporate virtual card programme. The goal is to move spending policy out of a PDF handbook and into the payment infrastructure itself, so that the card cannot be used outside the parameters you have defined.

Effective spend control mechanisms include:

• Per-transaction limits: Cap the maximum value of any single transaction at the card level, preventing both accidental overspend and deliberate misuse.
• Velocity controls: Restrict how many transactions can occur within a given time window, daily, weekly, or monthly, regardless of individual transaction size.
• Currency restrictions: Limit cards to specific currencies to prevent cross-border spend on cards designated for domestic use.
• Expiry scheduling: Set automatic expiry dates so that single-use vendor cards become invalid after a payment clears, eliminating dormant credential risk.
• Real-time freezing: Suspend or cancel a card instantly via API if a transaction pattern looks anomalous or a vendor relationship ends.

The December 2025 joint EBA-ECB Report on Payment Fraud found that card payment fraud losses across the EU/EEA reached €1.329 billion in 2024, a 29 per cent year-on-year increase. Critically, card fraud was 17 times higher when the payment recipient was outside the EEA, where Strong Customer Authentication is not legally required. A well-configured virtual card programme with per-card MCC controls and single-use credentials is structurally positioned to address exactly this exposure.

Q&A: What happens to unused cards?

Unused cards with open-ended expiry dates are a latent security risk. Best practice is to set maximum card lifetimes at issuance, aligned to the duration of a project, contract, or budget period. Many API-first platforms allow you to configure auto-cancellation rules triggered by inactivity periods, meaning cards that have not transacted within a defined window are closed automatically without manual intervention.

How does real-time expense tracking change financial operations?

Real-time expense tracking transforms the finance function from a backwards-looking reconciliation exercise into a forward-looking spend management operation. When every virtual card transaction triggers an immediate webhook to your ERP or expense platform, finance teams see spend as it happens, not when the month-end report arrives.

The operational benefits compound. Accruals become more accurate. Budget burn rates are visible in dashboards rather than spreadsheets. Anomalous transactions, a card used at an unexpected merchant, a charge in an unexpected currency, generate alerts within seconds rather than surfacing in a statement weeks later.

For SaaS businesses where subscription renewals, platform fees, and API usage charges are frequent and variable, real-time tracking provides the precision needed to understand the true cost of goods sold at the product level. Assigning virtual cards to specific products, teams, or cost centres means that spend data arrives in your systems pre-coded, dramatically cutting the manual allocation work that consumes finance team hours.

Further Reading: API architecture: how to integrate Wallester card issuance in your tech stack

What are the compliance requirements for virtual card programmes in 2026?

The compliance framework governing corporate virtual card programmes in the UK and EU has tightened considerably in 2026. Programmes operating across European entities need to satisfy requirements across several overlapping regulatory domains.

One area that catches programmes out is the treatment of card programmes under the e-money regulatory framework. If your programme involves pre-loading funds onto virtual cards, the issuing entity may require an e-money licence under the UK Electronic Money Regulations 2011 or equivalent EU frameworks. Partnering with a licensed issuer, rather than building issuance infrastructure in-house, is the most direct path to compliance without the overhead of direct authorisation.

The EBA-ECB fraud report also confirms that SCA-authenticated transactions carry materially lower fraud rates than non-SCA transactions across all payment categories. For corporate card programmes, this reinforces the value of building authentication controls into the issuance workflow, not treating them as an afterthought.

How does Wallester support API-first card programme infrastructure?

Wallester is a licensed e-money institution operating under the Estonian FSA, with full passporting rights across the European Economic Area. For Fintech and SaaS businesses building corporate virtual card programmes, Wallester’s infrastructure addresses the core technical and regulatory requirements without requiring you to build card issuance capability from scratch.

The Wallester API covers the complete card lifecycle: create a card, set spend controls, retrieve transaction data, and cancel credentials, all through documented REST endpoints. Card issuance is near-instantaneous, with new virtual cards available for use within seconds of an API call. For businesses operating high-velocity workflows, onboarding new vendors, funding project budgets, or running employee expense programmes at scale, this speed has direct operational value.

Comparing API-based issuance with traditional banking card programmes:

For European entities specifically, Wallester’s EEA authorisation means businesses incorporated in EU member states can access card issuance through a single commercial agreement, without navigating individual country-by-country banking relationships. Onboarding is API-driven, documentation is in English, and go-live timelines are measured in weeks rather than quarters.

If you are evaluating card issuance infrastructure for your corporate expense programme, Wallester’s developer documentation and enterprise onboarding team are worth a conversation.