Easypay Php Laravel Package

Product Decisions This Supports

• Market expansion into Portugal: easypay.pt is a Portuguese acquirer/gateway whose value is localized payment methods — Multibanco references, MB WAY, Payshop, and local card processing. If "launch in PT" is on the roadmap, payment method coverage is a launch blocker, and this package is a candidate integration path.
• Build vs. buy at the adapter layer, not the gateway layer: this code is a thin client over easypay's HTTP API. The real buy decision is the merchant contract with easypay; this package only decides how much glue code we write. Rough sizing: days of engineering to wrap their REST calls ourselves vs. hours to adopt and fork this.
• Payment method coverage as a product requirement: if checkout conversion in PT depends on Multibanco/MB WAY (it does — cards alone under-serve the market), the decision is "which integration gets us those methods fastest," and a low-friction PHP client lowers the trial cost.
• Roadmap sequencing for a "local payments" epic: use it as a spike/prototype dependency to validate easypay's API shape, sandbox behavior, and webhook/notification flow before committing to a full abstraction (Omnipay driver, Cashier-style billable trait, or a multi-gateway router).
• Deprecation/consolidation decisions: with 16 stars and zero dependents, it is not a de facto standard. Treat it as a reference implementation and a fork candidate, not as a dependency you inherit maintenance immunity from. This informs whether we standardize on one payments abstraction or tolerate per-gateway clients.
• Opportunity signal (score 4.33): the gap is not the gateway — it's that there is no well-maintained, Laravel-native easypay integration (config publishing, service provider, signed webhook handling, idempotency, refunds, test fakes). That's a plausible internal package or, if we ever open-source, a small ecosystem play.

When to Consider This Package

Consider it when:

• The stack is PHP and, more specifically, Laravel/Composer-based — adoption is a composer require with no runtime services.
• easypay.pt is already the chosen or shortlisted acquirer (merchant account, pricing, and settlement terms settled or in negotiation).
• The scope is narrow: create payment, redirect/form flow, read status. You do not need a rich domain model.
• You are prototyping or running a low-volume launch and can accept owning the code. MIT license means forking and patching is legally and practically cheap.
• You need Multibanco/MB WAY/Payshop support and prefer to spend engineering effort on checkout UX rather than on re-reading a gateway's API docs.

Look elsewhere when:

• You need a gateway-agnostic abstraction (multiple PSPs, routing, failover, unified refunds/webhooks). Reach for Omnipay, Laravel Cashier-style patterns, or a payment orchestration layer — this package is point-to-point by design.
• You need strong guarantees on SCA/PSD2, 3-D Secure flows, and webhook signature verification. A 16-star, low-activity client cannot be assumed to track gateway API changes or security guidance. Verify against easypay's current docs and confirm the library covers the endpoints and auth scheme you actually need before committing.
• You need maintenance assurance: active issue triage, semver discipline, CI, PHP/Laravel version support matrix. Zero dependents is a signal that few teams are exercising it in production. Budget for a fork with your own tests and a named owner.
• Your stack is not PHP (Node, Python, Go, JVM) — write the client against easypay's REST API directly.
• You need inbound webhook handling, reconciliation, refunds, partial captures, subscriptions, or stored credentials/tokenization as first-class features. Likely out of scope; plan to build around it.
• Compliance posture requires a vendor with a support contract — go through easypay directly or a supported SDK.

PM checklist before adoption: confirm the library's last-commit date and PHP version constraints, confirm it targets the current easypay API version (not a deprecated one), map which endpoints it covers vs. which you'd hand-roll, and get an engineering estimate for forking plus a test suite.

How to Pitch It (Stakeholders)

For executives: This is a small open-source PHP connector to easypay.pt, a Portuguese payment gateway. It is not a strategic asset — it's a few hundred lines of glue that saves our team roughly a week of integration work if we enter the Portuguese market. The license is permissive (MIT), so there is no commercial or legal lock-in, and no cost beyond engineering time.

The strategic decision is not this package; it's whether Portugal is on the roadmap and whether easypay is the right acquirer. If yes, this library lets us validate the integration cheaply — sandbox, Multibanco and MB WAY flows, settlement behavior — before we commit to a full payments architecture. If no, ignore it entirely; it has no standalone value.

The risk is maintenance, not money. Sixteen stars and no downstream dependents tells us almost nobody is running this in production, so we should assume we own it: fork it, add tests, assign an owner, and track easypay's API changelog. Estimated ongoing cost is low but nonzero.

Recommendation: approve a timeboxed spike (one engineer, roughly one to two weeks) to prove out easypay's Multibanco/MB WAY flow using this library as the starting point. Do not adopt it as a production dependency without a fork-and-own plan, and do not let it become our payments abstraction — if we ever add a second gateway, we will need a proper abstraction layer above it.

For engineering: treat it as reference code and a head start, not a dependency. Verify endpoint coverage, auth, and webhook handling against easypay's current documentation first; wrap it behind our own PaymentGateway interface so it stays swappable.