- Can I use ruudk/payment-mollie-bundle in a Laravel application?
- No. Despite being catalogued alongside Laravel/PHP packages, this is a Symfony 2 bundle that ships a Bundle class, a DI extension, service definitions, and depends on JMSPaymentCoreBundle for its payment domain model. Laravel has no concept of Symfony bundles or container extensions, so it cannot be dropped in without effectively rewriting it as a service provider. Treat it as a reference implementation only, not a runtime dependency.
- Is ruudk/payment-mollie-bundle still maintained?
- No, the repository is explicitly marked NO LONGER MAINTAINED. It targets Symfony 2.x, which reached end of life in November 2018, and the Mollie API v1 era. There is no security patching path, no CVE response process, and no upstream maintainer to escalate to. For code that touches payments, that is a serious risk.
- Which Mollie API version does this bundle use?
- It encodes the Mollie API v1 request and response shapes from the legacy PHP client. Mollie sunset both the v1 API and that client years ago, so those endpoints and payload structures are no longer served. Any adapter written against this code would need to be rebuilt on the current Mollie API.
- What should I use instead of this bundle in a Laravel app?
- Use the official mollie/mollie-api-php SDK wrapped in a thin internal service class, rather than a framework-specific bundle. Pair it with Laravel-native primitives: a signed webhook controller, queued jobs for reconciliation, and explicit currency and minor-unit handling. If you want an abstraction layer, define your own PaymentGateway contract with create, capture, refund, and status methods rather than adopting an abandoned one.
- Will Composer install this package on PHP 8.1 or later?
- Almost certainly not without patching. The bundle is hard-incompatible with PHP 8.x in all likelihood, due to dynamic properties, deprecated constructors, and old PSR versions, and its abandoned transitive dependency JMSPaymentCoreBundle compounds the problem. Constraint resolution will typically fail, and the effort to force it installable exceeds a clean reimplementation.
- What is JMSPaymentCoreBundle and why does it matter?
- It is the payment domain model this bundle depends on, providing the PaymentInstruction, Token, Payment, and status transition concepts plus the gateway interface pattern. It has had no meaningful release in years and is itself unmaintained. That makes it an abandoned transitive dependency sitting directly in your payment path.
- Is it safe to handle real payments with unmaintained Mollie code?
- No. Risk here is high and concentrated in the worst possible place: unmaintained code touching money with no patch path and effectively no community testing, given 0 dependents and roughly 15 stars. PCI scope is partially mitigated because Mollie is the PSP and redirect or hosted-fields flows keep card data off your infrastructure. However, webhook authenticity, idempotency, and amount and currency precision all become your responsibility to own and harden.
- Is there any value in reading this bundle's source code?
- Yes, as a read-only reference. A one-to-two day spike is cheap and sufficient to extract its domain vocabulary and state machine, such as the PaymentInstruction to Token to Payment status transition model and the gateway-interface pattern. Keep the naming so future engineers recognise it, then discard all transport, DI, and template code and reimplement against the current SDK.
- Does it support refunds, subscriptions, SEPA, Klarna, or iDEAL?
- Whatever it once covered reflects 2019-era Mollie capabilities, and current coverage differs materially. Mollie's supported methods, subscription handling, refund flows, and OAuth for connected merchants have all evolved since then. Check the official mollie/mollie-api-php documentation for current capabilities rather than assuming this bundle's coverage applies.
- How do I test or migrate away from this bundle?
- There is nothing to migrate from, because the bundle was never adoptable in a Laravel stack in the first place. Reframe the work as extraction: mine the domain model, define an internal PaymentGateway contract, implement a Mollie adapter against the official SDK with idempotency keys, then harden webhook signature verification and replay protection. If you are on Symfony 6 or 7, the same SDK applies, with Payum or Sylius as the modern equivalents of what this bundle once provided.