mitcheroo

[stable flare]

Hello

We don't really know much about the Dashboard here as we focus on the API. You will be better off reporting this to our Support team: https://support.stripe.com/contact/login

[slim kernel]

Hi there. Actually, my question is driven by an API issue. I can't tie a payout transaction (a dispute withdrawal) back to a dispute, because it looks like the transaction was created as a Balance Transfer, not a Dispute Withdrawal like I usually see. I am not sure how to get the details of the Balance Transfer via the API, was hoping to see details via the dashboard. Can you help?

If so, the original charge ID is ch_3M6FmaDOwYADn7R82BNnVgu9

[stable flare]

Ah okay thanks for explaining

Let me take a look

So I assume you mean "balance transaction" when you say "balance transfer"

[slim kernel]

Yes, I'm sure you're right. The Type column in the Transactions list on the dashboard is blank for that transaction, and its ID begins with btri_

[stable flare]

Hmm we don't have any IDs that start with btri_ afaik

Balance Transactions are txn_

[slim kernel]

This is in the Description column in the Transactions list: btri_1MHgTtDOwYADn7R8We18HnFl

[stable flare]

Ahhhh

Thank you

That is an inbound balance transfer

So yes that is different from balance transaction

And i forgot that it does indeed start with btri

Okay I need to step away but my colleague @rugged wigeon is going to step in and take a look

[slim kernel]

Ok, thanks for your help so far

[rugged wigeon]

👋

When you list all Balance Transactions via the API, do you see this btri_ object show up?

[slim kernel]

Checking, it'll take me a bit

[slim kernel]

Written in C#: calling the BalanceTransactionService with date range filtering of between 12/20/2022 and 12/22/2022, all I see is txn_ transactions. Does that answer your question? Anything else you want me to try?

[rugged wigeon]

Do you see multiple objects whose source is the Charge you listed above? If not, are there any with the source as this btri_ object ID?

[slim kernel]

Looking

Is there an API call that will return all objects for a source?

I'm calling BalanceTransactionService.List and nothing for that source is being returned

[rugged wigeon]

Hmmm, I don't think we surface those objects then. Where did you get the btri_ object ID from in the first place? Maybe we can work backwards from there to identify a workaround

[slim kernel]

On the dashboard. Check out payout
po_1MHgTvDOwYADn7R8iWqrcrox

What happened was: when I query the API to get the transactions that are a part of a payout, I don't get a transaction back for that dispute. So I can't reconcile our payout records with Stripe's

[rugged wigeon]

Apologies for the wait. Taking a look now

[slim kernel]

No worries, I'm not in a hurry

Got plenty to do here 🙂

So I pull the transactions for the payout and I DO get a balance transaction

[rugged wigeon]

I don't know if this helps or not, but the payout reconciliation report has that transaction in it, but not with the Payout, so I don't think it's possible to associate it with a payout. That being said, it does give a Balance Transaction with a btr_ ID

https://dashboard.stripe.com/reports/reconciliation?startDate=2022-12-01&endDate=2022-12-31&currency=usd&templateType=merchant&timezone=America%2FNew_York

Ah, we may have done the same thing just now

[slim kernel]

How can I use the btr_ to tie to the original charge?

[rugged wigeon]

Wait, when you say "So I pull the transactions for the payout and I DO get a balance transaction" what do you mean? Where did you pull from?

You can't, but I think the txn_ object that it's associated with will have the Charge ID as its source field

[slim kernel]

BalanceTransactionService (C#)

source is null

[rugged wigeon]

That's.... frustrating

[slim kernel]

Still looking

[rugged wigeon]

I think because this transaction effectively represents "Transferring funds from future refunds or disputes to cover a negative Stripe balance." it doesn't map to a specific Charge.

[slim kernel]

Yea, hm. Will the BalanceTransactionService accept a btr_ transaction?

Trying that

[rugged wigeon]

I don't think so. I think it has to be a txn_

[slim kernel]

Yep - "No such balance transaction"

[rugged wigeon]

So when you pass in the Balance Transaction ID for the btr_ (which is txn_1MHgTuDOwYADn7R8KHrpFOO2) to BalanceTransactionService is there anything helpful at all in the payload?

[slim kernel]

I think that's for a different transaction, but no, I don't see anything I can use to tie back to the original charge. Or dispute

[rugged wigeon]

Whooops sorry, it's this one --> txn_1MHgTuDOwYADn7R8KHrpFOO2

[slim kernel]

No, looks like the only other ID included is the btr_ ID

btr_1MHgTtDOwYADn7R8iFiqSYuN

[rugged wigeon]

Ah, alright. Okay yeah, in that case I don't think there's a way to trace back to the original Charge from the Balance Transfer object. I hate to give that answer, but I'm at a loss for other workarounds.

In the end, I don't think that transaction is important for reconciliation. Was this workflow intended to aid in closing your books? If not, can you elaborate on the problem you were hoping to solve by tying these two things together?

[slim kernel]

Sure. We consume transaction webhooks to record the individual transactions, then we associate those transactions with a payout when a payout webhook is received

Which we then tie to our bank statement

We also have processes that record transactions synchronously instead of by consuming webhook events, so it's important to us to make sure all transactions are tied to a payout, that nothing slips through the cracks or is inadvertently created

Reread your question - I suppose that's a long answer for - yes, we're closing our books 🙂

Monthly

[rugged wigeon]

Just want to pop-in and let you know that I'm trying to figure out a good course of action and provide a better explanation for you on what to do with these btri_ objects. I want to say

"you can ignore them because they only represent money moving from your top-up balance to cover refunds and disputes (which you will already have information about for closing your books)"

But I'm not confident enough in that answer to say with certainty. Will work a bit more on this in the background and circle back once I've dug a bit more

[slim kernel]

Ok, thanks. If there were some other transaction in the list of payout transactions that corresponded to the dispute, I would agree. Looking forward to seeing what you come up with

[rugged wigeon]

Okay, so here's what I found. The btri_ transaction represents the event where funds are moved from your account's pre-funding balance (see "Future refunds or disputes or negative balance" at the bottom of the page here: https://dashboard.stripe.com/balance/overview). This is the flow for refunds as an example:

your Stripe pre-funding balance --> your Stripe balance --> Stripe --> Customer's issuing bank

So each btri_ just represents the part of the transaction's lifecycle where your balance is either (a) used to cover a refund or a dispute, or (b) absorbed from your pre-funding balance and added to a payout to your bank. Lastly, this money was always in your Stripe balance and either resulted in a Payout, Refund, or Dispute. So with that in mind, as long as you are accounting for Payouts, Refunds, and Disputes in your reconciliation, you can safely ignore these btri_ transactions.

There is unfortunately no way to associate btri_ objects with a payout at this time, as Stripe just considers them part of your balance.

Correction on the last sentence in the above message:

There is unfortunately no way to associate btri_ objects with a payout at this time, as none of the object associations are being surfaced to Stripe users in any meaningful way

[slim kernel]

So using this dispute as an example: if I have a net 34.81 dispute withdrawal recorded in our system, and there is no dispute transaction recorded as part of the payout, I'm kinda stuck. Unless I want to take the rather imprecise approach and assume that the 34.81 balance transfer transaction is associated with the dispute, and hope I'm correct. Is that accurate?

I just want to make sure there are no other alternatives

Because I'm hoping this is a rare occurrence. But if that changes, and it becomes much more frequent, we may have a huge headache to deal with

[rugged wigeon]

If I understand correctly, even though it says "Transferring funds from future refunds or disputes to cover a negative Stripe balance." all that happened with this particular btri_ is it was absorbed into your balance. If there were a refund or dispute that it was used to cover, you should already be tracking that, as I assume you need all refunds and disputes to close your books.

I don't think that this btri_ was used to cover a dispute or refund though. I think it was just absorbed into your regular balance in order to be sent with that payout, either (a) because it was a lingering pre-fund balance that didn't need to be used for refunds, disputes, or a negative balance, or (b) because you would have had a negative balance after the payout was created.

As an aside I'm going to surface this whole conversation to the product team with a call to action, as I think that having these transactions show up and point nowhere is not an ideal experience

[slim kernel]

Agreed, thanks.

You're correct, we're tracking the refund or dispute. But when a deposit arrives at our bank, representing what could be thousands of transactions (our largest payout last month contained nearly 6,300 transactions), we need a way to associate the deposit with individual transactions. Just to make sure everything reconciles.

So if the btri_ is just a transfer, does that mean there is a transaction in a payout somewhere that corresponds to this dispute?

I'm guessing No, because one really weird thing I noticed is that clicking the payment transaction in the dashboard shows no Payout For Dispute in the Connections section
https://dashboard.stripe.com/payments/pi_3M6FmaDOwYADn7R82sdU2Z5j

[rugged wigeon]

So if the btri_ is just a transfer, does that mean there is a transaction in a payout somewhere that corresponds to this dispute?
Yes, but only if the btri_ is actually representing a dispute. Remember what I said earlier about how a btri_ transaction can represent a refund, dispute, or a balance to balance transfer used to cover a negative balance? That means it could be any one of those things and tracking it is not necessary, because it will be accounted for elsewhere in the balance. It's essentially a Stripe-balance to Stripe-balance transfer and should be ignored entirely

This Payment Intent (pi_3M6FmaDOwYADn7R82sdU2Z5j) seems unrelated unless I'm missing something obvious

All of this boils down to:

btri_ represents a Stripe-balance to Stripe-balance transfer and should be ignored entirely in your accounting

[slim kernel]

Yes, but my issue is that it isn't accounted for anywhere else; the btri_ is the only line item that I can tie to. Correct me if I'm wrong.

Looking at the payment intent...

I see the payment intent, not sure what to do with it

[rugged wigeon]

Yes, but my issue is that it isn't accounted for anywhere else; the btri_ is the only line item that I can tie to. Correct me if I'm wrong.
It is part of your overall balance already and cannot be accounted for anywhere else. It's literally just a transaction Stripe uses internally in order to make sure there are funds available to cover refunds, disputes, and negative balances. It has nothing to do with any transaction you created.

I see the payment intent, not sure what to do with it
You sent me that Payment Intent, so I was just saying I don't know why you sent it to me. Is it relevant to this conversation?

[slim kernel]

Oh! Yes, look at the Connections section. Every other dispute I've seen has a Payout For Dispute. That one doesn't.

[slim kernel]

Then how can I confirm that a payout contains a withdrawal for a dispute?

[rugged wigeon]

As far as I can tell, it does. That's what the po_ object is

[slim kernel]

That's the payout for the original charge, not the dispute. Here's the Connections section for the disputed December charge:

As always, correct me if I'm wrong

[rugged wigeon]

If I had to guess, I would say that it will be included in a future payout, since the Dispute was only settled 3 or 4 business days ago. We've gotten a bit into the weeds here, as this channel isn't really intended to handle reporting questions or Dashboard behavior, so I would recommend directing follow-up questions about Disputes to our support folks, as they can escalate to Dispute specialists who have way more context than I do: https://support.stripe.com/contact/email

I wanted to make sure you had a solid answer for the original question though, so hopefully that part is fully wrapped up at least

[slim kernel]

Thanks, I REALLY appreciate your time on this