stripe-js: [BUG]: in-iFrame Apple Pay support in Safari Preview >=167

@brendanm-stripe

Why is the top-level parent domain passed to the apple-pay-gateway.apple.com/paymentservices/startSession instead of the iframe domain? Could this possibly be changed?

Rationale for this would be that the parent is explicitly enabling the child frame to allow payment via allow="payment" which is the origin of the payment interactions.

Requiring the parent to also be registered negatively impacts the portability of the child frame which is registered.

Would love to see the child domain passed to apple vs the top-level parent

Hey @brendanm-stripe I think this isn’t quite working yet. After failing to get our own SDK work I tried embedding your demo https://stripe-payments-demo.appspot.com/ on a third party website with the allow="payment" flag (I used Notion, see image).

The ApplePay button appears now but, upon clicking it, I immediately receive an error about the payment unable to be completed. The ApplePay demo flow works fine when I use https://stripe-payments-demo.appspot.com/ directly outside an iframe.

This is the exact same behaivor we are seeing locally.

Mind looking into this?

Just a brief update: we’ve got a fix for this rolling out asap, so you should start to see behaviour change.

Thank to all those who reported this!

Hey @ryan-lambert-IEX – currently Apple Pay is only supported in iframes from the same domain, it’s not available when framed from another domain.

Our team is aware of the beta feature and knows that developers are ready to use it! Once Safari 17 is out of beta and this feature is GA, we’ll re-evaluate the support of cross-origin iframes for Apple Pay.

@brendanm-stripe This is now released per https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes#Apple-Pay

Any updates as to when Stripe will add support?

@brendanm-stripe is there any update to the question above? regarding the limitation being from stripe, not apple, and stripe changing the origin of the request to the parent rather than the child

i understand the security discussion above, but as @ryan-lambert-IEX has said:

In all cases, it seems better to specify CSP headers in the child which controls where the child can be displayed

many of us, i believe, are building applications specifically meant to be embedded in any domain, but on top of that have implemented origin limitations ourselves - meaning the security concerns would not apply

with that said, i think it would be great to have an option at the very least to enable this “less secure” flow, where the child’s origin is used, and the child is the only one required to serve the .well-known verification file

@alekseyg this limitation is from Stripe since they are changing the origin of the request to apple-pay-gateway.apple.com/paymentservices/startSession; we have a version of our SDK which interacts with Apple directly and it works fine inside an iframe. But it’s nice to use Stripe since we get all the nice Stripe features, so would love it if you changed this @brendanm-stripe

@ryan-lambert-IEX thanks for trying that out, that aligns with our understanding of the restrictions.

@alekseyg Yes, that was a fix we put in place after learning of the gap in the early cross-origin support here. With the framed domain registered we would originally allow Apple Pay to show, but it would not work due to the top level registration requirement. As you noticed, this has been corrected to properly not show Apple Pay if the top domain is not registered.

After retesting with our own SDK, I believe I was originally incorrect and Apple does indeed seem to require the top-level domain be used when forming a valid session object.

I am able to get a session object, but it fails completeMerchantValidation. When running the debugger locally via $ log stream --level debug --predicate 'subsystem == "com.apple.passkit"' , I see

com.apple.PassKit.PaymentAuthorizationUIExtension: (PassKitCore) [com.apple.passkit:Payment] 
Application failed to provide a valid merchant session. We can't proceed to authorize the transaction.

The session validation works when I pass in the top-level domain. This is all while using the allow=“payment” attribute on my iframe which is registered under our merchant domain umbrella.

I would love to (again) be incorrect, so anyone with any working counter-examples would be appreciated.

Works for me as well. Thank you!

I just tested, can confirm it works as expected.

This is not fixed. Can we re-open it?

Hey folks, some good news to share here: you should now be able to do this by adding allow="payment" on your iframe. Still ironing out the corresponding docs changes, but the support should be available now.

Edit: docs changes have landed here: https://stripe.com/docs/apple-pay?platform=web#web-integration-considerations

Using an iframe with Elements: When using an iframe, its origin must match the top-level origin (except for Safari 17 when specifying allow=“payment” attribute).

@brendanm-stripe thank you for speedy response + clarity - would love to see support added when available