Listening For Events

There are a few different ways to listen for key events, and respond appropriately in your app. Let's start off with what's supposed by Laravel, ready...

Model Events

You can create model observers, using Artisan:

artisan make:observer ReceiptModelObserver --model=\\Gitstore\\Peddle\\Models\\ReceiptModel

This will create a new file, at app/Observers/ReceiptModelObserver. The official docs already describe the different ways to use those class, but the simplest would be to add it to your AppServiceProvider:

namespace App\Providers;

use App\Observers\ReceiptModelObserver;
use Gitstore\Peddle\Models\PeddleReceipt;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
    public function boot()

You can react to different model events, like:

  1. PeddleReceiptObserver->created(PeddleReceipt $model)
  2. PeddleReceiptObserver->updated(PeddleReceipt $model)
  3. PeddleReceiptObserver->deleted(PeddleReceipt $model)

Paddle Events

Then, there are events that only Paddle can trigger. These are things like when a subscription is created or a payment is received. Peddle dispatches these events as they are received, so you can slitter for them by adding listeners to your EventServiceProvider:

namespace App\Providers;

use Gitstore\Peddle\Events\PeddleSubscriptionCreatedEvent;
use Gitstore\Peddle\Events\PeddleSubscriptionCancelledEvent;
use App\Listeners\SubscriptionCreatedListener;
use App\Listeners\SubscriptionCancelledListener;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
    protected $listen = [
        PeddleSubscriptionCreatedEvent::class => [
        PeddleSubscriptionCancelledEvent::class => [

Event Lookup Table

Here are the models you can observe events on:

  • PeddleCustomer
  • PeddleReceipt
  • PeddleSubscription
  • PeddleUser
  • PeddleVerifiedUser

PeddleCustomer, PeddleReceipt, and PeddleSubscription are extensions of the Cashier Paddle models.

Depending in the config you set, when Installing Peddle; your app will either use PeddleUser or PeddleVerifiedUser. You shouldn't need to listen for events on both.

Here are events connected to user activity:

  • PeddleUserLoggedInEvent
  • PeddleUserRegisteredEvent
  • PeddleUserVerifiedEmailEvent
  • PeddleSubscriptionSwappedEvent

The user events are given an instance of the PeddleUser model. The "subscription swapped" event happens when a user switches to another plan or back to the free plan.

Here are the events that Paddle notifies us about, as long as you've set up webhooks for them in Paddle:

  • PeddleCustomerPaymentSucceededEvent
  • PeddleSubscriptionCancelledEvent
  • PeddleSubscriptionCreatedEvent
  • PeddleSubscriptionPaymentSuceededEvent
  • PeddleSubscriptionUpdatedEvent (this is also triggered on plan swap)

These are called with a customer or subscription, and a JSON payload. From there, you can find the appropriate user and plan.


Paddle webhook events are asynchronous, so you need to take that potential delay into account. On the Peddle site; we store a session timeout, so that we can allow the user access to premium features until the webhook message comes through:

session()->put('subscriptionChangedTo' . $planId, time());

You can compare this, in your own code, by calling a PeddleUser method:


...and customising the timeout by going to config/peddle.php and finding the webhook.timeout section. By default, Peddle will wait for 30 minutes before pushing the user back into "free" territory; if it still hasn't received the webhook message from Paddle.

If you're not getting webhook messages from Paddle, make sure you've configured them, and that the public URL in Paddle matches the APP_URL in .env; and that you've restarted artisan serve since you set APP_URL.

It should be something like (in Paddle), and APP_URL= in .env; unless you've changed the route prefix config.