#elppypy_api

1 messages ¡ Page 1 of 1 (latest)

paper aspenBOT
#

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

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

young crow
#

Hello there

#

There is no way through the API to see the origin of the request itself

primal bronze
#

How can I know which id belongs to which application?

young crow
#

If you expand the application you will see info about the application's name.

#

Otherwise you can map this on your side -- the ID won't change.

primal bronze
#

Sorry, where exactly? I can't find this in the dashboard

paper aspenBOT
primal bronze
#

Oh, I just found out there's the "--expand" flag that can give me the name of the application

#

But there's a problem, it's a single charge but multiple refund requests

#

I'd need an "application" field or similar referring to the refund

young crow
#

Hmm yeah application isn't tied to Refunds directly. Are you saying that multiple different platforms would issue partial refunds for the same Charge?

primal bronze
#

It's not partial refunds, but yes there are multiple platforms issuing refunds

#

For specific situations I need to allow one or the other, therefore the need to identify which platform requested the refund

paper aspenBOT
main sable
#

fyi i am taking over this thread! gimme just a bit to catch up

primal bronze
#

All right

main sable
#

are you handling this with webhook events (e.g. listening to the charge.refunded event)?

primal bronze
#

yes we are

#

But the event payload does not contain this information either

main sable
#

gotcha. gimme a bit to dig into this for you

#

one other question, so is it possible that an application other than the one that created the charge could issue the refund?

primal bronze
#

Yes

#

Recurly creates the charge, Chargeblast can issue a refund for it. That's what I'm trying to detect, whether the refund was issued by Chargeblast or Recurly

main sable
#

hmmm, i am not seeing any quick solutions here. as bismarck noted the refund doesn't have its own application field.

primal bronze
#

This information is visible in the dashboard logs, but not through the API?

main sable
#

the dashboard pretty frequently has special code paths or other logic that differs from the API

#

i'm gonna check with my colleagues real quick to see if they've run into this before. gimme a bit.

#

ok yeah, i don't think that this information is currently available anywhere via the API unfortunately. i can pass this along to our product team though to see if we can get this information added to the refund object directly, although as with all product feedback i can't guarantee that it will be implemented

#

can you share more context on why refunds could be issued by different applications than the one which created the charge? i think that is a pretty rare case which is why it's not available via the API currently, and understanding your use case better will help inform my feedback to the team