Laravel Cashier Mollie Laravel Package

Technical Evaluation

Architecture fit

• mollie/laravel-cashier-mollie is not a driver bolted onto laravel/cashier; it is a parallel reimplementation of the Cashier API surface backed by Mollie's Payments/Subscriptions/Customers/Mandates APIs. It ships its own Billable trait, its own migrations (customers, subscriptions, subscription_items, orders/payments-style tables), and its own service provider.
• That means the decision is effectively "which billing backbone do we standardize on", not "which adapter do we enable." A codebase cannot meaningfully mix laravel/cashier (Stripe) and this package on the same billable model — namespace and trait collisions make them mutually exclusive. This must be confirmed in a spike before any planning commitments.
• Fits cleanly where the domain is: Laravel app, EU-centric customer base, EUR-denominated, subscription plus one-off charges, SEPA Direct Debit + cards + local methods (iDEAL, Bancontact, etc.). Poor fit for global/US-first pricing, multi-currency catalogs, or metered/usage billing.
• The package leans on Mollie's hosted checkout (redirect-based), which trades UX control for PCI scope reduction and localized payment methods — a reasonable trade for a TPM to defend.

Integration feasibility

• Low technical friction for greenfield: Composer install, publish config/migrations, add the trait to the billable model, wire the webhook route, set MOLLIE_KEY. A working subscription checkout is typically days, not weeks.
• The real effort is behavioral parity assessment: what the team knows from Stripe Cashier (proration semantics, trials, coupons/promotions, invoice PDFs, tax handling, dunning) does not map 1:1. Mollie owns invoicing and tax presentation at the dashboard level; the package exposes a thinner programmatic surface.
• Webhook model differs materially: Mollie posts a thin payload (resource ID only) and the app must fetch the resource. This forces a queue-backed, idempotent handler from day one — good practice, but it is a design constraint, not an optional nicety.

Technical risk

• Community depth is the dominant risk. 182 stars and a low composite score signal a narrow knowledge base. Official Mollie backing materially mitigates abandonment risk, but it does not mitigate "nobody on StackOverflow has hit your edge case" risk.
• API-surface drift: the package tracks Mollie's API and Laravel majors; expect periodic breaking upgrades and read-the-changelog discipline. Pin versions and treat upgrades as planned work.
• Mandate lifecycle (SEPA) is the sharp edge: mandate creation, revocation, expiry, and re-authorization flows are where subscription state drifts and revenue leaks.
• Migration from Stripe is expensive, not because of code but because mandates and customer tokens are provider-bound. Active subscribers generally must re-authorize; that is a churn event to plan and message, not a script to run.
• Bus factor: small maintainer surface. Mitigation is an internal abstraction layer around billing calls so the provider is swappable in principle.

Key questions to resolve before commitment

1. Which payment methods and currencies are revenue-critical in the next 12 months? (If anything outside Mollie's coverage, stop here.)
2. Do we require programmatic invoice PDFs, granular tax logic, or metered billing? If yes, this package is likely insufficient without significant custom work.
3. Are there existing active subscribers on another provider? If so, what is the acceptable re-authorization churn?
4. Who owns webhook infrastructure (public HTTPS endpoint, queue worker, retry/dead-letter, alerting) in production?
5. Is the billing domain isolated enough behind an internal interface that a provider swap is a quarter-level, not a rewrite-level, event?
6. What is our contract with Mollie commercially (fees, settlement, support tier), independent of the package?

Integration Approach

Stack fit

• Laravel (current LTS-era majors), PHP 8.1+, Composer, Eloquent, queue workers, HTTPS. No unusual runtime dependencies. Standard config/services.php credentials, .env-driven.
• Assumes a monolith or modular monolith with a single billable model (User or Team). Multi-tenant or multi-billable-model designs need explicit validation — the package's relationship assumptions are opinionated.
• Requires durable queue infrastructure (Redis/SQS/database) for webhook processing and any deferred billing state transitions. If the team runs sync queues today, that is a prerequisite project.

Migration path

• Greenfield (recommended adoption context): direct install, no migration. Sequence: spike → config + keys (test mode) → migrations → trait on billable model → checkout flow → webhook endpoint + queue → subscription lifecycle → dunning/retry → observability → production keys.
• From laravel/cashier/Stripe: treat as a re-platforming, not a package swap. Recommended pattern: introduce an internal BillingGateway interface first, back it with the existing Stripe implementation, then build the Mollie implementation behind the same interface. Run both in parallel by cohort (new signups on Mollie, existing on Stripe until natural renewal or forced re-mandate). Do not attempt dual-write on the same billable row.
• From bespoke/manual billing: lower risk; the package is a net reduction in custom code. Migrate historical payments as read-only records, not as live subscriptions.

Compatibility

• Verify Composer-level conflict with laravel/cashier (same-namespace collision is likely). If both must exist during transition, they need separate billable models or separate applications, not the same model.
• Confirm supported Laravel/PHP matrix against our current and next-major versions before committing — an upgrade freeze is a hidden cost.
• Payment-method coverage is per-currency and per-country; validate against the actual pricing pages, not the marketing matrix.
• Test mode is well-supported (Mollie test keys); ensure CI uses test keys and that production keys are never reachable from non-prod environments.

Sequencing (suggested)

1. Spike (1 week): install, prove checkout + webhook + one renewal in test mode; document every Stripe-Cashier feature we currently rely on and mark parity/gap.
2. Decision gate: parity gaps acceptable → proceed; gaps require custom build → re-estimate or reconsider.
3. Foundation: config, migrations, billable trait, internal billing interface, queue-backed webhook endpoint, idempotency keys.
4. Core flows: subscribe, swap plan, cancel (immediate and at-period-end), resume, trial, one-off charge, refund.
5. Operational hardening: webhook retry/dead-letter, reconciliation job, alerting on failed renewals, runbook.
6. Cutover: new signups first; existing subscribers migrated by cohort with a communicated re-authorization flow.

Operational Impact

Maintenance

• Ongoing cost is moderate and lumpy: quiet between Laravel majors, then a focused upgrade when the package tracks a new framework or API version. Budget one planned upgrade per year and pin the version in between.
• Internal maintenance is the abstraction layer plus the webhook handler — small surface, high leverage. Keeping business logic out of package specifics is the single highest-return maintenance decision.
• Documentation depth is thin relative to Stripe Cashier; expect to maintain an internal runbook rather than rely on external answers.

Support

• Commercial support flows through the Mollie merchant relationship (API, settlement, disputes), not the package. The GitHub repo is best-effort. Do not assume vendor SLA on the library itself.
• Escalation for billing correctness issues (a subscription that should have renewed and didn't) lands on our on-call, not the vendor. Plan for that.

Scaling

• Volume is bounded by Mollie's API rate limits and our webhook processing throughput. Queue-based handling scales horizontally; the constraint is usually the renewal burst at month boundaries and the retry storm after a partial outage.
• Data growth is linear in payments/subscriptions; the package's tables are conventional and index-friendly, but reconciliation queries against payments will need attention past low millions of rows.
• Multi-region/multi-entity billing (different legal entities per market) is not a package concern and would require custom work.

Failure modes to design for

• Missed or duplicate webhooks → subscription state drift, double-provisioning. Mitigate with idempotency keys on resource IDs, a reconciliation job that polls Mollie for non-terminal subscriptions, and dead-letter alerting.
• Mandate revocation / SEPA failures / insufficient funds → silent churn. Requires an explicit dunning sequence and customer-facing recovery flow; Mollie will not do this for you.
• Mollie API outage or deprecation → checkout unavailability and renewal delays. Degrade gracefully (queue renewals, surface status), and track deprecation notices.
• Test/production key leakage → charges against real cards in staging, or silent no-ops in prod. Enforce environment guards and startup assertions.
• Currency or payment-method mismatch at checkout → conversion loss discovered only in analytics. Add per-method funnel monitoring.
• Upgrade-induced breakage on a framework bump → catch via contract tests against the test API in CI.

Ramp-up

• Engineers fluent in Stripe Cashier will need 1–2 sprints to internalize Mollie's customer/mandate/subscription model and the thin-webhook pattern. The API is simpler than Stripe's but differently shaped, which is where mistakes happen.
• Product/Finance need onboarding too: settlement timing, payout reconciliation, refund and dispute handling all live in the Mollie dashboard with a different mental model than Stripe.
• Recommended ramp assets: a one-page model diagram (customer → mandate → subscription → payment), the webhook runbook, and a parity checklist of features we intentionally do not have.

TPM bottom line: a defensible, low-friction bet for an EU-focused Laravel product with EUR subscriptions and a tolerance for a thinner feature surface; a poor fit for global, multi-currency, or invoice/tax-heavy billing, and an expensive migration for existing Stripe subscribers. Approve conditional on a one-week spike that closes the parity checklist and confirms the laravel/cashier coexistence question.