melbourne

[zinc wraith]

There's unfortunately not a great way to do this. The closest you can get is balance.available, which updates you when funds are available for payout. https://stripe.com/docs/api/events/types#event_types-balance.available This will give you a balance object, which, as you can see, doesn't contain individual info about each payment intent: https://stripe.com/docs/api/balance/balance_object. You could then list balance transactions: https://stripe.com/docs/api/balance_transactions/list. You can inspect the balance transactions available_on date to find the ones with the timestamp set to that same day: https://stripe.com/docs/api/balance_transactions/object#balance_transaction_object-available_on. Then you could list charges and try to find ones with the matching balance transaction: https://stripe.com/docs/api/charges/object#charge_object-balance_transaction

This flow isn't great though because there's not a way to list balance transactions by available_on (you'd need to list all and then filter them by that yourself). Similarly, there's not a way to list charges by balance_transaction (also would need to filter that out yourself).

I can suggest a slightly better approach. One minute

As you collect charges, it would be better if you keep track of each one's balance transaction. So, when a payment intent succeeds, I recommend looking at the associated charge object: https://stripe.com/docs/api/payment_intents/object#payment_intent_object-latest_charge. Then, inspect its balance transaction: https://stripe.com/docs/api/charges/object#charge_object-balance_transaction. At this point I recommend storing in your database the payment intent id, charge id, balance transaction id, and the available_on date. That way you have a complete record on your side of when you expect each payment intent to hit your balance. That way, when you do get the balance.available webhook event, you can check your database to match the right payment intent to that event. This isn't the smoothest flow either but it's better than that first one I outlined.

[cedar stratus]

Thank you, that's all helpful. Is the available_on more or less guaranteed then? I kind of thought it was just an estimation.

Your second suggested workflow sounds perfect for us if available_on is a reliable way to know when the balance will become available. We're already storing the 3 IDs (PI/Charge/BalanceTransaction) and accessing the BalanceTransaction to get the net amount post-fees so it may be as easy as also taking the available_on date at that point.

[zinc wraith]

AFAIK it's accurate

Let me double check with a colleague though

Yeah my colleagued echoed the same that it's sufficient for reconciliation

Should be accurate

[cedar stratus]

Excellent. We'll give it a try. If it works reliably then what I thought was going to be a fairly big change will be like 2 lines of code. Thank you very much for your help and have a nice day.