- Can I install myfatoorah/symfony-bundle in a Laravel application?
- No, not as a working integration. The package is a Symfony bundle, so it relies on Symfony's Kernel, bundle registration in config/bundles.php, DependencyInjection Extension load()/prepend() hooks, Configuration trees, and autoconfiguration tags that Laravel does not have. Composer will install the code, but nothing will wire it into Laravel's service container. The only realistic path is to consume the underlying HTTP client or SDK layer directly and build a Laravel adapter around it.
- What is the difference between a Symfony bundle and a Laravel package?
- A Symfony bundle ships a Bundle class with a build-time lifecycle, a DI extension that loads service definitions, and a Configuration class that validates a config tree. Laravel instead uses service providers with register() and boot(), a config/*.php file merged via mergeConfigFrom(), and facades or container bindings for access. A Symfony bundle's service definitions and autowired constructor arguments have no equivalent discovery mechanism in Laravel, so the bundle's services are never registered or resolved.
- Is there a framework-agnostic MyFatoorah PHP SDK I can depend on directly instead of the bundle?
- You need to confirm this before adopting it, because the answer determines whether integration is a wrapper or a rewrite. Look for a standalone myfatoorah/* SDK package, a plain client class, or a transport built on symfony/http-client or Guzzle that you can instantiate yourself. Also check whether services use constructor injection with plain value objects or Symfony-specific types like ParameterBagInterface, RequestStack, and HttpFoundation requests. If business logic is baked into Symfony services and DI parameters, extracting a usable core is real work.
- Which Laravel and PHP versions can run this MyFatoorah bundle?
- There is no official Laravel support matrix, because the package targets Symfony. The practical compatibility risk is transitive Symfony component constraints colliding with the versions Laravel 10 and 11 pin, notably http-client, options-resolver, and translation. Run composer why-not against those packages in a scratch Laravel project before committing to anything. Test on the PHP version your production hosts actually run, since the bundle's own minimum may differ.
- How do I integrate MyFatoorah into Laravel if the bundle will not work?
- Introduce a domain port, for example PaymentGateway, with methods such as createPayment, confirm, refund, status, and verifyWebhook, then write a MyFatoorahAdapter as its only implementation. Depend on the core SDK if one is published, or vendor the client classes into an internal package, and expose them through a service provider plus config/myfatoorah.php. Skip the facade, and keep MyFatoorah request and response DTOs out of controllers and jobs. This isolates Symfony-versus-Laravel drift and makes adding a second PSP for non-GCC markets a config change.
- How does the MyFatoorah integration handle amounts and 3-decimal currencies like KWD, BHD, and OMR?
- Verify this explicitly in the source rather than assuming. Confirm that amounts are passed in the smallest currency unit as integers and that zero-decimal and three-decimal currencies are handled correctly, since KWD, BHD, and OMR use three decimals and naive multiply-by-100 logic will be off by a factor of ten. Add unit tests around the conversion before you take live traffic.
- Does this package support 3-D Secure, webhook signature verification, and refunds?
- These are payment-critical and must be verified in the code, not the README. Check whether webhook payloads are authenticated with HMAC or a signature header and whether verification is enforced by default rather than optional. Confirm 3-D Secure flow handling, idempotency keys on capture and refund, and support for partial refunds. Also check whether checkout uses a hosted or embedded redirect, which keeps you in PCI SAQ A rather than SAQ A-EP.
- Is myfatoorah/symfony-bundle safe for production when it has no GitHub stars or public issue tracker?
- The repository is hosted on Azure DevOps rather than GitHub, so blank stars and dependents are a measurement artifact, not proof of neglect. The real concern is visibility: composer audit and Packagist advisories will not surface CVEs unless the package is registered there, and there is no public issue tracker, contributor graph, or release cadence signal. Pin an exact version rather than a caret range, and mirror the repo into an internal Composer registry such as Satis or Private Packagist so a repo outage cannot break your build.
- What is the recommended Laravel integration architecture for MyFatoorah?
- Wrap the SDK in a port-and-adapter layer and treat the gateway as an implementation detail. Define a PaymentGateway interface covering payment creation, confirmation, status, refunds, and webhook verification, and keep DTOs out of controllers. This keeps the Symfony-to-Laravel drift contained, allows a second PSP for markets outside the GCC, and lets you swap to a maintained fork without touching checkout code.
- Who maintains myfatoorah/symfony-bundle and what happens if it is abandoned?
- It is a single-vendor repository under dev.azure.com/myfatoorahsc with no community fork path, so if it stalls you own the maintenance. MyFatoorah is strong across the GCC for KNET, MADA, and Visa/Mastercard, plus Egypt and Jordan, so it is reasonable if that is your market and a liability if you need global coverage. Budget for a fork if you need patches, and confirm the license terms and whether the Azure DevOps repo is genuinely public-read with issue tracking enabled.