- Can I install lelivrescolaire/payment-sips-bundle in a Laravel application?
- It is not a Laravel package. It is a Symfony bundle with a DI extension, service definitions and a Symfony 2.x configuration tree, and there is no service provider, facade or publishable config. To use it in Laravel you would vendor the source and re-wire the container yourself, or run an Illuminate/Symfony bridge the package was never tested against. Treat Laravel integration as greenfield work over a reference implementation.
- Does this SIPS bundle work with Laravel 9, 10 or 11?
- No, not out of the box. The last release was December 2015 and targets PHP 5.4 to 7.0 with Symfony 2.3 to 2.8, so Composer constraints will almost certainly block installation on a modern Laravel runtime. Any Laravel 9+ usage means forking the package and porting the request signing and response parsing logic yourself. Do not expect upstream fixes.
- What PHP and Symfony versions does KptivePaymentSipsBundle support?
- The bundle is from the 2015 era: PHP 5.4 through 7.0 and Symfony 2.3 through 2.8. Its service definitions and configuration tree use Symfony 2.x idioms that will not load on Symfony 5.4 or 6.x. Plan on a fork if your stack is current.
- How do I configure the SIPS merchant ID, contract numbers and secret key?
- In Symfony the bundle exposes a configuration tree through its DI extension where you supply merchant identifiers, contract numbers, the secret key and endpoint URLs. In Laravel there is no equivalent, so you would create a config file and bind a SIPS client in a service provider. Keep the secret key out of source control and load it from environment variables.
- Is this package maintained or archived?
- It is effectively abandoned: zero stars, zero dependents, no releases since December 2015 and no upstream security response. Payment code touches shared secrets, signature validation and callbacks, so the lack of maintenance is a real risk. Any adoption should include an internal security review before the first live transaction.
- How does the bundle handle SIPS callbacks and response signature verification?
- The bundle's durable value is its SIPS request signing, response parsing and callback handling for the legacy ATOS Page de paiement and SIPS Office protocols. That logic is what you would extract into an internal, tested client library. Its controllers, templates and container wiring are disposable and can be replaced.
- Does this bundle support recurring or subscription payments through SIPS?
- Yes, it includes a recurring and subscription variant, but that only works if your live ATOS or Worldline SIPS merchant contract has the abonnement option enabled along with the required contract numbers. The subscription lifecycle logic lives in your application code, so correctness depends on callback delivery guarantees that SIPS does not strongly provide. Verify the full flow against a sandbox before committing.
- Do I need a live SIPS merchant contract to use this bundle?
- Yes. The package is only usable by teams that already hold a live SIPS merchant contract with Worldline, formerly ATOS Worldline, including the recurring option if you need subscriptions. That is a hard gate rather than a preference. If the requirement is a French card acquirer rather than SIPS specifically, a maintained PSP SDK is cheaper than resurrecting this bundle.
- What is the alternative to this bundle for French card payments in Laravel?
- If your acquirer relationship allows it, integrate directly against SIPS 2.0 or Worldline Online Payments, or use a maintained PSP SDK, rather than the legacy SIPS bundle. That removes the fork-and-certify burden and gives you supported security updates. Choose a modern option unless legacy SIPS is a contractual requirement.
- How do I migrate this Symfony bundle into a Laravel service provider?
- Start with a one-week spike against the SIPS sandbox to prove a successful payment and a successful recurring enrollment end-to-end, and stop if no sandbox is available. Then extract only the signing and verification logic into an internal, tested client library and reject the bundle's controllers, templates and container wiring. In Laravel, add a service provider binding that client, a config file for merchant ID, contract numbers, secret key and endpoints, and controllers for the return and callback routes.