johan

[gleaming raven]

Hi! Let me help you with this.

[fresh dew]

thanks a lot

[gleaming raven]

they get confirmed multiple times (users get charged more than once)
This is not possible
Could you please provide an example PaymentIntent ID? pi_xxx

[fresh dew]

this is an example of a customer that got charged 4 times, the paymentIntent was confirmed 4 times.
1: pi_3MPWlcJ0LvPBcIXv0QKlEQmB
2: pi_3MPWlkJ0LvPBcIXv0prTPhxf
3: pi_3MPWmAJ0LvPBcIXv1MVWYNef
4: pi_3MPWnlJ0LvPBcIXv0VdcDBFl

this happens very rarely, we get cases where they get charged multiple times or cases where they get charged but the order doesn't get fulfilled after confirming the paymentIntent in the client side

[gleaming raven]

These are 4 different PaymentIntents, so it's expected

It's best to keep 1 PaymentIntent for a session, and update it if the amount changes. This will ensure the customer only gets charged once.

[fresh dew]

okay I understand, but if that was the case why 99% of the cases it works and occasionally it charges customers multiple times?

[gleaming raven]

How are you creating your PaymentIntents? Why are you confirming them right away? (confirm: "true",)

[fresh dew]

We have an API to create an confirm a paymentIntent, if that is successful we trigger an API request from the client to the server and fulfil the order (assign a gym class to a customer)

should we confirm the paymentIntent after the class is assigned successfully then?

we have other scenarios such as this one: pi_3MLqP1B45ZPr5ETA0mGlQi7Q where we don't confirm it straightaway in the API, but we confirm it on the client and then we fulfill the order and it fails occasionally too.

[gleaming raven]

I see, you can have a check if a class is already assigned to a user before creating and confirming the PI. This way, if the customer clicks a few times, by accident, they won't be charged multiple times