Provider Testing Best Practices

Once you’ve finished your integration and all necessary providers have been enabled, the next step is testing. Because every digital ID scheme works a little differently, testing can look different depending on the provider. This guide covers the main ways teams typically validate providers before going live.

1. Providers with Test Credentials

Some providers offer official test credentials that can be used in demo environments. If test credentials are available, this is usually the fastest way to validate your integration.

Recommended when:

• The provider supports sandbox testing
• You want repeatable, automated QA flows

Europe

• SPID (Italy)
• MojeID (Czech Republic)
• Czech BankID
• MitID (Denmark)
• Finnish Trust Network
• iDIN (Netherlands)
• BankID Norway
• BankID Sweden
• Smart-ID (Baltics)
• OneID (UK)
• Verimi (Germany)

North America

• CLEAR (US)
• LA Wallet (US)
• Google Wallet

Asia

• Indonesia Biometric Match
• Philippines Digital National ID
• PhilSys Biometric Match
• Philippines National ID

Oceania

• ConnectID

South America

• Brazil CPF Check
• Brazil Digital CNH

Africa

• Nigeria NIN Lookup
• South Africa National ID Lookup

2. Testing with Internal Employees

Many digital ID providers do not offer test data. In these cases, testing often requires a real credential from someone in the correct geography.

For example:

• A team member in Sweden testing BankID
• An employee in Louisiana testing LA Wallet

Recommended when:

• No test credentials exist
• You have internal access to the required wallet or ID

3. Using Trinsic’s Testing Network

If you don’t have test credentials and don’t have someone internally who can test, you can use Trinsic’s Testing Program to request a tester. This allows you to validate providers in regions where you may not have local coverage.

To submit a request, you’ll provide:

1. A session URL that is long-lived (at least two days)
2. The provider you want tested
3. Any instructions for the flow (success/failure scenarios)

Trinsic will coordinate the test and can provide a recording of the experience if helpful.

Recommended when:

• The provider requires a real credential
• You don’t have an internal tester available

What You Should Validate

Regardless of testing method, we recommend confirming:

• A successful verification completes as expected
• Failure and “not found” cases behave correctly
• Sessions time out or cancel cleanly
• Redirects return the user back to your application
• Any fallback flow (e.g., document verification) works if applicable

Before Production Launch

Before enabling production traffic, make sure you have a structured testing plan that covers:

• Which environment you are testing in (sandbox vs production)
• Whether test credentials or testers are available
• Clear success/failure criteria
• A confirmed fallback option for unsupported users

If you’re unsure which testing approach applies to a specific provider, feel free to reach out to us at [email protected]; were happy to guide you through it.