Paybox Bundle Laravel Package

Product Decisions This Supports

• French market entry / Carte Bancaire acceptance. Paybox (Verifone/Point) is a major French acquirer. If roadmap includes EUR card checkout through a domestic acquirer — better interchange, a merchant contract we already hold, or a French entity's banking requirement — this bundle gives a concrete, low-commitment datapoint for what "integrate Paybox" actually costs.
• PSP strategy: single-provider vs. multi-PSP. Informs the "do we add Paybox alongside Stripe/Adyen, or consolidate?" decision without first committing engineering to a discovery sprint. The bundle is small enough to read in an afternoon, which lets product price the option cheaply.
• Build vs. buy on payment plumbing. Paybox's Hosted Page/System contract (PBX_* fields, HMAC signing, callback/IPN verification, 3DS return handling) is fiddly and failure-prone. The real PM question is: build and own ~200–400 lines, adopt a maintained abstraction, or reuse this as a reference? This package supports framing that decision as a time-boxed spike rather than a dependency bet.
• Scope shaping for Phase 1 vs. Phase 2. The bundle only plausibly covers Paybox System (redirect + callback). It does not model Direct (server-to-server), refunds, subscriptions, or newer Verifone APIs — so it clarifies what to cut from launch scope.
• Ownership and vendor posture. With 1 star, 0 dependents, one maintainer, and a dormant upstream, it forces the "vendored, internally owned module" call before code lands in a payment path.

Calibration: the score (0.005), opportunity (21.74), and adoption signals say this is a reference implementation, not a strategic dependency. Use it to inform decisions; do not let it become a silently installed production component.

When to Consider This Package

Consider it as a reference/spec artifact when:

• You are pursuing French/EUR card acceptance and want to price a Paybox integration before committing engineering.
• You already hold (or can realistically obtain) a Paybox/Verifone merchant contract with PBX_SITE, PBX_RANG, PBX_IDENTIFIANT, and HMAC key, plus preprod credentials. The contract and sandbox access gate everything; without them the package is untestable.
• Scope is intentionally narrow: hosted-page redirect, signed payload construction, callback signature verification, order reconciliation.
• You are on Symfony, or you are treating it purely as documentation-by-example to reimplement in Laravel.
• You will fork or pin a commit, assign a named owner, and write independent tests for signature generation/verification and the IPN endpoint.

Look elsewhere — do not adopt as a dependency — when:

• The stack is Laravel. This is a Symfony bundle (Bundle class, DI extension, EventDispatcher, YAML/XML service definitions). There is no ServiceProvider, facade, or publishable config. Adopting it in Laravel means hand-wiring classes outside the Symfony container, which is more work than a clean implementation.
• You need multi-PSP abstraction, unified refunds/webhooks, or a modern SDK → Stripe / Adyen / Mollie / Payplug, or a maintained Omnipay Paybox driver.
• You need maintenance guarantees, security responsiveness, or current PHP 8.x / Symfony compatibility. One maintainer, one star, no releases, no dependents, and a dead upstream is exactly the wrong profile for payment code.
• You need Paybox Direct (higher PCI burden), refunds, or recurring billing — the bundle does not cover these.
• A mainstream hosted-checkout PSP satisfies the commercial requirement, removing the risk entirely.

How to Pitch It (Stakeholders)

To executives: "This is a possible accelerator for a French launch, not a platform bet. It's a small MIT-licensed wrapper around Paybox's redirect-and-callback flow. Its strategic value is market access — it lets us quote a concrete integration cost for accepting Carte Bancaire through a French acquirer without funding a discovery sprint. The risk is maturity: near-zero adoption, one maintainer, dead upstream. Treatment: fork it, own it, or replicate the ~200–400 lines of logic in-house. Either way it becomes our code with our tests, not a third-party dependency."

To engineering: "Read it as a spec, not a dependency. It documents Paybox's PBX_* parameter set and HMAC signature scheme better than the vendor PDF does. It's a Symfony bundle — Laravel gets nothing usable directly — so the plan is a time-boxed spike: reproduce redirect + callback against Paybox preprod using the reference classes, extract the signature and IPN verification into our own namespace, and cover with unit tests for signing/verification and feature tests for the callback (idempotency, replay, malformed params, cents-integer amounts, currency 978, charset and URL-encoding rules, callback IP allowlisting). 3–5 days for the spike; ~1–2 sprints for a safe System-flow implementation with sandbox certification and reconciliation. Budget a named owner."

Decision to force: approve a time-boxed spike against a named French-market hypothesis (with confirmed Verifone merchant credentials), or decline and route French payments through the existing PSP. Do not let a 1-star, single-maintainer bundle become an unowned dependency in the payment path.