Payment Stripe Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the payment integration layer. This package is a thin pass-through to stripe/stripe-php dressed in Symfony bundle conventions (DI extension, config tree, YAML service definitions). The real decision it forces is not "which wrapper" but "do we own a wrapper at all, or call the official SDK behind our own interface?" For a Laravel roadmap the answer is effectively pre-decided — this package is a Symfony bundle, not a Laravel package, so adopting it means reimplementing its wiring anyway.
• Framework and stack alignment. If the product is on Laravel (or moving there), this package is out of scope on day one: no ServiceProvider, no Facade, no publishable config/*.php. It cannot be registered by Laravel's container. The decision it informs is "do we standardize payment code on a framework-neutral interface so the wrapper choice stays reversible?"
• Which monetization features are actually de-risked. Because the wrapper targets the older Charges-era Stripe surface, it implicitly deprioritizes — or blocks — Payment Intents/SCA, subscriptions, Connect/marketplace splits, Tax, and Billing. If any of those are on the roadmap, this is a signal to plan the integration on stripe/stripe-php v13+ or Laravel Cashier instead.
• Dependency risk budget for the revenue path. Zero stars, zero dependents, score 0, no maintainer of record. Payment code is the least appropriate place in a codebase to carry an unvalidated dependency; this is a legitimate input to a "we do not accept unowned dependencies in billing" policy decision.
• Roadmap sequencing for compliance and platform expansion. No SCA support means EU/UK card flows fail as silent declines under PSD2; no webhook signature verification means confirmations are spoofable. Both are product-scope constraints (which markets we can sell into, how we recognize revenue), not just engineering details.
• Buy-vs-vendor for legacy inheritance. If an existing Symfony app already uses the KJ bundle family, the decision is "vendor and own it" versus "strangler it out behind our own PaymentGateway interface" — a scoped refactor, not a new-product decision.

When to Consider This Package

• Only when maintaining an existing Symfony 2.x/3.x application that already depends on the KJ bundle family, where consistency with neighbouring bundles has real value and the payment surface is a single charge flow.
• Payment needs are minimal and stable — no subscriptions, no marketplace/split payments, no tax calculation, no SCA-heavy European card traffic.
• The team has in-house Symfony depth and is prepared to treat the bundle as vendored source: fork it, own it, patch it, and pin explicitly against a Stripe API version you have confirmed is still live.
• A due-diligence pass has confirmed: the pinned stripe/stripe-php version, whether webhook signature verification exists, whether any SCA/PaymentIntent flow is implemented, the composer.json PHP/Symfony constraints, license, and test coverage.

Look elsewhere if:

• You are building on Laravel. This is not a Laravel package — install it and Composer will fail on Symfony component and Guzzle 7 conflicts against PHP 8.1+/Laravel 10–11. Use stripe/stripe-php with a thin service binding, or Cashier if subscriptions are core.
• You need active maintenance, CVE response, or anyone to call when card processing stops. There is no upstream: bus factor is zero.
• Modern payment surface is required — Payment Intents, SCA/3DS, Connect, Billing, Tax, disputes, idempotent retries.
• You cannot accept secrets living in YAML config, or you need webhook signature verification as a guarantee rather than a hope.
• Your organization has (or should have) a policy against unowned dependencies on the revenue path.

How to Pitch It (Stakeholders)

For executives — recommendation: do not adopt. We reviewed kj/payment-stripe-bundle, a third-party wrapper that exposes the Stripe API inside a Symfony bundle. Two facts settle it. First, it is not a Laravel package — it uses Symfony's bundle, DI, and config-tree machinery, none of which our application runs, so it cannot be installed on a modern Laravel stack; the only reusable part is roughly fifty lines of configuration plumbing we would write ourselves. Second, it carries no adoption signal whatsoever: zero stars, zero dependents, no visible maintainer. For revenue-critical code that means we inherit ownership on day one with no upstream to fix anything. The commercial exposure is concrete and quiet: no SCA support (card payments fail in the UK and EU under PSD2, which looks like "customers stopped paying" rather than a bug), no webhook signature verification (false payment confirmations), no idempotency keys (duplicate charges and chargebacks), and credentials likely configured in version-controlled YAML. The wrapper saves maybe a day of setup and costs an unknown amount of remediation later. Standardize on the officially maintained Stripe SDK, which is what this bundle wraps anyway and which carries Stripe's own compatibility and security guarantees.

For engineering — treat it as a reference, not a dependency. If it appears in a legacy Symfony codebase, do not require it; vendor the service classes or, better, extract the intent. Define an internal PaymentGateway interface expressing your domain operations (charge, refund, tokenize, handleWebhook) and implement it against stripe/stripe-php v13+ directly, or Cashier if subscription billing is the core use case. Lock and document a target Stripe API version as an explicit decision rather than a default. If existing code calls the bundle, apply a strangler pattern: put the interface in front of current call sites first, dark-launch the new implementation in Stripe test mode with production-shaped payloads, canary a small share of live volume with reconciliation running against both paths, and decommission the bundle once reconciliation matches for a full billing cycle. Call sites never need to learn the bundle went away.

The one durable decision here is architectural, not vendor-specific: keep payment logic behind our own abstraction so the choice of wrapper — this bundle, Cashier, or raw SDK — stays reversible. Payments are the most expensive layer to rewrite, and this package is a one-way door we should not walk through.