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

# Deposits & Payouts

> Reserved phone numbers and account numbers that drive a sandbox transaction to a specific outcome.

Sandbox never contacts a real payment provider, so a transaction needs
something to tell it how to end. Send money to one of the reserved values
below and it resolves that way, every time.

These behave like production, not like a mock. The transaction is accepted,
sits pending for a few seconds, then settles — firing the same webhook, moving
the same balances and writing the same timeline as a real one. A failed payout
reverses the wallet debit, because a real failed payout does.

## Mobile money

Use as the customer phone number on a deposit, a payout, or an onramp. Any
format works — `+254700000001`, `254700000001` and `0700000001` are the same
number.

| Phone number    | Settles as                     | After |
| --------------- | ------------------------------ | ----- |
| `+254700000001` | Success                        | \~5s  |
| `+254700000002` | Success                        | \~5s  |
| `+254700000010` | Failed — insufficient funds    | \~5s  |
| `+254700000011` | Failed — account not found     | \~5s  |
| `+254700000012` | Failed — limit exceeded        | \~5s  |
| `+254700000013` | Failed — cancelled by customer | \~5s  |
| `+254700000020` | Never settles                  | —     |
| `+254700000021` | Success                        | \~60s |

## Bank payouts and card deposits

These aren't simulated. Bank and card providers run their own sandbox
environments, so those transactions dispatch for real outside production and are
tested against the provider's own test credentials and test cards — reserved
values here would take that away.

## Anything else succeeds

A number that isn't reserved settles successfully after the usual delay. That
keeps casual testing simple — you only need a reserved value when you want a
particular outcome.

## The cases worth testing

<AccordionGroup>
  <Accordion title="A payout that fails">
    `+254700000010` on a mobile money deposit or payout. Confirm
    you handle the `FAILED` webhook, surface the reason, and notice that the
    wallet debit is reversed — the balance returns to what it was.
  </Accordion>

  <Accordion title="A transaction that never settles">
    `+254700000020` stays pending forever. This is the one most integrations
    get wrong: money is committed but no terminal webhook ever arrives. Make
    sure something on your side eventually reconciles or escalates it rather
    than waiting indefinitely.
  </Accordion>

  <Accordion title="A slow provider">
    `+254700000021` takes about a minute. Useful for checking you aren't
    assuming a transaction is final just because the create call returned, and
    that your polling backs off sensibly.
  </Accordion>

  <Accordion title="Paying the wrong person">
    `+254700000002` succeeds but is registered to a different name than
    `+254700000001`. Pair it with
    [account validation](/v3/testing/account-validation) to test catching a
    mismatched recipient before you pay.
  </Accordion>
</AccordionGroup>

<Note>
  Deposits credit your wallet on the same reconciliation pass production uses, so
  the balance moves within about a minute of the deposit settling rather than
  instantly.
</Note>

<Warning>
  Reserved values mean nothing in production — they are ordinary numbers there.
  Make sure they don't survive into your production configuration.
</Warning>