- How do I install and configure the laravel-fib-integration package?
- Install it with Composer using composer require rawahamid/laravel-fib-integration, then publish the package config with php artisan vendor:publish and set your FIB API credentials in your .env file. The package registers a configurable service provider, so you can call its client from a controller, job, or your own service class. Keep credentials per environment and never commit them to source control.
- Does laravel-fib-integration support a sandbox or test environment for FIB payments?
- Yes. Version 1.0.3 added a dev (sandbox) environment, so you can point the package at FIB's non-production endpoints instead of hard-coding base URLs or forking the config. Make sure the sandbox uses separate credentials and a separate base URL from production. Add a hard fail-fast check so an unset or invalid FIB_ENV value cannot silently route live traffic to the sandbox or vice versa.
- Which Laravel and PHP versions does laravel-fib-integration support?
- The package is built in idiomatic Laravel style and assumes a modern stack, generally Laravel 8+ with PHP 8.x and Composer 2. The supported version matrix is not clearly CI-enforced, so check the composer.json constraints and release tags before committing. Verify compatibility against your platform version as part of your evaluation.
- How does laravel-fib-integration verify FIB callbacks and webhooks?
- Callback and webhook verification is not documented in the package, so treat incoming FIB callbacks as untrusted until you verify them yourself. Implement signature or shared-secret validation, consider an IP allowlist, and add replay protection with idempotent processing. Persist raw callback payloads so you can audit and reconcile disputes later.
- Is laravel-fib-integration production-ready for handling real payments?
- Treat it as a thin adapter around FIB's API, not a payments platform. It is maintained by a single contributor with patch-level releases, and there is no visible evidence of a test suite, contract tests against FIB's sandbox, or documented idempotency semantics. For production, wrap it behind your own port interface, add logging, retries, reconciliation, and environment fail-fast guards before moving real money.
- Does laravel-fib-integration support idempotency on payment creation?
- The package does not document idempotency semantics, so do not assume it deduplicates payment creation requests. Generate a caller-supplied idempotency key per transaction and enforce uniqueness in your own database before calling FIB. That protects you from duplicate charges caused by retries, timeouts, or queue redelivery.
- How do I safely switch laravel-fib-integration between the FIB sandbox and production?
- The FIB_ENV setting now selects which FIB endpoint and credentials the package uses, which introduces configuration risk. Use strictly separated credential sets per environment, fail closed when FIB_ENV is missing or unrecognized, and clear your config cache after deploys. Add a startup assertion that confirms the resolved base URL matches the expected environment before any payment call.
- Can laravel-fib-integration be used alongside other payment gateways?
- It is not a multi-gateway abstraction layer; it is a single-gateway adapter for First Iraqi Bank. If you need several providers, define your own payment port interface and implement it with this package as one adapter. That keeps your domain code independent and lets you swap or add gateways without rewriting checkout flows.
- Is laravel-fib-integration actively maintained and supported?
- The package has a single contributor, patch-level releases, and a small changelog, with no stated support or security-disclosure policy. That is a governance risk for payment-critical code, so pin a tested version, review the source before upgrading, and consider vendoring or forking it. Plan for the possibility that you, not upstream, will fix issues.
- Does laravel-fib-integration store payment state and handle reconciliation?
- No. The package is stateless and makes no database, queue, or cache assumptions, so persistence of payment state, retry policy, and reconciliation are your responsibility. Design your own payments and payment_events tables, record every FIB request and callback, and build a reconciliation job against FIB's records. Keeping that logic in your application also makes audits and gateway migrations easier.