Both 3DS1 and 3DS2 are available for your Actions Center Reservations 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 toacquirer_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](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/guides/payments_3ds1.png?authuser=7)