rarepepi

[brave path]

Hi 👋

Okay yikes Apple Pay doesn't play nice with layered iFrames

[faint crag]

Yeah its been hard to even test it haha

im guessing to properly do it I would have to programmatically have people in their dashboard verify their domains if they want to enable apple pay

const stripe = require("stripe")("sk_live_••••••••••••••••••••••••");
stripe.applePayDomains.create({
  domain_name: 'example.com'
});

but was recently told about how helpful the discord is so wanted to check here, really appreciate it btw

[brave path]

Okay so wait, is the issue that you are trying to use your own domain to utilize Apple Pay but that isn't the top level domain the iframe is hosted within?

[faint crag]

yes exactly

Im guessing it is too i guess, because its not working right now haha even though i followed these docs https://stripe.com/docs/stripe-js/elements/payment-request-button?client=react

[brave path]

Have you got it working in your own integration?

[faint crag]

Yeah our checkout solution has been live for over 6 months it uses Stripe Connect to do everything, just been wanting to add more payment options lately namely Apple Pay right now

[brave path]

No I mean do you have a working Apple Pay integration that is not hosted within Connect iframes?

[faint crag]

No but i can quickly try setting it up

[bold carbon]

Hello! I'm taking over and catching up...

Apple Pay won't work unless the origin of all iframes matches exactly.

For example, you can have a page on https://example.com which contains an iframe that loads a different page from https://example.com with Apple Pay in there and that's fine.

But you can't have a page on https://example.com/ load an iframe containing Apple Pay from any other origin, it just won't work.

See here for more details: https://stripe.com/docs/stripe-js/elements/payment-request-button?client=html#safari

[faint crag]

Ok gotcha so I would have to use the stripe.applePayDomains.create(.. to programmatically have users in our dashboard elect to use apple pay and go through the dns confirmation the way I would for https://example.com

[bold carbon]

No.

As I understand it you're trying to build something that people can add to their sites to accept Apple Pay payments, and the form that will take is an iframe on their site which contains content loaded from your server/domain. Is that correct?

[faint crag]

Yeah we have already built and been live for 6 months with a checkout solution that leverages stripe connect under the hood, I wanted to add Apple Pay support

https://mysite.com ->(iframe) https://clientsite.com

if I have already setup my domain with apple pay in the stripe dashboard, couldnt I just use the stripe api to programmatically allow users to also add their domains for support(being that they also do the host verification file steps)

[bold carbon]

Yeah, to be very clear, this will not work.

The origins are different, so Apple Pay will not function.

That's a security measure imposed by Apple.

This is not an issue related to domain validation.

[faint crag]

oooooo wow i see, even if both verified they just check if different and block if so

[bold carbon]

Yes.

[faint crag]

damn well thanks for your help i really appreciate it, already spent a bunch of hours trying to make it work good to know that apple was just blocking it

[bold carbon]

One question: how much control do you have on the top-level page? Can you run arbitrary JS there?

Or can you only inject your iframe?

[faint crag]

We can ask our clients(people integrating our checkout) to do anything I guess

[faint crag]

this is the current solution we offer since its easiest for people to integrate us that way

[bold carbon]

There is a workaround, but it's kinda complicated. It requires you to run the actual Apple Pay stuff in the top-level page rather than in the frame, and exchange messages across the iframe boundary. Have a look here: https://4242.io/apple-pay-frame/

[faint crag]

does the mini demo work for you? lol i guess apple found this ahahaha

also tysm really appreciate you looking into this with me, im super down to do something hacky to get this up

[bold carbon]

Yeah, it works for me. Did you open it in Safari?

[faint crag]

Oh lmfao i forgot to open in safari ok yeah it works

this is amazing wow! it actually works

[bold carbon]

I should clean up that error message...

[faint crag]

haha you made this?

[bold carbon]

Yep.

[faint crag]

this is sick!!

wow love that

[bold carbon]

Wait, what browser did you use?

I'm getting something different in Chrome.

Yeah, in Chrome and Firefox I get this:

[faint crag]

oh interesting i used chrome Version 115.0.5790.170

Version 115.0.5790.170 (Official Build) (arm64)

[bold carbon]

That's the version I'm using. 😅

[faint crag]

ahh that error message is in the actual iframe, i get the other message above just was scrolled past it before

Stripe Connect users have their own pks? no right?

cause cant expose ours so would have to do some server side aspect

never mind lmao, crypto guys so i see pk and think private key, pk exposure meaning public in stripes case is fine haha

hmmm ok so our checkout is actually primarily used through a React Component i made on npm, could just inject the js through there since most our customers choose the npm package to implement and that way they dont have to worry about any extra js on their side

[bold carbon]

I can't say for sure (not a React dev), but probably.

And yeah, pk_ at Stripe is for publishable key. 🙂

[faint crag]

so if our client is on https://clientsite.com and our iframe is hosted on https://iframe.com which ones needs to be verified? just ours at https://iframe.com or would the client also have to verify with this solution and we should provide those steps in our dashboard for them to enable it

[bold carbon]

It would need to be the top-level page.

clientsite.com

If you're using the technique I shared above.