Sandbox
Where to test, and how the sandbox differs from production.
The sandbox is a separate deployment of the same API, with its own data, its own keys and the payments provider's sandbox. Build and test your integration there, then switch the base URL and the key.
| Sandbox | Production | |
|---|---|---|
| Base URL | https://sandbox.api.ramp.tucop.xyz | https://api.ramp.tucop.xyz |
| API keys | tcr_test_sk_... | tcr_live_sk_... |
| Payments provider | Sandbox | Production |
| Money | No real money moves | Real COPm and real pesos |
| Data | Separate from production | Your real users |
A key works only in its own environment. A test key sent to production, or a live key sent to the
sandbox, gets 401 invalid_api_key. GET /consumer shows which environment a key belongs to in
api_key.environment.
What the sandbox has
| Area | Sandbox |
|---|---|
| Sessions, parties, destinations, quotes, payments, limits | Yes |
Rates (GET /rates) | Yes, with the payments provider's sandbox rate. |
Withdraw and deposit (/withdrawals, /deposits) | Withdraw yes. Deposit no: the payments provider's sandbox does not create COP deposit accounts, so POST /deposits answers 422 provider_rejected there. It works in production. |
Webhooks and the event feed (GET /events) | Yes. Sandbox endpoints and events are separate from production. |
| Payments provider | The payments provider's sandbox. No real money moves. |
| Payments provider webhooks | Not sent by the payments provider's sandbox. Payment status comes from TuCOP polling the payments provider, about once a minute. |
P2P (/p2p, TuCOP's own apps only) | No. P2P orders are settled by TuCOP operators and only run in production. |
The payments provider's sandbox has no Bre-B directory, so the sandbox answers the lookup itself: a destination
is verified a few seconds after you create it, with the party's verified name for a first-party key
and the owner_name you sent for a third-party key (Sandbox Holder for a
key lookup, sent without owner_name). A key ending in 0000 is rejected with
directory_no_match, so you can test that path. Production always asks the real directory.
Identity verification in the sandbox goes through the payments provider's sandbox. TuCOP can approve a test party's identity check for you; ask at support@tucop.org.
Things to keep in mind:
- Your sandbox consumer, keys, limits and webhook endpoints are separate from production. Create sandbox keys in the console: switch it to Sandbox. The sandbox consumer is created the first time you open that tab.
- Webhooks from the sandbox are signed with the sandbox endpoint secrets, not the production ones. Create sandbox endpoints from the console's Sandbox page, under Avisos (see Webhooks).
- Do not use real identity documents, bank accounts or Bre-B keys of real people in the sandbox.
- Do not run automated tests against production. Every production order is a real order that a TuCOP operator acts on.
Finishing a P2P order without an operator
P2P is not mounted on the shared sandbox today. When it is enabled for a test deployment, POST /p2p/orders/{id}/sandbox stands in for the operator. The same wallet
signature as the other order routes is required. The body is {"outcome":"complete"} or
{"outcome":"cancel"}.
complete on an off-ramp records a simulated deposit (the hash is not a Celo transaction), claims
the order and marks the payout done. On an on-ramp it does the same from AWAITING_REVIEW, so
upload the payment proof first; from AWAITING_PROOF the response is 409 sandbox_proof_required.
cancel works only while the order is still unfunded (AWAITING_DEPOSIT or AWAITING_PROOF).
Calling it again after the order is already completed or cancelled returns the same status. Production does not mount this route.