Tap Payments · Rate Limits

Tap Payments Rate Limits

Tap Payments does not publish fixed numeric rate limits for its REST API in the public developer reference. As a card-present/card-not-present payment gateway, throughput is governed operationally - by acquirer and scheme limits, fraud and velocity controls, and per-merchant risk configuration - rather than by a published per-minute request cap. Clients should treat the API as rate-limited in principle, handle HTTP 429 responses with exponential backoff, and rely on idempotency/reference fields to avoid duplicate charges on retry.

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

It captures 2 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, Fintech, Payment Gateway, MENA, and Rate Limiting.

2 Limits Throttle: 429
PaymentsFintechPayment GatewayMENARate LimitingQuotas

Limits

REST API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Tap REST API.
Payment Velocity / Fraud Controls merchant
transactions
risk-configured
Transaction throughput is subject to scheme, acquirer, and per-merchant fraud/velocity rules rather than a documented API cap.

Policies

Backoff Strategy
On HTTP 429, back off exponentially with jitter and retry idempotently.
Idempotent Retries
Use the reference / metadata fields on charges to correlate and de-duplicate retried payment requests.

Sources