Limits and protection

What can slow an integration down or stop it, in one place. None of these are surprises if you read fault.code.

Rate limits

Endpoint	Limit	Keyed by	On excess
POST /gw/v1/orders	30 requests per 10 seconds, 5 queued	cash desk key	429
GET /api/pay/{id} (payment page data)	100 requests per 10 seconds, 10 queued	client IP	429
Cabinet sign-in	10 requests per minute	client IP	429
Other gateway calls	none

A 429 has an empty body. Back off for the window and retry; if you regularly need more than three orders a second from one cash desk, contact support.

Amount limits

Three layers, all in USD after conversion at the captured rate:

1. Provider capability. Each provider declares a min and max per rail and currency in the customer's currency; GET /gw/v1/methods shows the widest window currently offered.
2. Cash desk limits. Set on the cash desk in the cabinet, 0 meaning no bound. Outside them the order answers AMOUNT_BELOW_MIN or AMOUNT_ABOVE_MAX with the bound in detail.
3. Turnover limits. Below.

Turnover limits

The platform caps turnover in USD per cash desk, per merchant, per provider and globally, each per hour, day or calendar month. Windows are calendar-aligned, not rolling: a daily cap resets at midnight UTC.

Only completed orders count. Creation checks the cap against what has already settled plus the new order; when that exceeds the cap the order answers 400 TRAFFIC_LIMIT_REACHED and detail names the scope, the window and the numbers. Some limits are configured to notify the platform rather than stop traffic; those never reach you.

You cannot see your limits through the API; GET /gw/v1/methods reflects a stopped cash desk but not a cap that is merely close. If you plan a peak, ask support in advance.

The appeal guard

Open appeals count against the provider that served the order. At ten open appeals the provider is paused for everyone; it resumes when they are resolved down to seven. A paused provider disappears from GET /gw/v1/methods, and when no other provider offers the rail the order answers 503 NO_AVAILABLE_METHOD.

The circuit breaker

The cascade scores every provider per method and rail on recent outcomes. A provider whose recent success rate falls below the threshold is skipped for a cooling period, then tried again with a small share of traffic. Failures caused by our own side, such as a bad credential, are not scored. You never see this directly: routing just avoids a failing provider. When every provider for a rail is failing, orders answer 503 NO_AVAILABLE_METHOD; retry with a back-off.

Cascade timeouts

Finding a provider takes at most 160 seconds; each provider is given 10 seconds to answer. Under normal conditions creation answers within a second or two. If your HTTP client has a short timeout on POST /gw/v1/orders, keep it above the cascade's own limit or handle a client-side timeout by fetching the order by orderRef before retrying, so a retry does not create a second order after the idempotency hour.

Stops

Fault	Who set it	How it clears
SHOP_INACTIVE	You, by disabling the cash desk	Enable it in the cabinet.
SHOP_STOPPED	The platform, with a reason	Support; the reason is on the cash desk card.
MERCHANT_INACTIVE	The platform blocked the account	Support.
MERCHANT_NOT_APPROVED	The account is not approved and the sandbox is off	Approval.