Advanced Testing

Follow these tutorials to learn about advanced testing scenarios on the sandbox.

Test different data sets#

When you connect sample payroll accounts, you can test two different sets of employment data: rideshare/delivery and general data. These represent the different types of users that may use your application.

Prerequisites#

Before testing different data sets, you must:

• Have your sandbox API keys at hand.
• Connect sample payroll accounts.

Add user data#

Within the sandbox environment, there are two slightly different data sets:

• Rideshare/Delivery — if you select a gig company like Uber or Doordash, the data will have more activity (duration, distance, etc.) information.
• General — if you select any other employer or payroll provider, the data will reflect traditional employment records.

Select different Link item types to experiment with both data sets. Connect a gig Link item to test with a gig data set. Connect a non-gig Link item to test with a payroll/employer data set.

Test deposit switching#

After a user connects a payroll account through Argyle Link, you can ask them to:

• Redirect their pay, in whole or in part, to a new or existing bank account
• Add a debit card for instant payouts on their gig platform

This deposit switching process is initiated by including the following two lines in your Argyle Link initialization:

1// apiHost for Sandbox: https://api-sandbox.argyle.com/v1
2
3payDistributionUpdateFlow: true,
4payDistributionConfig: "<Your encrypted payDistributionConfig>"

The payDistributionConfig is an encrypted version of your DDS configuration, which contains the settings that determine which deposit switching screens and settings are shown to the user after they connect a payroll account.

Our Sandbox testing guide for deposit switching shows how to test a payDistributionConfig in Sandbox using Flows.

The guide also includes payDistributionConfig examples for different use cases that can be copy and pasted into your Argyle Link initialization or Link Flow in Sandbox mode for testing purposes.

Trigger periodic scans#

Periodic scans detect when a user or their employer has updated their employment data. Follow this tutorial to understand how to trigger a scan of sandbox data.

Prerequisites#

Before you triggering a periodic scan, you must:

• Have your sandbox API keys at hand.
• Connect sample payroll accounts.

Periodic scan data#

In the production environment, new data for connected payroll accounts is constantly generated and delivered to you—for example: new payouts, activities—during periodic data scans. For testing purposes, you can trigger a periodic scan to get new data for an account that is already connected.

A periodic scan for sandbox accounts returns 1-5 new payouts and activities. A periodic scan can be triggered as many times as you need for testing.

Trigger a scan of sandbox data#

Send a POST request to the following endpoint with an empty body: https://api-sandbox.argyle.com/v1/accounts/{id}/periodic-scan to trigger a periodic scan for Sandbox data.

{id} must be a sandbox accounts.id, otherwise this error is returned:

1// Sandbox periodic scan error
2
3{
4    "account": [
5        "Periodic scan can be manually scheduled only for sandbox accounts."
6    ]
7}

Trigger errors#

Sandbox mode gives you an opportunity to simulate error scenarios, so you understand how and why errors can occur in your implementation. You can also see how these errors appear for your users. You can trigger errors in two ways in the sandbox:

• Directly from Console.
• Programmatically via the Argyle API.

Prerequisites#

Before triggering errors, you must:

• Have your sandbox API keys at hand.
• Connect sample payroll accounts.

Possible errors#

You can trigger these errors in the sandbox:

See the Account connection errors and Direct deposit switching errors documentation for complete definitions of these errors.

Trigger errors via Console#

You can trigger errors directly in Console using Flows. See this video or follow the steps below to learn how to test this feature in Console:

1. Toggle the Simulate an error option to ON and select the error you want to test.
2. Toggle the Simulate a direct deposit switch option to test pay distribution errors. Account connection errors are available by default.
3. Copy the generated password and paste it into the Link login password field.
4. Click Connect.

Different error types behave differently at this stage:

• Connection errors occur immediately.
• You must manually trigger a periodic scan for a specific account to trigger a rescan error after successfully connecting an account.

This is what you'll see in Console when you trigger the auth_required error:

Trigger errors via API#

You can use an encoded JSON password to trigger errors via the API. See this video or follow the steps below to learn how to test this feature using the API:

1. Define a scenario in a JSON format, such as:

   1{
   2    "failure": {
   3        "fail_on": "connection",     
   4        "error": "account_disabled"
   5    }
   6}
   

   You can choose from these fail_on values:

   • connection - Use this value to simulate account connection errors.
   • pay_distribution_update - Use this value to simulate pay distribution errors.
   • rescan - Use this value to simulate rescan errors.

   See the possible errors section above for a complete list of values for the error field.

   
   

2. Call the password-encoding endpoint:

   1// POST /v1/test-password/encode
   2
   3{
   4    "failure": {
   5        "fail_on": "connection",     
   6        "error": "account_disabled"
   7    }
   8}
   

3. Receive a JSON response with the encoded password:

   1{
   2    "test_password": "eyJmYWlsdXJlIjogeyJmYWlsX29uIjogImNvbm5lY3Rpb24iLCAiZXJyb3IiOiAiYWNjb3VudF9kaXNhYmxlZCJ9fQ=="
   3}
   

4. Use the test_password that you received in the Link login password field and click Connect. Different error types behave differently at this stage:

   • Connection errors occur immediately.
   • You must manually trigger a periodic scan for a specific account to trigger a rescan error after successfully connecting an account.