Weave Code
Laravel Mollie Billing Laravel Package
graystackit/laravel-mollie-billing
Batteries-included Mollie billing for Laravel with VAT/OSS compliance, wallet-based metered billing, coupons, scheduled plan changes, trials, an admin panel and a Livewire 4 customer portal, all keyed off a Billable contract.
Batteries-included Mollie billing for Laravel: VAT/OSS compliance, wallet-based metered billing, coupons, scheduled plan changes, trial flow, admin panel and a Livewire 4 customer portal.
Frequently asked questions about Laravel Mollie Billing
- How do I install graystackit/laravel-mollie-billing in a Laravel app?
- Install it with composer require graystackit/laravel-mollie-billing, then publish the config, migrations, views and language files and run the billing:check-config command to validate your setup. After that you mount the package's route groups with their own middleware scopes and wire the facade resolution layer (resolveBillableUsing, authUsing, urlParametersUsing) in AppServiceProvider. The package assumes Laravel 12 or 13 and pulls in mollie/laravel-mollie ^4, bavix/laravel-wallet and mpociot/vat-calculator.
- Which Laravel versions does laravel-mollie-billing support?
- The package requires Laravel 12.x or 13.x together with Livewire 4, and there is no older LTS branch listed. There is no backport path for Laravel 10 or 11, so you need to already be on a very current stack. If you are still on an LTS release, plan the framework upgrade before adopting it.
- Can I bill individual users instead of organizations with this package?
- The package is deliberately opinionated: it expects the billable to be a tenant such as an Organization, with a Billable contract and HasBilling trait on that model rather than on User. Teams running a tenant-per-organization SaaS will recognise the shape immediately, but billing individual users or supporting multiple billables per user means fighting the contract from day one. Check your domain model before installing, because retrofitting a different billable shape later is painful.
- How does wallet-based metered billing work in this Mollie package?
- Metered usage is powered by bavix/laravel-wallet, so usage is tracked in wallets and overage is billed against the stored balance, including past_due retry handling. Because the wallet library is not hidden behind package-owned interfaces, you inherit its data model and upgrade cadence. Budget time for reviewing bavix/laravel-wallet releases alongside the package's own.
- How does VAT, VIES validation and OSS export work?
- VAT is calculated through mpociot/vat-calculator, with VIES validation for B2B reverse-charge and an OSS export for EU reporting. At every recurring payment the package reconciles user-declared, payment-derived and IP-derived country; a mismatch sets the subscription to cancel-at-period-end, emails the billable and offers a self-correct refund-and-reissue flow. Note that the OSS export is EU-centric and currency is set via BILLING_CURRENCY, so non-EU sellers should verify scope first.
- Do I need Flux Pro for the customer portal and admin panel?
- Yes. The Livewire 4 single-file-component customer portal and the admin panel are hard-coupled to Flux Pro, a commercial closed-source component library that Composer does not install. That makes it a licensing and procurement dependency as well as a technical one, so confirm you have Flux Pro licences before promising those screens. The package also ships no compiled assets, so you must add a Tailwind @source entry for the vendor views or the portal will render unstyled in production.
- How do I configure routes and webhooks so queued Mollie callbacks work?
- Route registration is split: checkoutRoutes() must sit outside the tenant prefix because the tenant does not exist yet at checkout, while routes() lives inside it. PropagateRouteDefaults handles request-scoped URL generation, and urlParametersUsing covers webhooks, queues and jobs, which is the two-mechanism URL story that often passes in dev but breaks in a queued Mollie webhook. Test a real queued webhook against a tenant-scoped route before going live.
- What are billable_key_type and user_key_type and why do they matter before migrating?
- Set billable_key_type and user_key_type correctly before the first migration. The package rewrites polymorphic columns across its own tables plus bavix/laravel-wallet's wallets.holder_id, transactions.payable_id and transfers.from_id and to_id. Changing them after data exists means manual column surgery on third-party tables, so do not prototype with defaults you have not confirmed.
- How do I test this billing package safely before production?
- The repository includes a CI test workflow, a changelog, tagged releases and the billing:check-config validator, which together suggest an author who has shipped this pattern before. There is, however, no public evidence of third-party production deployments, so treat your own staging environment as the real test bed. Exercise VAT classification, refund-and-reissue and past_due overage retry paths explicitly, since those are money-and-compliance surfaces where a subtle bug is a liability rather than a support ticket.
- Is laravel-mollie-billing production-ready and how does it compare to alternatives?
- First, ask the maintainer whether any live deployment runs this or whether it is a first-party extraction, and who else is using it. The package has one star, zero dependents and a single-org namespace, so you would be among the first integrators and you will find the edge cases. If you need a battle-tested, community-proven path today, weigh that against the built-in VAT/OSS handling, wallet metering and portal UI you would otherwise have to build yourself.
Weaver
How can I help you explore Laravel packages today?