#beng
mental agate
👋 happy to help
using Stripe Elements within a web component
I'm not sure whether this is a good idea or not
hasty canopy
Oh really? What's your thinking there?
All the web component really does is render out <div id="stripe-payment-element"></div> and handle the JS for Elements to initialize
But either way I don't think that's the root of the issue we're seeing - all the other configured payment methods (card/Google Pay/PayPal) work successfully, and Apple Pay did work until recently, so something must have changed
calm vortexBOT
gusty tapir
👋
Stepping in
So @hasty canopy this is only happening on an iOS device?
On Safari the integration works fine
Have you tried multiple devices and multiple different cards?
hasty canopy
Yep that's right, only iOS, Safari on Mac doesn't seem to be an issue
Tried across at least 3 different physical iPhones
User doesn't even get to the Apple Pay popup which lets them select a card, so nothing further tried on the 'multiple cards' front
I did briefly start to wonder if I'd used some JS that was supported on desktop Safari but not iOS Safari, but nothing's jumping out at me
hasty canopy
Yeah that was a big help! But it only got us so far - we can see the error being thrown from the confirmPayment call, and that no network requests are being made, but the error message doesn't have any more clues beyond it being an invalid_request_error
hasty canopy
Sure, I can send you a link to a QA env?
hasty canopy
Was just thinking the same thing - it's for a client of ours so will DM
gusty tapir
Sounds good, think you need to friend request first
Okay give me a min to see if I can repro
Let's keep convo here in case I need to step away and a colleague of mine needs to take over at some point
hasty canopy
No probs, thank you for taking a look!
gusty tapir
Hmm okay interesting.
Can you share a PaymentIntent ID on your account where this is happening?
Can you also share your full code for your confirmPayment handler?
hasty canopy
Sure thing, happy if I send them over DM again?
gusty tapir
If you feel it necessary. The PaymentIntent ID is not sensitive. If you really don't want to share the code publicly then that's fine
Hmm also I was able to repro on safari on web as well
Seems like you are triggering a redirect or an overlay on confirm with your "processing" page?
hasty canopy
No worries. PI ID from this morning: pi_3MokkIDPr7GGBFhm2HDBsBYN
gusty tapir
Also to clarify, the error message you are seeing is coming from your own code
That isn't one of our error messages
hasty canopy
I'd love to be able to share the code publicly but given the agreement we have with our client I'll DM to be safe
gusty tapir
That's fine
hasty canopy
You're right about the overlay and redirect, yes
Surprising to hear on Safari on web! We should try that again internally
gusty tapir
Can you try removing that overlay
I wonder if it is messing with the Apple Pay modal presentation
Like I have run into issues in the past trying to combine alerts with Apple/Google Pay
Wonder if it is a similar thing here
hasty canopy
Surprised about the error message too. In this case we're displaying error?.message returned from confirmPayment directly to the user, so I thought that was one of yours?
I can see if the overlay is messing with things, but I wouldn't expect the Elements code to even know it was there, right? So if it was blocking the Apple Pay modal, we just wouldn't see it?
Plus our overlay is just a big fullscreen div, whereas the Apple Pay modal is OS-level (i.e. not even within the webpage), right?
gusty tapir
Ah sorry I'm wrong on the error message
I see it in our code right now (we have a variable for wallet in our code since it can apply to Apple Pay or Google Pay)
I agree it seems like the overlay shouldn't have any effect. I'd still test removing it. Let me also do a bit more research on this specific error and see if I can find anything
hasty canopy
Thanks, yeah that makes sense. We can give that a try and also attempt another repro on Mac Safari
Once you've taken a look, if there's any reason you're able to point me towards that could potentially be causing that error to be thrown, that would be super helpful - I'm pretty sure I'm just being blind to it in the code, but it seems even more likely now that I'm dong something Safari isn't happy with
gusty tapir
I mean your confirmPayment function looks fine to me. There is a lot of other stuff going on around it which I don't have full context on. I think similarly removing all of the stuff around it and just test having confirmPayment fire and catch the error would be the next step to see if something isn't playing nicely (similar to the idea of removing the overlay).
I'm seeing on our end that we throw that error when the modal show fails. But not a lot of details for why that would happen in our code that I'm looking at right now.
hasty canopy
Yeah there's definitely a lot of more external stuff happening around the edges, so a minimal repro might be helpful here.
gusty tapir
Ah wait
I know what the issue is
Okay so in web console I can see:
IntegrationError: show() must be called from a user gesture handler (such as a click handler, after the user clicks a button).
So this is actually an Apple security limitation
The short of it is that Apple gives you a 1 second window from when the user action triggers to when the modal should open
Right now you are doing other stuff in your confirmPayment handler prior to the confirmPayment function running
If that stuff eclipses the 1 second window, then Apple throws an error and won't let the modal show.
hasty canopy
Oh yeah I really am, and it's very likely to take more than 1 second
I had spotted that console message before but not at all made the connection
That makes perfect sense
Thank you so much for digging in!
gusty tapir
Sure!
Yeah it is based on the user-activation-api that Apple uses: https://webkit.org/blog/13862/the-user-activation-api/
So basically you want to move any logic you need to run before confirmPayment out of that handler and run it before that submit
That should fix things up!
