#rayray - Separate Charges and Transfers with Subscriptions
1 messages ยท Page 1 of 1 (latest)
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
Looks like it's something we're considering internally, but we don't currently support transfer groups or anything like that on Subscriptions.
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?
Hang on, looking at something else...
k
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?
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
I think you would want to try on the invoice.created event so it happens while the invoice is still in draft form
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
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
pi_3KN04D2pZ9LNiazX147BnTKA
Ah, yes it is. One moment as I remember the workaround
i'll look for a subscription a couple years old
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
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?
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.
awesome!
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.
would be very helpful, thank you!
Sorry, I have an answer soon but there was a last little bit of miscommunication on this.
sweet thanks
๐ 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?
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
so you are floating the funds completely?
suppose so yea
just to be clear: you're 100% sure that's what you want for your business model? (often it's a misunderstanding)
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
I can't imagine a non profit being allowed to float money
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?
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? ๐
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
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
yes - very nice. Now, suppose there was a tertiary party. how would i manage that?
is there? or is it just hypothetical?
there is
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
I really don't get why anyone would do this
we started with stripe in 2014
that's not really related though
probably just didn't have the capabilities at that point or weren't smart enough to use them!
sure but let's focus on what you want the real experience to be
then I can say if it can be built
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
The first part is doable, the second part isn't
I as the platform would rather not float the money
you're a platform here, you're the one aggregating the funds and splitting it in 2
right thats what i thought
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
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
sure but you're still splitting funds between 3 entities and in that world you, the platform, are the one accepting the funds
then, more to the point, the barber shop wants to keep that relationship but offer a monthly subscription that does the same thing
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"
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
right
it also means everyone has a Custom account (or Express) and you own the liability/refund/dispute flows