> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pcibooking.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Virtual Cards

> Issue single-use virtual cards through supported providers and automatically tokenize them in PCI Booking.

## What Are Virtual Cards?

Virtual cards are temporary card numbers issued programmatically 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?

| Benefit               | How                                                           |
| --------------------- | ------------------------------------------------------------- |
| Fraud protection      | Single-use card cannot be reused if intercepted               |
| Spend control         | Set maximum amount and authorization date range               |
| Reconciliation        | Each virtual card maps to a specific booking or transaction   |
| No real card exposure | The supplier receives a virtual card, not your funding source |

Virtual cards are common in the travel industry for paying hotels, airlines, and other suppliers without exposing the company's actual payment credentials.

## How It Works with PCI Booking

PCI Booking integrates with virtual card providers (VCPs) and handles the full flow:

1. You call [Issue Virtual Card](/api-reference/additional/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

Use the [List Virtual Card Providers](/api-reference/additional/list-virtual-card-providers) endpoint to see all currently supported providers and their required credentials. This endpoint is public and requires no authentication.

Each provider has its own credential structure. Use [Retrieve VCP Credential Structure](/api-reference/additional/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](/api-reference/additional/issue-virtual-card) request body.

**Option 2: Store credentials in PCI Booking.** Use [Store Credentials](/api-reference/process-cards/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:

| Parameter           | Description                                              |
| ------------------- | -------------------------------------------------------- |
| **MaxValue**        | Maximum amount and currency the card can be charged      |
| **MinAuthDate**     | Earliest date the card accepts authorizations            |
| **MaxAuthDate**     | Latest date the card accepts authorizations              |
| **UniqueReference** | Your own reference for reconciliation (e.g., booking ID) |
| **CustomData**      | Provider-specific additional data                        |

## Using the Issued Card

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

* **Relay it** to a hotel or supplier via [Token Replacement in Request](/use-tokens/token-replacement-in-request)
* **Display it** to an agent via [Card Display](/use-tokens/card-display)
* **Query its metadata** via [Retrieve Token Metadata](/api-reference/manage-tokens/retrieve-token-metadata)
* **Delete it** via [Delete Token](/api-reference/manage-tokens/delete-token) when no longer needed

## Typical Workflow

A travel platform issuing a virtual card to pay a hotel:

1. **Issue** a virtual card with the booking amount and check-in/check-out dates as the authorization window.
2. **Relay** the token to the hotel's payment system using token replacement.
3. The hotel charges the virtual card.
4. **Reconcile** using the `UniqueReference` you set (e.g., your booking ID).
5. **Delete** the token after the transaction is settled.

## Related

* [Issue Virtual Card](/api-reference/additional/issue-virtual-card) - API reference
* [List Virtual Card Providers](/api-reference/additional/list-virtual-card-providers) - See supported providers
* [Get Virtual Card Provider](/api-reference/additional/get-virtual-card-provider) - Provider details
* [Retrieve VCP Credential Structure](/api-reference/additional/retrieve-vcp-credential-structure) - Required credential fields
* [Store Credentials](/api-reference/process-cards/store-credentials) - Save VCP credentials
* [Token Replacement in Request](/use-tokens/token-replacement-in-request) - Relay card data to suppliers