Nova Mollie Tool Laravel Package

Getting Started

This package is a Laravel Nova navigation tool that renders a list of Mollie payments inside the Nova UI. It was released in August 2018, which places it in the Nova 1.x era (Laravel 5.6/5.7, PHP 7.1+, Vue 2, laravel-nova Mix helpers). Read it as a small reference implementation rather than a maintained dependency.

Minimal steps:

1. Confirm compatibility first. Check composer.json in the repo for the laravel/nova and mollie/mollie-api-php constraints before installing. On Nova 4/5 you will almost certainly need to fork or rewrite rather than composer require.

2. Install: composer require taronyuu/nova-mollie-tool

3. Locate the service provider and tool class in src/ (the 2018 nova:tool scaffold produces a ToolServiceProvider and a NovaMollieTool class). Register the tool in app/Providers/NovaServiceProvider.php inside tools():

   public function tools()
   {
       return [
           new \Taronyuu\NovaMollieTool\NovaMollieTool(),
       ];
   }
   

4. Publish config/assets if the provider exposes them:

   php artisan vendor:publish --provider="Taronyuu\NovaMollieTool\ToolServiceProvider"
   php artisan nova:publish
   

5. Set the API key the tool expects (MOLLIE_KEY or MOLLIE_API_KEY — verify the exact name in the config/README) in .env, starting with the test_ prefix so you don't leak live data into a dashboard.

First use case: log in to Nova as an admin, look for the "Mollie" item in the left sidebar, and confirm it lists your test-mode payments. If it renders an empty table, the key or the API call is the problem — not the UI.

Where to look first: the README's install steps, then src/ for the HTTP call to Mollie (that's the only non-scaffolding logic), then resources/js/tool.js / components/Tool.vue for the table.

Implementation Patterns

Nav tool, not a dashboard card. It registers via tools(), so it shows as a sidebar entry. If you want it on the dashboard instead, register the same component as a card in cards() and wrap it in a Metable/Card shell — or duplicate the Vue component.

Key management. Keep the Mollie key in .env and config only; never in the DB or committed config. Use separate keys per environment and gate the tool so only production admins see live data:

public function tools()
{
    return [
        (new \Taronyuu\NovaMollieTool\NovaMollieTool())
            ->canSee(fn ($request) => $request->user()->hasRole('finance')),
    ];
}

(canSee exists on modern Nova tools; on Nova 1.x you'll need to guard in the provider or component instead.)

Pair it with webhooks for anything real. Live-calling the Mollie API on every page load is fine for an internal convenience tool but terrible as a reporting layer. The robust pattern is:

• Add a payments table and a webhook endpoint that stores Mollie's id, status, amount, currency, method, paidAt, consumerName, and metadata.
• Then either point this tool's fetch at your local table (edit the tool's controller/component) or, more cleanly, build a Nova Resource over payments. You get filters, search, sorting, and export for free — which this tool does not provide.

Extend the Vue component rather than the PHP. The useful surface area is the table: add date-range filters, status badges, and a link to https://my.mollie.com/dashboard/.... Copy resources/js/components/Tool.vue into your app, register your own tool class pointing at your component, and override the original.

Multi-tenant / multi-key setups. If you have one Mollie account per tenant, don't fight the single global config — inject the key per request via a custom tool class and let the Vue side pass a tenant query param.

Gotchas and Tips

• Nova version drift is the headline risk. Nova 2/3 kept the tool scaffold but bumped Vue and Mix; Nova 4 replaced ToolServiceProvider with Nova::tools() registration and moved to Vue 3 + Vite. A 2018 package will not boot on Nova 4/5. Budget for a fork of ~200–400 lines rather than a fix.
• mollie/mollie-api-php major-version changes. v2 changed the client construction and method signatures versus v1. If Composer resolves an old constraint, the call in src/ may simply not match current docs. Cross-check the repo's composer.lock against the Mollie PHP docs.
• "Transactions" ≠ payments. The tool lists Mollie payments. Refunds, chargebacks, and settlements are separate API resources and won't appear. Don't use this for accounting reconciliation.
• Pagination. Mollie's payments endpoint is cursor-paginated (v2: from + _links.next). Naive implementations fetch only the first page (default ~50). If you see exactly 50 rows, that's the bug. Loop on _links.next or use iterator.
• Amounts are strings. Mollie returns {"value": "10.00", "currency": "EUR"}. Never cast to float for display math; format with number_format after parsing as a decimal string, and respect per-currency decimal rules.
• Latency and rate limits. API calls on page load will make the Nova dashboard feel slow and can hit 429s under load. Cache results for 1–5 minutes (Cache::remember) or, better, switch to the webhook-backed table above.
• API key debugging. If the table is empty or errors, test independently of Nova:

  curl -u test_xxxxxxxx: https://api.mollie.com/v2/payments?limit=5
  

  A 401 means the key; a 200 with data means the tool's request code is the problem. Check storage/logs/laravel.log — the 2018 code likely swallows exceptions into an empty array.
• Test vs live key confusion. test_ keys return test payments only; users frequently "lose" transactions because the key prefix changed on deploy. Echo the key prefix (never the full key) into the tool header for a quick sanity check.
• No authorization, no filters, no export. This tool gives you a read-only list. If your finance team actually needs it, wrap it in a Nova Resource. The tool is best treated as a scaffold example of how to call Mollie from Nova.
• Maintenance signal. 10 stars, last release 2018, and no updates since — treat this as a learning reference. Fork it, vendor the two files you actually need (tool class + Vue component), and own them in your app; don't depend on it transitively in composer.json for a production dashboard.