Weave Code
Payment Core Bundle Laravel Package
ezsystems/payment-core-bundle
JMSPaymentCoreBundle provides a unified Symfony API for integrating multiple payment backends. It handles payment and transaction persistence, retries, sensitive-data encryption, and supports many providers out of the box.
A unified API for processing payments with Symfony
Frequently asked questions about Payment Core Bundle
- Can I use ezsystems/payment-core-bundle (jms/payment-core-bundle) in a Laravel application?
- No. Despite the Composer name, this is a Symfony bundle that ships a JMSPaymentCoreBundle class extending Symfony's Bundle kernel, Doctrine ORM entities, and YAML service definitions. Laravel has no bundle kernel, no container compilation pass for services.yml, and a different ORM and event model. Composer will happily install it, but there is no service provider, facade, or config file to boot it, so it cannot run in a Laravel app without a full port.
- Is jms/payment-core-bundle still maintained and does it support modern PHP or Laravel?
- No. The repository is archived with roughly two stars and zero dependents, meaning no upstream patches, no maintainer response, and no compatibility work for PHP 8.x, Symfony 6/7, or Laravel 10/11. Its constraints are pinned against Symfony 2/3 components and Doctrine 2.x. Archived payment code also receives no CVE backports, which is a serious concern for anything handling financial data.
- What does JMSPaymentCoreBundle actually do?
- It provides a unified Symfony API for integrating multiple payment backends, abstracting away differences between payment protocols. It handles persistence of payments and transactions, retry logic, encryption of sensitive data, and ships adapters for several providers. The core value proposition is integrate once and switch providers behind a single API.
- Why does composer require succeed but the bundle fail to boot in Laravel?
- Composer only resolves and downloads code; it does not verify framework compatibility. The package registers itself through Symfony's bundle kernel, compiles DI service definitions from YAML, and wires an event-dispatcher-driven transaction workflow, none of which Laravel provides. Installation succeeds, but the first attempt to boot or resolve a payment service will fail because there is no Laravel service provider or container binding.
- Will jms/payment-core-bundle conflict with my Laravel composer.json dependencies?
- Very likely. The package pins constraints against older Symfony 2/3 components and Doctrine 2.x, which will collide with the Symfony components and Doctrine versions pulled in by a modern Laravel application. Even where Composer can be coerced into resolving, you end up with duplicate or downgraded packages. Dependency rot of this kind is a maintenance trap rather than a one-time install problem.
- Can I reuse the JMSPaymentCoreBundle Doctrine entities (Payment, Transaction, Credit) with Eloquent?
- Not directly. The entities are Doctrine ORM mappings with annotation or XML metadata and associations, so Eloquent cannot hydrate or persist them. A port would mean reimplementing the domain model as framework-independent or Eloquent entities, rewriting the payment state machine against Laravel's container and events, and replacing Symfony Form, Validator, and security plumbing. That is a rewrite rather than an integration, and every gateway adapter would need re-validation afterwards.
- Is it safe to use the bundle's sensitive-data encryption to store card details?
- No, and you should not store card data at all. Adopting this bundle pulls stored payment credentials into your database and expands your PCI DSS scope, and legacy crypto helpers of this vintage frequently rely on mcrypt (removed in PHP 7.2) or deprecated OpenSSL modes. Tokenize at the PSP using hosted fields or a payment element and persist only PSP tokens, keeping you in SAQ A or A-EP territory rather than full SAQ D.
- Which payment gateways does JMSPaymentCoreBundle support and are those adapters still current?
- The advertised backends include PayPal Classic/NVP, Authorize.net, and Datatrans, several of which point at APIs that have been sunset. The adapters predate SCA/3DS2, webhook signature verification, and idempotency keys, so they cannot be trusted to reflect current protocol requirements. A unified API only pays off when the adapters are maintained, and here they are not.
- What should I use instead of JMSPaymentCoreBundle for multi-gateway payments in Laravel?
- Define a thin first-party abstraction such as App\Payments\Contracts\Gateway with authorize, capture, refund, and void methods, a PaymentIntent value object, and a normalized Result. Implement one adapter against your chosen PSP's official SDK (Stripe, Adyen, Mollie, Paddle), bind it in a service provider, and configure it via config/payments.php with secrets from env or a KMS. Persist your own payments, payment_events, and webhook_events tables with idempotency keys, treat signed webhooks as the source of truth, and run a reconciliation job against the PSP ledger. If a provider-agnostic layer is genuinely required, evaluate league/omnipay, which is actively used and Laravel-friendly.
- Is there anything worth taking from JMSPaymentCoreBundle's architecture?
- Yes, as a reference design rather than a dependency. The transferable ideas are a Payment/Transaction state machine, explicit retry semantics, gateway-agnostic request and response DTOs, and persistence of full transaction history. Those are worth a day or two of design study and zero lines of copied code. Before building, clarify whether you actually need an abstraction over multiple PSPs or just one solid integration, since it is almost always the latter.
Weaver
How can I help you explore Laravel packages today?