> ## Documentation Index > Fetch the complete documentation index at: https://docs.fluz.app/llms.txt > Use this file to discover all available pages before exploring further. # Business Accounts in OAuth > Let a user authorize your app against a business account — or pre-approve permissions for a business they are about to register — and understand which account an authorization code actually resolves to. A Fluz user can hold a personal account and one or more business accounts. Until now the OAuth flow always resolved to the personal account. It no longer does. If your application serves businesses, this page is the difference between an integration that works and one that quietly attaches every grant to the wrong account. Nothing here changes the authorize URL, the callback contract, or the token exchange. What changes is **which account the returned code is bound to**, and **which permission list was used to build the consent screen**. *** ## The two flows | Flow | When it runs | What the grant is against | | :------------------------- | :------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | | **Standard authorization** | The user selects a personal or an existing business account | That account | | **Business registration** | The user chooses to apply for a new business account, or your app is business-only and they don't have one yet | Their personal account, plus a set of permissions pre-approved for the business that will be created shortly afterwards | The second flow exists because the business doesn't exist yet at the moment of consent. The user grants permission to register a business on their personal account and, in the same step, pre-approves the business permissions your app will need once that business exists. Those pre-approved permissions are held against the user until the business is created. A user can run the business-registration flow more than once from the same personal account, pre-approving permissions for several businesses over time. *** ## Enabling business accounts on your app The two permission lists are on the **Permissions** tab of your app, and you edit them yourself. See [Configure OAuth App](/create-an-o-auth-app). Whether the flow is allowed to settle on a personal account is not on that tab — Fluz configures it on your application. Edited independently of the consumer **Permissions** list. **A non-empty business list is what makes your app business-enabled** — leave it empty and users are never offered the option to apply for a business account. Permission to register a business is not available on this list. It's granted by the personal account, so it belongs on the consumer list. Required for the business-registration flow. Without it that flow cannot complete. Fluz can configure your application so the flow never settles on a personal account. It is not self-serve — contact your Fluz account manager if your app should only ever operate on business accounts. Skip this if your app serves both consumers and businesses. Without the restriction, a user with no business account is offered their personal account alongside the option to apply for a business one, and some of them will pick the personal account. *** ## How the account gets chosen Fluz decides between skipping the picker and rendering it. Your app doesn't drive this — but you need to know what your users will hit. | Situation | What happens | | :------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | `external_id` already resolves to an account from a previous authorization | Picker skipped. That account is reused, and if the earlier authorization was a business-registration flow, that flow resumes | | No business account, and the app is restricted to business accounts | Picker skipped. Straight into business registration | | No business account, personal accounts allowed | Picker shows the personal account and, if the app is business-enabled, an option to apply for a business account | | Has business account(s) | Picker shows them. The personal account is included only when personal accounts are allowed | | A business application is already in progress | The "apply for a business account" option is hidden | The account selection step is why you should not assume the code you receive is bound to the user's personal account. Read the account off the exchange response and persist it — do not infer it from your own records of who started the flow. *** ## Which permission list applies The consent screen is built from your app configuration, never from the authorize URL. Which of the two lists it uses depends on the flow: | Flow | Consent screen shows | | :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------- | | Personal account | Your consumer **Permissions** | | Existing business account | Your **Business permissions** | | Business registration | Both, as two distinct groups — the consumer permissions being granted now, and the business permissions being pre-approved for the future business | In every case the list is read-only. The user accepts all of it or does not complete the authorization. Permissions are validated on our side against the list that applies to the flow. Anything outside that list is rejected, not silently dropped. *** ## Using `external_id` with businesses `external_id` is unique per application and binds to a single Fluz account on first use. With businesses in the picture, that has a consequence worth planning for: * If a user authorizes a personal account under `external_id=acct_123`, that ID is bound to the personal account. You cannot later reuse it for their business account. * Give each account you want to track its own external ID. If you model businesses separately in your own system, use your business identifier — not the owning user's. See [Managing External Reference IDs](/managing-external-reference-ids) for the general rules. *** ## Business accounts in the widget Where your integration uses the [embedded widget](/developers/widgets), a business account can be the active context for **deposit, payout, and pay-in**. Two behaviors differ from the consumer context: * **Consumer identity verification (KYC) does not apply.** A business context is verified through business verification (KYB) instead, and no consumer KYC prompt is shown. * **PIN is set at the user level.** A user who hasn't set a PIN can set one from either context, and it applies to both. *** ## Troubleshooting | Symptom | Almost always | | :------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No option to apply for a business account | **Business permissions** is empty, so the app isn't business-enabled — or the user already has a business application in progress | | Business-registration flow fails to complete | Permission to register a business isn't enabled on the consumer **Permissions** list | | Authorization rejected over an unrecognized permission | Something was sent that isn't on the list applying to that flow. Personal-account authorizations are checked against **Permissions**, business ones against **Business permissions** | | Reusing an `external_id` fails | It's already bound to a different account on this app | | The grant landed on a personal account when you expected a business | The user picked the personal account. Ask your Fluz account manager to restrict the app to business accounts if it should never accept one | *** ## Next steps The authorize URL, `state`, and the callback. Where the two permission lists live. Choosing identifiers you won't regret. Turn the code into tokens.