Test Accounts

Test mode lets you build, validate, and demo a Vouched integration end-to-end without triggering real identity verification, incurring billing, or submitting real PII for processing.

Test mode is a property of the account, not of individual jobs. Once your account is provisioned as a test account, every job submitted under its API keys runs through the same endpoints and pipeline as a live account, but each verification check returns a deterministic synthetic response instead of running for real.

When to use test mode

Wiring up a new Vouched integration and validating success, failure, and review code paths.
Regression-checking your client after Vouched or SDK changes.
Exercising checks that are backed by regulated or restricted data sources whose terms of use forbid test or non-genuine submissions. Test mode never forwards a test account's traffic to those sources, so you can rehearse the integration without breaching their terms.

Test mode is not for:

Measuring Vouched's accuracy against real documents or identities — synthetic responses do not reflect real model behaviour.
Simulating downstream outages, timeouts, or partial responses — test mode always responds quickly and deterministically.
CI and automated testing usage.

Mocked Users

First and last name are how you tell test mode what outcome you want.

Every test-mode check — DOB, SSN, TIN, driver's license validation, crosscheck, AML screening, and the per-field checks inside a standard verification — decides its outcome by looking at only the first and last name on the submission. Other inputs (SSN digits, TIN digits, DOB, address, phone, IP, ID images) are accepted and format-validated, but their content does not influence the outcome.

Other fields still need to be syntactically valid so the request passes input validation, but the specific values are ignored. Use any plausible placeholder.

The Test Identifier

Field	Value	Notes
First name	`test`	Case-insensitive.
Last name	`pass`	Case-insensitive.

Submit a job with exactly this name pair and every gated check returns the "clean" outcome for that check (a successful verification, or — in the case of AML screening — no sanctions/PEP hit). Submit any other name and every gated check returns the opposite (failed verification, or an AML hit).

There is no separate magic name for "review", "deceased", or any other intermediate state at this time. The model is intentionally binary — test pass or everything else.

Behaviour by job type

All job types accept the same test / pass pair as the positive trigger.

Job type	`test` / `pass` →	Any other name →
Standard verification (IDV)	Name-scored fields pass; DLV, crosscheck, and IP checks return positive results. NOTE: The name must be provided via invite or the `firstName` and `lastName` properties (api only). The name on the document being processed does NOT matter.	Gated checks return negative results.
Crosscheck	Address, phone, IP, and email checks return matching/valid.	Address, phone, and IP checks return invalid.
DOB verification	Match.	No match.
SSN verification (private)	Match.	No match.
Driver's licence validation	Approved.	Not approved.
TIN validation	`TIN Matched`.	`Did Not Match` with a non-match IRS reason.
AML screening	No hit. Clean screening result with no sanctions, PEP, or adverse-media matches.	Sanctions hit returned with a synthetic high-risk profile.
IP inspection	Returns a fixed non-risky US result regardless of IP.	Same — IP content is always ignored.
Address validation	Returns a fixed confirmed US address regardless of input.	Same — address content is always ignored.

For image and selfie-based checks

Standard verification jobs still run the image pipeline (OCR, face match, liveness). That means:

Upload a real ID image and your own selfie during integration, or use any image fixture you already use in your own tests.
Face-match and liveness outcomes depend on the actual images you submit — they are not gated by the name.
- To pass both this means the Selfie submitted will need to match the ID submitted
To get a full green IDV pass, the submitted ID must OCR to test / pass, and the selfie and ID photo must genuinely match on biometrics.

If you don't want to manage image fixtures, you can still exercise the non-image parts (DOB, SSN, TIN, DLV, crosscheck, AML) against their dedicated endpoints with the test / pass identity.

Limitations

No failure simulation. Test mode does not simulate downstream timeouts, rate limits, network errors, or partial responses. If you need to test how your integration behaves under failure conditions, mock at your own layer.
No guaranteed field-for-field parity. Synthetic responses are shaped like real responses but may not include every field a live response would populate.
No promised data retention. Data submitted to a test account has no guaranteed retention window and may be pruned at any time.
Rate limits apply. Test accounts are rate-limited; if you plan to drive higher volume, contact support before doing so.
No automated test usage. Test mode should not be used for any CI-style automated testing.
Fallback is "fail", not "pass-through". If you submit a non-magic name, gated checks return a negative result. They do not fall back to running a real verification.

Test API keys

Test account API keys are prefixed so they are visually distinguishable from live keys:

Key type	Prefix
Private	`test_prv_`
Public	`test_pub_`
Signature	`test_sig_`

Live keys use the same structure without the test_ prefix (prv_*, pub_*, sig_*). You can tell at a glance whether a key is live or test without looking up the account.

Test accounts are permanent

Important: An account that has been flagged as a test account cannot be converted to a live, billable account. This is a one-way flag by design.

If you want to go live:

Keep using your test account for ongoing integration work and demos.
Request a separate live account from Vouched support.
Swap your API keys from test_* to the new live keys. Everything else in your integration stays the same — the API surface is identical.

This is intentional, not a bug. It prevents a test account (which may have had synthetic, non-PII-safe data pushed through it) from silently becoming a production identity pipeline. If you are not sure whether you want a test or live account, start with test.

Getting a test account

Test accounts are provisioned by Vouched Support — they are not self-service. Contact your Customer Success Manager or Support with:

The name you want on the account (it will need to be distinct from any existing live account you have).
Whether you want the account pre-configured to match an existing live account's settings (e.g. which job types are enabled, workflow configuration).

Support will provision the account and confirm which job types are enabled.

Notes

Test accounts are generally provisioned as sub accounts