postKycVerification 將已決策的結果提交給 Fluz。
與其他 API 方法不同,Fluz 在此不會對身分本身進行篩查 — 決策由您做出。Fluz 只會驗證並記錄該結果,並據此更新客戶狀態。
運作方式
postKycVerification mutation 為同步操作。您提交已驗證的身分與支撐您決策的供應商驗證資料,Fluz 會在回應本文中回傳 APPROVED、DECLINED、DUPLICATE 或 ERROR。不會有面向客戶的互動步驟。
此方法有幾個特定行為:
- 僅接受已決策結果。
decision必須為PASSED或FAILED。請勿送出待處理或未決策的驗證。 - 冪等性。 以
externalVerificationId(您供應商對此嘗試的全域唯一 ID)做為冪等鍵。重送相同 id 會回傳原始結果且不會寫入;若同一驗證重新決策,必須以新的 id 提交。 - 狀態轉換。
PASSED會將未驗證的客戶變更為已驗證。若客戶已經被驗證 — 不論透過任何方法 — 此次驗證仍會為稽核而記錄,但其狀態不會被變更;回應訊息會註明已保留既有狀態。FAILED會被記錄,且不變更狀態。 - 無嘗試次數限制。 因為您是在回報結果而非請求篩查,此方法沒有嘗試次數限制,且不計入 透過 SSN 驗證 或 KYC 自動填寫 的限制中。
請求
客戶由Authorization 標頭中的使用者存取權杖識別 — person.userId 與您的應用程式身分會由 Fluz 自動填入,且任何您提交的值都會被覆蓋。
完整欄位參考,包括
person 與 verifications 物件結構,請見 postKycVerification。
範例
Response
處理回應
測試
使用虛構身分在 staging 端點進行測試 — 因為決策由您做出,無需如其他方法般遵循供應商的測試身分要求。請使用900-XX-XXXX 範圍(從未發放)的 SSN、每次嘗試產生新的 externalVerificationId(重放同一 id 會回傳原結果,無法測試新情境),並確保您提供的任何照片 URL 可被存取 — Fluz 會擷取並儲存影像。