#noah_applepay-handler

1 messages ยท Page 1 of 1 (latest)

hollow hullBOT
#

๐Ÿ‘‹ 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.

prime matrixBOT
autumn saffron
#

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?

ripe sapphire
#

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

autumn saffron
#

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

ripe sapphire
#

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

autumn saffron
#

What do the uers see on their end?

ripe sapphire
#

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>

autumn saffron
#

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

ripe sapphire
#

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?

autumn saffron
#

Looking further

ripe sapphire
#

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!)

autumn saffron
#

Without any reproducable steps, this is so hard to debug.

prime matrixBOT
gentle kernel
#

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

ripe sapphire
#

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?

gentle kernel
#

When that error happens then ApplePay (or GooglePay)'s UI will not show so the customer can't pay

ripe sapphire
#

Would they still be able to see credit card payment, or is the widget blocked at that point?

gentle kernel
#

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

ripe sapphire
#

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?

gentle kernel
#

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

ripe sapphire
#

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>)
};`

gentle kernel
#

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

ripe sapphire
#

Ok, perfect, so if our async call before confirmPayment takes too long, we'll see this

gentle kernel
#

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"

ripe sapphire
#

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.

gentle kernel
#

yep exactly that

#

and if you're unlucky, it's all fast on local development so you never notice it

ripe sapphire
#

Ok, this was incredibly helpful, thank you for taking the time to talk this through

#

I'm going to drop from discord now, but Koopajah, thank you so much for taking the time to help on this