Platform Overview

This document reviews key Berbix Verify concepts and describes how a sample application integration works holistically.

Key Concepts

The following Berbix concepts will be referenced throughout this guide:

  • Action Map: Actions are a way to customize the business logic associated with Berbix transactions and can be thought of as the "business decision" after a verification such as accept, reject, or review. Actions are included in the returned Transaction data and can be mapped to a Review Queue.
  • Templates: A template represents the configuration for a Berbix Verify flow including the types of verification you'd like to conduct (photo ID, selfie, etc.) and settings for the verification flow (number of attempts, timeouts, etc.).
  • Themes: Themes can be used to customize the look-and-feel of your Berbix Verify experience. Themes are associated with a template.
  • Transactions: Transactions are the core component of Berbix Verify and represent a user verification.
  • Review Queues: Review Queues contain new transactions that may require additional 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 Verify, it's helpful to understand how all of the key integration concepts fit together. We recommend reading the Verify Flow Overview to also understand how the application workflow relates to the end-user experience.

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.