#Kevin™
1 messages · Page 1 of 1 (latest)
Hi, are you saying that with Apple Pay, when you call elements.fetchUpdates(), the amount does not get updated and you see the above error? Can you share a request id with me where this error is shown? Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Sure. I'm working on reproducing the issue again now.
@pallid dagger req_YnwFX8kmwy8nbS
That is a successful payment intent update request. It's the last logged request before receiving this error when attempting to confirm the payment intent:
Something went wrong. Unable to show Apple Pay. Please choose a different payment method and try again.
My assumption is that something in fetchUpdates on the elements object is updating Apple Pay and there's a race condition that occasionally causes the apple pay payment sheet to be shown before the payment request is updated.
Yeah, it's hard to tell from my end.. do you have a test URL where I can reproduce this?
Like an URL page where I can go through your Checkout flow and try to use Apple Pay
This is the event I'm testing with in our staging environment:
https://mbtest.staging.churchcenter.com/registrations/events/1755781/
This is what I was looking for where we surface this on our documents: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements#fetch-updates
But let me try to reproduce this issue on my end
☝️ It doesn't always require a user to submit the form multiple times to trigger this issue, but changing the payment amount is what will explicitly trigger a payment intent update and then ultimately the elements.fetchUpdates call.
Did you test this in Google Pay and it work's as expected?
I have not tested it in Google Pay yet but we only have user reports of this failing for Apple Pay. The reports started about a week ago and we haven't tracked down any relevant changes in our application.
where is .show() called?
usually this happens when you confirm a PaymentIntent but not from an explicit click in the UI from the user.
Like you're going to have the click submit, you go to your server, you update the amount, come back client-side, do fetchUpdates() and then call confirmPayment() but Apple doesn't like that because the confirmPayment() is triggering Apple Pay not from an explicit click from the customer
Does that make sense?
Often it's because your code/network roundtrip is too slow. Apple has a "hard limit" I think at 1 second after the click before it says it's not in a gesture handler
so possibly this step is a bit slower and exceeds that limit now?
I think the show is part of stripe JS, but the workflow you described is exactly what's happening.
So yeah my guess is that's what's happening to you in that case
Ok. I tried simulating network latency and didn't find it to become any more frequent but maybe that wasn't reliable.
Thanks for looking into this!
what you can do is use setTimeout() to call confirmPayment() after your fetchUpdates()and if you wait 100ms it should work but if you wait 3s it should reproduce that error