Stripe Bundle Laravel Package

Technical Evaluation

Architecture fit — still poor. The core finding is unchanged: this is a Symfony bundle, not a Laravel package. It targets the Symfony kernel, DI compiler passes, Configuration trees, and Doctrine ORM/DBAL. A Laravel application runs on the Illuminate container, service providers, and Eloquent. Adoption still requires either a hybrid Symfony/Doctrine stack or a fork that strips framework coupling. v3.1.4 does not alter that.

What v3.1.4 changes. Patch release, no breaking changes, no new features, no deprecations. It maps decimal percent fields as string to match DBAL. That is a narrow type-mapping bugfix. It matters for two reasons: it confirms the Doctrine/DBAL layer is load-bearing rather than incidental, and it shows the package is receiving at least minimal maintenance. The PR is from @kbaryshev-hw, which reads as a Herdwatch-affiliated contributor, and the ticket FIT-8548 is an internal-style reference. That reinforces the prior read: the public artifact is a byproduct of an internal product, not a community-supported library.

What the package actually offers. Two capabilities: (1) a thin wiring layer over stripe/stripe-php, and (2) persistence of Stripe objects into a relational store via Doctrine. Capability (1) is commodity — stripe/stripe-php is a one-line install in Laravel, and laravel/cashier covers subscription billing with first-party support. Capability (2) is the only differentiated idea, and it is a pattern, not reusable code for us: "mirror Stripe objects locally so billing state is queryable and joins to app data."

Integration feasibility. Low. Zero GitHub stars, zero dependents, and a score of 15.4/100 still indicate no production signal. v3.1.4 is a single patch PR, not evidence of a support contract, release cadence, or external adoption. The anomalous release date of 2026-07-24 from the prior assessment remains unreconciled and should still be treated as a data-hygiene issue until proven otherwise.

Technical risk. High, concentrated in five areas:

• Bus factor 1, effectively. A new contributor is marginally positive, but the contributor handle and ticket reference point back to Herdwatch. We would still be adopting an internally driven artifact with no independent community.
• Stripe API version drift. Any Doctrine mapping of Stripe objects bakes in an assumed API shape. Stripe versions account objects and deprecates fields; a schema-mirroring library is structurally fragile against that.
• DBAL type-mapping fragility. v3.1.4 is itself a type-mapping fix — decimal percent fields as string to match DBAL. In a Laravel/Eloquent codebase this is a non-issue; in this bundle it is a maintenance tax we would inherit.
• Data-sensitivity surface. Persisting Stripe objects invites storing payment-adjacent data. Any path that lands PAN, CVC, or full card payloads in our database is an immediate PCI scope expansion. We would need to verify the bundle restricts itself to non-sensitive identifiers and metadata.
• Doctrine coupling. The bundle ships or expects entity mappings and migrations. In a Laravel app, a foreign migration/schema system directly collides with our migration chain.

Key questions for the maintainer (or for our own spike):

1. Is this package actively maintained beyond internal patch needs, and what is the intended support contract? Is Herdwatch consuming v3.1.4 in production?
2. Which Symfony, PHP, Doctrine ORM/DBAL, and stripe/stripe-php version ranges are supported? Does the DBAL string-mapping fix imply a minimum DBAL version?
3. Is the Stripe API version pinned, and what is the upgrade story when Stripe ships a new version?
4. Is persistence one-way (Stripe → DB) or bidirectional? What happens on drift?
5. Which Stripe object types are mapped, and does the bundle ever persist sensitive payment instrument data?
6. Is webhook signature verification implemented, and is event persistence idempotent?

Integration Approach

Recommendation: do not integrate. Adopt the pattern, not the package. v3.1.4 is a patch-level bugfix and does not change the framework mismatch or the maturity profile. The realistic outcome remains a design decision, not a dependency.

Stack fit. For a Laravel shop the correct primitives are unchanged: stripe/stripe-php for SDK access, laravel/cashier where subscription billing is the actual requirement, and native Eloquent models plus queued jobs for any local mirroring of Stripe objects. This gives us the bundle's only real idea — a queryable local projection of billing state — with zero foreign-framework surface. The v3.1.4 DBAL fix is a concrete example of cost we avoid: Eloquent handles decimal casting natively.

Migration path. There is nothing to migrate from; we have no existing dependency. The productive move remains a timeboxed spike (2–3 days) that reads the bundle's source as a reference implementation and extracts three things:

1. Its object-mapping schema — which Stripe fields it persists and how it keys them (stripe_id, unique constraints, soft-delete semantics), including how it treats decimal/percent fields after v3.1.4.
2. Its sync strategy — webhook-driven vs. polling vs. on-demand fetch, and how it handles replay and out-of-order events.
3. Its idempotency handling for webhook event IDs.

Those answers are directly portable to Eloquent models. The code is not.

Compatibility. If the estate also contains Symfony services where this bundle would be native, treat it as a separate, scoped evaluation with its own go/no-go. The v3.1.4 patch is relevant to that evaluation because it confirms active Doctrine/DBAL compatibility work; it is not relevant to the Laravel application.

Sequencing.

1. Confirm licensing and provenance (MIT is stated — verify the LICENSE file and that no Herdwatch-proprietary code is entangled).
2. Reconcile the anomalous release date and confirm Packagist publication and v3.1.4 availability.
3. Run the read-only source spike described above.
4. Write an ADR: "local Stripe projection — build in-house on Eloquent" with the bundle cited as prior art.
5. If a Symfony estate genuinely exists, open a parallel evaluation gate.

Operational Impact

Maintenance. As a dependency this remains a liability. v3.1.4 shows the package is not dead, but one patch PR from an internal contributor does not create an upstream community. Zero dependents means we would still be the first and only external production consumer — every bug becomes our bug. Rejecting the dependency removes that obligation; the in-house alternative is a few hundred lines of Eloquent models and a webhook handler we control and can staff.

Support. No evidence of an issue tracker with responsiveness, no security advisory history, and no release cadence to extrapolate from beyond this patch. We cannot construct an SLA or answer "who fixes this at 2 a.m." The v3.1.4 PR is a positive maintenance signal, but it is a signal about Herdwatch's internal needs, not about support for external Laravel consumers.

Scaling. The bundle itself is not a throughput concern; the mirroring pattern is. A local Stripe projection scales well for reads — billing state becomes a normal indexed query, joins to accounts and entitlements without an API hop — but introduces write-path pressure from webhook volume and backfill jobs. Any implementation must push sync work onto queues, rate-limit Stripe API calls, and handle burst reconciliation after downtime. These are our design problems regardless of which codebase supplies them.

Failure modes to design against:

• Drift. Stripe is the source of truth; the local mirror can silently diverge after missed or failed webhooks. Mitigate with a periodic reconciliation job that diffs against the Stripe API and repairs.
• Webhook replay / out-of-order delivery. Stripe retries and does not guarantee ordering. Deduplicate on event ID and use object timestamps for last-writer-wins.
• Signature verification bypass. Any webhook endpoint must verify Stripe-Signature with the endpoint secret; a mirror that trusts unsigned payloads is a data-integrity hole.
• API version upgrade breakage. A schema-mirroring layer is coupled to Stripe's object shape; pin the API version explicitly in the SDK call and treat Stripe version bumps as a scheduled migration with a reconciliation pass.
• DBAL type-mapping drift. The v3.1.4 fix is an example: decimal/percent field mapping required a patch to match DBAL. In a foreign-framework adoption this becomes a class of bug we would track indefinitely.
• Migration collision. Foreign entity mappings landing in our migration chain is a real risk in hybrid setups; another argument for not importing the bundle.
• Compliance creep. If any code path persists sensitive payment data, PCI scope expands. Constrain the schema to identifiers and non-sensitive metadata, and make that a reviewed invariant.

Ramp-up. Evaluation cost remains low — the source is readable and the spike is cheap. Ownership cost remains the problem: onboarding an engineer onto a Symfony-bundle idiom inside a Laravel team is pure overhead with no transferable benefit. The in-house projection is idiomatic Eloquent work any team member can pick up.

Verdict. v3.1.4 is a minor positive maintenance signal, not a material change. Score 15.4/100 remains a fair representation. High opportunity score reflects that Stripe-plus-local-projection is genuinely valuable to a subscription business — but that value is captured by the pattern, and the pattern is cheaper to rebuild than to adopt here. Recommendation: no-go on the dependency; run a 2–3 day read-only spike to harvest the mapping and sync design; document the decision in an ADR.