Prove Pre-Fill Sandbox Testing

​

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 Pre-Fill Test User

Please temporarily use 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).

​

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 intepretation 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 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

​

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.