sm_art

[marsh sundial]

Hi there!

[bleak whale]

Hi Soma

[marsh sundial]

is adding a 1000 units to the user collection regardless of the amount specified when creating Stripe product
Can you clarify this? Like do you have a request ID or object ID to share?

[bleak whale]

the product id itself?

[marsh sundial]

Yes for example

When I create a new product and select “Package pricing” I don’t get the option to create a payment link for it
Yes I don't think it's possible to create a "package pricing" if you are using Payment Link. You should use a Checkout Session instead.

[bleak whale]

my understanding is that this field "amount" is synced with the number of units I specify when creating a product, and it resets at the end of the billing cycle, is that correct?

here is the product ID:
price_1MdCkXIGIjJte0RIzMZcnvzS

[marsh sundial]

Thanks! Give me a few minutes to look into this.

[karmic osprey]

Number of units I specify when creating a product
I'm not sure what that refers to specifically(what API call or action in the dashboard that is).
and it resets at the end of the billing cycle
it wouldn't no, since it's licensed-style pricing(quantity x price-amount = amount charged). Quantity only resets when using usage-based/metered billing

[bleak whale]

The units ( quantity ) is specified when creating a Stripe Product.

After user pays for this product ( subscription ) I can see that Firebase “Run Payments with Stripe” extension is creating new fields in user document ( firebase users collection)

and I can see an "amount field under
subscriptions -> <subscription ID> -> items-> 0 -> plan -> amount

I was expecting this amount to reflect the amount specified when I created a product. but I'm getting amount=1000 regardless of the amount specified in Prodcut

I was planning to decrease the "amount" field when user consumes his credit on the website. And was hoping that Stripe will automatically reset this amount at the end of the billing cycle. Is this what "package pricing" meant for? Is there a better pricing model to achieve this?

[karmic osprey]

what's in your screenshot is not an amount or quantity on an actual subscription or product

[bleak whale]

but there are units there

[karmic osprey]

yeah just hang on and I'll get you a link

[bleak whale]

The alternative I'm considering is to use "standard pricing" and handle the credits given to users with a firebase cloudfunction, but it is prune to errors, and need to handle lots of cases like upgrading and downgrading half way through the billing cycle. I was hoping to find out of the shelve solution from Stripe since it is a common pricing model

[karmic osprey]

yes, and that's all it is, the unit. It's just saying, the price is 30 pounds per 3000 units. That's the definition of the pricing model, it says nothing about how many units you have in an actual instance of a subscription — that is the amount of the SubscriptionItem on the subscription. E.g. if that amount is 6000 then that subscription charges 60 pounds a month.

but I'm getting amount=1000 regardless of the amount specified in Prodcut
then whatever code creates the subscription must be passing 1000 somewhere, I would say

I was planning to decrease the "amount" field when user consumes his credit on the website
you can call the API to update the subscription to change the amount, that's how you'd do this. https://stripe.com/docs/billing/subscriptions/quantities

And was hoping that Stripe will automatically reset this amount at the end of the billing cycle.
we don't, no, the quantity is set by you and doesn't change per cycle.

Is this what "package pricing" meant for? Is there a better pricing model to achieve this?
I don't really know if there's a built in way to do this, I wouldn't think so, but I'm not a Saas Billing expert so I don't completely understand how we talk about our models. Maybe metered Prices makes more sense where you report the usage as it's used, instead of doing the opposite now where you decrease credits

[bleak whale]

Thanks for explaining! it makes sense now.

From the link you sent me it seems like we need "per-seat licensing" how can I create this type of product from Stripe dashboard? "package pricing" seem to be the most relevant among other options

Here is a reference to what we are trying to implement

[bleak whale]

“Run Payments with Stripe” official Firebase extension from Stripe creates subscription record inside firebase, that's why I'm asking about its behaviour, is there a better place to ask questions related to this extension?

[karmic osprey]

From the link you sent me it seems like we need "per-seat licensing" how can I create this type of product from Stripe dashboard? "package pricing" seem to be the most relevant among other options
it's the same thing as far as I know — per seat means you have a quantity X and a amount $Y, and the monthly subscription is X x $Y.

in your screenshot I suppose it depends what credits are and how those work/how they get used/can they be added to/do they go up or down/what happens when they're used up before I could really try to give any advice

[karmic osprey]

not really. It's "official" but unmaintained as the folks involved in creating it no longer work at Stripe and nobody internally at Stripe really knows/uses Firebase. You can try asking Github issues on it as the best way to get visibility

[bleak whale]

user gets an amount of credits ( say for generating images) and after each generation I decrease his credit amount by 1.

[karmic osprey]

does the price they pay change if they have an amount between 1 and 24,000 or is it the same

[bleak whale]

no it is fixed, you pay for a 1K credits and you used them

[karmic osprey]

and what happens if the number reaches 0

[bleak whale]

you can't use the website, or you upgrade to another subscription

if you only use 200 out of 1000 you have per month you still get charged the same ( you actually pay in advance to get the credit) and by the end of the billing cycle the amount resets to 1000 unless you cancel

[karmic osprey]

hmm I don't think there's any way direct way to model that in Stripe. Let me ask someone else

[bleak whale]

Thank you! it is a very common pricing model in image generating websites, and they all use stripe and some of them with stripe customer portal

I would love to know what is the best practice here to avoid committing to a custom solution that is prune to errors

for reference:
https://getimg.ai/pricing

[karmic osprey]

let me see what other people on my team say but IMO this is just something you do outside of Stripe entirely. In Stripe you just do a regular $42 a month subscription (one Price with quantity:1). Each month when it renews, you listen to webhooks and set a credit variable in your database to 1000; you edit your database as credits are used inside your system

[bleak whale]

We started working on this but realised there are many edge cases: like upgrading or downgrading half way through the billing cycle. I saw that Stripe handles this from customer portal neatly with pro-rated diff pricing and was hoping it can also directly update the credit for the user in firebase

[karmic osprey]

I asked someone on my team and they agree that there's no in built pricing model for this and you mostly maintain it on your side.

You can ask https://support.stripe.com/?contact=true if you want too, my team is more about specific coding and API detail questions then this sort of business modelling topic.

I saw that Stripe handles this from customer portal neatly with pro-rated diff pricing and was hoping it can also directly update the credit for the user in firebase
our proration is really about prorating charges, as in charging you a prorated amount of a new price, and refunding a prorated amount of what you already paid, it's all focused on dollars in/dollars out. It doesn't really act on or calculate other things. This overall works differently then what you probably want — the way it works is you set the quantity of the subscription item(or the customer can do it in the portal), and we calculate prorated charges based on the new amounts, but we don't interact with anything like a merchant-specific concept of credits.