> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.useroot.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.useroot.com/_mcp/server.

# 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

```python
ALLOWED_TEST_ACCOUNT_NUMBERS = [
    "1234567890",
    "9999999999",
    "0000123456",
    "1111222233"
]
```

### Allowed Test Routing Numbers

```python
ALLOWED_TEST_ROUTING_NUMBERS = [
    "111000025",
    "021000021",
    "011401533",
    "091000022"
]
```

### Allowed Test Card Numbers

```python
ALLOWED_TEST_CARD_NUMBERS = [
    "4111111111111111",  # Visa test card
    "5555555555554444",  # Mastercard test card
    "378282246310005",   # Amex test card
    "6011111111111117"   # Discover test card
]
```

### 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):

| **Payment Rail**    | **Simulated Processing Delay** | **Description**              |
| ------------------- | ------------------------------ | ---------------------------- |
| INSTANT\_BANK (RTP) | 5 seconds                      | Real-time payment processing |
| INSTANT\_CARD       | 10 seconds                     | Card payment processing      |
| SAME\_DAY\_ACH      | 30 seconds                     | Same-day ACH settlement      |
| STANDARD\_ACH       | 1 minute                       | Standard ACH processing      |
| WIRE                | 3 minutes                      | Wire transfer processing     |

### 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):

| # | **Scenario**                           | **Description**                                                                                 | **Payee/Payer Name**                                   | **Webhook**            |
| - | -------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ---------------------- |
| 1 | **Payout** Status: Initiated → Failed  | Payout initiated but failed during processing.                                                  | John Failed                                            | *failed*               |
| 2 | **Payout** Status: Initiated → Success | Payout succeeds. Terminal state depends on rail: Settled (instant rails) or Debited (ACH rails) | Any name except John Failed (e.g., Acme Supplier Inc.) | *settled* or *debited* |
| 3 | **Payin** Status: Initiated → Failed   | Payin initiated but failed during processing.                                                   | John Failed                                            | *failed*               |
| 4 | **Payin** Status: Initiated → Success  | Payin succeeds. Terminal state: Settled (ACH rails only)                                        | Any name except John Failed (e.g., Jane Q. Customer)   | *settled*              |

**Note:** The reserved name **`John Failed`** always triggers the failure scenario for both payouts and payins. All other names simulate a successful transfer.