3DS1 和 3DS2 都適用於 Actions Center 端對端預訂整合。請視需求為整合導入其中一個 (或兩者一併導入)。
無論 3DS1 或 3DS2 都必須符合歐盟付款服務指令 (以下簡稱 PSD2) 中的嚴格用戶驗證機制 (Strong Customer Authentication) 相關規定，但兩者之間有些主要差異，說明如下：
- 3DS1：如果您認為可能是不肖人士以詐欺手法收費，可以決定為交易觸發 3DS1 驗證。
- 若要導入 3DS1，您必須變更預訂伺服器。
- 3DS2：3DS2 驗證只適用於受 PSD2 規範的交易 (收單銀行和客戶的銀行都位於歐洲經濟區)。
- 如要導入 3DS2，您必須變更商家動態饋給。
導入 3DS2
如要導入 3DS2，您必須為 TokenizationConfig 訊息中的商家動態饋給添加額外欄位。如果付款都會匯進同一個帳戶，請分別在各個商家項目中輸入相同的值。如果付款會匯入不同帳戶，各個商家項目中的值必須是交易中收款帳戶的值。
修改商家動態饋給
merchant_of_record_name：商家記錄 (MOR) 的名稱。消費者會在 3DS2 驗證要求中看到這個名稱。payment_country_code：處理交易的國家/地區，以 ISO 3166-1 alpha-2 格式的代碼表示。CardNetworkParameters訊息：系統會重複發出這個訊息，並在當中加入不同信用卡組織各自專用的值 (使用 Visa 或美國運通卡進行的交易才需要使用)card_network：要套用這些值的信用卡組織 (Visa、美國運通卡)。acquirer_bin：用來處理信用卡的收單銀行發卡行識別碼。acquirer_merchant_id：收單銀行指派給商家的商家識別碼，用於交易授權 (使用 Visa 和美國運通卡進行的交易才需要)。
將這些欄位加進商家動態饋給後，每當發生受 PSD2 規範的交易時，您都會在預訂伺服器收到的 unparsed_payment_method_token 中取得 3DS2 密文。請您按照規格，將 unparsed_payment_method_token 和內嵌的密文傳送給您的付款處理合作夥伴。
導入 3DS1
修改預訂伺服器
系統會建立 CreateBooking 要求。如果您判定交易需要進行 3DS1 驗證，請透過 CreateBooking 方法傳回 Booking Failure，並指定 PAYMENT_REQUIRES_3DS1 做為原因。在該失敗回應中，您也必須在 PaymentFailureInformation 訊息內指明 ThreeDS1Parameters 訊息：
acs_url= 表單來源網址，用來載入表單供消費者進行驗證。pa_req= PaymentAuthentication 要求，將會張貼至 ACSUrl 表單。transaction_id= 存取控制伺服器 (簡稱 ACS) 供應商使用的 ID。請將它貼進 ACSUrl 表單。md_merchant_data= 動作中心與 ACS 供應商共用的資料 (如有提供)。
接下來，系統會透過內嵌 pa_response 的 PaymentInformation 訊息重新送出原始的 CreateBooking 要求。「pa_response」欄位會包含 ACS 供應商傳回給我們的酬載，請您務必使用此欄位授權處理方完成交易。
下方圖表說明了使用 3DS1 驗證機制的付款流程：
