Weave Code
Payments Bundle Laravel Package
sylius/payments-bundle
The Sylius Payments Bundle provides the payment foundation for Sylius e-commerce stores, including payment method management, gateway integrations, and transaction handling for checkout and order workflows. It offers extensible services and interfaces for building custom payment providers.
[READ-ONLY] For BC purposes.
Frequently asked questions about Payments Bundle
- Is sylius/payments-bundle a Laravel package?
- No. It is a Symfony bundle built for Sylius, the Symfony-based e-commerce platform, and it has no Laravel service provider, no config publish tag, and no Eloquent models. It depends on Symfony DI container compilation, Doctrine ORM mapping, the Sylius Resource/Registry system, and Payum for gateway abstraction. There is no supported path into a Laravel application short of running a parallel Symfony kernel against a shared database.
- Can I install sylius/payments-bundle in a Laravel application?
- Not realistically. The package requires Symfony 2.8 to 3.4, PHP 5.6 to 7.2, Payum 1.x, and Doctrine ORM 2.4/2.5, so dependency resolution will fail on a modern Laravel stack. The only theoretical integration is a parallel Symfony kernel sharing a database, which costs more than using a native Laravel payments package. Treat it as incompatible and do not attempt adoption.
- What Laravel versions does sylius/payments-bundle support?
- None. It is not a Laravel package and never targeted Laravel versions; it targets legacy Sylius releases up to 1.0-beta on Symfony 2.8 to 3.4 with PHP 5.6 to 7.2. For Laravel applications, the correct comparators are laravel/cashier, stripe/stripe-php, or Omnipay. Do not include this bundle in Laravel dependency planning.
- What is sylius/payments-bundle used for?
- It provided the payment foundation for older Sylius stores: payment method management, per-channel gateway integrations through Payum, a payment state machine, and transaction handling for checkout and order workflows including refunds and partial payments. It is marked READ-ONLY for backward compatibility only. Payment functionality was consolidated into Sylius core as Sylius\Bundle\PaymentBundle from Sylius 1.0 onward.
- Is sylius/payments-bundle maintained or deprecated?
- It is end-of-life by design, not by neglect. The repository is marked READ-ONLY for BC purposes and exists so older applications still resolve dependencies; with 0 stars, 0 dependents, and a score of 0, there is no user base to inherit fixes from. There are no patches, no upstream CVE response, and no maintainer to escalate to. Treat the read-only banner as authoritative and do not evaluate it as a candidate component.
- How do I install sylius/payments-bundle?
- You would only install it with Composer on a legacy Sylius application pinned below 1.0 that still resolves the bundle, running Symfony 2.8 to 3.4, PHP 5.6 to 7.2, Payum 1.x, and Doctrine ORM 2.4/2.5. There is no Laravel installation path and no service provider or config publish workflow. For new projects, do not install it; use Sylius core PaymentBundle for Sylius or a native Laravel payments package for Laravel.
- How do I configure payment gateways with sylius/payments-bundle?
- Gateways are configured through Sylius payment method entities and the Sylius Resource system, with Payum providing gateway abstraction, rather than through Laravel config files. Configuration is tied to Doctrine mappings and per-channel payment method records in the database. There is no config/*.php publish tag and no Laravel-style configuration layer, so any migration must inventory config keys and gateway definitions explicitly.
- How do I test sylius/payments-bundle or plan a migration off it?
- Tests require a Symfony kernel and Doctrine, using Payum gateway mocks and Sylius state machine tests for transitions such as new to pending to completed or failed plus refund transitions. For migration planning, inventory config keys, gateway definitions, entity and table names, payment form template overrides, and service decorators. Preserve the payment state vocabulary as an API contract, not an implementation detail, because checkout UX, support tooling, and finance reconciliation all depend on those semantics.
- What are alternatives to sylius/payments-bundle for Laravel?
- For a Laravel target stack, evaluate laravel/cashier, stripe/stripe-php, or Omnipay rather than a Sylius bundle. For an existing Sylius application, the replacement is Sylius core PaymentBundle, which absorbed this functionality from Sylius 1.0 onward. Choose based on whether your stack is genuinely Laravel or Sylius/Symfony, because the evaluators and integration paths are entirely different.
- What production risks come with sylius/payments-bundle?
- The package is read-only, so there are no patches, no upstream CVE response, and no fork-and-PR courtesy path. It sits directly on the payment path, the highest-blast-radius surface in a commerce system, which pulls any unpatched defect into PCI-DSS and financial-reconciliation scope. The transitive Payum 1.x chain carries its own end-of-life exposure. For existing use this is a containment problem with a deadline, not an acceptable choice for new builds.
Weaver
How can I help you explore Laravel packages today?