Apple Pay in third‑party browsers gives merchants the ability to offer Apple Pay as a payment method across non‑Safari browsers on Mac and on devices outside of the Apple ecosystem.

Yes, Apple Pay in third‑party browsers is available where Apple Pay is live with the exception of mainland China.

Support is available for all computer or tablet devices capable of running a supported browser. Refer to Devices compatible with Apple Pay for a list of devices compatible with Apple Pay.

Enabling Apple Pay in third‑party browsers is easy:

• Merchants can simply add the Apple Pay JS SDK to their existing Apple Pay integration to extend support to more browsers and devices.
• Merchants can also check with their e‑commerce platform or payment service provider, as they may offer this capability through their implementation.

Once a consumer has scanned the dynamic code, the website overlay window will display a message prompting the consumer to complete the payment on their iPhone or iPad.

The scannable code is a unique circular format, similar to App Clip Codes. The data embedded is specific to the Apple Pay session and requires an iPhone running iOS 18 or later or iPad running iPadOS 18 or later to successfully scan the code.

These codes can be scanned on any eligible iPhone running iOS 18 or later or iPad running iPadOS 18 or later.

For security purposes, the codes in the overlay will change every few seconds. An active code is only valid for a single successful scan. Once successfully scanned, the code is invalidated and no further codes are displayed on the overlay for that payment session.

The experience is identical to that of a consumer initiating a payment directly on their iPhone. A consumer will still be able to successfully scan the code and will be presented with a payment sheet prompting them to select a payment method. They can then follow this prompt to complete an in‑line setup flow and proceed with payment.

The experience is identical to that of a consumer initiating a payment directly on their iPhone. A consumer will still be able to successfully scan the code and will be presented with a payment sheet prompting them to try a different payment method. They can then follow this prompt to complete an in‑line setup flow and proceed with payment.

Closing the browser, tab, or Apple Pay overlay before the payment is completed will cause the payment session to be cancelled and the payment sheet on the linked iPhone will also close.

Integrations via Apple Pay JS API will work on the vast majority of browsers that support WebSockets. For integrations via Payment Request API the browser must also have support for the W3C Payment Request API. Merchants who want to ensure maximum browser coverage may wish to consider using the Apple Pay JS API.

In iOS 16 and iPadOS 16 Apple Pay was enabled in WKWebView, enabling non‑Safari browsers on iOS and iPadOS to support Apple Pay directly on device.

Starting with iOS 18 and iPadOS 18, support for Apple Pay in third‑party browsers was extended to include Mac and other computers using an iPhone or iPad to complete the purchase. Refer to Enable Apple Pay in third‑party browsers for more details.

Apple Pay transactions initiated in third‑party browsers and Safari offer the same capabilities (including pay in full, pay with installments, and rewards). The only difference is that once the consumer scans the Apple Pay code in a third‑party browser, the payment session is passed to the consumer’s iPhone or iPad to complete the purchase.

When a consumer initiates Apple Pay via Safari on their Mac, the payment sheet is typically displayed directly on the computer, where they then authenticate on device using Touch ID or passcode. Alternatively, they may complete payment using handoff from their Mac to a nearby iPhone or Apple Watch.

For non‑Safari browsers on Mac or on non‑Apple devices, a scannable code will be displayed to the consumer when they click the Apple Pay button. This code needs to be scanned by an eligible iPhone or iPad to complete payment. Once scanned, the payment sheet is presented on the scanning device (iPhone, iPad) where the consumer can review their payment. Once authenticated on their iPhone or iPad, the payment can be completed on the initiating device.

No. The modal window containing the Apple Pay code is an HTML overlay rendered within the same browser window of the initiating website. Depending on the merchant’s implementation, a new window may also be used to present the Apple Pay code. In each case, the Apple Pay code would not be affected by pop‑up blockers or ad blockers, as the window gets generated from a consumer action and not programmatically generated by JavaScript code without consumer intent.

Yes, visit Apple Pay on the Web Demo using a third‑party browser on a Mac or a PC. Click the Apple Pay button, then use an iPhone running iOS 18 or later or iPad running iPadOS 18 or later to scan the Apple Pay code.

Yes, canMakePaymentsWithActiveCard() works on Safari, even after adding third‑party browser support. Switching to the applePayCapabilities() API is encouraged, however, as canMakePaymentsWithActiveCard() has been deprecated.

Merchants process Apple Pay payments initiated from a third‑party browser in the same way as those initiated from Safari. Although payload generation and payment authentication occurs on the consumer’s iPhone or iPad, the payment experience gets routed back to the merchant’s website automatically like a standard Apple Pay transaction today.

Yes. All payment sheet interaction events get handled the same way for Apple Pay transactions in both Safari and third‑party browsers. For existing integrations, any logic for responding to billing contact changes, shipping method or contact changes, or payment card changes will still be triggered without additional effort from the merchant.

Yes. Refer to testing best practices  above for guidance on how to test third‑party browser implementation.