#jason-paymentintent-processing

1 messages · Page 1 of 1 (latest)

half stagBOT
jaunty marsh
#

Not immediately sure what may have happened here but I am consulting my colleagues and will get back to you

rapid wharf
#

Thank you!

jaunty marsh
#

We are still looking in to this. We think this may have something to do with the timing around the cancel call and the user trying to complete 3DS but are still confirming

rapid wharf
#

Thanks! FWIW, on the second payment intent pi_3OgXniJ7xI3N7Avq0Tj6N2iT, we retried the cancel about a second later and it succeeded on retry. From what I can see, before the first cancel call, the last known status was requires_action

jaunty marsh
#

Gotcha, and do you know what triggered the cancel request for this intent?

rapid wharf
#

We trigger it manually via API after a reasonable delay if the user has not 3DS authenticated the payment

jaunty marsh
#

Gotcha. So from what we can see this error is because the user was completing 3DS. This is expected behavior and from what I can see it has not changed recently. Basically we do move intents in to a processing state at a point during the 3DS process, normally this is brief but sometimes there can be delays which make it happen for longer. So this looks to be an unfortunate case of timing, and I think retrying as you did would be the right way to mitigate it

#

I will make sure we update our docs here, the doc definitely makes it sound like this should never happen

rapid wharf
#

Can you clarify what you mean by "completing 3DS"? Do you mean they still have the 3DS authentication window open?

jaunty marsh
#

Apologies I initially misunderstood what we found. It looks like the user had just completed 3DS and we were waiting to hear back from the bank about it.

rapid wharf
#

Interesting, how come we didn't see an authentication succeeded event if they completed 3DS?

jaunty marsh
rapid wharf
#

Yeah, so I see it failed after the first cancel request was made (albeit only a second later)

#

Ok, so for pi_3OgXniJ7xI3N7Avq0Tj6N2iT, I think what might have happened was we first got the webhook event that the 3DS attempt failed. After getting this webhook event, our handler calls Stripe to cancel the payment intent, but seems like the first time we sent this request, Stripe did not have the updated status as requires_payment_method yet, despite 3DS having already failed. So possibly Stripe has some delay in updating its status? We then see that 1 second later the status is now requires_payment_method and the subsequent cancel request that we retried succeeded.

#

I think the same thing happened on both PI. Seems like possibly a race condition due to async updating of the status?

jaunty marsh
#

Yep seems like it. Do you know if this has happened more than twice? It is a bit surprising that this has happened on two of them

rapid wharf
#

So far I've only seen it twice

rapid wharf
#

Actually sorry, taking a look at our own logs this is what I see happened from our side + cross referencing Stripe's dashboard:

  1. We created a payment intent and requested 3DS
  2. We didn't receive any webhook that the user 3DS authenticated or fail authentication in time frame (10 minutes) before we attempted to cancel
  3. We made a request to cancel the payment intent
  4. This failed due to "You cannot cancel this PaymentIntent because it has a status of processing. Only a PaymentIntent with one of the following statuses may be canceled: requires_payment_method, requires_capture, requires_confirmation, requires_action.; code: payment_intent_unexpected_state"
  5. Then a second later there was a webhook event that 3ds authentication failed, which also updated the status to requires_payment_method
  6. We then retried canceling the payment intent, this time it succeeded because the status is not processing

We've had this flow in place for a while to cancel payment intents after a delay and have never encountered the status as processing until today. An example payment intent where we canceled the payment intent successfully is here: https://dashboard.stripe.com/payments/pi_3OgVy7J7xI3N7Avq1RWpsPhk. So I'm wondering if the two payment intents in my original post just experienced a coincidence where they failed 3DS authentication at the exact moment we tried to cancel them? Seeing this edge case twice for the first time on the same day seems a bit suspicious though.

jaunty marsh
#

Yeah that does seem strange. I will try to double check with my colleagues to see if anything changed.

rapid wharf
#

Thank you, I appreciate you looking into it!

half stagBOT
wooden plaza
#

jason-paymentintent-processing

wooden plaza
#

@rapid wharf looks like it is "expected" that processing can happen on card payments when we're in the middle of 3DS. I didn't know this either unfortunately and I agree our docs are unclear on this. Ultimately my advice is to handle this gracefully if you get a failure trying to cancel a PaymentIntent because of that error you can retry async later for example

rapid wharf
#

Got it, thank you!