Lhv Connect Laravel Package

Technical Evaluation

Architecture fit. swiftmade/lhv-connect is a thin Laravel integration package for the LHV (Estonian bank) API — the typical shape being a service provider, a publishable config file for credentials, and a small set of façade/manager classes wrapping HTTP calls (payments, account statements, and related banking operations). That design lands cleanly inside a standard Laravel application: no queue worker, no schema changes, minimal bootstrapping, and no opinion imposed on your domain layer. For a TPM this is the good case — a connector package rather than a framework, so the blast radius of adoption is limited to the integration boundary.

Integration feasibility. Composer install plus vendor:publish for config, credentials injected via .env, and a first call against LHV's test environment. Effort is low on the happy path; the real unknown is external — whether LHV's onboarding, certificates/keys, and IP allowlisting are in place, since banking connectors almost always fail on the bank side first, not the package side. Confirm sandbox access before committing a sprint.

Technical risk. Three material risks. First, version posture: 0.2.0 is pre-1.0, so no semver stability guarantee and breaking changes are permitted in minor releases — pin the version and read every changelog. Second, bus factor: the release history is a single maintainer (aozisik) with a small PR count, which is normal for a niche regional connector but means support and security response are single-threaded. Third, the content of this release: adding Laravel 12 and 13 support is a forward-compatibility change, which is a positive maintenance signal, but it also touches the framework constraint in composer.json. Widening a version constraint is low risk in itself; the risk is transitive — a Laravel major bump can drag dependency updates into your app that have nothing to do with this package. Note also that "Laravel 12 & 13" support should be verified against the framework versions actually shipped and tested in CI, not just the constraint string.

Key questions.

• Which LHV API surface and version does the package target, and is it PSD2/payment-initiation scoped or narrower (e.g. account statements only)?
• What exactly changed in composer.json for 0.2.0, and is there a CI matrix proving Laravel 12 and 13 are tested rather than merely allowed?
• Is there a documented sandbox/test-environment path with LHV, and what onboarding lead time does it carry?
• What is the package's security disclosure process given a single maintainer?
• Does 0.2.0 contain any behavioural or signature changes, or is it purely a constraint widening? The changelog suggests the latter but is one line.
• Versioning policy: is there a stated path to 1.0, and will breaking changes be minor-versioned?

Integration Approach

Stack fit. Excellent for a Laravel-first codebase already using Composer and config-driven credentials. Assumes a reasonably current PHP version, which the Laravel 12/13 constraint implies. If the application is on an older Laravel (10 or 11), this release does not help you — the constraint may not cover you, so verify the require block rather than assuming backward coverage from the changelog headline.

Migration path. Effectively greenfield — there is no prior assessment and no incumbent implementation to displace. Treat adoption as a new integration, not a migration. The one migration-adjacent concern is the reverse case: teams that adopted 0.1.0 on Laravel 10/11 should not blindly run composer update; the widened constraint is additive in intent but the lockfile diff is what matters.

Compatibility. The 0.2.0 change is a compatibility expansion. On Laravel 12/13, this release converts the package from "likely blocked by constraint" to "installable." On Laravel ≤11, behaviour should be unchanged, but confirm the constraint did not drop older majors in the same edit — a widening PR occasionally narrows elsewhere. Pin to 0.2.0 exactly (or ~0.2.0) rather than a floating ^0.2.

Sequencing.

1. Read the composer.json diff for 0.2.0 and confirm minimum PHP and Laravel constraints against the target application.
2. Raise the PR that pins swiftmade/lhv-connect:0.2.0, and inspect the resulting lockfile diff for unrelated transitive upgrades.
3. Stand up config and credentials in a non-production environment; validate against LHV's test endpoint.
4. Build a thin internal adapter (interface plus one implementation) around the package façade so a future swap or major-version break is contained to one class.
5. Only then wire into production flows, with a feature flag.

Operational Impact

Maintenance. Low ongoing code maintenance, moderate dependency-watch overhead. Because the package is pre-1.0 and single-maintainer, budget a recurring line item for "check upstream releases and constraint drift" — at minimum each Laravel major cycle. The 0.2.0 release is evidence the maintainer is tracking framework releases, which is the signal you want; it is not yet evidence of a long-term support commitment.

Support. Primary support channel is the GitHub issue tracker with no commercial SLA. Escalation for an outage caused by this package is effectively "fix forward ourselves or vendor the code." Mitigate by pinning, keeping the integration behind an internal interface, and being prepared to fork — the codebase is small enough that forking is a realistic option rather than a theoretical one.

Scaling. Negligible application-side scaling cost: the package is I/O-bound on outbound HTTPS to LHV. Scale concerns are bank-side — rate limits, certificate rotation, connection pooling. Watch for synchronous calls placed on user-request paths; move payment initiation and reconciliation onto a queued job with retry and idempotency keys so a bank outage degrades gracefully instead of timing out requests.

Failure modes.

• Bank-side outage or maintenance window — highest probability, highest customer visibility. Needs timeouts, retries with backoff, and a queue.
• Credential/certificate expiry — silent, total failure at the worst moment. Put expiry monitoring on the cert, not just the secret.
• Upstream breakage in a 0.x minor — mitigated by exact pinning and reading changelogs before bumping.
• Abandonment — low probability near-term given active framework tracking, high impact. Track last-commit date as a standing health metric.
• Framework constraint conflict during a Laravel upgrade — the package becomes the blocker for the whole app upgrade. Note this now; 0.2.0 is exactly the class of change that resolves it, which is why this release is worth taking.

Ramp-up. A mid-level Laravel engineer can integrate the happy path in under a day; the schedule risk sits in LHV onboarding and regulatory/contractual prerequisites, not in the code. Estimate one engineer-week end-to-end including sandbox validation and the adapter layer, with bank onboarding tracked as its own dependency. No specialised banking-API knowledge is needed to operate it, though someone on the team should own the LHV relationship.

Verdict on 0.2.0. Take it. The change is a constraint expansion that unblocks current Laravel versions, with no indicated behavioural break — but verify the composer.json diff and pin the version before merging, and keep the integration behind an internal seam given the pre-1.0, single-maintainer profile.