Liontech Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for a new payment rail. This is a thin, MIT-licensed integration layer (service provider, facade, container bindings) over the nokimaro/liontech-php-sdk. Choosing it saves roughly a sprint of glue work — config wiring, singleton registration, webhook signature verification, RSA card encryption — without adding commercial lock-in. The real dependency is the SDK and, beneath that, FusionPayments itself.
• Roadmap: adding or replacing a payment provider. Relevant if FusionPayments (formerly LionTech) is already on the shortlist for cards, payouts, refunds, saved payment methods, or balances. The exposed client surface (auth, orders, payments, refunds, payouts, tokens, balances, transfers) maps cleanly to a provider-abstraction layer in your own codebase.
• Scoping PCI compliance. CardEncryptor and the RSA public-key flow mean raw PAN/CVV need not transit your application in the clear if you use encryption or hosted payment pages. That is a pricing-driving compliance decision (SAQ scope), not just a technical one — worth confirming with your QSA before committing.
• Multi-tenant / marketplace architecture. Single-account setups get container singletons; per-tenant credentials require instantiating Client directly, bypassing the container. This is an explicit, documented escape hatch — useful, but it means the package does not solve multi-tenancy for you. Plan for a tenant-aware client factory in your own code.
• Environment and operational parity. .env-driven config, a sandbox flag, and preloaded public keys make staging/production promotion and local development straightforward, and the published config file gives you a single reviewable surface for credentials.
• Delivery-risk signals to weigh. Zero stars and zero dependents, one maintainer, and an explicit "unofficial" label. That is a legitimate concern for a payments-adjacent dependency, but the blast radius is bounded: the wrapper is small, the license is permissive, and it can be vendored or forked if maintenance lapses. Treat it as a convenience layer, not a strategic platform commitment.

When to Consider This Package

• You are on Laravel 11–13 with PHP 8.3+ and already committed (or close to it) to FusionPayments; the package adds no upgrade burden beyond what Laravel's support window already imposes.
• You want webhook signature verification and card encryption implemented correctly once, rather than reinvented per project. The 1.1.0 changelog shows a real prior bug here (card encryption silently using the webhook signature key), which is exactly the class of mistake a shared, tested wrapper prevents.
• You value the quality gates as a proxy for maintenance: PHPStan at max level with strict rules, 100% test and type coverage claims, and CI across the supported PHP/Laravel matrix.
• You need one primary account per application environment. This is the well-trodden path.
• The FusionPayments rebrand and domain migration (1.3.0 moved default URLs to fusionpayments.io) is acceptable to you — but confirm with the vendor that the LionTech endpoints are not being sunset on a timeline that would strand ^1.1 of the SDK.

Look elsewhere or build directly when:

• You need an official, vendor-supported integration. LionTech/FusionPayments ships no first-party Laravel package; this carries no SLA, no support contract, and no security disclosure obligation beyond a volunteer policy.
• You require multiple accounts as a first-class feature. The multi-tenant story is "instantiate the client yourself," at which point you are effectively using the SDK, and the wrapper's value drops sharply.
• Your compliance or procurement process requires maintainer due diligence — contributor diversity, funding, security review history, or a named on-call party. A single-maintainer project with no dependents will not clear that bar for a payments-critical path.
• Your stack is PHP < 8.3 or Laravel ≤ 10. Hard requirement, no backport path.
• You need capabilities the README does not evidence: idempotency keys, retry/backoff policy, queue integration, structured logging, or rate-limit handling. Go to the underlying SDK docs, and if they are absent there too, budget for building them yourself.
• The vendor's roadmap is uncertain. A rebrand plus a domain migration within the package's short life is a yellow flag worth a direct conversation with FusionPayments' account team about long-term API stability.

How to Pitch It (Stakeholders)

For executives: We can add FusionPayments as a payment provider in days rather than weeks. This is a free, MIT-licensed Laravel connector maintained by one developer in the community — the vendor does not publish an official one — so we should adopt it as a time-saver, not as a strategic dependency. The integration is small enough that we can take ownership of it internally if the maintainer steps away. It also helps keep card data out of our systems, which can reduce our compliance scope and therefore our audit cost. The trade-off to accept knowingly is that support comes from us, not a vendor.

For engineering: Drop-in auto-discovery, no manual provider registration. All API clients are container singletons and reachable through the LionTech facade or constructor injection, so it fits existing Laravel idioms without a bespoke service layer. Webhook signature verification and RSA card encryption come wired and injectable (WebhookSignatureVerifier, CardEncryptor), removing the highest-risk custom code from the project. Config is .env-driven with a publishable file and a LionTechConfig::isConfigured() / isSandbox() guard for safe startup. Two caveats to design around: the container holds exactly one client, so per-tenant credentials mean constructing Client manually; and the package is a wrapper only — idempotency, retries, and observability are ours to build. Pin the SDK version, vendor the code if you prefer, and add a smoke test against the sandbox in CI so a maintainer going quiet surfaces as a failing build rather than an incident.