#heymato
1 messages · Page 1 of 1 (latest)
hello! you won't get into the requires_confirmation step unless you use confirmation_method=manual : https://stripe.com/docs/api/payment_intents/create#create_payment_intent-confirmation_method
you may want to take a look at https://stripe.com/docs/payments/intents too
Well the strange thing is I got this status of a customer in my production environment. I'm trying to figure out how he got there
do you have the PaymentIntent ID pi_xxx where that happened?
yes
pi_3MHh11EzohgVwKXw0Ycya4ps
the thing is, I thought something was wrong with my implementation but I cannot seem to find where.
you create the PI, then confirm it on the frontend, it moves to requires_action because the customer needs to do 3D Secure. About a minute 30s after that you call the update PaymentIntent API, which clears the payment attempt and moves it back to requires_confirmation
yes
I have an extra question, can I see if the customer actually confirmed and get through?
or in other words, did he get passed the for example 3D secure ?
if they did the Promise from calling confirmPayment on the frontend would resolve and you'd have gotten a payment_intent.payment_succeeded webhook event. Actually sorry, it wasn't 3D Secure, it was iDEAL(they should have been redirected to iDEAL's website to complete the payment).
and no it didn't succeed in that example, since presumably while the customer was on the iDEAL page, you update the PaymentIntent, which cancels the attempt overall
That last one is an important one. But i do not understand how my code would do something without an action of the customer or webhook.
that's where you'll have to do some debugging/investigation, I'd start by looking for paymentIntents.update in your codebase and see what could trigger that and add some logs around it
OK thanks
My apologies to ask so many questions. In the above scenario could it be that they just stopped and exit from the IDEAL screen ?
it could be, we don't have any observability into what they actually see or did
all we know is iDEAL authentication was needed, presumably they were redirected to it, and then 30 seconds later you update the PaymentIntent, we don't really know what happens in the browser or in iDEAL during that time, that's more something you might have logs for to combine with the PaymentIntent logs
yes OK thanksè
I wish you great holidays and I am very happy with your support. I might ask you some things again today but for now I have enough information.
Sorry to bother you again. Where did you see it was iDEAL?
never mind. I found it
Hi karllekko, just to be sure we are talking about the same. The update (in blue) is the one that re-updates the paymentIntent from requires action to requires confirmation. Which is 8 sec. later?
yep
when I said 30s I'm talking about pi_3MHh11EzohgVwKXw0Ycya4ps, I assume the other one is the same thing just with a different timeframe
OK, so I called this particular customer and the customer told me he was billed, but when I look in the timeline, I cannot see any payment. Could it be that iDEAL did do the payment? pi_3MHnJDEzohgVwKXw1EDMPPdz
yeah the IDEAL transaction is settled on our side so they were charged yes
ok
because you're updating the PaymentIntent it's removing the active payment attempt and probably results in us failing to reconcile the PaymentIntent to the correct status when we get an update from IDEAL
which shouldn't happen. What happens as far as I know in this case is we'll eventually automatically clean up this PaymentIntent from checkers that look for broken PaymentIntents, and refund the customer. You can follow up with https://support.stripe.com/?contact=true for questions on specific livemode payments
but really you need to stop updating these PaymentIntents while they are requires_action and the customer is involved in authenticating them
Yes, I understand. Unfortunately that doesn't seem to be very easy in the existing code....