#mtoledo2_api
somber micaBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1338903501782122506
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- mtoledo2_connect-application-fees, 22 hours ago, 10 messages
- mtoledo2_api, 5 days ago, 3 messages
robust forge
Hello good question. And you are looking for the py_ objects that exist on the connected account itself? Also it sounds like you are using either our destination charges flow or separate charges and transfers correct?
wary oxide
yep looking for the py_ objects on the connected account
using destination flow at the moment
Finding the py_ id via report is straightforward but all the details appear to be a bit harder to get to then link on our account
robust forge
One way to get this info would be to expand source_transfer.source_transaction.payment_intent on the charge objects when listing them. source_transfer will have the ID of the transfer object that is on your platform account, and anything else that you expand off of that property will also be info from your platform account's related objects
https://docs.stripe.com/api/charges/object#charge_object-source_transfer
wary oxide
Interesting. Haven't tried that
let me give that a go
thanks!
Ok that doesn't appear to work in my use case because we use multicapture in some scenarios so source_transfer will actually be null
robust forge
Oh wow, I will have to file something about that. I am very surprised that that is how that edge case works.
Looking into whether there is another way to get this info
Can you send me the ID of a charge that was created that way where the source transaction is null?
wary oxide
ch_3QgpGNDMNOMDEQIU24swk4JJ
Yeah we adopted multicapture because works great for certain use cases but reporting has turned out to be an issue. I've been able to marry it in some cases but having that payouts API would be very helpful because I could then get the tranfer object and then link via transfer group
maybe I'm missing something to make my life easier
robust forge
Still looking in to this. I do see that we call out that we don't support this field for separate charges and transfers flows, so it looks like we may not have great support for this combination either.
https://docs.stripe.com/payments/multicapture?platform=web&ui=stripe-hosted#availability
Actually wait, to double check, is there also a py_ object on the connected account that represents funds from that charge? And do you know if that us automatically created when the later captures happen?
wary oxide
yes those automatically get created when the captures happen
basically on our end it's the same payment intent/charge that amount_captured gets updated and for the connected account a new payment gets created every time
so does move from 1 to many which is why I'm assuming support isn't too great as breaks a lot of assumptions
somber micaBOT
hardy onyx
Hi hi! I’m going to be jumping in here; give me a moment to read back.
Can you re-summarize the issue for me? I'm not quite clear on what's going on.
wary oxide
Yep no problem
so looking for a way to query the charge object API but not the one that corresponds to the platform account but the connected account
so py_
hardy onyx
You want to retrieve the py_?
wary oxide
that's the immediate ask. But at a higher level I leverage multi capture and am trying to marry the payments py_ back to the charges/payment intents that happen on the platform account
And my thinking of how to do this is through grabbing the payment object and then it's corresponding transfer group and using that to marry the transfer group on the charge that occured on the platform account
hardy onyx
What information are you starting with?
wary oxide
starting with the connected account itemized balance change report
Connected_account_itemized_balance_change_from_activity_acct_1Q3nMoD043DMGRkh_USD_2024 report that looks like the following
would later like to automate this but want to first do this manual and see what steps are required
wary oxide
wary oxide
txn_1QZPb0D043DMGRkhc2SS8O6i
hardy onyx
Ok cool.
So you want to eventually eliminate this report from <process-step-at-your-org>; what does that process do?
wary oxide
what I'd like to do is basically marry platform data with connected account data and additional metadata that stripe doesn't know about. Like for example this charge belongs to this order so then can the connected account then attribute back this specific payment belongs to this order
hardy onyx
Do you not know that at the time of the Charge?
Sorry, I mean when the charge is created?
wary oxide
some data yes but other data we don't know until capture time since we're using multicapture.
The exact use case is this order consists of 3 items. 1 item gets shipped and we capture the amount for that and that has it's own shipping label and also it's own payment object on the connected account but there is still only 1 charge object on the platform side
hardy onyx
Gotcha.
Ok so you want to use the response from a partial capture to find the associated py_ right?
wary oxide
Correct, that'd be awesome
Open to another way of doing so if it involves a couple of requests but if this can figured out from a partial capture response that'd be the best case scenario
hardy onyx
Just looking at the resulting object and trying to use my brain.
wary oxide
yep if there's anything I can do to help let me know
wary oxide
As I was digging I found this field in one of the payloads.
use_single_bt_partial_capture_behavior and it was set to false
Anything there that might help simplify things?
hardy onyx
Lots going on, I promise I didn't forget.
hardy onyx
I was also in a meeting in addition to the handful of convos going on; I'm out of the meeting now. I think you might just need to do some expand ing but I'm still digging.
wary oxide
ok sounds good
hardy onyx
This is the weapon, I'm just working on findng the exact move: https://docs.stripe.com/expand
somber micaBOT
wary oxide
sounds good. Let me know if there are any questions
somber micaBOT
regal notch
fyi there are a lot of open threads so i might be a little slow
wary oxide
ok no worries
regal notch
ok i'm at least caught up on the problem statement, let me see if i can figure out how to get what you're looking for
wary oxide
ok perfect
regal notch
yeah i'm not finding an obvious way to navigate to the py_ here either. i might need to set up a test on my side to experiment with a couple of things
wary oxide
ok let me know if you need any help to reproduce
somber micaBOT
visual vigil
👋 taking over as solanum needs to step away soon
visual vigil
py_ on the connected account typically maps to destination_payment under transfer object created on the platform - https://docs.stripe.com/api/transfers/object#transfer_object-destination_payment
Have you been able to get to the transfer object? I haven't read through the whole context in the thread so just to clarify, are you using destination charges or separate charges & transfers?
Looks like you're creating destination charges
wary oxide
yep creating destination charges
visual vigil
Gotcha. I see you're tried using source_transfer parameter already. Have you tried expanding transfer parameter on the charge and see if you can find the py_ under destination_payment ?
wary oxide
let me give that a try
wary oxide
Ok I don't see a transfer object attached to the charges
example charge ch_3QYufNDMNOMDEQIU0tOEE69y
visual vigil
Hmm I'm not seeing the transfer that was associated with this payment
wary oxide
so this is the py_ object on the connected account py_1QZPb0D043DMGRkhvuTlukO0
from there I found the transfer group which is group_pi_3QYufNDMNOMDEQIU05qOtbQk
and that transfer group gave me that charge ch_3QYufNDMNOMDEQIU0tOEE69y
visual vigil
Yeah as far as I can tell, the transfer field should be populated under the charge object - https://docs.stripe.com/payments/multicapture?platform=web&ui=stripe-hosted#charge.updated
wary oxide
yeah if that were the case then I think that solves all my problems
visual vigil
Oh I think that's only true if you specify application fee
I suspect the behavior is different if you use transfer_data['amount']
somber micaBOT
dim spade
Hi, taking over for a teammate who needs to step away. Let me catch up
dim spade
Thank you for your patience, I'm working internally to identify what might be going on
wary oxide
ok thanks! Please let me know as you have updates
somber micaBOT
hardy onyx
:lmaohno:
wary oxide
lol
hardy onyx
Well I'm back; lemme catch up. 🙂
Ok, I think I just figured out how to reproduce your account type, so that in theory is a good step forward.
Or backward.
Or sideways.
But it's a step. 😂
hardy onyx
I'm holding tight to that theory. 😅
wary oxide
also if you need steps on reproducing, let me know
although guess you could pull the request logs for the charge objects I shared
hardy onyx
We've done that. The multicapture bit makes it hard(er) for us to reproduce, but I'm like 85% of the way there. 😂
somber micaBOT
hardy onyx
Boom.
wary oxide
the suspense is building up lol
hardy onyx
Hey now, you've waited all day - what's a couple more minutes? 😂
Using arlyon/async-stripe ya?
wary oxide
yess
well combination of that and our own library that has some of the additional features not publicly available
hardy onyx
Ok, you need to add https://docs.rs/async-stripe/latest/stripe/enum.Expandable.html to your Partial Capture API call, and expand the following:
If you just need the py_ ID: expand: ["latest_charge.transfer"] and the ID as a string will be at latest_charge.transfer.destination_payment
If you want the py_ Object: expand: ["latest_charge.transfer.destination_payment"] and the whole py_ Object will be at latest_charge.transfer.destination_payment.
wary oxide
ok let me give that a try real quick. Any way to get that after the fact for backfill purposes? Because I noticed that transfer for a given charge was null
hardy onyx
Oh ya. You can use the same mechanism for just a straight up Retrieve Payment Method too.
I think you wanted to add metadata to the py_, right? So all you need is the ID (option one) and you have enough to make your update metadata API call.
wary oxide
If I could attach metadata directly to the py_ object that'd be great
hardy onyx
For backfill, you'll likely need to run a bazillion GET /v1/payment_intents (with expand), or else use some of the magic reporting to get the details; at some point backfilling and "just working" will coalesce and you'll be all up to date.
wary oxide
awesome, let me give this a try
hardy onyx
🤞
wary oxide
holy shit
hardy onyx
Like, from the Pope?
hardy onyx
WOOO
There's another way you can do this too, as my colleague pointed out to me: you can list all the py_s in a Transfer Group: https://docs.stripe.com/api/transfers/list#list_transfers-transfer_group so that would work for backfilling for sure, and then the expand model will work for right-then updating. 🙂
You could also potentially do ~some of this in Webhooks.
wary oxide
quick question. Do I have enough to update the metadata with the py_ I tried retrieving the charge earlier and anything with py_ I would get a not found error
hardy onyx
Ah, you need to retrieve it from the Connected Account. One sec.
wary oxide
yeah wasn't clear to me based on docs how to properly retrieve
hardy onyx
The same colleague who is thankfully lurking over my virtual shoulder ❤️ also just pointed out that this approach will only give you one py_ where in this case there were two, so the Transfer Group approach might end up being necessary.
wary oxide
Ok that makes sense to me. I'm assuming for backfill transfer group but for that moment the expand would work
And pretty much same thing where need to list transfers from the connected account with transfer group
hardy onyx
I think the question is do you get a different py_ for each of the /capture calls or not.
wary oxide
will test that right now
hardy onyx
This is the update API call you need: https://docs.stripe.com/api/charges/update#update_charge-metadata You use the py_ ID as the Charge ID, and you also need to add the Stripe-Account header to the request so Stripe operates on the correct account: https://docs.stripe.com/connect/authentication#stripe-account-header
wary oxide
ok slightly bad news
so the py_ object does exist in the capture but only if I do a final_capture
hardy onyx
lmaohno
wary oxide
If I set it to false it doesn't look like I get back the py_
hardy onyx
What about listing them via <https://docs.stripe.com/api/transfers/list#list_transfers-transfer_group >?
hardy onyx
I'm not 100% on this specific implementation so I'm not entirely sure what expected behaviour is in that case (but that's not what I'd expect).
wary oxide
Yeah I don't think I expect that either. My only guess as to why that would be the case (having no real idea about the internals) is that there might be some batching that is trying to be done with multi capture?
hardy onyx
The Charge only has a spot for one of those py_ objects which makes it hard. Listing by transfer group is probably the right way to go. That still can be done at any time, and it's not a big list because it's specific to that group.
wary oxide
ahh that might make sense trying listing right now
so transfer group kind of works as in I'm able to get the py_ object and if I capture mulitple times I can get both
the only problem is that it's a bit hard to map each capture request
hardy onyx
Tell me more.
wary oxide
So if I have 2 capures and thefore 2 payments I guess I then have to check the amounts to map each capture request to a payment
and by payment I mean py_
hardy onyx
Remind me when you're making these /capture API calls? Like what business event/activity is it related to?
wary oxide
The other way I'm thinking of it is I do get a balance transaction txn_ when I capture and get that in the expand object. I can always use that to fetch the transfer and then map to the specific py_
hardy onyx
I tried to dig through that way and it didn't work previously, but I can peek again.
wary oxide
Use case is I have an order of 3 items. I ship items separately and want to attach an invoice (basically a shipping label) to each capture request and subsequently each payment
So when the connected account sees py_ they can basically cross reference and say this got successfully shipped so we're good here. They tell us when to capture as a shipment goes out and now I'm trying to marry the data
I guess theoretically the order in which a capture is done should match the order of the creation of the py_ in the case of mapping with list transfers. Feels a bit brittle but would work
hardy onyx
Brittle is bad
Ok so there's another way this could work: Connect webhooks. Each of those transfers should be a payment.created Event in the Connected Account, and we include the Request ID in that: https://docs.stripe.com/api/events/object#event_object-request-id
wary oxide
oooh
hardy onyx
And you can see the /capture Request ID in the headers of the response to the request: https://docs.stripe.com/api/request_ids
Immutable, unique strings that will be present in both your request, and the event.
wary oxide
I think that should definitely be able to work
somber micaBOT
hardy onyx
You will need to store the metadata you want to add somewhere that you can look up by Request ID so that when the Event comes in, you can properly process it.
Arguably, you want to store {reqID, metadataToAdd} from the capture, and {reqId, pyId} from the webhook, and then unify those to process them - that removes the timing of things entirely.