Payment Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for payment orchestration. The bundle is essentially a thin abstraction layer: a shared payment model/state machine plus gateway adapters registered as Symfony services. That informs the recurring PM question "do we build our own PSP abstraction, or adopt one?" — this is a candidate only if the answer is "adopt a small, forkable one."
• Gateway-agnostic checkout scoping. It supports the product decision to keep the order/cart domain decoupled from any single provider (Stripe, PayPal, Atos/SystemPay, etc.), which is what lets roadmap items like "add a regional payment method in Q3" be a configuration task rather than a re-architecture.
• Multi-provider roadmap sequencing. Because adding a method is a bundle-level concern, the PM can sequence provider expansion by business value (conversion, geography) rather than by engineering cost — useful when prioritizing which markets to open next.
• Scope boundaries for "payments" v1. Reading the bundle's surface (payment states, callbacks/notifications, capture/refund hooks) is a cheap way to sanity-check your own MVP scope: what you must own (reconciliation, dunning, tax) vs. what a thin layer legitimately delegates to the PSP.
• Legacy Symfony modernization decisions. For an existing Symfony estate, this can be evaluated as a low-effort interim layer while a longer-term checkout rewrite is planned — a "stop the bleeding" option, not a destination.
• Framework direction signal (important). Despite the "Laravel/PHP" framing in the request, this is a Symfony bundle, not a Laravel package. A PM decision here is really two decisions: (a) is our stack Symfony, and (b) if not, is a bridge/adapter worth it? For a Laravel roadmap, this package does not shorten the path — it lengthens it.

When to Consider This Package

Consider it when:

• Your application is Symfony/PHP and the team already has bundle and DI-container fluency; integration cost is then genuinely low.
• You need a thin, redirect/off-site-style abstraction over several PSPs for simple one-time payments, and you accept owning the code.
• You are willing to pin a version and fork it internally — treat it as sample/reference code you adopt, not a dependency you consume.
• The workload is internal, back-office, prototype, or a bounded legacy integration where a 1-star, 0-dependent package is an acceptable risk because you are the maintenance plan.
• You want a pattern reference (state machine + tagged gateway services) to inform your own design, even if you never install it.

Look elsewhere when:

• You are on Laravel — use Laravel Cashier, the Omnipay ecosystem, or a direct PSP SDK. Retrofitting a Symfony bundle into Laravel is a net cost with no upside.
• You need subscriptions, proration, invoicing, dunning, or marketplace payouts; this is a request/response payment layer, not a billing engine.
• You need out-of-the-box SCA/3DS2, PSD2, or strong-customer-authentication compliance — verify per-adapter, and assume gaps. Do not let a bundle's existence imply compliance.
• You need a vendor with an SLA or security responsiveness. With 1 star, 0 dependents, and a low composite score, there is no community safety net, no implied CVE response, and no ecosystem of fixes to lean on. Gateway APIs (especially legacy Atos/SystemPay-style ones) drift; unmaintained adapters silently break at the worst moment.
• Your payment flow is revenue-critical at scale — the cost of an outage or a broken callback handler will exceed the integration savings within weeks.
• You require multi-currency, tax, fraud tooling, or reconciliation reporting as product scope.

Adoption gate before any commitment: a 1–2 day spike that (1) confirms bundle compatibility with the current Symfony/PHP version, (2) exercises a real sandbox transaction end-to-end including callback/notification handling and a refund, and (3) records exactly which upstream files we would need to own. If the spike can't get a sandbox transaction through, stop.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated idci/payment-bundle, an MIT-licensed Symfony component that standardizes how an application talks to multiple payment providers. Conceptually it matches a real need — keeping our checkout independent of any single provider so we can add or switch gateways for conversion and geographic expansion without rebuilding checkout. Practically, it is a very low-adoption package (1 GitHub star, no dependent projects, no vendor support), which means we would be adopting code to maintain, not a product to rely on. Recommendation: treat it as a reference architecture and a possible time-boxed accelerator for a Symfony codebase only, never as a strategic dependency. For a Laravel stack, it is not applicable and should be removed from the shortlist. Expected saving if adopted is measured in days of integration work; expected ongoing cost is ownership of a fork, plus compliance and gateway-API-drift risk we would carry ourselves.

For engineering (the honest version): It's a Symfony bundle providing a payment entity/state machine and tagged gateway services — the classic pattern, competently scoped, but effectively unmaintained and unproven in the wild. Two asks before we decide: run a two-day spike proving a sandbox authorise → callback → capture → refund cycle on our target Symfony/PHP version, and produce a list of files we'd have to fork. If the spike is clean, we cap the commitment to the smallest surface possible and wrap it behind our own PaymentGateway interface so it is replaceable in one sprint. If it's not clean, we take the pattern and write the 300 lines ourselves — that is the likely outcome and it is not a bad one.