#tp-kmai_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1501639601708732528
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
๐ taking a look
No sweat, actually let me post some screenshots since it might be easier to see
this is for the payment intent from checkout session
and this is the payment intent from the invoice
Hey there, sorry for the wait, stepping in for Janet here.
Okay, so these two PaymentIntents are from Subscription Invoices which are created on your acct_1N3MNXBCxN7wn3Lg which I assume is the platform. These Subscriptions are created via the Subscriptions API and not via Checkout Sessions - you missed Checkout Sessions
For pi_3TU8hWBCxN7wn3Lg0vEOrdHp, you created a transfer after the fact that references this PaymentIntent in this request: https://dashboard.stripe.com/acct_1N3MNXBCxN7wn3Lg/test/logs/req_kz4iDR0rX0mKAm
Right the invoices are generated from the subscription
so for pi_3TTUbJBCxN7wn3Lg13KQ1pFe...is that transferring happening before?
Or do I need to call a different API for the transfer instead of the transferService..? Like do I need to update pi_3TU8hWBCxN7wn3Lg0vEOrdHp with PaymentIntent service and update the transfer_data?
The transfer happens after and I don't expect you would expect Stripe to update the PaymentIntent in this case. Is there a reason why you need to create the transfer after the fact? Why not configure this on the Subscription up front using the transfer_data parameter?
Looking at pi_3TU8hWBCxN7wn3Lg0vEOrdHp it seems like we did update transfer_group but it isn't in a webhook event
Oh that's odd.. cause the UI looks different between the two then
Hmm that's a good point.. let me see...
Another thing to note is that there isn't always parity between the dashboard and the API, for better or worse
Here, assuming that your screenshot is one of the two PaymentIntents above, it does look like the dashboard is finding the transfer destination and displaying it to you, but it doesn't seem like we do that in the API in the same way
Oh i didn't include it in the screenshot but the one will the less information has checkout session tied to it while the other one has invoice... so let me post that really quick..
and this is the "invoice" one
Oh okay.. so it looks like what we do is we listen to the Invoice.Created event and then do some calculation/change the invoice amount before finalizing it. In that process we add transfer_data there
Do you do a consistent percentage of the total amount transferred to the connected account? If yes then setting transfer data on the Subscription might still work
Somewhat consistent, we calculate what kind 'product' it is and then modify the amount then... there is one product that varies month to month so the amount of seller will change then
Okay, that's something to consider then. You can set transfer_data.destination and transfer_data.amount_percent up front when creating the Subscriptions and that would automate the transfer creation and you would have that information available
but it is worth being aware here that the only reason you're able to do this at all is because you're using a private feature where you pass the pay_immediately: 'false' parameter when creating the Subscription
So you're getting some custom behavior here
ah yeah that won't work since it's not percentage based, it's custom amounts
but besides that two UI not showing the same information...effectively the transfer is the same?
For PI pi_3TTUbJBCxN7wn3Lg13KQ1pFe the transfer_data is coming from what you set on the invoice here prior to finalizing it: https://dashboard.stripe.com/acct_1N3MNXBCxN7wn3Lg/test/logs/req_w4ilGKYntaw15j
Which you can do because you defer the immediate payment during subscription creation in the API: https://dashboard.stripe.com/acct_1N3MNXBCxN7wn3Lg/test/logs/req_g9rEjEnSxZIj8I
But this is not possible for the Checkout-created subscription, which pays right away
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Which is presumably why you are creating the manual transfer afterwards as palamedes shares: https://dashboard.stripe.com/acct_1N3MNXBCxN7wn3Lg/test/logs/req_kz4iDR0rX0mKAm
This pattern does not retroactively set transfer_data on the payment intent, so it is expected that it will appear differently.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Okay that makes sense why it will appear differently... but for the purpose transfering the funds to the connected account... the end result is still the same, right?
Yes, pretty much, though the refund flows will differ a bit.
You're effectively doing payments with two different flow: destination charge with transfer_data[amount] and "separate charges and transfers"
These are explained and diagramed here for reference:
https://docs.stripe.com/connect/destination-charges?platform=web&ui=stripe-hosted&fee-type=transfer-amount#flow-of-funds-amount
https://docs.stripe.com/connect/separate-charges-and-transfers?platform=web&ui=elements#collect-fees
ah i see then refund will be an additional step to refund both side then
Yes, with the manual transfer you'd have to manually reverse the transfer, too:
https://docs.stripe.com/connect/separate-charges-and-transfers?platform=web&ui=elements#reverse-transfers
With the destination charge this can be combined in a single API call by enabling reverse_transfer=true
https://docs.stripe.com/connect/destination-charges?platform=web&ui=stripe-hosted&fee-type=transfer-amount#issue-refunds
hmm... is it possible to set the transfer_data inside of CheckoutSession?
okay i see hmm
What mode is the Checkout Session?
If you're in payment mode then yeah, you can use this field - https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_intent_data-transfer_data
subscription mode
For subscription mode, we do have transfer_data parameter under subscription_data - https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-subscription_data-transfer_data
but when we add a discount and the amount change, that field is immutable, correct?
What do you mean by immutable? You're specifying the "percentage" under transfer_data for Subscriptions. So it would be proportional to the final amount that'll be charged to the customer
I can't use the perctenage just because of how the amount is structure for our business need so i have to use amount to seller.. so currently i'm doing that when the Invoice is in draft state and updating its transferData there, but because CheckoutSession immediately pays out the invoice I'm trying to replicate that transfer behavior
I don't believe we allow setting an amount for Subscription mode checkout sessions
If you need to transfer a specific amount then you'd need to use Separate Charges and Transfers flow instead.
where the amount first settles on your Platform account and then you make the transfers to the connected account