Omnipay Bundle Laravel Package

Product Decisions This Supports

• Gateway coverage on an existing Sylius storefront. The bundle is a configuration bridge that turns Omnipay gateway definitions into Sylius payment methods. As a PM, its leverage is answering "can we add PayPal / a regional PSP / a wallet to checkout without a bespoke integration each time?" — and only on a Symfony 2–3 + Sylius 1.x codebase.
• Build vs. buy, scoped to the glue layer. The buy decision is the integration plumbing, not payments. One abstraction plus N gateway packages is cheaper than N hand-rolled gateway services. Note the value sits in league/omnipay and the individual gateway packages; this bundle contributes wiring only.
• Technical-debt prioritization and migration sequencing. The most useful PM signal here is what the package's status implies: archived, READ-ONLY, 17 stars, 0 dependents, no maintainer. That makes it a "when do we retire this" input, not a "what do we add" input. It belongs in the roadmap as scheduled debt cleanup with a dated exit.
• Checkout conversion roadmap input (historical). Local payment methods and wallets are proven conversion levers; for legacy Sylius apps this bundle was the on-ramp to those gateways. Relevant only if the product still runs that stack — otherwise the roadmap item is the replacement path (native Sylius payment requests + official PSP SDKs, or hosted checkout).
• Explicitly not a lever for greenfield. No pricing, packaging, or new-feature decision on a modern stack should route through this package. It is not Laravel-native either: there is no service provider or facade, and its Symfony/PHP constraints will conflict with a current composer.json. For any Laravel product, the PM decision is "use league/omnipay plus the specific gateway package directly," not this bundle.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining an existing Sylius 1.x / Symfony 2–3 application already on Omnipay, and you need one more gateway with the smallest possible change surface.
• The target gateway exists upstream in Omnipay and can be wired purely through bundle configuration.
• You accept pinning a dormant dependency on a frozen stack, with a named owner and a documented exit date.

Look elsewhere when:

• The target is a new build, Sylius 2.x, Symfony 6+, or any Laravel application — use the framework's native payment architecture with official PSP SDKs, or a hosted checkout that keeps card data out of scope.
• You need active security maintenance, a current PCI-DSS/SAQ posture, SCA / 3-D Secure 2, or webhook and reconciliation tooling. An archived EOL stack is difficult to defend in an audit.
• You need recurring billing, multi-currency, split payouts, or dispute workflows — Omnipay's abstraction is shallow for these; a first-party SDK or Payum fits better.
• Adoption or support risk is a gating criterion: 17 stars, 0 dependents, archived, no maintainer means bus factor zero and nobody to escalate to.

Decision rule for a PM: if the question is "adopt or remediate," and the answer is not "we already run it," the answer is no.

How to Pitch It (Stakeholders)

For executives. This is a legacy adapter, not a strategic asset. It sits between the storefront and Omnipay's gateway catalog and contributes configuration convenience — nothing more. It is archived, unmaintained, and effectively unadopted, so it carries unpatched security and framework-compatibility risk in the highest-blast-radius part of our system: payments. Do not fund new capability on it. The real decision is not "should we use Omnipay" but "when and in what order do we move off this," and it should be budgeted as scheduled debt cleanup, not incident response.

For engineering. Do not introduce this into a new project, and do not treat it as a Laravel dependency — it isn't one. If you inherit it: pin the version, wrap it behind an internal PaymentGateway interface, and treat the bundle as replaceable glue. The durable dependency is league/omnipay itself, which can be wired directly via a small owned service layer (or a Laravel service provider) with less dead weight. Migrate gateway by gateway behind that same interface — today delegating to the bundle, then to direct Omnipay, then to native Sylius payment requests plus official SDKs or hosted checkout — so application and checkout code never changes. Sequence it as: inventory which gateways and flows actually traverse the bundle; freeze new gateway additions behind it; build the interface and move the highest-risk or highest-volume gateway first; retire the dependency; only then take on broader framework upgrades. Keep the payments migration and the Symfony upgrade on separate tracks, with the interface as the seam. Document the gateway inventory, credential rotation, and gateway-level health checks before touching code, and set an explicit retirement date so the program has a forcing function rather than an indefinite legacy tail.