Recently, I decided to tackle the persistent Wi-Fi range issues in my home. I had been using a TP-Link Archer AX73 router, which delivered great speeds but couldn't provide sufficient coverage throughout the house. Dead zones and weak signals were becoming daily frustrations, hindering everything from streaming movies to working remotely.

To address these problems, I invested in a TP-Link Deco X60 mesh system with three units. I was excited about the promise of seamless Wi-Fi coverage and better connectivity. However, integrating the new hardware wasn't as straightforward as I anticipated.

This is the story of how I set up the Deco X60 mesh network, the challenges I encountered—like losing access to my home server—and how I overcame them by learning about IP addresses, DHCP ranges, and the crucial role of subnet masks in network configuration.

The Initial Setup

My home network consisted of:

• Router: TP-Link Archer AX73

• Home Server: Set to a static IP address 192.168.1.100

• Issue: Wi-Fi coverage was spotty in certain areas of the house

I relied on my home server for various tasks, accessible via SSH at 192.168.1.100. However, the limited Wi-Fi range of the AX73 meant that devices in other parts of the house couldn't maintain a stable connection.

Introducing the Deco X60 Mesh System

To resolve the Wi-Fi coverage problem, I replaced the AX73 with a TP-Link Deco X60 mesh system, installing three units around my home. The expectation was that the mesh network would provide seamless Wi-Fi coverage everywhere.

Setting Up the Deco X60

• Connected the Main Deco Unit: Hooked it up to my modem.

• Placed Additional Units: Positioned the other two Deco units strategically around the house.

• Used the Deco App: Followed the in-app instructions to set up the network.

After the initial setup, Wi-Fi coverage was indeed much better. However, a new problem arose: I couldn't access my home server anymore.

The Problem: Unable to Access Home Server

Even though devices were connected to the new mesh network, I couldn't SSH into my home server at 192.168.1.100. I was not able ping the server or access the Proxmox panel.

Troubleshooting Steps

1. Updating the Deco X60's IP Address

I suspected that the issue was related to IP addressing, as the Deco X60 was accessible at 192.168.68.1. I decided to update the IP address of the main deco unit.

• Accessed the Deco App:

  • Opened the app on my smartphone.

• Navigated to Network Settings:

  • Went to the 'More' tab and selected 'Advanced'.

• Changed the LAN IP Address:

  • Selected 'LAN IP'.

  • Updated the LAN IP to 192.168.1.1, matching the IP of my old AX73 router.

2. Adjusting the DHCP Range

Since we changed the IP address, I decided to change DHCP range to as well.

• Accessed DHCP Settings:

  • Still in the 'Advanced' section, I selected 'DHCP Server'.

• Updated the DHCP IP Range:

  • Changed the IP range from 192.168.1.50 to 192.168.3.250.

• Saved the Settings:

  • Applied the changes to ensure all devices could obtain IP addresses within this range.

Result After Changes

After updating the LAN IP and DHCP range, I was able to ping the home server at 192.168.1.100. Hurray!!! 🎉

However, when I tried SSH in to server, I received following error when attempting to connect.

kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.1.100 port 22

The Solution: Fixing the Subnet Mask

It dawned on me that the subnet mask might be causing devices to think they were on different networks, even though their IP addresses were correct this time.

I saw subnet mask was configured to 255.255.0.0 in Deco X60. So I decided to change it & give it a try.

Updating the Subnet Mask on the Deco X60

• Accessed LAN IP Settings:

  • In the Deco app, under 'Advanced' > 'LAN IP'.

• Set the Subnet Mask:

  • Changed it to 255.255.255.0.

Verifying the Server's Network Configuration

• Checked the Server's Subnet Mask:

  • Ensured it was also set to 255.255.255.0.

• Confirmed the Default Gateway:

  • Made sure the server's gateway was 192.168.1.1.

Restarting Devices

Restarted my home server, computers, and any other network devices to apply the new settings.

Success at Last

After fixing the subnet mask, everything started working as expected. I could SSH into my home server at 192.168.1.100 without any issues. The network was now correctly configured, and all devices could communicate seamlessly.

What I Learned

This entire process was a significant learning experience. I'm not a networking expert, but I gained valuable insights:

• The Importance of Subnet Masks:

  • The subnet mask must be consistent across devices to ensure they're on the same network.

• Consistent IP Configuration:

  • Updating the router's IP to match the old configuration prevented conflicts.

• Adjusting DHCP Range:

  • Ensuring the DHCP range accommodates all devices is crucial, especially with multiple units.

• Patience in Troubleshooting:

  • Networking issues can be complex; methodically checking each setting helps identify the problem.

Conclusion

Switching to a mesh network with the Deco X60 significantly improved my home's Wi-Fi coverage. However, the journey wasn't without its challenges. By updating the LAN IP, adjusting the DHCP range, and fixing the subnet mask, I was able to resolve the connectivity issues with my home server.

This experience taught me the critical role that subnet masks and proper network configurations play in a home network. While I'm not an expert, I now have a better understanding of how these settings impact device communication.

Tips for Others:

• Check Default Network Settings: New routers may have default IPs and subnet masks that differ from your existing setup.

• Ensure Consistent Subnet Masks: This ensures all devices are recognized on the same network.

• Adjust DHCP Ranges as Needed: Especially important when adding multiple units to your network.

• Don't Hesitate to Learn: Troubleshooting can be a great learning opportunity.

Upgrading your home network can bring significant benefits, and with a bit of patience and willingness to learn, you can overcome any hurdles along the way.

Laravel Sanctum is a package made by Taylor Otwell which solves this issue by using a special kind of cookies called HttpOnly cookies. These cookies are set by the server, and cannot be read by the JavaScript code running on the client-side aka browser. When these cookies are set by the server, the browser automatically sends these cookies back to the server with every request, and thus the server knows it an authorized request.

Laravel Sanctum also takes care of CSRF protection by including CSRF cookie in each request. And also protects your site against XSS based attacks.

Introduction

In this tutorial, we will build a sample Nuxt.js application which will demo the authentication flow using Laravel sanctum. We are going to build our Nuxt application in the SPA (Single page application) mode. If you want to deploy your application in universal (SSR - Server-side rendered) mode, you can still do it.

Authentication in the Nuxt using Laravel sanctum does work in SSR mode. But it doesn't make much sense if your application running SSR mode if the application requires login to access and search engine can access your site without a login.

SPA and Backend domains

To work with Sanctum, we should be familiar with a few things first. We must use our SPA and API backend on the same domain, like frontend on domain.com and API on api.domain.com. We cannot set frontend on domain.com and backend (API) on another-domain.com. The client must be able to include cookies with each request being sent to the backend.

Please check out Mozilla developer documentation on withCredentials & article by Mohamed Said on Authentication and Laravel Sanctum for information on session using cookies.

Here is my little advice, when you are developing the Nuxt site in local, use php artisan serve command to serve Laravel backend at http://localhost:8000 instead of using valet like sanctum-nuxt.test.

Setting up Laravel Sanctum

Enough of theory! Let's begin by setting up Laravel sanctum for your Laravel application. Just follow these steps carefully to configure your app.

In your Laravel 7 app, install the sanctum package using composer:

composer require laravel/sanctum

Next, publish sanctum configuration & database migration files.

php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"

Then, we will need to run our migration to create personal_access_tokens table, which will be used by Sanctum to save access tokens for the users.

php artisan migrate

Since we are using Sanctum for our SPA, we need to make sure that our HTTP request pass through Sanctum middleware. Configure api middleware group in app/Http/Kernel.php to use Sanctum middleware.

// FILE: app/Http/Kernel.php

use Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful;

protected $middlewareGroups = [
  ...
  'api' => [
      EnsureFrontendRequestsAreStateful::class, // Add & import this class
      'throttle:60,1',
      \Illuminate\Routing\Middleware\SubstituteBindings::class,
  ],
];

Next, let's configure domains for our SPA. To make sure our SPA works with Sanctum, set the appropriate values for SESSION_DOMAIN and SANCTUM_STATEFUL_DOMAINS inside .env file at the root of our application.

SESSION_DOMAIN="localhost"
SANCTUM_STATEFUL_DOMAINS="localhost"

Also, make sure our SPA domain is configured and have set supports_credentials to true in CORS config/cors.php.

// FILE: config/cors.php

return [
    ...
    'paths' => ['*'],
    'allowed_origins' => ['http://localhost:3000'],
    'supports_credentials' => true,
    ...
];

And our last step should be to use Sanctum auth middleware auth:sanctum to protect our routes like this in routes/api.php.

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
    return $request->user();
});

And we are done! Now that we have finished setting up our API backend with Sanctum. Let's proceed for setting up our Nuxt SPA app to use our API.

Nuxt application setup

Let's begin by setting up the Nuxt.js app first, and then the Laravel-based API backend using Sanctum. Before that, let me provide you a little information on how to set up your domains to work with the Sanctum's SPA authentication.

Create a new Nuxt.js project by entering the following command in your terminal.

npx create-nuxt-app your-project-name

Next, setup will ask you a series of questions, answers them as your preferences.

? Project name: sanctum-nuxt
? Project description: My fantastic Nuxt.js project
? Author name: Swapnil Bhavsar
? Choose the package manager: Npm
? Choose UI framework: Tailwind CSS
? Choose custom server framework: None (Recommended)
...

When setup asks for choosing Nuxt.js modules, be sure toggle axios the option, We will need it, so that our Nuxt app can make HTTP requests.

? Choose Nuxt.js modules (Press <space> to select, <a> to toggle all, <i> to invert selection)
- Axios

In the final step, choose the Single Page App when setup asks for, choose rendering mode. Of course, you can also choose to render your app in the universal mode. But for the scope of this tutorial, we will deploy our app in the spa mode.

? Choose rendering mode (Use arrow keys)
- Single Page App

Auth module

The Auth module is an official package provided by the Nuxt.js community which adds authentication support for the Nuxt.js app. It provides helper objects like $auth, which can be used to log in a user or access an authenticated user.

To allow our app to authenticate with our API backend, we will need to create an auth strategy scheme in the auth section of nuxt.config.js. But before that, we need to install the Auth Module.

Install the Auth module by running the following command in terminal:

npm install @nuxtjs/auth

Then, register the auth module in nuxt.config.js like this:

modules: [
  '@nuxtjs/axios',
  '@nuxtjs/auth'
],
auth: {
  // Options
}

Before proceeding to configuring the auth module, set baseURL and credentials options for the axios section in nuxt.config.js. Setting credentials: true will include cookies in the HTTP request made to the server.

axios: {
  baseURL: "http://localhost:8000",
  credentials: true
},

Next, configure the auth module in nuxt.config.js to authenticate with our Laravel application endpoints like this:

auth: {
  redirect: {
    login: '/login',
    logout: '/',
    callback: '/login',
    home: '/'
  },
  strategies: {
    local: {
      endpoints: {
        login: { url: '/login', method: 'post', propertyName: false },
        user: { url: '/api/user', method: 'get', propertyName: false }
      },
      tokenRequired: false,
      tokenType: false
    }
  },
  localStorage: false
},

After adding the local strategy in the auth section, let's proceed to creating a login page for our Nuxt app.

Creating a login page

Create a file called login.vue under the pages directory in your Nuxt.js project with the following content. Before loading, it sends a request to /sanctum/csrf-cookie path so that the server could initialize CSRF protection for the application. It also has a login form which uses $auth.loginWith a function provided by the auth module to submit the login form.

<template>
  <div class="flex h-screen items-center justify-center">
    <form ref="loginform" @submit.prevent="login()" class="w-1/4 mx-auto p-4">
      <h1 class="font-semibold mb-2 text-xl">
        Login
      </h1>
      <div class="mb-4">
        <label for="email" class="block mb-1 text-sm">Email</label>
        <input
          type="email"
          name="email"
          class="w-full border rounded px-3 py-2"
          required
        />
      </div>
      <div class="mb-4">
        <label for="password" class="block mb-1 text-sm">Password</label>
        <input
          type="password"
          name="password"
          class="w-full border rounded px-3 py-2"
          required
        />
      </div>
      <button
        type="submit"
        class="bg-blue-500 text-white font-semibold py-2 px-10 w-full rounded"
      >
        Login
      </button>
    </form>
  </div>
</template>

<script>
  export default {
    data() {
      return {
        error: {},
      };
    },
    mounted() {
      // Before loading login page, obtain csrf cookie from the server.
      this.$axios.$get('/sanctum/csrf-cookie');
    },
    methods: {
      async login() {
        this.error = {};
        try {
          // Prepare form data
          const formData = new FormData(this.$refs.loginform);

          // Pass form data to `loginWith` function
          await this.$auth.loginWith('local', { data: formData });

          // Redirect user after login
          this.$router.push({
            path: '/',
          });
        } catch (err) {
          this.error = err;
          // do something with error
        }
      },
    },
  };
</script>

Access authenticated user

You can access the authenticated user data by using this.$auth.user. For example, create an account.vue the page which will show the user's information like this in the /page directory.

<template>
  <div>
    <p>Name: {{ $auth.user.name }}</p>
    <p>Name: {{ $auth.user.email }}</p>
  </div>
</template>

<script>
  export default {
    middleware: 'auth',
  };
</script>

You can use auth middleware to make sure that your pages are only accessible by authenticated users. You can find more information on using middleware here: https://auth.nuxtjs.org/guide/middleware.html

Conclusion

This is a bare minimum example for you to get started with authentication in Nuxt.js using Laravel Sanctum. I am pretty amazed by the simplicity provided by the Sanctum package over Laravel Passport when implementing API authentication for your applications.

This was my first article on my blog, hope you will find it useful. You can ask me questions or send feedback about the article on Twitter @swapnil_bhavsar.

By default, Laravel Cashier assumes the App\Model\User class as a Billable model. We can configure it to use a different model, but in our case, there were two different models. So, I had to follow a different approach.

CASHIER_MODEL=App\Models\User

PS: This will be a long tutorial! I will explain everything from creating models, updating migrations, configuring webhooks, etc.

But if you are rushing, here is your solution, the trick is to set Cashier's billable model at the runtime using the config helper function.

config(['cashier.model' => 'App\Models\Seller']);

Initial Setup

Let's start by assuming that our application has two billable models, a User, and Seller. Both models will have subscriptions. There can be multiple ways to use cashier with multiple models, but for simplicity, we are going to store the details of their subscription in separate tables.

Let's start by installing the Cashier package for Stripe first.

composer require laravel/cashier

The cashier will use subscriptions and subscription_items tables to store information about the user's subscriptions. Let's publish Cashier's default migrations so that we can take over a look at the table structure.

php artisan vendor:publish --tag="cashier-migrations"

Now we should have the following files in our database/migrations directory.

1. 2019_05_03_000001_create_customer_columns.php

2. 2019_05_03_000002_create_subscriptions_table.php

3. 2019_05_03_000003_create_subscription_items_table.php

These files contain schema information about the subscriptions table. Don't worry about them, we will come to these files later.

The User model setup

First, let's set up our first billable model, User with Cashier. Add Billable trait to our first billable model which at App\Models\User.

use Laravel\Cashier\Billable;

class User extends Authenticatable
{
    use Billable;
}

This user model is going to have its subscription information stored in the subscriptions table.

Next, let's create our second billable model & add migrations for it.

The Seller model setup

Our Seller model will have subscriptions like the User model. But, we need to set up a few more things than just adding a Billable trait to our model. We will need to add migrations, configure auth guard, etc. for the Seller model.

Along with the Seller model, we will create two more models, SellerSubscription & SellerSubscriptionItem. The SellerSubscription will hold the subscription information for the Seller model, and the SellerSubscriptionItem model will be responsible for holding the Multiplan Subscriptions.

In short, we are going to need the following models & tables for our Seller model.

1. The Seller model with sellers table.

2. The SellerSubscription model with seller_subscriptions table.

3. The SellerSubscriptionItem model with seller_subscription_items table.

Let's start by generating our model using the following artisan command. Also, generate model & migrations files by adding the -m flag to our command.

php artisan make:model Seller -m

It should generate these two files at the following locations.

1. Seller.php (In /app/models directory) - The Seller model

2. 2021_XX_XX_XXXXXX_create_sellers_table.php (In /database/migrations directory) - The migration file

Now, let's set up our Seller model. Just like the User model we need to add the Billable trait to our Seller model sitting at App\Models\Seller.

use Laravel\Cashier\Billable;

class Seller extends Authenticatable
{
    use Billable;
}

In the migration file (2021_XX_XX_XXXXXX_create_sellers_table.php) for creating the sellers table, add the following schema content. We will also bring columns we got from 2019_05_03_000001_create_customer_columns.php after publishing Cashier's default migrations.

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateSellersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('sellers', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();

            // Stripe Cashier's columns
            $table->string('stripe_id')->nullable()->index();
            $table->string('card_brand')->nullable();
            $table->string('card_last_four', 4)->nullable();
            $table->timestamp('trial_ends_at')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('sellers');
    }
}

We are almost finished with our Seller model. But we still need to add seller specific subscriptions model and migration.

The SellerSubscription model setup

By default, subscription information for model App\Models\User will be stored in the subscriptions table. By using the Billable trait we are instructing Laravel, the User model will have a hasMany relation with the Laravel\Cashier\Subscription model. We can confirm that by the ManagesSubscriptions trait.

Here in the Laravel\Cashier\Concerns\ManagesSubscriptions trait, we can see the subscriptions method, which defines hasMany relation with the Laravel\Cashier\Subscription model.

use Laravel\Cashier\Subscription;

public function subscriptions()
{
    return $this->hasMany(Subscription::class, $this->getForeignKey())->orderBy('created_at', 'desc');
}

So, we are going to create a class called SellerSubscription which extends the Laravel\Cashier\Subscription model & inherits its properties.

In your console run the following command to generate the SellerSubscription model & migration.

php artisan make:model SellerSubscription -m

This will generate the following files.

1. SellerSubscription.php (In /app/models directory)

2. 2021_XX_XX_XXXXXX_create_seller_subscriptions_table.php (In /database/migrations directory)

The SellerSubscriptionItem model setup

Our User model has Multiplan Subscriptions stored in the subscription_items table. Then why should we leave the Seller model behind? Let's add multi-plan subscriptions functionality to the Seller model by defining a new model called SellerSubscriptionItem.

Let's generate the SellerSubscriptionItem model along with migration by running the following command in the terminal.

php artisan make:model SellerSubscriptionItem -m

This command should generate the following files.

1. SellerSubscriptionItem.php (In /app/models directory)

2. 2021_XX_XX_XXXXXX_create_seller_subscription_items_table.php (In /database/migrations directory)

Next, modify the SellerSubscription class slightly to extend Laravel\Cashier\Subscription class. And also define belongsTo relation with the Seller class as well as hasMany relation with the SellerSubscriptionItem class.

<?php

namespace App\Models;

use Laravel\Cashier\Subscription;
use Illuminate\Database\Eloquent\Factories\HasFactory;

class SellerSubscription extends Subscription
{
    use HasFactory;

    public function owner()
    {
        return $this->belongsTo(Seller::class);
    }

    public function items()
    {
        return $this->hasMany(SellerSubscriptionItem::class);
    }
}

Next, also modify SellerSubscriptionItem class to extend Laravel\Cashier\SubscriptionItem class. And define belongsTo relation with the SellerSubscription class like this.

<?php

namespace App\Models;

use Laravel\Cashier\SubscriptionItem;
use Illuminate\Database\Eloquent\Factories\HasFactory;

class SellerSubscriptionItem extends SubscriptionItem
{
    use HasFactory;

    public function subscription()
    {
        return $this->belongsTo(SellerSubscription::class);
    }
}

Now, it's time to take inspiration from Cashier's default migration, and update migrations for seller_subscriptions and seller_subscription_items accordingly.

Update migration 2021_XX_XX_XXXXXX_create_seller_subscriptions_table.php for seller_subscriptions table with the following schema structure. Pay attention to referencing key seller_id & modify it according to your custom model.

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateSellerSubscriptionsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('seller_subscriptions', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('seller_id');
            $table->string('name');
            $table->string('stripe_id');
            $table->string('stripe_status');
            $table->string('stripe_plan')->nullable();
            $table->integer('quantity')->nullable();
            $table->timestamp('trial_ends_at')->nullable();
            $table->timestamp('ends_at')->nullable();
            $table->timestamps();

            $table->index(['seller_id', 'stripe_status']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('seller_subscriptions');
    }
}

Next, also update migration 2021_XX_XX_XXXXXX_create_seller_subscription_items_table.php for seller_subscription_items with the following schema structure. And also pay attention to referencing key seller_subscription_id & modify it according to your custom subscription item model.

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateSellerSubscriptionItemsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('seller_subscription_items', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('seller_subscription_id');
            $table->string('stripe_id')->index();
            $table->string('stripe_plan');
            $table->integer('quantity');
            $table->timestamps();

            // Short key name to support 64 character limit- http://dev.mysql.com/doc/refman/5.5/en/identifiers.html
            $table->unique(['seller_subscription_id', 'stripe_plan'], 'seller_subscription_id_stripe_plan_unique');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('seller_subscription_items');
    }
}

After defining the SellerSubscription and SellerSubscriptionItem models, define a hasMany relation by adding the subscriptions method on the Seller class.

And finally, run the migration command to create/update tables in the database.

php artisan migrate

The Seller model

Now, modify the Seller model to override the subscriptions relation coming from the Billable trait. Instead of defining a relationship between the Laravel\Cashier\Subscription class, define it with App\Models\SellerSubscription.

Your finished seller model should look like this.

<?php

namespace App\Models;

use Laravel\Cashier\Billable;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Factories\HasFactory;

class Seller extends Model
{
    use HasFactory, Billable;

    public function subscriptions()
    {
        return $this->hasMany(SellerSubscription::class)->orderBy('created_at', 'desc');
    }
}

Next, let's set up Stripe webhooks for the Seller model. By default, the cashier will use the /stripe/webhook route to handle Stripe webhooks for the default configured model.

Webhooks for the Seller model.

Stripe can notify your application in case the customer's payment method declined and many such events. We need to ensure that our application is handling it. The Cashier package makes it easy by using the /stripe/webhook route to handle these events.

By default, it handles these events for the default configured model App\Models\User. In our case, we should register a different route the handle Stripe webhooks for our custom model.

First, generate a controller called SellerWebhookController using artisan command.

php artisan make:controller SellerWebhookController

Next, update SellerWebhookController by extending Laravel\Cashier\Http\Controllers\WebhookController class. And, also modify the getUserByStripeId method to use our custom model Seller.

<?php

namespace App\Http\Controllers;

use App\Models\Seller;
use Laravel\Cashier\Http\Controllers\WebhookController;

class SellerWebhookController extends WebhookController
{
    protected function getUserByStripeId($stripeId)
    {
        return Seller::where('stripe_id', $stripeId)->first();
    }
}

After controller, register a new route SellerWebhookController to handle webhook events coming from the Stripe.

use App\Http\Controllers\SellerWebhookController;

// Route for handling Stripe events
Route::post('/stripe/seller/webhook', [SellerWebhookController::class, 'handleWebhook']);

Next, in your Stripe control panel, you should enable the following webhooks for URL https://{yourapplication.com}/stripe/seller/webhook.

• customer.subscription.updated - When subscription is updated

• customer.subscription.deleted - When subscription is cancelled/deleted.

• customer.updated - When customer's information updated.

• customer.deleted - When a customer is deleted.

• invoice.payment_action_required - When action is required for the payment method. Typically, when the customer's card is declined.

That's it, our application is now ready to handle Stripe webhooks for the custom billable model Seller.

Configure auth guards & providers

In our application, sellers can authenticate themselves. So it makes sense to configure the Seller model to take advantage of Laravel's authentication functionality.

Start by registering a new User provider in the providers array in config/auth.php for our billable model Seller and also register a new guard in the guards array in config/auth.php file.

'guards' => [
        // ...

        'seller' => [
            'driver' => 'session',
            'provider' => 'sellers',
        ],
    // ...
],

// ...

'providers' => [
        // ...

        'sellers' => [
            'driver' => 'eloquent',
            'model' => App\Models\Seller::class,
        ],
    // ...
]

After this, we should able to retrieve our authenticated seller by using the $request->user('seller') helper.

Uses

With all the setup, we are finally ready to use our Seller model with the Cashier. Now we should be able to retrieve our authenticated seller using $request->user('seller') and override Cashier's default model using config helper.

// retrieve authenticated seller
$seller = $request->user('seller');

// override cashiers default model at the runtime
config(['cashier.model' => 'App\Models\Seller']);

Let's see it, how we can use it in actual code.

Creating a new Subscription

When creating a new subscription for our custom model Seller, retrieve it first by using the $request->user('seller') helper. And then set the cashier billable model to Seller at runtime using config helper.

use Illuminate\Http\Request;

Route::post('/seller/subscribe', function (Request $request) {
    config(['cashier.model' => 'App\Models\Seller']);

    $request->user('seller')->newSubscription(
        'default', 'price_premium'
    )->create($request->paymentMethodId);

    // ...
});

Retrieving Stripe Customer

When we need to retrieve a customer using Stripe ID, we should use Cashier::findBillable(). But before that don't forget to set Cashier's billable model using config helper.

use Laravel\Cashier\Cashier;

config(['cashier.model' => 'App\Models\Seller']);

$seller = Cashier::findBillable($stripeId);

Stripe Billing Portal

If you are using Stripe's billing portal in your application, you can redirect our custom Seller model to his billing portal like this.

use Illuminate\Http\Request;

Route::get('/billing-portal', function (Request $request) {
    // Override cashier's default model in case
    config(['cashier.model' => 'App\Models\Seller']);

    // Retrive authenticated seller
    $seller = $request->user('seller');

    return $seller->redirectToBillingPortal();
});

That's it! These are a few ways to use multiple models with the Cashier package. You can find more information about the Cashier in the documentation.

Summary

Laravel Cashier is a wonderful package for managing subscriptions in Laravel. Of course, there can be other ways to use Cashier with multiple models. This is one of the approaches you can use when you have more than two billable models.

Anyway, this was one long article, and thank you for going through the article! If you have questions about the article, then hit me up on Twitter @swapnil_bhavsar.

PS: Here is the source code for the project on GitHub - https://github.com/IamSwap/laravel-cashier-multiple-models