#daken-3ds
frigid heron
Can you share an example payment ID?
sand blade
As you see, he tries 3DS like 6 or 7 times
one of them gets through but our theory is that this request gave timeout to the user for his internet connection
so he thinks the payment failed, so he retries again
frigid heron
Which specific payment?
All I see is multiple incomplete Payment Intents around the same timestamps
frigid heron
Where do you see 6/7 3DS attempts? I only see 1 for that specific payment and it succeeded: https://dashboard.stripe.com/logs/req_KECXkIOaGwIXqG
The other in that list aren't 3DS attempts, they're completely separate Payment Intents that your integration is creating
sand blade
My integration creates new payment intents if the user refreshes the checkoout (i know it should not be) but those payments are the same checkout, you can see for the hours
Just assking if its posible the reasoning I told you before, client disconnects or cancel the 3DS but the 3DS request gets to Stripe in time, but since he canceled, he sees an error, and since we are generating a new payment intent, then he pays again
cunning crow
Hi! I'm taking over this thread.
Can you share the PaymentIntent ID of the "duplicate charges"?
sand blade
All of them are similar to this, give me a moment to search some of them
cunning crow
Please share at least 2 PaymentIntent ID that you think are duplicates
cunning crow
Here's the request to create the first PaymentIntent: https://dashboard.stripe.com/logs/req_XJ36kaBEACjOtl
And here's the request for the second one: https://dashboard.stripe.com/logs/req_NxERLbyT6zehVG
So from Stripe's point of view everything worked as expected: you created and confirmed 2 PaymentIntents, so Stripe charged the customer twice.
If that's not expected, you need to review your integration to understand why you created and confirmed 2 PaymentIntents.
sand blade
I know
I am nos asking any of this, I know there are 2 payment intents
Because we generate a new one with each refresh of the checkout
I am asking, if its posible that during the 3DS, for some network problems, the client thinks the 3DS failed, but in reality it went trough
Because this is what the clients are saying, that the 3DS gave error, so they tried purchasing another time
cunning crow
On our end it the 3DS was succeed with no errors. But I guess it could be possible for the user to close the page just before the success messages is displayed, so they are not aware that the 3DS succeed?
Do you have some screenshots or screen-recordings of what the user is seeing in this case?
sand blade
I am thinking of network timeouts or closing the 3ds modal before it gets completed
No, we do not have screen recordings.
balmy kettle
there's very little we can say really beyond what you've found yourself
sand blade
But we have extensive descriptions of all users who explain the problem
Just wanted to make sure if its posible what I said
Network timeout or cancel results in error in the frontend but success on the Stripe
balmy kettle
3DS can fail for lots of reasons like timeouts or the bank being broken or anything really
and yes, sometimes we can see cases where it looks like an error happened but the authentication proceeded, anything is possible unfortunately
webhooks are the source of truth for the payment outcome