Lhv Connect Laravel Package

Product Decisions This Supports

• Build vs. buy for bank connectivity: This package is the "buy/borrow" option for reaching LHV Connect (LHV Pank's corporate banking API) from a Laravel codebase. It should be weighed against building a thin in-house client against LHV's own API docs — the decision hinges on how much of the package covers flows you actually need (payment initiation, account statements, reconciliation feeds) versus how much you'd wrap anyway.
• Roadmap sequencing for money-movement features: Any feature that touches outbound payments, payouts, refunds, or balance/statement sync can be scoped against this package's capability surface. If the package covers initiation plus status/statement retrieval, you can put "payment status visibility" and "auto-reconciliation" on the roadmap earlier than if you had to build the transport layer first.
• Market/segment expansion: Choosing LHV Connect constrains you to a specific bank and a specific (largely Estonian/Baltic corporate) customer segment. That is a product decision, not just a technical one — treat adoption as a commitment to that segment's banking rails.
• Framework upgrade planning: The 0.2.0 release adds Laravel 12 and 13 support. This directly de-risks a Laravel major-version upgrade for any team depending on the package, and it is a positive maintenance signal to feed into the build-vs-buy and dependency-health review.
• Vendor concentration and exit cost: Because this is a thin wrapper over one bank's API, the real product risk is bank/vendor lock-in rather than code lock-in. Use this evaluation to force a decision on whether an abstraction layer (a PaymentProvider-style interface) is worth the upfront cost so a second bank or PSP can be added later.
• Compliance and operations scope: Decide early whether reconciliation, audit trails, and manual retry/approval flows live in your product or in the bank's portal. That determines a meaningful chunk of back-office roadmap.

When to Consider This Package

Consider it when most of the following hold:

• Your product is built on Laravel and you are on, or actively planning to move to, Laravel 11/12 (0.2.0 explicitly adds 12 and forward-compat with 13), so the framework-fit argument is strong.
• You need server-to-server corporate banking flows — outgoing payment initiation, payment status, account statements/balances for reconciliation — rather than consumer-facing bank-link/redirect flows.
• Your customer base or your own treasury operations actually bank with LHV, or LHV is a required rail for your market.
• You want to validate a money-movement feature quickly (a pilot, an internal tool, an MVP payouts flow) without owning the API client surface.
• You can absorb pre-1.0 risk: this is a 0.x package, so minor bumps may carry breaking changes and there is no long-term support promise. Acceptable for internal tooling and pilots; needs scrutiny before it sits in a regulated production payment path.
• You are willing to read the source — at this maturity, the package is small enough to audit, and you should, given the domain.

Look elsewhere (or plan to wrap heavily) when:

• You need a multi-bank or multi-PSP abstraction out of the box; this is single-institution by design.
• You need consumer bank-link / account-information consent flows (PSD2 AIS/PIS redirect UX) rather than a corporate API client.
• You require a 1.0+, SLA-backed, or vendor-supported dependency for a regulated production path, or your procurement process cannot accept a 0.x community package handling payment credentials.
• Your stack is not Laravel — the value here is largely framework integration (config, service container, facades, HTTP client), which evaporates elsewhere.
• You need breadth of payment methods/countries beyond LHV's reach.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, focused, open-source Laravel component that lets our product talk to LHV Connect, a corporate banking API, without us writing and maintaining that integration ourselves. The new 0.2.0 release adds support for Laravel 12 and the upcoming 13, which means the maintainer is keeping pace with our platform and it will not become the thing that blocks our next framework upgrade. It is a low-cost way to test a payments or auto-reconciliation feature with LHV-banking customers before committing engineering headcount. The honest caveats: it is pre-1.0, single-bank, and community-maintained rather than vendor-supported, so we should use it for pilots and internal tooling first, keep our own thin abstraction layer so a second bank is not a rewrite, and gate any production payment path behind our own code review and a documented fallback to the bank's portal.

For engineering (bullets):

• Scope: thin Laravel wrapper over LHV Connect — expect config publishing, a service-container binding, and an HTTP client under the hood. Budget half a day to read the source before adopting; it's small.
• Version 0.2.0 is additive: Laravel 12 support plus forward-compatibility with 13, no reported breaking changes in the changelog. But it is a 0.x line — pin the version and read the diff on every bump.
• We own the risk surface: credentials handling, idempotency on payment initiation, retry/backoff, and reconciliation state are ours to design regardless of what the package provides.
• Recommended shape: wrap it behind an internal interface now (submit payment, fetch status, fetch statements) so a second bank or PSP is an implementation, not a migration. Cheap now, expensive later.
• Test strategy: contract tests against LHV's sandbox plus a recorded-fixture suite, so a package bump or a bank API change surfaces in CI rather than in production.
• Decision requested: approve a timeboxed spike (roughly one sprint, sandbox only) to confirm it covers our payment-initiation and statement flows; revisit the build-vs-buy call and the 1.0-readiness question at the end of that spike.