Portal
Definition
Portal is Ondorse's white-label onboarding solution. It helps you create a fluid and smart experience for your customers by integrating features such as auto-fill and suggestions. It leverages the know-how of Ondorse in business and individual onboarding while supporting a high degree of visual customisation.
A portal is a set of Ondorse-hosted web pages with a unique URL you can generate through Ondorse API. Once you have generated a portal and sent it to a customer, the information the customer fills in, including collected documents, will be sent to a case in the Ondorse case management.
Portal's web pages are based on the following logic:
- Business details, a web page to collect information on a legal entity (note that you can add custom questions)
- Relationships details, a web page to collect information about the relationships of the company (natural persons and entities) such as the directors of a company
- Documents, a web page to drop all required documents
Each portal is unique and persistent. It means that, until submitted, a customer can go back to its portal page to add more information or edit it.
Portal's features include:
- Search bar on entity names or registration number, with auto-complete to ease the search
- Auto-fill of fields powered by official register connections to reduce the burden on your customer and maximise conversion rate (note that customers can always edit and modify this information)
- Relationships (natural persons or entities) smart suggestions for directors and UBOs, depending on data availability
- Responsive design to fit seamlessly on any screen size
Portal links creation
Portal links can be created directly in the Portals section. By clicking "Create portal," a link is automatically generated, which can be shared with your customers for onboarding in Ondorse. All links are stored and retrievable in the Portals section.
Example integration for onboarding
In this example integration, the account is created before the KYB verification. Until the KYB verification is done and approved, the account is kept inactive and has limited access to your application (example: wire transfers are disabled).
This design choice have several advantages:
- While the KYB verification is pending, the user has already access to your application. You can already build engagement: complete the setup, train the user, etc.
- With an account creation as first step of the process, you have more means to contact and re-engage the user in case of drip out.
- You can pass down specific information to the KYB case such as: internal references (ex:
account_id
) or risk data (ex: acquisition channel).
Implementation guidelines
- Use the endpoint
POST /api/portals
(reference) to create a Portal link:- use the param
default_custom_fields
to pass custom case data such asaccount_id
etc.. - use the param
redirect_url
to redirect the user after the submission of the Portal
- use the param
- Use the webhook event
application.submitted
to be notified when a case is submitted via Portal- in the payload, you have access to the
application_id
andcustom_fields
values (especially the ones coming fromdefault_custom_fields
)
- in the payload, you have access to the
- Use the endpoint
GET /api/applications/{application_id}
(reference) to get access to case content- use the field
status_review
to know the decision status - use the fields
risk_score
andrisk_level
to get information about the risk scoring
- use the field
- Use the webhook event
application.review_updated
to be notified when a case gets an update on itsstatus_review
- Use the webhook event
collect.opened
to be notified when a case needs an information from the customer- Use payload
data.object.portals.link
to access the link to the collect Portal that you can send to the customer.
- Use payload
Updated 6 days ago