Key Concepts

The following Berbix concepts will be referenced throughout this guide:

• Transactions: When your end-user verifies their identity, the end-to-end process is called a Transaction. The data captured in each transaction may be viewed individually in the Berbix dashboard, or may be retrieved programmatically via integration.
• Transaction ID: The unique identifier we assign to a transaction when it is generated.
• Customer UID: When you create transactions, we strongly recommend that you assign a unique identifier to the individual end-user. For best practices, check out our Frequently Asked Questions.
• Templates: When you configure a Template, you are defining the steps your end-users will take to verify their identity. This may include selecting an allowed document type, uploading photos of the front and back of their ID, taking selfies, and more.
• Action Map: An Action Map uses possible transaction flags to set business logic. When your end-users complete transactions, we use this logic to decide on an Action; accept, reject, or review.
• Themes: Customize the look and feel of the end-user experience to match your branding with Themes.
• Review Queues: Transactions that result in a review action are routed to Review Queues for manual verification.

Token Types

There are three token types associated with any given transaction within Berbix:

• access_token: short-lived (one hour) token that enables your backend to fetch data about a given transaction.
• client_token: short-lived (one hour) token that connects the Berbix frontend with a given transaction.
• refresh_token: long-lived token that may be used to regenerate the other two tokens.

End-to-End Application Workflow

Before integrating Berbix, it's helpful to understand how all of the key integration concepts fit together.

The typical end-to-end application workflow is:

1. An end-user in your application flow needs to perform some form of identity verification.
2. Before initiating the verification flow, your application creates a new Berbix transaction associated with a customer_uid and template_key, which returns an associated access_token, refresh_token, and client_token.
3. Your application stores the refresh_token alongside your user record, which is used to generate an access_token and client_tokens in future requests.
4. Your application sends the generated client_token for the transaction to your frontend to initialize the Berbix flow.
5. The end-user performs the selected form of identity verification and their details are sent directly to Berbix for validation.
6. Upon completion, the Berbix frontend SDK triggers a successful callback hook or an error if verification is unsuccessful.
7. Your application fetches the metadata for a successful verification using the transaction's access_token.
8. Your backend sends the returned action to your client to determine the user experience.

To check out how this is experienced by the end-user, we recommend that you review the End-User Verification Flow.

© Berbix Inc. All rights reserved.