Payum Stripe Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for payments: This bundle is a "buy/borrow" answer for Stripe Checkout via the Payum abstraction. It removes the need to hand-roll a Stripe gateway, webhook handling, and SCA/3DS redirect flow for Payum-based stacks — a scope we would otherwise estimate at 2–4 engineer-weeks plus ongoing compliance maintenance.
• PSD2 / SCA roadmap: It directly supports a compliance-driven roadmap item (Strong Customer Authentication) for EU/UK customers. If we sell into Europe, this is a checkbox we can close with an integration rather than a bespoke project.
• PCI scope reduction: Stripe Checkout Sessions are hosted by Stripe, keeping card data off our infrastructure and keeping us in SAQ-A territory. That is a security/audit decision as much as a technical one, and it is a strong argument for the Checkout-based flow over embedded card forms.
• Payment method coverage / conversion experiments: Because it plugs into Payum's gateway abstraction, we can add Stripe Checkout as an alternative payment method alongside existing gateways and A/B test conversion, without rewriting checkout.
• Market expansion: Enables launching in regions where SCA-compliant card processing is mandatory, unlocking a go/no-go decision on EU/UK launch that would otherwise be blocked on payment infrastructure.
• Framework currency / upgrade tax: v3.0.1 adds Symfony 8 support, so this can sit on a current Symfony line rather than pinning us to an EOL framework. For a new build, that removes an "adopt-then-immediately-plan-a-migration" objection; for an existing app on Symfony 8, it removes a blocker outright.
• Use cases it fits: Sylius storefronts, Symfony apps already using Payum, single-currency/one-time-purchase checkouts, and teams that want a redirect-based flow rather than a custom Stripe Elements build.

When to Consider This Package

Consider it when all of these are true:

• The application is Symfony and already uses Payum (most commonly a Sylius storefront, since this repo lives under the Sylius org).
• You want Stripe Checkout Sessions (hosted redirect), not embedded Payment Elements or a fully custom Stripe integration.
• SCA/3DS support is a requirement or soon will be.
• You need Symfony 8 / current PHP compatibility — v3.0.1 covers this; pin the version and confirm the PHP floor against your runtime.
• You are comfortable with a low-adoption dependency (single-maintainer org, thin star count, no dependents) and can absorb the maintenance/fork risk — i.e., you have PHP engineers who can read and patch the bundle, or you plan to vendor it. v3.0.1 is a positive signal (the maintainer is shipping framework-compatibility releases, so it is not abandoned), but it does not materially change the adoption-risk picture.

Look elsewhere when:

• You are not on Payum. This bundle's value is entirely the Payum gateway bridge; without Payum it is dead weight — go straight to the official stripe/stripe-php SDK.
• You need capabilities beyond Checkout Sessions: subscriptions/billing portals, Stripe Connect/marketplaces, multi-currency presentment, saved payment methods, or in-app/embedded UI. Checkout Sessions is a narrow slice of Stripe.
• You are on Sylius and want a maintained first-party path. Evaluate Sylius/StripePlugin and the broader Payum gateway ecosystem (payum/stripe) first — they carry more community surface and clearer support expectations.
• You need vendor-backed SLAs or a support contract. MIT-licensed, single-maintainer-org project with a thin star count is community-grade support only.
• You need a non-redirect checkout UX (on-page card entry, wallets inline) — the hosted redirect will be a product/UX tradeoff you should decide deliberately, not inherit by accident.

Practical next step before committing: a one-sprint spike on a staging Sylius app covering successful payment, 3DS challenge, failed payment, and refund/webhook reconciliation, plus a written check on how much of the bundle we would need to own if upstream goes quiet. Note that v3.0.1 is a compatibility-only patch (no breaking changes from v3.0.0), so the spike can run against latest.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony bundle that lets us accept Stripe payments — including the EU's mandatory SCA/3DS verification — through Stripe's hosted checkout page rather than building card handling ourselves. It buys us a compliant payment path for roughly a sprint of integration work instead of a multi-week build, and it keeps card data entirely with Stripe, which materially lowers our PCI audit burden and breach exposure. Its latest release adds Symfony 8 support, so it stays current with our framework rather than locking us to an ageing stack. The tradeoff is dependency risk: the project is small and thinly adopted, so we should treat it as "adopt with a fork-in-pocket" — budget a short proof-of-concept and a small maintenance reserve, and keep the official Stripe SDK as the fallback if the project stalls.

To engineering: It's a Payum gateway implementation over Stripe Checkout Sessions with SCA handling, so it slots into the existing payment-method abstraction — no checkout rewrite, no custom card form, no webhook plumbing from scratch. v3.0.1 is a one-line compatibility release adding Symfony 8 support — no breaking changes, but confirm your PHP floor and pin the version. Constraints to validate: Checkout-only scope (no subscriptions, Connect, or embedded Elements), redirect-based UX, and no dependents, meaning we are early adopters and should expect to read the source and be ready to patch. Recommend a time-boxed spike covering the 3DS challenge and refund/webhook paths, and a decision point on vendoring the bundle versus writing our own thin Payum gateway on stripe/stripe-php.