Partners not paying on travellers behalf

Learn how to define the required payments data when you create an order using different credit cards and authorisation methods.

Is this for you?

If you are not entitled to directly charge your travellers and pay on their behalf, but you are authorised to use Online payment methods, then this use case is for you.

	Partner type	Online available methods
	Partners who are not entitled to directly charge travellers and are not the merchant of record. In this case, is Booking.com who directly charges travellers credit cards.	✓ 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 uses your application, finds a suitable property and product, and decides to book it. Pays online with credit card

The flow

• The traveller decides to pay online now with their credit card. They provide their card details.
• You forward the traveller`s card details to Booking.com, who charges the card.
• Booking.com pays the property.

1. Check the available payment options

→ Refer to the Quick guide for examples of responses and initial instructions on how to use the payment endpoints. So you can check the available payments options, including timings, schedules and methods.

2. Create your order

For this Online payment scenario, Demand API offers several card authentication methods that respond to different geographic regulations.

• The following examples show different options that your application could support in this scenario.
• Each example shows the payment and specifically the card.authentication details that you need to provide in the /orders/create request for each card authentication method.

Use these instructions to define the payment card authentication field, according to your business regional legislation.

/orders/create example

In general, when using cards as the payment method, the payment field in your /orders/create request should look like this:

    "payment": {
        "card": {
        "authentication": {
            "3d_secure": {
                "cavv": "xxxx",
                "eci": "xxxx"
            }
        },
        "cardholder": "xxxx",
        "cvc": "123",
        "expiry_date": "2030-10",
        "number": "1234123412341234"
        },
        "include_receipt": true,
        "method": "card",
        "timing": "pay_online_now"
    }

• card.authentication: You must define the appropriate authentication method for the card that is being used to secure the booking.

  • In the case of a customer credit card with SCA, you need to enter the SCA token using the 3d_secure field.

  • In the case a customer card without SCA, no authentication is required.

    • If you are using Riskified (non-SCA), you need to enter the Riskified data.

  • When using Credit card MOTO (SCA exempted), you need to indicate that you won't need SCA token.

• cardholder, cvc, expiry_date, number: Must contain the details of a valid payment card that can be used to secure the booking.

  • Check the list of supported methods.cards returned in the /orders/preview response. (Refer to Quick guide to learn how to get this information).

• include_receipt: Is optional.

• method: Must be "card".

• timing: Must be "pay_online_now".

Credit Card + SCA token

Use this option for transactions that need to comply with Strong Customer Authentication (SCA) which is mandatory in European Economic Area regulations.

The flow

• The traveller decides to pay online now with their credit card.

  • They perform Strong Customer Authentication on your platform, providing their card details.
  • SCA token generated by issuing bank is shared with you.

• You forward the traveller`s card SCA Token to Booking.com, who charges the traveller card using token.

• Booking.com pays the property.

Pre-requisites

Define your request

In your /orders/create request:

Enter the SCA token in the payment.card.authentication field by using the 3d_secure field:

• It must contain the appropriate values for the 3D Secure 2 (3DS2) parameters, this is:
  • cavv, eci and (optionally) transaction.
  • You should obtain these values from your bank or payment service provider (PSP).

For example:

"payment": {
 "card": {
     "authentication": {
         "3d_secure": {
             "cavv": "xxxx",
             "eci": "xxxx",
             "transaction": "xxxx",
          }
     },
     "cardholder": "xxxx",
     "cvc": 123,
     "expiry_date": "2030-10",
     "number": "1234123412341234"
 }, 

Credit card (non SCA)

Use this option for non-SCA transactions where you are using your own fraud solution (3rd partner provider).

The flow

• The traveller shares their credit card details via your platform.
• Fraud protection is performed by your third party provider.
• You forward the traveller`s credit card details to Booking.com, with no token.
• Booking.com pays the property.

Pre-requisites

Define your request

In your /orders/create request, do not use the payment.card.authentication field.

For example:

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

Credit Card (non SCA) + Riskified

This is an Online payment method in which partners can book prepaid rates with travellers credit cards by sharing a Riskified session ID via the Demand API.

Use this option for non-SCA transactions where you have Riskified in place to provide fraud detection support.

The flow

• The traveller decides to pay online by credit card and shares details via your platform.

  • Fraud protection is performed by Riskified.

• You passes the traveller`s credit card information alongside the Riskified session ID and the IP address.

• Booking.com charges the traveller credit card and pays the property.

Pre-requisites:

Create your order request

In the payment.card.authentication field:

• riskified.session_id: Must contain your Riskified-provided session ID for external fraud verification.

• ip_address: This is a mandatory field.

  For this case do not use the sca_exemption or 3d_secure fields.

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)

This option is available for Corporate partners, for Strong Customer Authentication (SCA) transactions that qualify for exemption because they are transactions made by telephone or email.