PortOne · Rate Limits

Portone Rate Limits

PortOne does not publish explicit numeric rate limits for the V2 (api.portone.io) or legacy V1 (api.iamport.kr) REST APIs in its developer documentation. As a payment gateway, effective throughput is bounded by the merchant's account standing and, critically, by the rate and fraud controls of the downstream PSP handling each transaction. Standard HTTP 429 handling with exponential backoff is the recommended client posture. Specific per-endpoint values are not reconciled in this artifact.

Portone Rate Limits is the machine-readable rate-limit profile for PortOne 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 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Payments, Payment Orchestration, Korea, Rate Limiting, and Quotas.

3 Limits Throttle: 429
PaymentsPayment OrchestrationKoreaRate LimitingQuotasThrottling

Limits

V2 REST API (api.portone.io) account
requests
see provider documentation
No published numeric limit; bounded by account standing and PSP throughput.
V1 REST API (api.iamport.kr) account
requests
see provider documentation
Legacy Iamport API; token-authenticated; no published numeric limit.
Payment (acting) endpoints account
transactions
bounded by downstream PSP
Card / virtual-account / easy-pay throughput and fraud controls are enforced by the connected PSP, not PortOne.

Policies

Backoff Strategy
Clients should implement exponential backoff with jitter on HTTP 429 and idempotently retry payment lookups (not acting operations without idempotency keys).
Webhook Reconciliation
Rather than polling aggressively, rely on registered webhooks for payment status changes and use the resend-webhook operation to recover missed events.

Sources