# Virtual cards

A **virtual card** is a single-use or limited-use payment instrument — think of it as a one-time card number Adrasis issues per booking, scoped to one supplier, in one currency, with a fixed spending limit and an expiry date. You issue one when a booking lands so the supplier (e.g. Hotel Sunrise in Antalya) can charge a clean amount in their preferred currency, without you handing over a corporate card or wiring money for every reservation.

## What virtual cards solve

The traditional alternatives are *"we paid with our corporate card"* or *"we wired the supplier"*. Both break at scale:

* **Corporate card on the supplier's terminal** — exposed to declines, currency-conversion surprises, fraud, and every supplier seeing the same card number.
* **Wire transfers per booking** — operationally expensive, slow, hard to reconcile, no clean per-booking record.
* **Bulk wire transfers per period** — better, but matching the lump-sum back to individual bookings is manual finance work.

Virtual cards remove all three. Adrasis issues a card scoped to the booking, in the supplier's currency, with a fixed limit, and the supplier charges it like any other card. Reconciliation is automatic — the card is the booking.

## What you can issue

| Property                        | Default behavior                                                                                                              |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Currency**                    | Issued in the supplier's preferred currency (typically the contract currency — e.g. EUR for Hotel Sunrise).                   |
| **Limit**                       | Set at booking time to the exact amount the supplier should be able to charge (e.g. EUR 600 for a 4-night booking).           |
| **Validity window**             | Active from booking until check-out plus a safety buffer (typically 7 days); expires after.                                   |
| **Single-use vs. multi-charge** | Most are multi-charge (deposit + balance + ancillaries); some are single-use for one-shot payments.                           |
| **Per-merchant lock**           | Where the payment gateway supports it, the card is locked to the supplier's merchant identity so it cannot be used elsewhere. |
| **Cardholder details**          | Synthetic — your organization identity, not an operator's personal name.                                                      |

Each virtual card is bound one-to-one to a booking. If the booking changes (rate adjustment, ancillary charge, partial cancellation), the card limit and validity adjust automatically.

## When you issue them

The standard flow:

1. **Booking lands** — direct, channel-sourced, or Adragent-driven.
2. **Settlement terms read from the contract** — net rate, supplier currency, when the supplier can charge.
3. **Virtual card issued** — currency, limit, validity, locks set per terms.
4. **Card details delivered to the supplier** — by the method the contract specifies (email, partner portal, channel push).
5. **Supplier charges the card at check-in or per the contract schedule.**
6. **Reconciliation** — Adrasis matches the supplier's charge against the booking's expected amount; mismatches surface for review.
7. **Card expires** — after the validity window, the card cannot be charged again.

For self-service supplier portals, the supplier pulls card details when they need them; for connected channels, Adrasis pushes the card details automatically.

## Multi-currency

Concrete example:

* A Turkish traveller pays TRY 24,000 for a 4-night Hotel Sunrise booking.
* The Hotel Sunrise contract is in EUR; the net rate is EUR 600.
* Adrasis issues a EUR 600 virtual card; Hotel Sunrise charges it at check-in like any other card.
* You bear the conversion from TRY (the traveller's payment) to EUR (the card-funding account) at the time of card issuance, with the rate shown on the card and payment views.

Conversions you would otherwise have to chase at the payment gateway, the bank, or in finance reconciliation become part of the card lifecycle.

## When the booking changes

A booking is not always settled exactly the way it was originally written. Common adjustments:

* **Ancillary charges** — late check-out, room upgrade, mini-bar, parking. The card limit can be raised to accommodate (e.g. EUR 600 → EUR 660 for a EUR 60 late check-out); the new limit is recorded.
* **Partial cancellation** — one of three rooms cancels; the card limit drops to match the new total.
* **Full cancellation within the refund window** — the card is closed (limit goes to zero); any pre-paid amount is refunded through the original traveller-side payment method.
* **No-show waiver** — operator goodwill; the card is closed without the supplier charging.

Each adjustment is an event on the card record, with the operator who made it and the reason.

## Reconciliation lives in the booking

When the supplier charges the card:

* Adrasis sees the charge through the payment gateway.
* The amount is matched against the booking's expected supplier amount.
* If they match, the card record shows *charged in full*; the booking record shows *settled*.
* If they do not match, the discrepancy surfaces for review — common reasons are a tax difference, an unexpected ancillary, or a currency-conversion variance.

You see all of this on the booking page, alongside the card record. Finance does not have to cross-reference card statements with booking lists; it is one view.

## What virtual cards do not solve

Virtual cards are not magic:

* A supplier that does not accept cards needs a wire transfer instead. Adrasis supports both; you choose per supplier in the contract.
* A chargeback (when a cardholder disputes a charge with their bank — the bank pulls the funds and you have a defense window) against your card-funding account is still a chargeback; the defense flow runs in Adrasis but the merchant-of-record is your organization.
* Some markets restrict virtual-card usage for travel; the contract surface flags incompatibility before issuance.

## Card controls

* **Issuance** happens automatically on booking; the contract terms set the parameters.
* **Manual adjustment** covers raising a limit or closing a card early.
* **Card details disclosure** is visible from the payment view.

## Adragent and virtual cards

Common phrases that map to Adragent virtual-card operations:

* *"Issue a virtual card for the new Hotel Sunrise booking BK-12345."*
* *"Show me every virtual card with charges that don't match the booking total."*
* *"Close the virtual card for booking BK-67890 — the cancellation just landed."*
* *"List bookings where the virtual card has been issued but the supplier hasn't charged yet."*

Read operations return immediately; writes preview before applying.

## Where to next

* **The settlement and reconciliation flow virtual cards plug into** → [Settlement & reconciliation](/console/payments/settlement-and-reconciliation.md)
* **What happens on cancellations and disputes** → [Refunds & chargebacks](/console/payments/refunds-chargebacks.md)
* **The contracts that drive virtual-card terms** → [Contracts](/console/contracts-and-onboarding/contracts.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/payments/virtual-cards.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.