#noah_applepay-handler
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1230263366602326056
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi, can you add more details on where and when specifically you're seeing this error? Is that the exact full error? Have you seen this error before? Did it work before? When you try to pay in test mode, does the payment go through?
Can you also share a screenshot of this error?
Hi, first off, thanks for hopping on to chat!
A few more details
- I'm not necessarily seeing the error myself, my teammate was able to use Apple Pay without a hitch, so we are having trouble reproducing
- We are seeing the errors in datadog, a tool that we use to log client & server errors
- The error is not new - we keep 2 weeks of logs around in datadog and i see the errors going back that far, though recent campaigns around ios have caused the error rates to increase in the past week, as we are getting more users attempting to pay with apple pay
we've experienced 332 instances of this error in the past week - not individual spikes (associated with multiple times per user) but patterned as we'd expect to see payments
Here's some stack trace info from one of the error logs
construct@[native code]
at n (https://js.stripe.com/v3:1:612788)
construct@[native code]
at (unknown) (https://js.stripe.com/v3:1:607270)
at t (https://js.stripe.com/v3:1:147733)
at (unknown) (https://js.stripe.com/v3:1:548663)
at (unknown) (https://js.stripe.com/v3:1:598588)
at (unknown) (https://js.stripe.com/v3:1:102338)
at (unknown) (https://js.stripe.com/v3:1:259432)
at (unknown) (https://js.stripe.com/v3:1:97216)
forEach@[native code]
at (unknown) (https://js.stripe.com/v3:1:97101)
at (unknown) (https://js.stripe.com/v3:1:90737)
at (unknown) (https://js.stripe.com/v3:1:102458)
at (unknown) (https://js.stripe.com/v3:1:88367)
at r (https://tutor.classdojo.com/assets/sentry-WmADp1tc.js:1:85449)
We also log the users' entityIds, so I can look up any users who hit this error and send you to their payment page in our stripe dashboard so you can see any associated payment events
Yeah, that would be helpful if you can share a few payment ids. Can you confirm where and when exactly you see the error? Can you share a reproducable steps for me?
Is the following the entire error you're seeing?
the code that shows the apple pay payment sheet must be invoked directly by a user activation event like a click or a touch gesture to prevent this error make sure the code that shows the payment sheet is at or near the top of your user gesture event handler before any async or long running code
As I wrote, these errors are in our logs, not something that I've reproduced myself successfully. I can share what the stripe code looks like on the pages where users are hitting these errors. This is when users are attempting to book a single (trial) class
What do the uers see on their end?
here's an example of a user who hit this error: https://dashboard.stripe.com/payments/pi_3P6eQVAoyUxvLRDY1qF4rTkM
I am unsure, we've been unable to reproduce, so it is hard to say what the users are seeing. But several hundred stripe errors in the past week was enough to feel like this isn't a one-off, even if I'm having trouble seeing
here's an extremely simplified version of the stripe react code we have on the page where this error is thrown
import { PaymentElement, Elements } from "@stripe/react-stripe-js";
<Elements stripe={STRIPE_PROMISE} options={{ clientSecret }}>
<PaymentElement />
</Elements>
It looks like the payment intent was created but it was never confirmed. It's very hard to debug this if I can't reproduce this or can't see what the end user is seeing unfortunately
Going back to the original error that is thrown within stripe though:
the code that shows the apple pay payment sheet must be invoked directly by a user activation event like a click or a touch gesture to prevent this error make sure the code that shows the payment sheet is at or near the top of your user gesture event handler before any async or long running code
It seems as though the apple pay payment sheet is not being activated within the stripe code?
Looking further
Thank you!
I need to step away for a few moments, if I leave is this conversation ended? Can I give you my email to follow up, or would i just sign back on to discord for updates? Support via discord is new to me (and quite cool!)
Without any reproducable steps, this is so hard to debug.
I won't be able to follow up with an email. In this case, you'd want to write in to support, https://support.stripe.com/contact
noah_applepay-handler
@ripe sapphire that specific error is raised when your code is triggering the sheet outside of a customer action. For example imagine I click on a button and you show the ApplePay sheet -> works.
Now I click on a button, you make an HTTP request to your server to create an order, save it in your database and return with details 10 seconds later and then your code shows the payment sheet -> you get the error you mentioned
Interesting! Thats a lead ๐
So my main question here, before we get into any fixes - what is the consequence of that error? Will users who faced this be unable to proceed, or is it just a warning?
When that error happens then ApplePay (or GooglePay)'s UI will not show so the customer can't pay
Would they still be able to see credit card payment, or is the widget blocked at that point?
I don't know what you call "the widget"
If you mean our PaymentElement UI then nothing is blocked. You do something to trigger ApplePay, we try, it fails. It's on your own code to recover.
For example lots of devs will disable their submit button after a click so you'd need to fix that
overall though really you do not want that error and your goal should be to fix it
Definitely, that's what we are working towards, just making sure that I understand correctly
When you say code triggering the sheet
To confirm - is this what you are calling the 'sheet'?
As in, are you suggesting that there's some code on our end that delays before showing this, or some code after submitting this that is delayed and causing errors?
Yes, that picture you have is our PaymentElement. But in your code somewhere you must call something that triggers the appearance of the ApplePay or GooglePay sheet. For example you call confirmPayment() or elements.submit() or createPaymentMethod(). There are multiple ways to integrate but you want to find your own code that usually is triggered on a button click or form submission to then tell us to confirm the PaymentIntent if that makes sense
Ok, I think I'm understanding
So, on submitting that form, we have this code
const result = await stripe.confirmPayment({
elements,
confirmParams: {
return_url: ${baseURL}#/booking/${classId}/success,
},
});
but it is part of a larger submit handler
if we have an async function that is executed before this, it could throw the error?
So, hope you bear with some pseudocode, but are you suggesting that this would cause the error
const FormExample = () => { const onSubmit = useCallback<TypescriptStuff>( async (event) => { await saveStuffToOurBackend(); await stripe.confirmPayment({ elements, confirmParams: { return_url: ${baseURL}#/booking/${classId}/success`,
},
});
}, [deps])
return (
<form onSubmit={onSubmit}>
<PaymentElement />
</form>)
};`
yeah basically Apple/Google understand you might need some quick async flow before showing the UI, but they also want to prevent devs from just randomly popping up the UI. So my understanding is that they allow for "a few seconds" of async request like yours before the call to confirmPayment() but if it takes too long then you get that error. That might explain why you get it sporadically
Ok, perfect, so if our async call before confirmPayment takes too long, we'll see this
yes, you can reproduce easily by adding a sleep in your server-side code there for like 15 seconds and you'll see it timeout client-side
the real issue is "number of seconds" can change and is different between Google Chrome and Apple's Safari too ๐ So our advice is "do things in one second at most, or try to do the work before the click"
Ok, this is super insightful
sorry for the slow reply, was conferring with my team
I think we'll need to create some transaction logic - right now, we were saving to our system, then actually calling confirmPayment to charge users once we had happily saved their data. Instead, we'll want to confirm payment ASAP, and roll it back in our system if the payment fails I guess
We are seeing this error more frequently on mobile clients, which would make sense - slower internet, slower API calls before confirming payment
One of our engineers just got back to me about the flow on ios - sounds like exactly the thing you are cautioning us away from.