- Is sylius/payment-bundle compatible with Laravel?
- No. It is a Symfony bundle, not a framework-agnostic library: its classes extend Symfony's Bundle base class and depend on dependency-injection extensions, YAML/XML service definitions, Doctrine ORM mappings, and symfony/workflow. Laravel has no bundle or DI-extension concept, so the package's actual surface area cannot be booted in a Laravel application. Only the thin sylius/payment domain model underneath is reusable, and it is small enough to rewrite from scratch.
- Can I install sylius/payment-bundle with Composer in a Laravel 10 or 11 project?
- Composer will refuse to resolve it. This is a Symfony2-era split repo with constraints in the neighborhood of php ~5.5|7.0, symfony/symfony ~2.7|~3.0, and Doctrine ORM 2.4.x, none of which are satisfiable on PHP 8.2/8.3 with Laravel 10/11. Forcing the install with --ignore-platform-reqs yields classes that autoload but cannot be wired, because the state machine, repository mappings, and gateway configuration all rely on Symfony's container.
- What does sylius/payment-bundle actually contain?
- It is the Symfony integration layer for the Sylius Payments component: a bundle class, a DependencyInjection extension, service definitions, route and fixture loaders, form types, and Twig templates. The reusable part underneath is a thin domain model made of Payment, PaymentMethod, PaymentGateway, and PaymentTransitions — interfaces, enums, and a static state-machine graph. The commercial value is the design of that state model, not the Symfony plumbing around it.
- Which PHP and Symfony versions does sylius/payment-bundle require?
- It targets the Symfony2/Symfony3 era, with constraints around php ~5.5|7.0, symfony/symfony ~2.7|~3.0, and Doctrine ORM 2.4.x. That places it well outside what Laravel 10 or 11 supports on PHP 8.2+, so the conflict is structural rather than a version bump away. Treat those constraints as hard: there is no supported upgrade path for this split repository.
- What is the best Laravel alternative to a Symfony payment bundle for gateway abstraction?
- For most Laravel teams the answer is a gateway SDK or Laravel Cashier rather than any abstraction layer, especially if only one or two gateways such as Stripe, Adyen, or PayPal are in scope. If you genuinely need multi-gateway abstraction, league/omnipay is framework-agnostic, actively maintained, and Laravel-friendly. Pair either option with a native state machine built from backed enums and guarded transitions, or use spatie/laravel-model-states.
- Is sylius/payment-bundle safe to use in production?
- It is marked READ-ONLY and appears to be an archived split that was folded back into the Sylius monorepo around the 1.x consolidation, with roughly 22 stars and zero dependents. There is no upstream security response, no CVE triage, and no maintainer to escalate to. Placing archived code in a payment authorization, capture, or refund path creates an audit finding regardless of whether card data ever touches it. The domain logic also predates idempotency keys, webhook signature verification, and Payment Request abstractions that modern gateways assume.
- Can I use the sylius/payment component without the Symfony bundle?
- Technically the component is framework-agnostic, but it is only a thin domain model of a few hundred lines: interfaces, enums, and a static state-machine graph definition. You would still have to supply persistence, gateway calls, idempotency, webhook handling, and refund bookkeeping yourself. In a Laravel app it is almost always cheaper to reimplement that model with Eloquent models and enums than to pull a second framework's machinery in for one feature.
- Does sylius/payment-bundle support Stripe, PayPal, or Adyen?
- The bundle is gateway agnostic by design — it provides the payment foundation, not concrete gateway integrations. Gateway support historically lived in separate Sylius payment plugins, which carry the same Symfony2-era constraints and the same archived-split status. For Laravel, use the gateway's official SDK or Laravel Cashier instead.
- How do I replicate the Sylius payment state machine in Laravel?
- Harvest the model as a design reference: new to processing, then authorized, captured, and refunded, with explicit failure transitions branching off at each step. Implement it natively with backed enums and guarded transitions, or with spatie/laravel-model-states, and persist every transition in an audit table alongside the payment record. The roughly fifteen transitions this bundle defines can be reproduced in about a day using Eloquent models your team already knows how to operate.
- Where did sylius/payment-bundle go, and is it still maintained?
- The repository is a read-only split that was folded back into the main Sylius monorepo during the 1.x consolidation. Bug reports and contributions are redirected to the Sylius/Sylius GitHub issues rather than this repo. For a Laravel codebase it is a naming-collision risk rather than an adoption candidate, so choose an actively maintained alternative.