#stavros-malakoudis_api

1 messages · Page 1 of 1 (latest)

native nymphBOT
#

👋 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/1461068434786877532

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

wind hollow
#

Hi there - thanks for the clear examples

orchid elm
#

Sure, let me know if there is anything I can give more detail for!

wind hollow
#

Do you happen to have a fresher example on the clover API version? (req_D2j314fxPvDUvU) The webhook events on that are out of retention by a couple of days. If not I can hunt for one which should be easy if you often do partial capture

orchid elm
#

Yes, I was going to provide the same one !

wind hollow
#

I feel like I'm perhaps not grasping the issue completely. I understand that we don't use refunds to represent partial capture any more, and this is breaking your logic for differentiating between partial capture & partial refund, but I'm not sure why yet.

So if we take the current example above's charge.captured event here: https://dashboard.stripe.com/acct_1IvUSeHxNT300n1J/events/evt_3SpZ3SHxNT300n1J0RzP1CAv

I'm going to spoof the numbers for simplicity, but you have amount($10), amount captured($9), and amount refunded (0)

In the previous version you would have amount($10), amount captured($9), and amount refunded ($1), right? but that refund is released authorization and not a real refund

orchid elm
#

Exactly

#

thats correct. The old way of calculating the "true" refund cannot work for the new logic

#

And the issue is that old charges keep the amount_refunded > 0 even on the new API (makes sense in a way) but unfortunately this results in all the past partial captures having a different schema than the new ones

#

Ideally we would like to have a unified way of identifying between a partial capture and a true refund that works for both cases. It's clear how to do the old way and its clear how to do the new way. We cannot figure out how to do both using a single approach, if that makes sense

#

We tried to use the refunded flag but this is true only for full refunds, so that cannot do

wind hollow
#

I was aware this change was happening but I haven't had occasion to sit with it yet so let me do a little testing here. I would have assumed fetching PaymentIntents created using an older API version with the current version should get you a PaymentIntent in the current shape and that that would solve the issue but it sounds like you're saying that isn't the case.

orchid elm
#

I was hoping for the same to be honest. Each time we take any financial action on our system we sync with Stripe (in case we missed any refunds) and that would have solved our issue

#

Take your time, no worries

wind hollow
#

We've made this difficult 😅

orchid elm
#

We could try to change the approach based by the payment creation date but then again our database would be split into two different versions of the same thing and reporting will be even harder

wind hollow
#

Yeah, I understand. I don't see a way to distinguish, but I want to discuss this with my colleagues who are in a meeting for the next ten minutes or so

orchid elm
#

I can wait!

#

Thank you for digging further into this

native nymphBOT
wise nebula
#

Hey @orchid elm thank you for your patience. Unfortunately it looks like there isn't a way to do this that works in both the pre and post basil versions. So it sucks but I do think having code that checks the created time and then runs the appropriate calculation is the best way forward here.

orchid elm
#

Alright! Thank you for investigating this

wise nebula
#

Of course, and let us know if you run into any other issues here

orchid elm
#

thanks!