#nickdnk-failed-refund
hearty ginkgo
hearty ginkgo
no I'm looking into where that error is coming from
hearty ginkgo
no I'm good, just trying to understand what is causing that error to not return https://stripe.com/docs/error-codes#charge-already-refunded like it should
velvet shell
Hmm.. No? This is when you refund a charge that's already refunded, is it not? I'm trying to refund a charge which has a failed refund attempt associated with it
In other words; a charge that has reverted from refunded to "not refunded at all"
hearty ginkgo
that's the thing, it's the same
you can not refund a charge that was refunded already, whether it failed or not. The fact that the refund failed is irrelevant (or should be) and the same error code should be used
velvet shell
It's a partial refund
I don't know if that helps
I mean, this changes the point of "you cannot refund a charge that was refunded already" - unless it was partially refunded
hearty ginkgo
yep that's what I'm trying to track down, I've never seen this error before and IMO we shouldn't prevent you from refunding because of that error
velvet shell
I'm sorry I do this to you on such a regular basis
hearty ginkgo
haha it's fun, that's a big part of my day to day work to track down every API changes and make sure they are approved before they go out
velvet shell
Well then I'm happy I keep you busy
Was referencing the previous "I'm always worried you found a nasty bug"
hearty ginkgo
ah yeah but I'd much rather you find it quickly than no one until weeks later :p
welp, that error is 3 years old and I've never seen it. The more you know
I agree an error code would help so I'll flag but unlikely to happen soon
velvet shell
Cool, not a big deal to me either
It's just to avoid reporting it from my backend if I know it's a case
And yeah this is super edge-case territory
Is there a way to detect if an API response was returned based on idempotency key?
I see it in the dash; req_4NtZPAItl0T7ez but I don't know how to access that in the PHP library if it's at all possible
And yes this is related to refund logic, as I'm refunding partially from the same order and cannot do that multiple times for the same item, so I use idempotency keys, but this creates this problem where a failed refund and a new attempt within 24 hours will mess up my logic
hearty ginkgo
we return a custom header when the request is an idempotent reply
the header is Idempotent-Replayed with true if it's a replay.
https://github.com/stripe/stripe-php#accessing-response-data is how you access headers
hearty ginkgo
yay for features we add hoping people need them
velvet shell
distributed systems are hard 😄
hearty ginkgo
okay reported the ask, we'll see what happens, thanks for flagging, I'm always surprised how many edge-cases I've never seen even after so many years
(we're still hiring 😉)
velvet shell
Just living up to my nickname
And yes unfortunately things are going quite well with our platform at the moment. We have moved so much volume now that we interviewed for the revenue share program. But I'll keep it in mind if we go bankrupt for sure.
velvet shell
Yeah some headwind finally after a year and a half with absolutely zero traffic
By the way, I listened to the webhook talk here on the Stripe Discord stage. I think it was some first "attempt" at creating some community events, and I noticed that there was talk in #841573134531821615 about "what did you build with Stripe"... so on that note, if you need someone to do presentations of something running on Stripe for future stuff like that, I could probably show some of the things we built.
While we're on the subject of the business and working at Stripe, this seems like something in between that could happen
velvet shell
Heading to bed, let me know. Thanks for your help.
hearty ginkgo
ah I don't run this but I'll flag to the team!