Fraud Prevention Service 沙箱
Fraud Prevention Service 支援沙箱功能,可讓您在非生產環境中測試 API。它也能讓使用者複製同步和非同步推薦決策流程,並比照生產環境中預期情況,測試通知服務的整合。
存取沙箱
如需存取沙箱功能和產品設定的詳細資訊,請參閱沙箱。在 API 用戶端建立步驟期間,請務必在可用產品清單中搜尋「Fraud Prevention」,並將此一使用範圍新增至您的帳戶。
API 功能
帳戶畫面
「帳戶畫面 API」可為帳戶交易提供詐騙相關建議。建議可包括「接受」、「質疑」或「拒絕」。只要沒有足夠的訊號可建議「接受」或「拒絕」,交易就會標示為「質疑」。這些「質疑」事件會進行手動審核,並透過非同步方式做出更正後的建議。
所需的建議可根據要求主體中指定的電子郵件地址進行模擬。下表列出了與每個推薦流程相關的電子郵件地址。
電子郵件地址 | 決策 |
---|---|
accept@anydomain.com | 接受 |
reject@anydomain.com | 拒絕 |
challenge@anydomain.com | 質疑 |
challengepass@anydomain.com | 質疑 -> 通過 |
challengefail@anydomain.com | 質疑 -> 未通過 |
acceptfail@anydomain.com | 接受 -> 未通過 |
當存在帳戶生命週期轉換 (例如質疑結果、帳戶還原或補救動作完成) 時,就會呼叫「帳戶更新 API」。例如,如果使用者帳戶已停用、刪除或還原,就會呼叫「帳戶更新 API」,以告知 Expedia Group 與變更相關的資訊。當使用者根據詐騙建議來回應登入多重要素驗證時,也會呼叫「帳戶更新 API」。
如果對應的帳戶交易不存在,則「帳戶更新 API」將不會運作,因此在測試「帳戶更新 API」時,請務必先呼叫「帳戶畫面 API」。
訂單購買畫面
「訂單購買畫面 API」可為訂單購買交易提供詐騙相關建議。建議可包括「接受」、「拒絕」或「審核」。只要沒有足夠的訊號可建議「接受」或「拒絕」,交易就會標示為「審核」。這些「審核」事件會手動審核,並透過非同步方式做出正確的建議。
所需的建議可根據要求主體中指定的電子郵件地址進行模擬。下表列出了與每個推薦流程相關的電子郵件地址。
電子郵件地址 | 決策 |
---|---|
accept@anydomain.com | 接受 |
reject@anydomain.com | 拒絕 |
review@anydomain.com | 審核 |
acceptreject@anydomain.com | 接受 -> 拒絕 |
reviewreject@anydomain.com | 審核 -> 拒絕 |
reviewaccept@anydomain.com | 審核 -> 接受 |
當訂單狀態改變時,就會呼叫「訂單購買 API」。
例如,如果客戶取消預訂、以任何方式變更預訂,或在預訂中新增其他產品或旅客,就會呼叫「訂單購買更新 API」,以告知 Expedia Group 與變更相關的資訊。
當旅宿根據詐騙建議取消或變更訂單時,也會呼叫「訂單購買更新 API」。
如果對應的訂單購買交易不存在,則「訂單購買更新 API」將不會運作,因此在「訂單購買更新 API」時,請務必先呼叫「訂單購買畫面 API」。
沙箱專用功能
叫用建議的決策
生產環境中預期的所需決策,可透過沙箱內的要求主體中使用指定的電子郵件地址來加以複製。 此功能還允許使用者測試非同步建議流程,當中的交易會手動審核,而合作夥伴後續會取得修正後的建議。 下方清單提供了與每個同步和非同步建議流程相關的電子郵件地址清單。
帳戶畫面
電子郵件地址 | 決策 |
---|---|
accept@anydomain.com | 接受 |
reject@anydomain.com | 拒絕 |
challenge@anydomain.com | 質疑 |
challengepass@anydomain.com | 質疑 -> 通過 |
challengefail@anydomain.com | 質疑 -> 未通過 |
acceptfail@anydomain.com | 接受 -> 未通過 |
訂單購買
電子郵件地址 | 決策 |
---|---|
accept@anydomain.com | 接受 |
reject@anydomain.com | 拒絕 |
review@anydomain.com | 審核 |
acceptreject@anydomain.com | 接受 -> 拒絕 |
reviewreject@anydomain.com | 審核 -> 拒絕 |
reviewaccept@anydomain.com | 審核 -> 接受 |
模擬決策變更之間的時間延遲
在生產環境中,非同步決策流程期間的決策變更之間會存在時間延遲。此行為可在沙盒中使用電子郵件地址後綴 -delay
進行模擬和測試,這項作業將為決策更新增加 5 分鐘的延遲。在測試與通知服務的整合時,可以使用這項支援功能。
例如,使用電子郵件地址 acceptreject-delay@test.com
,將模擬從「接受」到「拒絕」的決策變更,而決策變更之間會有 5 分鐘的延遲。
測試與通知服務的整合
如需通知服務的詳細資訊,請參閱通知。