- How do I install tightenco/nova-stripe in a Laravel Nova application?
- Require it with Composer, pinning to the 3.0.x line, then publish the package config and migrations and run migrate. You register the tool and its Nova resources in NovaServiceProvider and supply a Stripe restricted key in the config. Confirm your scheduler and queue workers are running before the first sync, because v3 replicates data into your own database instead of calling Stripe on render.
- Does nova-stripe write anything back to Stripe?
- No. Stripe stays the system of record, and the package reads from the Stripe API and mirrors Products, Customers, Charges, and Subscriptions into local tables for display in Nova. Because it is read-only against Stripe, a bad sync can leave your local copy stale or wrong but cannot corrupt subscription or charge data in your Stripe account. Verify this against the README for the exact version you pin before relying on it.
- What Stripe API key permissions does nova-stripe need?
- A restricted, read-only key covering products, customers, charges, and subscriptions is enough for the sync. Never use your transactional secret key. If your sync is webhook-driven you also need a webhook signing secret, and both secrets belong in environment variables rather than in committed config.
- How does the nova-stripe sync actually work in v3?
- v3 is a sync pipeline plus admin UI: a scheduled command and possibly queued jobs pull Stripe data into your application database, and native Nova resources surface it with search, filters, and pagination. That is a real change from v2, which called the Stripe API on render and held no state. The practical consequence is that you now own a background process that has to run reliably and be monitored.
- Is nova-stripe v3 a breaking change from v2?
- Yes. v3 is a complete rewrite with a new config, a new database schema, and a new sync model, and an in-place upgrade from v2 is not a supported path. Plan for a fresh install, an initial backfill, and re-registering the tool and resources. Treat it as a small project rather than a Composer version bump.
- How long does the initial nova-stripe backfill take on a large Stripe account?
- It scales with your history. A small account backfills in minutes, but an account with tens of thousands of charges and subscriptions can take hours of throttled job time and will grow your database accordingly. Run the backfill against Stripe test mode first to measure duration and rate-limit headroom, and add indexes and batching before pointing it at production.
- Where does nova-stripe store customer data, and does it matter for GDPR?
- It replicates customer name, email, address, and charge metadata into your own database, so that PII now falls inside your backup, retention, and erasure obligations. You need a way to purge or anonymize mirrored records when someone exercises an access or deletion request. Also consider logs, screenshots, and exports that may persist the same data outside the tables.
- How do I stop the wrong Nova users from seeing Stripe revenue and customer records?
- Register the tool and resources in NovaServiceProvider and gate visibility with Nova authorization policies or canSee callbacks. Because v3 exposes subscriptions and full customer records alongside charges, the visible set is broader than in v2, so review who can reach which resources. Nova policies and gates are the right layer for this; do not rely on hiding menu items.
- Which Laravel and Nova versions does nova-stripe 3.x support?
- Pin to 3.0.x and check the composer.json constraints and README for the exact Laravel and Nova versions supported by the release you install. Nova is a hard requirement and the tool tracks Nova majors, so every Nova upgrade is a re-verification surface. Stripe API version drift matters too now, since it affects sync correctness rather than just how a card renders.
- How do I verify the nova-stripe sync is idempotent and not silently broken?
- Re-run the sync over the same data and confirm you get safe upserts rather than duplicates or partial records. Add a monitoring check on the scheduler and queue so a dead worker raises an alert instead of leaving a stale dashboard. Because the local tables are searchable and filterable, they look authoritative even when the data is weeks old.