Yoco · Rate Limits

Yoco Rate Limits

Yoco does not publish fixed numeric rate limits for its online payments APIs. The Checkout API (payments.yoco.com/api) and the versioned Yoco API (api.yoco.com/v1) are transactional REST surfaces; practical throughput is governed by payment processing and standard abuse protection rather than a documented per-minute request cap. Idempotency-Key headers are supported on checkout creation and refunds to make retries safe. Clients should implement exponential backoff with jitter and honor Retry-After on any 429 response.

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

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

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

Tagged areas include Payments, Fintech, Payment Gateway, Card Payments, and Rate Limiting.

3 Limits Throttle: 429
PaymentsFintechPayment GatewayCard PaymentsRate LimitingQuotas

Limits

Checkout API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Checkout API.
Yoco API (v1) Requests account
requests
not published
No fixed numeric request-rate limit is documented for the versioned read API.
List Payments Page Size request
records
50 default (cursor paginated)
GET /v1/payments returns up to a limit per page and a cursor for the next page.

Policies

Idempotency
Checkout creation and refunds accept an Idempotency-Key header so retries do not create duplicates.
Backoff Strategy
Clients should use exponential backoff with jitter and honor Retry-After on 429 responses.
Webhook Retries
Yoco delivers signed webhook events; consumers should respond quickly and rely on retries plus idempotent handling for reliable processing.

Sources