Nova Mollie Tool Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel Nova tool (a first-class Nova extension type: a PHP service provider plus a compiled Vue SPA mounted at a Nova route). It only makes sense inside a Laravel application that already licenses Nova. If the target stack is Laravel without Nova, or an Inertia/Livewire admin panel, the package has no delivery surface at all. Architecturally, this is a read-only dashboard over Mollie transaction data — it does not change application state, does not participate in the payment flow, and does not belong in a critical request path. That is a favorable risk profile for what is essentially observability tooling for finance/ops staff.

Integration feasibility: low, trending to not viable as-is. The last release is dated 2018-08-26, which is pre-Nova-2. Nova's tool API and front-end plumbing have been rewritten since (notably the move to Inertia in Nova 4), and the Mollie PHP client has moved to the v2 Mollie\Api\MollieApiClient under mollie/mollie-api-php. A 2018 Nova tool almost certainly targets the now-removed v1 client and the legacy Nova 1.x asset/mixin conventions. Realistically this is a reference implementation to read, not a dependency to install.

Technical risk. High and concentrated:

• Credential handling. Any Mollie integration needs a live API key. Payment-provider keys displayed or proxied through a UI component are a privileged-secret exposure; the package's approach here must be audited line by line before it touches production keys.
• Abandoned dependency surface. Unpinned transitive dependencies from 2018 are a supply-chain and CVE problem, and Composer will likely refuse or force awkward overrides on modern PHP.
• Read-only blast radius. Mitigating factor: because it only reads transactions, a failure degrades visibility rather than breaking checkout. It cannot double-charge a customer.
• 10 stars. No meaningful user base, no issue triage, no one to ask.

Key questions for the maintainer/owner.

1. Which Nova major version and Laravel/PHP version was this built and last verified against?
2. Which Mollie client version, and does it authenticate with an organization token, a profile key, or a live key?
3. Where are the API credentials stored and are any ever rendered client-side?
4. Does it read from Mollie's live API, or from locally persisted/webhooked transaction records?
5. Is there any pagination, rate-limit handling, or caching?

Integration Approach

Stack fit. Laravel + Nova + the Mollie PHP SDK. Three version couplings must all line up, and the 2018 release will satisfy at most the oldest combination. Concretely: Nova 1.x-era tool code will not boot on Nova 4/5; the Mollie v1 client is dead; PHP 8.x strictness will surface type and dynamic-property errors throughout.

Recommended migration path — rebuild, don't upgrade. Treat the repository as a specification. Two credible targets:

• Nova 4/5 tool, rebuilt from the current Nova tool generator (php artisan nova:tool), reusing only the UI intent: a paginated transaction table with status, amount, method, and consumer.
• Plain Laravel controller + Blade/Livewire page, if the organization would rather not pay the Nova tool tax or wants a narrower surface.

Either way, bind the modern mollie/mollie-api-php client as a singleton, inject it, and hit $mollie->payments->page(). That is a small rewrite — days, not weeks.

Compatibility. Assume zero compatibility with anything shipping today. Budget for: Nova version alignment, Mollie SDK v2, PHP 8.1+, and Composer resolution of any leftover 2018 constraints (drop them; do not try to satisfy them).

Sequencing.

1. Audit the source for credential handling and confirm no client-side secret exposure — this is the gate, before anything else.
2. Stand up a read-only sandbox key against a test Mollie account.
3. Rebuild as a Nova tool (or plain page) against the current SDK; keep it read-only, add pagination and caching.
4. Verify against real transaction shapes: refunds, chargebacks, expired and canceled payments, multi-currency.
5. Wire access behind Nova authorization gates so only finance/ops roles see it.
6. Retire the fork's coupling to the original package — vendored or internal namespace only.

Operational Impact

Maintenance. Effectively unmaintained upstream. The realistic operating model is "we forked it, we own it." For a read-only viewer that's a tolerable burden — perhaps a few hours a year — but it must be an explicit, named owner, not an implicit expectation that the 10-star repo will resurrect.

Support. None. No vendor, no community depth, no SLA, and the original author's availability in 2026 is unknown. Every question goes to the internal owner.

Scaling. Two constraints matter: Mollie API rate limits and payload volume. If the tool queries Mollie live on every table load (likely), a busy merchant account with tens of thousands of payments will be slow and will burn rate-limit budget during incident retros — exactly when finance needs it most. Recommend a local mirror (webhook-persisted payment records) or aggressive TTL caching of list pages. The Nova UI itself scales fine for page sizes of 25–100.

Failure modes to instrument and document.

• Expired/rotated API key — silent empty table, misread as "no transactions." Surface auth errors explicitly.
• Mollie API version change — response shape drift breaks the table with no upstream fix.
• Rate limiting — 429s during high-traffic periods; need backoff and a clear UI message.
• Composer/PHP upgrade — the package blocks Laravel upgrades if left as a dependency; keep it internalized to avoid being a version ceiling.
• Data staleness — if mirrored, reconciliation drift between the tool and Mollie's dashboard; state clearly that Mollie is source of truth.

Ramp-up. Low for a Laravel developer who knows Nova (a day to understand, days to rebuild). The real ramp-up is finance-domain, not technical: whoever builds it must understand Mollie's payment and settlement semantics well enough not to misrepresent a pending or refunded payment. Budget a short review with finance/ops to agree on which fields and statuses actually matter before rebuilding — the 2018 tool's field choices are a starting guess, not a requirement.

Bottom line. Do not install. Read it, extract the UI intent, and rebuild against modern Nova and the Mollie v2 SDK behind an authorization gate. The domain is low-risk and read-only, the rewrite is small, and the alternative — carrying an eight-year-old payment-adjacent dependency with 10 stars and no maintainer — is the only genuinely unacceptable option.