Nova Stripe Laravel Package

Technical Evaluation

Architecture fit

v2 was instrumentation: a Nova tool that called the Stripe API on render, held no state, and could not corrupt anything. v3 is a different class of component. It is a sync pipeline plus an admin UI: Stripe Products, Customers, Charges, and Subscriptions are replicated into the application's own database, then surfaced through native Nova resources with search, filters, and pagination.

That materially improves the product — search and filtering over local tables is exactly what made the Stripe Dashboard preferable to the old tool for anything beyond a glance at recent charges — but it changes the architectural contract:

• It now ships models and migrations. There is a schema, a backfill, and a rollback story.
• It introduces a background process (scheduled command and/or queued jobs, possibly a webhook receiver) that must run reliably and be monitored.
• It creates a second copy of customer PII and revenue data at rest in your database, inside your backup, retention, and erasure obligations.
• It can no longer be described as "cannot corrupt subscription/charge data." It still does not write to Stripe (verify this), so Stripe remains the system of record — but the local copy can now be wrong, stale, or incomplete in ways that look authoritative.

Adoption remains gated on a Nova licence, and now also on scheduler/queue infrastructure and a data-retention stance.

Integration feasibility

Still conventional, but no longer trivial — the day-one estimate now depends heavily on account size.

1. composer require tightenco/nova-stripe (pin to 3.0.x)
2. Publish config and migrations; run migrate
3. Supply a Stripe restricted read key covering products, customers, charges, subscriptions (plus a webhook signing secret if the sync is webhook-driven)
4. Configure and schedule the sync entrypoint; confirm queue workers are running
5. Run the initial backfill against Stripe test mode and measure duration and rate-limit headroom
6. Register the tool/resources in NovaServiceProvider
7. Gate visibility via Nova authorization / canSee

Effort: well under a day for wiring, plus a backfill window that scales with charge history — negligible for a small account, potentially hours of throttled job time for one with tens of thousands of charges and subscriptions.

Technical risk

Overall: moderate, up from low-to-moderate. The correctness and security risks have moved from "an operator sees something they shouldn't" to "the org stores PII it did not previously store and trusts a copy that may be stale."

The v3 rewrite significantly raises the package's value: the reason to keep a browser tab on the Stripe Dashboard was that the old tool could not answer "find this customer's charges." That gap is now closed. The cost is that a convenience mirror has become a data store.

Key questions

• What is the sync cadence, and is it incremental (cursor/created watermark) or a full re-pull? Incremental is the difference between a viable and an unviable large-account install.
• Polling or webhooks? Webhooks give freshness but add an internet-facing endpoint and a signing secret to manage.
• Does the sync ever write back to Stripe? Confirm read-only before enabling in production.
• What is the retention and erasure policy for the local copy, and how does a Stripe customer deletion propagate? If it doesn't, you own orphaned PII.
• Who owns monitoring the sync job, and what alert fires when it stops? Silence is the primary failure mode.
• Upgrade path from v2: drop-and-reinstall (treating local data as disposable cache) versus in-place? Strongly prefer the former.
• Multi-account / multi-currency: currency filtering was added, but is the schema per-account or application-global?
• Can the data volume and job duration be tolerated at current and 12-month projected charge counts?

Integration Approach

Stack fit

Laravel 10/11 (Laravel 11 support landed in this release, removing a real blocker), PHP 8.1+, Nova 4/5, Stripe PHP SDK — and now a scheduler and queue workers as hard prerequisites. Still assumes a single Stripe account per application instance; multi-tenant architectures mapping tenants to distinct Stripe accounts remain out of scope.

Migration path

This is now a genuine migration, not an additive install. Two migrations exist:

1. Package migration (v2→v3). Treat as a replacement, not an upgrade. Unpublish old config, publish new config and migrations, run the sync from scratch. The local tables are a cache — do not attempt to preserve them.
2. Operational migration. The team's mental model must shift from "live Stripe view" to "synced snapshot." Publish a one-line rule: the Stripe Dashboard is authoritative; the Nova view is a fast, searchable mirror that may lag by up to one sync interval. Put that in the tool's own description text if the package allows it.

Compatibility

• Pin to an exact 3.0.x version. 3.0.0 is a ground-up rewrite; expect 3.0.1+ correctness fixes in the first weeks. If the schedule permits, install at 3.0.x rather than .0.
• Validate against the actual Nova major in production — the rewrite touches Nova resource APIs, so Nova 4 compatibility no longer implies Nova 5.
• Verify scheduler and queue workers exist in every environment, including staging.
• Keep config and published migrations in-repo so schema and credential changes are reviewable in PRs.
• Confirm the Stripe SDK's pinned API version against the account default; a sync job that misreads a status field fails quietly.

Sequencing

1. Qualify — Nova licence and major, current charge volume, and whether finance/ops actually prefer this over the Dashboard now that search exists.
2. Credential design — Stripe restricted key, read-only, scoped to products/customers/charges/subscriptions; separate keys per environment; webhook secret if applicable.
3. Retention review — legal/security sign-off on storing customer PII locally before the first production sync, including erasure handling.
4. Staging install — test mode, migrations, full backfill; measure duration and rate-limit headroom against production volume.
5. Authorization — canSee/policy gating on every resource before production; unchanged as the highest-blast-radius step.
6. Monitoring — alert on sync job failure, on last-successful-sync age, and on row-count anomalies.
7. Production pilot — named ops/finance cohort, not all Nova users.
8. Review — after 2–4 weeks, decide keep / restrict / replace.

Operational Impact

Maintenance

Meaningfully higher than v2, and the increase is structural rather than cosmetic. You now own: composer upgrades on every Laravel/Nova bump, schema migrations on package upgrades, sync job health, queue worker capacity, credential rotation, Stripe API version reviews, and a data-retention obligation that did not previously exist. Budget roughly a half-day per Laravel/Nova major upgrade plus a migration review, not the few hours v2 required. The zero-dependents problem persists: no ecosystem pressure forces the maintainer to track Nova releases, so a pin-and-fork scenario remains plausible.

Support

MIT, community-supported via GitHub issues, no SLA, single-vendor stewardship. The rewrite is a positive signal — it is real engineering investment, not abandonment — and the arrival of additional contributors is mildly reassuring. But 3.0.0 is a new code path with a small user base; expect to self-diagnose sync problems. The exit cost has risen: v2 could be replaced by a ~100-line Nova card, whereas replacing v3 means rebuilding a sync pipeline plus UI — a few days, not an afternoon. Evaluate that cost explicitly at install time rather than assuming the old escape hatch still applies.

Scaling

The read path improved dramatically: Nova now queries local indexed tables, so search and pagination are fast and independent of Stripe latency. This eliminates the v2 timeout-behind-a-load-balancer concern entirely.

The write path is the new constraint:

• Backfill — initial sync duration scales with total charge/subscription history and is bounded by Stripe rate limits (~100 read ops/sec live, materially lower in test). Batch, throttle, and run off-peak.
• Ongoing sync — cost scales with daily delta, not total volume, provided sync is incremental. Confirm this; a full re-pull per run will not scale.
• Storage — tables grow monotonically with charge history. Size them, index stripe_id, customer_id, and created, and decide whether to prune old records.
• Concurrency — guard against overlapping sync runs (withoutOverlapping) or you will get duplicate upserts and rate-limit contention.
• Horizontal app scaling is otherwise unaffected; the shared state is the database, which you already scale.

Failure modes

• Silent staleness — the highest-impact failure and the one v3 introduces. A dead scheduler or crashed worker leaves a fully functional, confidently wrong UI. Mitigate with a freshness alert on max synced timestamp.
• PII over-retention — customer data persists indefinitely and outlives a Stripe-side deletion. This is a compliance failure, not a bug; handle erasure before go-live.
• Over-exposure of customer PII — unchanged in mechanism, broader in scope. Gating must ship before production.
• Invalid or rotated key — now breaks the sync, not the page. Degradation is gradual and less visible than v2's immediate exception, which is worse.
• Backfill rate-limiting or timeout — partial dataset that looks complete; verify sync completion state, not just absence of errors.
• Duplicate / non-idempotent records — double-counted revenue in filters and totals; test a re-run.
• Migration failure on deploy — a bad package upgrade now takes the admin surface down and may require a schema rollback; stage it.
• Stripe outage — improved: the UI keeps serving cached data; only the sync stalls.
• Multi-currency / multi-account confusion — currency filtering helps but does not model multiple accounts; annotate totals and never let the view imply a single consolidated balance.
• PCI scope — unchanged; brand/last4 only, but customer identifiers are now stored locally and fall squarely under privacy obligations.

Ramp-up

Low for operators — it is now a familiar Nova resource experience with search and filters, arguably easier than v2. Low-to-moderate for engineers: install is still a day, but the team must learn the sync model, the failure signature of a stalled job, and the rule that this view is a mirror, not a ledger. The organizational ramp-up is the real cost, and it has grown: security must approve a new PII store, legal must approve retention and erasure, and finance must be trained not to reconcile against a synced snapshot.

TPM recommendation: v3 changes the calculus in both directions. The value case is now genuinely strong — local search and filtering remove the main reason operators kept a Stripe Dashboard tab open — but the package is no longer disposable instrumentation; it is a PII-bearing data pipeline with a schema, a scheduler, and a staleness failure mode. Adopt if a Nova licence already exists and you can commit to sync monitoring plus a retention policy, and prefer a clean install on 3.0.x over an in-place v2 upgrade. The earlier "replace with a ~100-line Nova card" fallback no longer holds — recompute that exit cost before signing up.