Payment Sips Bundle Laravel Package

Product Decisions This Supports

• Payment provider strategy for French/EU markets — This bundle is a historical reference for what an ATOS SIPS (Worldline) integration looked like in PHP: request signing, seal/callback handling, and recurring/subscription flows. It informs the "which PSP do we standardize on" conversation by showing the integration surface area of the legacy SIPS path versus modern alternatives.
• Recurring billing / subscription build-vs-buy — Because it is explicitly a subscription plugin, it helps frame the scope question: how much custom work does recurring payment orchestration require if we self-integrate a PSP versus adopting a billing layer (Stripe Billing, Chargebee, Mollie subscriptions)? The bundle shows the minimum viable recurring flow but also the maintenance burden.
• Legacy migration planning — If the org has any Symfony 2-era application still talking to ATOS SIPS, this is evidence to scope a migration: what code exists, what it depends on, and what must be replaced before the PSP path can be modernized.
• Vendor risk / deprecation decisions — Zero stars, zero dependents, last release December 2015, archived. That is a concrete data point supporting "do not build new roadmap items on this dependency" and "budget for replacement" decisions.
• Roadmap sequencing for checkout/payments work — Reading the bundle tells you the real integration steps (seal generation, payment request construction, callback verification) so estimates for a payments epic are grounded rather than guessed.

When to Consider This Package

• Only as a reference artifact — You are reverse-engineering or auditing an existing ATOS SIPS integration in a legacy Symfony codebase and need to understand the intended request/response and callback contract.
• You are already live on ATOS SIPS and cannot migrate immediately — Forking and hardening it may be the cheapest short-term option for a legacy app, but this should be framed as technical debt with an explicit retirement date, not an adoption.
• You need to evaluate SIPS support in the French market — It documents that a community integration existed and what it covered, useful context in a vendor comparison.
• Look elsewhere when:
  • The stack is Laravel or modern Symfony — this is a Symfony bundle, not a Laravel package; there is no framework-appropriate glue here.
  • You are starting a new build — use the PSP's current official SDK (Worldline SIPS Paypage, Stripe, Adyen, Mollie) or a maintained billing platform.
  • You need PCI-scope reduction, SCA/3DS2, or PSD2-compliant flows — this 2015 code predates all of it.
  • You need security guarantees — an archived, zero-adoption package should not be trusted with cardholder-adjacent flows without a full security review and active fork ownership.
  • The business needs multi-currency, multi-PSP routing, dunning, or tax handling — out of scope for this codebase entirely.

How to Pitch It (Stakeholders)

Bottom line: this is not a dependency to adopt — it is a reference document and a migration signal.

For executives: lelivrescolaire/payment-sips-bundle is an archived 2015 Symfony bundle for ATOS SIPS subscription payments, with no stars, no dependents, and no releases in roughly a decade. Adopting it would introduce unmaintained payment code into our stack — a direct compliance and revenue risk. The value is diagnostic: it tells us what a legacy SIPS integration costs to own and gives us a defensible basis for recommending a modern PSP or billing platform. Ask: approve a small spike to confirm whether any live system still depends on SIPS, then fund migration rather than revival.

For engineering: treat it as documentation. Read it to understand seal/signature and callback handling, then implement against the PSP's current official SDK. Do not vendor it, do not fork it without a named owner, and do not let it into a new codebase. If a legacy service truly must keep SIPS running, isolate it behind an internal payments interface so it can be swapped without touching product code.

For product: the decision this unlocks is which billing model and provider we standardize on — not whether to use this package. The answer to the latter is no.