Acceptance-side · single-use aware

Virtual card payment processing — every issued credential, one API.

topropay accepts single-use AP virtual cards, wallet-provisioned tokens, B2B AP virtual cards and consumer prepaid virtual cards through the same authorise endpoint as standard card. PCI L1 vault, smart routing, invoice-linked reconciliation — no separate integration.

Book an acceptance review Read the API docs
300+
methods reachable — virtual cards included
PCI L1
vault holds virtual-card credentials, not merchants
Single-use
one-time BIN handling supported
1 ledger
virtual-card receipts alongside standard card

Card variants

Four flavours of virtual card payment solutions on the same acceptance surface

What actually arrives on the checkout when a buyer submits a virtual card — with per-flavour metadata preserved through vault, routing and reconciliation.

  1. 01

    Single-use / one-time virtual cards

    AP tools and travel-issuance platforms issue a new BIN + PAN pair per invoice or per booking. topropay accepts these as standard PAN-based authorisations, tokenises them into the vault, and reconciles the receipt against the merchant's original invoice reference where the buyer sends one.

  2. 02

    Scheme-tokenised virtual credentials (Apple Pay / Google Pay)

    Wallet-provisioned tokens on device are effectively virtual cards from the merchant's perspective — the PAN is a network token, not the underlying credential. Accepted as first-class citizens on the hosted checkout and inside embedded hosted fields.

  3. 03

    B2B AP virtual cards

    Corporate accounts-payable platforms (Bill.com, Coupa, SAP Ariba, and bank-issued AP cards) push virtual card details into invoice-pay flows. Received through the same authorise endpoint as any card; higher-value tickets routed via commercial-BIN-aware lanes.

  4. 04

    Prepaid virtual cards

    Consumer prepaid virtual cards issued by neobanks and fintechs land on the checkout like any other card. BIN detection identifies prepaid ranges; routing considers issuer approval behaviour and the buyer's declared use case.

How virtual card payment system flow runs

From virtual-card submit to invoice-linked ledger row in five steps

What actually happens between the buyer entering a virtual-card credential and the row landing in the merchant's reconciliation feed.

  1. 01

    Buyer submits the virtual card details

    On a hosted checkout, embedded hosted fields, invoice pay link or wallet handoff. Virtual-card BINs render identically to standard card BINs on the merchant side — the difference is upstream, not on the surface.

  2. 02

    Vault + tokenisation

    The PAN captures into topropay's PCI DSS Level 1 vault before any acquirer sees it. A vault token is issued. Where the scheme supports it, a network token (VTS / MDES) is also provisioned for future re-use.

  3. 03

    Routing across the acquirer panel

    The routing engine scores connected acquirers on BIN, currency, country pair, commercial vs consumer flag and risk. Commercial-BIN virtual cards prefer commercial-BIN-aware lanes when they clear at higher approval.

  4. 04

    Authorise, capture, settle

    Card-not-present authorisation; capture is automatic or merchant-triggered per the flow. Settlement files from the acquirer arrive with the transaction's original virtual-card BIN preserved for reporting.

  5. 05

    Reconcile with invoice metadata

    Each virtual-card receipt is reconciled against the merchant's original invoice reference (where the buyer supplied one). One ledger across virtual and standard card receipts, tagged by BIN type.

Main use cases

Where b2b virtual card payment solutions and consumer virtual cards land

Six recurring merchant shapes that see meaningful virtual-card volume — from SaaS invoicing through to marketplaces and platform resellers.

  • SaaS

    SaaS invoicing via AP virtual cards

    Enterprise buyers pay SaaS invoices with a single-use virtual card generated by their AP tool. The merchant sees one auth per invoice, reconciles the receipt against the invoice ID, and doesn't need to store card-on-file.

  • Travel

    Travel and hospitality booking via issued virtual cards

    TMCs (travel management companies) issue single-use virtual cards per booking. The merchant accepts them at check-in or check-out; refunds run against the original vault token, which reverses back to the issuing platform.

  • B2B

    B2B marketplaces with mixed card mix

    Marketplaces receiving both consumer cards and B2B virtual cards; routing considers commercial-BIN vs consumer-BIN separately; commercial-BIN traffic can be surcharged where scheme rules and geography allow.

  • Inv

    Invoice pay via virtual cards

    Hosted invoice pay links accept virtual cards alongside standard card, ACH and SEPA. Invoice-linked reconciliation ties the receipt back to the merchant's original invoice ID automatically.

  • Sub

    Recurring on virtual cards

    Where the issuing platform provisions a re-usable virtual credential rather than single-use, network-token recurring runs against it just like a standard card-on-file — with scheme updaters keeping the token alive across re-issuance.

  • Plat

    Platforms passing virtual cards to sub-merchants

    PSPs and marketplace platforms accept virtual-card payments and route them across the connected acquirer panel per downstream sub-merchant, with the sub-merchant tag preserved through reconciliation.

Platform features

Capabilities behind these virtual card payment solutions

Twelve capabilities the platform ships once and reuses across virtual and standard card acceptance — the primitives that make the two feel like one product.

  • Same authorise endpoint

    Virtual cards ride the same POST /v1/authorizations as standard card — no separate integration required.

  • PCI DSS Level 1 vault

    Card data captures into the platform vault before any acquirer sees it; PAN never lands on merchant systems.

  • Network tokens where available

    VTS and MDES tokens issued when the scheme and issuer support it; recurring against the token survives re-issuance of the underlying virtual credential.

  • Commercial-BIN routing

    Commercial-BIN virtual cards preferred to commercial-BIN-aware lanes where they clear at higher approval.

  • Selective 3DS2 / SCA

    EMV 3DS2 fires per PSD2 exemption logic; frictionless flows pass through for commercial BINs where issuer-side rules allow.

  • Invoice-linked reconciliation

    Each virtual-card receipt reconciled against the merchant's original invoice reference where supplied.

  • Refunds against the vault token

    Refunds default to the original virtual card — reversing back to the issuing platform's ledger for AP-side reconciliation.

  • Single-use awareness

    Where the merchant knows the credential is single-use, recurring / stored-credential flags are suppressed to avoid scheme misalignment.

  • Cross-currency handling

    Virtual cards accepted in the buyer's currency where the issuer and acquirer allow; conversion follows the same FX metadata treatment as standard card.

  • Chargeback surfacing per BIN

    Chargebacks tagged with the virtual-card BIN plus its commercial / consumer classification for evidence-pack purposes.

  • Unified reconciliation feed

    Daily normalised feed across every connected acquirer, with virtual-card BIN metadata preserved on each row.

  • Operator-side refund controls

    Refunds require justification and log every event with actor identity, reason and timestamp — same audit trail as standard card.

Industry relevance

international payment virtual card acceptance for licensed merchants

topropay's virtual-card posture targets licensed merchants operating across EU, UK, APAC and LATAM — SaaS platforms billing via AP virtual cards, travel and hospitality accepting TMC-issued virtual credentials, B2B marketplaces with mixed consumer / commercial card mix, and licensed regulated-industry merchants where corporate spend flows via bank-issued virtual cards.

Trust & compliance

Compliance posture around virtual-card acceptance

One audited environment underneath both virtual and standard card acceptance; scheme metadata preserved through the authorisation for single-use awareness.

PCI DSS Level 1
Vault, switch and tokenisation are PCI DSS Level 1 service-provider components; sub-merchants inherit the posture whether the receipt is card or virtual card.
Scheme programme posture
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer; virtual-card BINs travel through the same programme framework as standard BINs.
SCA & PSD2
Selective EMV 3DS2 on the card path keeps approval high on European virtual-card acceptance without skipping the SCA bar.
Single-use scheme handling
Scheme metadata on single-use virtual credentials preserved through the authorisation; no false stored-credential flagging.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and virtual-card BIN mix.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of card type.

Ready to accept every virtual credential

Add virtual-card acceptance to the same integration you already run.

A 30-minute acceptance review covers the virtual-card BIN mix in your traffic, the routing policy tuned to your commercial vs consumer split, and a sandbox you can test against before any commercial commitment.

Book an acceptance review Read the API docs

Frequently asked

Buyer questions about virtual card payment processing on topropay

Definitions, single-use vs re-usable mechanics, B2B commercial-card angles, L2 / L3 data enrichment and the practicalities of accepting virtual cards through one unified API.

  1. 01

    What does virtual card payment processing actually mean on topropay?

    Virtual card payment processing on topropay is acceptance-side handling of virtual-card credentials — whether that's a single-use AP virtual card, a scheme-tokenised wallet credential (Apple Pay, Google Pay), a corporate-issued B2B virtual card or a consumer prepaid virtual card. All types share the same authorise endpoint, vault and reconciliation feed as standard PAN-based card payments.

  2. 02

    How do virtual card payment solutions differ from standard card acceptance?

    Virtual card payment solutions differ in the issuance side, not the acceptance side. From topropay's perspective the transaction is a card-not-present authorisation against a valid BIN — the fact that the BIN was minted specifically for this invoice or booking is invisible to the acceptance flow. Where it matters is in downstream metadata: single-use BINs shouldn't be flagged as stored-credential for future re-use.

  3. 03

    What kinds of virtual card payment system inputs does the platform accept?

    The virtual card payment system side accepts hosted-checkout entry, embedded hosted fields on the merchant's own checkout, hosted invoice pay links, and wallet handoffs (Apple Pay, Google Pay, Click to Pay). AP-tool integrations that push virtual card details programmatically integrate against the low-level SDK. The back-end is the same regardless of the entry surface.

  4. 04

    Does topropay support b2b virtual card payment solutions specifically?

    Yes. B2B virtual card payment solutions target commercial-BIN virtual cards issued by AP tools (Bill.com, Coupa, SAP Ariba, bank-issued AP cards). Commercial-BIN routing preference, higher-ticket lane awareness and invoice-linked reconciliation are all supported. Level-2 / Level-3 data enrichment is available where the acquirer supports it, to secure interchange-optimised commercial-card rates.

  5. 05

    How does international payment virtual card acceptance work?

    International payment virtual card acceptance runs through the platform's FX-aware acceptance path. Virtual cards issued in one currency but presented for a purchase in another currency clear according to the acquirer's cross-currency rules; the platform tags the settlement row with the transaction currency, settlement currency and applied FX rate for finance visibility.

  6. 06

    Are single-use virtual cards handled differently from re-usable ones?

    Yes. Where the merchant knows (or the BIN metadata implies) the virtual card is single-use, stored-credential and recurring flags are suppressed on the authorisation message. This prevents scheme misalignment and reduces the risk of scheme fines from mis-flagged stored credentials that no longer resolve on re-billing.

  7. 07

    How do refunds work on a single-use virtual card?

    Refunds against the vault token that was issued for the original authorisation. The refund reverses through the same acquirer to the issuing platform's ledger, even if the underlying virtual card credential is no longer active for new debits — because the vault token points at the acquirer's clearing route, not the raw PAN.

  8. 08

    What about chargebacks on virtual cards?

    Chargebacks on virtual cards follow standard scheme dispute rules. The unified dispute queue tags each case with the virtual-card BIN and its commercial / consumer classification. Evidence-pack templates include the original invoice reference where the buyer supplied one, which is often the strongest defence on B2B virtual-card disputes.

  9. 09

    Do virtual cards get lower approval rates than standard cards?

    Not systematically. Approval depends on the issuer's fraud posture and the acquirer's ability to signal the transaction context. Single-use virtual cards from established AP tools typically clear at approval rates comparable to standard commercial cards on commercial-BIN-aware lanes. topropay's smart routing preferentially picks lanes that historically clear the specific BIN range.

  10. 10

    Can the platform issue virtual cards for the merchant to use?

    No. topropay's virtual card handling is acceptance-side only — the platform accepts virtual cards presented by the merchant's buyers. Merchants that need to issue virtual cards (for corporate spend, employee expenses, marketplace payouts) integrate a separate card-issuing partner and then accept the resulting virtual credentials on topropay's acceptance side.

  11. 11

    How does level-2 / level-3 data enrichment work for B2B virtual cards?

    Level-2 (tax amount, customer code) and Level-3 (line-item detail) data enrichment is passed through on the authorisation and capture messages where the acquirer supports it. This qualifies commercial-BIN virtual-card transactions for interchange-optimised commercial-card rates, which materially reduces cost on high-value B2B tickets.

  12. 12

    What geographies is virtual-card acceptance available in?

    Virtual-card acceptance is available wherever the connected acquirer panel accepts card — EU, UK, APAC and LATAM as a baseline. US-issued virtual cards clear via connected US acquirers; India-issued cards via licensed partner gateways; the routing engine picks the lane per BIN and issuer country pair.

  13. 13

    Can virtual-card volume be run alongside standard card and non-card methods?

    Yes — that's the platform's default posture. Virtual cards, standard cards, wallets, bank rails, BNPL and (via partner gateways) crypto all sit on the same unified API. Reconciliation surfaces every receipt in one feed, with card-type metadata (virtual vs standard, commercial vs consumer, single-use vs re-usable) preserved per row.

  14. 14

    Is there anything specific to watch for on virtual cards vs standard card?

    Two things. First, don't flag single-use virtual cards for stored-credential re-use — the credential expires with the original authorisation. Second, expect a higher share of chargebacks on virtual-card BINs to succeed on the buyer's side when the buyer's AP platform pulls the credential — evidence packs should include the original invoice reference and the fulfilment proof.

  15. 15

    How long does virtual-card acceptance take to set up on topropay?

    Virtual-card acceptance is enabled the moment the merchant's standard card acceptance is live — usually 1–3 weeks from KYB submission. No separate integration required; the merchant configures which BIN ranges to route where in the same routing-policy editor that governs standard card.

Related

Related on the topropay platform