Payments Bundle Laravel Package

Product Decisions This Supports

• Payment domain modeling — copy the spec, not the code. The bundle is a working reference implementation of payment primitives: Payment, PaymentMethod, gateway configuration, a payment state machine (new → pending → completed / failed), multiple payments per order, refunds, and partial payments. A PM can lift that vocabulary directly into a PRD or data-modeling doc without writing a line of PHP. That is the highest-value use of this package.
• Build vs. buy for the payments core. The bundle demonstrates the full scope of what "we'll just build our own payment layer" actually means: entities, repositories, forms, a configurable state machine with callbacks, per-channel payment method availability, and gateway abstraction. That scope is the argument against building it in-house — the conclusion is to inherit a platform payment component or a maintained gateway SDK, not to reimplement this.
• Checkout and gateway roadmap sequencing. The gateway-agnostic abstraction is a decision checklist for launch scope: onsite capture vs. offsite redirect, authorize-vs-capture timing, multiple payments per order, partial and full refunds, failure and retry paths. Each of those is a product decision with finance and support implications, and the bundle names them explicitly.
• Stack-fit and tech-debt triage — the decisive product finding. Despite being filed as a Laravel/PHP package, this is a Symfony bundle built for Sylius, with no Laravel service provider, no Eloquent models, and no Laravel-shaped config. If it appears in a composer.lock, that is a status signal: the application is pinned to a pre-consolidation Sylius payments layer. The decision it supports is "when and how do we upgrade," not "should we adopt."
• Migration scoping artifact. It yields a concrete inventory for an upgrade epic: gateway config records, payment method fixtures, template overrides of payment forms, service decorators, and the payment state machine vocabulary. That converts an open-ended "upgrade the platform" item into an estimable backlog.
• Risk-register input, not roadmap input. Zero stars, zero dependents, and a [READ-ONLY] For BC purposes banner mean no maintainer, no release cadence, and no CVE path. That belongs in a supportability/security review line item, sized and owned — not in a feature backlog.

When to Consider This Package

Legitimate, narrow uses:

• You maintain a legacy Sylius application (≤1.0-beta) where Composer still resolves it and an upgrade is genuinely blocked this quarter. Pin it, contain it, and record it as technical debt with a named owner and target date. Do not extend it.
• You are writing payment requirements, a migration plan, or a custom gateway and want the canonical Sylius payment modeling as a reading reference. Read the source; do not take the dependency.
• You need to explain to stakeholders why the payment layer is a risk — the archive status makes the case for you.

Look elsewhere — usually the platform's own payment component or a maintained gateway SDK — when:

• Your target stack is Laravel. The correct comparators are laravel/cashier, stripe/stripe-php, or Omnipay. A Symfony bundle cannot be dropped into a Laravel app without running a parallel Symfony kernel and sharing a database, which is a net-negative architecture decision. Close the evaluation.
• You are starting a new build. There is no scenario where a greenfield project should resolve this.
• You need maintained gateway coverage (Stripe, Adyen, PayPal), SCA/3DS2, webhooks, idempotency keys, or multi-store/multi-currency payment method configuration. None of that is coming from an archived repo.
• You operate under compliance or procurement requirements expecting a maintained dependency — SBOM provenance, CVE response windows, an LTS commitment, a vendor support channel.
• You are planning any change to checkout, refunds, dunning, or subscription billing. New payment work on a frozen bundle multiplies the eventual migration cost.

Rule of thumb: if it is already in the tree, treat it as a migration trigger. If it is not, do not add it.

How to Pitch It (Stakeholders)

One line for executives: This is not a product opportunity — it is a status indicator and a modeling reference. If it is in our stack, our payments layer is end-of-life and the decision in front of us is an upgrade, not an adoption.

The framing:

• Payments is revenue-critical infrastructure. An unmaintained dependency sitting directly under checkout is a business-continuity exposure: no security patches, no gateway updates, no support path.
• The good news is this is consolidation, not net-new investment. The capability we need already ships in the platform. The cost is migration effort, and it is bounded and estimable — the bundle itself tells us the scope.
• For a Laravel target, the answer is simpler still: the correct choice is a maintained Laravel-native payments path, and this package is not a candidate at all.

For engineering:

• Adopt the payment model, not the dependency. Preserve the payment state vocabulary exactly as an API contract — checkout UX, customer support, and finance reconciliation all key off those state names — and backfill or map historical payment rows.
• Re-validate each live gateway end to end, including refunds, partial refunds, and failure handling. Those are the acceptance criteria, not unit coverage.
• Freeze new feature work on the legacy path now. Every gateway feature built on a frozen bundle is paid for twice.

Recommendation with a decision date:

1. Spike (time-boxed): confirm exactly what resolves this package, what overrides it, and whether the framework mismatch is real. This produces the size estimate.
2. Inventory and freeze: enumerate services, config keys, and DB columns sourced from the bundle; formal code-owner sign-off on no new payment features against it.
3. Fund the upgrade on the roadmap, sequenced ahead of the next payments-related feature request — bundling them makes the upgrade fundable and the feature safe.
4. Name an owner and a target quarter. "Known and unowned" is how a bounded migration becomes an incident.

Anti-pitch, to close the loop: do not let "it's already integrated and it's free" win the room. Zero stars, zero dependents, and a read-only banner describe precisely the dependency you least want under your checkout. The maintenance risk is real; the convenience is temporary.