#defekt7x
1 messages · Page 1 of 1 (latest)
As far as I know, you shouldn't be getting charge.refunded on cancelled Payment Intents. Are you 100% certain that that's what is causing the event?
Yes, I got payment_intent.canceled and charge.refunded events that came in at the same exact timestamp when I canceled that uncaptured payment
I get payment_intent.canceled, but I don't get charge.refunded.
Can you provide the ID for the charge.refunded Event that happened?
Ahhhh, okay. I didn't realize you were on an older API version. If you upgraded, you wouldn't have the charge.refunded event as far as I can tell. Let me double-check though
Yeah, that looks like it is from an older API version, so you could upgrade to stop that event from firing, otherwise you would need to code your handler to ignore authorization cancelations
I see. Ok that makes sense. Are there any breaking changes I need to be aware of when upgrading?
Hard to say from my end, since I don't know what your integration is using. You can review our changelogs: https://stripe.com/docs/changelog
And our docs on upgrades: https://stripe.com/docs/upgrades
Additionally there may be more useful information on Github changelogs on a library-by-library (language_by_language) basis
Howdy - stepping in here for @trim summit who has to step away soon
I'll also mention that you really shouldn't be doing authorizations like this when you don't intend to collect payment
Using our newer APIs, you can authenticate cards without collecting payment by using Setup Intents
See the guide about this here: https://stripe.com/docs/payments/save-and-reuse?platform=web
Thanks, @deft mortar - yeah, I paused this method for the time being while I was investigating some of these quirks. It seemed like a decent method at the time, using test cards, but I was not aware that it would actually post to customers bank accounts, so I immediately reverted this. Will check out that link, thank you