Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I want to use Laravel Cashier but also want to plan for future and code to an Interface so that I can later on swap if needed with different Billing Provider.
I have checked Laravel Cashier's Billable Contract (vendor/laravel/cashier/src/Laravel/Cashier/Contracts/Billable) and found a few methods that every class implementing the Billable Interface must adhere to.
public function expired();
public function onPlan($plan);
public function requiresCardUpFront();
public function readyForBilling();
public function stripeIsActive();
public function setStripeIsActive($active = true);
public function deactivateStripe();
public function getStripeId();
public function setStripeId($stripe_id);
public function getStripeSubscription();
// .... etc
Why would the Billable Contract specify methods that make it linked only to Stripe? How can I design on my end some interface can I will implement the current Laravel Cashier, but also allow for future changes?
Because laravel cashier uses stripe and built for stripe. Unless you are going to make PayPal use stripes database columns etc. Payment gateways aren't something you really can easily swap if your running subscriptions. What are you going to do when the user wants to renew?
An option is to use stripes PHP and build your own or swap out the use statements in your model to a different namespace.
Billable contract is a contract in name only. In reality, it's an implementation of Stripe subscriptions.
If you want to support other payment options, I would suggest not using Cashier. Cashier is fundamentally designed for Stripe payments only.
Alternatively, you could use Cashier as your Stripe implementation, and maybe connect it to your own billing interface via an adaptor. But honestly, once you've gone to the trouble of creating your own vendor-neutral payment logic, you might as well just write your own Stripe implementation.
You absolutely can have implementations for multiple payment gateways, but you will need to sort out your core payment logic.
That means you will need to decide what basic operations are required/supported in your payment system. For example, I have decided that a user must be able to cancel their subscription without leaving my website. This becomes part of my SubscriptionManagerInterface, and any implementations must provide that feature.
@Mike Hopley explained it better, but just to clear, because you coded to an interface doesn't mean you can easily swap out payment gateways. Meaning you have 2000 subscriptions on stripe and now you want to NOT use stripe and switch to Paypal. So you made the action of the swap easier but like swaping to a different database software, the code isn't arguably the hard part it's the migrating of the data.
I gathered from the term swap that's what the op meant.
Meaning you have 2000 subscriptions on stripe and now you want to NOT use stripe and switch to Paypal.
Yes, that's definitely an important concern.
When you already have subscriptions from a previous gateway, you need to maintain at least part of the code related to that gateway.
For example, I used to take subscriptions via Worldpay and "classic Paypal". I am no longer accepting new subscriptions from these, but I do have to maintain the code that processes their payment webhooks (for example).
It helps a lot if you can minimise (or perhaps I should say isolate) the gateway-specific code in your application.
@jekinney "swap" is a broad term. More specifically, I meant that I might want to ADD/REMOVE a new billing provider(s) and ditch something that does not suit my business needs. For example, I put everything on Stripe and in 2 years they decide to go for 10% and $1 per charge (just and example, hope this never happens :D). If I put "all my money" on Stripe I would start losing a lot and my manager would not be very happy with me if I cannot easily go for another provider.
If your using subscriptions which is cashiers main purpose, the swapping of payment gateways is the least of your worries. Like I said, you'll have to require the users to swap too or be left out. If it's a e-commerce where one time payments not as big of an issue, unless you store c/c info then again your asking your users to re-enter data. With people already worried about data theft, you're app will suffer.
But in the eCommerce case cashier may not fit the bill anyways. With stripes PHP API literally wrap three of stripes methods and your done. That case would be easier to swap out.
Please or to participate in this conversation.