Authorisation flows in virtual card processing

This article walks through how authorisation requests move through the virtual card payment chain, from the moment a transaction is triggered to the response code that approves or declines it. It covers the roles of acquirers, card networks, and issuing processors, the controls that dictate authorisation decisions, and the practical details payment teams need to manage virtual card programmes effectively.

Virtual cards have given finance teams a level of transaction control that physical cards cannot provide. Every card can carry its own rules, every transaction can be scrutinised in real time, and every decline can be traced to a specific control rather than an ambiguous fraud flag. But none of that works without a solid authorisation flow underneath it all. Understanding how that flow operates, and where it can break down, matters whether you’re building a payment programme, integrating an API, or troubleshooting a wave of unexpected declines.

Further Reading: How Virtual Card Technology Works

What is an authorisation flow in virtual card processing?

An authorisation flow is the sequence of messages exchanged between a merchant, acquirer, card network, and issuing processor to verify and approve or decline a card transaction in real time. 

For virtual cards, this process is entirely digital: no chip is read, no PIN is entered, and every decision is made based on the data fields transmitted in the authorisation request message. The whole exchange follows the ISO 8583 financial transaction message standard, which defines how data is structured and routed across the payment network.

When a virtual card is used, say to pay a supplier via an online portal, the merchant’s payment gateway packages the transaction details into an authorisation request and sends it to the acquirer. The acquirer routes that request through the relevant card network (Visa or Mastercard, for instance), which then forwards it to the issuing processor. The issuer checks available balance, fraud rules, and any card-level controls, then sends an authorisation response back through the same chain. The merchant receives an approval or a decline, usually within two seconds.

Q&A: What data fields does a virtual card authorisation request contain? 

An authorisation request for a virtual card includes the primary account number (PAN), expiry date, CVV2, transaction amount, transaction currency, and the merchant category code (MCC). It also carries the merchant’s acquirer identification number, the point-of-interaction data, and various ISO 8583 data elements covering terminal capability and transaction type. Together, these fields give the issuer everything it needs to make an authorisation decision.

How does a virtual card authorisation differ from a physical card transaction?

A virtual card authorisation is a card-not-present (CNP) transaction by default, meaning there is no physical card, no chip to read, and no cardholder standing at a terminal. Authentication relies entirely on the card credentials (PAN, expiry, and CVV2) along with any additional controls set at the card level. This is structurally different from an EMV chip transaction, where the terminal and card exchange cryptographic data that strongly authenticates the card’s physical presence.

Virtual cards compensate for the absence of a chip through other mechanisms. Many programmes use dynamic CVV2 values that rotate on a time-based schedule, or single-use PANs that are valid for exactly one transaction. Beyond credential-level controls, virtual cards can carry velocity rules and spend limits defined at the point of issuance, restrictions that a physical card simply cannot carry in the same programmable way. These controls are evaluated by the issuing processor during the authorisation decision, adding a layer of transaction governance that sits entirely on the issuer side of the flow.

Further Reading: Dynamic CVV Technology: Real-Time Security for Modern Issuers

Step-by-step: the full authorisation sequence

The authorisation flow for a virtual card follows a defined path:

1. A transaction is initiated by a cardholder, an automated payment system, or a supplier portal accepting card details.
2. The merchant’s payment gateway or acquirer formats an ISO 8583 authorisation request message.
3. The acquirer routes the request to the appropriate card network based on the card’s BIN range.
4. The card network identifies the issuing processor and forwards the request.
5. The issuing processor evaluates the request against available balance, card-level controls, and fraud scoring rules.
6. The issuer returns an authorisation response code to the card network.
7. The response travels back through the network to the acquirer and on to the merchant.

The round-trip is fast. Visa’s authorisation processing benchmarks target response times well under two seconds for the vast majority of transactions, with the network infrastructure designed to handle thousands of transactions per second globally. According to Visa’s processing guidelines, network authorisation response times are monitored at the millisecond level to maintain service standards across all connected issuers and acquirers.

Within the issuer’s decision engine, the logic goes beyond a simple balance check. Rules-based controls (MCC filters, transaction amount caps, velocity counters) are evaluated in sequence. Real-time fraud scoring may apply machine learning models that assess the transaction against behavioural patterns. BIN-level configurations can impose additional constraints that apply to every card issued under a specific programme.

Q&A: What causes a virtual card authorisation to be declined? 

A virtual card authorisation can be declined for several reasons: insufficient available balance, a transaction MCC that falls outside the card’s permitted merchant categories, a single-use PAN that has already been consumed, a velocity limit that has been breached (too many transactions in a 24-hour window, for example), a CVV2 or AVS mismatch, or a fraud flag raised by the issuer’s real-time scoring engine. Each decline maps to a specific ISO 8583 response code, which helps payment teams diagnose the cause.

What authorisation controls can be set on a virtual card?

Virtual card programmes allow payment operators to define controls at the card level, applied at issuance or updated via API in real time. These controls are evaluated by the issuing processor as part of every authorisation decision, meaning a card can be tightly scoped to a single supplier, a specific budget, or a narrow time window.

These controls function within the issuer’s authorisation logic and are checked in real time. Changes made via API, such as adjusting a spend limit mid-programme, take effect immediately for subsequent authorisations.

Partial authorisations and over-authorisation: what payment teams need to know

A partial authorisation occurs when an issuer approves less than the full requested amount, most often when the available balance covers only part of the transaction. For consumer cards this is common at fuel stations; for virtual card programmes used in B2B payments, it creates reconciliation problems because the approved amount and the invoice amount no longer align.

Over-authorisation is a related but distinct problem. Certain merchant categories (hotels, car rental companies, and some utilities) place a pre-authorisation hold that exceeds the expected final transaction amount. The merchant captures only what was actually spent at settlement, but the hold reduces available balance in the interim. Mastercard’s transaction processing rules specify maximum hold durations by merchant category: hotel pre-auths, for example, can remain open for up to 31 days before the issuer is permitted to release the hold automatically. For virtual card programmes with strict per-card budgets, an open pre-auth hold can block subsequent legitimate transactions against the same card.

Payment teams managing virtual card programmes should map out which merchant categories they expect to encounter, and build reconciliation logic that accounts for the gap between authorised amounts and settled amounts.

Further Reading: Tokenisation: How Virtual Cards Protect Payment Data

How do card networks handle authorisation routing for virtual cards?

Card networks route authorisation requests using the BIN (Bank Identification Number), the first six to eight digits of the card’s PAN, to identify the issuing processor and direct the message accordingly. For virtual cards operating within tokenisation programmes, the PAN presented to the merchant may be a network-issued token rather than the real card number. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) both replace the funding PAN with a token that is specific to a merchant or device context.

When a tokenised authorisation request reaches the card network, the token is detokenised before the message is forwarded to the issuing processor. The issuer therefore sees the real PAN and processes the authorisation exactly as it would for any other transaction. The merchant, however, never handles the real card number. For CNP transactions, 3-D Secure 2 (3DS2) provides an additional authentication layer, passing device, behavioural, and transactional data to the issuer for risk-based authentication without requiring a cardholder challenge in most cases.

Q&A: Does network tokenisation affect the authorisation flow for virtual cards?

Network tokenisation changes what the merchant sees, but not what the issuer processes. The token is resolved to the real PAN at the network level before the authorisation request reaches the issuer, so the issuer’s decision logic (balance checks, fraud scoring, card-level controls) operates on the actual card credentials as normal. The merchant receives an authorisation response without ever handling the underlying PAN, which limits data exposure on the merchant side.

Authorisation response codes: what they mean and how to handle them

ISO 8583 response codes are two-digit values returned by the issuer to communicate the outcome of an authorisation request. Payment operators integrating virtual card programmes need to handle these codes correctly, not just log them, but build appropriate retry logic and system notifications around them.

Code 05 is the most common catch-all decline and the least informative. When a virtual card programme sees a spike in 05 responses, the investigation should start with fraud rules and BIN-level configurations rather than card controls, since issuers may apply programme-level blocks that do not surface as more specific codes.

Further Reading: What is a Bank Identification Number (BIN)?

Real-time authorisation webhooks and API integration

Modern virtual card platforms deliver authorisation events to connected systems via webhooks, HTTP POST requests sent to a pre-configured endpoint at the moment an authorisation decision is made. This is distinct from a settlement webhook, which fires when funds actually move; an authorisation webhook fires at the point of approval or decline, before settlement occurs.

For developers building on virtual card APIs, the authorisation webhook is the primary integration point for real-time spend visibility. Latency matters here: a webhook that arrives ten seconds after the transaction is useless for systems that need to update budget dashboards or trigger downstream workflows synchronously. Issuers and platforms are expected to deliver event notifications with minimal delay relative to the authorisation decision itself.

Integration best practices include idempotency handling, because webhook delivery is not always guaranteed exactly once. Systems should deduplicate events using a unique transaction identifier rather than processing every incoming POST as a new event. Retry logic on the receiving end should apply exponential backoff for failed deliveries, and endpoints should return a 200 response immediately upon receipt, processing the payload asynchronously to avoid timeout-triggered redeliveries.

Virtual card authorisation with Wallester

Real-time authorisation processing functions at the core of how Wallester’s virtual card infrastructure works. Card-level controls are evaluated within the authorisation decision loop rather than applied as post-transaction filters, which means every spend rule takes effect at the moment the transaction is submitted, not after the fact.

Every card issued through the Wallester platform can carry its own configuration: MCC filters, per-transaction and cumulative spend limits, currency restrictions, and time-based validity windows, all manageable via API without needing to reissue the card. For payment teams running high-volume programmes, Wallester’s webhook infrastructure delivers authorisation events as they happen, supporting the real-time spend visibility that finance and operations teams need to manage budgets at scale. Cards can be issued individually or in bulk, each with a distinct rule set, making the platform well suited to accounts payable automation, contractor payment programmes, and travel expense management.If you’re evaluating virtual card infrastructure or looking to add programmable card controls to an existing payment programme, Wallester’s API documentation is a practical starting point, or you can speak directly with the team about your specific programme requirements.