#Guillaume-elements-checkout
zinc kettle
Hey Hanzo, I'm in no rush! 🙂
round crane
what was the exact behavior? Like they were never redirected?
Did they see an error?
zinc kettle
They were never redirected, but I was seeing declines on my dashboard.
I'm looking through my code now, and it's possible that the submit callback just fell through without doing anything. Here's my code: https://pastebin.com/dCmGeY5U
round crane
what error are you seeing on the dashboard?
zinc kettle
bank declines.
but meanwhile, they were still on the checkout page, with the submit payment still disabled.
so it looks like my formSubmit finished without redirecting them.
round crane
can you share those example PaymentIntent IDs?
zinc kettle
sure
pi_3LA3wFEib9TdzxSq1IRaVM5D
This was a Korean user with a weird Chrome version: 102.0.0.0
I'm wondering if there wasn't a problem with their browser/javascript engine...
(my checkout page is working fine for me in Chrome and Firefox, and all the customers I've had lately, but I'm wondering if maybe the javascript isn't compatible for some other browsers. ie I know async/await is not fully supported yet.)
round crane
Could be. For each attempt the card was declined.
zinc kettle
could you please take a quick look at my code? Is it possible that there is no error variable set after const {error} = await stripe.confirmPayment() ?
right now my code will do nothing if there is no error var set, and the pay button will stay disabled. this may be what happened to this user.
round crane
yeah I'd recommend throwing in a debugger or a console.log
zinc kettle
well I would do that if it was on my machine, but how do you debug a customer's js execution?
round crane
ah I meant on your machine and trying to trigger that block with one of our test cards
https://stripe.com/docs/testing
zinc kettle
i've already tested all of those, everything works fine in my test browsers.
I'm asking if you know if this js code can be problematic for older browsers, and what I can do about it?
round crane
AFAIK async/await should be supported on that chrome version so unlikely its that
let me take another look
zinc kettle
ok
round crane
Can you explain this piece of code? Like what is the intent here exactly?
if (++failedCharges >= 4) {
window.location.href = '$returnURL';
} else {
showError("Your payment could not be processed. " + error.message);
submitButton.value = "Submit Payment";
submitButton.disabled = false;
}```my $returnURL page gets the paymentIntent from the session and shows the status. But before redirecting there, I want to give the user a couple other chances of fixing anything on the form and trying to submit the payment again.
So I only redirect after a couple of failures.
otherwise I show an error and enable the payment submit button again.
round crane
gotcha. so one of the theories I have is that something must be setting failedCharges back to 0
zinc kettle
no
cause they were not seeing an error message.
the submit button was staying disabled, without an error message, which implies that there was no error var set.
other possibility is that confirmPayment was taking REALLY long. How long can it take?
round crane
How long ? It shouldn't take very long. but it also depends on customer's internet connection
They maybe going through some fluctuations/unreliable connection
Are you seeing this happen with any other users as such?
zinc kettle
well, I can't ever see if this happens unless they tell me. and this is the first time a user has reported this.
but who knows how many other users are encountering this and not reporting it...
I'm going to change my code slightly so that it redirects to the status url if there's no error var set.
just to be safe.
and I will maybe add a message to wait while the payment is processing, and that it can take a while...
round crane
Yeah I'm not sure how we can investigate this further. the code looks fine to me.
I agree that it is weird but can't make any recommendations since its just one user (that we know of) and issue isn't re-producible (could be an edge-case, but not really sure).