Easypay Php Laravel Package

Technical Evaluation

Architecture fit gordalina/easypay-php is a plain PHP SDK wrapper around the easypay.pt API — not a Laravel package. There is no evidence of a service provider, facade, config publishing, or package discovery, so it will not "just work" inside Laravel's container. Architecturally it should sit as a low-level transport client behind our own PaymentGateway interface (authorize, capture, refund, status, webhook verification), bound as a singleton in a service provider we write. It must not be called directly from controllers, models, or jobs.

Integration feasibility Composer-installable and MIT-licensed, which keeps legal friction low. Feasibility hinges on facts that need verification, not assumption:

• Which easypay API generation it targets (easypay has iterated its APIs; an SDK pinned to a deprecated version is a dead end).
• composer.json PHP constraint, PSR-4 compliance, and Guzzle/PSR-18 version pins versus our Laravel runtime.
• Sandbox/test credentials support and whether the SDK exposes the operations we need: card payments, MB WAY, Multibanco references, refunds, and asynchronous callbacks.
• Presence of tests, CI, and tagged releases; the near-zero adoption (16 stars, 0 dependents) means there is no downstream signal to lean on.

Technical risk High relative to typical dependencies. This is effectively unvetted, single-maintainer code handling payment data. Principal risks: API-version drift and abandonment; unclear callback signature verification; retry/idempotency behaviour that could produce duplicate charges; and untyped or loosely validated request/response objects. The 0.23 score aligns with "treat as vendored code to be reviewed, not a trusted library."

Key questions

1. Which easypay API version and endpoints does it call, and is that version still supported?
2. Does it cover refunds, partial captures, and webhook/callback signature validation?
3. What is the PHP/Laravel compatibility matrix, and are constraints compatible with our runtime?
4. Is there a test suite, and does it run against a sandbox?
5. What is the maintainer's recent activity and response time?
6. Does it handle idempotency keys and timeouts in a way that is safe for payment retries?
7. What PCI scope does the integration imply — hosted payment page vs. direct card data?

Integration Approach

Stack fit A natural fit for a Laravel monolith or modular PHP service that already needs Portuguese payment rails. Wrap it: define an internal PaymentGateway contract, implement an EasypayGateway adapter that delegates to the SDK, register it in a service provider, and keep credentials in config/services.php sourced from the environment. Never let SDK objects leak into domain code.

Migration path Because there is no incumbent Laravel integration, the realistic path is adapter-first: build our interface and tests, then implement it with this SDK. That makes the SDK replaceable if it is abandoned or if we later migrate to easypay's current official API or another PSP. If we already have a PSP, run easypay in parallel behind a feature flag on a small traffic slice before any cutover.

Compatibility Pin an exact version, commit the lockfile, and verify PHP, Laravel, and HTTP-client constraints in CI. If the SDK's dependency pins conflict with our framework version, prefer forking and maintaining a thin internal copy over loosening our own constraints.

Sequencing

1. Source review and dependency/security audit; confirm API version and sandbox access.
2. Sandbox spike proving the full lifecycle: create payment, receive callback, refund.
3. Build the adapter, interface, config, and automated tests against the sandbox.
4. Harden the callback endpoint (signature verification, idempotency, replay protection).
5. Canary release behind a feature flag with reconciliation against easypay's dashboard.
6. Full rollout, then remove the flag; retain the abstraction for future PSP swaps.

Operational Impact

Maintenance Assume we own this code. Budget for periodic review, dependency bumps, and likely a fork if the maintainer goes quiet. Any easypay API change becomes our incident, not a vendor's.

Support No commercial support and a negligible community. Escalation is internal plus easypay's own merchant support. Document runbooks accordingly.

Scaling Payment volume for a Portuguese-market integration is unlikely to stress the SDK itself; the constraints will be network timeouts, connection pooling, and queue throughput on callbacks. Route payment calls through queued jobs with bounded retries rather than inline in request cycles.

Failure modes API deprecation or endpoint changes; timeouts and partial failures that risk duplicate charges without idempotency; dropped or replayed callbacks; refund and reconciliation mismatches; silent signature-verification gaps. Each needs an alert, a reconciliation job, and a manual fallback path.

Ramp-up Low for a mid-level PHP developer — the SDK surface is small and the adapter is a few days' work. The real cost is domain knowledge: easypay's payment methods, reference expiry, and settlement semantics. Pair the integration work with finance/ops sign-off on reconciliation before go-live.