Prove Pre-Fill Sandbox Testing
Learn more about simulating the Prove Pre-Fill flow using the Sandbox environment.
Overview
When you interact with the Sandbox environment, you’ll be able use the test users below to simulate different behaviors. You will simulate the possession checks utilizing the client-side SDK. No text messages will be sent and real user information will not validate - you must use the test users.
sandbox test users can only be used with project credentials. Attempting to use these test users with different project credentials will result in an unauthorized access error.
Unless specified below, you can introduce failures in the tests that would otherwise be successful:
-
If you call a step out of order, you will receive:
-
Status Code: HTTP 403
-
Response:
{"code":1003,"message":"step not allowed"}
-
-
If a required field is missing, you will receive:
-
Status Code: HTTP 400
-
Response:
{"code":1001,"message":"field 'flowType' is missing"}
-
Steps
These are the steps you’ll follow for each of the tests.
-
For Start:
-
Send into request:
-
flowType
: use eithermobile
ordesktop
-
phoneNumber
: (use number from table above) -
finalTargetUrl
:https://www.prove.com
-
dob
orlast4SSN
(otherwise, pass it in to Challenge request)
-
-
Response will return:
-
authToken
-
correlationId
-
next = v3-validate
-
-
-
For Validate:
-
Send into request:
correlationId
(from Start response)
-
Response will return:
-
success = true
-
challengeMissing = false
-
next = v3-challenge
orv3-complete
-
-
-
For Challenge (only if the previous Validate call returned:
next = v3-challenge
):-
Send into request:
-
correlationId
(from Start response) -
dob or last4SSN
(if still needed)
-
-
Response will return:
-
success = true
-
Individual information (from table above)
-
next = v3-complete
-
-
-
For Complete:
-
Send into request:
-
correlationId
(from Start response) -
Individual information (from table above)
-
-
Response will return:
-
success = true
-
changeDetected
(true if there is a data mismatch with the Challenge response) -
next = done
-
-
Short-Term Test User
Please temporarily use the below test user when performing initial testing with cURL or Postman. This test user intentionally skips the client-side SDK authentication to help you understand sequence of API calls; however the client-side authentication is a required integration element (it initiates the Prove possession check).
Phone Number | First Name | Last Name | Address | City | State | Zip | Date of Birth | SSN | |
---|---|---|---|---|---|---|---|---|---|
2001001695 | Milo | Pinson | 6377 Birchwood Hill | Littleton | CO | 80161-2001 | 1/17/1981 | 847350596 | mpinsonm@dyndns.org |
After initial short-term testing, please implement the client-side SDK and utilize the remaining test users below to fully test your implementation. Please see the Quick Start Guide to better understand required components.
Prove Pre-Fill Test Users
Below is the comprehensive list of Prove Pre-Fill Test Users. Follow the steps above in the UAT environment to test out your implementation to ensure it’s working properly. Please see the Outcomes Table to review scenarios to test and interpretation of success and failed states.
Key points about possession:
-
Mobile Flow Testing: When prompted for your OTP during
mobile
flow testing, you must use1234
to simulate a successful OTP. Any other combination of numbers will simulate a failure. Please use Marcia Longo to test that OTP setup is functioning as expected. -
Desktop Flow Testing: You will simulate Instant Link during Desktop flow testing. You know your logic is set up correctly if your test user passes the Validate step
Phone Number | First Name | Last Name | Address | City | State | Zip | Date of Birth | SSN | |
---|---|---|---|---|---|---|---|---|---|
2001001687 | Agretha | Chene | 4861 Jay Junction | Boston | MS | 02208 | 12/29/1994 | 369956933 | achenee@printfriendly.com |
2001001688 | Nevin | Chattey | 9398 Scott Plaza | Austin | TX | 78744 | 3/20/1980 | 542742985 | nchatteyf@techcrunch.com |
2001001693 | Marcia | Longo | 00 Mallard Park | New Orleans | LA | 70165 | 7/19/1982 | 470806227 | mlongok@amazonaws.com |
Prove Pre-Fill Outcomes and Test Scenarios
The below table provides Pre-Fill outcome possibilities including which sandbox users to test with, testing notes and interpretation of each success and failed state in Production. The Prove Pre-Fill Test Users table above contains the comprehensive list of test users including mock data. If you are trying to troubleshoot Success=False
in the API response, please see the next section.
API Response Troubleshooting Tips
Please see the below table for assistance troubleshooting when Success=False
in an API response. To understand what this indicates in Production, please see the Pre-Fill Outcomes and Test Scenarios table above.
Server Side Call | Possible Behaviors Resulting in Success=False | Troubleshooting Tips |
---|---|---|
/start | Not Applicable | Please see Error and Status Codes page for common 400 response errors |
/validate | PreFill Sandbox Users intended to fail this step: Agretha Chene,Nevin Chattey | Please see Test Scenario Table for which test users fail each scenario |
/validate | Client Side SDK Authenticate() function wasn’t called or was configured incorrectly* *Required for all sandbox users except Milo Pinson (who is only used for initial temporary testing) | See the Client Side SDK implementation guide |
/validate | Wrong one-time password (OTP) entered | See the Client Side SDK implementation guide |
/challenge | The phone number entered isn’t associated with the SSN/partial or DOB entered (you entered Tod Weedall’s Phone number with different last4 than test user data) | See Pre-Fill Test User Table for sandbox test user data |
/complete | First Name or Last Name or SSN isn’t associated with the phone number entered (you entered Tod Weedall’s Phone number with different last4) | Please see Test Scenario Table for which test users fail each scenario |
If you are encountering 400 or 500 response errors when running these test scenarios, please refer to the Error and Status Codes page.
If you’re still having issues, send your correlationId
from a failing request. Use either the Support button in the Portal or contact your account representative.
Production Access
To access this functionality in Production, please contact your sales representative.