Mollie Laravel Package

Product Decisions This Supports

• EU/Benelux market expansion: Mollie is a primary PSP in the Netherlands, Belgium, and wider EU, with strong coverage of local methods (iDEAL, Bancontact, SEPA Direct Debit, Klarna, credit cards). This package is the cheapest path to accepting those methods if your stack is already Omnipay-based.
• Local payment method coverage as a conversion lever: iDEAL in particular is table stakes for Dutch checkout conversion. A PM can treat this as a low-effort experiment: ship local methods, measure checkout completion vs. card-only baseline.
• Build vs. buy for gateway integration: Buying a driver (MIT-licensed, thin adapter) is typically 1–3 sprint-weeks cheaper than a bespoke Mollie integration, and it decouples your payment code from a single PSP.
• Vendor lock-in reduction / multi-PSP strategy: If product strategy calls for routing by geography, method, or cost (e.g., Mollie for EU local methods, Stripe for global cards), Omnipay's common interface lets you A/B or failover gateways behind one abstraction.
• Roadmap sequencing for subscriptions and recurring revenue: Omnipay's createSubscription/cancelSubscription and stored-card abstractions can unblock a recurring-billing MVP for EU customers without building PSP-specific billing logic.
• Marketplace / platform payouts (with caveats): Relevant only if Mollie Connect-style split payments are exposed by the driver — verify before committing roadmap dates.
• Refund and back-office operations: Uniform refund/void semantics across PSPs simplify finance tooling and support workflows.

When to Consider This Package

Adopt when:

• Your application is PHP/Laravel and already standardized on Omnipay (or you're consciously choosing Omnipay as your payment abstraction). In that case the marginal cost is trivial and consistency wins.
• You need Mollie alongside at least one other PSP, and the abstraction value is real rather than theoretical.
• You need standard checkout flows: hosted payments, authorizations, captures, refunds, webhooks, stored cards, basic subscriptions.
• You're comfortable owning integration risk for a small-community driver (63 stars) — i.e., you can vendor/fork it and patch it if Mollie's API shifts.

Look elsewhere when:

• Laravel-first, Mollie-only: use Mollie's official mollie/laravel-mollie / mollie/mollie-api-php SDK instead. It tracks new API features faster, has first-party support, and is the documented path. Omnipay adds an abstraction layer you won't use.
• You need Mollie's newer or richer surfaces: Orders API, Payment Links, Connect/marketplace onboarding and splits, Settlements, gift cards, QR, advanced Klarna/pay-later flows, granular idempotency and webhook semantics. Driver coverage in Omnipay packages typically lags the official SDK.
• You require vendor SLAs or security attestation: this is a community package; there's no commercial support contract.
• Non-PHP services or a polyglot payments layer: consider a PSP-agnostic service or the official SDKs per language instead.
• You need strong, opinionated PCI scope reduction and SCA flows out of the box: confirm hosted-fields/redirect behavior explicitly rather than assuming parity with first-party SDKs.

Due diligence before committing: confirm the driver's supported Mollie API version and method list, whether webhooks are signature-verified, how idempotency keys are handled, and the maintainer/bus-factor situation. The low opportunity score and modest star count are a signal about ecosystem momentum, not about whether the driver works — treat it as a maintenance-risk input, and budget a short technical spike plus a fork-and-patch contingency.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed adapter that lets our Laravel application accept Mollie payments — including iDEAL, Bancontact, SEPA, Klarna and cards — through the same payment interface we already use. It's the lowest-cost way to open the Netherlands/Belgium market and test local payment methods at checkout, with a plausible lift in conversion versus card-only. It also preserves our ability to switch or add PSPs later, which is a negotiating lever on fees. Cost is near zero in license terms; the real investment is a short integration spike and a contingency plan to fork the driver if upstream maintenance stalls. Recommendation: pilot in one EU market, measure checkout completion and payment-method mix, then decide on broader rollout.

To engineering: It's a thin Omnipay driver over Mollie — no new architectural concepts if we're already on Omnipay. It buys us a uniform gateway contract (purchase, authorize, capture, refund, void, stored cards, subscriptions) so payment code stays PSP-agnostic. Two caveats to validate in a spike: (1) feature coverage versus Mollie's official PHP SDK — particularly Orders, Payment Links, and Connect/split payments; (2) maintenance risk at 63 stars, so plan to vendor the package and own patches. If we're Mollie-only and Laravel-only, the official mollie/laravel-mollie package is the better default and we should say so explicitly rather than adopt an abstraction we don't need.