Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi,
I built an app a year or so using Laravel Spark, but that decision is catching up with me, specifically around billing and active accounts. Basically, I never should have used Spark, as I need flexible billing options (i.e. they mail me a check), and subscriptions that cover flexible dates (i.e. people pay annual subscriptions for one calendar year like 2019, not Jun-Jun).
Long story short, having laravel Spark handle subscriptions is causing all kinds of problems for me, and I am wondering if anybody has had any experience or has found any resources on decoupling Spark for payments and billing.
I just want to be able to set my own flag for if someone is subscribed, rather than checking some Stripe or credit card thing.
I appreciate any ideas or shared experience! Thanks in advance
Decoupling spark probably isnt easy given the FAQ says it's not designed to integrate with existing apps so I guess the inverse is true
Not sure if you could hook into the event/middleware system to acheive what you need
https://spark.laravel.com/docs/8.0/billing#checking-subscription-status-via-middleware
I'm not brilliant with spark so take my advice with a huge pinch of salt and there might be a better/easier option
@d9705996 thanks for the thoughts on it, and the links.
Yeah, I expect it to be real messy, given its keeping user data on the subscription on the front end and the back end, so middleware and Vue objects. Not looking forward to this at all!
@TONSOFLAZ - If you have a good test suite then it should nt be too painful to switch to something like cashier
It might be worth reacing out to Taylor with details of your issue as he might be able to point you in the right direction so you can keep using spark
I've been contemplating this from the opposite end as I am just starting out with Spark. I've been digging deep and the reality is, as others have suggested, that everything between the Laravel side and the Vue side is strongly related - of course!
I have gone from being okay with Laravel from about 3 years ago, to being pretty comfortable with Spark in a few weeks, while also learning a lot of other stuff at the same time.
I think it's really worth investing the time to learn about how Spark works and why; the Vue 2 course here on Laracasts will get you to close to where you need to be, I am up to episode 31, but found myself more than capable of understanding a significant amount of everything in Spark from a few episodes earlier and being able to implement my own components and hook them into the Laravel side. If you work through the examples there, then go and look at the code I think you will be very pleasantly surprised.
If you then look for all the files related to billing it should become clear how you may add additional billing methods. As I say I haven't done this yet, but my initial investigations didn't make me run away in horror. It's actually very clean.
Yes, there will be confusing moments and hours of frustration along the way, but if you already have an application built in Spark I can only see a huge rewards for your time and effort.
I will check in occasionally and do what I can to help if you decide to go ahead and keep posting your findings here. Feel free to tag me so I get a notification.
When you get there you will see how good Spark really is!
@tonsoflaz I recently built a SaaS app for a client using Spark and they had a similar requirement. They had a ton of existing customers and while we were able to get around 85% of them onto the new subscription based payments, the rest are old and stuck in their ways and still wanted to pay by check. This method may not work for you. It depends upon one thing, if you're using trials for newly registered customers or not. If you are, then this might not work.
Basically how I handled it, was I built a custom user management page and added the ability to manually set the trial expiration date. On the users table there is a column "trial_ends_at". If the user is not subscribed, then in my management system I can set that date field to a future date. So if I want to give a user 6 months of time, I just change that date and set it to 6 months in the future. This allows them full access to your app using the standard built in subscription and trialing system without changing the underlying system. I then renamed all the public instances of the word "trialing" to be "pre-paid". So to a customer they just see that they have pre-paid time until that trial time ends.
It is a really easy way to fix this problem as long as you aren't using the standard trial system for newly registered users. Hope that gives you an idea of how to move forward.
@gcwilliams Thanks very much for this, I may go that route if I keep Spark in some fashion. It is extremely useful to know you have done it before, and thank you for sharing!
Just read about someone in your similar situation who outgrew Spark.
If it were me, I wouldn't try to hack major changes into Spark. Start fresh with a version 2.0 instead.
This guy switched to PHP Lumen as the REST API and VueJS as the frontend, that would be my choice too:
https://medium.com/once-upon-a-site/why-we-chose-laravel-spark-and-later-dropped-it-55552309d7bd
Please or to participate in this conversation.