Payment Be2Bill Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance. 2.0.0 is still Rezzza\PaymentBe2billBundle, a Symfony bundle — DI extension, configuration tree, compiler passes — with the reusable value sitting in its Be2bill client dependency and the request-signing / notification-verification classes. For a Laravel codebase, layer (1) remains dead weight: no service provider, facade, publishable config, or queue integration. The reusable asset is still the plain-Composer client wrapper and the Be2bill parameter/response models, which is where a Laravel integration should attach. Be2bill (Dalenys/Ingenico) remains a French PSP with hosted-page/redirect, iframe, and direct-API modes plus server-to-server notification callbacks; the package's core job is still building the signed payload and verifying notification hashes.

Integration feasibility. Materially improved on the mechanical dimension, unchanged on the assurance dimension. The prior assessment's strongest objection was that a 2018 composer.json pinned to PHP 5.6/7.0–7.1, Symfony 2.x/3.x, and old PSR-7/Guzzle would not resolve against Laravel 10/11 (PHP 8.2+, Guzzle 7, Symfony 6/7) — a 2.0.0 major bump is the conventional signal that this constraint set has been modernized, which would move adoption from "certain fork required" to "possibly installable as-is." Verify that directly from the tagged composer.json; the release note does not state it. Against that, adoption is still effectively zero, there is still no fork ecosystem or production evidence beyond the original author, and a major version published seven years after the last release, described only by a bare PR link, is a breaking change with no accompanying changelog or upgrade guide — an unusual and unwelcome pattern for payment-path code.

Technical risk. The risk profile has shifted rather than shrunk. Previously the dominant risk was a stale client that would not compile; now it is an unverified client that will. New concerns layered on the old: (a) undocumented 1.x → 2.0.0 delta — a major bump implies breaking changes, and in this domain the likely candidates are signature construction, parameter naming, endpoint paths, or the Guzzle/PSR-18 interface; any of these silently invalidate prior integration assumptions, so the PR diff must be read rather than inferred from the version number; (b) PSD2/SCA — still unresolved by a version bump, and still the single highest-impact question: if the 2.0.0 client does not emit 3DS2/SCA parameters, European card payments will be declined or degrade into issuer friction regardless of code quality; (c) API drift — modernization of the PHP side says nothing about conformance to Be2bill's current API contract; (d) security posture — a single modernization PR is not CVE triage, dependency currency, or a disclosure process; (e) PCI scope — unchanged: hosted/iframe keeps you in SAQ-A/A-EP, direct-API pulls card data into your environment, and the bundle still supports both, so scope remains a design decision.

Key questions. What exactly does PR #34 change, and does 2.0.0 carry a changelog or upgrade guide beyond that link? Is the tagged composer.json actually resolved against PHP 8.2+/Guzzle 7/Laravel 10–11, or does it only relax the upper bounds? Did the PR touch hashing, signing, or notification verification — i.e. must we re-validate the wire format rather than port the old one? Does the client emit 3DS2/SCA parameters, and does the provider require them for our merchant country and card mix? Is there now an official Be2bill/Ingenico SDK or maintained Omnipay driver that supersedes this? Are there tests in the PR, and do they run against the provider's sandbox or only mock the HTTP layer? And: does one modernization PR constitute a maintenance cadence, or is this a one-off — who owns the fork, and what is the patching SLA for a payment-critical dependency?

Integration Approach

Stack fit. Unchanged. Do not attempt to load the Symfony bundle into Laravel. Vendor the underlying Be2bill client — or extract the request-signing and notification-verification classes — and wrap it idiomatically: a Be2billServiceProvider, a publishable config/be2bill.php bound to env(), a Be2billGateway resolved through the container, and a Be2billNotification controller/job for callbacks. Keep the PSP behind a PaymentGateway interface so swapping to the official SDK or another provider is a binding change rather than a rewrite. The 2.0.0 bump does not change this shape; it only changes which version of the client you vendor.

Migration path. Route A (bypass the package, integrate the official SDK or a maintained Omnipay driver, using this repo as a reference for parameter names and hash construction) remains recommended and is now better informed — 2.0.0 is fresher reference material than the 2018 source. Route B (fork) is now cheaper than before: fork the 2.0.0 tag rather than modernizing the 1.x tree yourself, strip the Symfony bundle classes, keep the client, pin it via private VCS or path repository. That removes the bulk of the prior modernization work, but only if the tagged constraints genuinely resolve on our stack — confirm first, because a fork whose composer.json still conflicts is the worst of both routes. Route B remains defensible only if Route A has no maintained equivalent.

Compatibility. Two gates, in order. First, mechanical: resolve the 2.0.0 tag in a throwaway Laravel 10/11 skeleton and confirm a clean install with no --ignore-platform-reqs. Second, semantic: diff 1.x against 2.0.0 (PR #34) specifically for signature/hash logic, parameter naming, endpoint URLs, and the HTTP client interface, then validate the wire format against Be2bill's current spec rather than either version's source. Confirm the merchant account's API version and notification protocol, and secure sandbox credentials and a test merchant ID, before writing integration code. Expect some HTTP-layer rework regardless if the PSR-18/Guzzle surface changed in the major bump.

Sequencing. (1) Read PR #34 and the 2.0.0 changelog; classify the breaking changes as mechanical vs. wire-format. (2) Confirm PSP contract, API version, and mode (hosted vs. direct). (3) Spike: sandbox auth + capture + refund + notification verification using the 2.0.0 client. (4) Decide build-vs-fork on spike results, defaulting to the official SDK if one exists. (5) Implement the Laravel wrapper and config. (6) Build callback handling with idempotency keys and replay protection. (7) Load and negative test. (8) Ship behind a feature flag with a parallel-run period against any existing payment flow.

Operational Impact

Maintenance. Still the dominant cost, and largely unretired by 2.0.0. A single modernization PR after seven quiet years is a data point, not a cadence — assume no ongoing maintenance until a second and third release prove otherwise, and budget a named owner plus a standing quarterly review of the fork as before. Treat it as internal code with an external contract. The one genuine improvement is a lower starting point: forking a modern tree is far cheaper than modernizing a 2018 one, so the sunk cost of adoption drops even though the run cost does not. Security patching remains entirely ours; Composer audit will flag the transitive tree and require manual triage.

Support. No vendor support for the package, and the 2.0.0 release note — a bare PR link with no changelog, migration guide, or stated rationale — is itself evidence that support expectations should be low. Be2bill support covers the API, not this client. Debugging requires reading the provider's docs against source, now with the added wrinkle of two divergent versions in the wild; pin the exact tag and record it in the runbook. Onboarding remains low in code volume, high in domain context.

Scaling. Unchanged and unconstraining. The package is stateless request/response code, so horizontal scaling is not a constraint; throughput is bounded by the PSP's rate limits. The real scaling concern remains the notification endpoint — Be2bill callbacks arrive out of band and may retry, so handling must be queued, idempotent, and verified before any state mutation, with a durable queue and a dead-letter path.

Failure modes. Carried forward: silent signature mismatches after secret rotation; unhandled 3DS/SCA challenges surfacing as apparent declines; notification replay or forged callbacks if verification is skipped; timeouts on capture leaving orders indeterminate and requiring reconciliation; currency/amount-format regressions (minor units); provider deprecation of parameters the client still sends. Added by this release: upgrade-induced wire-format drift — a major bump with no published changelog means any assumption carried from 1.x is unvalidated until proven against sandbox, and a hashing change is silent by nature; and false confidence — a team seeing an active 2.0.0 release may assume maintained status that a single PR does not establish.

Ramp-up. Roughly unchanged: low code-reading time, high verification time. A competent Laravel engineer grasps the client in a day; validating correctness end-to-end against a live sandbox — auth, capture, refund, partial refund, 3DS challenge, notification ordering, reconciliation — realistically takes one to two weeks including compliance review. Add a half-day to read PR #34 and diff the two majors before any of that starts, and keep the pre-production security review of the fork in the estimate.