Payment Core Bundle Laravel Package

Technical Evaluation

Architecture fit. Poor. Despite the Composer package name, ezsystems/payment-core-bundle (published as jms/payment-core-bundle) is a Symfony bundle, not a framework-agnostic library. It ships a JMSPaymentCoreBundle class extending Symfony\Component\HttpKernel\Bundle\Bundle, Doctrine ORM entities (Payment, Transaction, Credit, FinancialTransaction), Symfony DI service definitions, and an event-dispatcher-driven transaction workflow. Laravel has no bundle kernel, no services.yml container compilation, and a different ORM and event model. There is no service provider, facade, config file, or Laravel test coverage. "Installing" it via Composer will succeed; booting it will not.

Integration feasibility. Effectively zero without a port. A viable integration would require reimplementing the domain model as Eloquent/Doctrine-independent entities, rewriting the payment workflow state machine against Laravel's container and events, replacing Symfony Form/Validator/security plumbing, and re-validating every gateway adapter. That is a rewrite wearing an integration's clothes. The package is also archived with 2 stars and 0 dependents — no upstream patches, no maintainer response, no compatibility work for PHP 8.x, Symfony 6/7, or Laravel 10/11.

Technical risk. High and asymmetric.

• Security/compliance: the bundle's core value prop includes "encryption of sensitive data" and persistence of financial entities. Adopting it pulls stored payment credentials into our database and expands PCI DSS scope. Legacy crypto helpers of this vintage frequently rely on mcrypt (removed in PHP 7.2) or deprecated openssl modes, and archived payment code receives no CVE backports.
• Dependency rot: pinned constraints against Symfony 2/3 components and Doctrine 2.x will conflict with a modern Laravel composer.json.
• Gateway staleness: the advertised backends (PayPal Classic/NVP, Authorize.net, Datatrans, etc.) point at APIs several of which are sunset; adapters cannot be trusted to reflect current protocol requirements (SCA/3DS2, webhook signing, idempotency keys).
• Unified API value is illusory here: the abstraction only pays off if the adapters are maintained, which they are not.

Key questions.

1. Is the requirement an abstraction layer over multiple PSPs, or a single PSP integration? (Almost always the latter.)
2. Do we intend to store card data, or tokenize at the PSP (hosted fields / Payment Element)? Only the second is defensible.
3. What is the actual PCI scope target — SAQ A/A-EP, or full SAQ D?
4. Which gateways are contractually required, and do they offer current SDKs?
5. Is there a hard dependency on this package from an existing EZ Platform/Symfony system we must interoperate with, or is this a greenfield choice?

Integration Approach

Stack fit. None directly. Treat this package as a reference architecture, not a dependency. The transferable ideas are: a Payment/Transaction state machine, retry semantics, gateway-agnostic request/response DTOs, and persistence of transaction history. Those are worth ~1–2 days of design study and zero lines of copied code.

Migration path. Recommended path is a thin, first-party abstraction:

1. Define App\Payments\Contracts\Gateway with authorize, capture, refund, void, plus a PaymentIntent value object and normalized Result.
2. Implement one adapter against the chosen PSP's official SDK (Stripe, Adyen, Mollie, Paddle). Bind via a Laravel service provider; configure through config/payments.php and env/KMS-held secrets.
3. Persist our own payments, payment_events, and webhook_events tables with idempotency keys; never store PAN/CVV — store PSP tokens only.
4. Handle webhooks as the source of truth for terminal state, with signature verification and replay protection.
5. Add a reconciliation job comparing local state to the PSP's ledger on a schedule.

If a framework-agnostic abstraction is genuinely mandated, evaluate league/omnipay (actively used, Laravel-friendly) or a provider-agnostic layer like Laravel Cashier for Stripe/Paddle. Both are maintained; this bundle is not.

Compatibility. Assume PHP 8.x, Laravel 10/11, MySQL 8/Postgres. The package's Symfony 2/3-era constraints will not resolve. Any attempt to force it creates a composer.json conflict surface that blocks future framework upgrades — an unrecoverable position for a payments subsystem.

Sequencing.

• Week 0: ADR documenting rejection of the bundle with rationale (archived, Symfony-coupled, PCI risk).
• Week 1: Gateway contract, config, secret management via AWS KMS/Vault, PSP sandbox account.
• Week 2–3: Primary adapter + webhook ingestion + idempotency + test suite against sandbox.
• Week 4: Reconciliation job, dashboards, runbook, PCI scope memo.
• Later: second adapter only if a real business requirement emerges — the abstraction earns its keep when there are two implementations.

Operational Impact

Maintenance. If adopted, we own the code outright: no upstream fixes, no security releases, no PHP/framework compatibility work. Budget ongoing fork maintenance or accept a frozen, unpatchable subsystem sitting in the payment path — the highest-consequence place to freeze code. Recommended path (first-party abstraction over a maintained SDK) shifts maintenance to the PSP vendor.

Support. Zero vendor support, 2 stars, 0 dependents means no community to triage issues, no Stack Overflow corpus, no known-issue database. Incident response falls entirely on our on-call engineers debugging unfamiliar Symfony/Doctrine internals during a revenue-impacting outage.

Scaling. Persistence-heavy transaction model with Doctrine entities is fine at moderate volume but adds a Doctrine/Symfony-shaped resource profile to an otherwise Eloquent application — two ORMs, two migration systems, two connection pools, doubled cognitive load. Webhook throughput and retry storms need explicit queue/backpressure design regardless of library.

Failure modes to design for.

• Partial state: authorized-but-not-captured payments; need explicit state machine plus expiry sweeper.
• Duplicate charges: the bundle's "retry logic" is exactly where double-capture bugs live — enforce idempotency keys at the PSP boundary and unique constraints locally.
• Webhook loss/duplication: signature verification, event dedupe table, replay-safe handlers, reconciliation as safety net.
• Secret/key compromise: encrypted-at-rest payment data requires key rotation, envelope encryption, and audit logging; a stale crypto implementation here is a breach vector.
• Silent gateway deprecations: PSP API sunsetting will surface as production failures, not deprecation warnings.

Ramp-up. Any engineer touching this needs Symfony bundle/DI/Doctrine fluency plus payments domain knowledge — a rare and expensive combination, and the opposite of the Laravel team's existing skill set. Realistic ramp-up on the legacy code is weeks for basic literacy and months for confident incident response. By contrast, a 500-line first-party abstraction over a documented SDK is reviewable in an afternoon by any senior Laravel engineer.

TPM recommendation. Do not adopt. Record the decision, harvest the domain model as design input, and build a thin internal gateway abstraction over a maintained PSP SDK. The unified-API premise is sound; this specific artifact is archived, Symfony-only, PCI-expanding, and unmaintained — all four disqualifying for a payments path.