Both 3DS1 and 3DS2 are available for your Reserve with Google integration. You may implement either (or both) of these to 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.
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.
CardNetworkParametersmessage: 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
unparsed_payment_method_token received by your booking server whenever
PSD2 applies to the transaction. You should pass the
and its embedded cryptogram to your processing partner in accordance with their
Changes to the Booking Server
We will make a CreateBooking or CreateOrder request and if you determine 3DS1
to be needed for the transaction, return a Booking Failure
from your CreateBooking method, or an
from the CreateOrder method, and specify
PAYMENT_REQUIRES_3DS1 as the cause.
In that failure response you will also need to specify the
message within the
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 Reserve with Google to share with the ACS provider if supplied.
We will then resend the original CreateBooking or CreateOrder request with the
within the PaymentInformation message.
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: