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 within the
unparsed_payment_method_token received by
your booking server whenever PSD2 applies to the transaction. You should
unparsed_payment_method_token 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
Order Failure from the CreateOrder method, and specify
PAYMENT_REQUIRES_3DS1 as the cause. In that failure response
you will also need to specify 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
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: