Retrieving the transfer (tr_xxx) id from a source (py_xxx) for a Stripe Managed Account

[beNjiox]

I'm using Stripe Connect and I'm trying to get the transfer in which is included a payment

I have the payment_id (py_xxx), I'm looking for the transfer_id (tr_xxx). It is displayed on the Stripe Dashboard as shown in this screenshot http://cl.ly/3E0E2r1r0o2X

Looking at the network on the Stripe dashboard shows that the way to go would be to do that:

`Stripe::Charge.retrieve({ id: "py_17gQazAm2w0MZj3jE7v0TgOn", expand: ['balance_transaction.automatic_transfer'] }, { stripe_account: "acct_xxx" })`

But Stripe returns "This property cannot be expanded (balance_transaction.automatic_transfer)" (Using Rails SDK)

Doing `Stripe::Charge.retrieve({ id: "py_17gQazAm2w0MZj3jE7v0TgOn", expand: ['balance_transaction'] }, { stripe_account: "acct_17Zqv2Am2w0MZj3j" })` works but does not contain the information I need.

I insist on the fact that it works on Stripe Dashboard

Params of the request: http://cl.ly/3V2c3O2D081H

Response with the transfer_id I need highlighted: http://cl.ly/2V1d3U2L231a

Any idea? 

Thanks,

[Matthew Arkin]

Using the API you cannot go from charge or payment to the transfer, you can go from the transfer to the payment and if you need the charge / transfer linkage I suggest storing it in your database for easy lookup.

The way I handle it in my system is I listen for the transfer.created (or transfer.paid) webhook, then using the balance history [0] API, I pass the transfer ID which provides me the list of balance transactions that went into that transfer.

Then from the balance transaction objects I have a reference to the charge / payment id.

Matt

[0]: https://stripe.com/docs/api#balance_history

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[beNjiox]

Argh.

It's an issue in my case because I've to build a script to reconcile some payments. But we're talking 1000+ payments. I've to do that because of a mistake that's been done. I really need to get this information through an API call to fix my issue.

Am I in a big mess?

Thanks Matt,

[Matthew Arkin]

Instead of listening for the transfer webhook, you can just use the list transfers API [0]. Then pass each transfer through the balance history API as stated above and at the end you'd have a listing of every transfer to every payment. 

[0] https://stripe.com/docs/api#list_transfers

[beNjiox]

Yeah, ok. I was trying to avoid this solution.

I'm really curious, though. Clearly the API has a way to do that, as shown in my screenshots. There is the exact expand parameter I need.

Why can't I just use it? I don't see any reason. Is this just a limitation of the Rails SDK? 

It would make my life way easier right now :/

[Matthew Arkin]

The dashboard doesn't call directly to the API (you'd see the url of the request is not api.stripe.com but like dashboard.stripe.com).

The dashboard does have access to a few special apis (most notably the search API), my guess (given no knowledge of how the dashboard APIs work) would be that Stripe can't currently guarantee the usability of these API endpoints against all versions nor may the be performant  enough to handle API requests beyond the dashboard.

[beNjiox]

Oh ok. I didn't notice that indeed. 

Well, if a Stripe person sees this, now that you would have at least one happy developer to have such handy property from the live Stripe Api.

PS: As always, thanks for your reactivity and clear answers, Matt.

[Jamin Benjamin]

I went through this same scenario back when I was first integrating stripe.  I had LOTS of trouble trying to fit that square peg into the round hole and eventually went and asked Stripe about it.  They pretty much said what Matt has said...and because it was a key part of my design, it would be foolish to design around something like that.  Unsupported, could change at any moment...etc..

My problem sounds the same though.  I had inbound payments.  Each day the day's charges were transferred to my bank, and I needed my app to know when they had cleared so the funds could be split up.  I needed to know what charges were covered in said transfer.

Like Matt suggested, storing locally is a decent way to go.  I have a local Charge table, a local Transfer table, and the local StripeEvent table (log events so I don't process events twice).  

When my customer makes a payment, I hit Stripe and that is when I create the local Charge record.  That data has ChargeId from stripe.  Then, I listen to the transfer.paid event.  When a transfer.paid comes in, I store the Transfer locally.  So now I have a TransferId.  

Then comes the balance transactions...retrieve balance transactions, by type of Charge, and filter them to match the transferId (this is all still in the webhook parse).  This returns a list of all charges for that transfer.  Every item in this list will match an item in your local charge table (at least it better!) ... then I update Charges to save the transferId to each charge.  

Let me know if I can clarify any of this...I'm not great at explaining things at 1AM :) 

[JP Sugarbroad]

FYI going from automatic transfer to the payments involved *is* supported. Use /v1/balance/history?transfer=tr_xxx. Doing the reverse is not currently possible with a single call, although you could probably do it in multiple calls by searching for the proximate transfer.

[Michael Bianco]

I've run into this same situation, here's the snippet (inefficient, but works!) that I use to get around this issue: https://gist.github.com/iloveitaly/e7958e5f55136928f082

[Matthew Arkin]

Yeah that will do it, if you plan on doing a lot of the look up especially if they go far back into your transfer history, just iterating through every transfer and balance transaction and storing the linkage as a local cache will end up being more efficient then doing multiple lookups / api calls per charge. 

--