#dorian_subscription-invoice
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1248351788260655217
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
Hey there!
Yes, you can do this by specifying an item with price_data to provide an ad-hoc amount & recurring interval etc:
https://docs.stripe.com/api/subscriptions/create#create_subscription-items-price_data
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
OK thanks. Do I need to preconfigure the products or items that a user would subscribe to or can I have a UI that allows that to be built in real time when the user enters the amount, selects the frequency and start date etc?
You need to specify a product the customer is subscribing to, so if a generic product/name you can re-use is not appropriate, you'd need to create this before creating the subscription
https://docs.stripe.com/api/subscriptions/create#create_subscription-items-price_data-product
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Got it thanks. A generic one would be fine. And then when you process the next payment, that presumably creates a "transaction" that I can pull into my trasnactions DB table?
Yes, each subscription period has a distinct Invoice which has an associated PaymentIntent (our stateful payment abstraction)
I suggest taking a read through this section of the docs that gives an overview of objects involved in a subscription, and including a visual diagram: https://docs.stripe.com/billing/subscriptions/overview#subscription-objects
OK thanks
To keep things simple, I want the Customer to have a single payment method that is used for all their subsciprtyions. I have already built the Stripe chekout capability for them to add a payment method and have bult access to the Customer Portal for them to maintain payment methods. Can I use whatever their current payment method each for each paymet that is processed for a given Subscription? Do I need to udpate all Subscriptions when a customer changes their payment method?
If you set the customer's invoice_settings.default_payment_method it would be used for all subscription payments, though you can optionally also set the default_payment_method on each subscription
Awesome thanks!
NP!
I plan on using the functionality to allow a business to create recurring subsidies for each of their employees - sort of like payroll. Would each employee's subsidy need to be a seperate subscription, or could i hae one subscirption for al the montly subsidies, one for the weekly etc? Im just thinking if its one sub per employee, that'a a lot of emails tyhat would be sent to the buisiness and a lot to manage.
Hmm I don't fully understand the model here, can you provide a more concrete example with a couple of employees?
but broadly, you can set that up either way as appropriate, using quantity on the items or multiple items up to the limit per subscription, or separate subscriptions
You can control automatic emails sent to the customer, such that you don't actually send anything unless you choose to
The business may say that I want to pay employee 1 $200 a month, employee 2 $400 a month and maybe employee 3 $100 every 2 weeks. I need to figure out how to set up those charges. I take care of moving the funds to the employee's account on our platform, dont need Stripe there. I am jsut trying to figure out how to set up that subscription or those subscriptions to charge the business on a recurring basis. Ideally I think I would have all the montly cahrges on one subscription, all the fortnightly on another, all the weekly on another and could then send one email for each of those summarizing all the charges withing that one subsciption.
Heres a draft UI, that might help explain things better
You in fact must do that for the different intervals, because all items on a given subscription must have the same billing cadence
(same interval, all renew together on the same anchor)
Ah ok
So you could combine the subscriptions for employees on the same interval, but its really up to you
Don't let email volume dictate that for you, sicne you can disable those automatic emails
Consider cases like proration for changing the number of employees, or adding items, cancellationg when employees depart etc
separare subscriptions is likely to be much easier to reason about, but will greatly depend on your customer model with your business customers
More than email you should consider the separate payments
If you have separate subscriptions, each one will have a separate payment
If that aspect might be undesirable, instead preferring to charge your customer in fewer payments, then you might want to prefer combined subscriptions
ie, if they have 100 monthly stipend employees, do you want 100 payments or 1?
both are perfectly valid, just depends on what you want
OK thank you this is all good stuff. Yes I am thinking that one payment for all the monthly stipend employees would be best, for example. One payment for each employee would be overwhelming for the business. Can I still add/remove/edit individual employee subsidies within the one subscription? Is each employee effectively a 'line-item' on the subscription?
You can do it either as a quantity or multiple items depending on how you want it to appear on the invoice
well, quantity would work only where the amounts are the same
otherwise separate items, yes
OK yes sepreate items definitely.
Amazing thank you for all your great help
Stripe support really is the best! ๐
Sorry another Q. Re this text in the docs:
"To start subscriptions where the first invoice always begins in a draft status, use subscription schedules instead. Schedules provide the flexibility to model more complex billing configurations that change over time."
I think this is me as i want the business to setup the subscription and be able to specify the start date, which very likely wont be the same day. Does this mean I should use a sub schedule?
Yep, thats likely the right path if you want to start the subscription in the future
NP!
dorian_subscription-invoice
It looks like each subscription can only have 20 items? i.e. I could only have 20 employees on one sub, I'd need to create additional subs for employees 21 onwards?
@solar briar if you do a separate SubscriptionItem per employee then yes. But really using quantity is the most common approach
Understood thanks and I will use quantity when the price is the same, but if price is different I will need different items
yeah but even that is uncommon honestly to have different pricing per employee all on the same subscription
In our case its very possible. These are subsidies the employer pays to employees and they can choose to pay whatever they want.
You might be better off modeling this as one unique Price and calculating monthly how much they owe you maybe with usage-based billing or similar?
Like even if we gave you an increase say to 500 SubscriptionItems, it'd still break for companyes with more 500 employees so I don't think your modeling will scale/work here
Well I already shifting to thinking that I will have one line item per subsidy amount and use quantity when multiple employees are receiving the same amount, which is common. So for example in the draft UI below, we have three line items with a quantity of 3 on the first. Is that what youre suggesting?
yep that's fair but you would still hit that 20 limit ๐ฆ
True if there are more than 20 monthly amounts
What is the alternative?
One unique price you said? Im not folllowing sorry.
There isn't really a good alternative other than doing the math and charging for the sum of all subsidy all at once instead and then having your own breakdown/logic
OK thanks. I think we will be good for now. We havent seen a scenario where a business has more than 20 differnent amounts fo each interval.
We will have different subs for each interval
we do have a beta where we can allow up to 100 SubscriptionItems that might get you far enough too