Payment Bundle Laravel Package

Product Decisions This Supports

• Payments architecture (build vs. buy the abstraction, not the code): This package is a useful reference model for decoupling checkout from any single PSP. The product decision it informs is whether we own a gateway-agnostic payment abstraction layer (one internal PaymentGatewayInterface, N adapters) or let Stripe/Adyen SDK objects leak into order and checkout code. Its existence is evidence that the abstraction-first pattern is tractable in PHP.
• Order and payment lifecycle design: The bundle's core value is an explicit payment state machine (roughly new → processing → completed / failed / cancelled / refunded). That directly drives product decisions we can't defer: what a customer sees during 3DS/pending states, when an order becomes fulfillable, how partial refunds and voids are represented, and what "cancelled" vs. "failed" means to support agents.
• Multi-PSP and failover roadmap: Because the gateway is a pluggable strategy, it makes "add a second acquirer for EU/APAC" or "route card traffic by BIN/region" a configuration decision rather than a re-architecture. Useful for a roadmap conversation about regional expansion, PSP cost negotiation, and outage failover.
• Webhook/reconciliation design: Async notifications map onto payment transitions, which frames decisions on idempotency keys, replay handling, and how we reconcile PSP settlement reports against our ledger — a common source of finance-visible bugs.
• Use cases it plausibly covers: classic hosted/redirect checkout, authorize-then-capture, refunds and partial refunds, multi-currency orders, and retry/dunning flows. It does not evidence support for subscriptions, marketplace split payouts, or SCA/3DS2-native flows in its current form — treat those as net-new work.
• A "don't build" decision: With 22 stars, 0 dependents, and a READ-ONLY repository, this is a strong signal to not adopt the artifact. That frees the team to spend the same effort on Omnipay-style adapters or a first-party PSP SDK, and is itself a decision worth recording.

When to Consider This Package

Adopt (or rather, consume it transitively) only when:

• The platform is Symfony, not Laravel. This is a Symfony bundle built on the Sylius component set; the description's "Symfony2" wording dates it by roughly a decade. There is no drop-in path into a Laravel service container, and retrofitting Symfony DI/EventDispatcher into Laravel to host one bundle is a poor trade.
• The team is already on Sylius (or committed to it) — in which case this code arrives via Sylius core, and you should pin the Sylius version rather than depend on this archived split repo directly.
• You need a gateway-agnostic abstraction with an explicit payment state machine and your PSP mix is genuinely plural. If you only ever intend to use one processor, the abstraction is overhead.
• You have in-house Symfony depth to own the adapters, since upstream fixes will not arrive.

Look elsewhere when:

• The stack is Laravel or framework-agnostic PHP — the majority case here. Use the thephpleague/omnipay family for the same abstraction idea, laravel/cashier for subscriptions/billing, or the PSP's own official SDK (Stripe, Adyen, Mollie) for modern payment intents.
• You need current PSP capabilities: PaymentIntents, SCA/3DS2, wallets (Apple/Google Pay), idempotent webhooks, strong customer authentication flows. This bundle predates all of it.
• You need subscriptions, invoicing, dunning, or split payouts out of the box — none of that is evidenced here.
• Maintenance risk is disqualifying: READ-ONLY status, 22 stars, 0 dependents, and a "maturity: readme" signal mean no upstream security patches. A fork is a permanent internal liability, not a shortcut.
• You want a supported vendor path — this is MIT-licensed community code with no commercial backing as a standalone artifact; Sylius's own support applies to the suite, not this repo.

How to Pitch It (Stakeholders)

To executives: We evaluated sylius/payment-bundle as a way to avoid hand-rolling payment plumbing. Recommendation: do not adopt it. It is an archived, read-only Symfony 2-era component with negligible standalone adoption (22 stars, zero dependents) and no maintenance path — that's a security and business-continuity risk in a revenue-critical path. We are, however, borrowing its strongest idea for free: a single internal payment abstraction with a documented payment state machine, so adding a second processor or a new region is a config change, not a rebuild. Net effect: same architectural benefit, no orphaned dependency.

To engineering: Treat this as a design reference, not a dependency. Lift two things: (1) the PaymentGatewayInterface-style seam so PSP SDK types never reach domain code, and (2) the payment state machine, which becomes our source of truth for order fulfillment eligibility, refunds, and webhook reconciliation. Implement them behind an interface we own, with adapters per PSP (Omnipay or first-party SDKs), and make transitions idempotent and auditable. Budget the work as 3–5 days of abstraction scaffolding plus per-PSP adapter effort — cheaper than integrating a Symfony bundle into a non-Symfony stack and then owning a fork forever. Revisit only if we standardize on Sylius.

One-line risk statement: archived upstream + read-only repo + no dependents = zero upgrade path; the concepts are worth an afternoon, the code is not worth a dependency.