本頁內容不會改變 authorize URL、callback 契約或 token 交換。改變的是回傳的授權碼綁定到哪個帳戶，以及同意畫面是用哪一份權限清單建置的。
兩種流程
第二種流程存在的原因是：在使用者同意的那一刻，企業還不存在。使用者在自己的個人帳戶上授予「註冊企業」的權限，並在同一步驟中預先核准你的應用程式在該企業存在後所需的企業權限。這些預核權限會挂在使用者名下，直到企業被建立。
同一個個人帳戶可以多次走企業註冊流程，隨時間推移為多家企業預先核准權限。
在你的應用程式上啟用企業帳戶
兩份權限清單位於應用程式的 Permissions 分頁，由你自行編輯。參見設定 OAuth 應用程式。流程是否允許落在個人帳戶上，則不在該分頁上 —— 由 Fluz 在你的應用程式上設定。1
填寫 Business permissions 清單
與消費者 Permissions 清單獨立編輯。企業清單非空，才會讓你的應用程式啟用企業能力 —— 留空的話，使用者永遠不會看到申請企業帳戶的選項。註冊企業的權限不在這份清單裡。它由個人帳戶授予，因此屬於消費者清單。
2
在消費者 Permissions 清單上啟用「註冊企業」權限
企業註冊流程必需。沒有它，該流程無法完成。
3
如有需要，請 Fluz 將應用程式限制為僅企業帳戶
Fluz 可以為你的應用程式進行設定，使流程永遠不會落在個人帳戶上。這一項不是自助的 —— 如果你的應用程式只應在企業帳戶上運行，請聯繫你的 Fluz 客戶經理。如果你的應用程式同時服務消費者與企業，請跳過此步。在未啟用該限制前，沒有企業帳戶的使用者會同時看到自己的個人帳戶與申請企業帳戶的選項，其中一些人會選個人帳戶。
帳戶如何被選定
是跳過選擇器還是顯示它，由 Fluz 決定。你的應用程式不控制這一點 —— 但你需要知道你的使用者會遇到什麼。適用哪一份權限清單
同意畫面始終根據你的應用程式設定建置，而不是根據 authorize URL。使用哪一份清單取決於流程：
每種情況下該清單都是唯讀的。使用者要麼全部接受，要麼無法完成授權。
權限會在我們這一側根據適用於該流程的清單進行驗證。不在清單內的內容會被拒絕，而不是靜默丟棄。
在企業情境下使用 external_id
external_id 在每個應用程式內唯一，首次使用時就會綁定到唯一一個 Fluz 帳戶。引入企業後，這帶來一個值得提前規劃的後果：
- 如果使用者以
external_id=acct_123授權了一個個人帳戶，該 ID 就綁定到了個人帳戶。你無法之後再把它用在他的企業帳戶上。 - 為每個你想追蹤的帳戶分配各自的外部 ID。如果你在自己的系統裡單獨建模企業，請使用你的企業識別碼 —— 而不是所有者使用者的。
元件中的企業帳戶
當你的整合使用嵌入式元件時，企業帳戶可以作為存款、payout 與 pay-in 的當前情境。有兩點與消費者情境不同：- 消費者身分驗證（KYC）不適用。 企業情境透過企業驗證（KYB）完成核驗，不會出現消費者 KYC 提示。
- PIN 在使用者層級設定。 尚未設定 PIN 的使用者可以從任一情境設定，且對兩者都生效。
疑難排解
下一步
面向客戶端的授權流程
authorize URL、
state 與 callback。設定 OAuth 應用程式
兩份權限清單在哪裡。
外部參考 ID
選擇不會讓你後悔的識別碼。
交換授權碼
將授權碼換成 token。