Skip to main content
PCI Booking connects to a library of virtual card issuing providers (VCPs). You request a card through PCI Booking, the connected provider issues it, and PCI Booking automatically tokenizes the result. It’s a capture method like any other - it just starts with PCI Booking requesting a new card instead of a cardholder entering an existing one.
The provider is the actual card issuer. PCI Booking connects to your provider account, requests the card, and tokenizes what the provider returns - PCI Booking is not an issuer itself.

​
What Are Virtual Cards?

Virtual cards are temporary card numbers issued programmatically by a card provider for a specific transaction or purpose. They have a set spending limit, an authorization window, and can be restricted to a single use. Once the transaction is complete or the card expires, it cannot be used again.

​
Why Use Them?

Virtual cards are common in the travel industry for paying hotels, airlines, and other suppliers without exposing the company’s actual payment credentials.
Common pattern: charge the original card, fund the virtual card. Many customers combine virtual card issuance with the Universal Payment Gateway: first charge the guest’s original card (already tokenized in PCI Booking) through the UPG, then issue a virtual card funded by that payment to pay the supplier. The guest’s card and the supplier’s card stay completely separate, and both sides of the flow run through PCI Booking tokens end to end.

​
How It Works

  1. You call Issue Virtual Card with the provider credentials, amount, currency, and authorization date range.
  2. PCI Booking requests a virtual card from the provider.
  3. The provider issues the card.
  4. PCI Booking automatically tokenizes the issued card and returns a PCI Booking token URI in the Location header.
The issued card number and CVV are masked in the API response. You only receive the PCI Booking token, which you can then use like any other token: relay it to a supplier, display it, or process a payment.

​
Supported Providers

See the full list of supported providers via the API, along with each provider’s required credential fields. If your provider isn’t listed, we can add it. Contact support@pcibooking.net with:
  • Your PCI Booking username.
  • The provider’s server-to-server API documentation (in English).
  • A test account or instructions on how to set one up.
  • A support contact at the provider.
Each provider has its own credential structure. Use Retrieve VCP Credential Structure to get the exact fields needed for a specific provider before storing credentials.

​
Setting Up Credentials

You have two options for providing VCP credentials: Option 1: Pass credentials per request. Include ProviderName and Credentials in each Issue Virtual Card request body. Option 2: Store credentials in PCI Booking. Use Store Credentials to save your VCP credentials once, then pass the credentialsId query parameter on each issuance request. This is more secure and avoids sending credentials repeatedly.

​
Issuance Parameters

When issuing a virtual card, you control:

​
Using the Issued Card

Once issued, the virtual card is a standard PCI Booking token. You can:

​
Typical Workflow

A travel platform issuing a virtual card to pay a hotel:
  1. Charge the guest’s original card (its PCI Booking token) through the Universal Payment Gateway - optional, but this is how most platforms fund the virtual card.
  2. Issue a virtual card with the booking amount and check-in/check-out dates as the authorization window.
  3. Relay the token to the hotel’s payment system using token replacement.
  4. The hotel charges the virtual card.
  5. Reconcile using the UniqueReference you set (e.g., your booking ID).
  6. Delete the token after the transaction is settled.