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
	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.

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.

2. Create your order

→ Use /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 request should look like this:

{
  "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"
  }
}

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

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.

Object structure

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

Usage example:

"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).

Best practices

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

Define your request

Add the card details.

For example:

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

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.

Example:

"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.

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.

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:

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.

For example:

"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 for details.