Worldpay Laravel Package

Technical Evaluation

• Architecture fit: omnipay/worldpay is a thin gateway driver for the Omnipay PHP payment abstraction. It fits best when the application already uses Omnipay and needs WorldPay as another gateway behind a common purchase, authorize, capture, refund, and callback-style API. It is a poor architectural reason to introduce Omnipay solely for one WorldPay integration unless the team values the common gateway interface.
• Integration feasibility: Feasible for a legacy or narrowly scoped WorldPay integration: install via Composer, configure credentials, instantiate the WorldPay gateway, and map application payment flows to Omnipay requests/responses. Feasibility depends heavily on which WorldPay product/API the package targets and whether that API is still available to new or existing merchants.
• Technical risk: High lifecycle risk. The last release was 2017-10-23, adoption is low at roughly 24 stars, and the package likely predates current PSD2/SCA, 3DS2, tokenization, webhook, and API-version expectations. It may have undeclared constraints against modern PHP, Laravel, and Omnipay versions. The MIT license permits forking, but the team must own security and compatibility updates.
• Key questions:
  • Which exact WorldPay entity/product/API does this driver support: legacy WorldPay XML, WorldPay US, WorldPay UK, or a deprecated endpoint?
  • Is the target WorldPay integration still supported for the merchant account, and what migration deadlines apply?
  • Which Omnipay and PHP versions are actually compatible, and are dependencies still maintained?
  • Does the driver support required flows: authorize/capture, partial refunds, void, tokenization, 3DS/SCA, idempotency, webhooks, multi-currency, and settlement reconciliation?
  • What is the PCI scope, and can hosted fields/tokenization reduce it?
  • Is there a maintained fork, vendor support path, or official SDK that should replace this package?

Integration Approach

• Stack fit: Suitable for Laravel/PHP applications already comfortable with Composer and Omnipay. In Laravel, wrap the gateway behind an application-level PaymentGateway interface or service rather than calling Omnipay directly from controllers. Keep WorldPay-specific request/response mapping isolated.
• Migration path: Treat the package as a tactical adapter, not a strategic payment platform. First validate it in a sandbox against the merchant’s actual WorldPay contract. If viable, pin the exact Composer version and commit a fork or internal patch path before production. If not viable, use the package only as reference material for a direct integration with a supported WorldPay SDK/API.
• Compatibility: Verify PHP version constraints, Omnipay major version, Guzzle/HTTP client dependencies, TLS requirements, and Laravel service-provider compatibility. Run composer audit, static analysis, and a dependency graph review. Expect to fork for PHP 8.x, modern TLS, PSR-18 HTTP clients, or Omnipay 3 compatibility if not already supported.
• Sequencing:
  1. Confirm WorldPay product/API support and merchant eligibility.
  2. Build a sandbox proof of concept for purchase, authorize/capture, refund, void, and failure handling.
  3. Decide: use pinned package, maintain internal fork, or replace with supported SDK.
  4. Implement a gateway abstraction and feature flag.
  5. Add contract tests for request signing, response parsing, idempotency, and error mapping.
  6. Pilot with low-value transactions and reconciliation checks before broad rollout.
  7. Document exit criteria and a replacement plan.

Operational Impact

• Maintenance: Low upstream activity means the internal team must own maintenance. Budget for dependency upgrades, security patches, API deprecation changes, and regression testing. Avoid unpinned installs; use a private fork if production depends on it.
• Support: Community support is limited by low adoption. WorldPay/FIS support may not recognize the package, and Omnipay maintainers may not cover WorldPay-specific behavior. Establish an internal escalation path and retain sandbox/test credentials and sample payloads.
• Scaling: The driver itself is likely stateless and not the primary scaling bottleneck. Scaling risk sits in synchronous gateway latency, retries, reconciliation, rate limits, and webhook/callback processing. Use queues, timeouts, circuit breakers, and idempotency keys where the WorldPay API allows.
• Failure modes: Deprecated endpoints, TLS/certificate changes, authentication changes, SCA/3DS challenges, malformed or changed response formats, duplicate charges from retries, missed callbacks, currency/rounding issues, and silent partial failures. Log request IDs and gateway references, but never log card data or secrets. Build reconciliation and manual-review queues.
• Ramp-up: Low for developers familiar with Omnipay; moderate for everyone else because WorldPay-specific quirks, sandbox setup, and legacy API behavior require investigation. TPM should allocate discovery time for merchant configuration, test accounts, and payment-operations sign-off. PCI scope remains a compliance concern regardless of package simplicity.