Skip to main content

Sandbox and approval

Sign-up is open, so a new account starts in the sandbox. Everything about the integration is real from the first minute: keys, signatures, statuses, callbacks. Only the money is not.

What the sandbox is​

A provider named sandbox that accepts every order from an unapproved account and never touches funds. GET /gw/v1/methods reflects it: it lists what the sandbox can take, which is every method, every rail, and RUB and USD with no amount bounds. The payment details it returns are placeholders:

RailDetails
Sbpphone +70000000000, holder SANDBOX HOLDER, bank Sandbox Bank
C2ccard 4111 1111 1111 1111, holder SANDBOX HOLDER, bank Sandbox Bank
Phonephone +70000000000
noneaccount SANDBOX-ACCOUNT-0001

Driving a sandbox order​

The sandbox does nothing on its own: an order stays Created until you act or until it expires. On the order page in the cabinet, a sandbox order shows two buttons:

  • Simulate payment plays a provider confirmation. The order goes straight to Completed, the credited amount lands on your balance, and order.completed is delivered to your callback URL through the same worker, with the same signature, as a live order.
  • Simulate failure plays a provider rejection: Canceled, and order.cancelled.

Everything else works as live: expiry after lifetimeMinutes, GET on the order, appeals, the callback attempt list, Resend callback. Sandbox orders skip the platform's funds-confirmation step, so they complete immediately; live orders pass through Payed first.

The sandbox balance is not real money. It is reset when the account goes live.

Going live​

An administrator reviews the account and approves it. From that moment the same cash desks, the same keys and the same callback URLs route to live providers. Nothing changes in your code. The Settings page in the cabinet shows the current mode under Account, and the overview shows a notice while the account is under review.

If the sandbox provider is switched off on the platform, an unapproved account gets 400 MERCHANT_NOT_APPROVED on order creation until it is approved.

Limits that can stop traffic once live​

  • Turnover limits. A cap in USD per cash desk, merchant or the whole platform, per hour, day or calendar month. When reached, orders answer TRAFFIC_LIMIT_REACHED until the window rolls over. See Limits.
  • The appeal guard. A provider with too many open appeals is paused; traffic resumes once they are resolved. This is per provider, not per merchant.
  • A stop by the platform. Support can stop a cash desk; it answers SHOP_STOPPED with the reason, and the cash desk card in the cabinet shows the same reason.
  • Your own switch. A cash desk you disable answers SHOP_INACTIVE.

GET /gw/v1/methods reports all of these as available: false with a reason.