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

# Sandbox testing

> How to test an integration before going live

Sandbox is a separate environment with its own keys. Nothing you do there touches real money or
real cards.

## Switching environments

The base URL is the same in both environments — **your key determines which one you hit**.

```
https://api-v4.reeple.ai
```

Test keys are marked as such in the key itself, so a key intended for testing cannot
accidentally charge a real card.

<Warning>
  Test and live keys are issued as a matching set: a test public key only works alongside a test
  secret key and the test encryption key. Mixing an encryption key from one environment with an
  API key from the other produces a `400 — Something went wrong while trying to decrypt your
      payload`.
</Warning>

## What only exists on sandbox

|                                                                          | Sandbox   | Production             |
| ------------------------------------------------------------------------ | --------- | ---------------------- |
| [`POST /charge/data/encrypt`](/encryption#the-sandbox-encryption-helper) | Available | **Not available**      |
| Card authentication                                                      | Simulated | Real 3-D Secure        |
| Bank transfer settlement                                                 | Simulated | Real bank notification |

<Warning>
  The encryption helper is the big one. If your integration calls it, it will break the moment
  you point at production. Implement [encryption](/encryption) yourself before going live.
</Warning>

## Test cards

<Note>
  Card numbers, expiry dates and CVVs for the various authentication paths — 3-D Secure, no-auth,
  declines — are issued with your sandbox credentials. Contact Reeple if you don't have them.
</Note>

The authentication path is driven by the card you use, plus the optional `authOption` field:

| Scenario          | How to trigger                                    |
| ----------------- | ------------------------------------------------- |
| 3-D Secure        | Default for a 3DS-enrolled test card              |
| No authentication | `"authOption": "NOAUTH"` in the card object       |
| Saved card        | `"savedCardId": <id>` instead of the card details |

See [Pay with a card](/api-reference/payments/pay-with-card) for the exact payloads.

## Testing bank transfers

[List banks](/api-reference/banks/list-banks) returns real bank codes on sandbox. Pay with one,
and the response gives you a `recipientAccount`. On sandbox no real transfer is needed —
settlement is simulated.

## A checklist before going live

<Steps>
  <Step title="Your own encryption works">
    Run a full create, pay and status cycle without calling `/charge/data/encrypt` at all.
  </Step>

  <Step title="You poll to a final status">
    Confirm you branch on `isFinalStatus`, not on the pay-order response.
  </Step>

  <Step title="You verify server-side">
    Confirm [Verify an order](/api-reference/verification/verify-order) runs with your secret key
    from your backend before anything is fulfilled.
  </Step>

  <Step title="Fulfilment is idempotent">
    Verify the same reference twice and confirm the order is only fulfilled once.
  </Step>

  <Step title="You handle pending">
    Confirm a payment that never completes leaves the order pending rather than failed, and that
    a backend job reconciles it.
  </Step>

  <Step title="Swap the keys">
    Replace test keys — all three — with live ones. See
    [Authentication](/api-reference/authentication).
  </Step>
</Steps>