#josh.molloy - payout payments

1 messages · Page 1 of 1 (latest)

glacial wedge
#

Hey there! Yes, when using automatic payouts you can accomplish this using expansion ( https://stripe.com/docs/api/expanding_objects ) by expanding the source of each charge balance transaction associated with a given payout. This is shown in our use case example here:
https://stripe.com/docs/expand/use-cases#charges-in-payout

Stripe API reference – Expanding Responses – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

Expanding responses use cases

Learn how to leverage expand to perform common tasks

formal void
#

Awsome, thanks. I will give this a read.

glacial wedge
#

NP!

formal void
#

@glacial wedge, I was under the impression that charges and payment intents are different objects. For my use case, I will be generating payment intents, having the user go through the stripe elements payment form with an express connect account model (payee -> connected account living under my company's platform account). We plan to listen for payout.created events and then reach out to the balance transactions API to get the expanded source of the payout transaction using the payout id we get in the event body. The documentation keeps referring to charges, so I am confused as to whether I would receive info tied to the payment intent.

glacial wedge
#

Payment Intent's use charges internally still, and the balance transactions reference those charges

#

Connect makes this a little more complicated, but still possible

#

You need to make the request using the Stripe-Account header as the conencted account with the payout

#

then add a couple of layers to the expansion to traverse the destination charge transfer: expand[]=data.source.source_transfer.source_transaction

#

Which will get you the charge objects on your platform

#

These have a reference to the payment_intent if you need that, but expansion is limited to 4 layers so you cannot expand it further without another request

vernal forge
#

Sorry to interrupt. I work with Josh. Would it be possible to get the payment intent through a custom report? Or, would we need the connected account header information to traverse from payout -> originating charge -> payment intent? Or, would we need to make multiple requests to traverse this, still?

glacial wedge
#

The result I share would include the PI ID already -- if that's all you need it was already be there

#

If you need the object/details, you'd need another request

#

What do you mean by custom report?

vernal forge
#

If I'm not misunderstanding the documentation, Sigma provides a means to produce custom reports for the reporting API.

Sorry, I misread your last - I didn't realize the expand parameter would already produce the payment intent id.

lament scaffold
#

Hi @vernal forge 👋 I'm taking over for Synthrider. Give me just a minute to get up to speed

#

Would it be possible to get the payment intent through a custom report? Or, would we need the connected account header information to traverse from payout -> originating charge -> payment intent? Or, would we need to make multiple requests to traverse this, still?
Are these questions still outstanding?

vernal forge
#

It might help us make a decision on the best approach.

lament scaffold
#

Sigma is essentially a front-end that accepts SQL to produce reports with data from various objects (e.g. customers, subscriptions, charges, payouts, etc.) on your account.

#

Are you just trying to decide whether to use Sigma or use your own in-house reporting software by getting data via the API?

vernal forge
#

We're developing in-house means to resolve payouts to payment intents. We're looking for the quickest means to resolve a payout.created event to the originating payment intent(s). I was thinking that Sigma could be saved to be later retrieved via the report api - am I mistaken?

glacial wedge
#

Just before I step away, I think the expanded balance transaction results would get you what you need here, a list of payment intent IDs. If you need the details of those payments intents though they'd need to be retrieved separately (using the API). I'd suggest exploring that option first since it's an API request you can test, before going for a more complex solution.

vernal forge
#

Thanks @glacial wedge - I think what you've suggested should meet our needs.

#

It just seemed like a lot of expanding (overhead information), where a report might be leaner. When we only care about the payout.id -> payment_intent.id(s)

glacial wedge
#

Possibly, but I'd only expect that to be an issue if you were expecting many payments per payout. In that case, yes another approach might suit your needs better. Expansion is not particularly performant for long lists x deep expansion.

vernal forge
#

Good to know. I think it may be likely, since we handle rent collection. So, our connected accounts would likely have the bulk of their transactions on the first of the month, to be paid out when available.