Overview
Fluz KYB（Know Your Business，企業認識）可讓你的平台透過自有 UI 將商家導入 Fluz rails。透過一小組操作，你可以：- 解析企業實際經營的商業類別與次類別，
- 送出法人實體資料 — 法定名稱、組織型態、稅號、註冊州、法定地址、帳戶預期用途 — 以及最終受益所有人名單，
- 完成需要驗證之所有人的身分驗證，並
- 追蹤最終的 KYB 案件至核准或婉拒。
accountId，且 kybStatus 為 SUBMITTED。
註冊是驗證，不是核准。
success 回應僅代表傳入資料通過驗證且已開立 KYB 案件。這不代表商家已獲核准。請將整合設計為在狀態為核准前，不嘗試為帳戶加值或發卡。商家帳戶能解鎖什麼
一旦 KYB 核准，商家帳戶即可用於平台的商務功能：- 商家消費帳戶與餘額
- 商用虛擬卡，包含大量發卡
- 授權使用者與卡片層級的消費控管
- 卡片、轉帳與報銷的審批流程
- 商家層級的交易報表與費用註記
何時使用這些端點
當你希望在自有 UI 蒐集法人與持有人資料，而非將使用者導向 Fluz 代管體驗時，請使用此流程。若你希望由 Fluz 代管資料蒐集與文件上傳，請與你的客戶經理聯繫以採用基於小工具的導入選項。KYB flow
Step-by-step
1
Step 0 — 滿足先決條件
這些不屬於流程的一部分，但在呼叫
registerBusiness 前都必須成立。每列皆鏈接到下方細節。見先決條件2
解析商業類別與次類別
呼叫 getBusinessCategories，讓使用者選擇一個類別與該類別的一個次類別。
3
上傳授權簽署人文件（若適用）
僅在申請人持股少於 25% 且不是控制人時需要。先上傳文件，接著將回傳的 URL 傳入
authorizedSignerDocumentUrl。見提交商家文件。4
提交 registerBusiness mutation
以單次呼叫送出完整法人資料、持有人聲明，以及所有持有人。驗證錯誤會出現在回應 payload 中 — 見回應細節。
5
讓其餘持有人完成驗證
讀取 getBusiness 以查看每位持有人所需的驗證類型與當前進度。對於走文件驗證路徑的持有人，以 requestOwnerDocumentVerificationLink 產生連結並傳送給他們。被邀請的持有人會由 Fluz 寄送 email，並自行完成驗證。
6
等待 KYB 決定，然後佈建
申請最初為審核中。請向使用者呈現此狀態，而非暗示已就緒。狀態變為
APPROVED 後，再建立消費帳戶並發卡。端到端序列
Prerequisites
Application permission scopes
在 Fluz dashboard 的應用程式權限範圍中選擇REGISTER_BUSINESS。所有 KYB 操作皆需要此範圍，而權杖僅能攜帶你的應用程式被設定可請求的範圍。見 Application Scopes。
訂閱 KYB_STATUS_UPDATE webhook 亦需要相同的範圍。
Applicant authorization
申請人必須完成你應用程式的 OAuth 授權，且該授權必須涵蓋你應用程式所請求的每個商家範圍。若之後新增範圍，既有使用者必須重新授權才能註冊商家 — 否則註冊會以AUTH-0008 失敗。
The applicant must already be cip-verified
Bearer 權杖標識的是申請人：提交申請的使用者。名冊中必須有且僅有一位持有人與權杖使用者以email（不分大小寫）或電話號碼相符，且該持有人不可標記為isInvited: true。
KYB 會驗證商家與「其他」持有人，不會驗證申請人，因此申請人必須事先達到已驗證狀態。你為其送出的 isUsPerson 值決定套用哪種檢查：
身分驗證發生在 KYB 之外，需具備
VERIFY_KYC 範圍，使用 verifyUserInformation、verifyUserPrefillInformation，或 requestDocumentVerificationLink。見身分驗證（KYC）。若該人尚無任何 Fluz 帳戶，請先以 registerUser 建立。
One open application per user
在既有申請仍開啟時，使用者不得啟動新的註冊 — 否則回傳BS-0007。
Access tokens
每個操作都需要特定帳戶型態的 Bearer 權杖：使用
generateUserAccessToken 產生 Mint Bearer 權杖 — 請參閱 API 參考的 Authentication 章節。KYB status lifecycle
SUBMITTED 僅會由 registerBusiness 回傳。getBusiness 回報三值狀態，而註冊後緊接的狀態在那裡會顯示為 PENDING — 兩者描述的是同一時點但用詞不同。Tracking an application
有兩種方式追蹤申請至最終狀態。選擇最符合你基礎架構者；許多整合同時使用 webhook 以降低延遲，並偶爾讀取以對帳。- Webhook
- 直接讀取狀態
在 Fluz dashboard 訂閱
KYB_STATUS_UPDATE 事件：註冊你的回呼 URL 並選取該事件。你的應用需要 REGISTER_BUSINESS 範圍才能訂閱。當商家 KYB 狀態變更時，Fluz 會對你的端點發出 POST。需處理兩件事：
- 將傳遞視為至少一次。 讓你的處理器具備冪等性，以
accountId加上newStatus作為鍵。 - 你可能收到
previousStatus等於newStatus的事件。 案件在內部狀態間移動，但外顯狀態相同。將這些視為 no-op。
載荷僅攜帶商家狀態 — 不包含持有人名冊。當你需要查看個別持有人進度時，請呼叫 getBusiness。
一般審查會在一至兩個工作天內完成，但若需補件或某位持有人尚未完成身分驗證，時間可能更長。若案件似乎停滯，請以
accountId 聯絡你的客戶經理，而非重新提交 — 第二次提交會被 BS-0007 擋下。Identifying businesses with externalReferenceId
Fluz 以在註冊時產生的 UUID accountId 識別商家。externalReferenceId 則是你可選擇提供的識別碼，讓你能用自家系統已使用的 ID 與 Fluz 互動。
於 registerBusiness 一次性傳入：
- 免存 Fluz ID 的權杖簽發。 以外部參考來簽發商家帳戶存取權杖，而非用
userId與accountId。 - Webhook 對應。 每個
KYB_STATUS_UPDATE事件都會附帶此參考值，讓你不需查表即可將事件對應到自家紀錄。
accountId，無論如何都建議這麼做。
規則
這裡涉及兩個不同的參考值，容易混淆。你的存取權杖已攜帶的參考值用於定位申請人既有的授權；而
registerBusiness 輸入中的參考值 會寫入新的商家帳戶。兩者用途不同。Related pages
註冊商家
registerBusiness mutation：完整參數參考、持有人規則與錯誤代碼。商業類別
取得 mutation 所需的類別與次類別 ID。
提交商家文件
上傳授權文件並回應 KYB 補件要求。
商家 KYB 狀態
讀取 KYB 狀態與持有人逐一驗證進度。
持有人驗證連結
為持有人產生可分享的身分驗證連結。
註冊客戶
建立將作為申請人的 Fluz 使用者。