PayPal release of SDK v6 (e.g. Shopify stores) unable to pay

[janbrasna]

PayPal is broken again. This time not just iPadOS, but iOS too, i.e. all devices and consumers.

SDK v6 was released last week of September, Shopify stores already use it in checkout flows.
https://developer.paypal.com/community/blog/paypal-js-sdk-v6/ (Sept 27, 2025)

Previous workarounds are no longer effective.

Steps to reproduce

https://dowsedesign.co.uk/collections/new/products/hot-lighters or
https://www.mollyjogger.com/products/scrimshaw-heirloom-knife-kit
(works from cart, fails from checkout)

Expected behavior

In SDK v5 mobile user agents (differing over time, FxiOS used to be special cased on their side by user agent sniffing, but that was later applied to CriOS, EdgiOS, Safari and more too…) instead of opening modals, that turn to new tabs on mobile, used embedded flow within the same page.

While attempts to open the PayPal modals failed, if provided with mobile UA the flow would succeed in the same tab.

Actual behavior

In SDK v6 there only seems to be some logic around support of dialog elements, but for some reasons FxiOS no longer gets the same-page flow — so the previous bandaid to spoof all as mobile has no longer any effect.

The real culprit was never fixed, this means just the workaround is no longer helping and the underlying issue exhibits fully. Previous investigation at #17911 (comment)

Device & build information

• Device: iPhone (all devices, incl. iPads; but before this was only issue in "request desktop" mode, now it affects completely all users)
• Build version: any
• First seen version: this is from change on Shopify side and PayPal new SDK release

(BTW opening into new tabs like in other browsers apparently worked fine at some point: webcompat/web-bugs#72818 …)

Notes

SDK v6 uses web components with Lit (the "checkout" iframe with buttons that fail is "paypal express wallets" — loading "wallets sandbox" which is a v6 endpoint loading https://www.paypal.com/web-sdk/v6/core …)

SDK v5 is loaded via https://www.paypal.com/smart/buttons?fundingSource=paypal[…]sdkVersion=5.0.515[…] supportedNativeBrowser=false&supportsPopups=true&userAgent= Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_15_7)%20AppleWebKit%2F605.1.15%20(KHTML%2C%20like%20Gecko)%20Version%2F18.6%20Safari%2F605.1.15 from e.g. https://www.paypal.com/sdk/js?client-id=CLIENT_ID

Interestingly I see the same navigator regexp testing in the new SDK js code too, it just might not get used for this particular behavior variability in the end.

Attachments:

This is a store with no v5 "smart buttons" / express checkout:

ScreenRecording_10-18-2025.21-02-30_1_avc.mp4

Here this store has both flows, working on the cart page before checkout, but failing on the "express wallets" inside the checkout:

ScreenRecording_10-18-2025.21-06-29_1_avc.mp4

FYI:

The same flow in Brave opens new tabs in both cases — successfully:

ScreenRecording_10-18-2025.23-34-35_1_avc.mp4

The same flow in a random WKWebKit implementation opens the embedded dialog in-page:

ScreenRecording_10-18-2025.23-30-19_1_avc.mp4

(Given the investigations into the about:blank failing were not too successful, and I haven't found a MRE that would exhibit this i.e. the actual culprit is currently unknown, I'm going to look into spoofing as a dumb WKWebKit/UIWebKit in case that would help stay in-page.)

🙈

┆Issue is synchronized with this Jira Task

[janbrasna]

Seeing in the last recording there is a functionality to finish the flow within the same page, presumably when there is no capability to open windows/popups:

… I'll try to see if I can make the SDK fall into this "Taking you to PayPal" in-page flow.

(The same can be observed in Focus iOS.)

[janbrasna]

Confirming the bandaid resolves at least Shopify merchants for now, verified on iPhone running iOS 18.7.1 using TestFlight v145.0beta (63786)

Leaving this open for the underlying about:blank issue #17911 (comment) — as this will keep impacting all merchants moving to SDKv6 and hosting the button components in their context, the patch linked above unfortunately only targets shopify.com sources and is not a solution for anyone else:/

[dwilliams27]

Hey @janbrasna!

I'm on the v6 JS SDK team at Paypal and came across this issue thread. I've created a minimal example that doesn't use our SDK that I think shows the problem where the new about:blank tab is not functional. Recreation code here, and I've pushed example up to https://firefox-demo.fly.dev

It seems this has something to do with opening the new tab from a cross-origin iframe. This code:

const windowRef = window.open('about:blank', 'testing', 'width=600,height=400,top=100,left=100');
// Wait 1 second
windowRef.location.replace('https://www.paypal.com');

Works fine when running inside of an iframe that has the same origin as the parent page, but does NOT work if running from an iframe that is cross-origin (new tab opens, but never redirects).

I've tested this recreation with other major mobile browsers (IOS Safari, IOS Chrome, Android Chrome, Android Firefox, Android Edge) and I see the redirect happening as expected for all of those. Seems this is just isolated to IOS Firefox as best we can tell.

[janbrasna]

Oh wow hey there @dwilliams27 — thanks, that's very helpful! Appreciate you taking the time to dive into the specifics what might have been the culprit and minimizing the reproduction to the core issue, that's truly awesome! (I personally was looking into timing issues regarding having descendant windows focused with delay, but this shows it needs looking into something completely else!) … Thank you so much for this very thorough insight into what might have been that specific in the patterns you use — we wouldn't have figured out that particular difference easily without your tribal knowledge and familiarity with the SDK, this is a great help, hands down.

(I do not immediately see where webview would be making the origin impact differently when specifically coming from frames, but I know there is some investigation around passing webview configuration to the descendant windows going on, so this new information will hopefully fit within the other things investigated and the traits getting set on the new tabs etc.)

@yoanarios This is definitely a new angle, but the linked PoC is very straightforward. (Thanks David for keeping that up for us for a bit! You rock!) 🎸

[janbrasna]

So what actually happens is in the cross-frame cross-origin case, the WebKit content process crashes #32462 (comment) so after reloading the opener and the popup are no longer connected, and the event loop is also no longer called to update the location.

Couldn't find any mention of a similar rdar, will investigate later based on the crash log messages.

EDIT: Some WebKit references [+]

After looking through some WebKit rdars a timeline of similarly sounding issues cropped up:

• https://bugs.webkit.org/show_bug.cgi?id=244314
• https://bugs.webkit.org/show_bug.cgi?id=244315

started occurring after

• https://bugs.webkit.org/show_bug.cgi?id=244068

with some later wrinkles as

• https://bugs.webkit.org/show_bug.cgi?id=248065
• https://bugs.webkit.org/show_bug.cgi?id=253285

Basically the linked patches/PRs have the rationale in the commit log, I'm quoting from the latest:

"In 255420@main I introduced checks in the network process to make sure that firstPartyForCookies is an allowed domain for that process. There are a few places in WebKit where we still have about:blank or a null firstPartyForCookies, which is fine most of the time because ResourceRequest::allowCookies is false so it doesn't matter that there's no firstPartyForCookies. Sometimes, though, we have a piece of code that loads without a firstPartyForCookies and allows cookies. This is an existing bug and should probably be fixed, but it is not catastrophic because the result is that no cookie access is given. However, with 255420@main it became catastrophic because we terminate the web content process, which I'm told is undesirable when a user is trying to do something like download a PDF. This change makes it no longer terminate the web content process."

Sounds related to the experience here.

We probably want to open a rdar/FB with this specific case, as this should just give an empty collection and move on, the content process terminated seems too aggressive for that — and this use of documentEnd scripts in a WKWebView consumer might not be something they consider or had test coverage for.

Looking for workarounds in the meantime.

[janbrasna]

Thanks to everyone looking into the underlying issues, we now have Nightly 69545:

ScreenRecording_03-24-2026.23-08.mp4

Once again thank you for you MRE @dwilliams27 — this has been great help in finding the culprit!