Skip to main content

​
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:

​
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. Searching for employers while connected a sample account in the Sandbox mode of Argyle Link.

​
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: 
// apiHost for Sandbox: 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 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:

​
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: 
// Sandbox periodic scan error

{
    "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:

​
Possible errors

You can trigger these errors in the sandbox:
  • account_inaccessible
  • account_incomplete
  • account_disabled
  • expired_credentials
  • invalid_account_type
  • invalid_auth
  • login_attempts_exceeded
  • mfa_attempts_exceeded
  • mfa_exhausted
  • mfa_not_configured
  • physical_mfa_unsupported
  • platform_unavailable
  • service_unavailable
  • system_error
  • tos_required
  • trial_connections_exhausted
  • trial_period_expired
  • unsupported_auth_type
  • unsupported_mfa_method
  • account_disconnected
  • bank_and_card_update_failed
  • card_update_failed
  • confirmation_timeout
  • incompatible_config
  • invalid_account_state
  • mfa_attempts_exceeded
  • mfa_exhausted
  • mfa_not_configured
  • missing_allocation
  • missing_allocation_type
  • not_supported
  • not_supported_by_employer
  • physical_mfa_unsupported
  • rejected_bank_account
  • rejected_card
  • rejected_microdeposit
  • rejected_routing_number
  • service_unavailable
  • system_error
  • unsupported_allocation_type
  • unsupported_bank_accounts
  • unsupported_bank_account_country
  • unsupported_mfa_method
  • waiting_period
  • auth-required
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.
  • account_disconnected
  • incompatible_config
  • invalid_account_state
  • missing_allocation
  • missing_allocation_type
  • not_supported
  • not_supported_by_employer
  • unsupported_allocation_type
  • unsupported_bank_accounts
  • waiting_period
  • bank_and_card_update_failed
  • card_update_failed
  • confirmation_timeout
  • mfa_attempts_exceeded
  • mfa_exhausted
  • mfa_not_configured
  • physical_mfa_unsupported
  • rejected_bank_account
  • rejected_card
  • rejected_microdeposit
  • rejected_routing_number
  • service_unavailable
  • system_error
  • unsupported_bank_account_country
  • unsupported_mfa_method
This is what you’ll see in Console when you trigger the auth_required error: An auth_required error shows that the user needs to reconnect their payroll account.

​
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 above for a complete list of values for the error field.
  1. Call the password-encoding endpoint: 
    // POST /v1/test-password/encode

{
    "failure": {
        "fail_on": "connection",     
        "error": "account_disabled"
    }
}
  2. Receive a JSON response with the encoded password: 
    {
    "test_password": "eyJmYWlsdXJlIjogeyJmYWlsX29uIjogImNvbm5lY3Rpb24iLCAiZXJyb3IiOiAiYWNjb3VudF9kaXNhYmxlZCJ9fQ=="
}
  3. 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.
  • account_disconnected
  • incompatible_config
  • invalid_account_state
  • missing_allocation
  • missing_allocation_type
  • not_supported
  • not_supported_by_employer
  • unsupported_allocation_type
  • unsupported_bank_accounts
  • waiting_period
  • bank_and_card_update_failed
  • card_update_failed
  • confirmation_timeout
  • mfa_attempts_exceeded
  • mfa_exhausted
  • mfa_not_configured
  • physical_mfa_unsupported
  • rejected_bank_account
  • rejected_card
  • rejected_microdeposit
  • rejected_routing_number
  • service_unavailable
  • system_error
  • unsupported_bank_account_country
  • unsupported_mfa_method
Insert the encoded test_password into the password field of the payroll login screen.