specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Apple Pay
providerId: apple-pay
created: '2026-05-04'
# Provenance stamped 2026-08-11: this artifact was written by the API Evangelist
# bulk sweep dated 2026-05-04, not harvested from the provider. See roadmap#35.
method: generated
modified: '2026-05-05'
reconciled: false
tags:
  - Rate Limiting
  - Payments
  - Apple
description: 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.
notes: No public rate-limit documentation exists; downstream processor limits dominate.
sources:
  - https://developer.apple.com/documentation/apple_pay_on_the_web
responseCodes:
  throttled: 429
  serviceUnavailable: 503
limits:
  - name: Merchant validation endpoint
    scope: merchant-id
    metric: varies
    limit: not publicly documented
    notes: Calls to apple-pay-gateway.apple.com for merchant session creation are subject to Apple's anti-abuse
      fairness controls.
  - name: ApplePaySession (client)
    scope: device
    metric: varies
    limit: bounded by user interaction
    notes: ApplePaySession is user-initiated; server-side throughput is bounded by the merchant's checkout
      volume and payment-processor capacity.
  - name: PassKit
    scope: device
    metric: varies
    limit: bounded by device
policies:
  - name: Backoff Strategy
    description: 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.
  - name: Processor Coordination
    description: 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.
  - name: Sandbox Testing
    description: Use Apple Pay sandbox tester accounts and processor sandbox endpoints for load and edge-case
      testing rather than touching production endpoints.
  - name: Anti-abuse Detection
    description: Apple may dynamically throttle suspicious merchant validation patterns; ensure server-to-server
      merchant identity calls are signed correctly and not retried in tight loops.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com