# Payment methods

**Payment methods define how a traveller pays for or guarantees a booking in the Demand API. If you are implementing the [Search, look and book](/demand/docs/development-guide/application-flows/#search-look-book) flow and want to understand the available payment methods, this guide explains how payment methods work across booking scenarios.**

## What is a payment method?

A payment method defines **how a charge is collected or secured**.

It is one of the three core payment concepts:

* **[Payment timing](/demand/docs/payments/payments-timings)** → when payment happens.
* **Payment method** → how payment is made.
* **[Payment schedule](/demand/docs/payments/payments-schedules)** → how payments are split.


Payment methods should always be interpreted together with payment timings and schedules.

## Supported payment method types

The Demand API supports two primary categories:

### Card-based methods

Used for online payments or booking guarantees.

Includes:

* Credit cards
* Virtual credit cards (VCC)
* Tokenised card flows (e.g. SCA flows)


### Pay at service

Payment is collected at the point of service delivery.

Examples:

* Pay at the property (accommodation)
* Pay at pickup (car rental)


These flows may still require a card guarantee.

## How payment methods are determined

The available payment methods depend on:

* Your **partner configuration**
* The **supplier or property policy**
* The **payment timing selected**
* **Regulatory requirements** (e.g. SCA in EEA)


Do not hardcode payment methods.

Always retrieve available options dynamically from the Demand API.

## How to retrieve payment methods

Payment methods are exposed at different stages of the booking flow:

| 
| **Stage** | **Endpoint** | **What you get** |
| Product selection | /details | Returns the payment methods that are accepted by the property or supplier, for the selected product. |
| Order preview | /orders/preview | Returns the final set of supported methods for the selected payment timing. This may vary from those returned in */details. |


Source of truth
Always use  /orders/preview response as the **source of truth** for checkout behaviour.
This is because:

* Payment availability may change dynamically.
* Some methods depend on the selected timing or product combination.
* Final constraints are only known at preview stage.


## Payment methods and timing compatibility

Not all payment methods are available for all payment timings.

For example:

* Some card flows are only supported for `pay_online_now`
* Pay at service may not require upfront card charging, but may require a guarantee.


Always validate the selected **payment method + timing** combination using /orders/preview.

Please note that `pay_online_later` is currently **not available** for payment methods: CC MOTO, CC SCA, CC Riskified or CC.

## Payment method types

### Virtual credit cards (VCC)

Virtual credit cards (VCCs) are single-use or limited-use card numbers generated for a specific transaction.

They are commonly used when:

* Payments are made **on behalf of the traveller**.
* Additional control or security is required.


Characteristics:

* Unique card details per booking.
* Limited validity and amount.
* Suitable for online and some offline payment flows.


To use VCCs, partners must generate them though a provider such as AirPlus or similar.

See the [VCC use case](/demand/docs/payments/models/partner-collects) for implementation examples.

### AirPlus virtual credit card (VCC) — accommodation only

AirPlus is a third-party Payment Service Provider that generates virtual credit cards (VCCs) used primarily in business travel scenarios.

Demand API is integrated with AirPlus, enabling *Corporate partners* to use this method when paying online for business trips.

It enables:

* Centralised company billing.
* Deferred payment handling.
* Automatic VCC generation.


See the accommodation-specific [AirPlus implementation guide](/demand/docs/payments/models/corporate#airplus-vcc-for-online-payments) for details.

### Payment instructions (authorisation forms) — accommodation only

In some **accommodation pay-at-property scenarios**, properties may require:

* Proof of payment authorisation.
* Instructions on how to charge a provided card.


This is handled via:

* Authorisation forms.
* Payment instruction fields in the booking request.


This flow currently applies to **accommodation only** and is primarily used in corporate travel scenarios.
See the [Accommodation authorisation form guide](/demand/docs/payments/models/corporate#a-paying-at-the-property-with-authorisation-form) for implementation details.

#### Authorisation form

In such cases, our Demand API allows passing payment instructions on the requests. This is done via an **authorisation form** (auth form), which is issued per reservation, and contains the following:

* Credit card details - type (Visa, Mastercard, etc.), number, card holder, etc.
* A statement confirming that the VCC has been authorised by the corporate entity.
* Payment instructions, outlining how the property should process the VCC.


![authorisation_form](/assets/auth_form.a0f975eeaddd69ce32c1b2e89784c8e66da993da55b5fb88e3150d0fa4215edf.fe580a34.png)

Refer to the [ Accommodation payment instructions use case](/demand/docs/payments/models/corporate#paying-at-property-with-authorisation-form) for further details and examples.

### Credit cards

Credit cards are the most widely supported payment method.

They can be used for:

* Online payments.
* Booking guarantees.
* Pay-at-service fallback scenarios.


The API supports a wide range of global and local cards to cater to travellers' preferences:

|  Global |  |  |  | Local  |  |  |  |
|  --- | --- | --- | --- | --- | --- | --- | --- |
| ![americanexpress](/assets/american_express.68875898cbf9007ca24b591b3c39716933bbe83d524d5527817aa39e144a4e38.fe580a34.svg) | ![visa](/assets/visa.cc328c1c89552dd9b6e7f480f18bdd37f9ab971e786a6e5eb7989e3c2176528a.fe580a34.svg) | ![mastercard](/assets/mastercard.d52b0dfeb14f434e744de510083891c1b77842d80583b2fb9f504aa9f3d68471.fe580a34.svg) | ![maestro](/assets/maestro.ca855e5fcdac5f3f9ff3acd7e0ef5ae8e5d44dd4de19a8114d59dd9db1f6a6f7.fe580a34.svg) | ![Japan Credit Bureau (JCB)](/assets/jcb.1c513baab5f754eb08baeca162c3b6f8fa6a16d5f38b0a5484ec9b00e5262130.fe580a34.svg) | ![unionpay](/assets/union_pay.77299dc88dc28b471a51563c5fe2ba50947cc37a27e5166005891a2d0616a7c0.fe580a34.svg) | ![discover](/assets/discover.31920ca3a366585ae851dfbc06d661e67ff8c9f6f50a34903f61a937a7e8a1c4.fe580a34.svg) | ![diners-club](/assets/diners-club.9fa966e22094f2ad624581ac77f6bbc9a7ba2798d826206872ab9128debda89d.fe580a34.svg) |


Retrieve the full list via [common/payments/cards](/demand/docs/open-api/3.2/demand-api/commonpayments/common/payments/cards)

#### Authentication models

Credit card flows vary depending on regulatory requirements and the Demand API supports various authentication options to ensure compliance with regional regulations.

##### Strong Customer Authentication (SCA)

Required in regions such as the European Economic Area EEA.

* Requires authentication via a Payment Service Provider (PSP)
* Uses tokens passed during booking.


See the [CC SCA use case](/demand/docs/payments/models/booking-collects#credit-card--sca-token-3d-secure) for implementation details.

##### Non-SCA payments

Used in regions where SCA is not required (e.g. US).

Often combined with:

* Third-party fraud detection solutions.
* Risk scoring systems.


See the [CC non SCA use case](/demand/docs/payments/models/booking-collects#credit-card-non-sca) for examples.

##### MOTO (Mail Order / Telephone Order)

The MOTO is a type of credit card transaction made by telephone or email. Used for offline or assisted bookings.

* No real-time authentication.
* Typically used in corporate or agent-assisted flows.


See the [Corporate Partner integration guide](/demand/docs/payments/models/corporate#online-payments-credit-card--moto) for more details.

#### Fraud protection (e.g. Riskified)

This flow allows partners to process prepaid bookings using traveller credit cards together with a Riskified session ID.

Riskified is a fraud screening solution that you can use to maintain low chargeback for processing credit card payments where authentication is not a legislative requirement.

For non-authenticated payments, fraud detection may be required.

This includes:

* Session validation.
* Risk scoring.
* Chargeback protection.


Use this option to provide fraud detection support for non-SCA transactions.

Availability depends on partner configuration.
See the [Riskified guide](/demand/docs/payments/models/booking-collects#credit-card-non-sca--riskified) for implementation details.

### Co-branded cards - card subtype v3.2

In Demand API v3.2 there is also the option of using co-branded cards for cards that belong to supported special or co-branded programmes, currently to UnionPay co-branded cards:

* UnionPay + Visa.
* UnionPay + Mastercard.


These may require:

* Additional card subtype information.
* Special handling in booking requests.


See the [Co-branded use case](/demand/docs/payments/models/booking-collects#co-branded-cards---card-subtype) for more details.

## Where to check supported methods

To determine which payment methods are available:

| Scenario |  |  Endpoint |  What to use it for |
|  --- | --- | --- | --- |
| ![houseIcon](/assets/house.dc7d7e8cfaeaa5cfa90114b43a034610e593d2dd72ca75b6ba27e5508fcbb72d.9c1bb791.svg) | Pay at service (at property or car rental desk) | /*/details | Accepted payment methods at the service location (e.g. property or rental desk). |
| ![onlinepay](/assets/monetization-tablet.f9f01f530881c3f3631756e4d81fb8eb796e2ac99a4424ab5cfdcea57d66b5f8.9c1bb791.svg) | Online payment | /orders/preview | Final supported methods for the selected booking and timing.* Use it as source of truth.

 |


For online payments always rely on payment methods retrieved in orders/preview even if */details returns different methods.

## Implementation principles

* Always retrieve payment methods dynamically.
* Do not assume a fixed set of supported cards or flows.
* Always validate methods against /orders/preview.
* Ensure consistency between:
  * Selected payment method.
  * Payment timing.
  * Booking request configuration.


## Key takeaways

✅ Payment methods are dynamic and depend on timing, policy, and partner configuration.
✅ /orders/preview is the authoritative source for checkout payment behaviour.
✅ Payment methods must always be validated together with payment timings.
✅ Some payment flows are specific to accommodation scenarios (for example, authorisation forms).
✅ Do not hardcode supported payment methods or assumptions about payment flows.

## Next steps

Curious to know more?
* Learn about [Payment timings](/demand/docs/payments/payments-timings)
* Understand [Payment schedules](/demand/docs/payments/payments-schedules)
* See how to [Display payment information](/demand/docs/payments/payments-display)