Payment Mollie Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental mismatch. Despite being catalogued as a "Laravel/PHP package," ruudk/payment-mollie-bundle is a Symfony 2 bundle, not a Laravel package. It ships a Bundle class, DI extension, service definitions, and depends on JMSPaymentCoreBundle for its payment domain model. It cannot be dropped into a Laravel application without effectively rewriting it. Even inside a Symfony app it targets Symfony 2.x (EOL November 2018) and the Mollie API v1 era. Verdict: not adoptable as a runtime dependency; usable only as a reference implementation and domain-model donor.

Integration feasibility — low. Three independent blockers stack up: (1) framework mismatch (Symfony bundle vs. Laravel service provider), (2) abandoned transitive dependency (JMSPaymentCoreBundle has had no meaningful release in years and is itself unmaintained), and (3) API drift — Mollie sunset its v1 API and the legacy PHP client years ago, so the request/response shapes this bundle encodes are no longer served. Composer constraint resolution alone will likely fail on modern PHP (8.1+) without patching.

Technical risk — high, and concentrated in the worst place. This is unmaintained code touching money. There is no security patching path, no CVE response, and no upstream to escalate to. If adopted, every defect becomes our defect, in the payment path, with 0 dependents and 15 stars meaning no de facto community testing. PCI scope is partially mitigated because Mollie is the PSP (redirect/hosted-fields flows keep card data off our infrastructure), but webhook authenticity, idempotency, and amount/currency precision are all things we would own.

Key questions

• Does any part of our stack still run Symfony 2.x, or is this purely a Laravel target? (Likely the latter, which ends the adoption conversation.)
• What is the actual driver — a specific Mollie feature, or "we need Mollie at all"? The official mollie/mollie-api-php client likely covers the need directly.
• Is the goal reuse or reference? If reference, a 1–2 day read-only spike is sufficient and cheap.
• Which Mollie capabilities do we need (one-off payments, subscriptions, refunds, SEPA, Klarna/iDEAL methods, OAuth for connected merchants)? Current coverage differs materially from 2019.
• Who owns the webhook endpoint, reconciliation job, and refund flow if we build rather than buy?

Integration Approach

Stack fit. Zero for Laravel. The correct target architecture for a Laravel app is the official Mollie PHP SDK (mollie/mollie-api-php) wrapped in a thin internal service, plus Laravel-native primitives: queued jobs for reconciliation, signed webhook controller, Http client only if the SDK is bypassed. If the team is on Symfony 6/7, the same SDK applies; Payum or Sylius payment abstractions are the modern equivalents of what this bundle once provided.

Migration path. There is nothing to migrate from — the bundle was never adopted. Reframe as extraction: mine the bundle for its domain vocabulary and state machine, then reimplement. Concretely, lift the PaymentInstruction → Token → Payment → status transition model and the gateway-interface pattern from JMS PaymentCore, keep the naming so future engineers recognize it, and discard all transport, DI, and template code.

Compatibility. Hard-incompatible with PHP 8.x in all likelihood (dynamic properties, deprecated constructors, old PSR versions), Symfony 4+, and Laravel 8+. Do not attempt to make it installable; the effort exceeds a clean reimplementation.

Sequencing

1. Timeboxed spike (1–2 days). Read the source only. Output: a one-page domain model extract and a list of Mollie operations it encodes. No install.
2. Define an internal PaymentGateway contract in our own codebase — create, capture, refund, status, webhook handling.
3. Implement the Mollie adapter against the official SDK and current API version, with idempotency keys and explicit currency/minor-unit handling.
4. Harden the edges: webhook signature verification, replay protection, reconciliation job, ledger-side double-entry or equivalent.
5. Shadow-run in test mode against Mollie's sandbox before any production traffic; no dual-run with the bundle is possible or needed.

Operational Impact

Maintenance. If adopted, 100% ours from day one: no upstream commits, no patch releases, no dependency bumps. We would be maintaining a vendored fork of a nine-year-stale Symfony bundle. That is a permanent tax on a two-person team. As a reference-only artifact, maintenance cost is zero — it is a document, not a dependency.

Support. None. Archived repository, no issue triage, no maintainer responsiveness, 0 dependents meaning no peer experience to draw on. Any production incident debugs from source with no external help.

Scaling. Not a runtime concern if we do not adopt it. If we did, scaling concerns would be secondary to correctness concerns — the bundle has no idempotency guarantees in the modern sense, and webhook handling written for a 2019 API is unlikely to survive subscription volume or partial-failure scenarios.

Failure modes (if adopted). Deprecated endpoints returning 404/410 with no fallback; silent status-transition bugs where a payment is marked complete without confirmation; missing idempotency leading to double charges on retry; float-based amount handling causing rounding drift in non-EUR currencies; uncaught exceptions during webhook processing that leave orders in limbo; PHP 8 fatal errors from deprecated syntax. Each of these is a customer-visible money event.

Ramp-up. Documentation is effectively nil — a README and the source. Estimate one engineer-day to understand the domain model and one to two days to map it onto a modern Mollie integration. Cheap, and the only real value on offer here.

TPM recommendation. Do not adopt. Commission the 1–2 day spike to extract the domain model, then build on mollie/mollie-api-php. The 0.3225 score accurately reflects a package that is architecturally wrong for the stated stack, dependency-abandoned, and API-obsolete — its only leverage is as a free design reference for payment state modeling.