Apple Pay · Rate Limits

Apple Pay Rate Limits

Apple does not publish numeric rate limits for the Apple Pay merchant validation endpoint (apple-pay-gateway.apple.com), the Apple Pay JS / ApplePaySession surface, or PassKit native APIs. Throughput is bounded in practice by the merchant's payment-processor capacity (Stripe, Adyen, Braintree, etc.) and Apple's anti-abuse fairness throttling. Apple may apply dynamic throttling on suspicious patterns and signals 429/503 in those cases.

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

It captures 3 rate-limit definitions, measuring varies.

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

Tagged areas include Rate Limiting, Payments, and Apple.

3 Limits Throttle: 429
Rate LimitingPaymentsApple

Limits

Merchant validation endpoint merchant-id
varies
not publicly documented
Calls to apple-pay-gateway.apple.com for merchant session creation are subject to Apple's anti-abuse fairness controls.
ApplePaySession (client) device
varies
bounded by user interaction
ApplePaySession is user-initiated; server-side throughput is bounded by the merchant's checkout volume and payment-processor capacity.
PassKit device
varies
bounded by device

Policies

Backoff Strategy
Implement exponential backoff with jitter on merchant-validation 429/503 responses; surface a generic 'try again' state to the buyer to avoid duplicate session creation.
Processor Coordination
Apple Pay tokens are exchanged with the merchant's payment processor (Stripe, Adyen, Braintree, etc.) — that processor's rate limits and idempotency keys govern downstream charge attempts.
Sandbox Testing
Use Apple Pay sandbox tester accounts and processor sandbox endpoints for load and edge-case testing rather than touching production endpoints.
Anti-abuse Detection
Apple may dynamically throttle suspicious merchant validation patterns; ensure server-to-server merchant identity calls are signed correctly and not retried in tight loops.

Sources