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 flow and want to understand the available payment methods, this guide explains how payment methods work across booking scenarios.
A payment method defines how a charge is collected or secured.
It is one of the three core payment concepts:
- Payment timing → when payment happens.
- Payment method → how payment is made.
- Payment schedule → how payments are split.
Payment methods should always be interpreted together with payment timings and schedules.
The Demand API supports two primary categories:
Used for online payments or booking guarantees.
Includes:
- Credit cards
- Virtual credit cards (VCC)
- Tokenised card flows (e.g. SCA flows)
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.
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.
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. |
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.
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.
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 for implementation examples.
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 for details.
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 for implementation details.
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.
Refer to the Accommodation payment instructions use case for further details and examples.
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 | ||||||
|---|---|---|---|---|---|---|---|
 |  |  |  |  |  |  |  |
Retrieve the full list via common/payments/cards
Credit card flows vary depending on regulatory requirements and the Demand API supports various authentication options to ensure compliance with regional regulations.
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 for implementation details.
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 for examples.
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 for more details.
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 for implementation details.
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 for more details.
To determine which payment methods are available:
Scenario | Endpoint | What to use it for | |
|---|---|---|---|
 | Pay at service (at property or car rental desk) | /*/details | Accepted payment methods at the service location (e.g. property or rental desk). |
 | Online payment | /orders/preview | Final supported methods for the selected booking and timing.
|
For online payments always rely on payment methods retrieved in orders/preview even if */details returns different methods.
- 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.
✅ 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.
- Learn about Payment timings
- Understand Payment schedules
- See how to Display payment information