SCA 的實作
透過以下方式生成 SCA-compliant 的預訂:Rapid API
無論您是將「Rapid API」設為正式收款商,還是允許旅客於抵達時付款,皆可採用 Rapid 的 API 解決方案,以生成符合 SCA 法規的預訂。我們的 API 透過在預訂流程中採用 3D-Secure (3DS) 2.0,以符合 SCA 規範。透過 3DS 2.0,我們支援「risk-based」驗證機制,此機制賦予銀行酌情決定何時要求旅客進行安全驗證的權限,從而降低旅客的交易摩擦。
3DS 2.0 的解決方案包含三個明確的步驟:
您將在 check-out 頁面中加入一個 iframe,該 iframe 用於託管發卡銀行為旅客提供的驗證流程。在整合文件中,這被稱為 3DS iframe。
>> 進一步了解 iframes您還需在 check-out 頁面中加入一個新的 client-side JavaScript 函式庫,該函式庫用於收集瀏覽器資料、與 iframe 進行通訊,並在 iframe 內顯示 SCA 體驗。在整合文件中,這被稱為 3DS 連接器函式庫。
Rapid API 將接受銀行的付款人資訊,並在完成安全驗證後完成預訂。
當同時使用 JavaScript 和 Rapid API 時,採用 SCA 的預訂流程現在會在呼叫預訂 API 之前和之後,增加幾個額外的步驟。下圖為更新後的預訂流程:

更新後的預訂流程中,上一步驟的輸出資料用做下一步驟的輸入資料。也就是資料會在瀏覽器的 JavaScript 和 Rapid 之間傳輸。
整合所需元件詳細說明
SCA 的實作始於瀏覽器端的 check-out 體驗,隨後會導入 Rapid API 的流程中。
Browser
此 iframe 置於「check-out」體驗中,用於載入向使用者顯示的認證流程,並將任何 traveler-supplied 資訊直接傳送至其銀行;該內容由旅客所屬的 card-issuing 銀行所擁有的 URL 提供。該 iframe 應預設為隱藏狀態,並能在用戶嘗試預訂後需進行身份驗證時,將其疊加顯示於頁面之上。
JavaScript 函式庫
此函式庫已新增至 check-out 頁面,並會在預訂時被呼叫,以支援驗證流程。此函式庫的 API 支援以下所述的功能。
Traveler 裝置資訊
在嘗試預訂之前,必須先收集旅客裝置的相關資訊,以便為預訂進行身份驗證做準備。該資訊會傳送至旅客的銀行,以便評估風險、決定該筆交易是否需要進行 3DS 2.0 驗證,並確保其顯示正確。根據 3DS 2.0 規範,將從旅客的瀏覽器收集以下資料:語言、色彩深度、螢幕高度、螢幕寬度、時區、使用者代理程式,以及 Java 是否已啟用。
驗證畫面
嘗試進行預訂 後,該函式庫會用來顯示 iframe 覆蓋層,並將銀行的內容載入其中。在驗證過程中,銀行可能會蒐集有關旅客裝置的額外資訊,以協助進行風險評估。此步驟是完成預訂的必要程序。
Rapid API
Rapid API 包含可與 client-side JavaScript 函式庫協同運作的 API。這些 API 目前支援以下功能:
旅客及付款詳情
在嘗試預訂之前,Rapid API 需要收集有關旅客的額外資訊,以準備進行身分驗證,其中包括旅客的相關資訊,例如預訂地點及付款方式。這些資料隨後會傳送至旅客的銀行,以便評估風險,並決定該筆交易是否需要進行安全驗證。請參閱「Rapid Booking API」中的「Register Payment API」,以了解更多資訊。
付款與預訂確認
嘗試預訂後,當瀏覽器中的 SCA 流程完成時,必須再次呼叫 Rapid API。在後台,我們將確認驗證成功,以便確認預訂。請參閱「Rapid Booking API」中的「完成付款」章節,以了解更多資訊。
預訂流程
以下是旅客啟動預訂後所需的 API 呼叫順序示意圖。該程式碼序列同時包含對 JavaScript 函式庫的呼叫,以及對 Rapid API.

當一筆訂單準備進行驗證時,未必總是需要進行驗證。是否需要進行驗證,由用於付款的信用卡發卡銀行決定。此判定是在交易過程中進行的,並會顯示於「建立預訂」API 的回應中。
Rapid Lodging API 亦提供「暫停與恢復」功能。以下是該功能所需的 API 呼叫順序。
