# 

There are two environments. Only one of them moves money.

| Environment | Base URL | Moves real funds |
|  --- | --- | --- |
| Sandbox | https://api.sandbox.paradisegateway.net | No |
| Production | https://api.paradisegateway.net | Yes |


Sandbox reaches the processors' own test systems, so a transaction gets a real processor response without any funds moving. Build against it until you are ready to go live.

Your API key and client ID are issued per environment. A production key does not
work against sandbox, and the reverse. See [Authentication](/docs/get-started/authentication).

## The Try it button talks to a mock

Requests you send from the API reference go to a **mock server**, not to any of
the environments above. The mock replies from the examples written into the API
description, so what comes back is well formed and correctly shaped but entirely
made up.

That is deliberate: a public documentation page must not be able to push a
transaction into a live processor.

Two things follow from it.

* **Values in a mock response are illustrative.** Identifiers, auth codes, and
timestamps are sample data. Never carry one into a real integration.
* **The mock echoes what you send.** Edit `amount` in the request and the same
amount comes back, so you can see the shape of a response for your own values.


By default the mock returns the first response example for an operation. To ask
for a specific one, name it in a header:

```http
x-redocly-response-body-example: saleDeclined
```

That is how you see a declined body without a real decline.

## No card number triggers a decline

Against the real gateway, **no test card number causes a decline**. Declines come
from the issuer's own test system and depend on the processor configuration
behind your merchant account, not on which test PAN you pick.

If you have seen a table of "decline simulation" card numbers elsewhere, it was
wrong. To exercise your decline handling, use the mock and the header above, or
ask your implementation contact to arrange a decline on the processor side.

## Test cards

Test card numbers, their CVV values, and the address to use for AVS testing are
in [Test cards and test accounts](/docs/reference/test-cards). All of them use
expiry **12/28**.

Never send a real card number to sandbox.

## Going live

Work through this before you switch the base URL:

1. Swap the base URL for the production host.
2. Swap in your production API key and client ID.
3. Confirm you branch on `result`, not on the HTTP status. See
[Handle declines](/docs/payments/handle-declines).
4. Confirm your retry logic treats a `502` differently from a `500` or `503`. See
[Errors and retries](/docs/get-started/errors).
5. Confirm no log line anywhere in your stack holds a full card number, a CVV,
or a bank account number.
6. Send one small live transaction and refund it.


## What the API does not have yet

Worth knowing before you design around them:

* **No webhooks.** The API sends no outbound notifications. Poll
`GET /v1/transactions` for state that arrives after the response, such as
settlement or an ACH return.
* **No idempotency key.** Retrying a `POST /v1/transactions` that already
succeeded creates a second transaction. Reconcile before retrying a payment.
* **No 3-D Secure.** There is no field to carry a 3DS result.