#gyungi_code
fluid spruceBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1392267950425374891
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- gyungi_code, 13 hours ago, 18 messages
- gyungi_docs, 6 days ago, 6 messages
wraith drum
What's the error you're running into?
thorn hemlock
"Canceling this refund is unsupported."
Seems fairly self-explanatory, I'm just curious about what refund cancellations ARE supported and what I should do if I can't cancel a particular refund.
at a more granular level, we have our code set up such that whenever we process a card payment in our system, we start our flow by processing the payment in stripe and then recording things in our database that use the payment intent id from that flow; if any of that fails we cancel the payment so no funds move and I'd love to be able to do a similar thing for refunding any sales made in our system
Is the right thing to do here to just re-charge the payment method?
wraith drum
Sorry, one sec.
thorn hemlock
no stress!
thorn hemlock
We store information about the transactions that happen on our platform in our database; in the event that there's some failure on our end to record the refund transaction, we want to reverse everything that happened in that flow, including the refund. Basically if something goes wrong on our end we want to make it such that it looks like nothing happened, which we can do with payments but we're working on getting to work with refunds as well
wraith drum
That's not really going to be possible, either in Stripe, or from an accounting perspective.
Are you listening to the refund events? https://docs.stripe.com/api/events/types#event_types-refund.created
thorn hemlock
Not listening to the refund events, I'll look into that!
when you say from an accounting perspective, what do you mean? Like once the refund has been processed you can't cancel it in the same way that you cancel a payment?
wraith drum
I mean, you can't ever "delete" things in accounting, only reverse them.
(Despite what QuickBooks would have you believe...)
thorn hemlock
Yeah sorry that's kind of what I'm trying to accomplish here is a reversal via a cancellation
like it can reflect as having happened and been reversed in stripe, i just would like the funds not move
wraith drum
Ahh, ya. Ok. https://support.stripe.com/questions/canceling-a-refund talks about cancelling refunds; it's not really a common thing, I don't think.
thorn hemlock
The documentation I looked at earlier said that initiating a new charge for the same amount accomplishes the same thing and I'm happy to go that route I was just wondering if there was a route to go with the refund directly
wraith drum
I mean, it would do that, ya?
thorn hemlock
It would yeah, I was just wondering what constituted a refund that WAS cancellable so that I could use that endpoint instead
wraith drum
That doc I just sent you talks about it. It's not something that's broadly supported, I don't think.
But do note that creating another charge will mean the customer will see the first charge, the refund, then the "un-refund charge".
If this is just about "is my system in sync with Stripe" I'd definitely suggest looking at the Events and making use of those (alongside your own existing code/api calls) to ensure they're in sync - if that makes sense?
thorn hemlock
yeah that's what i was trying to avoid is that you'll see all of that in your card activity; def read that it wasn't a common thing or something that's broadly supported but was hoping to avoid the triple whammy so to speak lol
yeah i'll take a look at the events!
wraith drum
Not sure if you're already using Stripe Webhooks or not, but lots of good info here: https://docs.stripe.com/webhooks#best-practices
thorn hemlock
nah we haven't started using em yet but it's been in the back of our minds for a while, maybe this is the impetus to start doing it
thanks much, this has been helpful!
I think in this specific instance we'll have decent conviction that we're either in-sync or out of sync with stripe but still helpful
wraith drum
You're very welcome! Implementing asynchronous event handling alongside your existing stuff can be an adventure - making sure that you handle the API call and its event the same way, and only once, for example - but it's also quite powerful.
One thing I'd suggest: make your "Event handling" code (that actions the Event) separate from your "Event receiving" code (that describes the handler for the URL that Stripe actually hits) so that you can, for example, list a bunch of events via the List Events API, and push each of those through your "Event handling" code.
That lets you ~easily do backfills, handle dropped events, (more easily) write tests, and develop the "Event handling" code from a JSON file full of Event objects (i.e., from the List Events API).
thorn hemlock
Yeah makes total sense! Appreciate the advice 🙂