Payments
In one line: A PWA collects payment through the same web rails as any site — the Payment Request API, Google Pay, Apple Pay, and provider SDKs like Stripe — so the real questions are which methods are available on a given engine and whether the SDK behaves in installed standalone mode.
The payment stack
Section titled “The payment stack”| Layer | Examples | Notes |
|---|---|---|
| Browser API | Payment Request API | Standard request/response UI; coverage varies by engine. |
| Wallet | Google Pay, Apple Pay | Apple Pay on the web needs Safari + domain verification; Google Pay needs the supported context. |
| Provider SDK | Stripe, Adyen, Braintree, regional rails | JavaScript SDKs that run in any PWA; some offer Payment Request integration. |
Payment Request API support
Section titled “Payment Request API support”The Payment Request API gives a consistent, browser-native checkout sheet and is the most portable path. Its support — and the methods it can surface (basic-card, Google Pay, Apple Pay) — differs across Chromium, Safari, and Firefox. The structured matrix is here:
| Browser / Platform | Support | Since | Confidence | Source | Notes |
|---|---|---|---|---|---|
| Chrome (Android) | ✅ yes | 61 | high | ref | — |
| Chrome (Desktop) | ✅ yes | 61 | high | ref | — |
| Edge (Desktop) | ✅ yes | 79 | high | ref | — |
| Safari (iOS) | ✅ yes | 11.1 | high | ref | Backed by Apple Pay as the payment method. |
| Safari (macOS) | ✅ yes | 11.1 | high | ref | Backed by Apple Pay. |
| Firefox (Desktop) | ❌ no | — | medium | ref | Implementation shipped then disabled; not available by default. |
| Samsung Internet | ✅ yes | 7.0 | medium | ref | — |
Ecosystem & commercial policy
| Entity | Type | Context | Status | Sponsored | Notes |
|---|---|---|---|---|---|
| Apple Pay | payment_sdk | Safari / iOS | ✅ supported | No | Works in Safari via Payment Request; merchant-domain verification required. |
| Stripe | payment_sdk | Cross-browser | ✅ supported | No | Stripe wraps Payment Request as the Payment Request Button / Payment Element. |
| Google Play billing | store_policy | Google Play TWA | ❌ unsupported | No | TWAs distributing digital goods must use Play Billing, not Payment Request, per Play policy. |
Wallets and installed standalone mode
Section titled “Wallets and installed standalone mode”- Apple Pay on the web works in Safari and in iOS home-screen PWAs, but requires merchant domain verification and a secure context.
- Google Pay works in supported Chromium contexts; verify it surfaces correctly when the PWA is launched standalone, not only in a tab.
- Provider SDKs (Stripe et al.) are plain JavaScript and load in any PWA, but always test the redirect/popup flows in standalone display mode, where window handling differs.
Where the policy verdicts live
Section titled “Where the policy verdicts live”Beyond raw API support, the commercial position — which payment SDKs and methods are officially supported for PWA/standalone surfaces, with a source and verification date — is maintained as rows in the policy dimension. This page explains the stack and links the capability matrix; it does not restate the policy verdicts, which have a single source of truth.
Practical checklist
Section titled “Practical checklist”- Prefer the Payment Request API for portability; fall back to a provider SDK where unsupported.
- Verify Apple Pay domain verification for iOS home-screen installs.
- Test wallet and redirect flows in installed standalone mode, not just a browser tab.
- Check the policy data for the current, sourced support verdict.
← Back to the Ecosystem overview.