Testing PassFort
When you're implementing a new configuration of PassFort, you want to be sure it's working as expected.
We recommend running initial tests in your demo environment, a special account just for testing. It does not run live checks, with the exception of checks run with free data providers (e.g. Companies House).
When you're happy with how the demo environment works, you have the option to set up a staging environment. This account is used for testing checks run by data providers with which you have direct agreements.
Finally, we'll move everything over to your production environment. This is the environment that your users will eventually see. Before you roll out PassFort to your users, we recommend running tests in your production environment to ensure your data providers and integrations are properly configured.
If you have any questions, we'll be here to answer them. You can contact your Customer Success Manager or raise a ticket with our support team at support@passfort.com.
Demo environment tests
The demo environment is designed to let your core development and testing teams run as many tests as they like.
The demo environment does not run live checks with any data providers that may charge you, so you can "run checks" without the worry of being charged.
What tests should I run?
Testing the default smart policy
When you get a PassFort demo environment, we'll add a default smart policy to it.
You can use the default smart policy to start testing immediately, try out different policy behaviours, and get an idea of what changes we can make so your smart policy fits with your compliance procedures.
We've prepared test scenarios for the default smart policy.
Testing your smart policies and risk levels
Once you have your own smart policy, ideally, you want to test every path in your smart policy workflow(s) that a customer can experience. Find out what happens when customers go down the happy path and also what happens when manual intervention is required.
To force profiles down certain paths, create them with details that you know are critical to your smart policies (e.g. nationality, pledge amount, etc).
If you're using risk, you should also test onboarding with different risk levels.
As with smart policy testing, you can force applications to be assigned specific risk levels by creating profiles with details relevant to your risk model(s).
Testing checks
This environment does not run live checks with any data providers that may charge you. Instead, all paid checks are simulated and demo data is returned so you can see a sample of what the results will look like.
PassFort provides a series of tests you can run to simulate check results with paid providers. To get the tests:
- Find the articles for your data providers.
- In the articles, go to the section called Testing your configuration. All the steps to run the tests are there.
You can combine test words into a single profile.
For example, if you're testing the Electronic identity check with Experian Prove-ID and the PEPs and sanctions screening with RDC, you could run these tests by creating profiles with the following names:
Test | Keyword(s) required | Profile name for test |
What happens to customers with no PEPs matches and a 2+2 result? | To test no PEPs matches: No keywords are required To test a 2+2 result: No keywords are required | Alex Wheeler |
What happens to customers with no PEPs matches and a fail result? | To test no PEPs matches: No keywords are required To test a fail result: fail | Alex Wheeler fail |
What happens to customers with some PEPs matches and a 2+2 result? | To test some PEPs matches: PEP To test a 2+2 result: No keywords are required | Alex Wheeler PEP |
What happens to customers with some PEPs matches and a fail result? | To test some PEPs matches: PEP To test a fail result: fail | Alex Wheeler PEP fail |
Testing your API integration
When testing your API integration, you should confirm that:
- When profiles are created via the API, all required data is populating in PassFort correctly, including collected data and custom fields.
- Webhook data is being returned as expected.
We recommend using aliases rather than IDs for your API calls when possible. Aliases will be the same in your demo environment and production environment, so you won't have to update your code when you switch environments.
How do I log into the demo environment?
To log into your demo environment, go to https://identity.passfort.com/login.
You should log in with the credentials we provided you with when we set up your demo account.
Once you log in, you'll see the word Demo in the top bar.

Staging environment tests
A staging environment is an optional transitional account that sits between your demo environment and production environment.
Its purpose is to let you do rigorous end-to-end testing with your data providers with which you have direct agreements.
Any data providers with which you have a direct agreement will run live checks. You will be charged for these checks.
Any data providers with which you have a PassFort reseller agreement will return demo data only. This means you will not use any of your PassFort credit.
Testing checks
Because checks run with data providers with a direct agreement are live, you can use real data to test.
The demo data for checks with data providers with a reseller agreement will be the same as it was for your demo environment.
How do I request a staging environment?
To request a staging environment, please speak to your Customer Success Manager.
Production environment tests
Your production environment is configured exctly the same as your demo environment (and, if used, staging environment), but all checks are live.
You'll see real check results from your data providers and you'll be charged for any checks you run.
You'll have likely completed the majority of your functional testing (i.e. the different routes through the Risk Models and Smart Policy workflows) in the demo environment, so we recommend using the production environment to test:
- Whether the data providers are properly configured.
- Whether all systems (including any customer systems) are properly integrated.
We recommend choosing a small subset of individuals to test on (e.g. employees or family members).