Stripe Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (payment abstraction layer): PaymentSuite positions itself as a provider-agnostic payment core for Symfony, with Stripe as one pluggable method. This package is only worth a decision if the broader question is "do we standardize on PaymentSuite?" — not "do we need Stripe?"
• Provider redundancy roadmap: If the product goal is multi-gateway support (Stripe + PayPal + Adyen) behind one interface, PaymentSuite's PaymentCore abstraction is the actual thing being evaluated; the Stripe bridge is a cost line item, not a feature.
• Legacy maintenance triage: At 10 stars, 0 dependents, and a last release of 2014-04-19, this is best treated as a data point for "how much of our stack is on unsupported dependencies," not as a candidate for new adoption.
• Scope/feature deferral: Because the bundle predates Stripe Payment Intents, SCA/PSD2, and modern Stripe API versioning, adopting it means accepting a hard ceiling on features (subscriptions, 3DS2, wallets, multi-currency) without a fork. That's an explicit scope decision, not a detail.
• Vendor-dependency risk register: Useful as a concrete example when justifying investment in a first-party payments integration or a maintained abstraction (Payum, Sylius Payment, or Stripe's official SDK).

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony 2.x/3.x application that already commits to PaymentSuite/PaymentCore in production.
• Stripe is one of several providers you route through that core, and rewriting the abstraction is out of scope.
• Volume and feature surface are narrow: single-currency, one-off charges, no subscriptions, no SCA/3DS2 mandates, no webhook-driven reconciliation.
• You have engineering capacity to vendor/fork the package and pin your own Stripe SDK version — you should assume no upstream fixes.

Look elsewhere when any of these are true:

• New build, or Laravel. This is a Symfony bundle (subtree split of a monorepo), not a Laravel package — the framework mismatch alone is disqualifying for a Laravel app. Use Laravel Cashier or a direct Stripe SDK integration.
• You need PSD2/SCA, Payment Intents, subscriptions, or webhooks. A 2014-era bundle almost certainly targets the legacy Charges API and an old Stripe PHP SDK; retrofitting Payment Intents is a rewrite.
• You want a maintained abstraction. Prefer Payum, Sylius Payment, or Stripe's official stripe-php with a thin internal adapter.
• You need support, CVE response, or an issue tracker. This repo is explicitly [READ-ONLY] and is a subtree split — issues and PRs live in the monorepo, so triage and release cadence are outside your control.
• Zero-dependency or minimal-footprint goals. 0 dependents means no ecosystem validation; you'd be the only consumer exercising edge cases.

How to Pitch It (Stakeholders)

For executives: There is a Stripe integration package here, but it's effectively unmaintained — last shipped in 2014, ten GitHub stars, no downstream dependents, and the repo is a read-only mirror. It doesn't cover modern Stripe requirements (SCA/PSD2, Payment Intents, subscriptions). The cost of adoption isn't the install; it's the fork we'd own forever plus a likely re-platforming project the first time compliance or a new payment method lands. Recommendation: do not adopt. If payments abstraction is a roadmap priority, fund either a maintained abstraction layer or a thin first-party Stripe adapter — that's a small, bounded build that keeps us current with Stripe's API and SDK.

For engineering: Treat this as a Symfony/PaymentSuite artifact, not a Laravel package — it doesn't fit our framework. It wraps Stripe behind PaymentCore's provider interface, which is a reasonable pattern, but the code predates Payment Intents and modern Stripe API versioning, and there's no maintainer path for fixes. If we need provider abstraction, evaluate Payum or Sylius Payment against our actual requirements; otherwise integrate stripe-php directly behind an internal interface we control. Budget a spike to confirm current API coverage before anyone prototypes against this.

For product/procurement: Low direct cost (MIT), high total cost of ownership. The decision to make isn't "yes/no on this bundle" — it's "do we own our payments integration layer, and who maintains it?" That answer also determines how fast we can ship wallets, subscriptions, and regional payment methods.