#VoodooPrawn

1 messages · Page 1 of 1 (latest)

whole viperBOT
upbeat frigate
gritty burrow
#

Hmmm

#

We have it set up this way currently

#

but it's taking a lot of time (many requests) to pull out ALL balance tx per payout and wondered if it would be quicker if we grabbed all balance tx between a suitable range and match them to payouts we've already grabbed

#

but if there is no way to work out the payout for a given balance tx, I'm not sure that's possible

upbeat frigate
#

it's not

#

what you do is you listen to payout.created webhook events, do the process described at https://stripe.com/docs/expand/use-cases#charges-in-payout to reconcile that payout, and you can for example update your database or add metadata to objects like Charges so you can directly know they were in a specific payout. You can't go the other way directly, you have to reconcile the Payout.

gritty burrow
#

that's an interesting idea

#

listen to payout.created and set the payout per-payment within our DB

#

then when we run this monster report, we don't need to make anywhere near as many calls to Stripe to get data

#

just to confirm, before I go in this direction

#

we are using Connect with Express accounts

#

we have some international clients using direct OBO and UK clients using destination charges (I think that's correct?)

#

for international, we use stripe_account header

#

for UK we use transfer_data.destination

upbeat frigate
#

I see

gritty burrow
#

when we store the payment our side, we store the pi_ we get back when it's created

#

so my question is, if we listen to the payout.created event (presumably for both the Account and Connect webhook) are we able to match up pi_ to the payout that has just been created?

upbeat frigate
#

well it depends.

if it's about the accounts where you're doing Direct Charges(international using Stripe-Account as you say), you get an event to your Connect endpoint. The po_xxx object and the BTs returned and the linked Charges and PaymentIntents are all existing on the connected account.

If it's about the accounts where you're doing Destination Charges(transfer_data), then there's two Payouts really. There's a Payout on your platform(sent to your non-Connect endpoint) which reconciles to the PaymentIntent(the portion of it that you did not transfer). There's a Payout on the connected account(sent to your Connect endpoint) which reconciles to the Transfer, and you can also work back to the PaymentIntent. The link I posted above describes how you work backwards in that case.

gritty burrow
#

understood, so both the ones we need will come down the Connect webhook

#

(to give you some context, we've been asked to create a report where we export payments AND the payout date, ETA etc)

#

but I think this would be a much better way of doing it

#

So we listen for payout.created, take that single payout and find all payments our side that include it (which will have to be done slightly differently depending on if it's a direct or a destination), then we store the payout info against each payment our side, so when we run the report, we don't even need to hit Stripe

#

genius

#

thanks so much, that's a great approach