#NewtReyes-balancetransactions

1 messages · Page 1 of 1 (latest)

polar tusk
quaint surge
#

Hi, @polar tusk 🙂

polar tusk
#

Hello!

#

Are you using manual or automatic payouts?

quaint surge
#

automatic

#

Can you limit the returned list to the ones that have not been paid out yet?

#

If not, would it be enough to retrieve the balance transactions and add them up to the point where they match with what you receive from the https://api.stripe.com/v1/balance api endpoint?

polar tusk
#

Hmm so there doesn't really seem to be an easy way to go from balance transaction -> payout (the other way around is easy)

#

And there isn't a way to limit the returned balance transactions to be the ones that haven't been paid out yet

#

There are some workarounds you could look into, give me a minute to type them out:

#

Okay I was typing out some things, but this one is probable the best:

  • You can check the available_on for the Balance Transaction and compare it to the most recently created payout's arrival_date
quaint surge
#

Interesting

#

Sorry for the delayed response

#

And what about retrieving the last payout, then retrieving the most recent balance transaction from that payout (that is not the payout balance transaction) and the listing all balance transactions up to that one?

#

could that work @gusty cobalt ?

gusty cobalt
#

Hello 👋 catching up

quaint surge
#

Thank you!!!

gusty cobalt
#

Quick question: how would you be retrieving the most recent balance transaction that is not the payout balance transaction?

gusty cobalt
#

Still looking in to this.

#

And out of curiosity, do you have thoughts or concerns on the other workaround that karbi proposed?

You can check the available_on for the Balance Transaction and compare it to the most recently created payout's arrival_date

#

And to be clear on your workaround. You mean to take the most recent payout and list all Balance Transactions ending_before its created timestamp?

quaint surge
#

You can check the available_on for the Balance Transaction and compare it to the most recently created payout's arrival_date
Ahhhhh

#

I think I wasn't fully getting what he was proposing

#

Interesting

#

So, let me see if I am correctly getting it now

#

Take the last payout arrival_date, then retrieve all balance transactions that have and arrival date that is after the last payout arrival date.

#

Now, question: if I retrieve the balance transactions using https://api.stripe.com/v1/balance_transactions, can I page until I get to the first one that has an arrival date that matches with the one of the latest payout, @gusty cobalt ?

gusty cobalt
#

Your understanding is correct.

#

And you should be able to page through. What are your concerns with paging?

quaint surge
#

None

#

I mean, my only worry is that the balance transactions may not be fully ordered by arrival date.

low reef
#

Hello! I'm taking over for @gusty cobalt, let me get caught up...

#

When listing Balance Transactions:

The transactions are returned in sorted order, with the most recent transactions appearing first.

Meaning the most recently created Balance Transaction will be at the top of the list. The order has nothing to do with their available_on property.

#

Going back to your original question:

how do you find out if a specific Balance Transaction has already been included in a payout

Are you asking about a specific Payout (as in "is this Balance Transaction in this specific Payout?") or are you asking more generally (as in "has this Balance Transaction been paid out?")?

quaint surge
#

The latter

#

Here's what we are trying to accomplish

#

We are retrieving the Balance for a specific Stripe Connect Custom Account.

#

We want to know which balance transactions add up to the amount from that balance

low reef
#

Meaning the balance that has not been paid out yet?

quaint surge
#

Yes

#

Exactly that

#

Ex.

#

This is the balance for a specific account

#

We are showing the following to our clients:

#

Pending + Available Balance add up to the amount we are showing.

#

We want to be able to show them which balance transactions add up to that USD Balance we are showing there.

#

In my head, the best way was to get all the balance transactions after the last balance transaction that was included in the last payout. Those should add up to that value.

#

Is that correct?

#

But then we got the suggestion of using arrival date.

opaque steeple
#

@quaint surge I'll start by saying something you won't like: do not try do this, you will regret it, do not try to do some magic guessing, you will regret it, it's near impossible

#

The way to approach this is to reverse the logic. Assume BTs are never paid until they get paid out. And you know that by checking what's in a Payout.
So track every BT in your database if you want/need to, and treat them as "pending" until you see them part of a payout when you et the payout.created event

quaint surge
#

Interesting

#

So, let's say I want to check if a BT has been paid out. Do I have to check all payouts to find if it was included in one of them?

#

Isn't it the case that all BT after the last BT in the last payout haven't been paid out yet?

#

Is that assumption "magic guessing"?

#

@opaque steeple ?

#

I thought the algorithm deciding which BT to include in a payout was a sequential one. Ex. If all transaction from Oct 1st were included in the last payout (until BT "txn_xxx"), then all transactions from Oct 2nd and on will be pending (starting from the one right after BT "txn_xxx").

opaque steeple
#

the channel is busy, please bear with me :p

#

Isn't it the case that all BT after the last BT in the last payout haven't been paid out yet?
No. Card payments settle in 2 days, ACH payments settle in 7 days. So they can be intertwined

#

So, let's say I want to check if a BT has been paid out. Do I have to check all payouts to find if it was included in one of them?
Yes, though it's easier to track this on an ongoing basis. Every time you get a payout.created event, you list the BTs that make up this Payout and you mark them as associated with that payout. So that in 2 weeks when you need to know if txn_1233456 is paid out, your database tells you that

quaint surge
#

But the BT is created when the payment is settled, right?

opaque steeple
#

it definitely is not

#

try it quickly, the BT is created when the charge is created

quaint surge
#

Ahhhhh

#

but it is not paid out until it is settled

opaque steeple
#

correct

quaint surge
#

Yes, though it's easier to track this on an ongoing basis. Every time you get a payout.created event, you list the BTs that make up this Payout and you mark them as associated with that payout. So that in 2 weeks when you need to know if txn_1233456 is paid out, your database tells you that

Right. Now, what happens if our database get's out of sync?

opaque steeple
#

so Monday you create a Charge with txn_123, that will settle/be available on Wednesday (2 days later). On Tuesday we create a Payout (sent a day before) and that includes txn_123

#

Why would your database get out of sync?

quaint surge
#

Because "Murphy's Law"

#

🙂

#

So, we wanted to create a Resync engine by using Payouts and Balance Transactions

#

That may still be possible

#

but we will need to fully sync first, make sure all paid out transactions are marked as paid out in the system and then add up the rest.

#

Sorry. It's getting late here and I may be mixing stuff up.

#

Let's not get in the the Resync engine.

#

So, we can't know by means of the API which BT add up to the Balance we retrieve from the Balance API endpoint unless we calculate that on our side.

opaque steeple
quaint surge
#

Can you explain to me what available / pending mean in this case?

#

does pending mean "still not settled" while available mean "settled"?

#

is that it?

opaque steeple
#

yep!

quaint surge
#

got it

#

thank you for the thorough explanation