Test Environment
As part of the test entity, you can fully simulate the product experience. Each test entity is preloaded with sample payees and payers. For payouts and payins, the simulation bank decides success or failure from the payee or payer name as described below.
For Payouts: Use any payee name for a successful simulated payout, except John Failed, which simulates a payout that fails after initiation.
For Payins: Use any payer name for a successful simulated payin, except John Failed, which simulates a payin that fails after initiation.
Card and bank details do not determine which scenario is triggered, but a general sanity check is performed on the provided card and bank information. A predefined list of valid card numbers, account numbers, and routing numbers is provided for use in the test entity. Random or invalid numbers are not accepted.
For sandbox bank values in currencies other than USD, see Test Values by Currency under Test Environment. For bank field shapes (country_code, currency_code, routing_number_type, and how account_number / routing_number are formatted), see Country and Currency under Payment Methods API.
Allowed Test Bank Account Numbers
Allowed Test Routing Numbers
Allowed Test Card Numbers
Payment Rail Restrictions
Payout Rails (Money Out)
In the test environment, payouts support all available payment rails:
- INSTANT_BANK (RTP) - Real-time payments
- INSTANT_CARD - Card payments
- SAME_DAY_ACH - Same-day ACH settlement
- STANDARD_ACH - Standard ACH processing
- WIRE - Wire transfers
Payin Rails (Money In)
In the test environment, payins only support ACH rails, similar to the live environment:
- SAME_DAY_ACH - Same-day ACH Debit
- STANDARD_ACH - Standard ACH Debit
Note: Attempting to use non-ACH rails (such as INSTANT_BANK, INSTANT_CARD, or WIRE) for payins will result in an error, as ACH Debit is the only supported method for pulling funds from payer accounts.
Processing Delays and Timing
The test entity simulates bank processing delays based on the payment rail so webhooks and status transitions occur after a short, rail-specific wait (when simulated delays are enabled in the worker environment):
Webhooks
The test entity supports webhooks just like your production entity. If you have a test entity and create a webhook for a scenario that emits webhooks, you will receive them after the realistic processing delay for the selected payment rail.
Examples:
- If you create a payout using the INSTANT_CARD rail for a payee named Acme Supplier Inc., the webhook will be sent approximately 10 seconds after the payout is initiated (when simulated delays are enabled).
- If you create a payin using the SAME_DAY_ACH rail for a payer named Jane Q. Customer, the webhook will be sent approximately 30 seconds after the payin is initiated (when simulated delays are enabled).
Scenarios
The following scenarios work for both payouts and payins (use the payee name for payouts and the payer name for payins):
Note: The reserved name John Failed always triggers the failure scenario for both payouts and payins. All other names simulate a successful transfer.