Stripe error in payments log

breaksecurity

immagine
What is the meaning?

And why if there was an error the order status is changed anyway?

ryanmitchell

You’d need to look at Stripes error responses to see what that means.
Did the order get marked as being successful?

breaksecurity

I set stripe order to have as a status received that is also the default status for new orders so maybe that was the problem

I found this:
https://stackoverflow.com/questions/63136668/payment-intent-unexpected-state-in-stripe-payment-integration

Also found this seems to be code related:
https://stackoverflow.com/questions/64857014/stripe-php-api-you-cannot-confirm-this-paymentintent-because-its-missing-a-pa

Also in the forum:
https://forum.tastyigniter.com/d/1458-cannot-select-stripe-as-payment-method

Also the error shows up in only one order for now

Also some pieces of discussion founds on internet:

10:00
stripe425
“You cannot confirm this PaymentIntent because it’s missing a payment method. You can either update the PaymentIntent with a payment method and then confirm it again, or confirm it again directly with a payment method.”
10:01
karllekko
mthinglis: I think I saw a case of that before but I don’t know if it’s a known issue. If you can get any more information I’d write to support.stripe.com/email. For example maybe in the browser console there’s an error, or the network request to load stripe.js is failing, if you have some reproduction steps we can try to look into it
10:03
stripe016
this is it ! thanks @karllekko
10:03
karllekko
stripe425: I think your backend (PHP?) code is not using the ID of the PaymentIntent that your frontend is sending, and is using a different one
10:05
karllekko
I’d suggest reviewing your logs(dashboard.stripe.com/test/logs) and your code
10:05
mthinglis
Ok, thanks @karllekko. I got in contact with stripe support (through their chat) but they sent me here. I will send an email to stripe
10:07
karllekko
stripe016: it looks like you e.g. create and confirm a PaymentIntent using the PaymentMethod from the frontend(dashboard.stripe.com/test/logs/req_eOjDxgjlNRCC6f), and that’s all good, but I think then when the frontend submits the PaymentIntent back to your server, it’s creating a brand new PaymentIntent instead of re-confirming the first one (dashboard.stripe.com/test/logs/req_yVR1E7hVZX97E6)
10:08
karllekko
sorry, that was for stripe425

And:

timebox here is the error
06:00
vipin
“message”: “You cannot confirm this PaymentIntent because it’s missing a payment method. You can either update the PaymentIntent with a payment method and then confirm it again, or confirm it again directly with a payment method.”,
06:00
timebox
vipin: So the Payment Intent doesn’t have a Payment Method.
06:01
vipin
yes because the payment method is generated using the JS sdk not from server side
06:01
timebox
vipin: So you’re not following that link I pointed you to?
06:02
vipin
timebox I added the “capture_method”: “manual”,
06:02
vipin
to my server side
06:02
timebox
Here? stripe.com/docs/stripe-js/elements/…quest-button#html-js-create-payment
06:03
timebox
vipin: If that’s all you changed and you’re otherwise following it, it should work (except that the payment won’t be captured at the end)
06:05
vipin
timebox do you want me to add the payment method and the customer Id in server side payment Intent before click on pay now button
06:05
Nstripe0
Hi, will it be an issue if PaymentIntent’s specify setup_future_usage=off_session for a PaymentMethod that is already attached to a customer?
06:06
timebox
vipin: You need to follow the tutorial completely first, make sure that works, and then make the changes you need.
06:07
wsw
@Nstripe0 I don’t think you could do that, but let me test quickly.
06:07
timebox
Nstripe0: Hi! I’m not sure what will happen but I almost suspect you’ll get an error.
06:08
vipin
timebox okay let me try
06:12
wsw
@Nstripe0 actually you can do that and it does not throw any errors and it will simply do nothing for those pm not needing additional setup
06:13
Nstripe0
wsw: Thanks, appreciate you confirming that.
06:27
wsw
@Nstripe0 np, also, you cannot use setup_future_usage=off_session together with off_session=true, it means that when a card is SCA card, even if the card is setup, you will still be prompted to 3DS again as you cannot use off_session=true
06:33
Nstripe0
wsw: Got it, thanks for the tip.

ryanmitchell

Seems odd.

We did add idempotency and incomplete payments in the last couple of releases but neither of those would cause that error.

can you confirm from payment logs on the order that it was marked as successful?

I assume you are using the latest version?

breaksecurity

Last version, yes I can confirm it was NOT marked as incomplete. I am preparing a message with all the other odds scenarios happened with card payment. I will post soon.

breaksecurity

Also I am noticing different anomalies with Stripe payments.
1) Duplicated order (The card withdraw is done two times instead of one! A nightmare)

Happened 4 times! One of this was not a duplicated order but was a quadruplicated order with 2 card withdraw…

2) Cart as insufficient founds but order get confirmed anyway…
immagine

3) Wrong security code after payment successful… Order get confirmed anyway
immagine

4) Wrong card number after payment successful… Order get confirmed anyway
immagine

5) Sone cases are very “colourful”
immagine

6) This one is a duplicated order but I will put it separately from point 1 because of the odds status…

the first order get NO status history at all. The duplicated ones get a sort of “duplicated payment alert”

Other info:

Tasty was last beta.
Additional extensions used was printer and broadcast.
Those scenarios are not so easy to reproduce because we do NOT know what the customers are doing (usually happening on Saturday when we have more traffic).
Log are clear from errors.

Hope to be useful for the community @ryanmitchell @sampoyigi

ryanmitchell

Im not sure about
You’d need to look at the payment intent logs in Stripe, but I suspect it ultimately was successful which is why it got marked as so. Could just be a payment log error.
3, 4, 5. The most recent log is at the bottom of the list not the top… so these are correct.
This is idempotency keys preventing duplicate payments (which is why 1 is odd to me) and is expected behaviour. This happens when a customer double/triple clicks and we’ve put a method in place to prevent duplicate payments. You will get only 1 payment taken and 1 order marked as successfull - the others will be incomplete.

breaksecurity

Thanks so much for clarification I was considering the TOP one to be the most recent one because in status history is this way and I have only hour to discriminate NOT so useful for those events that are so near in time

ryanmitchell

Feel free to open a PR with the change - should be an easy one 🙂

breaksecurity

I will do. Is there something that I can do to help debugging the odds scenarios?

ryanmitchell

For #1 I would look at the times in Stripe itself to try and get understanding as to what has happened. Look at the time of the orders payments etc. Its possible the customer has incorrectly placed multiple orders rather than being a code issue.

breaksecurity

Thanks and way tasty have done two card withdraw with duplicated order? Is a concurrency problem?

ryanmitchell

Thats issue #1 - thats what I said you need to look into.