- Is plemi/paybox-bundle a Laravel package?
- No. Despite the composer name, plemi/paybox-bundle is a Symfony bundle from the Symfony 2.x/3.x era, using DependencyInjection, services.xml, and a Bundle namespace. There is no Laravel ServiceProvider, facade, or publishable config/paybox.php. Treat any Laravel integration plan as a fork-or-reimplement task, not a composer require.
- Can I install plemi/paybox-bundle with Composer in a Laravel application?
- Usually not cleanly. Its composer constraints most likely pin old symfony/http-foundation and PHP versions that conflict with a modern Laravel runtime. If you need its logic, vendor or fork the signing and parameter-building classes instead of adding the bundle as a dependency.
- Which PHP and Symfony versions does plemi/paybox-bundle require?
- The bundle layout points to the Symfony 2.x/3.x era, so expect old PHP and Symfony constraints. Check composer.json before planning anything; it will not match a current Laravel or Symfony runtime. This alone makes direct installation risky for new projects.
- Does plemi/paybox-bundle verify Paybox server-to-server callbacks?
- You must confirm this in the source before trusting it. The Paybox flow includes a server-to-server callback (PBX_REPONDRE_A) and the browser return, and browser-return-only handling is exploitable because a customer can close the tab after paying. Verify that the bundle validates the signature on the callback and checks the response code, not just the presence of a return.
- Is HMAC-SHA1 signing in plemi/paybox-bundle safe for production payments?
- SHA-1 is deprecated, and legacy Paybox integrations often used HMAC-SHA1 by default. Paybox has supported stronger hashes for years, so shipping SHA-1 in a payment path is likely to be flagged in a security or compliance review. Prefer SHA-256 where Paybox supports it and keep the HMAC key out of logs and version control.
- How does plemi/paybox-bundle handle PBX_TOTAL amounts and currency?
- Legacy Paybox expects PBX_TOTAL in minor units (cents), and thin wrappers often leave that conversion to the caller. Confirm whether the bundle converts or passes the value through, and always send integers in cents with an explicit currency. A decimal amount here is a production incident waiting to happen.
- What Paybox response codes does plemi/paybox-bundle treat as success?
- Do not assume. A correct integration checks PBX_R against 00000 and verifies the signature, rather than treating any callback or return as paid. Read the code and re-validate against Paybox's preprod environment, because the bundle has no test suite or fixtures.
- How do I test Paybox payments if plemi/paybox-bundle has no sandbox harness?
- There is no test suite, fixtures, or sandbox harness in the bundle, so every behavior must be re-validated against Paybox's preprod environment. Build your own fixtures for the HMAC signer and parameter builder, and exercise the success, declined, and abandoned-cart paths. Do not trust the bundle's response-code handling without testing it.
- Is plemi/paybox-bundle maintained and safe to depend on?
- No visible activity, 12 stars, and 0 dependents mean you should treat it as unmaintained. There is no community to absorb a CVE or answer an issue, and no guarantee the repository survives. Fork it, extract the framework-agnostic signing logic, and own the code if you use it at all.
- What should Laravel developers use instead of plemi/paybox-bundle?
- Fork or vendor the HMAC signing and verification into framework-agnostic classes, or implement the current Paybox PBX_* redirect flow against official documentation or a maintained SDK. Keep the full-page hosted redirect so card data stays off your servers, which typically keeps you in PCI SAQ A rather than SAQ D. Reassess scope before anyone turns it into an iframe or direct card form.