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. By default, Berbix provides three actions:
remove actions from within the Berbix Dashboard. When editing, you have control over:
Name: the name of the action (such as
accept) which is exposed in the Berbix Dashboard and in the transaction metadata from the Berbix Verify API.
Priority: the relative priority of the action compared to other actions (higher numbers = higher priority). Berbix will default to the highest priority action in the case of an inexplicit action mapping,
Color: the color associated with the action button shown in transaction views within the Berbix Dashboard when manually reviewing transactions.
Queue: the Review Queue the transaction will be sent to based on the action. By default, only the
reviewaction is mapped to the
The status value of a photo ID verification represents whether or not a readable image was successfully collected from the user. There are two status values:
complete: all required components of the photo ID were collected successfully.
pending: the user exceeded the number of attempts to complete collection of one or more required components. In a
pendingresult, one or more ID Flags will be returned to indicate why the ID verification was unsuccessful.
Verification Status Mapping lets customize how the
status value determines the
action to take in your application. As shown in the example below, you might
complete transactions and
pending transactions notwithstanding any specific flag action mapping.
ID Flags indicate something of note with the photo ID verification. It doesn’t necessarily imply that the ID is fraudulent, but there is something important to consider when writing systems to accept or reject verifications. These are items such as
A complete list of ID flags that Berbix returns can be found here: ID Flags
Flag Action Mapping lets you customize how the
flags determine the
action to take in your application. These mappings are highly dependent upon your business case and the actions you've defined. We're happy to help you define these mappings based on the best practices for your vertical and use case!
As an example, you may want to automatically
reject transactions that return the
id_under_21 flag if you're selling an age-restricted good.