Nova Stripe Laravel Package

Product Decisions This Supports

• Build vs. buy for internal revenue visibility — re-scoped by v3. The package is no longer a thin read-only view over the Stripe API. v3.0.0 is a complete rewrite that synchronizes Stripe Products, Customers, Charges, and Subscriptions into your own database and exposes them as full Nova resources with search, filters, and pagination. That moves the internal-build estimate from ~1–2 engineer-days (a dashboard card) to something closer to 1–2 engineer-weeks (sync jobs, schema, idempotency, backfill, failure handling, permission scoping). The build-vs-buy question is now genuinely non-trivial, and the package is a much stronger buy — but it is also a much bigger commitment than v2.
• Reducing internal support load — still the core value, now broader. Finance, support, and ops get searchable, filterable, paginated Stripe records inside the admin panel they already use. v3 meaningfully upgrades this: "find the charge for this customer" and "show me subscriptions by status" become real workflows instead of a glanceable card. That is a stronger answer to ad-hoc "can you check Stripe?" requests.
• Operational monitoring, still not financial reporting. Synchronized records with filters improve payout/charge triage and "did this customer actually get charged?" flows. It still does not deliver reconciliation, revenue recognition, refund/dispute workflows, cohort/MRR analysis, or export-driven finance reporting. The sync is a local mirror, not a ledger — treat freshness and completeness as best-effort.
• New decision this release forces: data stewardship. You are now storing customer PII and payment metadata in your own database. That introduces retention policy, access control, backup/restore, and possibly data-residency or compliance review — none of which applied to v2. This is a product/legal decision, not just an engineering one, and should be surfaced explicitly before adoption.
• Sync freshness is now a product concern. With on-the-fly retrieval, data was always current. With synchronization, "how stale is this screen?" becomes a user-facing question. You need a scheduled sync cadence, a backfill/initial-import story, and a visible answer for "the data looks wrong" — otherwise ops will lose trust in the panel faster than they would have with no panel at all.
• Roadmap de-prioritization signal — strengthened, with a caveat. The scope jump makes this a clearer "close the backlog item" move than v2 was: you are unlikely to build this well internally for a convenience feature. Counterweight: a total rewrite at a major version is a maturity signal worth noting — expect churn, and expect v2 → v3 to be a re-install rather than an upgrade.
• Tooling consolidation bet. Unchanged in direction, stronger in effect: the more Stripe surface Nova covers, the more it reinforces Nova as the single pane of glass. If Nova is being evaluated or deprecated, this package should not factor into that decision at all.

When to Consider This Package

Adopt when:

• You are already running Laravel Nova in production and pay its per-site license — the marginal license cost is still effectively zero.
• The need is "searchable, filterable internal visibility into Stripe customers, charges, subscriptions, and products" — a superset of v2's glanceable card, and a legitimate reason to prefer this over custom code.
• You are prepared to own a synchronized copy of Stripe data: migrations, a scheduled sync job, backfill on install, monitoring for failed syncs, and a retention policy for customer PII now living in your database.
• You can issue a restricted, read-only Stripe key and gate every Nova resource behind permissions — revenue data should not be visible to every admin-panel user by default.
• You are on Laravel 11 or can verify compatibility; v3 explicitly adds Laravel 11 support, which was a gap before.
• You are a small team comfortable pinning a version and tracking a single-maintainer org's release cadence.

Look elsewhere when:

• You are not on Nova. Nothing here changes that; Filament, Backpack, or a Cashier-backed page each need bespoke work.
• You need finance-grade capability: Stripe Sigma, the Stripe Dashboard's reporting, or a dedicated tool (ChartMogul, Baremetrics, Stripe Revenue Recognition) for MRR, cohort, churn, and reconciliation.
• You need alerting or anomaly detection (failed payouts, charge spikes) — that's webhooks plus your own monitoring, not synced records in Nova.
• You cannot store payment/customer data locally — data-residency, PCI-adjacent, or compliance constraints that v2's on-the-fly reads sidestepped. This is the single biggest new disqualifier introduced by v3.
• You need customer-facing billing (Stripe Billing Portal, Cashier) — different problem entirely.
• You are mid-migration on Nova 4 → 5 or unwilling to run an upgrade spike; v3 is a rewrite, so plan for a fresh install and validation rather than an in-place bump.

Risk note: v3.0.0 is a ground-up rewrite with a new contributor as primary author, released as a major version — feature parity with v2 is not guaranteed and edge-case regressions are plausible in the first few patch releases. Combined with zero dependents and a single-maintainer-org cadence, community validation remains thin. MIT plus a still-modest surface area keeps forking or vendoring credible. Nova major-version compatibility remains the most likely breakage point; add sync correctness and Stripe API version drift as a second. Verify both in staging before committing, and wait for at least one patch release if the timeline allows.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed add-on that puts searchable Stripe customers, charges, subscriptions, and products inside the admin panel ops and finance already use. The new major version is a substantial capability upgrade over the glanceable-card version — it behaves like a real Nova resource, with search, filters, and pagination — which removes more recurring interruptions to engineering. Two things changed materially: the scope is now large enough that building it ourselves would cost weeks rather than days, strengthening the buy case; and it now keeps a synchronized copy of Stripe data in our database, which brings a data-stewardship and access-control dimension that did not exist before. It remains a convenience and operations layer, not a finance system of record — reporting and reconciliation stay in Stripe and our analytics tools. Cost is still roughly zero in licensing and infrastructure terms.

To engineering: Correction to the earlier read: this is no longer read-only and no longer schema-free. v3 is a complete rewrite that synchronizes Stripe records locally and exposes them as Nova resources, so adoption means migrations, a scheduled sync job, an initial backfill, and monitoring for sync failures. Writes still do not go back to Stripe — the Stripe key stays restricted and read-only — but the data does land in our database, so PII retention and per-resource Nova permissions need explicit decisions. Upside: Laravel 11 support is now included, and search/filter/pagination are real. Plan for a fresh install rather than a v2 upgrade, validate Nova-version and sync correctness in staging, pin the version, and expect a couple of patch releases before it settles. Removal is no longer free — it now includes a table cleanup — but is still straightforward.