- Is phcorp/payment-sips-bundle a Laravel package?
- No. Despite how it is sometimes described, phcorp/payment-sips-bundle is a Symfony bundle, not a Laravel package. It ships DependencyInjection/, an Extension.php, and Resources/config/ service wiring that only resolves inside a Symfony kernel. Treat it as a reference implementation of the SIPS protocol rather than an installable Laravel dependency.
- Can I install phcorp/payment-sips-bundle in a Laravel application with Composer?
- Composer may resolve it, but the bundle will not boot in Laravel because Laravel never loads Symfony bundle extensions or compiler passes. Bridging Symfony's container into Laravel's is strongly discouraged, especially on a payment path where two service registries in one request become a debugging surface. The practical route is extraction, not installation.
- How do I integrate the SIPS payment gateway into Laravel correctly?
- Lift the signer, verifier, and field mapper into two or three plain-PHP classes under your own namespace, then wrap them in a thin Laravel adapter. That adapter typically includes a service provider binding, a SipsGateway class, a customer return controller, a server-to-server callback controller, and a published config file. Put the logic behind an internal PaymentGateway interface so SIPS stays swappable and mockable.
- What SIPS payment flow does this bundle actually implement?
- It implements the SIPS hosted-paypage flow: build a request payload, sign a canonical field string with a shared secret, POST or redirect the customer to the PSP, then verify the signed payload on the callback. Its real value is encoded protocol knowledge such as field ordering, signature construction, response-code taxonomy, and callback validation. That is an accelerator worth days of engineering, not a foundation.
- Does phcorp/payment-sips-bundle support 3DSv2, SCA, or PSD2 requirements?
- Assume no until proven otherwise. A Symfony bundle of this lineage likely predates Worldline's REST and SCA direction and implements the legacy certificate or sealed-field Paypage flow without 3DSv2/SCA, which PSD2 makes mandatory for EU card traffic. Confirm the exact behavior with your acquirer before committing, because this is a hard blocker for production EU card payments.
- How should I validate a SIPS callback signature in Laravel?
- Extract the verifier and test it against fixtures rather than trusting the bundle blindly. Concentrate on the two places where risk actually lives: callback verification and amount/currency encoding. Build three fixtures — one valid success payload, one tampered signature, and one amount or currency edge case — and assert field ordering, encoding, and signature algorithm empirically.
- Which SIPS product does this bundle cover: Paypage, Sips Office, or the REST offer?
- It most likely covers Paypage, the hosted payment form, because that is what legacy bundles of this vintage target. Sips Office operations such as capture, refund, and cancel, plus Worldline's newer REST offer, are probably out of scope. Confirm which product your contract uses before estimating, since the answer changes the integration plan substantially.
- Is phcorp/payment-sips-bundle maintained and safe to use in production?
- Treat it as unmaintained. It was forked from an abandoned upstream and shows zero stars, zero dependents, a single maintainer, and no visible CI or security advisory channel, which matters in any PCI or vendor-risk review. If you vendor any part of it, record the upstream commit SHA plus your delta and name an internal owner with a patch policy.
- What are the alternatives to this bundle for SIPS/Atos Worldline in Laravel?
- There is no first-party Laravel package for SIPS, so the realistic options are to extract this bundle's signer and verifier, adopt Worldline's newer REST/SCA SDK if your acquirer supports it, or write a thin gateway wrapper behind an internal PaymentGateway interface. Avoid bridging the Symfony container into Laravel. Keep the acquirer decision decoupled from checkout, orders, and reconciliation code.
- How do I test SIPS payment request generation and callbacks before going live?
- Run a protocol spike before writing application code: stand up a sandbox merchant ID and replay a signed request and a callback using curl or PHPUnit. This confirms field ordering, encoding, and signature algorithm for a few days of effort and de-risks the whole plan. Then keep the extracted classes behind an interface so tests can mock the gateway without touching real SIPS endpoints.