Payment Sips Bundle Laravel Package

Product Decisions This Supports

• Feature scoping — "can we ship a SIPS card payment option this quarter?" The package is a pre-built adapter for the SIPS (Atos Worldline) gateway used by several French banks. The decision it unblocks is shipping card capture against an existing merchant contract versus spending two to four weeks reverse-engineering the signed request/response and callback protocol from bank documentation. That is the entire value proposition, and it is a real one.

• Market entry sequencing for France/EU. SIPS is bank-issued and protocol-documented, not developer-first like Stripe. Support for it is a gate on launching in that market. This package is a cheap way to validate the integration path — a sandbox spike — before committing roadmap capacity to the acquirer.

• Build vs. buy, resolved as "adopt as reference, build the wrapper." The asset is the encoded protocol knowledge: seal/signature construction, field mapping, response-code taxonomy, callback validation. That knowledge is worth more than the code. The PM decision is to treat it as an accelerator for an internally owned ~300-line adapter, not a long-term dependency.

• Dependency posture decision. Zero stars, zero dependents, single maintainer, and an upstream that was already abandoned once. This forces an explicit choice: vendor the source under MIT terms with a named owner, or do not adopt. There is no middle option where it is "just a composer require."

• Architecture decision it surfaces. Whatever the choice, the payment integration belongs behind an internal PaymentGateway interface so the acquirer — and this package — stay swappable without touching checkout, orders, or reconciliation. This is cheap to insist on now and expensive to retrofit.

• Use cases it fits: one-off or low-volume card capture for a French/EU storefront; a Symfony back office or B2B portal with a single acquirer; internal tooling that needs a payment step but not a payment platform.

• Diligence finding worth recording for roadmap planning: despite being framed as a Laravel/PHP package, the *-bundle naming and KptiveStudio lineage make it a Symfony bundle. If the roadmap assumes a Laravel service, this is not a drop-in and the effort estimate changes materially — plan to lift logic, not install a dependency.

When to Consider This Package

Consider it when all of the following hold:

• Your acquirer is SIPS / Atos Worldline and the merchant contract is already signed — the gateway is a constraint, not a choice.
• Scope is simple one-shot payments: authorize/capture, a hosted paypage form or redirect, and a callback. No tokenization, no marketplace splits, no multi-acquirer routing.
• The team is comfortable reading and patching third-party PHP, and someone is willing to own it by name.
• You will vendor or fork it, pin the commit, write tests around it, and review it on a cadence.
• You can wrap it behind an internal interface so replacement is a contained project rather than a rewrite of checkout.
• Volume and risk are modest enough that a self-maintained adapter is proportionate to the business.

Look elsewhere when:

• The application is Laravel. The bundle's DI container, Resources/config service definitions, and kernel lifecycle have no equivalent registration path in Laravel. Budget for a rewrite against the SIPS spec regardless of whether you start from this code.
• You need 3-D Secure 2 / SCA, recurring billing, refunds, partial captures, or multi-acquirer routing. A thin, unmaintained adapter is the wrong foundation for stateful payment lifecycles — and SCA is mandatory for EU card traffic under PSD2.
• You need vendor support, SLAs, security advisories, or PCI-DSS evidence from the integration layer. Zero external users means zero external scrutiny of signature and callback-validation code — a real audit talking point.
• The protocol target is Worldline Online Payments (REST). A bundle of this vintage likely implements the legacy certificate/sealed-field flow only; confirm which SIPS offer you actually have.
• The team has no capacity to own PHP payment code. An unmaintained fork with no upstream is a future incident, not a shortcut.
• A hosted checkout or modern PSP (Stripe, Adyen, Mollie, Payplug) is commercially acceptable — once maintenance is priced in, build-vs-buy usually favors them.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, MIT-licensed community fork of an abandoned adapter for the SIPS payment gateway used by several French banks. It is not a platform; it is a head start. Its value is that it already encodes how to talk to SIPS, which saves us a few weeks of protocol work if we launch in that market. Its risk is that nobody maintains it — no stars, no downstream users, and the original project was dropped once already. The recommendation is to use it as a reference implementation: fold the relevant signing and response-mapping logic into our repository under a named owner, and keep it behind our own payment interface. That buys the launch speed without taking on an unowned dependency. Cost is low; the commitment is ongoing ownership, not a license fee, and the expected lift is two to four days to a validated sandbox integration and one to two weeks to production-grade with reconciliation.

For engineering — the short version. Treat phcorp/payment-sips-bundle as documentation that compiles. Vendor or fork it, pin the commit SHA, and never call it directly from application code — put an internal PaymentGateway port in front of it so we can swap acquirers later. Assume Symfony, not Laravel: if we are on Laravel, lift the request-signing, field-mapping, and callback-verification classes into two or three plain PHP classes under our own namespace and rebuild the wiring as a service provider plus a callback controller. Sequence the work protocol-first, framework-last: a sandbox spike replaying a signed request and a callback, then extraction with fixtures (success, tampered signature, currency edge case), then the adapter, then reconciliation. Audit the signature and callback paths ourselves before go-live, since no one else will. Instrument the failure modes that cost real money — seal mismatch on key rotation, minor-unit amount encoding, character encoding in the Data blob, duplicate or out-of-order callbacks requiring an idempotency key and a pending → authorized → captured state machine, 3DS abandonment, and silent authorization expiry on a two-phase flow. Assign an owner and an annual review; an abandoned upstream means every future SIPS protocol change lands on us.