#rayray - Separate Charges and Transfers with Subscriptions
indigo glen
Thanks @verbal shore I've asked a few times over the last 8 years but haven't figured it out just yet 🙂
just checking in for some fancy newfangled secret mission stuff. Or more likely something I've plainly missed
verbal shore
Looks like it's something we're considering internally, but we don't currently support transfer groups or anything like that on Subscriptions.
indigo glen
Thank you! will check back sometime later - let me know if you think its a next month, next quarter, or next year type of thing?
verbal shore
Hang on, looking at something else...
indigo glen
k
verbal shore
So it's not ideal, but it looks like this is technically possible today. You can update the Payment Intents associated with Subscription Invoices to add a transfer_group to them: https://stripe.com/docs/api/payment_intents/update#update_payment_intent-transfer_group
Would that work for your use case?
indigo glen
oh my
hold on let me read through
ok so can we listen for payments on a subscription invoice and update it right away or does it have to happen before that?
if the invoice is set to charge automatically, trying to figure where we insert ourselves into the process
sterile yew
I think you would want to try on the invoice.created event so it happens while the invoice is still in draft form
indigo glen
forgive me - how long do they usually stay in draft?
oddly it looks like from examples in my app that the invoice was somehow created after the payment succeeded
sterile yew
I thought it was an hour. Do you have the ID?
I feel like this may be behavior with the first invoice that I forgot about
indigo glen
pi_3KN04D2pZ9LNiazX147BnTKA
sterile yew
Ah, yes it is. One moment as I remember the workaround
indigo glen
i'll look for a subscription a couple years old
sterile yew
No need I think
I see where my advice was a bit off
To have the first invoice go in to draft for an hour, we recommend either starting the subscription with a couple second trial or creating a schedule that with a start that is a couple seconds in to the future
indigo glen
makes sense - though that would be the first one. on the next go around how to we catch it before it gets paid automatically you know?
sterile yew
Checking now. I think it should be able to be invoice.created.
Also I may have been wrong about the invoice needing to be a draft. I will get all of this straight and get back to you.
indigo glen
awesome!
sterile yew
Sorry for the silence here, we need to look at this more in depth than I initially thought. I've reached out to some colleagues and will get back to you with what we can find.
indigo glen
would be very helpful, thank you!
sterile yew
Sorry, I have an answer soon but there was a last little bit of miscommunication on this.
indigo glen
sweet thanks
simple rain
👋 I'm taking over! Taking a step back: are you trying to have the funds associated with the Transfer land immediately or do you want those to be transferred when the funds for the charge land in your account?
For example card payments take 2 days. If you charge $100 on Monday, you get the funds on Wednesday. When you create the transfer for $50 to a connected account, do you want them to get $50 immediately (you as the platform float the money) or on Wednesday like you, just you want the Transfer created upfront?
indigo glen
immediately
right now we manage it with two separate transactions and listen for a webhook each renewal for the main subscription to charge the customers account an additional amount and transfer the funds to the third party connected account via transfergroup
simple rain
so you are floating the funds completely?
indigo glen
suppose so yea
simple rain
just to be clear: you're 100% sure that's what you want for your business model? (often it's a misunderstanding)
indigo glen
i'll explain in more detail
We're a non-profit, we've got a deal with our partners to split a yearly membership with them
simple rain
I can't imagine a non profit being allowed to float money
indigo glen
because we aren't able to split the subscription each year we say the price is "100" and then create 2 charges to get there. one for us and one for the connected account (think we use the destination flag)
each subsequent year we watch for the subscription to renew and then key off another charge to the card and send it to our partners
we actually get a lot of disputes because people don't recognize or see how the connected account charge is correlated
not sure I'm answering your question/concern
am I being clear?
simple rain
not really :p
if you are doing a separate charge then this is moot
Are you really charging the card 2 separate times each time? 😅
indigo glen
yes - but I want to not be doing a separate charge
i want to be doing a single charge with a piece being sent to a connected account
simple rain
yeah
Wouldn't it work to have a subscription with transfer_data set?
like each year you charge $150 and the connected account gets $50
automatically, without you doing anything else
indigo glen
yes - very nice. Now, suppose there was a tertiary party. how would i manage that?
simple rain
is there? or is it just hypothetical?
indigo glen
there is
simple rain
Ultimately, it really looks you have no plan to float the money, which is the main question
I can't really advise you until you decide that
and I can't imagine a non profit being willing to float thousands of dollars to a partner while you wait for Stripe to pay you
but only you know that for sure
simple rain
I really don't get why anyone would do this
indigo glen
we started with stripe in 2014
simple rain
that's not really related though
indigo glen
probably just didn't have the capabilities at that point or weren't smart enough to use them!
simple rain
sure but let's focus on what you want the real experience to be
then I can say if it can be built
indigo glen
i want customer A to pay User 1 (connected account) and have that cash be split between User 1 (connected) and USer 2 (connected) with the platform account being paid our transaction fee
I want customer A to see he is paying User 1 NOT the platform
simple rain
The first part is doable, the second part isn't
indigo glen
I as the platform would rather not float the money
simple rain
you're a platform here, you're the one aggregating the funds and splitting it in 2
indigo glen
right thats what i thought
simple rain
If you make the charge on behalf of User 1, they get $150 of "revenue" when really you give them $50 so I don't think that's okay
like that can be done technically but doesn't mean it should be done
indigo glen
its two connected parties using a platform to facilitate their partnership basically
think of it this way. A barber shop has subcontractor barbers, the shop uses a platform to collect payment from their customers. The customer wants to pay "Joes barbershop" who receive the money and gives the subcontractor barber their piece. Meanwhile, the platform gets a transaction fee for enabling it
simple rain
sure but you're still splitting funds between 3 entities and in that world you, the platform, are the one accepting the funds
indigo glen
then, more to the point, the barber shop wants to keep that relationship but offer a monthly subscription that does the same thing
simple rain
But ultimately, it's what you already have today right
as far as I can tell what you are missing is this: https://stripe.com/docs/connect/charges-transfers#transfer-availability
when you create the transfers to user 1 and user 2 you say "please tie the payout schedule to the original charge's schedule"
simple rain
we don't have a way to do "automatically split funds between N parties" so you always need custom code. When you get invoice.payment_succeeded you can create the 2 Transfers and for each one pass source_transaction: 'ch_123' which is the id of the Charge associated with the paid invoice
that should fit your need, except that you are the "merchant of record" here so it's not the exact flow you need but that's the only way I can think of
indigo glen
right
simple rain
it also means everyone has a Custom account (or Express) and you own the liability/refund/dispute flows