Skip to main content

Apple Pay

paymentType: "APPLE_PAY_US".

This page covers what's specific to the Apple Pay express button of <swirepay-checkout>. For the shared integration flow, props reference, error/success payloads, theming, and testing, see SDK setup & flow; for minting the checkout session, see Checkout session.

Behavior​

  • Not supported for inventory-order checkouts — if included in an order-scope session's paymentType, it's silently dropped and the button won't render.
  • The button only renders if window.ApplePaySession exists and ApplePaySession.canMakePayments() resolves true — in practice this means Safari (or another WebKit browser exposing the Apple Pay JS API) on a device with a card set up in Apple Wallet, over HTTPS.
  • Under the hood, Apple Pay here is powered by the same underlying PayPal-based integration that backs Google Pay — Test mode runs against that integration's sandbox (see SDK setup & flow → Live vs. Test mode).
  • Unlike Google Pay's device-level check or PayPal's eligibility check (both silent), Apple Pay's own ineligibility check is not silent: if canMakePayments() resolves false, errorCallback fires. A merchant-level Apple Pay ineligibility check also fires errorCallback. In both cases the rest of the widget stays usable — only the Apple Pay button itself never appears.
  • The shopName prop (shop-name attribute) is passed through as the display name shown on Apple's payment sheet during merchant validation — Apple Pay is the only payment method where this prop has any visible effect. It is very strongly recommended, bordering on required: without it, the payment sheet falls back to a generic "Payment" label, and depending on your Apple Pay merchant configuration the sheet may fail to display correctly at all.
  • Testable only in Safari (desktop or iOS) — it will never appear in Chrome/Firefox regardless of configuration.
  • Always include at least one other paymentType (typically "CARD") so shoppers on non-Safari browsers still have a way to pay.

Pitfalls​

  • Testing in a non-Safari browser — the button will never render there; this is expected, and errorCallback firing with a canMakePayments()-ineligibility message is also expected, not a sign of misconfiguration.
  • Forgetting shop-name — the payment sheet falls back to a generic "Payment" label at best, and may fail to display correctly at all — treat this prop as effectively required.
  • Only requesting APPLE_PAY_US — shoppers on unsupported browsers will have no way to pay.
  • Assuming Apple Pay ineligibility is silent like Google Pay's or PayPal's — it isn't; Apple Pay's own canMakePayments() failure does call errorCallback.

See SDK setup & flow → Common pitfalls for pitfalls that apply across all payment methods.

On this page