Sylius Paybox Bundle Laravel Package

Product Decisions This Supports

• Market entry for French-facing commerce. Paybox (Verifone) is a PSP that many French finance teams and enterprise buyers already hold contracts with. If the roadmap includes a France-first storefront or a French enterprise client, this bundle is the cheapest possible way to evaluate that checkout path — no bespoke gateway work required to answer "can we take Paybox?"
• Build vs. buy vs. adopt on payment plumbing. Payment connectors are high-blast-radius, low-differentiation work. The real decision is never "should we write this?" but "do we adopt this, fork it, commission a build, or change PSP?" An MIT-licensed drop-in bundle sets the floor price of that comparison against a commercial Sylius plugin or an agency engagement.
• Roadmap scoping and sequencing. The integration surface is a Symfony bundle registered through Sylius's native payment method configuration — install, configure credentials, validate the redirect and callback flow. That is a contained, estimable slice of a release, not a multi-sprint project. It can be scheduled, deferred, or time-boxed without disturbing the rest of checkout work.
• Deal velocity on partner-led requirements. Enterprise and franchise conversations routinely arrive with "we already bank with Paybox — can you take it?" Having a credible, costed answer changes the shape of due diligence and removes a blocker from the commercial path.
• PCI and SCA scope decisions. A hosted/redirect flow (which Paybox typically offers) determines whether you pursue SAQ A versus SAQ A-EP, and where 3-D Secure v2 / SCA responsibility sits. That is a product-and-legal call made cheaper by choosing the integration pattern before engineering starts, not after.
• Portfolio hygiene and support-tiering. With 2 stars and 0 dependents, the correct read is "unproven," not "unusable." That signal decides whether the capability ships as supported on the roadmap or as available on request, via an internally forked connector — and it sets the maintenance budget the roadmap has to carry.

When to Consider This Package

Consider it when:

• The application already runs Sylius (Symfony), and the team is comfortable reading and patching PHP bundles. Note the framing correction up front: this is a Sylius bundle, not a Laravel package — it cannot be dropped into a Laravel app.
• You hold, or can realistically obtain, a Paybox merchant contract. Confirm fees, settlement currency, and chargeback handling before spending engineering time.
• The requirement is a standard card flow — redirect to the PSP's hosted page, return, webhook confirmation — for a single entity, single currency, straightforward checkout.
• You need it fast and cheaply: an MVP, a market test, or one B2B client. Plan from day one to vendor the code into your own repository rather than track upstream releases.
• Someone can audit the payment flow end to end: signature verification on callbacks, idempotency on retries, handling of duplicate and out-of-order notifications, and reconciliation against Paybox's back office.

Look elsewhere (or budget explicitly for a fork) when:

• You need a maintained dependency with a release cadence, test suite, and SLA. Two stars and zero dependents means the bus factor is effectively "whoever forked it last." Treat the repo as reference implementation, not infrastructure.
• You require SCA / 3-D Secure v2, recurring or one-click billing, partial refunds, authorize/capture separation, multi-currency, or multi-PSP routing. Verify each against the source; do not infer parity from the gateway's own capabilities.
• The business is not French-market-first. If Paybox is a nice-to-have rather than a contract requirement, a well-supported PSP (Stripe, Adyen, Mollie) is usually the better product decision — better docs, better tooling, no orphaned dependency.
• You need Apple Pay / Google Pay, SEPA direct debit, or alternative payment methods in the same checkout. That is a different integration.
• Nobody can own a PHP/Symfony connector long-term. An unowned third-party bundle failing during peak trading is an outage with extra steps.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source connector that lets a Sylius storefront accept Paybox — a payment provider many French merchants and enterprise clients already use. Licensing cost is zero and the integration is scoped in days, not a project. The business case is market access and deal velocity: we can say yes to prospects whose finance teams insist on their existing PSP rather than asking them to switch. The caveat is support risk — the project is effectively single-maintainer with negligible adoption, so we should treat it as a head start, not a foundation. Recommendation: fund a time-boxed technical spike against sandbox credentials; if it holds, vendor the code internally so we control it. Keep it off the critical path of peak trading until it has a named owner and a documented fallback.

To engineering: The leverage is real — this wires Paybox into Sylius's payment method configuration as a standard bundle, so we are not writing the gateway handshake from scratch. The ask is a bounded evaluation, not adoption: install in a scratch environment, walk the full lifecycle (initiate → redirect → return → callback → reconcile), and report on four things — authenticity/signature verification on the notification, idempotent handling of duplicate and out-of-order callbacks, refund and cancellation coverage, and SCA/3DS2 handling. Assume no tests and no upstream responsiveness. If the spike passes, fork into our namespace, add integration tests around the callback handler, pin Sylius/Payum/Symfony/PHP versions, and own it. If it fails, the spike output is still the spec for whatever we build or buy instead — the time is not wasted either way. And if the target stack is Laravel rather than Sylius, stop here and instead scope extracting the Paybox protocol logic (request construction, HMAC, callback verification) into a framework-agnostic service, or evaluate an Omnipay Paybox driver.