#aeo_best-practices

1 messages · Page 1 of 1 (latest)

gilded hazelBOT
#

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

📝 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.

magic sluice
#

hello! gimme a second to see if this is something that can be determined

prisma cliff
#

not that this matters "too" much.. but I'm also interested in making sure I also save 30 cents to cover out costs... (full reversal)... it might be sufficient for us to use the flag that automiatcily calculates the refund percentage on partial refunds... but I still need to know if that partial refund will be a reversal or not

magic sluice
prisma cliff
#

i was hoping to not have to do it that way... but I imagined it might end up that way.... I was trying to determine that at the time of the refund api call, and instead making it a 2 step process

magic sluice
#

ah, unfortunately, that's not going to be something you can determine at the time of the refund API call I believe

prisma cliff
#

will the refund.updated webhook be called many times?

#

is there a "final" status or something I can look for so, I don't have to worry about maintaining a state on my side of wether or not to process the app fee refund

#

i feel like this should be a very commong use case? i'm suprised there isn't something to handle it

#

can I call the api immediately after the refund is initiated, and check for the reversal status?

magic sluice
#

It depends on the situation. For example, your application might make updates to the Refund object that trigger a webhook, or a refund could fail and change from successful to failed (though this wouldn't happen for reversals). That said, I'd recommend building in safeguards against unexpected changes just to be on the safe side.

Why do you want to call the API immediately instead of waiting for the refund.updated event?

prisma cliff
#

not sure... just to build all the logic in one place... i was just asking 🙂

gilded hazelBOT
prisma cliff
#

i was already resigned to accepting that I would probably have to wait and check the webhook... just looking for more clarity and understanding, if I could get it done in one fell swoop

fading mist
#

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!

prisma cliff
#

from looking at some of my refunds / reversals... it looks like generally, i get one refund.updated evernt... if its a reversal, it appears about 2-3 minutes after the refund was initiated, but on a refund, it looks like 1-2 days

#

i dont think i have any more questions... the answer appears to be, monitor refund.updated... and deal with it.

fading mist
#

Happy to help then

prisma cliff
#

not sure if this is the right place for suggestions... but it would seem to me this use case would be VERY common for any platform initiating refunds

#

while the "refund app fee" property is useful. it really isnt in my case, because I don't want to refund, unless the platform is actually getting a refund.

fading mist
#

Sorry, not sure I understand your feedback/suggestion here?

prisma cliff
#

ok... let me explain.

#

connected account charges $1000

#

platform charges $50 app fee

#

connceted account refunds 2 minutes later

#

refund turns into a reversal

#

now platform has $50, that it really only had to pay 30 cents for.

#

connected account expects $50 refund of app fee

#

on a "refund" (lets say multiple days later)... connected account is still on the hook for app fee, because stripe is not refunding those fees

#

so.. the only time I want to refund the app fee, is when the refund will turn into a reversal

#

so, i would like a property or something on the refund call.. that is like "refund app fee if reversal = true"

#

because. now I have to do extra work... I have to monitor the refund.updated event... and determine the status of the refund myself.. if its a not reversal( ie a normal refund days later maybe) , I can ignore the refunding of the app fee.. because the platform is on the hook for IC fees.... but if its a reversal, the platform can give whatever percentage of the IC fees back to the connected account, because the platform will not have to pay them.

#

or if that doesn't make sense... then just a 100% certain way to understand if I initiate a refund on a charge, if that refund will turn into a reversal. (without having to wait and monitor webhooks)

#

or if not 100% then a very high rate 99+

#

anwyays, i hope that is more clear... i'm going to sleep now, you can close this.

#

thank you!

fading mist
#

Ah I see thank you so much for this clear explanation, however this does seems very specific to your use case, and I'm afraid that you need to use webhooks in this case to orchestrate your workflow.