#Pierre Beitz - price modeling
1 messages · Page 1 of 1 (latest)
We don't really provide a way to track credits like that so managing how many credits the user has will be up to your code. You might be able to do something like store the amount of the user's credits on the related Stripe subscription but that might be too complicated compared to storing those calues on your side
we thought of additionally adding a "0$"-prize with metered billing - and then checking out 2 prizes with a single subsctiption. that way we could store used credits in stripe, right?
How could we model that with stripe? Specially for a yearly subscription (where users shall pay the full amount upfront but will get their credits on a monthly basis).
This is a bit tricky as well. For yearly subscriptions we only send out events yearly. The two main ways in Stripe that I can think of are:
- Have a yearly subscription and a monthly $0 subscription for each user
- Have a monthly subscription for $0 and every 12 months add a one time charge to the subscription's invoice
I may be misunderstanding your pricing model
And unfortunately am in too many threads to become familiar with Zapier's. Can you give me a quick example of how you would want to work with a yearly user here?
Thanks Pompey, i think you got it right as we are considering option 1 currently. Just wanted to make sure there's no easier way of modeling this.
The idea in zapier is that you have different products - each of those with different tiers depending on how many "Zaps" (automations) you want to run in a month - e.g. 2000zaps/month for 10$, 5000zaps/month for 20$. And this is the other tricky part as we would have loved to use a mix of volume based pricing but with additional metered billing - for $0 per unit, just to do keep track of the used credits in stripe and not in our own DB.
oh, also forgot to mention zapier has a 33% discount if you pay yearly! but the zaps/month mechanism is the same. so you don't get all zaps at once but the "usage cycle" stays monthly - only the billing cycle changes to yearly.
so for monthly we could actually
- have one volume based prize to charge e.g. 10$/month for 1000 credits
- have a prize with metered biling (for $0 per unit) to store the used credits. next month we'd get a fresh quota (as in the amount of used units will be reported starting from 0 again), right?
for yearly this now gets more complicated as we'd need to "manually" handle two subscriptions. the one to charge yearly and the "artificial" one just like in the monthly example, right?
i hope you get what i mean. let me know if i can clarify!
Gotcha, thank you for clarifying. I will look in to our metered behavior to see if it would be possible to track credit usage like that. You definitely can record monthly sums bit by bit but I am not sure if the use case lines up properly or if there would be rough edges here. Checking in to this and will get back to you
Pierre Beitz - price modeling