#dannyboy
1 messages ยท Page 1 of 1 (latest)
Hello, which part of this do you need help with? Sending the funds to that many different accounts?
Building the payment intent
That recurring monthly is a bit hard as we currently passing the stripe_account header
I wanted to create a single payment intent for this order. and perform Transfer to respective account.
Yeah, that would be the way to do this. Create one payment intent for $160 and then create transfers to each accounts that you want to send funds to https://stripe.com/docs/connect/charges-transfers
So are you creating this payment on one of those connected accounts? Or is it happening on the main platform account?
our current flow is a mess. we are creating 3 payment_intent as of now ๐ฆ and would like to enhance it
no problem transfer funds to Account2 and Account3.. Problem is on Account1
Like how can i specify that the 50$ that will be transfered to Account1 is for Subscription with 30$ product/price and 20$ for 1 time payment?
Is this for your own records? In that case you can add that info as metadata when creating the charge
no. not for metadata.. 30$ is a recurring payment .. monthly
Alternatively, maybe you could create two separate charges and specify the source_transaction for each. That would also make sure we wait until the funds actually land on your account to make the payment
I meant store info on where the funds are coming from in the mnetadata
Or maybe I am not understanding the question. When you say you are specifying what the $30 and $20 comes from, what is the end goal of specifying that? Are you specifying that to get some certain functionality?
so the scenario goes like this...
user pays 160$
30$ is for monthly subscription
20$ add on payment (one time only)
40$ is different item - different vendor - need to perform transfer on managed_account 2
60$ is different item - different vendor - need to perform transfer on managed_account 3
so.. I'll be creating something like
Stripe::Transfer.create(amount: 4000, destination: managed_account2)
Stripe::Transfer.create(amount: 6000, destination: managed_account3)
Here comes the tricky part
Stripe::Transfer.create(amount: 5000, destination: managed_account1)
- User needs to be subscribed in the Product ( Basic Subscription) which cost 30$ monthly
- So that next month.. The recurring payment will kick in and will try to collect 30$ again
Ah, in that case, you can create a subscription with connect that charges the user 30 and sends it to the connected account https://stripe.com/docs/stripe-js/elements/payment-request-button
The one time $20 transfer could be made the same way as the other transfers
If you want the $50 to all be sent in the same transfer, you can do that but would want to then schedule a subscription to start charging them $30 next month
I got an idea.. Is this possible...
So for example today.. User pays 30$ .. Meaning, user is paid from Dec 17 - January 17..
I would create Subscription object today.. But.. it works like FREE or something like already paid...
So the first collection of the recurring payment will only happen on January 18?
I'm hesitant to mark user as "trialing" and set the trial_period_days to 30 ...
Does billing_cycle_anchor fits better? Like setting it this value to next month?
You can definitely do that, though anchor wouldn't affect the first time that your customer is billed. There are four main ways I can think of to acheive this without a trial:
- Giving the customer $30 of credit and starting the subscription
- Starting the subscription with a $30 off coupon
- Using a subscription schedule to create the subscription in a month
- Using a subscription schedule to start the user at a $0 price and changing it to $30 after a month
For the credit solution: https://stripe.com/docs/billing/customer/balance
For subscription schedules: https://stripe.com/docs/billing/subscriptions/subscription-schedules
how can i get the permalink to this thread?
The URL in your browser's navigation box should be the link to this thread. Otherwise you can click on the ... icon on one of our messages and click "Copy Message Link"
Doesn't look like it, I don't see current_period_start as something that can be set in our subscription creation or update calls https://stripe.com/docs/api/subscriptions/create
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
sorry, i must have scrolled up
Hi ๐
What is the reason you want to set the current_period_start that far in advance?
I have a very complicated scenario wherein a single payment intent will goes to 3 different managed_accounts.. And on ManagedAccount1 , i need to create a subscription.
So I was thinking that The Platform will receive the money and will perform 3 separate Stripe::Transfer on each managed_account..
The problem is on creating the subscription on ManagedAccount1.. I need to somehow link the Stripe::Transfer to the Subscription invoice.. Something like...
When I perform Stripe::Transfer.new(amount: 5000. destination: managed_account1) ... I would say that the 3000 or 30$ is the payment for the Subscription
So i'm thinking.. I can successfully transfer 50$ .. But when i start the subscription.. it will be marked as unpaid.. Since the subscription is monthly.. How can i achieve to make sure that the subscription is like free for 1 month or can i link the Stripe::Transfer to the subscription? so that Stripe will know that the 30$ from the 50$ transfer is for the subscription
hope it's clear ๐ฆ
I wanted to set current_period_start to Today + 1.month so that the subscription will only start on January 18..
but it's not possible. if you have a better idea on how to achieve this, i'm all ears
For your overall flow, I have no idea. That sounds way too complex to me. But for the simple ask I think you could use a trial period
https://stripe.com/docs/billing/subscriptions/trials
and/or provide a future billing_cycle_anchor
https://stripe.com/docs/billing/subscriptions/billing-cycle
These would allow you to defer when the paid subscription starts
okay ๐