Statamic Stripe Checkout Fieldtype Laravel Package

Technical Evaluation

What this release is: mitydigital/statamic-stripe-checkout-fieldtype 3.0.0 is a single-change major release adding support for Statamic 6. The package provides a Statamic control-panel fieldtype that wraps Stripe Checkout (hosted payment page) as a content-editable field.

Architecture fit

• Natural fit for a Statamic + Laravel estate: a fieldtype is the idiomatic extension point for "editable Stripe configuration/content" in the CP, with the server-side session creation and webhook handling living in the Laravel app layer.
• Hosted Stripe Checkout keeps card entry off our infrastructure, so PCI scope remains SAQ A — this is the main architectural reason to prefer this package over building custom Elements/embedded forms.
• The addon sits on a version boundary we do not control (Statamic majors). Every Statamic major becomes a forced upgrade decision for us; this is now the second such event.

Integration feasibility

• Feasible and low-effort if we are on, or moving to, Statamic 6 (which carries its own Laravel/PHP floors — assume PHP 8.2+ and a current Laravel major; confirmation required, not stated in the release notes).
• Content-side integration is trivial: add field to blueprint, render in Antlers/Blade. The non-trivial work is payments plumbing (keys, webhooks, fulfilment, idempotency), which the release notes tell us nothing about.

Technical risk

• Breaking-change risk is high by construction. 2.1.1 → 3.0.0 for "Statamic 6 support" almost certainly means Statamic 5 support was dropped, not that both are supported. The release notes do not say. Treat as a hard cutover until proven otherwise.
• CP asset layer risk. Statamic 6 changed the control-panel front end (Vue 3 / Vite-era tooling). Fieldtypes carry published CP assets; stale or unrepublished assets after upgrade are the classic failure mode (blank field, console errors, silently unsaved values).
• Silent data risk. If field data shape changed (e.g. stored Stripe price/session config), existing entries may render as empty in the CP even though front-end output still works — a "looks fine, is broken" state.
• Supply-chain / bus factor. Single-maintainer addon (@martyf / mitydigital). A major release with a one-line changelog and no migration guide is a documentation signal, not necessarily a quality signal — but we cannot distinguish without inspecting the diff and CI matrix.
• Payments-path risk is unchanged by this release but is the dominant risk overall: webhook verification, idempotency, and fulfilment logic determine whether we lose money or ship product twice.

Key questions before adoption

1. Does 3.0.0 support Statamic 5 and 6 simultaneously, or is it a hard break? Is there a 2.x LTS branch for teams not yet on 6?
2. Exact support matrix: Statamic 6.x range, Laravel major(s), PHP minimum, and whether the CI matrix proves it.
3. Is there an upgrade guide for 2.x → 3.0.0, and does it cover field data/schema changes and CP asset republication (php artisan vendor:publish)?
4. Which Stripe API version does the package pin, and how does it track Stripe's rolling API deprecations?
5. Do webhooks verify signatures (Stripe-Signature), and is fulfilment idempotent on replay?
6. Where do secrets live (env / Statamic .env), and is there any path where a secret or a price ID is stored in content?
7. Test coverage and release cadence: how quickly did 2.x track Statamic point releases? Any open issues on the 3.0.0 bump?

Integration Approach

Stack fit

• Assumes a Statamic 6 target: Laravel app + Statamic 6 + PHP 8.2+. Verify the package's own composer.json constraints against our composer.lock before anything else — this is the cheapest possible gate.
• Fits two usage modes we should decide between up front: (a) CP field configures pricing/CTA and front end renders a Checkout redirect, or (b) the fieldtype is only an authoring convenience and our app owns the Stripe session. Mode (b) reduces blast radius and lets us pin the addon loosely.

Migration path

• Because this is the first assessment, there is no migration — only an adoption decision. Frame it as: adopt 3.0.0 only alongside a Statamic 6 upgrade; do not adopt 3.0.0 as a standalone bump.
• If we are still on Statamic 5: stay on 2.1.1, pin ^2.1, and open a ticket to revisit at the Statamic 6 upgrade. Do not attempt a composer resolution fight to get 3.0.0 running on 5 — that is a signal the constraint is real.
• If we are already on Statamic 6: 3.0.0 is likely a required move (2.x may not boot on 6). Treat it as a forced upgrade and budget for verification, not implementation.

Compatibility

• Hard dependencies: Statamic major, Laravel major, PHP floor. Soft dependencies: Stripe PHP SDK version (conflicts with our own stripe/stripe-php are a real possibility if we also use Cashier or direct SDK calls — check for a constrained pin).
• Coexistence check: any other payment addon or custom Checkout code in the same app; two code paths creating Stripe sessions is an operational hazard.

Sequencing

1. Confirm support matrix from composer.json + README + CI config (not from the changelog).
2. Spike in a throwaway branch: install 3.0.0 on a Statamic 6 baseline, publish assets, render the field in the CP, complete one Stripe test-mode checkout end to end including webhook delivery.
3. If the app is on Statamic 5: stop. Pin 2.1.1 and park until the Statamic 6 upgrade is scheduled.
4. Upgrade Statamic first, addon second, in the same PR or adjacent PRs — never bundle the Statamic major with unrelated feature work.
5. Ship behind a Stripe test-mode QA gate; promote to live keys only after webhook replay and duplicate-submission tests pass.
6. Post-deploy: CP smoke test on every blueprint using the field (asset cache, empty-field behaviour).

Operational Impact

Maintenance

• Ongoing cost is dominated by Statamic's release cadence, not the addon's. Budget one upgrade-and-verify cycle per Statamic major, plus a light check per Stripe API version bump.
• Single-maintainer project: assume low bus factor. Mitigation is containment — keep our Stripe integration logic (fulfilment, entitlements) in our own code, with the addon responsible only for CP authoring and session creation. That makes the addon replaceable.
• Pin to ^3.0 and review on release, not automatically. Major-version auto-bumps on a payments-adjacent package are not acceptable.

Support

• Upstream support is GitHub issues from one maintainer; no SLA. Internal ownership must be assigned to the team that owns payments, with a named backup — this is a payments path, not a CMS nicety.
• Because the changelog is one line, we should expect to read source for behaviour questions. Factor that into estimates.

Scaling

• Stripe Checkout is hosted and scales with Stripe; our scaling surface is session creation (synchronous HTTP to Stripe during a request) and webhook ingestion.
• Under load, move session creation off the hot path where possible and ensure webhook handling is queued and idempotent. Statamic's static caching should not cache any route that creates a Checkout session — verify cache exclusions explicitly.
• No meaningful DB scaling concern from the fieldtype itself; field data is small and entry-scoped.

Failure modes to design for

• Missing/misconfigured keys → CP field renders but checkout 500s. Fail loudly at boot or config validation, not at the customer's click.
• Webhook loss or replay → order paid, nothing fulfilled (or fulfilled twice). Require signature verification + idempotency keys + a reconciliation job against the Stripe API.
• Stale CP assets after upgrade → field appears empty, editors re-save blank values, content is destroyed silently. This is the highest-probability failure specific to this release; smoke-test the CP immediately post-deploy.
• Abandoned/expired sessions → user returns to a dead success URL. Success page must re-query Stripe, not trust the redirect.
• Composer resolution drift → an unrelated composer update pulls Statamic 6 and breaks a 2.x-pinned addon (or vice versa). Lock and CI-check the matrix.
• Maintainer abandonment → no patch for a future Statamic 7. Acceptable given containment; unacceptable if the addon owns fulfilment.

Ramp-up

• Low for developers already fluent in Statamic addons (blueprint field, publish assets, one tag/partial). Half a day to first working test-mode checkout.
• Non-trivial for whoever owns payments: webhook plumbing, idempotency, reconciliation, and key rotation must be understood, not copied from the README.
• Editors need ~15 minutes of guidance: what the field controls, that it is not a live preview of pricing, and what to do if it looks empty (report, don't re-save).
• Documentation gap is the real ramp-up cost: with a one-line changelog and no upgrade guide, plan for the spike in step 2 of the sequencing to answer most of the key questions empirically rather than from docs.