Actions Center との予約のエンドツーエンドの統合では、3DS1 と 3DS2 の両方を使用できます。統合にそのいずれか（または両方）を実装できます。
3DS1 と 3DS2 のどちらでも PSD2 の強力な顧客認証の要件を満たしますが、重要な違いがいくつかあります。
- 3DS1: 請求が不正であることを示す兆候がある場合に、取引に対して 3DS1 をトリガーするかどうかを決定できます。
- 3DS1 を実装するには、予約サーバーに変更を加える必要があります。
- 3DS2: 3DS2 は PSD2 が適用される取引（加盟店契約銀行とお客様の銀行が EEA 内にある取引）にのみ使用されます。
- 3DS2 を実装するには、販売者フィードに変更を加える必要があります。
3DS2 の実装
3DS2 を実装するには、TokenizationConfig メッセージ内の販売者フィードにフィールドを追加する必要があります。すべての支払いが同じ口座で行われる場合は、各販売者エントリ内でその値を繰り返します。支払いが別のアカウントに渡される場合、各販売者エントリの値は、トランザクション内で資金を取得したアカウントに対するものである必要があります。
販売者フィードへの変更内容
merchant_of_record_name: 最終販売責任を負う商業者（MOR）の名前。このユーザーに表示される名前は 3DS2 チャレンジに表示されます。payment_country_code: 取引が処理される国（ISO 3166-1 alpha-2 形式）。CardNetworkParametersメッセージ: このメッセージは、さまざまなネットワークに固有の値とともに繰り返されます（Visa と American Express の場合のみ必要）。card_network: これらの値が適用されるネットワーク（Visa、American Express）acquirer_bin: カードの処理に使用された加盟店契約銀行の銀行識別番号。acquirer_merchant_id: 決済代行業者が販売者に割り当てた販売者 ID。Visa と American Express の取引の承認に使用します。
これらのフィールドを販売者フィードに追加すると、PSD2 がトランザクションに適用されるたびに、予約サーバーが受け取る unparsed_payment_method_token 内に 3DS2 クリプトグラムを受け取ります。unparsed_payment_method_token とその埋め込みクリプトグラムを、パートナーの仕様に従って処理パートナーに渡す必要があります。
3DS1 の実装
予約サーバーへの変更内容
Google は CreateBooking リクエストを行い、トランザクションに 3DS1 が必要であると判断した場合は、CreateBooking メソッドから Booking Failure を返し、PAYMENT_REQUIRES_3DS1 を原因として指定します。その失敗レスポンスでは、PaymentFailureInformation メッセージ内に ThreeDS1Parameters メッセージも指定する必要があります。
acs_url= 認証のためにユーザーに提示するフォームの読み込み元となる URL。pa_req= PaymentAuthentication リクエスト。ACSUrl フォームに投稿されます。transaction_id= ACS プロバイダが使用する識別子。ACSUrl フォームに投稿されます。md_merchant_data= ACS プロバイダと共有するアクション センターのデータ（指定されている場合）。
その後、PaymentInformation メッセージ内の pa_response を使用して、元の CreateBooking リクエストを再送信します。pa_response フィールドには、ACS プロバイダから Google に返されたペイロードが含まれます。これは、決済代行業者との取引を承認する際に使用します。
3DS1 フローについて説明する図を以下に示します。
