- Developers: what your integration needs to do at each stage
- Operations / product teams: what happens behind the scenes and why a user may be blocked
Customer creation and product access requests can be billable. Confirm commercial terms with your account manager.
The onboarding flow (high level)
Collect the right information
You collect identity and contact information from the user (and, when required, documents such as passport images and proof of address).The exact set of required fields depends on the product you want to enable.
Choose who runs verification
You have two supported models:
- BFinance verifies on your behalf: you create the customer with minimal data and receive a verification link to share with the end user
- You verify the user: you run verification with a trusted provider (for example Sumsub or Persona), and provide verified data to BFinance
Create the customer and start verification
You create the customer in BFinance and verification begins (either through the hosted verification link or using the data you provide).At this stage, the customer is usually pending.
Wait for a final verification outcome
Verification is asynchronous. A customer typically ends in one of these states:
- active — verified
- rejected — verification failed
- pending — still under review
- needs_information — more information or documents are required
You can create a customer with an “empty” payload (only customer type and verification level). In that case, the API response includes a verification link you can send to the end user to complete verification.
Read next (by topic)
What to collect
A checklist of user information and documents, plus how product requirements change what you need.
Verification and statuses
How verification progresses, what statuses mean, and what to do when verification fails.
Requesting product access
How to enable cards or virtual accounts for an already verified customer.
Updating a customer
When and how customer updates can trigger re-verification, and how to plan UX around it.