新增 3DS1 和 3DS2 支援

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 驗證機制的付款流程：