Financial Laravel Package

Product Decisions This Supports

• Feature scoping for payment-quote surfaces. The only capability here is the Excel PMT function (fixed-rate, fixed-term periodic payment). That maps directly to: EMI/loan-payment calculators, lease and financing quote widgets, pricing-page "from $X/month" previews, and internal deal-desk tooling.
• Build vs. buy — and the answer is build. At 1 star, 0 dependents, and a last release of 2018-12-06, this is not a vendor relationship; it's a code snippet with a composer.json. The formula is roughly three lines of arithmetic plus a zero-rate guard. The adoption cost (supply-chain review, wrapping, testing, owning a dead dependency) exceeds the build cost.
• Roadmap signal, not a dependency. The package advertises "more functions will be implemented in the future" but hasn't shipped since 2018. Do not plan any roadmap item — amortization schedules, APR, IPMT/PPMT, RATE, NPER, IRR/XIRR, NPV — on the assumption this library grows into it. It won't.
• Use cases this legitimately unblocks in a spike: validating a payment estimate before you commit to a real amortization engine; prototyping a quote calculator; replacing a fragile spreadsheet export in an internal tool.
• Recording a "no" is a valid decision artifact. Log the evaluation with the criteria below so the next PM doesn't re-litigate a 1-star, 7-year-stale package.

When to Consider This Package

Adopt only if all of the following hold:

• You need PMT and nothing else — no schedule generation, no principal/interest split, no rate solving.
• You are comfortable vendoring or copying the single class into your own namespace rather than depending on it via Composer, so a future break is a one-file fix.
• You will wrap it behind your own PaymentCalculator interface with your own tests and swap it out freely.
• Your amounts and rates are display-only estimates, not billing-grade figures.

Look elsewhere (or build in-house) when:

• You need more than PMT. IPMT, PPMT, RATE, NPER, FV, IRR, XNPV are all out of scope. phpoffice/phpspreadsheet is the pragmatic choice if Excel parity across many functions is the actual requirement.
• Money precision matters. PMT on floats drifts. For anything that touches invoices, ledgers, or stored amounts, compute in integer minor units — brick/money — and round with an explicit, tested policy.
• You need compliance-grade amortization (APR disclosure, Reg Z, French/Dutch amortization schedules, day-count conventions). A 1-star, single-author, unmaintained package is not the substrate for a regulated calculation.
• You need support, CVE response, or a maintenance commitment. None exist here.
• You're on a modern PHP version and want a guaranteed-compatible, tested dependency. There is no CI signal, no dependents exercising it, and no release in seven years.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source library for payment calculations. It does exactly one thing — Excel's PMT — has one star, zero downstream users, and hasn't been updated since 2018. Taking it as a dependency would add supply-chain and maintenance risk for a capability we can own in about twenty lines of tested code. Recommendation: do not adopt; build the calculation in-house behind an internal interface so we can extend to amortization schedules later without a migration. No cost, no vendor lock-in, no unmaintained code in our stack.

To engineering: Skip the dependency. Extract the PMT formula into a Finance\Payment value object, guard the zero-rate branch (the formula degenerates when r = 0), pin the sign convention, and round to minor units explicitly rather than trusting float output. Property-test against known Excel results across representative rate/term/principal combinations. If we later need IPMT/PPMT/RATE/IRR, we evaluate phpspreadsheet or extend our own module — not this package.