Testing in sandbox

Sandbox is a complete copy of the Pay-In API that moves no real money. Use it to build and certify your integration before you go live.

Base URL	https://sandbox-api.cashela.com
Credentials	A key from the Sandbox card of the Developer Portal
Money	None. No real payment happens.

Drive a deposit to its final status

In sandbox no real payment happens, so your deposits stay in progress until you decide their outcome with simulate. It moves a sandbox deposit to COMPLETED, DECLINED or CANCELLED exactly as a real payment would, including the signed notification to the deposit’s notification_url.

POST/api/v1/pay-in/sandbox/transactions/{reference}/simulate

Environment	Sandbox only. In production this path answers 404.
{reference}	The deposit’s reference, your external_identifier, or the deposit id.
Body	{ "status": "COMPLETED" }, or DECLINED, or CANCELLED.
Limit	30 requests per minute.

curl -X POST https://sandbox-api.cashela.com/api/v1/pay-in/sandbox/transactions/order-2026-0001/simulate \
  -u "$CASHELA_SANDBOX_API_KEY:$CASHELA_SANDBOX_API_SECRET" \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -d '{ "status": "COMPLETED" }'

The response is the deposit, as Get a deposit returns it, with its new status.

HTTP	When
404	Unknown reference, a deposit of another account, or the call was sent to production.
409	The deposit is already final (PARTNER_PAYIN_SIMULATION_ALREADY_FINAL). Only a deposit still in progress can be simulated.
422	status is not COMPLETED, DECLINED or CANCELLED ("The selected status is invalid.").

A typical certification run

1. Happy path. Create a deposit and simulate COMPLETED. Verify the notification signature, your handling of the credit, and that you answer 2xx.
2. Failure path. Create a second deposit and simulate DECLINED or CANCELLED. Verify that your system marks the order as unpaid and does not credit anything.
3. Reconcile. Read both deposits with Get a deposit and compare them with your records.
4. Idempotency. Repeat a creation request with the same external_identifier and the same body: you must get the original deposit. Repeat it with a different body: you must get 409.
5. Validation. Send invalid payer data (for example a phone from another country) and check that your form shows the 422 messages.
6. Recovery. Use the re-send endpoint to get a notification again.

Repeat until the go-live readiness checks are green. The minimum is 5 completed deposits, 3 notifications confirmed with 2xx, 1 error case handled (a deposit ending DECLINED, CANCELLED or FAILED), no failed authentication in the last 7 days and activity in the last 14 days.

Sandbox is not production

Production validates more strictly

Production applies strict validation that sandbox may not apply: phone number valid for the deposit’s country, document format and check digit, deliverable email and postal code pattern. Sandbox may accept data that production rejects. Test with data in the real format of each country, and handle every 422 in your form. See Payer data & documents.

• The catalog (countries, methods, fees, limits) can differ between sandbox and production. Never copy method codes from sandbox into your production code: always ask Get payment methods.
• Sandbox and production credentials, deposits and references are separate.
• Avoid failed authentication attempts in sandbox (wrong key or secret): they turn the Clean authentication check red for 7 days.