Stripe Laravel Package

Technical Evaluation

Architecture fit. lunarphp/stripe is a Composer package that plugs into Lunar (the Laravel e-commerce framework) via its payment driver abstraction. It registers a service provider, binds a Stripe payment driver, and exposes the configuration surface Lunar expects (publishable key, secret key, webhook secret). Architecturally it is a clean fit for any Laravel application already committed to Lunar as its commerce engine — it is not a standalone payment library and provides no value outside that context. The critical caveat embedded in the description is that this repository is a [READ ONLY] subtree split of the Stripe driver from the monorepo lunarphp/lunar. That means the artifact you install is a build product: issues, PRs, and releases originate upstream in the monorepo. The 20-star count on this repo materially understates adoption — the real signal lives on lunarphp/lunar. Evaluate the parent project, not this split.

Integration feasibility. Straightforward for a Laravel team. composer require lunarphp/stripe, publish config, set Stripe keys and webhook secret, and register the driver in Lunar's payment configuration. The package depends on Lunar core and the Stripe PHP SDK; both must be version-aligned. The main friction points are webhook endpoint configuration (signature verification, route exposure, CSRF exemption), payment intent lifecycle handling, and confirming the supported Stripe API version pinned by the SDK. Feasibility is high; effort is measured in days, not weeks, for a team already on Lunar.

Technical risk. Four risks dominate:

1. Subtree-split contribution friction. Any bug fix, patch, or feature must be raised against lunarphp/lunar, not here. If you need a hotfix, you are forking or waiting upstream — this is a real operational tax.
2. Version drift. The split is regenerated from monorepo tags; if the split lags the monorepo or version tags are inconsistent, you can end up on a stale driver without obvious warning.
3. Stripe API evolution. Stripe deprecates API versions and changes webhook payload semantics on a rolling basis. A community driver may not track these promptly, exposing you to breaking changes on Stripe's schedule.
4. Maintainer concentration. Lunar is a relatively small ecosystem; bus factor and release cadence are worth probing before production commitment.

Key questions to resolve before committing:

• Which Lunar core version does this driver target, and is the split tag aligned to the monorepo release?
• Which Stripe API version is pinned, and what is the upgrade path when Stripe deprecates it?
• Does it support SCA/3DS, Payment Intents, and the redirect flow required in EU/UK?
• Refund handling — full, partial, and asynchronous refund webhooks?
• Multi-currency and multi-market (Lunar's pricing model) compatibility?
• Webhook signature verification and idempotency handling — is it implemented or expected of the integrator?
• Test coverage and CI status in the monorepo; are there runnable integration tests against Stripe's test mode?

Integration Approach

Stack fit. Assumes Laravel (9/10/11 depending on the Lunar release line), PHP 8.1+, Lunar core, and the Stripe PHP SDK. It fits naturally into a Laravel-first team; there is no Node, no separate service, no sidecar. If your stack is Laravel + Lunar, this is the intended path.

Migration path. For greenfield Lunar projects this is a default choice. For an existing storefront migrating from another Stripe integration (e.g., Cashier, a bespoke driver, or a different commerce platform), the migration is non-trivial: you are re-modeling orders, payment intents, and webhook state into Lunar's order and transaction tables. Plan a parallel-run period where both integrations are live in test mode and reconcile against Stripe's dashboard.

Compatibility. The hard constraint is the Lunar core version — the split version must match. Secondary constraints are PHP version, Laravel version, and the Stripe SDK version transitively pulled in. Pin all of these explicitly and add a dependency-review step to CI. Do not adopt a floating version constraint on the split.

Sequencing.

1. Confirm Lunar core version and lock it.
2. composer require lunarphp/stripe at a pinned tag.
3. Publish config; load keys and webhook secret from environment/secret manager — never commit.
4. Register the driver in Lunar payment configuration.
5. Configure the webhook endpoint in the Stripe dashboard; verify signature handling and CSRF exemption in the route middleware.
6. Exercise the full lifecycle in Stripe test mode: authorize, capture, partial refund, full refund, failure, 3DS challenge, webhook delivery and replay.
7. Reconcile against Stripe's ledger before promoting to production.
8. Set up Stripe webhook retry monitoring and alerting before go-live.

Operational Impact

Maintenance. Maintenance is coupled to the Lunar monorepo release cadence, not to this repository. Because it is a read-only split, you cannot PR against it directly; treat upstream as your maintenance channel and budget for occasional forking or waiting on fixes. Track Stripe API deprecations independently of the driver — do not assume the driver will surface them.

Support. Expect community support (Lunar Discord/GitHub discussions, upstream issues), not commercial SLAs, unless you are on a Lunar commercial tier. The low star count on this split means search results and community answers will be sparse here; direct your questions to lunarphp/lunar. For a revenue-critical payment path, consider a paid support arrangement with the Lunar team or a retained Laravel contractor with Lunar experience.

Scaling. Stripe absorbs the payment-side scale; your constraints are application-side — webhook throughput, idempotency keys on concurrent retries, database contention on order state transitions, and queue capacity for async webhook processing. Ensure webhooks are handled asynchronously and idempotently; blocking on Stripe calls inside the request cycle is the common scaling mistake.

Failure modes to instrument.

• Missed or failed webhook deliveries (Stripe retries, but silent gaps exist) — alert on payment state divergence between Stripe and your DB.
• Signature verification failures (secret rotation, proxy rewrites).
• Amount/currency mismatches from Lunar's pricing model versus Stripe's minor-unit representation.
• API version drift causing payload shape changes.
• Duplicate payment intent creation on client retry — enforce idempotency.
• Stale split version lagging the monorepo — pin and review on a cadence.

Ramp-up. A Laravel developer with no Lunar experience needs roughly one to two weeks to become productive on the payment driver, longer to understand Lunar's order model and pricing abstractions. A developer with neither Laravel nor Stripe experience needs materially more. Document the webhook topology, the retry/reconciliation runbook, and the key-rotation procedure up front — these are the operational assets that reduce incident MTTR.