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
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. Whether the flow is allowed to settle on a personal account is not on that tab — Fluz configures it on your application.1
Fill in the Business permissions list
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.
2
Enable the register-a-business permission on the consumer Permissions list
Required for the business-registration flow. Without it that flow cannot complete.
3
Ask Fluz to restrict the app to business accounts, if you need it
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.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:
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.
Business accounts in the widget
Where your integration uses the embedded widget, 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
Next steps
Client-facing grant flow
The authorize URL,
state, and the callback.Configure OAuth app
Where the two permission lists live.
External reference IDs
Choosing identifiers you won’t regret.
Exchange an authorization code
Turn the code into tokens.