#chukd-payout-transactions

1 messages · Page 1 of 1 (latest)

compact cairn
#

Have you considered using Sigma for this? You'd be able to reconcile what's in a payout once the data is in sigma and run daily reconciliations for examples with one SQL query

#

But other than that, if you want to go back up to what is inside the platform, from the connected account's payouts then no

#

expanding data.source.source_transfer is the better option

#

You could alternatively, after each Transfer creation, go and update the associated py_123 in the connected account to set the right metadata on that py_123

topaz pilot
#

Can you ellaborate a little on updating the transfer py_123?

#

I assume py_123 is the destination payment id?

#

What do you mean by update? And if I can modify it, would that modified string be located in the payout.created webhook?

compact cairn
#

Transfer tr_123 -> destination_payment -> Charge py_123
That's the link yes, so you can call https://stripe.com/docs/api/charges/update after that Transfer creation and update the Charge on the connected account and set the metadata you want

topaz pilot
#

would I be able to associate that metadata with what I receive in the payout.created webhook?

compact cairn
#

I don't know what those words mean unfortunately

#

When you get the payout.created event, it can contain 1 charge, or 10, or 10M, so you can't have information in that event, you have to go look at what is inside that Payout with the List Balance Transaction

topaz pilot
#

Right, I'm double, triple, quadruple checking to see if there is another way for me to associate a payout with its transfers without List Balance Transaction or a Report or Sigma. It seems like there's enough data I can save from a Transfer and a Payout that there should be a way to link these guys together without a heavy query run millions of times potentially.

compact cairn
#

yeah I'm sorry I really don't understand what you mean

#

why would you run things millions of times, you don't have millions of Payouts right? And you'd run it once per Payout and it only looks at the BTs in that Payout so you won't do billions of calls a day

topaz pilot
#

ya I do, potentially. I could in fact have millions of customers receiving payouts every month. So, under that scenario, I would have to run List Balance Transaction millions of times.

#

not billions, but if I have say 1 million customers all receiving payouts on the 1st of each month, Stripe is going to send me 1 million payout.created webhooks all on the 1st or around the 1st. I would have to run List Balance Transaction for each payout.

compact cairn
#

Sure, but at that point, if you have 1M customers all having payouts monthly, you likely have billions of transactions daily like Amazon and such, and you have an infrastructure where doing a few millions BT lists a day is nothing

#

Overall though the Sigma approach would work, and updating the metadata on the connected account's py_123 also should work for CSV reconciliation.
But my advice is to use the List BT API for now, you can always revisit as you grow.

topaz pilot
#

ok thanks for the advice

#

do you have any link for the Sigma method I would use or should I just go to the Sigma page and start looking at the documentation?

compact cairn
#

mostly the latter, it's a SQL database, so there are tables for all objects (transfers, charges, connected accounts, etc.) and you can run queries to reconcile the data

#

but really, this makes sense when you have a lot of users, not when you build the app today, you're going to waste a lot of time optimizing code you might never need to change

topaz pilot
#

gotcha!

#

one more question. Will I always receive a payout.created, even if the payout fails at some point? I'm aware I can receive webhooks out of order, I'd just like to know if I will always receive the payout.created even if the payout fails?

cursive stone