Payment Stripe Bundle Laravel Package

Technical Evaluation

Architecture fit. Weak by definition: this is a Symfony2 bundle, not a Laravel package. It integrates through Symfony's bundle/DI/event system and the JMS\Payment\CoreBundle abstraction layer, neither of which has a Laravel equivalent. Adopting it in a Laravel codebase means either running a hybrid Symfony/Laravel stack (impractical) or porting the bundle's thin Stripe gateway class out of its Symfony wiring — at which point you have written a custom integration and the package is only a reference implementation.

Integration feasibility. Low. The bundle's actual value is a PaymentPluginController/gateway adapter that wraps the legacy Stripe PHP library (charges, customers, refunds) into JMSPaymentCore's plugin contract. Three transitive dependencies are each blocking on their own: (1) JMSPaymentCoreBundle is itself abandoned; (2) the legacy stripe/stripe-php versions it was built against predate Payment Intents; (3) the bundle expects Symfony 2.x-era container, event dispatcher, and PHP constraints (PHP 5.5–7.0 territory). Any one of these requires significant rework; together they are prohibitive.

Technical risk. High. Concrete risks:

• API drift: the Stripe API version this bundle targets is ~2015–2016. Stripe's charges API is deprecated; SCA/3DS2 (PSD2) and Payment Intents are mandatory for European cards. The bundle has no Payment Intents support and no path to it.
• Security posture: no maintenance since 2016 means no CVE response, no dependency patching, and an unmaintained transitive tree (Guzzle/Symfony components from that era carry known advisories).
• No validation signal: 7 stars, 0 dependents, archived — effectively zero production usage to learn from.
• Compliance: PCI scope is fine (Stripe-hosted), but webhook signature verification and idempotency semantics from that era may not meet current expectations.

Key questions for the requester.

1. Is the target genuinely Laravel, or is there a legacy Symfony2 service this is meant for? The answer changes the recommendation entirely.
2. What Stripe capabilities are required — one-off charges only, or subscriptions, SCA, wallets, marketplace payouts?
3. Is there an existing investment in JMSPaymentCore that must be preserved?
4. What is the PHP runtime baseline and supported-version policy?

Verdict. Not adoptable. Treat as a historical reference for how to shape a gateway adapter, not as a dependency.

Integration Approach

Stack fit. None for a Laravel target. The idiomatic Laravel path is stripe/stripe-php (official SDK, actively maintained, current API version) or laravel/cashier if subscriptions/invoicing are in scope. Both give you first-class Payment Intents, SCA, webhooks, and Laravel service-provider/facade wiring — the exact integration surface this bundle was trying to provide for Symfony.

Migration path. If a system already runs this bundle, the migration is a strangler pattern:

1. Inventory call sites — charges, refunds, customer creation, webhook handlers — and map each to the equivalent Payment Intents/Refunds/Customers API call.
2. Introduce the official stripe/stripe-php SDK alongside, pinned to a current API version, behind an internal PaymentGateway interface you own.
3. Port call sites one at a time to the new interface. Keep the old path live only for in-flight transactions.
4. Decommission JMSPaymentCore and the bundle once reconciliation confirms zero traffic over a full billing cycle.

Compatibility. Assume none. Effective constraints are roughly PHP ≤7.x, Symfony 2.x, and Stripe API 2015-era. Verify against composer.json before any spike, but the practical answer is "assume incompatible with anything current."

Sequencing. (1) Confirm framework target and required Stripe capabilities. (2) If Laravel: skip this package entirely and scope official-SDK vs. Cashier. (3) If a live Symfony2 system depends on it: run the inventory step first, because the migration is really a payments re-platforming with compliance sign-off, not a library swap. (4) Only after capability scoping should you pick a replacement — Cashier for subscription-shaped billing, raw SDK for bespoke flows.

Operational Impact

Maintenance. Zero. Archived repository, no releases in ~9 years, no maintainer response path. Any bug or incompatibility is yours to fix in a fork, which converts an OSS dependency into internal code you now own permanently.

Support. None available — no upstream, no community (0 dependents, 7 stars), no vendor. Internal escalation only. This is the single largest operational cost: you are the maintainer.

Scaling. The library itself is thin; scaling limits will come from Stripe's API and your webhook processing, not this bundle. But the absence of idempotency-key handling and modern retry semantics from the era means you will likely need to add your own guards before traffic grows.

Failure modes to plan for.

• Silent API breakage: Stripe retires API versions; a pinned 2016 version eventually loses support. Failures may surface as validation errors or, worse, as declined-then-abandoned payments.
• SCA/PSD2 declines: cards requiring 3DS2 will fail at charge time with no in-bundle challenge flow — a revenue-impacting failure, not a technical one.
• Webhook drift: signature verification and event schemas have changed; unverified or mis-parsed webhooks produce phantom order states and reconciliation breaks.
• Dependency rot: unpatched Guzzle/Symfony transitive advisories; expect security scanner noise at minimum.
• PHP runtime EOL: blocks upgrades of the host application, creating a compounding platform-debt risk.

Ramp-up. Low in absolute terms (small codebase, familiar Stripe concepts) but misleading — the effort is not learning the bundle, it is un-learning it and rebuilding around current Stripe primitives. Budget the team's time against Payment Intents and webhook best practices, not against this package's API.