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; however no text messages will be sent in this environment. Also note that real user information will not validate - you must use the test users.

Unless specified below, you can introduce failures in the tests that would otherwise be successful:

  • If you call a step not specified in the next field (or out of order), you will receive:

    • Status Code: HTTP 403

    • Response: {"code":1003,"message":"step not allowed"}

  • If you don’t pass in a required field, 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 either mobile or desktop

      • phoneNumber: (use number from table above)

      • finalTargetUrl: https://www.prove.com

      • either dob or last4SSN (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 or v3-complete

  • For Challenge (only if the previous Validate call returned: next = v3-challenge):

    • Send into request:

      • correlationId (from Start response)

      • either dob or last4SSN (if you didn’t pass it into Start request)

    • 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 the data doesn’t exactly match what was returned from Challenge response)

      • next = done

Short-Term Prove Identity Test User

Please temporarily use below test user when performing initial testing with Postman or cURL. 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 NumberFirst NameLast NameAddressCityStateZipDate of BirthSSNEmail
2001004000MartinaGoodram28965 Homewood PlazaLittle RockAR722047/26/1995490959347mgoodram0@nasa.gov

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 our Quick Start Guide to better understand required Integration Components.

Prove Identity Test Users

For each of the 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.

A few things to note on the Possession Portion:

  • Mobile Flow Testing: When prompted for your OTP during mobile flow testing, you must use 1234 to simulate a successful OTP. Any other combination of numbers will simulate a failure. Please use Benji Harper user 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 NumberFirst NameLast NameAddressCityStateZipDate of BirthSSNEmail
2001004009BenjiHarper27 Financial PlaceBakersfieldCA93301-242509/02/1994565252770bharperd@superstars.com
2001001699CarneyReinisch582 Coleman PointSan AntonioTX782303/3/2000166521601creinischq@php.net
2001001698EnidWildt861 Karstens CircleWashingtonDC204096/18/1996212285822ewildtp@eepurl.com

Prove Identity Outcomes and Test Scenarios

The below table provides Prove Identity outcome possibilities including which sandbox users to test with, testing notes and interpretation of each success and failed state in Production. The Prove Identity 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.

Sandbox Troubleshooting Tips

Please see below table for assistance troubleshooting when Success=False in an API response. To understand what this indicates in Production, please see the Prove Identity Outcomes and Test Scenarios table above.

Server Side CallBehavior Resulting in Success=FalseTroubleshooting Tips
/startNot ApplicablePlease see Error and Status Codes page for common 400 response errors
/validateProve Identity Sandbox user is intended to fail this step: Carney ReinischPlease see Test Scenario Table for which test users fail each scenario
/validateClient Side SDK Authenticate() function wasn’t called or was configured incorrectly* *Required for all sandbox users except Martina GoodramSee our Client Side SDK implementation guide
/validateWrong one-time passcode (OTP) enteredSee our Client Side SDK implementation guide
/completeFirst Name or Last Name or SSN isn’t associated with the phone number entered (eg you entered Cathy Blazevic’s Phone number with different last4)Please see Test Scenario Table for which test users fail each scenario

If you are encountering errors when running these test scenarios, please refer to the Error and Status Codes page.

If you’re still having issues, send us your correlation ID from a failing request. We may be able to provide additional insight after reviewing our logs using either the Support button in the Portal or contacting your account representative.

Production Access

To access this functionality in Production, please contact your sales representative.

Was this page helpful?