Payments Bundle Laravel Package

Technical Evaluation

Architecture fit — the premise doesn't hold, and that's the first finding. sylius/payments-bundle is not a Laravel package. It is a Symfony bundle built for Sylius, the Symfony-based e-commerce platform. It has no service provider, no config/*.php publish tag, 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 integration path into a Laravel application short of running a parallel Symfony kernel against a shared database — a decision that costs more than it could ever save. The TPM action here is to correct the framing in the intake record before it consumes another hour of engineering review, because a "Laravel payments package" and a "Symfony e-commerce bundle" route to entirely different evaluators.

The package is end-of-life by design, not by neglect. It is marked [READ-ONLY] For BC purposes. Payment functionality was consolidated into Sylius core (Sylius\Bundle\PaymentBundle) from Sylius 1.0 onward; this repo exists so older applications still resolve. With 0 stars, 0 dependents, and a score of 0, there is no user base to inherit fixes from and no maintainer to escalate to. Treat the read-only banner as the authoritative signal and stop evaluating it as a candidate component.

What a TPM can actually leverage here. Not the dependency — the artifacts. Three things transfer directly into our planning:

1. A validated domain model. Payment, PaymentMethod, per-channel gateway config, a payment state machine, and refund/partial-payment handling are the primitives any commerce payments layer must have. That model is now in Sylius core and is a legitimate reference when we scope our own design or evaluate a replacement.
2. A state-vocabulary contract. new → pending → completed / failed, plus refund transitions, is the shared language between checkout UX, customer support tooling, and finance reconciliation. Any migration must preserve these semantics and the historical rows behind them. Call this out in the plan as an API contract, not an implementation detail.
3. A migration scope inventory. Config keys, gateway definitions, entity/table names, template overrides of payment forms, service decorators. Enumerating these converts an open-ended "upgrade the payments stack" epic into an estimable backlog.

Technical risk — high and structurally unmitigable. Read-only means no patches, no upstream CVE response, no fork-and-PR courtesy path. The package 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 EOL exposure. Nothing about this is acceptable for new build, and for existing use it is a containment problem with a deadline.

Key questions to force a decision:

• Do we actually operate a Sylius instance pinned below 1.0 that still resolves this bundle? Owner: platform/eng lead. If no, close the evaluation as "do not adopt" and stop spending.
• Is our target stack genuinely Laravel? If yes, the comparators are laravel/cashier, stripe/stripe-php, or Omnipay — not a Sylius bundle. Owner: TPM.
• Who owns the payment domain today, and do we have anyone with Sylius/Payum operational depth? Owner: eng manager. A blank here is a staffing risk, not a footnote.
• What is our payment volume and contractual uptime obligation? This determines whether the exit is a routine release or a compliance-gated change window. Owner: TPM with finance/legal.
• Are we already mid-migration on a legacy instance? If yes, this is a workstream with a date, not an evaluation. Owner: program lead.

Integration Approach

Stack fit — valid only in one narrow lane. Sylius ≤1.0-beta, Symfony 2.8–3.4, PHP 5.6–7.2, Payum 1.x, Doctrine ORM 2.4/2.5. Modern Symfony 5/6/7 and PHP 8.x will fail dependency resolution outright. Incompatible with Laravel in every configuration. Classify it as a legacy-containment dependency and never a greenfield option.

Migration path. The exit target is Sylius core's built-in payment bundle (≥1.0). This is not a Composer swap — it is a config-and-schema migration with four workstreams:

• Payment method configuration: bundle-level gateway config maps to core's GatewayFactory registry and the sylius_payment configuration tree. Re-key, don't re-invent.
• Payum gateway definitions: legacy payum.gateways YAML must be re-expressed as Sylius gateway factories; custom Capture/Status actions need re-implementation against the core PaymentStateMachine. This is the largest unknown-effort item — size it after the inventory, not before.
• Schema: payment and payment-method entities move into core. Expect renamed tables, changed column types, and state-machine column additions, plus a data-backfill step to normalize historical payment states. Assume the schema diff is the schedule risk until a dry-run proves otherwise.
• Custom code: any class extending this bundle's services must be rewritten against core interfaces. No shim exists.

Compatibility gates before committing a window: PHP runtime upgrade path, Symfony major-version jump tolerance, gateway SDK versions against current PSP API versions, and whether the Doctrine schema diff is additive or destructive. A destructive diff on the payments table is the single biggest scheduling risk in the program.

Sequencing — six steps with owners and exit criteria:

1. Inventory (1 sprint). Enumerate every service, config key, DB column, template override, and decorator sourced from this bundle. Exit: an itemized list Engineering signs off as complete. This is the estimate-setting artifact; do not plan past it.
2. Freeze (immediate, no sprint). No new features, no new gateways against the legacy bundle. Exit: written code-owner sign-off. Every feature built on a frozen bundle is paid for twice.
3. Contain (1 sprint). Pin the legacy app to a containerized, reproducible runtime; snapshot composer.lock; vendor artifacts. Add integration tests around existing payment flows as a regression harness before touching anything.
4. Parity harness. End-to-end authorize / capture / refund / webhook tests per gateway. These are the migration acceptance criteria — not unit coverage. Exit: every live gateway has a green parity suite.
5. Migrate in a branch. Schema diff dry-run against a production-shaped database copy; resolve destructive changes and rehearse rollback first. Exit: rehearsed rollback, not just a passing migration.
6. Cutover, staged by gateway. Lowest-volume gateway first. Dual-run reconciliation for at least one full settlement cycle with a named finance owner. Exit: reconciliation clean across one settlement cycle.

Operational Impact

Maintenance — permanently self-maintained. Read-only repo, 0 stars, 0 dependents, no release cadence, no security advisory channel. For as long as it stays in the tree, every fix is internal cost. Budget it that way in the capacity plan rather than assuming a vendor or community absorbs it.

Support. No vendor, no support contract, no meaningful question corpus. Internal runbooks become the only knowledge base. The state machine and gateway flows must be written down as part of the migration — tribal knowledge is the largest hidden cost and the one most likely to blow the estimate.

Scaling. The bundle is not the throughput bottleneck; payment latency is PSP-bound. Real constraints come from the coupled legacy runtime — an EOL PHP version without modern opcache/JIT gains and a Symfony 2/3 container that can't take current runtime tuning. Horizontal app-tier replication gets you capacity, but payment-path p95 will be dominated by gateway round-trips, which caps the return on optimization work here. Don't fund it.

Failure modes to staff against:

• Silent gateway drift — PSP API version changes with no patch path; failures appear as production payment errors. Mitigate with synthetic transaction monitoring per gateway, not health checks.
• Composer resolution failure — any dependency bump can make the tree unbuildable. Mitigate with vendored artifacts and a locked image.
• Unpatched CVE on the payment path — not remediable upstream; contained only via network segmentation and WAF rules.
• Destructive schema migration — highest-severity migration risk; requires a rehearsed rollback and a production-shaped dry run.
• Reconciliation breakage — dual-write/dual-run periods can double-count. Needs explicit finance-side ownership and a named reconciler.

Ramp-up. A competent Symfony engineer needs roughly 2–4 weeks to be productive on Sylius/Payum payment internals — the state machine, gateway factory registration, and Payum action pipeline are non-obvious. That skill set is scarce and thinning as the ecosystem moves on. Plan a single named owner plus a documented secondary; a bus factor of one on the payment system is not an acceptable operating posture.

Bottom line for the decision log: do not adopt. If a legacy Sylius instance already depends on this bundle, log it as a compliance-flagged containment item with a funded migration to Sylius core, with a named owner and a target quarter. "Known and unowned" is exactly how a bounded migration turns into a checkout incident.