- Can I use jrk/paymentsips-bundle in a Laravel application?
- No. It is a Symfony2 bundle that relies on AppKernel registration, XML/YAML dependency injection service definitions, a DependencyInjection Extension and Configuration class, and PSR-0 autoloading. Laravel has no bundle concept, so Composer may install it but you get no service provider, facade, publishable config, or container bindings. Fit as a direct dependency is effectively zero; its value is as a protocol reference.
- Does this package support Laravel 10 or Laravel 11?
- There is no Laravel support at any version. The bundle targets Symfony 2.x and typically pins PHP ~5.3 to 5.6, all of which are end-of-life. Composer install will often fail on a modern runtime, and even a clean install delivers nothing usable without porting the code yourself.
- How do I add PaymentsIPS payments to Laravel if this bundle won't work?
- Fork the repository and extract the protocol layer: seal computation, request field assembly, and response seal verification, moved into a PSR-4 namespace with zero Symfony imports. Keep the vendored ATOS toolkit binaries untouched because they are the bank's signed artifacts. Then wrap the extracted layer in a thin Laravel service bound through a service provider, with credentials in config/services.php sourced from env or a secrets manager. Expect roughly one to three engineer-days for the extraction, plus tests and the wrapper on top.
- Which configuration values from the bundle should I port to a Laravel config file?
- Read DependencyInjection/Configuration.php and the extension class first, because that parameter surface is the real API contract. It typically covers merchant ID, country, currency, pathfile, and key or certificate paths, which map cleanly to a config/payments.php array. Also read Resources/config/routing.yml to see the expected callback route shape before you define your Laravel route and queued callback job.
- What is the SIPS seal and why is it the riskiest part to port?
- The seal is a signature computed over a specific ordered set of request fields, and the response carries its own seal that must be verified. It is PSP-specific, easy to get subtly wrong, and the bundle's implementation may use legacy SHA-1 rather than SHA-256. Confirm which algorithm and field ordering your merchant contract requires. Seal bugs surface as silent declines or, worse, as accepted invalid responses.
- Does this bundle support 3D Secure 2 and PSD2 SCA?
- Almost certainly not. Given its Symfony2-era vintage, it most likely implements 3DS1 or a plain redirect flow, which is not compliant for EU card traffic since SCA requirements took effect in 2021. Before reusing any of it, confirm which protocol it targets, classic SIPS/1 or SIPS/2 and Worldline Online Payments, and plan to add 3DS2 handling yourself.
- Is jrk/paymentsips-bundle safe to run in production?
- No. Symfony 2.x has been end-of-life since November 2018, so there are no security patches and every transitive dependency is a liability on a payment path. The project has around 2 stars, no dependents, and no visible CI or test suite, which means no community validation and no vulnerability disclosure path. Code on a payment path without tests is unverifiable, and the license and authorship also need confirming before any reuse.
- Which files in the repository are actually worth reusing?
- The durable assets are the ATOS SIPS protocol work: request field assembly, seal computation, response-side seal verification, and the return or callback URL flow. DependencyInjection/Configuration.php gives you the parameter schema, and Resources/config/routing.yml shows the callback route shape. Keep the vendored bin and lib ATOS toolkit artifacts exactly as shipped, since those are the bank's signed binaries.
- How should I test a ported PaymentsIPS integration before going live?
- Write contract tests against the SIPS test environment using known-good request and response vectors, covering both seal generation and response verification. Add unit tests for field ordering and for whichever hash variant your contract specifies. Also test duplicate detection and callback replay behaviour, because a valid but replayed response must not create a second payment. Do all of this before any production credentials are involved.
- What are the alternatives if I need PaymentsIPS or ATOS SIPS in Laravel?
- There is no Laravel-native PaymentsIPS package, so the realistic options are forking and extracting this bundle, or writing a small client directly against the gateway documentation. First establish which protocol and endpoint set you are contracted for, since SIPS/1 and SIPS/2 differ significantly. Then decide scope beyond payments, such as refunds, cancellations, and tokenization, because the bundle's coverage of those operations is unconfirmed.