Paybox Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy: Use this package as a reference implementation for Paybox request construction, signature verification, and callback handling—not as a strategic dependency for a new Laravel product. It informs whether to build a thin internal Paybox adapter, buy a maintained PSP integration, or use provider-hosted checkout.
• Legacy roadmap: Supports a sustain/freeze/migrate decision for an existing Paybox footprint. The archived status, 2019 last release, 39 stars, and zero dependents make it a legacy-support input, not a forward-looking platform choice.
• Feature scoping and estimation: Helps estimate legacy Paybox checkout, payment callback, reconciliation, and refund/capture work if the business already has Paybox merchant accounts or French-market payment requirements.
• Laravel architecture choice: Clarifies that this is a Symfony bundle, not a Laravel-native package. For Laravel teams, its PM value is mainly protocol/reference value; direct adoption creates framework mismatch and maintenance risk.
• Vendor consolidation: Supports standardizing on one maintained payment integration and isolating Paybox behind an internal payment adapter if temporary support is required.
• Risk and budget framing: Because the package is archived with negligible adoption, any use implies owning forks, security review, compatibility work, and an exit plan—costs that should be budgeted explicitly.

When to Consider This Package

• You have an existing Symfony/PHP legacy application already using Paybox and need a short-term reference or maintenance bridge.
• You need to understand a legacy Paybox integration flow—request building, PBX_RETOUR contracts, callback handling, or payment status handling—for a migration or audit.
• Your product has a small, stable Paybox footprint with no near-term feature roadmap and an accepted plan to migrate away.
• You can perform security, PCI, and compatibility review and pin PHP/Symfony versions in a controlled legacy environment.
• You are not building a new Laravel payment flow. For that, look for a maintained Laravel-compatible Paybox/PSP integration, an official provider SDK, or a hosted payment page.
• Look elsewhere if you need active support, modern PSD2/SCA behavior, current API coverage, long-term maintenance, high transaction volume, or a clean Laravel package. Avoid it if the team lacks Symfony expertise or cannot isolate and retire the dependency.

How to Pitch It (Stakeholders)

Executive summary: This is a low-adoption, archived Symfony bundle for Paybox, not a modern Laravel package. It is useful as a reference for legacy Paybox behavior or a short-term bridge, but it is not a safe foundation for new payment features. The product recommendation is to avoid new investment in this dependency, use it only to assess or maintain an existing Paybox footprint, and budget migration to a maintained payment integration.

For executives: The package reduces discovery risk around legacy Paybox flows but increases ownership risk: no upstream security patching, no modern framework guarantees, and no community validation. Treat it as a migration and audit input, not a strategic payment platform. Approve it only with a clear exit path, security review, and vendor-consolidation plan.

For engineering: Treat it as legacy reference code. Extract only the reusable MIT-licensed logic—request construction, HMAC/signature verification, callback parsing, and response mapping—into a Laravel-native payment adapter. Validate Paybox contract type, sandbox access, 3-D Secure/recurring/refund requirements, and PHP/Laravel compatibility before committing. Add tests for success, decline, timeout, duplicate callback, refund, and signature-failure paths, and complete security/PCI review before rollout.