Payment Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for checkout payments: Elcodi's Payment Bundle is a reference model for how to layer payment method selection, payment method resolution, and order/payment state transitions on top of Symfony's service container. It's useful as an architectural comparison point when scoping a custom payment abstraction, not as a dependency to adopt.
• Feature scoping for multi-gateway checkouts: The bundle's structure (payment methods as tagged services, a payment-method resolver, a "payment bridge" concept between order and gateway) tells you what a minimum viable multi-gateway checkout surface looks like — useful when writing acceptance criteria for your own payment module.
• Roadmap input for maintenance and migration: Because this is EOL and archived, it directly informs legacy-support decisions: if a product currently depends on Elcodi (or a fork), the roadmap item is replacement, not integration. Budget for a migration spike, not an adoption spike.
• Vendor and platform due diligence: A PM evaluating e-commerce platforms should treat Elcodi as a cautionary data point — strong component decomposition, MIT license, but no release cadence since 2016 and no dependents. It's evidence for weighting maintenance signals (release recency, archive status, community activity) in platform selection scorecards.
• Competitive/technology landscape framing: Useful when justifying an in-house or modern-stack decision (Symfony UX + Stripe/Adyen SDKs, or a maintained bundle) versus reviving an abandoned component suite.
• Not supported: choosing a payment provider, pricing/contract negotiation, PCI scope determinations, or any decision that requires an actively maintained library.

When to Consider This Package

Consider it only in these narrow situations:

• Forensic/reference reading. You're designing a payment abstraction on Symfony and want to see a worked example of payment methods as services, resolvers, and order-to-gateway bridges. Read the source; do not require it.
• Maintaining an existing Elcodi installation. You inherited a codebase or fork that already vendors this bundle. Even then, the realistic decision is "freeze and plan exit," and the correct action is to work from the monorepo (elcodi/elcodi) since this split package is read-only and will not receive PRs.
• Historical due diligence on a legacy vendor. A partner, acquisition target, or RFP response cites Elcodi as its commerce stack. This package's status is relevant evidence in that evaluation.
• Architectural pattern mining for a migration. You need to enumerate existing behaviors (payment method selection, state transitions) before replacing the system, and the bundle is a spec of record.

Look elsewhere — clearly and without hedging — when:

• You need a payment integration for a product in development. Use a maintained, actively supported option: Symfony's own payment-adjacent tooling plus a provider SDK (Stripe, Adyen, Mollie), or a maintained bundle with recent releases and a live issue tracker.
• You require security patching, PCI-relevant updates, or compatibility with current PHP/Symfony versions. Archived since 2016 means no PHP 8.x or modern Symfony support, and no CVE response.
• You need support SLAs, documentation currency, or a community to escalate to. The README points to Gitter, Twitter, and Stack Overflow — channels that are effectively dormant for an EOL project.
• Dependency risk matters (it always does): zero dependents and a read-only repo mean no ecosystem safety net and no upstream fixes.
• You're evaluating this for a greenfield roadmap item. There is no version of "adopt" that is defensible here.

Practical guidance: treat this as a documentation and pattern artifact, not a library. If a team proposes using it, the PM question is "what is our replacement and exit plan, and what's the cost of the technical debt we're taking on today?"

How to Pitch It (Stakeholders)

For executives (one paragraph): Elcodi's Payment Bundle is an archived, end-of-life component from a 2016-era Symfony e-commerce suite — MIT-licensed, ~420 GitHub stars, no dependents, and no releases in roughly a decade. It is not a candidate for adoption: no security updates, no compatibility with current PHP/Symfony, and no maintainers. Its value to us is as a reference design and due-diligence input — it shows how a mature payment-method abstraction was structured, and it sharpens the criteria we use to reject stale platforms in vendor evaluations. Recommendation: do not add it to any build; do use it as a comparison point when we define our own payment module's requirements.

For engineering leads: The bundle models payment methods as tagged Symfony services with a resolver and an order-to-gateway bridge. That's a clean, legible pattern worth borrowing conceptually. Borrow the pattern; do not import the code. Any existing dependency on Elcodi should be logged as technical debt with a named owner and a migration path to a maintained provider SDK or bundle. Note the split-package read-only constraint — issues and PRs route through the monorepo, which is itself archived.

For product/finance stakeholders: There is no licensing cost (MIT), but the total cost of ownership is effectively infinite for new work — unsupported code compounds risk in a payment path, which is the highest-consequence surface in commerce. The decision this package supports is what to build instead, and how to score future platform candidates on maintenance signals: archive status, release recency, dependent count, and responsiveness of support channels.

The one-line ask: Approve zero engineering time for adoption; approve a small, time-boxed research read (a few hours) if we need the pattern for our own payment abstraction, and fund a migration assessment for any legacy Elcodi footprint we discover.