Nets Easy Laravel Package

Product Decisions This Supports

Market expansion into the Nordics. Nets Easy (Nexi Group) is a dominant payment provider in Norway, Sweden, Denmark and Finland, with strong local method coverage (Vipps, Swish, MobilePay, Dankort, bank transfers) and B2B invoicing support. This package is a PHP client for that REST API — it enters the picture whenever a roadmap item reads "launch checkout in NO/SE/DK/FI" or "support Nordic payment methods."

Build vs. buy (really: adopt vs. wrap). Payments are a classic "buy the provider, build the thin client" decision. A package with 7 stars and 0 dependents does not meaningfully shift the buy side of that equation — it saves perhaps 2–5 developer-days of API plumbing and buys you no support contract, no security response, and no community. The honest framing is: this is a reference implementation to read, not a dependency to adopt at scale. Realistic options for a PM to weigh:

Feature-level decisions it informs. Checkout flows (hosted vs. embedded), authorize/capture/refund/partial-capture lifecycles, recurring and subscription billing via stored cards, webhook handling for settlement and chargeback events, and idempotency behavior on retries. Before committing to any payment feature spec, a PM should confirm the package actually covers it — a 2022-era wrapper may predate newer API capabilities, so treat coverage as unverified until engineering reads the source.

Portfolio and platform strategy. If your product already integrates Stripe or Adyen, adding this package creates a second, unmaintained integration path. That argues for using it only as a temporary bridge behind your own PaymentGateway interface, so the provider — and the package — can be swapped without touching product code.

Where it genuinely earns its keep. Fast validation spikes ("can we take a Vipps payment end to end?"), internal finance/admin tooling, back-office refund utilities, and MVPs where the merchant agreement with Nets already exists and speed beats durability.

When to Consider This Package

Consider it when:

• You already hold (or are actively signing) a Nets Easy merchant agreement — the provider decision is made, and this only saves integration time.
• You need a working checkout or refund path in days, not weeks, to validate a Nordic launch.
• Your volume and blast radius are low: internal tools, back-office, a pilot with a handful of merchants.
• Your team is PHP/Laravel-native, comfortable reading a small REST wrapper, and has at least one engineer who can own a vendored fork.
• You can pin the dependency and accept that "latest release: Nov 2022" means you, not a maintainer, will handle API drift and security patches.
• You're comfortable adding the things a thin wrapper usually lacks: webhook signature verification, idempotency keys on retries, retry/backoff, and structured logging of payment state transitions.

Look elsewhere (or build) when:

• Payments are revenue-critical and long-lived. Zero dependents and 7 stars mean no downstream production signal, no issue triage, no CVE response. For a system handling money and PCI-adjacent data, that is a governance problem, not a taste preference.
• You need an SLA, vendor support, or a security disclosure channel. MIT gives you the code, nothing else.
• The API surface you need is unverified or absent. Confirm in source (and composer.json) that captures, partial refunds, subscriptions, and webhook payloads are actually modelled before it lands in a roadmap.
• You're outside the Nordics, or already standardised on Stripe/Adyen/Klarna — the marginal value is zero and the integration sprawl is real.
• Your stack is not PHP/Laravel, or you're PHP 8.3+ and the package's constraint graph is stale.
• You need typed DTOs, exhaustive error mapping, or test doubles — expect to build them.

Default PM recommendation: time-box a 1–2 day spike. If it clears the required feature list, fork it, pin it, assign a named owner, wrap it behind an internal payment interface, and put "replace or re-fork" on the roadmap as an explicit line item. If it fails the spike, the 5–10 days to write a thin internal client is cheaper than the interest you'll pay on a dead dependency.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Nets Easy is the practical way to take local payments in the Nordics, and this package is a free (MIT), small PHP helper that shortens the plumbing work by a few days. The catch is maturity: seven GitHub stars, no downstream projects using it, and no release since November 2022. That means no vendor, no support line, and no one else to catch problems. It is a useful accelerator and a poor foundation. The recommendation is to use it to validate Nordic checkout quickly, keep it behind our own payment abstraction so it is replaceable in days, and budget a small amount of ongoing engineering ownership rather than assuming it maintains itself. Cost to try: one to two days. Cost to depend on it blindly: an outage or a security patch we have to write ourselves.

For engineering — the ask: Fork and vendor rather than depend on the upstream tag; pin the commit; add contract tests against the Nets Easy sandbox; audit what the wrapper does and does not do (webhook verification, idempotency, retry semantics, error taxonomy, currency and rounding handling, and partial capture/refund state transitions). Wrap it in our PaymentGateway interface so the provider is swappable. Confirm PHP version constraints and transitive dependency freshness before it enters the lockfile. Flag anything we'd have to write ourselves so it lands in estimation, not in a surprise mid-sprint.

Risks to state plainly in the decision record: unmaintained upstream, single-maintainer risk, API drift versus current Nets Easy documentation, unverified security posture, and zero ecosystem signal. Each is manageable with a fork and an owner; none is manageable by assuming the package will be looked after.