- How do I install nokimaro/liontech-php-sdk in a Laravel application?
- Install the SDK with composer require nokimaro/liontech-php-sdk and add a PSR-18 HTTP client such as Guzzle if you do not already have one. The SDK itself has no Laravel service provider, facade, or config file, so for Laravel-native bindings and configuration evaluate the companion nokimaro/liontech-laravel package. Alternatively, register your own small service provider that binds the PSR-18 client, Transport, and Nokimaro\LionTech\Client into the container.
- Is this SDK a Laravel package or a framework-agnostic PHP library?
- It is a framework-agnostic PHP SDK, not a Laravel package, and it has no container bindings, config publishing, or facade by itself. It is PSR-4, PSR-7, PSR-17, and PSR-18 compliant and is intended to be used with any compatible PHP application. For Laravel-specific features, the separate nokimaro/liontech-laravel wrapper is the relevant package to evaluate.
- What PHP and Laravel versions are supported by this SDK?
- The SDK requires PHP 8.3 or higher, so applications on PHP 8.1 or 8.2 need a platform upgrade before adoption. Laravel version support is not defined by this framework-agnostic SDK and must be checked against the companion nokimaro/liontech-laravel wrapper and your application matrix. Also note that Laravel's Http facade is not PSR-18-compliant, so it cannot be used as a drop-in HTTP client for this SDK.
- How do I point the SDK at the FusionPayments sandbox or change the API base URL?
- Pass the appropriate baseUrl and secureUrl values when constructing the Client or using the builder, rather than relying only on defaults. The README documents sandbox endpoints and test cards, which makes it straightforward to target the FusionPayments test environment. Overriding these URLs is also important because the provider rebrand from LionTech to FusionPayments involved domain changes.
- Can I use Guzzle, Symfony HTTP Client, or Laravel's Http facade as the HTTP client?
- Yes, the SDK is PSR-18 compliant, so you can bring any PSR-18 HTTP client, with Guzzle recommended in the README. A Symfony HTTP Client implementation can also work if it satisfies PSR-18, and reusing a standard client across integrations is a practical benefit. Laravel's Http facade is not PSR-18-compliant, so it cannot be dropped in directly without an adapter or a separate PSR-18 client binding.
- How do I verify FusionPayments webhook signatures with this SDK?
- Use the SDK's webhookVerifier() and signature() helpers to verify incoming webhook payloads before processing business logic. Verification should happen against the raw request payload and the signature supplied by the gateway, using secrets stored in your application configuration. Check the README for the exact header names and verification flow, and reject unverified webhooks early.
- Does the SDK cover refunds, payouts, transfers, and balances as well as payments?
- Yes, the SDK exposes domain sub-clients for orders, payments, refunds, payouts, tokens, transfers, and balances, plus auth, signature, webhookVerifier, and cardEncryptor helpers. Requests and responses are represented as typed DTOs such as CreateOrderRequest, Money, Currency, PaymentData, and EncryptedCardData. This gives IDE support and static analysis benefits compared with raw arrays.
- How should I handle card encryption and PAN/CVV data with the SDK?
- The SDK includes cardEncryptor() and EncryptedCardData support for RSA encryption of card data before transmission. You still need to decide whether your threat model accepts a third-party community SDK performing encryption of PAN and CVV, or whether that should be owned internally or delegated to hosted fields. Never log card data, and keep encryption and key-handling responsibilities explicit in your design.
- How can I test the FusionPayments integration without charging real cards?
- Use the sandbox endpoints and documented test cards with OTP flows from the README to exercise order, payment, refund, and related flows. Because the SDK depends on a PSR-18 client, you can inject a fake HTTP client or mock your own payment gateway adapter in Laravel tests. Also test webhook signature verification and failure paths, since the package's 96% coverage refers to the SDK's own test suite, not your integration.
- Is nokimaro/liontech-php-sdk production-ready, maintained, and what alternatives exist?
- Treat it as a community-maintained, unofficial SDK: the README says FusionPayments has no official PHP SDK, and the package has a single author, no vendor backing, and low ecosystem visibility. The code is CI-verified with 96% coverage, but pin versions, wrap it behind your own PaymentGateway interface, and avoid leaking Nokimaro\LionTech DTOs into controllers or jobs. Alternatives include a direct HTTP integration, an OpenAPI-generated client, or another maintained FusionPayments client if one becomes available.