Calculateur d'intérêts du prêt

Un taux négatif ou une durée négative est rejeté avec invalid_input au lieu d'un coût négatif absurde.

Contrat d'entrée, formule de la mensualité et champs de réponse

Une durée négative est rejetée de la même manière. Les champs de style monétaire utilisent un arrondi half-up à deux décimales. Envoyez par POST un corps JSON avec trois nombres finis obligatoires. principal est le montant emprunté, supérieur à zéro, avec les alias amount et loan_amount afin que les tableurs gardent des noms de colonnes familiers. annual_rate est le pourcentage annuel nominal —six signifie six pour cent par an, non un décimal 0.06— et les alias rate, interest_rate et apr désignent le même champ. Si annual_rate est négatif, la tâche échoue avec invalid_input en nommant le champ ; c'est une erreur contractuelle et elle n'est pas facturée. term_years est la durée en années, supérieure à zéro et au plus cinquante, avec les alias term et years. Le moteur forme payment_count comme term_years fois douze et exige que ce produit soit un nombre entier de mensualités, si bien qu'un titre de cinq ans fait soixante versements et un de six mois en fait six, tandis qu'une durée qui ne tombe pas sur un mois entier est rejetée avec un message clair. Le taux périodique r est annual_rate sur cent divisé par douze. Lorsque r est zéro, chaque paiement est principal divisé par payment_count et le total des intérêts est zéro. Lorsque r est positif, payment égale principal fois r fois (un plus r) élevé à n, divisé par (un plus r) élevé à n moins un, avec n égal à payment_count. total_paid est payment fois n ; total_interest est total_paid moins principal. Les sorties répètent aussi principal, annual_rate, term_years, monthly_rate, payment_count, monthly_payment et une courte chaîne formula. Champs absents, nombres non finis, principal non positif et une durée qui n'est pas un nombre entier de mois échouent avec invalid_input et ne sont pas facturés.

Où une API d'intérêts du prêt trouve son utilité

Les pages de finances personnelles qui se classent sur intérêts du prêt ont besoin d'un chiffre en direct du coût sur la vie du crédit à côté de la mensualité, pour que le visiteur voie pourquoi une durée plus longue peut paraître moins chère mois par mois et coûter pourtant davantage. Conseillers et coachs parcourent le taux ou la durée entre offres concurrentes et les classent par total d'intérêts plutôt que par la seule échéance. Cette page n'est pas une identité d'intérêt simple, ni un outil de croissance composée de l'épargne, ni une page EMI qui met en avant la mensualité d'un logement ou d'une voiture : ces requêtes ont déjà leur propre contrat. L'outil n'émet pas d'échéancier période par période, d'impôts, d'assurances, de points ni de trajectoire à taux variable : seulement l'intérêt mensuel à taux fixe sur la vie du prêt et les totaux liés issus de l'échéance en forme fermée. Places de marché et originateurs préremplissent des calculateurs depuis des formulaires de devis et ont besoin d'un endpoint parse déterministe qui coïncide avec les amortissements de tableur sans dresser un cœur bancaire. Les salles de classe qui enseignent l'amortissement peuvent confronter total_interest à des cas de manuel et à des goldens arrondis stables. Parce que l'implémentation est parse pure de palier A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle et sans réseau sortant, et une validation échouée ne consomme pas de solde. Parcourez term_years ou annual_rate en boucle depuis votre propre code pour construire des tableaux de comparaison ; figez monthly_payment et total_interest dans les tests ; et gardez les requêtes petites.