Payment Sips Bundle Laravel Package

Technical Evaluation

Architecture fit. The package name is the first finding: phcorp/payment-sips-bundle is a Symfony bundle, not a Laravel package, despite how it was described. It carries DependencyInjection/, *Extension.php, and Resources/config/ service wiring that only resolves inside a Symfony kernel. From a TPM standpoint this reframes the work item: we are not evaluating an installable dependency, we are evaluating a reference implementation of the SIPS protocol. That distinction drives every downstream decision — estimation, ownership, and whether this appears on a dependency inventory at all.

Integration feasibility. The scope is genuinely small. SIPS is a hosted-paypage flow: build a request payload, sign a canonical field string with a shared secret, POST or redirect to the PSP, then verify the signed payload on the callback. The bundle's value is that it encodes field ordering, signature construction, response-code taxonomy, and callback validation — protocol knowledge that otherwise comes out of bank PDFs and failed sandbox attempts. That is worth several days of engineering, not several weeks. It is an accelerator, not a foundation.

Technical risk.

• Provenance. Forked from an abandoned upstream, 0 stars, 0 dependents, single maintainer, no visible dependents to absorb a breaking change. There is no security advisory channel and no external scrutiny of the signing code — a real talking point in any PCI or vendor-risk review.
• Vintage. A Symfony bundle of this lineage likely predates Worldline's REST/SCA direction. Assume it implements the legacy certificate/sealed-field Paypage flow and does not do 3DSv2/SCA, which PSD2 makes mandatory for EU card traffic.
• Dependency conflicts. Old bundles pin old Symfony components. Because Laravel shares symfony/http-foundation, some constraints will collide outright. Budget for extraction rather than installation.
• Concentrated, manageable risk. Once the signer/verifier is lifted out, exposure narrows to two places: callback verification and amount/currency encoding. Both are testable in an afternoon.

Key questions for the team to answer before commit.

1. Is the consuming service actually Laravel, or is a Symfony service the real target? This changes the estimate by an order of magnitude.
2. Which SIPS product — Paypage (hosted form), Sips Office (server-to-server capture/refund/cancel), or the newer REST offer?
3. Does it handle 3DS/SCA at all, or is that entirely absent?
4. Legacy certificate signing or sealed HMAC — and is the algorithm still accepted by our acquirer today?
5. Does the fork have tags, tests, or CI? Assume no until proven otherwise.
6. Who is the named internal owner, and what is the vendor-and-patch policy?

Integration Approach

Stack fit. Poor as a dependency, adequate as a reference. The correct integration is a thin Laravel adapter around extracted logic — a service provider binding, a SipsGateway class, a return controller, a server-to-server callback controller, and a published config file. Do not bridge Symfony's container into Laravel's; two service registries in one request is a debugging surface nobody should own for a payment path.

Migration path.

1. Protocol spike (before any application code). Stand up a sandbox merchant ID and replay a signed request and a callback with curl/PHPUnit. Confirm field ordering, encoding, and signature algorithm empirically. This de-risks the entire plan for a few days of effort.
2. Extract. Lift the signer, verifier, and field mapper into two or three plain-PHP classes under our namespace, with fixtures: one success payload, one tampered signature, one amount/currency edge case.
3. Adapt. Wire behind an internal PaymentGateway interface so SIPS is swappable and mockable, and so the acquirer decision stays decoupled from checkout, orders, and reconciliation.
4. Vendor the remainder only if Sips Office (capture/refund/cancel) is in scope, and record the upstream commit SHA plus our delta.

Compatibility. Verify the PHP constraint, Symfony component versions, and ext- requirements (curl, openssl, possibly soap for Office services) against the target Laravel version. If symfony/http-kernel or symfony/dependency-injection cannot coexist, extraction is mandatory — which it already is on the Laravel path.

Sequencing. Protocol spike → extraction plus tests → Laravel adapter → callback and reconciliation → capture/refund → production cutover with a parallel run against the PSP console. Do not sequence the framework bridge first; it is the least valuable and highest-friction component, and validating the protocol early is what protects the timeline.

Operational Impact

Maintenance — the dominant cost. An abandoned upstream with zero dependents means no upgrade path, no CVE response, and nobody to ask. This must be modelled as owned code from day one: a named maintainer, a pinned fork, an entry on the dependency inventory with a compensating-control note, and a standing review on any Worldline protocol notice. A ~300-line extraction we wrote is materially cheaper to own than a bundle we inherited — that is the core of the recommendation.

Support. Vendor support covers the merchant account and the SIPS protocol, not this package. Escalation for "signature rejected" runs Worldline → PSP account manager → our extracted signer, in that order. Publish that path; it will be used.

Scaling. Effectively a non-issue. Signing is stateless and CPU-cheap; throughput is bounded by the PSP, not by us. The actual scaling concern is idempotency — callbacks arrive duplicated, out of order, or never (users close the browser). Reconciliation against the PSP transaction report is mandatory regardless of package choice, and this package does not provide it. Price it into the estimate as a first-class deliverable, not a follow-up.

Failure modes to instrument and alert on.

• Signature mismatch from key rotation or algorithm change — alert loudly, never silently drop.
• Amount encoding: SIPS minor units with currency-specific exponents; a 100.00 vs 10000 bug is a real-money defect.
• Character encoding in the Data blob for customer fields (UTF-8).
• Duplicate or out-of-order returns versus server-to-server notifications — require an idempotency key and a pending → authorized → captured state machine; never trust the browser return.
• 3DS challenge abandonment leaving orders in limbo.
• Missing capture on a two-phase flow, causing silent authorization expiry.

Ramp-up and estimate. Low for a PHP developer comfortable with HMAC signing; the learning curve is SIPS documentation and French-market specifics (cartes bancaires, 3DS, SEPA), not this package. Plan 2–4 days to a validated sandbox integration and 1–2 weeks to production-grade including reconciliation and state handling. The package itself saves hours, not days. Recommendation to stakeholders: use it as a reference implementation, extract what we need under MIT terms, assign an owner, and keep it behind our own payment interface — launch speed without taking on an unowned dependency. Cost is low; the commitment is ongoing ownership, not a licence fee.