Mollie Laravel Package

Technical Evaluation

Architecture fit. vanilo/mollie is a first-party-style payment module for the Vanilo e-commerce stack, implementing the Vanilo Payments PaymentGateway contract against Mollie's REST API. Architecturally this is the correct shape for the ecosystem: Vanilo is a Laravel-native commerce framework that deliberately abstracts payment providers behind contracts, so a Mollie driver should drop in without touching order, checkout, or cart code. The critical caveat is that this is a thin integration package — its value is entirely bounded by (a) fidelity to the Vanilo Payments contract and (b) fidelity to Mollie's API. Neither is validated by the community signal here.

Integration feasibility. Mechanically low-friction: Composer install, Laravel package auto-discovery, a published config for API key(s), and a gateway registration in the Vanilo payment configuration. Checkout flow is almost certainly Mollie's hosted/redirect pattern, which keeps the merchant in the lowest PCI-DSS scope (SAQ A). Webhook endpoint registration is the main integration surface that needs operational planning.

Technical risk — this is where the package fails scrutiny. The signals are poor:

• 2 stars, 0 dependents, score 0.01. There is effectively no community validation, no downstream consumers confirming it works in production, and no network effect to accelerate issue resolution. A TPM should treat this as unproven code, not as an ecosystem-standard component.
• Version coupling is a black box. Vanilo's contracts have evolved (payments, checkout, admin). Whether this module targets Vanilo 3.x/4.x/5.x and which Laravel/PHP versions it tolerates is the first thing to verify — an unmaintained module on a moving framework is a compounding liability.
• Mollie API drift. Mollie deprecates API versions and payment method configs on a rolling basis. A low-traffic module is unlikely to track those changes proactively; the team inherits that tracking burden.
• Maintainer continuity. Single-maintainer risk is the default assumption until proven otherwise. Fork-and-own is the realistic fallback.

Key questions to resolve before adoption:

1. Which Vanilo and Laravel versions are supported, and is there a CI matrix proving it?
2. Which Mollie API version is targeted, and does the module handle Mollie's _links/status transition model (open → pending → paid/failed/expired/canceled) correctly against Vanilo's payment state machine?
3. Which payment methods are exposed — iDEAL, Bancontact, credit card, SEPA Direct Debit, Klarna — and is method selection configurable or hardcoded?
4. Does it implement refunds and partial refunds, or only authorize/capture?
5. Are webhooks signature-verified (Mollie does not sign webhooks, so the correct pattern is fetch-back by payment ID rather than trusting the payload)?
6. Is idempotency handled — duplicate webhooks, retried redirects, double-charge prevention?
7. Test coverage: are there automated tests against a Mollie test-mode key, or only manual verification?
8. Who is the maintainer, and what is their recent commit cadence?

Integration Approach

Stack fit. Strong on paper. Laravel + Vanilo + Mollie is a coherent, single-language, Composer-managed stack. Mollie is the right PSP for Benelux/DACH-oriented commerce (iDEAL, Bancontact, SEPA, local card acquiring), and Vanilo's gateway abstraction means the module should be swappable — you can keep a second gateway (Stripe, Pay.nl, MultiSafepay) registered alongside it and route by region or method. That optionality is the main architectural hedge available to you and should be exercised.

Migration path. Greenfield adoption is straightforward: install, configure keys, register the gateway, run test-mode transactions end-to-end in a staging environment. Brownfield is materially harder — if you are moving from another PSP, you need to reconcile the Vanilo payment record schema (transaction IDs, statuses, amounts), decide whether historical payments stay on the old gateway, and confirm the module's status mapping aligns with your existing order state transitions. Plan for a parallel-run window rather than a cutover.

Compatibility. Two distinct axes: framework compatibility (Vanilo/Laravel/PHP) and provider compatibility (Mollie API version, enabled payment methods, currency and country restrictions). Both need explicit pinning in composer.json and a documented upgrade policy. Because dependents are zero, you cannot infer compatibility from the wild — you must verify it yourself in a disposable environment before committing.

Sequencing. Recommended order:

1. Spike (1–2 days). Install in a scratch Laravel/Vanilo app, exercise test-mode payment, webhook, refund. This single step will resolve most of the risk questions above and is cheap.
2. Vendor-risk decision. If the spike passes and the code is legible, adopt with a fork-and-own posture (mirror to internal Git, pin the version). If it fails or the code is opaque, budget for a rewrite of the driver against Vanilo's contract — likely 3–5 engineer-days given the surface area.
3. Staging integration with full state-machine tests, webhook retry simulation, and failure injection.
4. Production canary on a low-traffic payment method before enabling all methods.

Operational Impact

Maintenance. Treat this as internally owned code from day one, regardless of the MIT license and nominal upstream. Zero dependents means zero external pressure on the maintainer to keep pace with Vanilo or Mollie; you should assume you will patch it. Budget a standing allocation of roughly 1–2 engineer-days per quarter for dependency bumps and Mollie API changes, plus ad-hoc time on framework upgrades.

Support. There is no commercial support and no meaningful community. Internal runbook documentation is mandatory: how the gateway is configured, where API keys live (secrets manager, not .env in repo), how to replay a webhook, how to reconcile a stuck payment manually in the Mollie dashboard, and who to escalate to. Without this, the module becomes tribal knowledge and a single point of failure during incidents.

Scaling. Mollie absorbs the transactional scale — there is no meaningful scaling concern on the payment side at typical commerce volumes. The scaling risks are elsewhere: webhook endpoint throughput and idempotency under retry storms, and database contention on Vanilo's payment/order tables during peak. Ensure the webhook handler is queued, fast, and idempotent, and that it does not block on synchronous Mollie calls inside the request cycle.

Failure modes to design for:

• Webhook loss or delay — Mollie retries but does not guarantee delivery ordering. The correct pattern is fetch-back-by-ID on receipt, plus a scheduled reconciliation job polling Mollie for non-terminal payments older than N minutes. This is the single highest-value hardening step.
• Redirect abandonment — customer completes payment at Mollie but never returns to your return URL. Only the webhook (and reconciliation job) can rescue this; do not rely on the return handler.
• Status mapping gaps — Mollie states that the module does not map cleanly will leave orders in limbo. Enumerate and handle every terminal and non-terminal state explicitly, with a default-to-alert path for unknown states.
• Currency/method mismatch — method availability varies by country, currency, and amount. Validate before redirect, not after, or you generate avoidable failed checkouts.
• Key rotation and outage — Mollie API downtime is rare but real; the checkout path should fail gracefully with a clear customer message and an alert, not a 500.
• Refund divergence — refunds issued manually in the Mollie dashboard will not be reflected in Vanilo unless the module syncs them. Decide the policy up front.

Ramp-up. Low for a Laravel-fluent engineer — the integration surface is small and the patterns are conventional. The real ramp-up cost is organizational: establishing the fork-and-own workflow, the runbook, the reconciliation job, and the on-call expectations for payment incidents. Estimate 1–2 weeks of one engineer's time to go from zero to confident production operation, inclusive of the spike and hardening.

Bottom line for the TPM. The package is architecturally well-positioned and operationally cheap to try, but the community signal (2 stars, 0 dependents, 0.01 score) means it must be treated as unvetted source code rather than a supported dependency. Approve a short spike to resolve the compatibility and code-quality questions; make the fork-and-own decision explicit before production; and budget modest ongoing maintenance as a known cost. Do not adopt it on the assumption that upstream will keep it current.