Worldpay Laravel Package

Product Decisions This Supports

• Legacy payment-rail continuity. If the product or any merchant-facing checkout still relies on legacy WorldPay (RBS/WorldPay UK hosted payment pages), this driver keeps payments flowing without a bespoke integration — a keep-the-lights-on decision, not a growth bet.
• Build vs. buy. It replaces an in-house WorldPay integration (redirect handshake, signature/response validation, order and transaction ID handling, callback handling) with a Composer dependency. The "buy" side is cheap (MIT, free); the real cost is the maintenance and talent burden of a stale package.
• Laravel/PHP architecture. Omnipay is framework-agnostic; adopting it implies a gateway-abstraction layer (GatewayInterface), which is a good decision if you want to swap PSPs later. This driver fits teams already standardized on Omnipay — it does not justify adopting Omnipay by itself.
• Roadmap and deprecation planning. Its stale state (last release 2017) is a forcing function: keep and isolate, or replace. It gives the "sunset legacy PSP" roadmap item a concrete date, owner, and risk entry.
• Scope and use-case fit. Best for low-volume, legacy-support scenarios — UK/EU merchants on old WorldPay accounts, admin-initiated payments, migration bridges. Not a fit for greenfield checkouts, modern tokenization/subscriptions, or SCA/3-D Secure 2-heavy flows without extra work.

When to Consider This Package

Consider it when:

• You already run Omnipay (or are willing to) on a compatible version — verify against Omnipay 3.x, since a 2017 release likely targets Omnipay 2.x; a major-version mismatch is a hard blocker.
• The business genuinely still uses legacy WorldPay (hosted/redirect payment pages), and the alternative is a custom integration or a stalled migration.
• Volume and risk are low and time-boxed — a bridge to a modern PSP, not a permanent foundation.
• You can pin and isolate it behind your own PaymentGateway interface, with contract tests and a documented exit plan.
• You have in-house PHP capacity to read and maintain a small, unmaintained MIT package (forking to patch is viable).

Look elsewhere when:

• You need modern Worldpay APIs (Access Worldpay / Worldpay Online / FIS-era) or US Worldpay (ex-Vantiv) — this driver targets the older integration.
• The roadmap requires active maintenance, security response, and vendor support — a 2017 last release and 24 stars signal a small or absent maintainer base.
• You want native Laravel ergonomics (Cashier, first-party SDKs) or PCI-scope reduction via modern tokenization/hosted fields.
• You're doing a new build — don't anchor new architecture to a legacy driver.
• You need SCA/3-D Secure 2, webhooks, idempotency, refunds and partial captures as first-class features — validate coverage explicitly before committing.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed adapter that lets us keep accepting payments through our existing legacy WorldPay account inside our Laravel app, without building a custom integration. The trade-off is age: last release was 2017, the community is small (~24 stars), and it likely targets an older Omnipay version. Translation: it's a cheap bridge, not a strategic asset. I recommend a time-boxed adoption — use it only where a legacy WorldPay account must keep working — with a named owner and a migration date to a modern PSP. Budget for a security and dependency review, and plan for replacement; the license is free, but the hidden cost is maintenance and the risk that the vendor deprecates the old endpoints.

For engineering: Treat it as a thin, isolated adapter. Pin the Composer version, confirm Omnipay major-version compatibility before scoping, and wrap it behind our own gateway interface so it can be swapped without touching checkout code. Validate only the flows we actually need (redirect, response signature/callback, refunds, error handling) with contract tests, and document a fork strategy — we may need to patch an unmaintained dependency. Keep it out of domain models.