Product Decisions This Supports
- Legacy modernization vs. continued maintenance: The archived status and 2019 last release make this a migration decision, not a new-adoption decision. A PM can use this assessment to prioritize removal from the roadmap risk register and fund migration to Mollie’s official PHP SDK or a maintained Symfony integration.
- Build vs. buy: Do not build new payment plumbing around this bundle. Treat payment integration as a buy/integrate decision using Mollie’s supported SDKs, and reserve engineering effort for checkout UX, reconciliation, and operational controls.
- Roadmap sequencing: If the product still runs on Symfony2 or JMSPaymentCoreBundle, the roadmap should couple payment modernization with the broader framework upgrade. Payment migration is a forcing function for Symfony/PHP lifecycle work.
- Feature feasibility: New payment features—payment methods, recurring payments, webhooks, refunds, SCA/3DS flows—should be assessed against the official Mollie API capabilities, not this bundle’s abstractions. This package should not constrain product scope.
- Vendor and compliance risk: The package’s age and archival status create security, compatibility, and PCI/payment-operations exposure. PM should treat this as a risk item with clear ownership, migration budget, and a deadline.
- Use-case fit: Only relevant for maintaining an existing Symfony2/JMSCore payment flow that already depends on it. It is not a candidate for greenfield checkout, marketplace payouts, subscriptions, or multi-gateway abstraction.
When to Consider This Package
Consider it only when all of the following are true:
- You have an existing Symfony2 application already using
JMSPaymentCoreBundle.
- The payment flow is in maintenance mode and a short-term patch is needed before a planned migration.
- You accept that the package is archived, unmaintained, and has effectively no community/dependent signal.
- Security and dependency risks have been reviewed and explicitly accepted by engineering/security leadership.
Look elsewhere—and generally migrate—when any of these apply:
- You are starting a new payment integration.
- You need current Mollie API features, webhook validation, refunds, subscriptions, recurring payments, or SCA/3DS support.
- You run Symfony 4+, PHP 8+, or any supported modern stack.
- You need active maintenance, security patches, or vendor support.
- You require multiple payment providers or a long-term payment abstraction.
- You cannot tolerate an archived dependency in the payment path.
The default recommendation is to not adopt this package and to plan migration to Mollie’s official PHP SDK or a maintained Symfony bundle.
How to Pitch It (Stakeholders)
Executive summary: This is an archived Symfony2-era Mollie integration based on an obsolete payment abstraction. It is not suitable for new product work and represents accumulated technical and payment risk if still in use. The product recommendation is to avoid new adoption and fund migration to Mollie’s officially supported SDK/integration as part of the next framework or checkout modernization cycle.
For engineering: Treat this as legacy-only. Do not extend it. Inventory existing usage, confirm API/security exposure, and scope migration to the official Mollie PHP SDK. Expect to replace JMSPaymentCoreBundle abstractions rather than wrap them further.
For executives: The business risk is not “missing features”; it is an unmaintained dependency in a revenue-critical path. The investment ask is migration budget and roadmap priority, not package adoption. The outcome is a supported payment integration with lower security/compliance risk and access to current Mollie capabilities.
Decision: No-go for new adoption. Conditional keep only for short-term legacy support with an explicit migration plan and owner.