Payum Stripe Laravel Package

Product Decisions This Supports

• Payment method expansion (feature): Adds Stripe as a first-class option in a Payum-based checkout — typically card payments via Stripe Checkout (offsite redirect) or Stripe.js (on-site card form), including 3DS/SCA flows and webhook-driven status updates. It answers "can we accept cards in this market?" without commissioning a bespoke Stripe client.
• Build vs. buy / adopt: The real decision is custom Stripe integration vs. Payum gateway. This package is the "buy" side: a small MIT dependency instead of owning authorize/capture/refund logic, webhook handling, and PCI-adjacent payment state.
• Architecture standardization (roadmap): Choosing it implicitly ratifies Payum as the payment abstraction layer. That is a multi-quarter commitment — it governs how cheaply we add PayPal, Adyen, or a second Stripe account later. Make it deliberately, not by default.
• Roadmap sequencing: If Stripe unblocks a launch (new region, new storefront, subscription pilot), the package shortens the critical path. If Stripe is one of many gateways, the uniform Payum contract reduces per-gateway integration cost.
• Upgrade/dependency policy (v2.1.0): The new release explicitly supports multiple Stripe SDK versions. That materially lowers the cost of keeping our Stripe PHP SDK current (security patches, API version bumps) without waiting on a gateway package release — a real operational win for a payment dependency.
• Checkout conversion/reliability (v2.1.0): The Stripe.js Elements form now re-renders when reusing a still-payable PaymentIntent. This addresses a recovery path — a customer returning to a pending PaymentIntent now gets a working form instead of a dead-end. Small, but it is the kind of bug that shows up as abandoned checkouts and support tickets.
• Best-fit use cases: Sylius storefronts (Sylius ships Payum), custom PHP/Symfony commerce apps already on Payum, and legacy-gateway migrations where a consistent abstraction is the goal.
• Ops/risk decision: Small surface, single purpose, low blast radius. Still a low-community-signal package, but v2.1.0 plus Sylius-org stewardship and named sponsor backing (Flux, Harman) is a positive sustainability indicator. Adopt it behind your own interface rather than coupling product code to it directly.

When to Consider This Package

Consider it when:

• You are already on Payum or Sylius. Its value is almost entirely in fitting an existing Payum pipeline; it is not a standalone Stripe SDK.
• You need Stripe as one gateway among several and want a uniform authorize/capture/refund/notify contract instead of a one-off integration.
• You want Stripe Checkout / Stripe.js with SCA and webhook handling without owning the payment state machine.
• You care about keeping the Stripe SDK current. v2.1.0's multi-SDK-version support means adopting it does not pin your Stripe PHP SDK to a single major line — relevant if you have a security-patch SLA on payment dependencies.
• You are comfortable pinning, wrapping, and testing a small MIT dependency yourselves.
• You can verify the supported PHP/framework matrix against your stack — v2.1.0 is a positive maintenance signal, but confirm it explicitly against your PHP/Laravel/Sylius versions.

Look elsewhere when:

• You are not on Payum. Direct Stripe SDK integration (or Laravel Cashier for subscriptions) is simpler and far better documented.
• You need capabilities beyond the gateway surface: Connect/marketplace payouts, Billing/Tax, complex subscription logic, advanced Radar rules. Payum's abstraction intentionally flattens these.
• You need vendor support, SLAs, or a large community. Star counts and dependent counts remain thin; you are largely on your own for edge cases. If that's unacceptable, budget internal ownership or pick a commercially supported integration.
• You want a Laravel-native answer. Without Payum in the app, the abstraction is overhead rather than leverage.

How to Pitch It (Stakeholders)

Executives: This is a low-cost (MIT) way to add Stripe card payments to our Payum-based checkout without building and maintaining a payment integration in-house. It lives in the Sylius organization with named sponsor backing (Flux, Harman) and a fresh minor release that both broadens Stripe SDK compatibility and fixes a checkout recovery path — signs of active stewardship, not an abandoned repo. Because it plugs into Payum's gateway abstraction, we can add or swap providers later without rewriting checkout. The trade-off remains adoption risk: small package, thin community, so we wrap it, pin the version, and treat it as replaceable. Net: faster time-to-market for payments with contained, reversible risk.

Engineering: It provides Stripe Checkout / Stripe.js gateways conforming to Payum's interfaces — webhook-driven status, refunds, SCA — so we write configuration and glue, not payment state machines. v2.1.0 is a minor, non-breaking release: multi-SDK-version support (fewer dependency conflicts when bumping the Stripe PHP SDK) and a fix that re-renders the Elements form when a still-payable PaymentIntent is reused (recovery flow). No deprecations or migration work indicated, so the upgrade is low-risk. We should still (1) pin the version, (2) wrap it behind our own payment port so a future swap is cheap, (3) add integration tests around webhooks, idempotency, PaymentIntent reuse, and failure modes, and (4) confirm the supported PHP/framework matrix. Track upstream issues; assume no SLA.

Finance/Legal: MIT licensing keeps cost at zero and legal review light. Stripe's own commercial terms still govern processing fees and compliance; there is no lock-in beyond the Payum abstraction itself.