On this page, learn how to:

• Test different data sets
• Test deposit switching
• Run periodic scans
• Trigger errors

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:

//for testing, use the Sandbox environment:
//
//apiHost: 'https://api-sandbox.argyle.com/v1'

payDistributionUpdateFlow: true,
payDistributionConfig: "<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 Link Emulator.

The guide also includes payDistributionConfig examples for different use cases that can be copy and pasted into your Argyle Link initialization or Link Emulator 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.

Period 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

Use this endpoint to trigger the scan in the sandbox:

https://api-sandbox.argyle.com/v1/accounts/<acc-id>/periodic-scan

This endpoint accepts POST requests with an empty body.

<acc-id> must be a sandbox accounts.id, otherwise this error is returned:

{
    "account": [
        "Periodic scan can be manually scheduled only for sandbox accounts."
    ]
}

This endpoint can be used for testing webhook integration and new data arrival.

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 Pay distribution errors documentation for complete definitions of these errors.

Trigger errors via Console

You can trigger errors directly in Console using the Link Emulator. 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:

{
    "failure": {
        "fail_on": "connection",     
        "error": "account_disabled"
    }
}

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 for a complete list of values for the error field.

2. Call the password-encoding endpoint:

POST /v1/test-password/encode

{
    "failure": {
        "fail_on": "connection",     
        "error": "account_disabled"
    }
}

3. Receive a response with the encoded password:

{
    "test_password": "eyJmYWlsdXJlIjogeyJmYWlsX29uIjogImNvbm5lY3Rpb24iLCAiZXJyb3IiOiAiYWNjb3VudF9kaXNhYmxlZCJ9fQ=="
}

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.