Transfer Sandbox

When creating transfers in Sandbox, see the /transfer/authorization/create documentation on how to generate approved or declined authorization responses.

In Sandbox, money doesn't move automatically, so you will need to simulate transfer events and fire transfer webhooks manually. Call the /sandbox/transfer/simulate and /sandbox/transfer/sweep/simulate endpoints to simulate transfer events and sweeps and /sandbox/transfer/fire_webhook to fire transfer webhooks in Sandbox. By default, all transfers and sweeps created in Sandbox remain at the pending status until the simulate endpoints are called. No money is moved by these endpoints.

For a full list of transfer simulations available in Sandbox, see Sandbox endpoints.

For a general overview of the Plaid Sandbox environment, see Sandbox overview.

In the Sandbox environment, recurring transfers can be simulated by using a test_clock object.

A test_clock is a mock clock that has a virtual_time field, indicating the current timestamp on this test clock. You can attach a test_clock to a recurring_transfer in Sandbox by providing a test_clock_id when calling /transfer/recurring/create.

You can advance the virtual_time on a test_clock to a higher value by calling /sandbox/transfer/test_clock/advance, but you can never decrease the virtual_time.

When a test clock is advanced, all active recurring transfers attached to this clock will generate new originations as if the time had elapsed in Production. For instance, assuming a test clock is attached to a weekly recurring transfer, if the test clock is advanced by 14 days, you should see two new transfers being created.

Note that advancing a test clock does not change the status of the transfer objects created by a recurring transfer. Transfers will stay in pending status unless you call /sandbox/transfer/simulate to simulate a transfer status update.

1. Create a test clock using /sandbox/transfer/test_clock/create, with a virtual_time of "2022-11-14T07:00:00-08:00", which is 2022-11-14 7AM PST (Monday).

2. Create a weekly recurring transfer on every Tuesday using /transfer/recurring/create with the test_clock_id returned from step 1. The recurring schedule starts on 2022-11-15, and ends on 2022-11-30.

3. Advance the test clock to "2022-11-15T23:59:00-08:00", which is the end of day 2022-11-15 PST (Tuesday).

4. Since we advanced the test clock to the last minute of Tuesday and the recurring transfer is also scheduled on every Tuesday, we expect to see 1 transfer being created. Inspect the recurring transfer created in step 2 with /transfer/recurring/get. Confirm the transfer_ids field now has 1 element, and the status field is "active".

5. Advance the test clock to "2022-11-29T23:59:00-08:00", which is the end of day 2022-11-29 PST (Tuesday).

6. Inspect the recurring transfer created in step 2 with /transfer/recurring/get. Confirm that the transfer_ids field now has 3 elements, and the status field is now "expired".

7. Advance the test clock to "2022-12-06T23:59:00-08:00", which is the end of day 2022-12-06 PST (Tuesday).

8. Inspect the recurring transfer created in step 2 with /transfer/recurring/get. Confirm that the transfer_ids field still has 3 elements, and the status field remains "expired".

Testing Instants Payouts works the same way as testing ACH Transfers. Create the transfer and use the /sandbox/transfer/simulate endpoint to simulate its progression.

In the Sandbox environment, the Plaid Ledger balance has fixed available balance of $100.00. Initiating credits will not deplete this balance. To test the scenario of running out of funds and triggering an NSF authorization decline, attempt to authorize a Instant Payout for over $100.00.

To test the /transfer/eligibility/get endpoint in Sandbox, login using the user_good user sandbox account (see here for more information), and use the first 2 checking and savings accounts in the "First Platypus Bank" institution (ending in 0000 or 1111), which will return true. Any other account will return false.