Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ralphmorris's avatar

Laravel Cashier or Custom Stripe Integration as per Jeffrey's tutorials

I have been following the How to Accept Payment tutorials as a bit of research before getting started on integrating Stripe into my project. The tutorials are brilliant.

However I have also looked at the Laravel Cashier tutorial which is also great and looks like a lot of the hard work is done for you. So I'm wondering which approach other developers have opted for in terms of doing your own Stripe integration and Subscriptions API or using Laravel Cashier?

The main things that are important to me are:

  • An understanding of how everything works.
  • Reliable, easy to maintain (hopefully low maintainance) in the long term.

This is my first transactional website where I am working from scratch so want to make sure I choose the right choice with longevity/maintenance in mind.

Any advice welcome.

Thanks

Ralph

0 likes
7 replies
stuartcusack's avatar

7 years for a response to a very relevant and important question; this post seem to have got lost in the laracasts database. I'm not much help but here's my two cents...

After many years with Laravel I still struggle deciding between two approaches: Cashier (stripe subscriptions) vs custom recurring charges.

I know Stripe Subscriptions and Cashier do a lot of the hard work for you but custom eloquent models have fewer limitations than the Stripe subscription model, and add to that Laravel queues, jobs, events and scheduled tasks; the Stripe PaymentIntents API combined with core Laravel features seems to cover everything that Stripe subscriptions provide, but with more flexibility.

Still I'm never sure which way to go and I pull my hair out for weeks before making a decision on each project. Currently I'm building one project with cashier and one with custom recurring charges. On the cashier project it's been quite difficult to handle bespoke features such as non auto-renewing subscriptions and gift subscriptions (museum membership). On the custom project I'm not confident that charges will keep working in the far future.

I'm more comfortable with the custom flow but the development community always pushes me towards Cashier and subscriptions. Maybe I'll realise why someday....

My current conclusion is that both approaches are valid and workable for most projects, but maybe, just maybe, I should avoid cashier and the stripe subscription model. I feel like any successful project will someday want to break out of the constraints that those models impose. Stripe subscriptions seem like a poor substitute for custom laravel stuff, but that implies that Cashier is an inferior approach. Take my words with a grain of salt because Taylor and Jeffrey have put a lot of work into cashier and the community consensus is to use cashier and stripe subscriptions.

martinbean's avatar

@stuartcusack I run two subscription-based SaaS projects, and I would hate the thought of having to code the subscription stuff myself.

I redirect customers to Stripe Checkout, they enter their payment details there, and then the webhooks take care of maintaining the subscriptions and their lifecycles.

Any custom code you write, is code you’re then creating an unofficial contract to maintain ever more going forward. So, you need to decide if you want to spend your time writing and maintaining a subscription billing solution, or if you’re just going to use an existing package made exactly for that purpose. I don’t know about you, but as a single-person business owner, I don’t want to spend my limited time reinventing the wheel and replicating Cashier’s feature set, when I can just use Cashier.

1 like
colbyalbo's avatar

I've had a handful of experiences with billing solutions. I used cashier for awhile, but ended up coding my own set of classes to work with the Stripe API/SDK. Both for single payments & subscriptions. For the subscriptions, I cant remember exactly what the issue I had with the Stripe subscriptions API, but i ended up ditching that, coding the recurring subscription logic myself also, and just used the stripe payments api to make the charges. I will admit, that WAS a boatload of work. I've also done the same with the Square Payments API. It was definitely a great learning experience for sure.

1 like
stuartcusack's avatar

Thanks for the feedback. Its clear that cashier and stripe subscriptions can be great timesavers for SaaS, but I'm not sure they are such a good match for something like a museum membership. Things like in-person payments (cash / cards), one-year memberships (non-renewing) and gift memberships don't fit very well into the Stripe subscription model.

I'm starting to think that I made a bad choice on that particular project by using Cashier, but I might be wrong. I'll know more in the near future and update this thread if I remember.

colbyalbo's avatar

@stuartcusack I was in the same situation a few years ago. My approach was to start a demo project to work through all the Stripe docs (Stripe and Square docs are solid) . And you can always review the source for Cashier to see how they do it. Good luck!

1 like
martinbean's avatar

I'm not sure they are such a good match for something like a museum membership. Things like in-person payments (cash / cards)

Stripe is a digital payment processor. So using Cashier or not is a bit of a moot point for in-person payments.

one-year memberships (non-renewing) and gift memberships don't fit very well into the Stripe subscription model.

Surely these are just products with one-time prices, that you can then capture payment for using a Stripe Checkout session?

stuartcusack's avatar

Stripe is a digital payment processor. So using Cashier or not is a bit of a moot point for in-person payments.

Indeed. When I made my first comment I was still unsure of what Stripe could do for in-person payments and if Stripe Subscriptions could still be used in this project.

In the end I went with a combination of Cashier, Stripe Subscriptions and a custom Membership model. Stripe webhooks interact with my custom membership model to create, extend and cancel memberships, as well as switch them to gift or non-gift. A Membership object can start off as cash-based then in future be connected to a Stripe subscription, and vice-versa.

There was so much custom code required that I'm still unsure on whether Cashier was a good choice for this particular project; simple Stripe Charges might have been a better fit for my Membership model; I guess time will tell. The cashier code has certainly been useful for designing my system and the way I'm using it seems to be fine.

Please or to participate in this conversation.