#mounirmtl
minor crown
zenith zephyr
Hello
You want to expand the Transfer's destination_payment: https://stripe.com/docs/api/transfers/object#transfer_object-destination_payment
That will be the payment on the Connected Account which will contain the application_fee: https://stripe.com/docs/api/charges/object#charge_object-application_fee
(You could also expand application_fee in this same request)
verbal bluff
I'm not the one who created the transfer though. Stripe does it automatically for me when the payment intent suceeds I guess.
Can I retrieve this from the paymentIntent?
zenith zephyr
Yep the PaymentIntent's latest_charge will have the Transfer
verbal bluff
awesome. Thanks
zenith zephyr
So more succinctly you can expand latest_charge.transfer.destination_payment.application_fee
verbal bluff
Oh so if I expand that when I search for a payment intent, I will have the data automatically in? Without making a subsequent request to get the charge and the application fee?
zenith zephyr
When you say "search" do you mean retrieve?
Or are you literally using the Search API?
verbal bluff
We're using the search api to search payment intents by metadata["order_id"]
zenith zephyr
Gotcha
Then you won't be able to do it all in one request
Since the Search API returns a list
And expansion only supports 4 levels
With a list the first level will always be data
So what you can do is Search for the PaymentIntent and then make another request to Retrieve the PaymentIntent with the 4 levels of expansion
Really what we would mostly recommend here is to use a Webhook and do the retrieval when you receive the payment_intent.succeeded Webhook and then ingest the data you want into your own database
verbal bluff
That's totally fair.
We're trying to avoid doing that for now as we want to keep stripe the source of truth for all financial transactions.
Optimizing queries to stripe is not a concern yet for us. Stripe sdk is super fast in golang. To the nanosecond order of magnitude. It's actually faster than our own requests to our database 😅
zenith zephyr
Gotcha. Well just beware that the Search API isn't meant for read-after-write
As there can be a delay before the data is ready
verbal bluff
Oh yeah. That makes absolute sense. We're not using it like that. We're mostly reacting to our own events or webhooks from stripe.
zenith zephyr
Then you should be fine doing it that way
verbal bluff
Nice. Strong consistency on read is not something we care much about. We have eventual consistency on our end as well so We're used to that.
Thank you though. Super helpful
zenith zephyr
Sure thing
verbal bluff
I have another question. Should I post it into the main channel or can I do it in this thread?
zenith zephyr
This thread
verbal bluff
When we do a refund for an application fee or a payment intent, how can I check that a refund has already been made?
Is there a specific error code when we try to refund an application fee or a payment intent twice that I can rely on?
zenith zephyr
Best thing to do for something like that is to test it out
Should be quite quick to test
I don't remember the exact error message off the top of my head.
verbal bluff
fair. Will do thanks