Paybox Bundle Laravel Package

Product Decisions This Supports

• Whether to add Paybox as a checkout option. Paybox (Verifone) is a mainstream PSP in France, and this package is a candidate building block for the redirect/form flow, request signing, and callback handling. If the business already has a Paybox merchant contract — common when banking with Crédit Mutuel/CIC or holding a Verifone relationship — this is the fastest-looking path to "we accept cards."
• Build vs. buy vs. wrap. The honest framing is almost never "adopt as a dependency." With zero stars, zero dependents, a score of 0, and hosting on a self-managed forge rather than Packagist/GitHub, this package functions as a reference implementation and an integration checklist, not inherited infrastructure. The realistic options are: fork and own it, or write ~200 lines in-house against Paybox's spec using this as a worked example.
• Roadmap sizing for the payments epic. It tells you whether Paybox acceptance is a one-sprint integration or a multi-sprint gateway-abstraction effort. The answer depends almost entirely on whether 3-D Secure 2 / SCA is in scope — for EU card payments it usually is, and that is the line item that turns a small wrapper into real work.
• How much to invest in gateway abstraction. Low adoption and unclear maintenance strengthen the case for an internal PaymentGateway interface (initiate / capture / refund / webhook) with Paybox as one adapter. That way a later switch to Stripe, Adyen, or Mollie is a configuration change and a new adapter, not a rewrite of checkout.
• Scope the first release to the happy path. Form-post redirect, success/failure/IPN callback, signature verification. Subscription billing, tokenization, partial refunds, capture-later authorization, and multi-currency are the features thin wrappers habitually skip — decide explicitly whether v1 needs them, because this package probably won't cover them.
• Risk posture for the payments path. Payment code is the highest blast-radius dependency in the product. Whatever we decide here sets the precedent for how we treat unvetted vendor code in revenue-critical flows.
• Use cases it plausibly serves: French-market storefronts, single low-volume checkout where a failed payment is recoverable by the customer, and reconciliation of Paybox callbacks into an orders table.

Caveat that should shape every decision above: the metadata is effectively a red flag set — no adoption, no community, no visible release cadence, unknown license, and a name ("bundle") that suggests Symfony packaging while we're evaluating it for Laravel. Treat it as unvetted vendor code and budget a code audit before it touches production payment paths.

When to Consider This Package

Consider it only when all of the following hold:

• Paybox is already mandated. You have a Paybox merchant ID (site, rank, identifier) and cannot freely choose the PSP. If the PSP is still an open question, a well-supported Laravel-native gateway is the better default.
• The stack actually matches. Verify whether this is a Laravel package (service provider, publishable config, facade) or a Symfony bundle wearing a Laravel label. The naming hints at the latter, and a framework mismatch means the "drop-in" saving evaporates.
• You need the happy path only — signed payment request and redirect, success/failure/IPN callback, signature verification. Not subscriptions, not stored cards, not partial refunds.
• You are prepared to fork and own it. Pin a commit, vendor the code, add tests around signature verification and callback idempotency, name an internal owner, and record the license determination in the SBOM.
• The blast radius is small. A single low-volume storefront where a broken payment is recoverable, not a high-throughput or high-AOV flow where a missed capture is a finance incident.
• You have time for a 1–2 day spike. Cheap to evaluate, cheap to abandon — that is the whole value proposition.

Look elsewhere, or build directly against Paybox/Verifone documentation, when:

• Maintenance cannot be verified. No stars, no dependents, no issue history, no CI visibility, and a private forge requiring credentialled VCS repository entries in CI. That is a supply-chain decision, not just a convenience one. Payment code is exactly where you cannot afford an abandoned dependency.
• 3-D Secure 2 / SCA is required. EU card payments need challenge flows and exemption handling. A thin legacy-style wrapper is unlikely to implement this; confirm before you commit any launch date.
• You need tokenization, recurring billing, partial refunds, capture-later authorization, or multi-currency.
• PCI scope matters and the flow could touch card data in your app. If it isn't strictly a hosted page or iframe redirect, the compliance cost dwarfs any integration saving.
• You want a vendor you can escalate to. A maintained official SDK or a well-adopted community package is the safer default unless Paybox is contractual.

Due diligence checklist before any adoption decision: license and provenance, recent commit activity, declared PHP/Laravel version constraints, the presence of signature-verification tests (including constant-time HMAC comparison), duplicate-callback and replay handling, whether sensitive payloads or secrets are logged, and whether the license permits commercial forking.

How to Pitch It (Stakeholders)

To executives — one paragraph: We have the option to add Paybox card payments using an existing open-source PHP integration rather than building the connector from scratch, which could shorten the initial build to roughly a sprint and unlock the French market or honor an existing Paybox merchant relationship. The catch is that it is effectively unproven — no public adoption, no community, hosted on a private forge, license unconfirmed. So I am recommending we use it as a starting reference, fund a short security and correctness review, and take ownership of a forked copy rather than depend on it as a maintained library. The risk we are actively managing is payment-path reliability and EU 3-D Secure compliance; we should confirm 3DS2 support before committing a launch date. Cost to evaluate is days, cost to abandon is near zero — the mistake would be adopting it blindly as a production dependency.

To engineering — the ask: Timebox a 1–2 day spike. Read the code, confirm whether it's Laravel or Symfony, check the license, and review the two paths that actually matter: HMAC signature generation and verification on callbacks (field ordering, constant-time comparison), and idempotency/replay protection on the IPN. Confirm 3DS2/SCA support, amount-handling in minor units, and Laravel version compatibility including behavior under config:cache. If it holds up, fork it, pin a commit, and put it behind an internal PaymentGateway interface so Paybox is one adapter among several. If it doesn't, keep the spike output as our integration spec and implement directly against Verifone's documentation — we've lost two days, not a quarter.

Decision framing: Low cost to evaluate, low cost to abandon, moderate-to-high risk if adopted blindly into the payment path. Approve the spike and the fork-and-own plan; do not approve it as a production dependency without a named owner, a pinned commit, and contract tests around request/response fixtures.