Add 3DS1 and 3DS2 Support

Both 3DS1 and 3DS2 are available for your Actions Center Appointments End-to-End integration. You may implement either (or both) of these for your integration.

Either 3DS1 or 3DS2 will meet the Strong Customer Authentication requirement of PSD2, but there are some key differences:

  • 3DS1: You can decide to trigger 3DS1 for a transaction when you have signals that the charge is fraudulent.
    • Implementing 3DS1 requires changes to your booking server.
  • 3DS2: 3DS2 will only be used for transactions where PSD2 applies (the acquiring bank and the customer’s bank are in the EEA).
    • Implementing 3DS2 requires changes to your merchant feed.

Implementing 3DS2

The implementation of 3DS2 requires you to add additional fields to your merchant feed within the TokenizationConfig message. If all payments go to the same account, you will repeat the value within each merchant entry. Should the payments go to different accounts, the values in each merchant entry will need to be for the account acquiring the funds within the transaction.

Changes to the Merchant Feed

  • merchant_of_record_name: Name of the Merchant Of Record (MOR). This user-visible name will be shown in 3DS2 challenges.
  • payment_country_code: Country where transaction will be processed, in ISO 3166-1 alpha-2 form.
  • CardNetworkParameters message: This message is repeated with the values specific for different networks (Needed only for Visa and American Express)
    • card_network: The network (Visa, American Express) that these values apply to
    • acquirer_bin: The Bank Identification Number of the acquiring bank used for processing of the card.
    • acquirer_merchant_id: The merchant identifier assigned by the acquirer to the merchant for use in transaction authorization (for Visa and American Express transactions).

By adding these fields to your merchant feed, you will receive a 3DS2 cryptogram within the unparsed_payment_method_token received by your booking server whenever PSD2 applies to the transaction. You should pass the unparsed_payment_method_token and its embedded cryptogram to your processing partner in accordance with their specification.

Implementing 3DS1

Changes to the Booking Server

We will make a CreateBooking request and if you determine 3DS1 to be needed for the transaction, return a Booking Failure from your CreateBooking method, and specify PAYMENT_REQUIRES_3DS1 as the cause. In that failure response you will also need to specify the ThreeDS1Parameters message within the PaymentFailureInformation message:

  • acs_url = The URL from which to load a form to present to the User for authentication.
  • pa_req = A PaymentAuthentication Request. To be posted to the ACSUrl form.
  • transaction_id = An identifier used by the ACS provider. To be posted to the ACSUrl form.
  • md_merchant_data = Data for the Actions Center to share with the ACS provider if supplied.

We will then resend the original CreateBooking request with the pa_response located within the PaymentInformation message. The pa_response field will contain the payload that is returned to us from an ACS provider, and it should be used by you to authorize the transaction with your processor.

Here is a diagram describing the 3DS1 flow:

Figure 1: 3DS1 process diagram
Figure 1: 3DS1 process diagram