Last updated

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 me?

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
partnerPartners 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 (non SCA)+ 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.

drawing

This option is only available if your partner agreement with Booking.com allows you to use Online payments. Refer to the pre-requisite checklist of your authentication method to ensure your application meets them all.

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.

  1. See examples of the /orders/preview responses in the Quick guide.
  2. Go to your /orders/create request.
  3. Specify the needed information in the payment object.

/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 card with SCA, you need to enter the SCA tokens.
    • In the case a customer card without SCA, no authentication is required.
    • In the case of Riskified (non-SCA), you need to enter the Riskified data.
    • In the case of VCC or MOTO (SCA exempted), you need to indicate that you won't need SCA tokens.
    • In 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.
  • 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".

For this case do not use the airplus or business information fields.

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

Checklist
You currently work with a Payment service provider (PSP) with token generation capability and able to share SCA version 1 or 2 with Booking.com.
You must send us the generated SCA Token via Demand API.

Define your request

In your /orders/create request, enter the SCA token in the payment.card.authentication field:

  • 3d_secure: 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.

For this case use VCC_exemption but do not use the riskified or sca_exemption fields.

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 (SCA exemption)

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

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

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 (SCA exemption) + 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.

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

  • 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 to version 2.10.

Create your order request

In the payment.card.authentication field:

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

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

For example:

 "payment": {
     "card": {
         "authentication": {
             "riskified": {
                 "session_id": "xxxxxxx"
             }
         },
         "cardholder": "xxxx",
         "cvc": 123,
         "expiry_date": "2030-10",
         "number": "1234123412341234"
     },
     ...

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.

For detailed instructions, refer to Corporate partners use case.