Simple mortgage calculator

A term that is not positive fails with invalid_input instead of inventing a schedule.

What a simple mortgage monthly payment means and how the amortizing formula works

The monthly rate r is the annual percent divided by twelve hundred: r equals annual_rate divided by twelve divided by one hundred. The number of payments n is term_years times twelve, because mortgages are quoted in years and repaid monthly. When r is greater than zero the closed form is monthly_payment equals P times r times (1 plus r) to the n, divided by (1 plus r) to the n minus one. That identity is the standard amortizing installment lenders publish for conventional mortgages: each installment covers interest on the outstanding principal first, then reduces the balance, so the interest share falls and the principal share rises even though the cash payment never changes. When the annual rate is zero the denominator would be zero, so the calculator switches to the honest special case monthly_payment equals P divided by n, which is how genuine interest-free notes and some seller-financed contracts are billed.

Input contract, the positive-term rule, and the response shape

Fractional years are accepted when they are still positive, so a five-and-a-half-year remaining term can be priced without rounding it to an integer first. POST a JSON body with three required fields: principal, the financed amount as a finite number strictly greater than zero (aliases amount and loan_amount); annual_rate, the annual nominal interest as a percent such as 6.5 for six and a half percent per year, finite and at least zero (aliases rate and interest_rate); and term_years, the term as a positive finite number of years up to fifty (aliases term and years). Each numeric field may arrive as a JSON number or as a numeric string. Missing fields, empty strings, non-finite values, a non-positive principal, and a negative annual_rate fail with invalid_input naming the field and are not billed. The distinctive product rule is the term: term_years must be positive. Zero, a negative number, a boolean, or a non-numeric string never produce a fake schedule, because a mortgage term that is not a positive span of years is not a valid simple mortgage. On success the body echoes principal, annual_rate, and term_years, and adds term_months (term_years times twelve), monthly_rate (annual_rate divided by twelve hundred), monthly_payment rounded to two decimals, and a formula string restating the amortizing identity and the zero-rate special case. Example: principal two hundred fifty thousand, annual_rate 6.5, term_years thirty yields a monthly rate of one twelfth of six and a half percent and a monthly payment rounded to two decimals. Pair the figure with your own tax and insurance table; this endpoint computes installment math only and does not emit an amortization schedule row by row.

Where a simple mortgage calculator earns its keep

Educators teaching amortizing versus interest-only mortgages can seed classroom examples that fail loudly when the term is not positive, instead of silently treating a zero-year note as a valid mortgage. Remaining-term what-ifs that use a fractional year, such as a refinance with five and a half years left, stay inside the same contract because the term rule is positivity, not an integer constraint. Failed validation, including a term that is not positive, does not consume balance. Quote tools and origination CRMs can call the same pure module from the browser for free previews and from the API when storing a scenario, guaranteeing that the monthly payment a visitor saw matches the monthly payment stored after they save a quote. Affordability worksheets already know the financed amount; posting principal, annual_rate, and term_years fills a card with the principal-and-interest installment so a counselor can see whether a thirty-year quote is cheaper in cash each month than a fifteen-year note at a higher monthly hit. Content teams can illustrate zero-percent seller financing with annual_rate zero, where monthly_payment collapses to principal over term_months without a divide-by-zero. Keep principal strictly positive and term_years a positive span of years, pin the rounded money fields in tests, and you get reproducible simple-mortgage payments for widgets, LMS modules, and edge workers without a loan-origination stack of your own.