#richard_api
1 messages ยท Page 1 of 1 (latest)
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.
- richard_api, 20 minutes ago, 4 messages
๐ 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/1272923299583623248
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Sorry got caught up in something and the thread got closed.
I think my primary question is how to initiate a subscription where the payment is taken at the end of the cycle. This is actually happening via the product?
Hi there ๐ that isn't possible to control. Our metered Prices will always bill in arrears (at the end of the billing period once usage has been reported), and licensed Prices will always bill at the beginning of the billing period.
So it sounds like you'd need to build a way to work around that behavior. Two approaches come to mind:
- Create the Subscription without the flat fees, but with the metered Price. Later add the flat-fee Prices to the Subscription, so they start charging at the beginning of the next billing period which is also the end of the first billing period. The concern here is that I'm pretty sure this approach causes two invoices to be generated each billing period, since they need to have different billing period dates on them.
- Create your flat fee prices as metered Prices rather than licensed ones. Report a usage of 1 for those. This way they'll be billed at the end of the billing period like you're describing.
I see...
I'm thinking option 2. since I need to adjust the flat fee based on usage
I have existing subscriptions with licensed products. To migrate them I'd change their line items to contain metered products instead
?
Correct
And you can use Test Clocks, in test mode, to see exactly how the full lifecycle of the Subscription will play out when you do that:
https://docs.stripe.com/billing/testing/test-clocks
Thanks will do that.
I'm guessing the Stripe checkout experience is going to be a bit weird for this implementation? It'll ask for $0
Yup, with this approach the first Invoice will be for $0, since everything will be billed at the end of the billing period, and our Checkout UI should show that.
With metered Prices, you need to either use a Billing Meter or Usage Records to report your usage information to us. Billing Meters are our newer way of reporting usage.
ah usage records are the docs marked as legacy?
Correct
Is it an option to do what I want by using items with quantity
https://docs.stripe.com/api/prices/create#create_price-recurring-aggregate_usage
https://docs.stripe.com/billing/subscriptions/usage-based/recording-usage#aggregation-formula
Last (coming soon)
Max (coming soon)
I think the API ref says these are available now?
I'm not sure I'm grasping what you're asking here. Like using quantity to preset the usage?
to set it at the end of the billing cycle
They're supported for Usage Records, but they aren't in Billing Meters yet:
https://docs.stripe.com/api/billing/meter/create#create_billing_meter-default_aggregation
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
I don't think so, but I may be mistaken. That shouldn't take too long to test with Test Clocks. (Sorry, I can't test myself right now, the server is pretty busy).
thanks Toby, I appreciate borrowing your impressive billing mental model