How virtual cards connect issuing and acquiring
Follow the cardholder, merchant, acquirer, network and issuer through authorization, capture, clearing and settlement.
A virtual card is a way of representing card credentials. It can be prepaid, debit or credit, and some credentials are tokenized for a device or merchant. Removing the plastic does not remove the issuer, card network or acquiring side of the payment.
This guide describes a typical card-network model. Closed-loop systems, domestic debit networks and local payment methods can have different roles and timelines.
Start with the two ends: cardholder and merchant
The cardholder pays; the merchant supplies goods or services. The issuer manages the card account and authorization decisions. A virtual card platform or programme manager may provide applications, budgets, team access and transaction views without being the licensed issuer itself.
The acquirer supports the merchant’s transactions. A gateway or payment service provider connects checkout and processes or orchestrates messages. The card network connects issuing and acquiring and establishes its rules. One organization may perform several roles or supply a capability through another institution.
Authorization: can this payment be approved?
A typical message travels from cardholder to merchant checkout, gateway or PSP, acquirer, network and issuer, with the answer returning along the chain. The issuer considers card status, funds or credit, risk and transaction details.
Approval normally reserves the relevant amount or limit; it does not mean the merchant has received final funds. 3DS authenticates the cardholder, while authorization decides whether to approve the transaction. Successful authentication can still be followed by a decline.
Recurring payments also require the distinction between cardholder-initiated and merchant-initiated transactions, valid consent, correct credentials and the appropriate indicators. One-off consent is not unlimited permission to charge later.
Capture, clearing and settlement have different jobs
Capture submits the final amount against an approved transaction. It may be automatic or separately triggered. A preauthorization can be reversed, expire or complete for a different final amount, subject to the use case and rules.
Clearing exchanges final transaction and fee data and calculates obligations. Settlement discharges the relevant funding obligations. A PSP’s payout to the merchant’s bank account then follows its own contractual schedule.
Track four moments separately: authorization, capture, network settlement and actual receipt in the merchant’s account. They can span different days, with further differences caused by weekends, reviews or reserves.
A virtual card platform manages more than numbers
Issuing-side work includes entities and users, card lifecycles, funding or credit, spending controls, authorizations, posted transactions, refunds and disputes. A limit is not a balance, and an authorization hold is not a final expense. The interface should distinguish holds, reversals, posting and refunds.
Connect the business operation, card identifier, provider operation and transaction references. Authorization, capture, fees and refunds may be separate records that need linking according to the provider’s model. Minimizing card data, separating permissions and verifying signatures matter as much as adding endpoints.
Acquiring connects the order to the money
The acquiring side starts with the merchant, goods, price and order, then handles checkout, authentication, authorization, capture, refunds, disputes and payouts. An order can have several attempts, but it must be protected from multiple successful charges for the same amount due.
Callbacks and queries should converge on a consistent state model. Keep amounts, currencies, fees and FX distinct rather than storing only a success flag. Reconcile orders, provider records, settlement reports and bank receipts.
A refund is initiated by the merchant. Disputes and chargebacks can proceed through issuer and network procedures. They are different flows; a dispute is not an invitation to issue a duplicate refund. Continue with authorization and 3DS, fraud, disputes and chargebacks or the payment map. Further reading: Stripe’s official documentation and FuturePay’s developer documentation.