Good day.
I'm working on a project that bills users with Stripe Metered Billing (https://stripe.com/docs/billing/subscriptions/metered-billing)
Are there any plans for implementing this functionality? From what I can tell it would involve allowing new subscription creation with a 0 value and a method for creating UsageRecords (possibly similar to the current tab method?)
Thanks,
Nic.
+1
I can see this being useful to others. I'll flag this as a feature request.
At the moment we don't have plans to add this ourselves but we're open to PRs.
Hey 馃憢 ,
I was thinking of working on this. It would be my first contribution, and I'm not very familiar with Laravel yet, so please excuse me if some words I used are wrong. Feel free to ask questions, I will try to make myself understandable.
I don't know very well cashier for now but I need this implemented for something I'm working on, so I was thinking of:
Add a SubscriptionItem class which will be an Eloquent model, with the following attributes:
It will also have a relationship to Subscription.
Methods related to quantity from Subscription will probably be there:
Some attributes won't be needed anymore, because they will be on items instead:
To maintain most of compatibility with existing code base, we could make methods related to quantity to be forwarded to the first SubscriptionItem if there is only one item in the subscription. Otherwise we will throw a LogicException.
We could also define a method getStripePlanAttribute to keep compatibility with the current stripe_plan attribute
The following methods will also be added:
Remove method quantity? It will not make sense anymore.
Add methods:
Change method getPayload to not return the key plan but instead a new items key with subscription items.
I believe these are the minimum changes that needs to be added to make multi plan subscriptions work, which are necessary to make usage reports.
Later, what can be added:
But it will mean these parameters will need to be added to the addPlan in SubscriptionBuilder to be able to be filled. With possible future changes, it will mean there will be a lot of parameters to this method. Do you think it would be an issue? I was thinking about introducing a SubscriptionItemBuilder but I don't know if it's worth it, and I don't know what could an elegant api for this class.
Of course, we will also need to update docs, upgrade guides, etc. Who does that?
I'm afraid I have to say that at the moment we're considering not to support this in Cashier in the future because of the following: https://stripe.com/guides/strong-customer-authentication
We're currently looking at implementing PaymentIntents which would be needed for payments with Stripe for the EU in the future. The article says the following about metered billing:
While subscription payments are often periodic and directed to the same business, an increasing number of companies charge variable amounts (also known as metered billing). Unless regulatory authorities agree to categorize those transactions as merchant-initiated transactions, these types of payments would not be covered by this exemption.
So unless something on Stripe's end changes about this we're probably not going to support it anytime soon.
Got it, thanks for the feedback.
The lack of clarity regarding this new EU regulation and variable recurring payments is a real pain in the butt.
Can I ask, would charging customers via subscription-based invoicing be compliant? My understanding is that it would be. And does Cashier support creating subscriptions with the send_invoice billing type? https://stripe.com/docs/billing/invoices/sending#subscription
Can I ask, would charging customers via subscription-based invoicing be compliant?
From what I understand now it will be although the docs/migration guide on moving to PaymentIntents at the moment mostly cover one-off charges. We're currently waiting a bit longer with moving forward on migrating until Stripe has released more info on moving from a subscription based flow.
And does Cashier support creating subscriptions with the send_invoice billing type?
Not at the moment. You might want to create a separate issue with this feature request.
The article linked above has been updated. https://stripe.com/en-US/guides/strong-customer-authentication
It appears that variable subscriptions will now be categorized as merchant-initiated, and that Payment Intents will cover the use case.
Yep although it comes with some concerns that the bank may still refuse the authorization in some cases. So it's still not 100% covered. But I feel like we may now reconsider metered billing for sure.
@pylebecq are you planning on picking this back up?
In any case, please wait with doing any work on this until v10 is released unless you want to rewrite stuff. v10 will change quite a bit of the internals.
@BeingTomGreen Probably not, sorry.
@driesvints What's the timeframe for V10? Would it be possible to have multi plan support included in the release?
@kyranb no specific timeline. Multi plan probably won't make it into the release since I'm focussing on the SCA stuff atm.
I ran into this. I commented out
L263 in
vendor\laravel\cashier\srcSubscriptionBuilder.php 'quantity' => $this->quantity, and the subscription worked.
You can't really comment out lines from vendor files, especially in production.
You need to override the $quantity property in SubscriptionBuilder, because it defaults to 1 which triggers an error for metered plans. Fortunately you can do this quite simply:
$user->newSubscription('default', 'plan_XXX')
->quantity(0)
->create($request->get('payment_method'))
@driesvints, @pylebecq any updates on this? looks like v10 is out (10.5.3 is the current version)
i need to start implementing a solution quite soon. so i will need to start working on it asap, so if you have any work on it so far, i would like to contribute to that
@thejacer87 I need to tackle multiplan first which will lay the foundation for possible metered billing support. I can't make any promises at this moment when that'll be.
no worries @driesvints, correct me if im wrong, or oversimplifying, but if the stripe docs say you just need to send SubscriptionItem::createUsageRecord. and it looks like that method was added in #694
seems like the only thing i would need to do, is call ->quantity(0) when creating the new subscription. (all this assuming i have already manually set up the metered usage in the stripe GUI)
We'll need to keep track of subscription items in the database for this to work. It's a bit more complicated than that.
If someone still needs a workaround on creating subscription for metered plan using builtin functions, here's a trick:
$plan = \Laravel\Spark\Spark::activePlans()
->where('id', 'metered')
->first();
\Auth::user()
->newSubscription('default', $plan->id)
->plan($plan->id, null)
->create();
Any updates on this?
@driesvints any update on this? Is there an open PR that we can help with? Thanks!
Anyone's free to send in PRs. However, we will only accept high quality ones which fully implement this feature.
Updating from Cashier 10 to 12.
The workaround https://github.com/laravel/cashier-stripe/issues/555#issuecomment-526958326 of adding ->quantity(0) no longer works (for me at least). The error says You cannot set the quantity on metered plans
And trying the workaround https://github.com/laravel/cashier-stripe/issues/555#issuecomment-635699631 of ->plans($plan_id, null) gives me this error:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'quantity' cannot be null (SQL: insert into `subscription_items` (`stripe_id`, `stripe_plan`, `quantity`, `subscription_id`, `updated_at`, `created_at`)
I assume because the new subscription_items table, the quantity is not nullable.
wondering if anyone has upgraded cashier recently, and got it to work...?
@thejacer87 I need to tackle multiplan first which will lay the foundation for possible metered billing support. I can't make any promises at this moment when that'll be.
@driesvints so now that multiplan is implemented, is this on the roadmap? what sort of things would you be expecting in the PR. Subscription items are now in the DB, so shouldn't it be pretty simple now?
I don't have time atm to deep dive into what's needed for this sorry. It's best that the Stripe docs and api docs on metered billing are read very carefully so a thorough PR can be worked out. It's been a while since I looked at it so I don't know for sure what's exactly needed at this point.
My workaround for this was to allow SubscriptionItems.quantity to be nullable.
This allows for passing in null as the quantity which allows the subscription to be created.
After creating the metered plan, I update the SubscriptionItems.quantity to be 0.
You then have to use the Stripe usage API to increment though.
Most helpful comment
You can't really comment out lines from vendor files, especially in production.
You need to override the
$quantityproperty in SubscriptionBuilder, because it defaults to 1 which triggers an error for metered plans. Fortunately you can do this quite simply: