Omnipay Bridge Laravel Package

Product Decisions This Supports

• Gateway coverage as a roadmap accelerator. Omnipay maintains a large catalog of PHP payment gateways (Stripe, PayPal, Authorize.Net, Sage Pay, WorldPay, and dozens of regional providers). This bridge lets the product reuse that catalog through Payum's abstraction instead of commissioning a native Payum gateway for each provider — a direct "buy vs. build" answer for the long tail of payment methods.
• Provider optionality / multi-PSP strategy. Supports product decisions around offering regional or backup payment providers without multiplying integration work: the same Payum-facing code path can reach any Omnipay-backed gateway, which is the strategic argument for keeping the payment layer provider-agnostic.
• Migration and legacy consolidation. Relevant when existing applications already run Payum and need to absorb gateways that only exist in the Omnipay ecosystem (or vice versa during a payments migration). Useful for phased cutovers where a full rewrite is not funded.
• Reduce time-to-market for experimental or low-volume channels. For secondary payment methods (local wallets, regional acquirers, B2B invoicing providers) where usage is uncertain, bridging is cheaper than a bespoke integration and defers the decision to invest natively until volume justifies it.
• Not a decision driver for: core checkout for high-volume, PCI-sensitive flows on its own — the bridge only adapts interfaces; it does not add tokenization, idempotency, or compliance capabilities beyond what the underlying gateway offers.

When to Consider This Package

Consider it when all of the following hold:

• The codebase is already standardized on Payum and the team is fluent in its GatewayInterface, Capture/Authorize/Notify actions, and token/storage model.
• You need one or more providers that have a maintained Omnipay driver but no first-party Payum gateway — this is the specific gap the bridge fills.
• The integration is for a secondary channel or a short-lived migration, not the primary revenue path where you are prepared to own long-term maintenance.
• You can absorb maintenance risk: the last tagged release is from January 2017, the package has zero dependents and a very small star count, so you will effectively be adopting an unmaintained artifact and should plan to fork and pin it inside your own codebase.
• You have validated PHP and dependency compatibility — check it against your PHP 8.x runtime, current Payum major version, and Omnipay 3.x; expect to patch signatures, deprecations, and any PSR/HTTP client assumptions before it runs.

Look elsewhere when:

• You are greenfield and not already committed to Payum. Adopt Omnipay directly or a currently maintained abstraction; there is no reason to add a two-hop bridge over a stale layer.
• The gateway you need already has a native Payum gateway — use it; the bridge adds indirection with no coverage benefit.
• The provider is on your critical payment path or subject to PCI DSS / SOC 2 / PSD2 SCA obligations where you need an actively maintained, security-patched dependency and a vendor you can escalate to. An eight-year-old package with no release cadence is a hard fail on most third-party risk reviews.
• You require formal support, SLAs, or a security disclosure process — none is available here beyond the MIT license and community goodwill.

How to Pitch It (Stakeholders)

One-line summary: A small adapter that lets our Payum-based payment layer reach the entire Omnipay gateway catalog — valuable as a cost-avoidance lever for gateway breadth, but an unmaintained dependency that must be treated as code we own.

For executives: Payments roadmap often stalls on "we need provider X." Each bespoke integration costs engineering weeks plus ongoing maintenance across providers. This package lets us reuse an existing open-source gateway catalog behind our current abstraction, so we can say yes to a regional provider or a backup acquirer without a new integration project. The trade-off is maturity: the project has not shipped since 2017 and has negligible adoption, so we would be adopting it as internal, forked code with our own patch and security-review obligations — not as a supported vendor dependency.

For engineering: A thin bridge implementing Payum's gateway interface over Omnipay gateways. Expect compatibility work before first use (PHP 8, current Payum/Omnipay majors, HTTP client), a fork pinned in our monorepo, and a named owner. It does not change how we handle tokens, storage, or webhooks — those stay in our Payum layer.

Recommendation: Do not standardize on it. Run a one-sprint spike on a single non-critical gateway to confirm compatibility and estimate the fork cost; if the spike is clean and we have an immediate provider gap, adopt it narrowly for that channel with an explicit exit plan (native integration once volume justifies it). If the spike is not clean, integrate Omnipay directly for that provider and leave Payum's native gateways as the default path.