Product Decisions This Supports
- Legacy triage, not greenfield planning. This package is a decision input only if you already own a Symfony 2.x application with
JMSPaymentCoreBundle in its dependency graph. It answers "how much work is the Stripe side of our migration?" — not "how do we add payments?"
- Build vs. buy vs. migrate. The realistic three-way comparison is: (a) keep this bundle and pin it, (b) replace it with Stripe's official server-side SDK called directly from a Symfony service, or (c) lift-and-shift the payment boundary behind an internal interface and swap providers. Because the bundle is a thin adapter over the Stripe API rather than a payments engine, option (b) is usually the cheapest path and rarely takes more than a few days per integration point.
- Scoping the blast radius of an upgrade. Knowing that the package sits on top of
JMSPaymentCoreBundle tells you the real coupling is to that core bundle's model (payment instructions, transaction entities, plugin/extension points), not to Stripe. That reframes migration cost: you are decoupling from JMS abstractions, and the Stripe calls themselves are portable.
- Roadmap risk qualification. Archived status plus a hard last release in 2016 means any roadmap that depends on this package carries unhedged risk: no security patches, no PHP 8 compatibility guarantees, no Stripe API version tracking. That belongs in a risk register entry, not a feature spec.
- Use-case fit check. The bundle only makes sense where you need server-side charge creation, refunds, and customer/token handling through Stripe inside a Symfony 2 DI container. It is not a checkout UI, not a subscription billing engine, not a webhook framework, and not a PCI scope reducer beyond keeping card data off your servers via Stripe.js/tokens.
When to Consider This Package
Consider it only under a narrow set of conditions, all of which must hold:
- You are maintaining an existing Symfony 2.x application that already depends on
JMSPaymentCoreBundle, and the payment integration is already wired through this bundle.
- The work is read-and-repair, not new build: fixing a bug, keeping the lights on, or bridging until a planned migration lands.
- You have pinned the dependency and have a compensating control for the lack of upstream maintenance — an internal fork, a vendored copy, or a documented SLA that no Stripe API changes will break you.
- Your Stripe usage is limited to the stable, long-lived primitives (charges/tokens/customers) rather than newer API surfaces.
Look elsewhere — and specifically at Stripe's official PHP SDK — when any of the following is true:
- New project, any framework. Symfony 2 has been end-of-life since 2018; the maintenance burden dwarfs any convenience this bundle offers. Use
stripe/stripe-php directly inside a framework-agnostic service, or Symfony's current tooling on a supported version.
- You are not already on JMS Payment Core. Adopting both this bundle and its underlying core bundle to get Stripe support is a large, obsolete dependency surface for very little value.
- You need modern payment features. Payment Intents, SCA/3DS2 compliance, subscriptions, Connect, or webhook signature verification are either absent or predate this package's last release. European and UK card flows in particular require SCA-aware APIs this bundle cannot have anticipated.
- Compliance or audit matters. With zero dependents, seven stars, and an archive flag, you have no community backstop and no vendor to escalate to. For anything touching cardholder data or a SOC2/PCI audit narrative, that is disqualifying.
- You need PHP 8 / modern Symfony support. Nothing in the project history suggests it was validated against those runtimes.
How to Pitch It (Stakeholders)
For executives: We evaluated this library and recommend against adopting it for anything new. It is an archived, single-maintainer Symfony 2 add-on for Stripe, last released in 2016, with no downstream users and no maintenance commitment. Its only legitimate role is as a short-lived bridge inside an existing legacy application we already own, and even there the right move is to replace it with Stripe's officially maintained SDK. Expect the swap to be measured in days, not quarters, because the library is a thin adapter rather than a payments platform. The risk we are retiring is the absence of security patches and the inability to support modern card-authentication requirements.
For engineering: This is a JMSPaymentCoreBundle plugin that translates the JMS payment-instruction model into Stripe API calls. The coupling that matters is to JMS, not to Stripe — the Stripe calls themselves port cleanly to stripe/stripe-php. Recommended path: define a narrow internal payment interface at the call sites, implement it today by wrapping this bundle, then swap in a direct SDK implementation behind that interface. That gets us off an archived dependency without a big-bang rewrite, and it puts SCA/Payment Intents support on the table without re-architecting. Pin the current version, vendor it if you cannot move quickly, and treat any Stripe API change as a blocking event since there is no upstream to absorb it.