Nova Stripe Checkout Field Laravel Package

Technical Evaluation

Architecture fit. Nova "fields" are designed to bind a UI component to a model attribute across form/detail/index views. A "Stripe Checkout button" is an action — it creates external state (a Checkout Session) and has no attribute to read or write. That makes the field a thin wrapper around a bespoke Vue component firing an HTTP call, which is an architectural mismatch with Nova's lifecycle. The idiomatic extension points are a Nova Action or a Tool; a field will inherit none of the authorization, audit, or queueing behavior those provide. The package also necessarily couples to stripe/stripe-php, so its useful life is bounded by an SDK it does not control.

Integration feasibility. Last release 2018-08-27, archived, 12 stars — this is a Nova 1.x-era artifact. Nova 4 (2022) moved to Vue 3 and a completely different asset pipeline (nova.mix.js, the laravel-nova npm package, changed component registration); a 2018 field component will not build or register against current Nova without a rewrite. Even on Nova 2/3, expect patchwork. Two independent decay axes compound: the Nova front-end contract and the Stripe API contract. Since 2018 Stripe has renamed Checkout Session items → line_items, made mode mandatory, required success_url/cancel_url, and moved the SDK through many major versions. Any hardcoded payload in this package is either broken or silently accepted under an account-pinned legacy API version.

Technical risk: high. An archived, Stripe-adjacent package means no security response surface and no deprecation notices. The specific hazards to verify before any code review:

• Does the field create the Checkout Session server-side, and is that endpoint behind Nova's auth middleware and a policy check?
• Is the Stripe secret key ever serialized into the field payload (leaking to the browser), or does the browser call Stripe directly?
• Are amount/price/currency client-supplied, and is mode forced to live vs. test per environment?
• Is there any idempotency key or double-click protection (orphaned sessions)?
• Is there a webhook or read-back so the button reflects whether payment happened?

Key questions for the team. Which Nova version are we on and what is the upgrade horizon? Is the underlying need "let a support agent collect a payment," or specifically "a button inside a Nova detail view"? If the former, Stripe Payment Links or the Stripe Dashboard satisfy it with zero code and zero new security surface. Kill/build/buy should be settled before any integration work.

Recommendation. Do not adopt. The capability is small and the total cost of ownership is not.

Integration Approach

Stack fit. Conceptually the right stack (Laravel + Nova + stripe/stripe-php is already present in most such apps); practically the versions do not line up. Composer constraints should be inspected first — PHP 7.x-era requirements and a pre-v7 Stripe SDK will conflict with any current Laravel application.

Migration path. There is no upgrade path, only a rewrite or a fork. Reimplementing as a first-party Nova Action with a policy-guarded controller is roughly 0.5–2 developer-days, including tests and an idempotency key. That is less effort than resurrecting a 2018 Vue build against Nova 4/5 and re-validating it against current Stripe, and it produces an asset we own. If the button UI itself is valued, vendor the source into the app, pin the Stripe API version explicitly, and treat it as an internal fork — never as a Composer dependency.

Compatibility. Assume Nova 1.x/2.x only, PHP ≤7.x, stripe/stripe-php ≤ v6-era. Verify against our actual Nova and PHP versions before spending further time.

Sequencing.

1. Timeboxed spike (≤ half a day) in a throwaway branch on current Nova — expect fast failure; the point is to confirm it, not to fix it.
2. If it fails (likely), write the Nova Action in-house.
3. If it unexpectedly works, still vendor, pin, add tests, and log it as unsupported.
4. In parallel, validate the requirement — if the need is "send someone a payment link," ship Stripe Payment Links and close the ticket.

Operational Impact

Maintenance. Entirely ours. Archived means no upstream fixes, no compatibility PRs, no response to Stripe API deprecations. Budget recurring effort against every Nova major, every PHP minor, and every Stripe SDK bump — three independent upgrade clocks for one button.

Support. None. Twelve stars means no community to triage issues, no Stack Overflow corpus, no third party who has hit our failure before we do.

Scaling. A non-issue. Checkout Session creation runs at admin-panel volume — a handful of calls per day against Stripe's limits. The risk here is correctness and security, not throughput.

Failure modes.

• Silent Stripe drift: parameter renames accepted or rejected with errors that surface only in production logs; agents see a broken button with no diagnostic.
• Nova upgrade breakage: front-end component stops compiling after a Nova major; the field disappears from resource definitions.
• Key/environment confusion: test vs. live keys producing real charges or silent no-ops.
• No state: a button with no read-back is a UX trap — the agent clicks, the session is created, and nothing in Nova changes. Users click again. Sessions orphan.
• Authorization gap: a bespoke endpoint outside Nova's policy layer exposes payment initiation to any authenticated Nova user.

Security. Confirm the secret key never crosses to the browser, the endpoint enforces Nova auth + CSRF, and amounts are server-derived rather than taken from the request. Hosted Stripe Checkout keeps PCI scope low (SAQ A), but that benefit is erased if the field handles card data or leaks credentials.

Ramp-up. Low in the narrow sense — a developer can read the whole source in an hour. That is also the tell: the artifact is small, the abandoned-dependency liability is not.