Laravel Mollie Billing Laravel Package

Product Decisions This Supports

• Build vs. buy vs. switch PSP. The package collapses subscription lifecycles, mandates, webhooks, proration, coupons, refunds, invoices, and a portal into an installable layer. The decision it informs: buy this layer, build on the raw mollie/laravel-mollie SDK, or move to an all-in-one merchant of record (Paddle/LemonSqueezy) that absorbs tax for you.
• EU market entry and tax compliance. This is the differentiator, not the Mollie plumbing. VAT calculation, VIES reverse-charge validation, and a three-way country reconciliation (declared vs. payment-derived vs. IP) with refund-and-reissue on correction are compliance work most teams discover mid-launch. It answers "can we sell B2C and B2B across the EU without hiring tax help or outsourcing VAT?"
• Pricing and packaging model. Wallet-based metered billing with included quotas and overage pricing supports a decision between seat-based, usage-based, or hybrid pricing without first building metering infrastructure. Five coupon types (SinglePayment, Recurring, Credits, TrialExtension, AccessGrant) plus signed promotion URLs let growth run discount, trial-extension, and comped-access campaigns without engineering cycles.
• Tenant-level billing architecture. The Billable contract living on Organization (not User) is an opinionated stance that matches how B2B SaaS is usually priced: per-company, seats counted from users. Adopting the package bakes that model into your data layer.
• Trial-to-paid funnel. Local-to-Mollie subscription conversion supports trials with no upfront payment method, then conversion — a meaningful conversion-rate lever.
• Self-service as a roadmap bet. Scheduled plan changes, end-of-period downgrades, proration, and the Livewire customer portal support a thesis that in-app upgrades and fewer support tickets beat white-glove billing ops.
• Buy-vs-fork risk. With one star and zero dependents, "adopt" and "vendor and own" are separate decisions worth making explicitly.

When to Consider This Package

Consider it when:

• You're on Laravel 12/13 and PHP 8.3+, and Mollie is already chosen or credible for your market (strong in Benelux/EU, thin elsewhere).
• You sell into the EU and do not want to own VAT/OSS, VIES, or country-mismatch logic.
• Your billable is a tenant/organization, not a user, and you need seats, quotas, or metered usage.
• You want a shipped customer portal and admin panel and are prepared to license livewire/flux-pro separately — it is required by the portal, checkout, and admin views, and is deliberately not bundled.
• You're a small team that prefers opinionated defaults over stitching together Mollie, bavix/laravel-wallet, mpociot/vat-calculator, and your own webhook handlers.

Look elsewhere when:

• You're US-centric or already standardised on Stripe/Paddle/LemonSqueezy. Trading PSP for a package's tax opinions is a bad deal.
• You need vendor assurance on something load-bearing. One star, zero dependents, and a single apparent maintainer is an unproven supply-chain dependency for revenue collection. Adopting means pinning, likely vendoring, and budgeting to own patches.
• You're not on Livewire 4 or don't want Flux Pro — you'd be buying a UI framework to use the billing core.
• Your billable is the User model, or you need marketplace/split-payment/per-line-item tax modelling this doesn't cover.
• Your primary key strategy isn't settled. billable_key_type and user_key_type must be set before the first migration; changing them later means hand-altering wallet tables.
• You need an SLA, security review, or support contract.

How to Pitch It (Stakeholders)

Executives. This is a buy-not-build accelerator for turning on subscription revenue in Laravel. The expensive, hard-to-hire part of EU billing is not the payment integration — it's VAT calculation, VIES validation, and keeping tax treatment correct when a customer's country, card, and IP disagree. This package ships that, plus trials, coupons, proration, refunds, credit notes, and a customer self-service portal, under MIT. Two costs come with it: a commercial Flux Pro license, and the fact that this is a young, single-maintainer, near-zero-adoption package. Recommendation: fund it as a one-to-two-week spike to de-risk EU VAT and metered billing, not as a strategic platform commitment, and assume we may fork it and own it.

Engineering. It's an opinionated layer over mollie/laravel-mollie v4, bavix/laravel-wallet, and mpociot/vat-calculator, with an audit trail stored as translation keys plus raw values (locale-safe history) and fully publishable Livewire SFC views. Adoption cost is real but bounded and mostly configuration: set the key types before the first migrate, mount webhook routes outside the web middleware group, keep checkout routes outside the tenant prefix, run billing:check-config, and make sure Tailwind scans the vendor views or the portal renders unstyled. The security-critical item is authUsing() — it must actually compare the billable to the requester, because the checkout route's query-parameter fallback otherwise lets ?organization=<other-tenant> disclose billing data. Plan to pin the version, write our own tests around auth boundaries and webhook idempotency, and add a Flux Pro license line item.