Product Decisions This Supports
- Build vs. buy on payments: This is a thin Laravel wrapper around Mollie's official PHP SDK. It exists to remove glue code, not to add business logic — so the real decision is "Mollie as PSP," not "this package vs. custom integration." Treat the package as a low-cost, replaceable adapter.
- Checkout and payment-method roadmap: Gives us hosted checkout, iDEAL/credit card/Bancontact/Sofort-style local methods, refunds, and webhook handling behind a familiar Laravel API — enough to ship a first paid tier without a payments team.
- Subscription and recurring billing scope: Supports Mollie's recurring mandates and subscription endpoints, but the package does not own dunning, proration, tax, or invoice generation. That work is still ours (or a billing platform's). Use this to size whether subscriptions are a Q3 feature or a Q4 feature.
- Platform upgrade sequencing: Release 4.0.0 requires Laravel 11 only. That makes this package a forcing function in the framework upgrade plan — the Laravel 11 migration must land before we can take payment-layer fixes or new Mollie API capabilities. Put it on the upgrade dependency map, not in a silo.
- Vendor risk and exit cost: Because payments are abstracted behind a small surface (create payment, handle webhook, refund, subscription), a future multi-PSP strategy is a contained refactor rather than a rewrite. Worth documenting the seam now.
Release-specific read (4.0.0): Two changes, both breaking in practice — dropping Laravel 9/10 support and moving to Mollie API 3.0. The API bump is the riskier of the two: request/response shapes, webhook payload fields, and any custom code touching SDK objects or raw payloads can shift. Plan a migration spike, not a composer bump.
When to Consider This Package
Adopt when:
- We are on (or committing to) Laravel 11 — 4.x will not install on 9/10, and older majors will stop receiving updates.
- Mollie is the chosen PSP (strong fit for EU/Benelux markets, local payment methods, SEPA and iDEAL coverage).
- We want hosted checkout to keep PCI scope minimal and avoid handling card data.
- The need is standard: one-off payments, refunds, webhooks, basic recurring mandates/subscriptions.
- We value a small, boring integration we can read end-to-end over a large billing platform.
Look elsewhere when:
- We are staying on Laravel 10 or earlier for the next two quarters — pin the last 3.x release, accept the maintenance gap, and revisit at upgrade time.
- We need multi-PSP routing, revenue recovery/dunning, tax computation, or metered billing — evaluate a full billing platform (Cashier-style or a merchant-of-record) instead of layering this.
- We need payment flows outside Mollie's coverage (e.g., strong US/APAC card acquiring, marketplace splits not supported by Mollie's model).
- We are not on Laravel at all — use
mollie/mollie-api-php directly.
Before adopting 4.0.0: confirm the Mollie API 3.0 migration guide against our code, and audit every place we read raw webhook or API payload fields.
How to Pitch It (Stakeholders)
For executives: This is the payment integration layer for our Laravel product — the shortest credible path to taking money in EU markets with local payment methods, without building or maintaining card-handling infrastructure. It's a small dependency, not a platform bet, and it's replaceable if our PSP strategy changes. The new 4.0.0 release is a maintenance-forced upgrade: it only works on Laravel 11 and moves to Mollie's API 3.0. That means a scheduled engineering effort — framework upgrade plus a payment-flow regression pass — rather than a routine dependency bump. Cost is bounded; the risk is in the upgrade window, not in the package.
For engineering: 4.0.0 drops Laravel 9/10 and adopts Mollie API 3.0. Scope the work as: (1) Laravel 11 upgrade prerequisite, (2) SDK/API contract review — request builders, response DTOs, webhook payload fields we parse, (3) regression tests across create payment, webhook handling/idempotency, refunds, and subscription lifecycle, (4) confirm error and status-code mapping still holds. Treat webhook parsing as the highest-risk surface — silent field changes there cause lost or double-credited orders, not loud failures.