Nova Stripe Checkout Field Laravel Package

Product Decisions This Supports

• Internal billing-ops tooling — build the capability, not the dependency. The package's only real job is to render a Stripe Checkout button on a Nova resource (Order, Invoice, Subscription). That maps to a concrete ops workflow: a support or finance rep opens a record and issues a payment link without leaving the admin panel, instead of escalating to finance or hand-assembling a Stripe link. Deciding whether that workflow is worth having is the product decision; the package itself is incidental.
• Build vs. buy vs. copy. The existence of a 12-star, single-purpose field is evidence the feature is small. A PM should read this as "this is a half-day in-house build," not "this is a vendor to evaluate." That reframes the build/buy decision toward copy the idea, own the code.
• Roadmap: are payment actions part of your admin surface? If dunning recovery, resending failed-invoice links, phone orders, manual/comped subscriptions, or plan changes are recurring support tickets, that's a roadmap line item for admin-panel payment actions — and this repo is a useful sketch of the UX. If those tickets don't exist, the package is a solution in search of a problem.
• Prioritization and ecosystem signal. Archived since 2018, last release 2018-08-27, 12 stars, low score. Treat it as market evidence that nobody has validated this as a package category — most teams either built the ~100 lines themselves or, post-2021, used Stripe Payment Links. That is a legitimate input to a "don't invest here" call.
• Risk budget for internal tools. Sets the bar for what you'll accept on an admin-only surface (low blast radius, no customer-facing SLA) versus customer-facing payments code (webhooks, idempotency, SCA/3DS, audit trail) — this package clears only the former, and barely.

When to Consider This Package

Consider it only in narrow, low-stakes conditions:

• You are still on a Nova 1.x/2.x-era install with a matching PHP/Laravel version, and you need an internal-only button this week.
• You intend to vendor or fork it rather than depend on it, and someone on the team can read and own ~100 lines of PHP.
• You want a reference implementation / spec for how a Nova field wraps a Stripe Checkout session — that is arguably its highest-value use today.
• The surface is internal, permission-gated, and a broken button is an annoyance rather than a revenue interruption.

Look elsewhere — or build in-house — if any of the following is true:

• Version drift. Last release 2018 predates Nova 4/5, Laravel 9+, and PHP 8+. Compatibility is unlikely and unmaintained; there are no security patches and no upstream fixes.
• Stripe API drift. Stripe Checkout has moved on (Sessions API evolution, Payment Links, Tax, updated SCA flows). A 2018 integration will not reflect current behavior or error handling.
• You need anything beyond a button: webhooks, idempotency keys, 3DS/SCA handling, multi-currency, tax calculation, audit logging of who issued which link, or role-based gating.
• Stripe Payment Links already solve it. Since 2021 you can create a reusable payment link in the Stripe Dashboard and surface it in Nova as a plain URL field — zero code, zero maintenance, Stripe-supported. For most one-off and dunning use cases this is the correct answer.
• Supply-chain hygiene matters to you. An archived, single-maintainer, low-adoption dependency is a standing liability in exchange for a button.

How to Pitch It (Stakeholders)

To executives: Recommend not adopting. This is an archived, 12-star, single-purpose Nova field last released in 2018. The cost of owning an unmaintained dependency in a billing workflow exceeds the cost of the feature itself, which is roughly half a day of engineering. The capability it provides — issuing a payment link from the admin panel — is real and worth having for support efficiency, but Stripe Payment Links deliver most of it with no code and no maintenance. Net recommendation: skip the package, keep the workflow.

To engineering: Treat the repo as a one-hour spec, not a dependency. Build a small in-house Nova field or action that creates a current Stripe Checkout Session (or surfaces a Payment Link), pinned to the current Stripe SDK, with role gating and an audit log of who generated which link for which record. Budget roughly half a day plus tests. Do not install the package: it predates Nova 4/5 and modern PHP, has no security-patch path, and its Stripe integration reflects a 2018 API surface. If the need is purely one-off links, the zero-engineering fallback is a Nova URL field populated from Stripe Payment Links.