- Can I install paymentsuite/free-payment-bundle in a Laravel application?
- No, not usefully. It is a Symfony bundle with no Laravel ServiceProvider, no publishable config, and nothing for Laravel package discovery to register. Composer may pull it in alongside paymentsuite/payment-core, but the runtime depends on Symfony DI, service tags, and compiler passes, so it will not work as a Laravel payment method. The equivalent behavior is roughly 150 to 300 lines of native Laravel code.
- What is paymentsuite/free-payment-bundle used for?
- It adds a zero-cost free payment method to applications built on the PaymentSuite stack, typically Symfony e-commerce apps. It lets customers complete free orders, trials, or test checkouts without contacting a real payment gateway or handling card data. It requires no API keys, credentials, or external HTTP calls.
- Is it compatible with Laravel Cashier or Laravel payment packages?
- No. It implements PaymentSuite contracts such as PaymentMethodInterface and PaymentBridgeInterface and relies on Symfony service tagging for payment router discovery. Laravel Cashier and similar packages use a different container and gateway model. For Laravel, treat this bundle as a design reference rather than a dependency.
- How do you install and configure it in Symfony?
- Install it with Composer alongside paymentsuite/payment-core, register the bundle in bundles.php, import its routing, and enable the method under config/packages/paymentsuite.yaml. You configure success, failure, and confirmation routes in YAML, and the views are Twig-ready. This is straightforward only if your PHP and Symfony versions match the bundle constraints.
- Which Laravel versions does this package support?
- None directly, because it is a Symfony bundle rather than a Laravel package. Its constraints target the older PHP 5 or 7 and Symfony 2, 3, or 4 era, and its last release was in January 2021. On a modern Laravel stack with PHP 8.2 or newer, expect version conflicts that may require ignore-platform-reqs or a fork.
- Does it verify that the order total is actually zero before marking the order paid?
- You must verify this in the source and not assume it. A free payment method that returns success without asserting the payable amount is zero is a revenue-bypass risk if it is exposed as a selectable checkout option in production. The method should fail closed when the order total is not zero, and any Laravel implementation you write should enforce that check explicitly.
- Is paymentsuite/free-payment-bundle maintained and safe for production?
- Maturity is the main risk. The repository has very low adoption, zero dependents, and a last release in January 2021, and the wider PaymentSuite ecosystem is largely dormant. For a legacy Symfony app already running PaymentSuite it may be acceptable after review, but for a production Laravel codebase it is not a dependency you should add.
- What order state transitions and events does the free payment method trigger?
- It plugs into the standard PaymentSuite order workflow and marks the order as paid through the PaymentMethodWrapper and bridge contracts. The exact events fired and whether those transitions are idempotent on retry need to be checked in the upstream source. If you reimplement the pattern in Laravel, make the state transition idempotent and emit your own payment events.
- Is there test coverage for the free payment method?
- Test coverage is not confirmed by the package overview and should be checked upstream before relying on it. Given the project's age and low activity, expect limited tests rather than a comprehensive suite. If you borrow the state-transition pattern for Laravel, write your own feature tests for zero-total success, non-zero rejection, retries, and route configuration.
- What should Laravel developers use instead for free or zero-total checkouts?
- Implement a small native payment method in your Laravel application rather than bridging the Symfony bundle. A custom gateway that asserts the total is zero, marks the order paid, fires your payment events, and exposes only server-side or admin invocation covers the same use case. Use Laravel Cashier or another maintained gateway only when you need a real payment provider.