- Is kptive/payment-sips-bundle compatible with Laravel?
- No. It is a Symfony 2-era bundle that integrates the Atos SIPS gateway through JMSPaymentCoreBundle, Symfony bundle registration, DI container configuration, and tagged service discovery. Laravel does not provide those seams, so a composer require into a Laravel app is not a viable starting point. You would need to extract the SIPS protocol logic and re-host it behind a Laravel service provider.
- How do I install and configure kptive/payment-sips-bundle?
- In a Symfony application you install it with Composer, register the bundle in the kernel, and configure merchant credentials and gateway settings through the bundle extension. That installation path assumes Symfony's bundle manifest and DI container. There is no supported Laravel installation or config publishing flow, so Laravel teams should treat the repository as reference code rather than a dependency.
- Does the bundle support Symfony 4, 5, 6, or PHP 8?
- The package targets the Symfony 2 era and shows no evidence of active PHP 8.x compatibility work. Expect deprecated functions, type strictness issues, and missing modern practices such as hash_equals in security-sensitive comparisons. Verify the actual composer constraints and run it against your runtime before planning any adoption.
- Which SIPS generation and connector does this bundle use?
- It targets the legacy Atos Worldline SIPS 1 gateway and its CGI-binary connector, not SIPS 2 or Worldline's modern acquiring APIs. Whether your bank still provisions SIPS 1, and whether it uses pathfile, HTTP, or CGI binaries, must be confirmed with your acquirer first. If your contract provides a current REST API or official SDK, this repository is likely irrelevant.
- Does kptive/payment-sips-bundle require Atos SIPS CGI binaries on the server?
- Yes, the integration shells out to Atos SIPS CGI executables for request and response processing. That introduces host provisioning, file permission, and portability concerns that a pure-PHP SIPS client avoids. Confirm that your hosting platform permits executing third-party binaries in the payment path before committing engineering time.
- How do I handle SIPS callbacks and the merchant return URL in Laravel?
- The bundle provides helpers for parsing the asynchronous callback DATA blob and mapping SIPS response codes, but you would reimplement the Laravel routing yourself. Create a controller for the merchant return URL and a separate endpoint for the server-to-server callback. Always verify signatures and treat unverified callbacks as untrusted, because the original code predates current SCA and 3DS2 expectations.
- Does the package support refunds, 3-D Secure, or multi-currency?
- The bundle exposes configuration for multiple payment methods and currencies, but its core scope is sending payment requests and reading responses. Refunds, capture flows, and 3-D Secure challenges must be checked against the underlying kptive/payment-sips client rather than assumed. The code predates PSD2 and 3DS2, so it will not satisfy a current auditor as-is.
- Can I reuse the SIPS request and response logic in a Laravel package?
- Yes. The genuinely portable part is narrow: building the payment request with merchant ID, minor-unit amount, currency, language, and order reference, signing and encoding parameters, constructing the redirect form, and parsing the callback and return payloads. That is a few hundred lines of plain PHP that can be re-hosted behind a Laravel service provider and a SipsGateway class. Reusing the repository directly as a dependency is not realistic.
- What are the alternatives to this bundle for Atos SIPS in Laravel?
- Ask your bank whether it offers an official SDK or a current REST API, which is the cleanest path. If you must use SIPS 1, build a thin first-party Laravel package with a service provider, published config for merchant credentials and endpoints, and a gateway class exposing authorize, handleReturn, and handleCallback. Treat this repository as protocol documentation for the SIPS wire format rather than an installable library.
- Is kptive/payment-sips-bundle maintained and safe for production?
- The project has negligible community signal, including one star and no dependents, and it depends on the legacy JMSPaymentCoreBundle. Assume no upstream security fixes or compatibility work and plan to fork and own any code you adopt. Because signature verification and callback trust are not inherited safely, reimplement those checks deliberately before going live.