Installation

Three steps, and none of them touches a table of yours. There is no interface to implement, nothing to bind in a service provider, and no column to add to the model you bill.

1. The package

composer require edulazaro/larameter

The service provider registers itself. It merges the default config, binds UsageTracker as a scoped instance, and attaches the two observers that keep the balance in step with the rows.

2. The config

php artisan vendor:publish --tag=larameter-config

This one you do want published, because the defaults are a starting point rather than a working setup: one free plan of a thousand credits a month, three windows, and no prices at all. See Configuration reference.

3. The tables

php artisan vendor:publish --tag=larameter-migrations
php artisan migrate

Four tables, all prefixed larameter_, all with a foreign key back to the account and cascadeOnDelete. The stub is heavily commented, and reading it is the fastest way to understand what the package stores. See The data model.

Add the traits

Whatever you bill, be it an organisation, a workspace, a team or a user:

use EduLazaro\Larameter\Concerns\HasCredits;
use EduLazaro\Larameter\Concerns\HasMeters;
use EduLazaro\Larameter\Concerns\HasPlans;

class Organization extends Model
{
    use HasCredits, HasPlans, HasMeters;
}

They are three because they answer three questions, and only the first is required:

The account row appears the first time you touch it. There is nothing to seed and no event to hook into when a customer signs up.

Naming the plans

A plan is one allowance figure, plus optional limits and features:

// config/larameter.php
'plans' => [
    'free' => ['credits_monthly' => 1_000],
    'pro'  => [
        'credits_monthly' => 50_000,
        'limits'   => ['members' => 25],
        'features' => ['api_access' => true],
    ],
],

If your plans already live somewhere else, and in most projects they do, point the package at that file instead of copying the numbers. See Plans.

Checking the install

$org = Organization::first();

$org->credits()->remaining();   // the allowance of the default plan
$org->plan()->handle;           // 'free'
$org->credits()->windows();     // one WindowUsage per declared window

None of those write anything. Reading a balance never opens a window, which matters more than it sounds and is the subject of Windows.

Upgrading an existing application

If you already have a usage table and are moving to this one, write your history straight into larameter_usage. The observer on that model applies every row to the balance as it is created, so a backfill cannot record consumption that nobody was charged for. If that is not what you want for a historical import, insert with the query builder rather than the model, and set credits_from_plan and credits_from_purchased yourself.