- Can I install gabrielextso/paybox-bundle in a Laravel application?
- No. This is a Symfony bundle (a fork of the dormant lexik/paybox-bundle) that ships a Bundle class, a DI extension with a Configuration tree, and service definitions, none of which a Laravel app can boot without a compatibility shim. Laravel has no bundle system or config/bundles.php, so there is no working install path. Treat the repo as a documented reference implementation of the Paybox protocol rather than a dependency.
- What does this package actually do for Paybox payments?
- It wraps the Paybox System hosted payment flow. It builds the request parameter set (PBX_SITE, PBX_RANG, PBX_IDENTIFIANT, PBX_TOTAL, PBX_DEVISE, PBX_CMD, PBX_RETOUR, PBX_HASH, PBX_TIME), signs the canonical string with HMAC, and validates the server callback Paybox sends back. It also supports switching between sandbox and production endpoints.
- Does it support Laravel 11 or Laravel 12?
- No. The package contains no Laravel service provider, facade, or framework constraints, and no Laravel version support is declared anywhere. It is built with Symfony idioms and the Lexik\Bundle\PayboxBundle namespace throughout. Any Laravel usage would require you to rewrite the adapter yourself.
- How do I install and configure it in a Symfony project?
- You install it with Composer and register the bundle in config/bundles.php, then supply your merchant credentials, site number, rank, identifier, and HMAC key through the bundle configuration. Sandbox and production endpoints are configurable. Confirm the target framework before installing, because the name says bundle but nothing about the package targets Laravel.
- Does it work with PHP 8 and Symfony 6 or 7?
- That is unlikely to be declared. The upstream project targeted Symfony 2.x and 3.x with PHP 5.x and 7.x-era APIs, and the fork does not document what it changed. Check composer.json for the PHP and symfony/framework-bundle constraints before assuming modern compatibility, and expect to patch code if you adopt it.
- How should I handle the Paybox IPN callback in Laravel?
- Put a dedicated controller on the return URL, recompute the HMAC over the returned parameters with your key, and compare it using hash_equals for constant-time verification. Then check the amount and currency against your stored order before marking it paid, and make the handler idempotent since callbacks can be retried. Never trust request parameters without a valid signature check.
- Is this package safe to use in production?
- Treat it as a reference implementation, not a blind dependency. It has a single maintainer, one star, no dependents, no releases, no changelog, and no advertised tests, and the HMAC verification path is unaudited. An unmaintained signature implementation sitting directly in the payment path is an unacceptable risk for most teams.
- Which Paybox product does it cover, System or Direct?
- It covers Paybox System: the hosted redirect form plus the IPN callback. Paybox Direct (server-to-server with a higher PCI burden), refunds, recurring payments, and Verifone's newer APIs are out of scope or unverified in this code. Decide which product you actually need before reusing any of it.
- Can I test Paybox integration without a merchant contract?
- Not realistically. You need a Verifone/Paybox merchant contract and preprod credentials (PBX_SITE, PBX_RANK, PBX_IDENTIFIER, and the HMAC key) before the flow can be exercised end to end. Make contract confirmation the gate for any estimate, and if French acquiring is only a hypothesis, validate that requirement first.
- What are the alternatives for Paybox payments in Laravel or PHP?
- The realistic options are reimplementing the thin adapter yourself (one gateway service, one signature helper, one callback controller, one reconciliation job), adopting a maintained Omnipay Paybox driver, or using Verifone's official SDK. Each should be judged on the same maintenance and security criteria. Many teams also find a mainstream PSP such as Stripe, Adyen, Mollie, or Payplug removes the risk entirely.