| Package Data | |
|---|---|
| Maintainer Username: | driesvints |
| Package Create Date: | 2023-03-31 |
| Package Last Update: | 2024-11-19 |
| Home Page: | https://lemonsqueezy.com |
| Language: | PHP |
| License: | MIT |
| Last Refreshed: | 2024-12-15 15:23:37 |
| Package Statistics | |
|---|---|
| Total Downloads: | 33,659 |
| Monthly Downloads: | 2,717 |
| Daily Downloads: | 34 |
| Total Stars: | 521 |
| Total Watchers: | 7 |
| Total Forks: | 51 |
| Total Open Issues: | 14 |
A package to easily integrate your Laravel application with Lemon Squeezy. It takes the pain out of setting up a checkout experience. Easily set up payments for your products or let your customers subscribe to your product plans. Handle grace periods, pause subscriptions, or offer free trials.
This package drew inspiration from Cashier which was created by Taylor Otwell.
Lemon Squeezy for Laravel is maintained by Dries Vints. Any sponsorship to help fund development is greatly appreciated ❤️
We also recommend to read the Lemon Squeezy docs and developer guide.
The below features are not yet in this package but are planned to be added in the future:
There are a few steps you'll need to take to install the package:
We'll go over each of these below.
Install the package with composer:
composer require lemonsqueezy/laravel
Next, configure your API key. Create a new key in testing mode in the Lemon Squeezy dashboard and paste them in your .env file as shown below:
LEMON_SQUEEZY_API_KEY=your-lemon-squeezy-api-key
When you're deploying your app to production, you'll have to create a new key in production mode to work with live data.
Your store identifier will be used when creating checkouts for your products. Go to your Lemon Squeezy stores settings and copy the Store ID (the part after the # sign) into the env value below:
LEMON_SQUEEZY_STORE=your-lemon-squeezy-store-id
To make sure we can actually create checkouts for our customers, we'll need to configure a model to be our "billable" model. This is typical the User model of your app. To do this, import and use the Billable trait on your model:
use LemonSqueezy\Laravel\Billable;
class User extends Authenticatable
{
use Billable;
}
Now your user model will have access to methods from our package to create checkouts in Lemon Squeezy for your products. Note that you can make any model type a billable as you wish. It's not required to use one specific model class.
The package comes with some migrations to store data received from Lemon Squeezy by webhooks. It'll add a lemon_squeezy_customers table which holds all info about a customer. This table is connected to a billable model of any model type you wish. It'll also add a lemon_squeezy_subscriptions table which holds info about subscriptions. Install these migrations by simply running artisan migrate:
php artisan migrate
If you want to customize these migrations, you can overwrite them.
Lemon Squeezy uses its own JavaScript library to initiate its checkout widget. We can make use of it by loading it through the Blade directive in the head section of our app, right before the closing </head> tag.
<head>
...
@lemonJS
</head>
Finally, make sure to set up incoming webhooks. This is both needed in development as in production.
The easiest way to set this up while developing your app is with the php artisan lmsqueezy:listen command that ships with this package. This command will setup a webhook through the Lemon Squeezy API, start listening for any events and remove the webhook when quitting the command.
php artisan lmsqueezy:listen
Although this command should always cleanup the webhook after itself, you may wish to cleanup any lingering webhooks with the --cleanup flag:
php artisan lmsqueezy:listen --cleanup
Currently, this command supports Ngrok and Expose.
For production, we'll need to setup things manually. Go to your Lemon Squeezy's webhook settings and point the url to your app's domain. The path you should point to is /lemon-squeezy/webhook by default. Make sure to select all event types.
[!NOTE]
We also very much recommend to verify webhook signatures in production.
Incoming webhooks should not be affected by CSRF protection. To prevent this, add your webhook path to the except list of your App\Http\Middleware\VerifyCsrfToken middleware:
protected $except = [
'lemon-squeezy/*',
];
Please review our upgrade guide when upgrading to a new version.
The package offers various way to configure your experience with integrating with Lemon Squeezy.
By default, we don't recommend publishing the config file as most things can be configured with environment variables. Should you still want to adjust the config file, you can publish it with the following command:
php artisan vendor:publish --tag="lemon-squeezy-config"
In order to make sure that incoming webhooks are actually from Lemon Squeezy, we can configure a signing secret for them. Go to your webhook settings in the Lemon Squeezy dashboard, click on the webhook of your app and copy the signing secret into the environment variable below:
LEMON_SQUEEZY_SIGNING_SECRET=your-webhook-signing-secret
Any incoming webhook will now first be verified before being executed.
Lemon Squeezy for Laravel ships with some migrations to hold data sent over. If you're using something like a string based identifier for your billable model, like a UUID, or want to adjust something to the migrations you can overwrite them. First, publish these with the following command:
php artisan vendor:publish --tag="lemon-squeezy-migrations"
Then, ignore the package's migrations in your AppServiceProvider's register method:
use LemonSqueezy\Laravel\LemonSqueezy;
public function register(): void
{
LemonSqueezy::ignoreMigrations();
}
Now you'll rely on your own migrations rather than the package one. Please note though that you're now responsible as well for keeping these in sync withe package one manually whenever you upgrade the package.
With this package, you can easily create checkouts for your customers.
For example, to create a checkout for a single-payment, use a variant ID of a product variant you want to sell and create a checkout using the snippet below:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->checkout('variant-id');
});
This will automatically redirect your customer to a Lemon Squeezy checkout where the customer can buy your product.
[!NOTE] When creating a checkout for your store, each time you redirect a checkout object or call
urlon the checkout object, an API call to Lemon Squeezy will be made. These calls are expensive and can be time and resource consuming for your app. If you are creating the same session over and over again you may want to cache these urls.
You can also overwrite the amount of a product variant by calling the charge method on a customer:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->charge(2500, 'variant-id');
});
The amount should be a positive integer in cents.
You'll still need to provide a variant ID but can overwrite the price as you see fit. One thing you can do is create a "generic" product with a specific currency which you can dynamically charge against.
Instead of redirecting your customer to a checkout screen, you can also create a checkout button which will render a checkout overlay on your page. To do this, pass the $checkout object to a view:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
$checkout = $request->user()->checkout('variant-id');
return view('billing', ['checkout' => $checkout]);
});
Now, create the button using the shipped Laravel Blade component from the package:
<x-lemon-button :href="$checkout" class="px-8 py-4">
Buy Product
</x-lemon-button>
When a user clicks this button, it'll trigger the Lemon Squeezy checkout overlay. You can also, optionally request it to be rendered in dark mode:
<x-lemon-button :href="$checkout" class="px-8 py-4" dark>
Buy Product
</x-lemon-button>
If you're checking out subscriptions, and you don't want to show the "You will be charged..." text, you may disable this by calling the withoutSubscriptionPreview method on the checkout object:
$request->user()->subscribe('variant-id')
->withoutSubscriptionPreview();
If you want to set a different color for the checkout button you may pass a hex color code (with the leading # sign) through withButtonColor:
$request->user()->checkout('variant-id')
->withButtonColor('#FF2E1F');
You can easily prefill user data for checkouts by overwriting the following methods on your billable model:
public function lemonSqueezyName(): ?string; // name
public function lemonSqueezyEmail(): ?string; // email
public function lemonSqueezyCountry(): ?string; // country
public function lemonSqueezyZip(): ?string; // zip
public function lemonSqueezyTaxNumber(): ?string; // tax_number
By default, the attributes displayed in a comment on the right of the methods will be used.
Additionally, you may also pass this data on the fly by using the following methods:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->checkout('variant-id')
->withName('John Doe')
->withEmail('john@example.com')
->withBillingAddress('US', '10038') // Country & Zip Code
->withTaxNumber('123456679')
->withDiscountCode('PROMO');
});
You can overwrite additional data for product checkouts with the withProductName and withDescription methods:
$request->user()->checkout('variant-id')
->withProductName('Ebook')
->withDescription('A thrilling novel!');
Additionally, you can customize the thank you note for the order receipt email.
$request->user()->checkout('variant-id')
->withThankYouNote('Thanks for your purchase!');
To redirect customers back to your app after purchase, you may use the redirectTo method:
$request->user()->checkout('variant-id')
->redirectTo(url('/'));
You may also set a default url for this by configuring the lemon-squeezy.redirect_url in your config file:
'redirect_url' => 'https://my-app.com/dashboard',
In order to do this you'll need to publish your config file.
You can indicate how long a checkout session should stay active by calling the expiresAt method on it:
$request->user()->checkout('variant-id')
->expiresAt(now()->addDays(3));
You can also pass along custom data with your checkouts. To do this, send along key/value pairs with the checkout method:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->checkout('variant-id', custom: ['foo' => 'bar']);
});
These will then later be available in the related webhooks for you.
When working with custom data there are a few reserved keywords for this library:
billable_id
billable_type
subscription_type
Attempting to use any of these will result in an exception being thrown.
Customers may easily manage their personal data like their name, email address, etc by visiting their customer portal. Lemon Squeezy for Laravel makes it easy to redirect customers to this by calling redirectToCustomerPortal on the billable:
use Illuminate\Http\Request;
Route::get('/customer-portal', function (Request $request) {
return $request->user()->redirectToCustomerPortal();
});
In order to call this method your billable already needs to have a subscription or made a purchase through Lemon Squeezy. Also, this method will perform an underlying API call so make sure to place this redirect behind a route which you can link to in your app.
Optionally, you also get the signed customer portal url directly:
$url = $user->customerPortalUrl();
Besides the customer portal for managing subscriptions, Lemon Squeezy also has a "My Orders" portal to manage all of your purchases for a customer account. This does involve a mixture of purchases across multiple vendors. If this is something you wish your customers can find, you can link to https://app.lemonsqueezy.com/my-orders and tell them to login with the email address they performed the purchase with.
Lemon Squeezy allows you to retrieve a list of all orders made for your store. You can then use this list to present all orders to your customers.
To retrieve a list of orders for a specific customer, simply call the saved models in the database:
<table>
@foreach ($user->orders as $order)
<td>{{ $order->ordered_at->toFormattedDateString() }}</td>
<td>{{ $order->order_number }}</td>
<td>{{ $order->subtotal() }}</td>
<td>{{ $order->discount() }}</td>
<td>{{ $order->tax() }}</td>
<td>{{ $order->total() }}</td>
<td>{{ $order->receipt_url }}</td>
@endforeach
</table>
To check if an individual order is paid, you may use the paid method:
if ($order->paid()) {
// ...
}
Besides that, you have three other checks you can do: pending, failed & refunded. If the order is refunded, you may also use the refunded_at timestamp:
@if ($order->refunded())
Order {{ $order->order_number }} was refunded on {{ $order->refunded_at->toFormattedDateString() }}
@endif
You can also check if an order was for a specific product:
if ($order->hasProduct('your-product-id')) {
// ...
}
Or for a specific variant:
if ($order->hasVariant('your-variant-id')) {
// ...
}
Additionally, you may check if a customer has purchased a specific product:
if ($user->hasPurchasedProduct('your-product-id')) {
// ...
}
Or a specific variant:
if ($user->hasPurchasedVariant('your-variant-id')) {
// ...
}
These two checks will both make sure the correct product or variant was purchased and paid for. This is useful as well if you're offering a feature in your app like lifetime access.
Setting up subscription products with different plans and intervals needs to be done in a specific way. Lemon Squeezy has a good guide on how to do this.
Although you're free to choose how you set up products and plans, it's easier to go for option two and create a product for each plan type. So for example, when you have a "Basic" and "Pro" plan and both have monthly and yearly prices, it's wiser to create two separate products for these and then add two variants for each for their monthly and yearly prices.
This gives you the advantage later on to make use of the hasProduct method on a subscription which allows you to just check if a subscription is on a specific plan type and don't worry if it's on a monthly or yearly schedule.
Starting subscriptions is easy. For this, we need the variant id from our product. Copy the variant id and initiate a new subscription checkout from your billable model:
use Illuminate\Http\Request;
Route::get('/subscribe', function (Request $request) {
return $request->user()->subscribe('variant-id');
});
When the customer has finished their checkout, the incoming SubscriptionCreated webhook will couple it to your billable model in the database. You can then retrieve the subscription from your billable model:
$subscription = $user->subscription();
Once a customer is subscribed to your services, you can use a variety of methods to check for various states on the subscription. The most basic example, is to check if a customer is subscribed to a valid subscription:
if ($user->subscribed()) {
// ...
}
You may use this in various places in your app like middleware, policies, etc, to offer your services. To check if an individual subscription is valid, you may use the valid method:
if ($user->subscription()->valid()) {
// ...
}
This method, as well as the subscribed method, will return true if your subscription is active, on trial, past due, paused for free or on its cancelled grace period.
You can also check if a subscription is on a specific product:
if ($user->subscription()->hasProduct('your-product-id')) {
// ...
}
Or on a specific variant:
if ($user->subscription()->hasVariant('your-variant-id')) {
// ...
}
If you want to check if a subscription is on a specific variant and at the same valid you can use:
if ($user->subscribedToVariant('your-variant-id')) {
// ...
}
Or if you're using multiple subscription types, you can pass a type as an extra parameter:
if ($user->subscribed('swimming')) {
// ...
}
if ($user->subscribedToVariant('your-variant-id', 'swimming')) {
// ...
}
To check if a user has cancelled their subscription you may use the cancelled method:
if ($user->subscription()->cancelled()) {
// ...
}
When they're on their grace period, you can use the onGracePeriod check:
if ($user->subscription()->onGracePeriod()) {
// ...
}
If a subscription is fully cancelled and no longer on its grace period, you may use the expired check:
if ($user->subscription()->expired()) {
// ...
}
If a recurring payment for a subscription fails, the subscription will transition in a past due state. This means it's still a valid subscription but your customer will have a 2 weeks period where their payments will be retried.
if ($user->subscription()->pastDue()) {
// ...
}
In this state, you should instruct your customer to update their payment info. Failed payments in Lemon Squeezy are retried a couple of times. For more information on that, as well as the dunning process, head over to the Lemon Squeezy documentation
Various subscriptions scopes are available to query subscriptions in specific states:
// Get all active subscriptions...
$subscriptions = Subscription::query()->active()->get();
// Get all of the cancelled subscriptions for a specific user...
$subscriptions = $user->subscriptions()->cancelled()->get();
Here's all available scopes:
Subscription::query()->onTrial();
Subscription::query()->active();
Subscription::query()->paused();
Subscription::query()->pastDue();
Subscription::query()->unpaid();
Subscription::query()->cancelled();
Subscription::query()->expired();
To allow your customer to update their payment details, like their credit card info, you can redirect them with the following method:
use Illuminate\Http\Request;
Route::get('/update-payment-info', function (Request $request) {
$subscription = $request->user()->subscription();
return view('billing', [
'paymentMethodUrl' => $subscription->updatePaymentMethodUrl(),
]);
});
Alternatively, if you want the URL to open in a more seamless way on top of your app (similar to the checkout overlay), you may use Lemon.js to open the URL with the LemonSqueezy.Url.Open() method. First, pass the url to a view:
use Illuminate\Http\Request;
Route::get('/update-payment-info', function (Request $request) {
$subscription = $request->user()->subscription();
return view('billing', [
'paymentMethodUrl' => $subscription->updatePaymentMethodUrl(),
]);
});
Then trigger it through a button:
<script defer>
function updatePM() {
LemonSqueezy.Url.Open('{!! $paymentMethodUrl !!}');
}
</script>
<button onclick="updatePM()">
Update payment method
</button>
This requires you to have set up Lemon.js.
When a customer is subscribed to a monthly plan, they might want to upgrade to a better plan, change their payments to a yearly plan or downgrade to a cheaper plan. For these situations, you can allow them to swap plans by passing a different variant id with its product id to the swap method:
use App\Models\User;
$user = User::find(1);
$user->subscription()->swap('product-id', 'variant-id');
This will swap the customer to their new subscription plan but billing will only be done on the next billing cycle. If you'd like to immediately invoice the customer you may use the swapAndInvoice method instead:
$user = User::find(1);
$user->subscription()->swapAndInvoice('product-id', 'variant-id');
[!NOTE] You'll notice in the above methods that you both need to provide a product ID and variant ID and might wonder why that is. Can't you derive the product ID from the variant ID? Unfortuntately that's only possible when swapping to variants between the same product. When swapping to a different product alltogether you are required to also provide the product ID in the Lemon Squeezy API. Therefor, we've made the decision to make this uniform and just always require the product ID as well.
By default, Lemon Squeezy will prorate amounts when changing plans. If you want to prevent this, you may use the noProrate method before executing the swap:
$user = User::find(1);
$user->subscription()->noProrate()->swap('product-id', 'variant-id');
To change the date of the month on which your customer gets billed for their subscription, you may use the anchorBillingCycleOn method:
$user = User::find(1);
$user->subscription()->anchorBillingCycleOn(21);
In the above example, the customer will now get billed on the 21st of each month going forward. For more info, see the Lemon Squeezy docs.
In some situation you may find yourself wanting to allow your customer to subscribe to multiple subscription types. For example, a gym may offer a swimming and weight lifting subscription. You can allow your customer to subscribe to either or both.
To handle the different subscriptions you may provide a type of subscription as the second argument to subscribe when starting a new one:
$user = User::find(1);
$checkout = $user->subscribe('variant-id', 'swimming');
Now you may always refer this specific subscription type by providing the type argument when retrieving it:
$user = User::find(1);
// Retrieve the swimming subscription type...
$subscription = $user->subscription('swimming');
// Swap plans for the gym subscription type...
$user->subscription('gym')->swap('product-id', 'variant-id');
// Cancel the swimming subscription...
$user->subscription('swimming')->cancel();
To pause subscriptions, call the pause method on it:
$user = User::find(1);
$user->subscription()->pause();
Optionally, provide a date when the subscription can resume:
$user = User::find(1);
$user->subscription()->pause(
now()->addDays(5)
);
This will fill in the resumes_at timestamp on your customer. To know if your subscription is within its paused period you can use the onPausedPeriod method:
if ($user->subscription()->onPausedPeriod()) {
// ...
}
To unpause, simply call that method on the subscription:
$user->subscription()->unpause();
By default, pausing a subscription will void its usage for the remainder of the pause period. If you instead would like your customers to use your services for free, you may use the pauseForFree method:
$user->subscription()->pauseForFree();
To cancel a subscription, call the cancel method on it:
$user = User::find(1);
$user->subscription()->cancel();
This will set your subscription to be cancelled. If your subscription is cancelled mid-cycle, it'll enter a grace period and the ends_at column will be set. The customer will still have access to the services provided for the remainder of the period. You can check for its grace period by calling the onGracePeriod method:
if ($user->subscription()->onGracePeriod()) {
// ...
}
Immediate cancellation with Lemon Squeezy is not possible. To resume a subscription while it's still on its grace period, call the resume method:
$user->subscription()->resume();
When a cancelled subscription reaches the end of its grace period it'll transition to a state of expired and won't be able to resume any longer.
For a thorough read on trialing in Lemon Squeezy, have a look at their guide.
To allow people to signup for your product without having them to fill out their payment details, you may set the trial_ends_at column when creating them as a customer:
use App\Models\User;
$user = User::create([
// ...
]);
$user->createAsCustomer([
'trial_ends_at' => now()->addDays(10)
]);
This is what's called "a generic trial" because it's not attached to any subscription. You can use the onTrial method to check if a customer is currently trialing your app:
if ($user->onTrial()) {
// User is within their trial period...
}
Or if you specifically also want to make sure it's a generic trial, you can use the onGenericTrial method:
if ($user->onGenericTrial()) {
// User is within their "generic" trial period...
}
You can also retrieve the ending date of the trial by calling the trialEndsAt method:
if ($user->onTrial()) {
$trialEndsAt = $user->trialEndsAt();
}
As soon as your customer is ready, or after their trial has expired, they may start their subscription:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->subscribe('variant-id');
});
Please note that when a customer starts their subscription when they're still on their generic trial, their trial will be cancelled because they have started to pay for your product.
Another option is to require payment details when people want to trial your products. This means that after the trial expires, they'll immediately be subscribed to your product. To get started with this, you'll need to configure a trial period in your product's settings. Then, let a customer start a subscription:
use Illuminate\Http\Request;
Route::get('/buy', function (Request $request) {
return $request->user()->subscribe('variant-id');
});
After your customer is subscribed, they'll enter their trial period which you configured and won't be charged until after this date. You'll need to give them the option to cancel their subscription before this time if they want.
To check if your customer is currently on their free trial, you may use the onTrial method on both the billable or an individual subscription:
if ($user->onTrial()) {
// ...
}
if ($user->subscription()->onTrial()) {
// ...
}
To determine if a trial has expired, you may use the hasExpiredTrial method:
if ($user->hasExpiredTrial()) {
// ...
}
if ($user->subscription()->hasExpiredTrial()) {
// ...
}
To end a trial with payment upfront early you may use the endTrial method on a subscription:
$user = User::find(1);
$user->subscription()->endTrial();
This method will move the billing achor to the current day and thus ending any trial period the customer had.
Lemon Squeezy can send your app webhooks which you can react on. By default, this package already does the bulk of the work for you. If you've properly set up webhooks, it'll listen to any incoming events and update your database accordingly. We recommend enabling all event types so it's easy for you to upgrade in the future.
To listen to incoming webhooks, we have two events that will be fired:
LemonSqueezy\Laravel\Events\WebhookReceived
LemonSqueezy\Laravel\Events\WebhookHandled
The WebhookReceived will be fired as soon as a webhook comes in but has not been handled by the package's WebhookController. The WebhookHandled event will be fired as soon as the webhook has been processed by the package. Both events will contain the full payload of the incoming webhook.
If you want to react to these events, you'll have to create listeners for them. For example, you may want to react to a subscription being updated:
<?php
namespace App\Listeners;
use LemonSqueezy\Laravel\Events\WebhookHandled;
class LemonSqueezyEventListener
{
/**
* Handle received Lemon Squeezy webhooks.
*/
public function handle(WebhookHandled $event): void
{
if ($event->payload['meta']['event_name'] === 'subscription_updated') {
// Handle the incoming event...
}
}
}
For an example payload, take a look at the Lemon Squeezy API docs.
Once you have a listener, wire it up in your app's EventServiceProvider:
<?php
namespace App\Providers;
use App\Listeners\LemonSqueezyEventListener;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;
use LemonSqueezy\Laravel\Events\WebhookHandled;
class EventServiceProvider extends ServiceProvider
{
protected $listen = [
WebhookHandled::class => [
LemonSqueezyEventListener::class,
],
];
}
Instead of listening to the WebhookHandled event, you may also subscribe to one of the following, dedicated package events that are fired after a webhook has been handled:
LemonSqueezy\Laravel\Events\OrderCreated
LemonSqueezy\Laravel\Events\OrderRefunded
LemonSqueezy\Laravel\Events\SubscriptionCreated
LemonSqueezy\Laravel\Events\SubscriptionUpdated
LemonSqueezy\Laravel\Events\SubscriptionCancelled
LemonSqueezy\Laravel\Events\SubscriptionResumed
LemonSqueezy\Laravel\Events\SubscriptionExpired
LemonSqueezy\Laravel\Events\SubscriptionPaused
LemonSqueezy\Laravel\Events\SubscriptionUnpaused
LemonSqueezy\Laravel\Events\SubscriptionPaymentSuccess
LemonSqueezy\Laravel\Events\SubscriptionPaymentFailed
LemonSqueezy\Laravel\Events\SubscriptionPaymentRecovered
LemonSqueezy\Laravel\Events\LicenseKeyCreated
LemonSqueezy\Laravel\Events\LicenseKeyUpdated
All of these events contain a billable $model instance and the event $payload. The subscription events also contain the $subscription object. These can be accessed through their public properties.
Check out the CHANGELOG in this repository for all the recent changes.
Lemon Squeezy for Laravel is open-sourced software licensed under the MIT license.