> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kirafin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Test value tables

> The exact values that produce each sandbox outcome.

Send one of these and the sandbox takes the matching path. Send anything else and it takes the ordinary one.

These work in **sandbox only**. In production the same fields carry real data and the values below mean nothing.

## Creating a business

The outcome follows from the business's tax identifier — the `ein` you send when you create a sub-client.

| Send `ein`    | What happens                                                                                                            |
| ------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `111111111`   | **Refused outright.** The business cannot be onboarded and sending it again will not change that                        |
| `111111113`   | **Refused on the data.** Comes back naming a field that is wrong or missing                                             |
| `222221006`   | **Accepted, then rejected on review.** The application is taken and left pending, and the decision comes back a refusal |
| `222221005`   | **Accepted, and decided later.** The application is taken and left pending, and the decision comes back an approval     |
| Anything else | **Approved on the spot**, with no waiting period at all                                                                 |

## Paying out

The outcome follows from the **cents** of the amount, whatever the whole part is — `10.03`, `1250.03` and `7.03` all take the same path.

| Cents         | What happens                                                                               |
| ------------- | ------------------------------------------------------------------------------------------ |
| `.02`         | **Held for a compliance check, then approved.** The movement pauses and resumes on its own |
| `.03`         | **Held for a compliance check, then rejected.** The movement pauses and does not resume    |
| `.04`         | **Accepted, then declined.** The payout is taken and a later callback fails it             |
| Anything else | Approved immediately, with no hold                                                         |

`.04` is the one that proves a refusal can arrive after the payment was accepted: the call answers as taken, and the payout turns `FAILED` seconds later. An integration that tells its customer the money is on its way at acceptance is the one this catches.

## Depositing

The outcome follows from the amount you simulate.

| Simulate `amount` | What happens                                     |
| ----------------- | ------------------------------------------------ |
| `11`              | The deposit is **returned** rather than credited |
| Anything else     | The deposit credits the account's balance        |

The amount is compared as a decimal, not as text, so `11`, `"11"`, `11.0` and `"11.00"` are the same value and all take the returned path.

[Simulate a deposit](/api-reference/virtual-accounts/simulate-a-deposit) is the call. On a `fiat` account the deposit is complete on arrival; on a `crypto` one it settles first.

## What these are not

They are not a mode you switch on, and there is no flag that makes the sandbox behave "normally" again — a value either matches one of the rows above or it does not.

They are also not a substitute for handling the real thing. A rejection you forced is the same rejection your customer will meet; a rejection you never forced is a branch you have never run.