#lanman9000_api
surreal prairieBOT
👋 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/1466300752858321145
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- lanman9000_checkout-price-data, 2 days ago, 27 messages
⛔️ Stripe developers have stepped away for a short while
Please leave your questions here, and we’ll respond as soon as we're back! If you need help urgently, you can contact Stripe support for help.
next turtle
Hi! Can you provide more details or a specific example to describe your issue?
azure inlet
our use case is a cloud IaaS hosting service. we will have 3 products. cpu cores, ram, and storage.
our portal will require the customer to be subscribed to all 3 products before we will provision services.
customers will essentially 'pre-pay' for resources before we provision. they must have a minimum of 1 cpu core (qty 1), 2 GB of ram (qty 2), and 1TB (qty 1) of storage.
let's imagine this scenario.
I sign up for services. I set up that I need 10 cores, 16gb of ram, and 2tb of storage. each product has different costs.
let's say that cpu cores cost $15/month, ram costs $1/gb/month, and stroage costs $20/tb/month.
as the customer, once I tell stripe how much of each product I want .. a recurring payment is set up every month for each product multiplyed by the quantity and price. All of this is on 1 invoice. where each product is just a separate line item.
now. as a customer, I need the flexibility to adjust the quantities of my resources at any time. let's say in the middle of the 2nd month (day 15) I need more cpu cores. so I go to the customer portal, and I adjust the quantity of my cpu cores from 10 to 20 cores.
now stripe will handle the calculations of the increase in price that I must pay today (the 15th) to cover the increase until the end of the current month.
then at the start of the next month, I will automatically be billed for 20 cores now, 16gb of ram, and 2tb of storage. same deal if I reduce resources. Stripe will handle the credits between the day I reduce to the end of the month, then at the start of the following month, the new value will be what im charged for the full month.
my question is .. based on the model I've described .. and the context you've ingested from stripe.. what kind of billing method is my use case? I think it's a subscription, but my developer says its metered billing.
next turtle
Give me a moment to look at this.
next turtle
Thanks for waiting! Regarding the pricing model, as long as you are collecting the payment at the start of the billing period, your use case's description matches per seat model [0]. Regarding updating the subscription and the quantity of its items, the customer will not be able to do it via the Customer Portal as mentioned here [1, 2].
[0] https://docs.stripe.com/subscriptions/pricing-models/per-seat-pricing
[1] https://docs.stripe.com/customer-management#customer-portal-limitations:~:text=update these subscriptions.-,Multiple products,-Usage-based billing
[2] https://docs.stripe.com/customer-management#customer-portal-limitations:~:text=Customers can’t define,.interval values.
azure inlet
why can't per-seat have its quantities changed?
next turtle
It can't be changed on the Customer Portal as the Customer Portal has limitations.
azure inlet
but if we have our own portal .. and send the customer to stripe checkout via API redirection with the updated quantity .. that will work correct?
the customer just uses stripe for checkout
why would we do 'per-seat' though .. each seat is not a separate user.
wouldn't we fall more into "usage-based" via "fixed fee" ?
next turtle
but if we have our own portal .. and send the customer to stripe checkout via API redirection with the updated quantity .. that will work correct?
By checkout are you referring to Checkout Session? If so, you cannot use Checkout Session for payment when updating a subscription. If there proration, it will create a new invoice.
why would we do 'per-seat' though .. each seat is not a separate user. wouldn't we fall more into "usage-based" via "fixed fee" ?
Following your example, your customer subscribes to 10 cores, 16gb of ram and 2tb of storage on Jan 1. Are you charging for these at the start of Jan or at the end of Jan?
azure inlet
we are charging at the start of the month
they are charged on Jan 1 .. for the period of Jan 1 to Jan 31
next turtle
For usage based model, the customer gets charged at the end of the billing period. I understand per-seat sounds like per user, but it is just a way to describe it. Per-seat should also work for a customer subscribing to a product with x quantity.
However, I would recommend for you to thoroughly test the models out to see which fits your use case.
azure inlet
yes, each product would be part of (1) main subscription. each product would have a separate quantity X.
1 subscription on 1 invoice for 3 products with X, Y, Z quantities.
each product is just a separate line item
so with that in mind .. per-seat is the best method for us?
next turtle
Based on above per-seat makes sense. But as I mentioned earlier, you should thoroughly test the models out to see which fits your needs as you best understand your use case.
azure inlet
let's go back to the customer portal limitation
so if we're using per-seat method .. we have our own portal that we're building where customers can "adjust" their quantities.
once they select how much quantity they want .. we would just send them to stripe to process the payment
so they click "change capacity" which brings up a window to let them adjust their quantities. once adjusted, they click "continue to checkout", which redirects them to the stripe checkout to process payment
obviously not everything is done which is why the quantities look weird in the screenshot .. but that is the flow we're going for.
so with per-seat .. we will send stripe the updated per-seat quantity .. then we just need stripe to process the payment / update the subscription.
next turtle
When your customer updates the quantities and there is a proration where payment is required, a new invoice will be created. If the collection_method is set as charge_automatically then the customer's saved payment method will be charged automatically. If it is set as send_invoice then the invoice will be sent to the customer.
The proration will be done on Stripe's end.
azure inlet
yes thats fine. a prorate or a credit because the quantities went up or down .. generating a new invoice is totally exepected
next turtle
However, you won't be able to create a Checkout Session for payments of such updates.
azure inlet
However, you won't be able to create a Checkout Session for payments of such upd...
i dont understand what this mean.s
next turtle
A Checkout Session can be used to create and pay for a new Subscription. You cannot use it to pay for prorations for an ongoing subscription.
azure inlet
what is a checkout session? .. is that what you are calling this ?
next turtle
Yes this is a checkout session.
azure inlet
ok .. so if after updating the quantity of a per-seat subscription (either up or down) .. what is the expected behavior then? in our portal, the customer clicks "complete checkout" or something similar .. then what happens?
next turtle
It depends on how you handle the update. So when you update the subscription with the new quantities and your proration_behavior is set to always_invoice, an Invoice will be created. Then depending on the collection_method [1] the invoice will either be sent to the customer or their saved payment method will be charged automatically. You can read more about updates and prortions here [2, 3]
[0] https://docs.stripe.com/api/subscriptions/update#update_subscription-proration_behavior
[1] https://docs.stripe.com/api/subscriptions/update#update_subscription-collection_method
[2] https://docs.stripe.com/billing/subscriptions/change
[3] https://docs.stripe.com/billing/subscriptions/prorations
azure inlet
no, I get all that. and thats great. but how does a customer visually tell that their subscription has been updated. If there is no checkout process .. is our portal supposed to call the stripe API .. then just present some message to the customer that the modification was successful ?
next turtle
Again that depends on how you do the update. You will be calling the update subscription endpoint to update the subscription [0]. From there it depends on what parameters you pass for the update and the payment status. For example, if you are to set payment_behavior as pending_if_incomplete or error_if_incomplete [1] and the payment fails, the update will not take place. Or if the payment is successful, it will trigger an invoice.paid webhook event [2].
You will need to inform your customer / present the message based on the outcome of the update. You can read more about payment status here [3].
[0] https://docs.stripe.com/api/subscriptions/update
[1] https://docs.stripe.com/api/subscriptions/update#update_subscription-payment_behavior
[2] https://docs.stripe.com/billing/subscriptions/overview#succeeded
[3] https://docs.stripe.com/billing/subscriptions/overview#payment-status
azure inlet
ok. thank you.