#gdog_api

1 messages · Page 1 of 1 (latest)

obtuse finchBOT
#

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

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

mortal swan
#

hey there 👋 metadata doesn't carry over between objects in Stripe generally

for payouts in particular, this is intended because a payout can contain multiple transactions

#

are you creating a payout manually for each individual transfer?

tribal bobcat
#

The only object we create (as far as I can tell) is the transfer to the connected account. We get back a destination_payment (payment not payout?) id which is the record the merchant can see on their summary and export.

Ideally, we want these to be matchable to our merchant-facing reporting, and the preferred solution is to include one of our identifiers somehow, if possible

mortal swan
#

yeah it's possible for sure, but it requires some development work to set up since Stripe doesn't carry over the metadata automatically

tribal bobcat
#

Fine by me - I'm happy to push the information to that record if I can work out what the endpoint is

mortal swan
#

this updates the Payment/Charge in the connected account (i.e. the py_123 object)

#

is that what you use to build out your merchant-facing reporting?

tribal bobcat
#

So, the ask from the business is that when the merchant exports their records from stripe it has our order identifier on it. Retrieving the py_ identifier and appending it on our end would be trivial.

mortal swan
#

cool! if the merchant exports their records from the 'Payments' page in the Stripe dashboard, they're exporting the Charge (py_) objects

#

so if you implement this metadata update flow, the metadata would be included in this export

tribal bobcat
#

Okay, so everywhere the API documentation mentions charge objects and prefixes them with ch_ I could use the payment identifier? So, charge update API using the identifier received when created the transfer and this should be visible

#

well, I guess the py_ identifier IS a charge identifier

mortal swan
#

yes exactly - it's a bit of a relic of our older API structure, where we also had Payment objects, hence the different prefix

but in effect a py_ object is exactly the same as a ch_ object in terms of API behaviour

tribal bobcat
#

Lovely, thank you! I was trying to find references to the py_ identifier and coming up with nothing.

#

Might mean that we need to rework how the transfers are made if it is a relic.

mortal swan
#

oh the behaviour and payment flow of creating transfers is fully up-to-date and still recommended

#

it's just the py_ prefix that stems from the older structure, so that's purely on our side

tribal bobcat
#

Got it. Thank you!

mortal swan
#

any time!

obtuse finchBOT
tribal bobcat
#

So, the charge update API returns no such charge with a py_ identifier - have I misunderstood the approach here, and I need to retreive the associated charge somehow?

ocean anchor
#

👋 Hi there! I'm taking over for my colleague. Let me take a look

#

Does the py_ belong to your platform, or the connected account, and so you need to specify the Stripe-Account header?

#

Do you have a request ID (req_) that you can share?

tribal bobcat
#

probably the connected account
req_J17xy7fe5wo7SP

ocean anchor
tribal bobcat
#

Perfect, that works. Thank you very much!