Testing in Sandbox

In Sandbox mode, Identity Verification accepts the fixed set of inputs below in order to result in successful Data Source and Document Verification checks.

Data Source checks in Sandbox will be compared against the information above. To simulate different test cases and results, you can adjust your Data Source input at the attribute level (e.g. an incorrect birthdate), and set up different Identity Rules to simulate different verification results.

Documents uploaded in Sandbox will always be interpreted as genuine (not fake) documents reflecting the name and date of birth matching the Leslie Knope test user. Document check will pass if the data provided in the Data Source check matches this name and date of birth, and will fail otherwise.

Users have three attempts to pass the Document check, so the status will not be updated in the Dashboard to failed until you have provided mismatching data three times.

Selfie checks will not be run in Sandbox mode, even if they are enabled in your template.

In Sandbox, Monitor screens against a real-world dataset, so the Sandbox user will not return any screening hits. For more information, including example data you can use to trigger screening hits, see Testing Monitor.

The risk check is fully functional in Sandbox. It’s common to trigger high risk scores when testing. For more information and advice, see Risk rules for testing.

Auto-fill behavior is fully functional in Sandbox.

Financial Account Matching is fully functional in Sandbox. If you want to change the Identity data that is being compared to the Identity Verification session, see how to create Sandbox test data.

Many common testing behaviors (e.g. attempting to enter the Identity Verification flow repeatedly on the same device using different credentials) may be flagged as risky behavior and cause your verification attempt to fail. For testing purposes, you can temporarily set the Acceptable Risk Level for any checks you are failing (typically Network Risk and Device Risk) to High, under the Rulesets -> Risk Rules section of the template editor. Make sure to set the Acceptable Risk Level back to your desired setting before launching in Production.

If you want to force a check to fail in Sandbox, an easy way to do this is to set Acceptable Risk Level for the Network Risk and Device Risk fields to Low. Checks will begin failing after your first few attempts.

Using the rules above, it is easy to create the outcome of passing both Data Source checks and Document checks, or of failing both checks. If you need to simulate specific combinations of pass / fail (passing one check but not the other), you can use the guides below.

1. Set up your template to always be enabled for Data Source checks and Document Checks.
2. Set up your template to not require a match or partial match on name or date of birth.
3. Enter Leslie Knope's correct test data for the address, SSN, and phone number fields.
4. Enter incorrect data for the name and date of birth fields.

If you would like this test to also trigger a Monitor hit, you can use the name and date of birth of a sanctioned individual. For examples, see Monitor test data.

1. Set up your template to be enabled for Data Source checks, with Document checks as a fallback.
2. Set up your template to require a match for address, SSN, and phone number fields.
3. Enter Leslie Knope's correct test data for the name and date of birth fields.
4. Enter incorrect data for the address, SSN, and phone number fields.

1. Create a template with Financial Account Matching enabled.
2. Call /link/token/create with identity_verification in the products array. Make sure to save the client_user_id you are using with this call, as you will need it later.
3. Launch Link and complete the Identity Verification session, entering Leslie Knope's correct test data.
4. See the Sandbox custom user repo for instructions on configuring custom Sandbox users and create a custom user using the Financial Account Matching custom user data from that repo.
5. Call /link/token/create with identity (or assets, for underwriting use cases) in the products array and the same client_user_id as was used in the first step, and launch a Link session.
6. Use the custom user you created above to log in to Link, then call /item/public_token/exchange to exchange the public token for an access token.
7. Call /identity/get or /identity/match (or /asset_report/create, if using assets instead of identity) on the access token.
8. Check the Identity Verification session in the Dashboard. You should see the linked account and a successful match in the Financial Account Matching section.