Payment Core Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on payment orchestration. This package is the "core" of a multi-gateway payment architecture: it defines a payment-method abstraction, a bridge that resolves and executes a selected method, and event hooks around success/failure. That is exactly the layer teams are tempted to hand-roll, so it is most useful as prior art for a design decision — what a gateway-agnostic payment core looks like — rather than as a dependency.
• Architecture review for multi-PSP support. If the roadmap includes "add a second or third payment provider," "route by region/currency," or "fall back to a backup acquirer," the abstraction boundary described here (method contract + orchestrator + event bus) is a reasonable baseline to compare internal designs against.
• Reference for in-flight payment lifecycle. The core's event-driven shape maps to product requirements we already carry: payment initiated, authorized, captured, failed, refunded, and the notifications/audit trail around each. Useful when writing acceptance criteria or the payments section of a technical spec.
• Licensing and fork-ability. MIT means no legal blocker to reading, copying concepts, or forking a thin slice into our own codebase if a specific idea is worth keeping. That removes the usual procurement question and leaves only the engineering question.
• Not supported: roadmap prioritization on new builds, vendor selection, or buy-vs-build for anything shipping in the next two quarters. With 25 stars, 0 dependents, and a last release of April 2014, there is no ecosystem, no maintainer, and no evidence of production use to de-risk adoption.

When to Consider This Package

Consider it (as reference material, not a dependency) when:

• We are designing an internal payment abstraction layer and want a cheap, MIT-licensed example of how someone else separated gateway concerns from domain logic.
• We maintain a legacy Symfony 2.x / PHP 5.x application that already speaks this bundle's contracts, and a short-lived internal tool needs to reuse existing wiring. This is the only scenario where it might be an actual dependency rather than a document.
• We want a checklist of concerns a payment core should own — method resolution, payment context/bag, result handling, event dispatch — to validate that our own design is not missing something.

Look elsewhere when:

• The stack is Laravel. This is a Symfony bundle, not a framework-agnostic library. It is coupled to Symfony's bundle, DI container, and event dispatcher conventions; making it work in Laravel means porting, not installing. The cost of that port exceeds the value of anything unique in it.
• Anything customer-facing or money-moving is in scope. Last release 2014 implies PHP 5-era code and Symfony 2.x. PHP 5 and Symfony 2 are both long past end-of-life with no security patches. Using it in a PCI-relevant path is an audit finding, not a technical preference.
• We need maintained provider integrations. Modern options cover the real work: laravel/cashier for Stripe/Paddle subscriptions, thephpleague/omnipay for a maintained multi-gateway abstraction, the official Stripe/PayPal/Adyen SDKs, or Sylius if we were in Symfony. For a fresh build, a thin in-house adapter over one provider's SDK is usually less code than adopting an orchestrator.
• We need a support contract or an answer to "who fixes this when it breaks at 2 a.m.?" The answer here is: us, from a decade-old codebase, with zero upstream and zero community.

How to Pitch It (Stakeholders)

Executives: We evaluated paymentsuite/payment-core-bundle, the core orchestration layer of the PaymentSuite family. Verdict: do not adopt it as a dependency. It is MIT-licensed and the concepts are sound, but the last release was April 2014, it has 25 GitHub stars and zero dependent projects, and no active maintainer. Using it would put unsupported, end-of-life PHP and Symfony code inside our payment path — a security, compliance, and hiring risk that dwarfs any saved build time. Its real value is as a free design reference: it shows how to separate "which payment method" from "how a payment is processed," which is directly relevant to our multi-provider roadmap. Cost to act on this: essentially zero (reading, not installing). Recommendation: keep the architectural pattern, discard the code.

Engineering: This is a Symfony bundle, not a Laravel package, so integration is a port, not a composer require. What is worth stealing is the shape: a PaymentMethod contract, a bridge that resolves and invokes the right method, a payment context object carrying order/amount/customer, and events fired on success and failure so notifications, logging, and reconciliation hang off the same seam. That structure is provider-agnostic and survives swapping gateways. What is not worth stealing is the code itself — expect PHP 5 idioms, Symfony 2 service definitions, and no tests or CI to tell you what still works. If we want a proven multi-gateway abstraction today, evaluate thephpleague/omnipay or a thin adapter over one primary provider's SDK; if we build our own, use this bundle's separation of concerns as the review checklist and nothing more.