Payum Bundle Laravel Package

Product Decisions This Supports

• Platform choice, before package choice. The single most consequential decision this package informs is whether the product runs on Sylius (Symfony) or Laravel. sylius/payum-bundle is a Symfony bundle with hard dependencies on Sylius\Bundle\ResourceBundle and Sylius\Bundle\CoreBundle; it cannot be installed into a Laravel application container. Frame the evaluation as "are we adopting Sylius for commerce?" — if the answer is no, this package drops out of the decision entirely and the real candidate is payum/payum core.
• Payment gateway strategy (multi-PSP vs single-provider). Inside Sylius, the bundle supplies a gateway registry and per-payment-method gateway configuration, so supporting Stripe + PayPal + an offline/invoice gateway is configuration and roadmap sequencing rather than re-architecture. This de-risks single-provider dependency and makes "add a PSP" a scoping conversation, not a rebuild.
• Payment lifecycle scope for v1. It wires a payment state machine with authorize / capture / refund actions plus admin-facing capture and refund operations. That directly determines whether auth-and-capture (high-value goods, hospitality, B2B invoicing) and partial refunds are in the v1 back-office scope — and those are demoable capabilities that shape ops headcount, not just engineering tickets.
• Build vs buy for payment orchestration. "Buy" here means adopting Payum's integration model instead of writing bespoke PSP clients. Custom build is only defensible for a single gateway with fire-and-forget charges; the moment you need uniform authorize/capture/refund semantics across several providers, the abstraction pays for itself.
• Compliance budget. Delegating tokenization and PSP interaction to Payum gateways keeps card data out of our systems and shrinks PCI DSS scope. That's a line item in the budget model, not a footnote.
• Roadmap risk: this is a bridge, not a foundation. Sylius is introducing its own PaymentRequest abstraction and moving away from Payum as the long-term payment model. Adopting it buys speed now at the cost of a known future migration — a trade worth making explicitly rather than by default.
• Use cases that fit: B2B commerce on Sylius needing invoice + card + wallet methods; marketplaces requiring per-channel gateway configuration; projects needing manual capture and refunds in admin; migrations off a legacy bespoke payment integration where the Payum action inventory becomes the migration scope.

When to Consider This Package

Adopt when:

• You are already on Sylius. This is effectively the only criterion. It is a [READ-ONLY] subtree split of the Sylius monorepo and arrives as a transitive dependency of sylius/sylius — you don't install it, you inherit it. The 11 stars and 0 dependents are artifacts of the split workflow, not signals of neglect; don't read them as adoption risk, and don't read them as health either.
• Your target PSP has a maintained Payum gateway factory, or you're prepared to own and maintain one. Do this inventory against the real provider list before committing.
• You need the authorize/capture/refund state machine and admin-visible capture and refund operations, rather than a single charge call.
• You need multi-store, multi-currency, or per-region gateway configuration — Sylius models this well and a Laravel rebuild would not.

Look elsewhere when:

• You are not on Sylius. Do not pull this into a Laravel app; there is no service provider, no config publish path, and no way to satisfy the bundle's Sylius dependencies. Use payum/payum core with an Eloquent StorageInterface if you genuinely need a uniform multi-gateway abstraction — but budget it as a multi-week build (credential encryption, gateway config UI, token lifecycle, state transitions), not an install.
• Your gateway coverage is hosted-checkout Stripe/PayPal. Laravel Cashier, Omnipay, or vendor SDKs reach the same outcome with far less surface area.
• You require SCA/3DS2-first flows. Payum's model predates much of the current PSD2 landscape; validate against your target Sylius version before planning around it.
• You need recurring billing or subscriptions. Payum provides no subscription management.
• You need vendor-level support guarantees. Payum is community-maintained with a small maintainer base; if a payment outage is revenue-critical, price in in-house ownership of the gateway factory or a Sylius/agency partner contract.
• You're starting a multi-year build on a Sylius version where Payum is already transitional. Confirm deprecation status against that version and ring-fence the migration estimate up front.

Operational rule for engineering: consume this via your sylius/sylius version constraint. Never pin sylius/payum-bundle independently — the split package tracks the monorepo and independent pinning invites version drift against core.

How to Pitch It (Stakeholders)

For executives: Payments are not something we build from scratch. This is Sylius's own integration with Payum, an established payment abstraction library, and it already covers the items that usually blow up a commerce budget: multiple payment providers behind one interface, authorize-then-capture, refunds from the admin console, and keeping card data out of our systems so PCI scope stays small. Two honest caveats. First, it only has value if we run commerce on Sylius — it is a Symfony bundle and cannot be dropped into a Laravel application; the low star count is a monorepo packaging artifact, not a neglect signal. Second, it is a bridge, not a permanent foundation: Sylius is replacing Payum with its own payment abstraction, so we adopt it to ship fast and ring-fence a migration estimate for a future Sylius major. The real risks to manage are strategic — framework lock-in and Payum's end-of-life path — not the package's quality.

For engineering: You get a gateway registry, per-payment-method gateway configuration, a payment state machine with authorize/capture/refund actions, and admin capture and refund operations out of the box. Use it as-is; do not fork it. It ships with sylius/sylius — do not install or pin the split package separately, or you will drift from core. Before we commit, two spikes: (1) confirm every PSP on our list has a maintained Payum gateway factory, including refund and 3DS behaviour; (2) prove credential encryption and key rotation before any live traffic. Then build token lifecycle and webhook idempotency, and test replay and out-of-order delivery — Payum's action-pipeline model is steep and few engineers can debug a stuck payment state machine at 2 a.m., so name an owner now. If we are Laravel-first, the recommended shape is Sylius as a payments service behind an internal API with a strangler boundary, not a shared runtime — Laravel and Symfony can coexist in one PHP version but not one application container. Finally, put the Payum-to-PaymentRequest transition in the upgrade plan today, while the codebase is small.