Nova Cashier Manager Laravel Package

Getting Started

• Check your stack before anything else. Last release 2018-09-03, so this targets Laravel 5.6/5.7, Cashier 7/8, and Nova 1.x. Run composer show laravel/nova — if you're on Nova 4 or 5, stop here. There is no upgrade path; port the tool's handful of queries into a Nova Resource or Action instead.
• Prerequisites on a legacy install: Cashier installed and migrated (subscriptions, and subscription_items if you're on Cashier 7+), your billable model (App\User) using Laravel\Cashier\Billable, and valid STRIPE_KEY / STRIPE_SECRET in .env.
• Install: composer require themsaid/nova-cashier-manager. Expect dependency constraints to drag old Cashier/Nova versions — pin them and confirm with composer why laravel/nova.
• Register the tool in app/Providers/NovaServiceProvider.php:

  public function tools()
  {
      return [
          new \Themsaid\CashierManager\CashierManager,
      ];
  }
  

  Then php artisan nova:publish / view:clear if the menu doesn't show up.
• First use case: support triage. A CS agent searches a customer, sees whether the subscription is active, on grace period, or canceled, and hits cancel/resume — without opening tinker or handing out Stripe Dashboard access. That is the entire value of the package; scope your evaluation to it.

Implementation Patterns

• Treat it as a read-mostly view over the subscriptions table, not as source of truth. The tool reads the local DB. The DB is only correct if your Stripe webhook endpoint and Cashier's WebhookController are wired up. Get webhooks healthy first, or the UI will lie to you.
• Gate visibility per panel. Register the tool conditionally so only admins see it:

  public function tools()
  {
      return auth()->user()?->isAdmin()
          ? [new \Themsaid\CashierManager\CashierManager]
          : [];
  }
  

  This is the minimum bar — the default registration exposes cancel/resume to every Nova user who can load the panel.
• Pair it with Nova Actions for anything workflow-shaped. Rather than letting people poke the tool, expose "Cancel at period end" / "Resume" actions on your User resource that call $user->subscription('default')->cancel() / ->resume(). You get audit trails, confirmation modals, and queueing for free.
• Keep a local price → label map. Plan names shown in the UI come from raw Stripe plan/price strings. If your product team knows "monthly_pro" but the UI renders price_1H..., add a lookup (config array or a plans table) and surface friendly names.
• Link from the User resource. Add a HasMany (Laravel\Nova\Fields\HasMany::make('Subscriptions')) on the billable model so people reach the tool from a customer record instead of hunting through a global list.
• Reconciliation pattern: schedule a nightly job or Nova command that loops $user->subscriptions and calls asStripeSubscription() to resync stripe_status / ends_at. The tool can't do this for you, and drift between Stripe and your DB is the #1 source of confusing UI states.

Gotchas and Tips

• Archived = frozen. No fixes for Nova/PHP/Stripe API changes, no security patches. Budget for a fork or replacement the moment you touch it.
• Cancellation is one click and irreversible-ish. The tool has no built-in role check beyond Nova's access gate — anyone who can see the tool can cancel any customer's subscription. Verify canSee/tool registration before it goes near production.
• Cashier 9+ renames break it. Cashier moved stripe_plan → stripe_price and added stripe_status. Any query or display in the tool that assumes the 2018 column names will silently return nulls or throw. Same for subscription_items vs the old single-plan model.
• Multiple billable models / multi-tenant are not handled. The tool assumes a single App\User-style billable. If you have model_type polymorphism or per-model Stripe accounts (Cashier 12+), you'll need to fork the queries.
• Three subscription states, not two. active(), onGracePeriod() (cancelled but still paid through ends_at), and canceled() (period over). Bugs happen when cancel/resume buttons are shown for the wrong state — check ends_at is in the future before offering "Resume", and be explicit about ends_at timezones (stored UTC, displayed in app timezone).
• Performance on large tables: add indexes on subscriptions.user_id and subscriptions.stripe_id if they're missing; the listing screens are unpaginated-ish and will crawl at scale.
• Debugging checklist: php artisan route:list | grep nova-vendor to confirm the tool's endpoints registered; browser Network tab for failing AJAX (usually a 500 from a missing Cashier column); storage/logs/laravel.log for the Stripe-side exception. If the menu entry is missing entirely, it's almost always a cached Nova service provider or a canSee returning false.
• Extension point: subclass the tool and override its card/list component if you need filtering by plan or tenant — the Vue side is easy, but keep the fork on a tagged branch so you can diff against upstream if you ever need to.
• Honest alternative: a nova-resource over subscriptions plus two Actions covers 90% of this package's surface area with Nova 4/5 support and no archived dependency. For a new project, do that instead.