Eway Laravel Package

Technical Evaluation

• Architecture fit: omnipay/eway is a payment driver for the Omnipay PHP abstraction layer, not a Laravel-native package. It fits Laravel/PHP systems that already use Omnipay or can isolate Omnipay behind an internal payment interface. Treat it as a tactical adapter for eWAY, not as a strategic payment platform component.
• Integration feasibility: Feasible for a controlled integration: install via Composer alongside omnipay/common, construct the eWAY gateway with merchant credentials, and wrap purchase, authorize, capture, refund, void, tokenization, and webhook handling in Laravel services/jobs. The main feasibility constraint is dependency compatibility with current PHP/Laravel/Guzzle versions.
• Technical risk: High relative to strategic packages. The package has only 14 stars and its last release was 2019-02-27, indicating low adoption and likely limited active maintenance. Risks include PHP 8.x/Laravel 10+/Guzzle compatibility gaps, missing modern SCA/3DS2 behavior, eWAY API changes, security patching gaps, and PCI/compliance exposure if card data or tokens flow through an unmaintained driver.
• Key questions:
  • Which eWAY product/API version is required: Rapid, Responsive Shared, Direct, or another integration?
  • Does the driver support our required flows: authorize/capture, refunds, voids, tokenization, 3DS/SCA, webhooks, and multi-currency?
  • Is the package compatible with our target PHP, Laravel, Omnipay, and Guzzle versions?
  • Who owns patching/forking if upstream is inactive?
  • What is the PCI scope, and can we keep card data out of our systems via hosted/tokenized flows?
  • Are eWAY webhook signatures, retries, and reconciliation semantics documented and implementable around this driver?

Integration Approach

• Stack fit: Best fit is an existing Laravel/PHP application with modest eWAY volume and a clear need to preserve eWAY merchant processing. Poor fit for greenfield platforms standardizing on Stripe/Adyen or requiring actively maintained SDKs.
• Isolation: Do not expose Omnipay request/response objects to domain code. Create an internal EwayPaymentGateway interface and adapter, with Laravel service-provider bindings, encrypted credential configuration, and a dedicated payment module.
• Compatibility: Establish a version matrix before development: PHP version, Laravel version, omnipay/common, Guzzle/PSR-7, and eWAY API version. Run composer why-not/dependency resolution in a branch and add static analysis plus sandbox integration tests.
• Migration path: Inventory current eWAY flows and stored tokens; map each flow to the driver’s supported operations; build parallel-run capability behind a feature flag; reconcile against eWAY settlement reports; cut over by merchant/region or payment method; retain rollback to the existing integration.
• Sequencing:
  1. Feasibility spike and security review against current Laravel/PHP.
  2. Sandbox proof of purchase, authorize/capture, refund, void, tokenization, and webhook handling.
  3. Build the internal adapter and webhook endpoint with idempotency and event storage.
  4. Add automated tests for declines, timeouts, duplicate submissions, and reconciliation.
  5. Pilot with low-volume merchants/transactions.
  6. Production cutover with monitoring and rollback plan.

Operational Impact

• Maintenance: Expect to own the dependency. With no release since 2019 and low community activity, budget for a fork or vendor patch path. Assign an owner for PHP/Laravel upgrades, eWAY API changes, security patches, and 3DS/SCA compliance.
• Support: Upstream support is likely community-only and thin. eWAY merchant support may cover API behavior, but not this driver. Define escalation paths for failed payments, token issues, and settlement mismatches.
• Scaling: Omnipay performs synchronous HTTP calls to eWAY. Use Laravel queues, timeouts, retries with idempotency keys, rate-limit awareness, and circuit breakers. Persist payment attempts and webhook events; never rely on a single request/response cycle for financial state.
• Failure modes: API timeouts, ambiguous responses after submission, duplicate charges, declined vs. errored payments, lost webhooks, invalid/expired tokens, 3DS challenge failures, currency/region mismatches, and settlement reconciliation gaps. Design for idempotency, manual review queues, and replayable webhooks.
• Ramp-up: A Laravel developer familiar with Omnipay can integrate basic purchase/refund flows quickly. Production hardening, compliance review, token migration, and reconciliation will take materially longer—plan for a spike plus one to two delivery iterations depending on volume and regulatory scope.