3DS1 と 3DS2 はどちらも、Actions Center の予約エンドツーエンドの統合に追加できます。いずれか（または両方）を統合に実装できます。
3DS1 または 3DS2 のいずれも、PSD2 の確実な本人認証（SCA）要件を満たしていますが、その主な違いは以下のとおりです。
- 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: 取引の承認（Visa および American Express 向け）で使用するために、加盟店契約銀行が販売者に割り当てる販売者 ID。
これらのフィールドを販売者フィードに追加すると、PSD2 が取引に適用されるたびに、予約サーバーが受信した unparsed_payment_method_token 内に 3DS2 クリプトグラムが届きます。unparsed_payment_method_token とその埋め込みクリプトグラムを、指定に沿って処理パートナーに渡す必要があります。
3DS1 の実装
予約サーバーへの変更内容
CreateBooking リクエストが行われ、取引に 3DS1 が必要だと判断した場合は、CreateBooking メソッドから Booking Failure を返して、PAYMENT_REQUIRES_3DS1 をその理由として指定してください。その失敗のレスポンスでは、PaymentFailureInformation メッセージ内に ThreeDS1Parameters メッセージを指定する必要もあります。
acs_url= 認証のために User に表示するフォームの読み込み元の URL。pa_req= PaymentAuthentication リクエスト。ACSUrl フォームに投稿されます。transaction_id= ACS プロバイダが使用する識別子。ACSUrl フォームに投稿されます。md_merchant_data= Actions Center で ACS プロバイダと共有するデータ（提供されている場合）。
Google は次に PaymentInformation メッセージ内にある pa_response とともに、元の CreateBooking リクエストを再送信します。pa_response フィールドには、ACS プロバイダから Google に返されるペイロードが含まれますので、このペイロードを使って決済代行業者との取引を承認してください。
3DS1 フローについて説明する図を以下に示します。
