#MJ Garcia
1 messages · Page 1 of 1 (latest)
Hi 👋
This forum is for developers integrating with Stripe APIs. Are you writing code yourself to handle this integration?
IF you have some example request IDs I can take a look to see if anything seems out of place with the requests themselves.
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
Hi Here you go: req_imuAFt2uSm5hw0
Thanks, looking
Okay this request is generating a Payment Intent for a specific customer that then requires a payment method
It's generated by Magento using your API keys
Correct, issue is it later canceled itself due to an abandoned cart.
There's nothing Stripe can or should do to prevent server side code that has your API keys from making requests that are valid
Cart abandonment isn't something Stripe controls
The Intent was created, modified twice, then canceled
But there is nothing fundamentally wrong with any of these API calls that should prevent Stripe from acting on them
We never had an issue with these kinds of orders before. Historically Stripe has prevented orders from being created in Magento due a payment issue ie insufficient funds or card declines, but for some reason over the past 3 weeks, any order with a payment intent, even if it fails, has been allowed to be created by Magento. Let me try to find one with a different error.
Stripe is the payment processor. If requests are being made that shouldn't be, that logic should. be handled in the integration. At least that is how it appears to me currently based on these API calls. There's no insufficient funds issue in any of the API calls related to the previous payment intent though. So maybe another example will clarify things.
Sorry for the delay, but here you go: req_zPaGPtAAzaVeQu
These was a invalid cvc
I should add that we did upgrade Magento around this time, so i'm not sure if this issue stems from that.
Okay so the CVC was invalid and the Charge was blocked. What did you expect to happen in this case?
I guess what we're trying to figure out is why these kinds of orders are being pulled into Magento, when they weren't before. Like the order was correctly blocked, and in the past that would be it. But now, even with the order being blocked, it is still be created in Magento, though being canceled right away.
That isn't something Stripe would control
Nothing about how these events are handled or the webhook events fired has changed recently
I am assuming that webhooks are how Magento synchronizes the records
For weeks we've been trying to figure out why this is happening and as far as we can see on our side of the integration, nothing seems to be wrong. We're trying to identify what is triggering this, and was hoping Stripe might be able to see something we're not.
That is correct.
So this would have fired a charge.created event
Got it. Its just weird because we didn't experience any of these issues when we were testing in staging before we upgraded Magento, but the issues started right after the upgrade went live. We were not on the most recent Stripe update though. But we did test the newest update in Staging, hoping it would resolve this, but the issue still persists.
Hmmmm... it sounds like Magento made a change in how they process the Stripe webhook events. I wonder if it was intentional (as in people wanted visibility of these failed charges) or is something configurable
I will bring that up with our team, thank you! Just been frustrating because we can't seem to pinpoint where the breakdown is and it came out of nowhere. We've gone through numerous big Magento and Stripe upgrades/updates since our integration started almost two years ago, and we have never seen this before. I really appreciate your help though. Hopefully taking another look into the webhook behavior and if it differs from pre-upgrade can give us what we're looking for.
Sure thing! If you still have questions after reviewing the configuration for Magento feel free to come back and ask. Having a set of "normal" and "weird" request IDs will really help too.
Okay, will do. Thank you again! Have a good weekend!