Midtrans · Rate Limits

Midtrans Rate Limits

Midtrans does not publish fixed numeric per-minute request-rate limits for its public payment APIs. Practical throughput is governed by the merchant account and by the underlying payment channels (acquiring banks, e-wallet providers) rather than by a documented request cap. A key operational constraint is idempotency by order_id: an order_id can be charged only once, so retries must reuse the same order_id and read status rather than re-charge. Midtrans advises relying on the asynchronous HTTP Payment Notification (webhook) as the source of truth and using Get Status for reconciliation rather than aggressive polling.

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

It captures 4 rate-limit definitions, measuring requests, charge, and payouts.

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

Tagged areas include Payments, Payment Gateway, Indonesia, Rate Limiting, and Quotas.

4 Limits Throttle: 429
PaymentsPayment GatewayIndonesiaRate LimitingQuotas

Limits

Payment API Requests account
requests
not published
No fixed numeric request-rate limit is documented for Snap or the Core API.
Charge Idempotency order
charge
one charge per order_id
An order_id can only be charged once; reuse the same order_id and read status instead of re-charging.
Status Polling account
requests
not published
Prefer the notification webhook over frequent Get Status polling for reconciliation.
Iris Payout Throughput account
payouts
balance-bound
Payout throughput is bounded by available Iris balance and approver workflow rather than a documented request cap.

Policies

Idempotency
Charges are idempotent per order_id; a repeated charge on the same order_id returns the existing transaction rather than creating a duplicate.
Asynchronous Notification
Transaction status changes are pushed via an HTTP Payment Notification to the merchant's configured URL; treat it as the source of truth and verify with a signature_key hash.
Backoff and Reconcile
On transient errors or 429 responses, apply exponential backoff and reconcile final state via Get Status rather than retrying the charge.

Sources