- Can I use softspring/payment-bundle in a Laravel application?
- No, not as a drop-in dependency. It is a Symfony bundle that relies on Symfony DependencyInjection, EventDispatcher, and Doctrine ORM mappings, while Laravel uses a different container, event model, and Eloquent. In Laravel the realistic path is to re-implement the useful concepts behind your own PaymentGateway interface or choose a Laravel-native option.
- Which payment gateways does Softspring Payment Bundle support?
- The overview says it provides pluggable gateway drivers for multiple payment providers, but it does not name specific PSPs. You must audit composer.json and every gateway adapter to confirm whether Stripe, Redsys, PayPal, Adyen, Omnipay, or others are actually implemented. Provider logic may be abstracted or hard-coded, so verify that before assuming multi-gateway support.
- How do I install and configure softspring/payment-bundle?
- For Symfony, the context indicates a standard bundle install and configure path exists, with Symfony DI extension and configuration tree handling payments and methods. You should still read composer.json, the DI extension, and entity mappings before installing. For Laravel there is no supported install or configuration path because the bundle is not Laravel-native.
- Does softspring/payment-bundle support Laravel 10 or Laravel 11?
- No. It does not provide Laravel service providers, Eloquent models, or Laravel event integration for any Laravel version. Supporting Laravel 10 or 11 would require a port, not a version constraint change. Use a Laravel-native payment package or build an internal abstraction instead.
- Does Softspring Payment Bundle handle refunds, partial captures, and 3DS or SCA?
- The overview lists a unified workflow of initiate, confirm, and refund, but it does not confirm partial captures, 3DS, or SCA support. The technical assessment explicitly flags these as questions to resolve before adoption. Treat those capabilities as unverified until you inspect the gateway adapters and run sandbox tests.
- How does it handle webhooks, signature verification, and idempotency?
- The provided context does not state that webhook signature verification, idempotency keys, retries, or replay protection are implemented. For payment code, those controls are mandatory, so absence or ambiguity is a serious risk. Audit the webhook path and test replay and retry behavior before any production use.
- Is softspring/payment-bundle safe and maintained enough for production payments?
- The assessment rates technical risk as high: zero stars, zero dependents, no community validation, and no evident security review or bus factor beyond one. Payment code has the highest blast radius because it touches money movement, secrets, webhooks, idempotency, and PCI scope. Treat it as unvetted source code, not a production dependency, unless you fork it, pin the commit, add tests, and assign ownership.
- What Laravel alternatives should I consider instead of softspring/payment-bundle?
- For Laravel, consider Laravel Cashier, a first-party PSP SDK, or Omnipay if multi-gateway abstraction is the real requirement. If you like this bundle's domain model, copy the concepts behind an internal PaymentGateway interface so the implementation stays reversible. The honest recommendation for a Laravel target is not to integrate this bundle.
- How can I test softspring/payment-bundle in a Laravel app?
- You cannot integration-test it as a Laravel package because there are no Laravel bindings. A sensible test is a short Symfony sandbox spike against a PSP sandbox, exercising authorize, capture, refund, and a signed webhook. For Laravel, write tests around your own PaymentGateway adapter and provider HTTP client instead.
- Can I extend Softspring Payment Bundle with a custom gateway?
- Yes, the overview says it exposes extensible interfaces for custom gateways and entities. In a Symfony app that may be useful, but in Laravel you would need to re-express the gateway seam in your own container and persistence layer. Use the interfaces as a design reference and keep provider-specific HTTP calls isolated.