Liontech Laravel Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Laravel-native design: Leverages Laravel’s service provider, facade, and dependency injection patterns, ensuring seamless integration with existing Laravel applications (v11–13).
  • Modularity: Exposes individual API clients (e.g., OrdersClient, PaymentsClient) via facade or DI, allowing granular control over LionTech’s API endpoints.
  • Security-first: Built-in webhook signature verification (WebhookSignatureVerifier) and RSA card encryption (CardEncryptor) align with PCI compliance requirements for payment processing.
  • Multi-tenancy support: Explicitly designed for multi-tenant scenarios (e.g., SaaS platforms) via direct Client instantiation with tenant-specific credentials.
  • Configuration flexibility: Supports environment variables and published config files, with validation for critical fields (e.g., LIONTECH_ACCESS_TOKEN).

• Cons:

  • Unofficial package: Lack of LionTech’s endorsement may introduce long-term compatibility risks (e.g., API changes, deprecations).
  • Limited adoption: Zero stars/dependents signals unproven reliability in production. The package’s maturity (last release: 2026-05-25) suggests active maintenance, but real-world usage is unknown.
  • Tight coupling to SDK: Relies on nokimaro/liontech-php-sdk (v1.x), which may introduce breaking changes if the underlying SDK evolves.

Integration Feasibility

• Laravel Ecosystem Compatibility:
  • Auto-discovery: Zero-config setup reduces friction for adoption.
  • Facade/DI duality: Supports both static (LionTech::orders()->create()) and injected (PaymentsClient $payments) usage patterns, fitting Laravel’s conventions.
  • Event-driven hooks: Webhook verification (WebhookSignatureVerifier) integrates cleanly with Laravel’s request pipeline (e.g., middleware or controller methods).
• Payment Workflow Integration:
  • Order/payment lifecycle: Aligns with common e-commerce patterns (e.g., CreateOrderRequest with successUrl, declineUrl).
  • Refunds/payouts: Dedicated clients for post-transaction operations (e.g., refunds()->create()).
  • Card encryption: Pre-built CardEncryptor simplifies PCI-compliant card data handling (e.g., tokenization for stored payment methods).

Technical Risk

• Critical Risks:
  • API drift: LionTech’s official SDK or API may diverge from the unofficial nokimaro/liontech-php-sdk, requiring manual patches or forks.
  • Webhook reliability: Signature verification depends on correct public key configuration (LIONTECH_WEBHOOK_PUBLIC_KEY). Misconfiguration could lead to false positives/negatives in fraud detection.
  • Token management: Refresh tokens (LIONTECH_REFRESH_TOKEN) must be securely stored and rotated. The package lacks explicit guidance on token revocation flows.
• Mitigation Strategies:
  • Fallback mechanisms: The package handles missing keys by fetching them dynamically from LionTech’s API (e.g., /signature-key or /encryption-key), reducing config errors.
  • Type safety: PHP 8.3+ and Laravel 11+ ensure type-hinted DTOs (e.g., WebhookPayload) reduce runtime errors.
  • Testing: 100% test coverage (per changelog) suggests robustness, but real-world edge cases (e.g., rate limiting, network timeouts) should be stress-tested.

Key Questions for Stakeholders

1. Compliance:
   • Does LionTech’s API align with your PCI DSS requirements? (e.g., tokenization, encryption standards).
   • Are there internal policies restricting use of unofficial SDKs?
2. Multi-tenancy:
   • Will you need per-tenant credentials? If so, the package’s Client instantiation pattern supports this, but performance/latency implications of dynamic clients should be evaluated.
3. Failure Modes:
   • How will you handle LionTech API outages? The package lacks built-in retry/circuit-breaker logic (consider integrating with Laravel’s Illuminate\Support\Facades\Http middleware).
   • What’s the fallback for webhook failures? (e.g., dead-letter queues for unprocessed events).
4. Long-term Support:
   • Is there a plan to monitor LionTech’s API changes and update the SDK? Unofficial packages may lag behind official releases.
5. Cost:
   • LionTech’s pricing model (e.g., per-transaction fees, volume discounts) may impact feature prioritization (e.g., refunds vs. payouts).

Integration Approach

Stack Fit

• Laravel Core:
  • Service Provider: Auto-registered via Laravel’s auto-discovery, eliminating manual bootstrapping.
  • Facade: LionTech:: facade provides a fluent interface (e.g., LionTech::payments()->create()), reducing boilerplate in controllers.
  • Dependency Injection: Individual clients (e.g., PaymentsClient) can be type-hinted into controllers/services, enabling mocking for testing.
• Payment-Specific Components:
  • Webhooks: Integrates with Laravel’s request pipeline via WebhookSignatureVerifier. Recommended to route webhooks to a dedicated controller (e.g., WebhookController) with middleware for signature validation.
  • Card Encryption: CardEncryptor abstracts PCI-compliant tokenization. Use in checkout flows to encrypt card data before sending to LionTech.
  • Configuration: Environment variables (.env) are preferred for secrets, but the published config (config/liontech.php) allows for runtime overrides.

Migration Path

1. Pre-integration:
   • Audit existing payment flows (e.g., Stripe, PayPal) to identify LionTech-specific requirements (e.g., webhook URLs, success/decline pages).
   • Set up LionTech merchant account and obtain test credentials (sandbox mode).
2. Initial Setup:
   • Install the package:

     composer require nokimaro/liontech-laravel
     

   • Configure .env with required tokens and URLs (sandbox/live):

     LIONTECH_ACCESS_TOKEN=your_live_token
     LIONTECH_SANDBOX=false
     LIONTECH_BASE_URL=https://api.fusionpayments.io
     

   • Publish config (optional) for customization:

     php artisan vendor:publish --tag=liontech-config
     

3. Core Integration:
   • Replace existing payment logic with LionTech clients:
     • Checkout: Use LionTech::orders()->create() to initiate payments.
     • Webhooks: Implement WebhookController with WebhookSignatureVerifier to handle async events (e.g., payment success/failure).
     • Refunds: Use LionTech::refunds()->create() for post-transaction adjustments.
4. Testing:
   • Test sandbox transactions end-to-end (e.g., success, decline, refund flows).
   • Validate webhook signatures using LionTech’s test payloads.
   • Load-test with expected transaction volumes (e.g., 100 TPS) to identify bottlenecks.
5. Go-Live:
   • Switch to live mode (LIONTECH_SANDBOX=false) and monitor for errors.
   • Implement rollback plan (e.g., fallback to legacy gateway) if LionTech API issues arise.

Compatibility

• Laravel Versions: Officially supports v11–13. Test compatibility with v10 if needed (may require minor adjustments).
• PHP Versions: Requires PHP 8.3+. Ensure your server meets this requirement.
• Dependencies:
  • Conflicts: None declared. The package uses Laravel’s container and HTTP client under the hood.
  • Overrides: Avoid naming collisions with existing facades/services (e.g., LionTech vs. PaymentGateway).
• Database: No schema migrations required. Stores payment data in LionTech’s API, not your database.

Sequencing

1. Phase 1: Core Payments
   • Implement CreateOrderRequest for checkout flows.
   • Route success/decline URLs to Laravel controllers.
2. Phase 2: Webhooks
   • Set up WebhookController with signature verification.
   • Handle events like payment.succeeded or payment.declined.
3. Phase 3: Advanced Features
   • Add refunds/payouts (LionTech::refunds()).
   • Implement card encryption for stored payments.
4. Phase 4: Multi-tenancy (if applicable)
   • Dynamically instantiate Client per tenant with tenant-specific credentials.

Operational Impact

Maintenance

• Configuration Management:
  • Pros: Environment variables centralize secrets. Published config allows team-specific overrides.
  • Cons: Missing keys (e.g., LIONTECH_WEBHOOK_PUBLIC_KEY) trigger API fallbacks, which may introduce latency or fail silently if the API is unreachable.
  • Recommendation: Document required .env variables and monitor for missing keys in logs.
• Dependency Updates:
  • The