Juspay · Rate Limits

Juspay Rate Limits

Juspay does not publish fixed numeric rate limits for its Express Checkout / PG REST APIs in the public developer documentation. As an enterprise payments platform, throughput is governed per-merchant by the commercial agreement and by the underlying acquirer/gateway capacity rather than by a documented per-minute request cap. Integrations should implement idempotency (the refund `unique_request_id` is an example of a client-supplied idempotency key), retries with exponential backoff, and asynchronous webhook-driven reconciliation rather than tight polling of order status.

Juspay Rate Limits is the machine-readable rate-limit profile for Juspay on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests and transactions.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Payments, Payment Orchestration, Checkout, India, and Rate Limiting.

3 Limits Throttle: 429
PaymentsPayment OrchestrationCheckoutIndiaRate LimitingQuotas

Limits

Express Checkout API Requests merchant
requests
not published
No fixed numeric request-rate limit is documented for the REST APIs.
Order Status Polling merchant
requests
not published
Prefer webhooks over aggressive polling of GET /orders/{order_id}.
Production Throughput merchant
transactions
per agreement
Governed by the commercial contract and downstream gateway capacity.

Policies

Idempotency
Refunds require a unique_request_id that cannot be reused across different refund requests, preventing duplicate refunds on retry.
Webhook-Driven Reconciliation
Juspay pushes server-to-server webhook notifications after each payment/refund event; rely on these plus order status rather than tight polling.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.

Sources