# No direct charge to travellers

**Learn how to define the required payment data when creating an order using different credit cards and supported authorisation methods.**

## Is this use case for you?

If you are **not authorised to directly charge travellers** (not the merchant of record), but your agreement allows online payments, this scenario applies to you.

In this setup:

* Booking.com charges the traveller’s credit card.
* You securely forward payment data via Demand API.
* The property receives the payout from Booking.com.


|  | Partner type |  Online available methods |
|  --- | --- | --- |
| ![partner](/assets/partner.abc227ef8d70c3f1f6816bcd3fd01b4c39c786f23b356fa1703ffaeb2b49c6c3.fe580a34.svg) | Partners not authorised to directly charge travellers. Booking.com is the merchant of record. | ✓ Credit Card + SCA  ✓ Credit Card (non SCA) ✓ Credit Card (non SCA) + Riskified ✓ Credit card + MOTO |


Follow these instructions and recommendations to create the payment data needed for your requests.

## Use case

> *A traveller books accommodation in your app and pays online with a credit card.*


### The flow

* Traveller enters card details in your application.
* You send card payment data via orders/create endpoint.
* Booking.com charges the card.
* Booking.com pays the property.


![drawing](/assets/example-pay-online-with-credit-card-2.12b3c11dc67c6770a840e9cf9c4aa2ad12ff4aba08715fa5bb6d5b5e3ae7cad8.fe580a34.png)

This option is available only if your partner agreement with Booking.com includes Online payments. Check the prerequisites for your authentication method before implementation.

Implementation steps:
1. Use [/orders/preview endpoint](/demand/docs/open-api/demand-api/orders/orders/preview) to check supported card methods and timings.
2. Provide payment details including the correct `card.authentication method` in [/orders/create](/demand/docs/open-api/demand-api/orders/orders/create) request.


## 1. Check payment options

→ Use the orders/preview endpoint to determine:

* Allowed `payment.method` and `payment.timing`.
* Supported card types (`methods.cards`).
* Whether SCA / Riskified / exemptions are supported.


* See [Payments quick guide](/demand/docs/payments/how-to) for details.
* Use the common/payments/cards endpoint to understand the card IDs retrieved in your response.


## 2. Create your order

→ Use [/orders/create](/demand/docs/open-api/demand-api/orders/orders/create).

When using cards, your request must include the correct `payment.card.authentication`, according to your business regional legislation (e.g. SCA in the EEA).

### Example - Generic card payment object

In general, when using cards as the payment method, the `payment` field in your [/orders/create](/demand/docs/open-api/demand-api/orders/orders/create) request should look like this:

3.1 request 

```json
{
  "payment": {
    "card": {
      "authentication": {
        "riskified": {...}, // only if needed
        "sca_exemption": "moto", // only if needed
        "3d_secure": {
          "authentication_value": "xxxx",
          "eci": "xxxx",
          "transaction": "xxxx"
        }
      },
      "cardholder": "xxxx",
      "cvc": "123",
      "expiry_date": "2030-10",
      "number": "1234123412341234"
    },
    "include_receipt": true,
    "method": "card",
    "timing": "pay_online_now"
  }
}
```

3.2 request
This version of the API includes additional fields such as the `card.subtype` and `3d_secure.authentication_response`.


```json
{
  "payment": {
    "card": {
      "authentication": {
        "riskified": {...}, // only if needed
        "sca_exemption": "moto", // only if needed
        "3d_secure": {
          "authentication_value": "AAABBIIFmAAAAAAAAAAAAAAAAAA=",
          "eci": "05",
          "transaction": "3ds_txn_789"
          "authentication_response": "Y"
        }
      },
      "cardholder": "Jane Doe",
      "cvc": "123",
      "expiry_date": "2030-10",
      "number": "4111111111111111",
      "subtype": "unionpay_cobrand" // only if needed
    },
    "include_receipt": true,
    "method": "card",
    "timing": "pay_online_now"
  }
}
```

| Field | Notes |
|  --- | --- |
| `payment.card.authentication`
 | Only include when required (SCA, Riskified, or MOTO exemption):
* **SCA (3D Secure) cards** – Provide the SCA token in the `3d_secure` object.
* **Riskified (non-SCA)** – Provide Riskified authentication data.
* **MOTO (SCA exempted)** - Indicate exemption using the `sca_exemption` field (e.g., "moto").

 |
| `payment.card` | Required for card payments. No authentication needed if the card is non-SCA and not using Riskified. |
| `cardholder`, `cvc`, `expiry_date`,`number` (and `subtype` in v3.2).
 | Must be valid card details. Ensure the card type is listed in the `methods.cards` array returned by the /orders/preview response.
(See the [Quick guide](/demand/docs/payments/how-to) to learn how to get this information).
 |
| `include_receipt` | Optional. Set to true if you want the payment receipt returned in the response. |
| `method` | Must be `"card"` for card payments. |
| `timing` | For online payments, use `pay_online_now`. |


**Do not include** `airplus` or any business-related fields for this payment type.

### Credit Card + SCA token (3D Secure)

For transactions that require **Strong Customer Authentication (SCA)** under European Economic Area (EEA) regulations.

#### The flow

* Traveller performs SCA on your platform, providing their card details.
* You receive a **3DS token** from your Payment Service Provider (PSP).
* Payment initiation - You send the traveller's card SCA Token using the `3d_secure` object (or empty if frictionless).
  * 3DS challenge - If the ACS requires a challenge, the client collects `authentication_value`, `eci`, `transaction`, and optionally `authentication_response`.
  * Order creation - Include the completed 3DS data in the /orders/create request.
  * Processing - The payment gateway validates the 3DS data before authorising the payment.
* Booking.com charges the card and pays the property.


#### Pre-requisites

| Checklist |
|  --- |
| ☑ | You work with a Payment Service Provider (PSP) that supports SCA token generation (and able to share SCA version 1 or 2 with Booking.com) |
| ☑ | You receive SCA values from PSP. |
| ☑ | Online Payments + SCA addendum signed. |


#### 3D Secure (3DS) Authentication

The `3d_secure` object contains ontains the authentication results from your 3D Secure provider for a card payment.
You must include these values to confirm that the cardholder authentication step was completed.

For this case **do not use** the `riskified` or `sca_exemption` fields.

**Object structure**

In your /orders/create request, populate `payment.card.authentication.3d_secure` with the values returned by your 3DS provider.

| Field | Required | Description |
|  --- | --- | --- |
| `authentication_value` | ✅ Yes | * The Cardholder Authentication Verification Value (CAVV) returned by the 3DS Server.
* Confirms successful cardholder authentication.

 |
| `eci` | ✅ Yes | * The Electronic Commerce Indicator (ECI) returned by the 3DS Server.
* Indicates the authentication result (e.g., fully authenticated, attempted, or not authenticated).

 |
| `transaction` | ✅ Yes | * Unique ID assigned by the Directory Server (DS) for this 3DS transaction.
* Used for traceability and reconciliation.

 |
| `authentication_response` (v3.2) | ❌ Optional | * The 3D Secure transaction status (`transStatus`) returned by your 3DS provider.
* For frictionless flows, provide the `transStatus` from the Authentication response.
* Not required if no challenge occurred.

 |


Obtain these values from your bank or Payment Service Provider (PSP).

**Usage example:**


```json
"payment": {
  "card": {
    "authentication": {
      "3d_secure": {
        "authentication_value": "AAABBBCCC123=",
        "eci": "05",
        "transaction": "abc123xyz",
        "authentication_response": "Y"
      }
    }
  }
}
```

**Explanation:**

* `authentication_value` - token returned after the cardholder completes 3DS authentication.
* `eci` - indicates that the cardholder was fully authenticated.
* `transaction` - uniquely identifies this authentication attempt.
* `authentication_response` - confirms the transaction status (success in this example).


**Authentication response (v3.2)**

If you are using Demand API v3.2, you can optionally send "authentication_response". This field maps to the 3DS transStatus value returned by your provider.

The available values follow the transStatus codes:

* Y – Authentication successful.
* N – Authentication failed.
* U – Unable to authenticate.
* A – Attempted authentication (for frictionless flows).


Only send this field if your provider returns it.

#### Best practices

| Field / Area | Action | Why / Note |
|  --- | --- | --- |
| `authentication_response` | Include only if a 3DS challenge flow occurred or your 3DS provider returns it. | * Frictionless flows may omit this field.
* Avoid sending empty or unnecessary data.

 |
| `authentication_value`, `eci`, `transaction` | Always provide these fields for 3DS-required payments. | * Missing any of these will cause payment failures.
* Do not leave blank.

 |
| `authentication_value` | Treat as sensitive: never log in plain text or expose in URLs. | * Protect customer data.
* Security compliance.

 |
| `3d_secure`, `authentication_value`, `eci`, `transaction`, `authentication_response` | Use consistent casing and terminology exactly as specified. | * Avoid developer confusion and integration errors.
* Consistency matters.

 |
| Integrating multiple 3DS providers | Map each provider’s output to these standard fields. | * Ensures uniform behaviour and reduces bugs.
* Standardise outputs.

 |


### Credit card (non SCA)

For transactions where fraud checks are handled by your **own fraud provider**.

#### The flow

* Traveller provides card details.
* Fraud protection is handled externally.
* You forward the traveller`s credit card details to Booking.com, with no token.
* Booking.com pays the property.


#### Pre-requisites

| Checklist |
|  --- |
| ☑ | You have a Fraud risk prevention provider. |
| ☑ | Demand API must be updated minimum to version 2.10. |


#### Define your request

Add the card details.

For example:


```json
"payment": {
  "card": {
    "cardholder": "xxxx",
    "cvc": 123,
    "expiry_date": "2030-10",
    "number": "1234123412341234"
  }
}
```

For this case **Do not use the `payment.card.authentication` field** in your request.

### Co-branded cards - card subtype

If you are using Demand API v3.2 you should provide `card.subtype` when submitting cards that belong to supported special or co-branded programmes, currently to UnionPay co-branded cards:

* UnionPay + Visa.
* UnionPay + Mastercard.


* These cards use Visa or Mastercard number ranges.
* Network cannot be reliably inferred from PAN alone.


Example:


```json
"payment": {
  "method": "card",
  "card": {
    "cardholder": "xxxx",
    "cvc": 123,
    "expiry_date": "2030-10",
    "number": "1234123412341234"
    "subtype": "unionpay_cobrand"
  }
}
```

Even though the number appears to be Visa-range, the subtype ensures correct routing as UnionPay co-brand.

If the field is omitted, the system will assume a standard card programme and route based only on the detected network from the card number.

**Important notes:**

**Detection Responsibility**

Your integration is responsible for setting `subtype` when you know the card belongs to a supported special programme. This is typically determined by:

* BIN tables.
* Upstream payment SDK metadata.
* Issuer identification data.
* Gateway hints.


**Do not provide subtype for:**
✗ Standard Visa cards.
✗ Standard Mastercard cards.
✗ Standard UnionPay cards (pure UnionPay range)
✗ Debit/credit classification differences.
✗ Corporate vs consumer cards.

This field is not a funding type or product category indicator.

### Credit Card (non SCA) + Riskified

For partners using Riskified to provide fraud detection.

#### The flow

* Traveller provides card details.
* Riskified validates the transaction.
* You send card details **plus Riskified session ID and IP address**.
* Booking.com charges the traveller credit card and pays the property.


#### Pre-requisites:

| Checklist |
|  --- |
| ☑ | You have an integration with Riskified. |
| ☑ | Demand API version must be updated minimum to version 2.10. |


#### Create your order request

In the `payment.card.authentication.riskified` field:

* `riskified.session_id` - Must contain your Riskified-provided session ID for external fraud verification.
* `ip_address` - This is a mandatory field.


Do not use the `sca_exemption` or `3d_secure` fields in this scenario.

For example:


```json
"payment": {
  "include_receipt": false,
  "card": {
    "number": "4111111111111111",
    "expiry_date": "2030-03",
    "cardholder": "io",
    "cvc": "xxx",
    "authentication": {
      "riskified": {
        "session_id": "00000000-0000-0000-0000-000000000000",
        "ip_address": "127.0.0.1"
      }
    }
  },
  "timing": "pay_online_now",
  "method": "card"
}
```

### Mail order/telephone order (MOTO) (SCA exemption)

For *Corporate partners*, where SCA does not apply (telephone or email bookings).

See the [Corporate partners use case](/demand/docs/payments/payments-examples3#using-credit-card--moto) for details.

Curious to know more?
* Learn more about the credit card method in the [Payment methods](/demand/docs/payments/payments-methods#credit-cards) section.
* Follow detailed guidance for MOTO transactions in the  [Corporate partners use case](/demand/docs/payments/payments-examples3/).
* Review the [Orders section](/demand/docs/orders-api/order-preview-create) for tips and examples on how to preview and create your order requests.