Testing Guide

Berbix provides a testing framework to easily perform and automate end-to-end tests of the Berbix Verify Flow in your app. The framework enables you to mock the completion of a transaction without needing to submit any verification data such as photo ID or selfie images. When overriding the transaction result, all you need to do is specify the type of photo ID data (payload) and which flags you'd like returned in the API response.

You can override transaction results via the API on the server-side or interacting with the client-side JavaScript SDK directly. Instructions for both methods are included below.

Berbix currently provides the following sample verification payload values:

us-dl: a sample verification for a US driver license
us-id: a sample verification for a US identification card
passport: a sample verification for a US passport

Please reference the Sample Response Payload for a complete sample response payload and let us know if you need additional test cases!

Server-Side Testing

To override results via the API, simply call the Overrides endpoint (/transactions/override) after you have created a transaction via the API.

You will need to provide the response_payload and the list of flags (if any) desired in the transaction result. Possible values for the response_payload are enumerated below and you can read through all possible Transaction Flags.

After overriding the transaction data, you can fetch the overridden verification data as you would normally via the API.

Client-Side Testing

To get started, load the Berbix Verify Flow in test mode within your application or create a test transaction using our hosted flow.

In the verification flow, click Test mode- Click to override in the top left corner to start the test result override process.

On the next screen, select which verification response Payload and Flags you'd like returned in the verification result.

After selecting an ID type via the Payload, you can select as many flags as you'd like to simulate common verification scenarios and corresponding business logic based on your Action Maps.

1046 — In this example, we've selected a payload and flags to simulate a transaction where a U.S. drivers license belongs to someone under the age of 21.

The verification is overridden once you click Complete. The data is then available to review in a Transaction Report Overview on the dashboard or fetch via API.

Generating development client tokens for Client-Side SDKs

There are two ways to generate client tokens for integration testing.

Create a transaction using the Berbix API explorer, then copy the generated client_token into one of the client SDK implementations for testing.
Use one of the backend API clients from our library to create a client token and pass it to the client SDK implementation.

Viewing Overridden Transaction Data

To locate overridden transactions on the dashboard, ensure Test Mode is toggled on and select All Transactions.

2282 — In the transactions list, overridden transactions have the "Override" label in the "Verifications" column.

The transaction report is similar to other live and test reports but does not include image data.

You may also find the direct url for the report in the response payload.

Including Berbix in your CI processes

Your Continuous Integration processes might include integration tests that incorporate behavior controlled by the Berbix Verify Flow. Whenever that is the case, we recommend mocking that behavior rather than making calls to Berbix directly. The Berbix Verify Flow has ample test coverage, which is continually maintained and improved by the Berbix Team. Moreover, we offer a status page which always contains the most up-to-date information on Berbix's status, obviating the need for you to run a health check against Berbix.

If you cannot mock Berbix in your application, we suggest using our Server-Side Testing options over our Client-Side Testing options. Please note that both of these options are primarily offered as a means to debug your integration, rather than continually test Berbix's behavior, and that we therefore enforce test transaction rate limits.

Test Transaction Limits

We rate-limit the creation of test transactions to 100 test transactions in a one minute sliding window. We also rate limit the creation of test transactions based on the number of test transactions that have been completed in a 4 hour sliding window. By default, you are limited to 100 completed test transactions per 4 hours. If you need this limit raised to debug your integration with Berbix, please reach out to [email protected]

Sample Response Payload

Berbix currently provides the following sample verification payload values:

us-dl: a sample verification for a US driver license
us-id: a sample verification for a US identification card
ca-dl: a sample verification for a CA driver license
passport: a sample verification for a US passport

The API response for each payload option will be identical with the exception of the id_type field and the sources for each field. Let us know if you need additional test cases!

🚧
Fields returned vary based on customer
Please note that the specific fields returned via the API depend on your use case and account configuration. Let us know if you are expecting additional fields in your API response.

The example payload below corresponds with the us-dl id_under_21 transaction demonstrated above.

{
  "entity": "transaction_metadata",
  "id": 6357469847879680,
  "flags": [
    "id_under_21"
  ],
  "action": "accept",
  "fields": {
    "given_name": {
      "value": "GIVEN",
      "confidence": "high",
      "sources": [
        {
          "value": "GIVEN",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "GIVEN",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "middle_name": {
      "value": "MIDDLE",
      "confidence": "high",
      "sources": [
        {
          "value": "MIDDLE",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "MIDDLE",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "family_name": {
      "value": "FAMILY",
      "confidence": "high",
      "sources": [
        {
          "value": "FAMILY",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "FAMILY",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "date_of_birth": {
      "value": "1990-12-15",
      "confidence": "high",
      "sources": [
        {
          "value": "1990-12-15",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "1990-12-15",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "id_type": {
      "value": "DL",
      "confidence": "high",
      "sources": [
        {
          "value": "DL",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "DL",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "id_issuer": {
      "value": "US-CA",
      "confidence": "high",
      "sources": [
        {
          "value": "US-CA",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "US-CA",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "address_subdivision": {
      "value": "CALIFORNIA",
      "confidence": "high",
      "sources": [
        {
          "value": "CALIFORNIA",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "CALIFORNIA",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    },
    "address_country": {
      "value": "US",
      "confidence": "high",
      "sources": [
        {
          "value": "US",
          "type": "pdf417",
          "confidence": "high"
        },
        {
          "value": "US",
          "type": "ocr",
          "confidence": "medium"
        }
      ]
    }
  },
  "images": {},
  "created_at": "2022-07-26T18:51:07Z",
  "completed_at": "2022-07-26T19:15:34Z",
  "customer_uid": "2323232323",
  "duplicates": null,
  "dashboard_url": "https://dashboard.berbix.com/transaction?orgId=5171605566390272&transactionId=6357469847879680&mode=test",
  "implementation_info": "The data for this transaction has been overridden with a test payload. Read more at https://docs.berbix.com/docs/testing"
}

Best Practices

Your integration is unique, and will require testing that replicates the custom end-to-end experience you have built for your end-users. We recommend considering the following suggestions when you are testing your integration.

Test the flow on multiple device types and browsers where applicable
Test using different ID types
If the flow will be opened in a webview, test with different sources
Test with different camera permission settings
If embedded, check your modal or inline UI

Server-Side Testing

Client-Side Testing

Generating development client tokens for Client-Side SDKs

Viewing Overridden Transaction Data

Including Berbix in your CI processes

Test Transaction Limits

Sample Response Payload

🚧Fields returned vary based on customer

Best Practices

🚧
Fields returned vary based on customer