Liontech Php Sdk Laravel Package

Product Decisions This Supports

• Go/no-go on FusionPayments as a payment processor. The SDK's breadth (orders, payments, refunds, payouts, tokens, transfers, balances) tells you what the gateway actually supports before you commit. If a capability you need isn't in the client list, it likely isn't in the product.
• Buy vs. build on payment integration. Payments integration is a well-understood, low-differentiation engineering task. This package turns what is typically 4–8 engineer-weeks of HTTP plumbing, DTO modelling, retry/auth handling, and edge-case debugging into roughly a day of wiring — a clear "buy" unless you have a specific reason not to.
• Roadmap acceleration for checkout, refunds, and seller payouts. The typed request/response objects map directly onto product epics: "accept online payment," "issue self-serve refunds," "pay out to sellers," "save a card for repeat purchase." Each maps to one or two methods here.
• PCI scope reduction as a product risk decision. Built-in RSA card encryption and webhook signature verification mean the "encrypt card data in transit to gateway" and "verify webhook authenticity" controls come pre-implemented rather than designed from scratch — a real compliance-scope and audit-cost input.
• 3DS / challenge-flow UX decisions. requiresRedirect() / getRedirectUrl() / isSuccessful() surface the friction points early, so the checkout UX and drop-off analysis can be scoped in the same planning cycle as the API work.
• Laravel vs. framework-agnostic architecture. This package is not Laravel-native — it is a PSR-18 SDK with a separate nokimaro/liontech-laravel wrapper (service provider, facade, config). That is a two-dependency decision, and it should be made explicitly, not discovered mid-sprint.
• Build-vs-fork contingency. Single maintainer, zero stars, zero dependents. If the integration becomes business-critical, the realistic roadmap item is "vendor the SDK or fork it internally," and that should be a named line item rather than an unspoken assumption.

When to Consider This Package

Adopt it when:

• FusionPayments (formerly LionTech) is already the chosen or shortlisted processor — this is the only PHP SDK path, since the provider ships no official one.
• The stack is PHP 8.3+ (hard requirement; the SDK uses enums, readonly classes, and typed properties). Laravel users should plan on the companion wrapper for config, DI, and facades.
• You want typed, domain-oriented objects and typed exception handling (TokenExpiredException, ValidationException, RateLimitException, ConflictException, etc.) rather than untyped arrays and string status codes — this materially lowers integration defects.
• You need webhook verification, card encryption, or token refresh, and would otherwise build those from scratch.
• You accept the trade: MIT-licensed, 96% coverage, CI, changelog — but a community library with one effective maintainer and no adoption signal.

Look elsewhere when:

• The processor decision is still open. Do not let an SDK's ergonomics drive a multi-year payments commitment; evaluate the gateway on rates, settlement, coverage, and support first.
• You require vendor-backed support, an SLA, security disclosure guarantees, or a procurement-approved dependency. An unofficial community package will not clear most enterprise third-party risk reviews without an internal fork-and-own plan.
• The team is on PHP < 8.3, or the app is not PSR-18/PSR-17 compatible and you don't want to introduce Guzzle.
• Your transaction mix is high-volume or heavily reconciled — you will want an abstraction layer you control, and possibly a payment orchestrator (Stripe, Adyen, etc.) with an officially supported SDK and a much larger maintenance base.
• You need a guaranteed upgrade path across gateway API changes. The rebrand from LionTech to FusionPayments already forced a domain-default change here; expect more of that, on the maintainer's schedule, not yours.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a small, free, MIT-licensed PHP library that removes the custom work of integrating the FusionPayments (formerly LionTech) payment gateway. It wraps orders, payments, refunds, payouts, saved cards, transfers, and balances behind a clean, typed interface, and includes the two security controls that are easiest to get wrong: card-data encryption and webhook signature verification. Practically, it compresses a multi-week integration into days and reduces our PCI exposure. The caveat is counterparty risk — it is community-maintained with a single primary author, no official vendor backing, and essentially no adoption yet. The recommendation is to adopt it, but only behind our own thin adapter interface and with a pinned version, so that swapping the processor or forking the library stays a contained engineering task rather than a rewrite.

For engineering — the pitch: PHP 8.3 SDK, PSR-4/7/17/18, bring-your-own HTTP client, 96% test coverage, real CI, versioned changelog with behavioural fixes documented (e.g. required webhookUrl on refunds, auth headers on GET, envelope unwrapping in the exception mapper). Typed exceptions and typed DTOs mean the domain model is legible from the client surface. Recommended posture: pin the version, vendor or fork if the integration becomes revenue-critical, keep every SDK call behind an internal gateway interface, and treat the baseUrl/secureUrl defaults as configuration — not constants — given the provider's recent rebrand and domain decommissioning. If we choose Laravel, budget for the separate wrapper package and its own maintenance.