Calculateur d'utilisation du crédit

Un plafond de crédit total égal à zéro est rejeté avec invalid_input et n'est pas facturé, car diviser par zéro ne définit pas un taux d'utilisation.

Ce que signifie l'utilisation du crédit et comment les deux totaux deviennent un pourcentage

En symboles, utilization_ratio est égal à total_balance divisé par total_credit_limit, et utilization_percent est ce rapport multiplié par cent. Une carte inutilisée avec un solde de zéro et un plafond de quatre mille élargit encore total_credit_limit et abaisse le pourcentage global ; fermer cette carte plus tard peut faire monter l'utilisation du jour au lendemain même si vous n'avez rien emprunté de nouveau. Une vérification résolue est un solde combiné de deux mille sur un plafond combiné de six mille : le rapport est un tiers et utilization_percent vaut environ 33.33. Cela se situe juste au-dessus de la consigne habituelle de 30 pour cent que beaucoup de conseillers citent avant une enquête hypothécaire. Lorsque le solde combiné dépasse le plafond combiné, le portefeuille est hors plafond, le pourcentage passe au-delà de cent, available_credit vaut zéro et over_limit_amount enregistre l'excédent.

Contrat d'entrée, forme de la réponse et comportement d'erreur

Envoyez par POST un corps JSON avec deux nombres finis obligatoires. total_balance est le solde revolving impayé combiné dans une seule unité monétaire ; les alias balance, balances, total_balances et outstanding pointent vers le même champ afin qu'un extrait de relevé conserve les noms de colonnes. total_credit_limit est le plafond de crédit revolving combiné dans cette même devise ; les alias credit_limit, limit, total_limit et creditLimit sont acceptés. Chaque champ numérique peut arriver comme nombre JSON ou comme chaîne numérique. Les champs absents, les chaînes vides et les valeurs non finies échouent avec invalid_input en nommant le champ. total_balance doit être supérieur ou égal à zéro : un solde nul est un cas légitime de crédit inutilisé et renvoie un utilization_percent de zéro plutôt qu'une erreur. Un solde négatif est rejeté. total_credit_limit doit être strictement supérieur à zéro. Un solde supérieur au plafond est autorisé : le portefeuille est hors plafond, utilization_percent dépasse cent, over_limit vaut true, available_credit vaut zéro et over_limit_amount enregistre le surplus au lieu de plafonner le pourcentage. En cas de succès, le corps répète les deux totaux arrondis half-up à deux décimales, puis indique utilization_ratio arrondi à six décimales, utilization_percent arrondi à deux, available_credit, over_limit_amount, le booléen over_limit et une chaîne de formule qui réaffirme l'identité. Exemple : deux mille de soldes combinés sur un plafond combiné de dix mille donnent une utilisation de vingt pour cent, huit mille de crédit disponible et over_limit false. Associez le JSON à votre propre liste des comptes que vous avez additionnés : ce point d'entrée divise les deux nombres que vous envoyez ; il ne tire pas un fichier de bureau, n'âge pas un score et ne reconstruit pas de lignes par carte.

Où un calculateur d'utilisation du crédit gagne sa place

Les conseillers en crédit et les coachs d'organismes à but non lucratif utilisent le point d'entrée à deux nombres lorsqu'un client a déjà les totaux du relevé sous la main et ne veut que le pourcentage, la marge restante et si le portefeuille est hors plafond, sans saisir chaque carte. Cet outil ne tire pas un rapport de crédit, n'âge pas un score de type FICO et ne modélise ni les lignes d'utilisateur autorisé, ni les passages en pertes, ni l'écart entre les soldes de relevé déclarés et le solde en direct d'aujourd'hui. Associez-le à votre propre extrait de bureau lorsque la question est ce que les bureaux voient déjà, et utilisez ce calculateur lorsque la question est ce que deux totaux revolving connus impliquent maintenant. Les unités de préparation aux examens et de cours ont besoin d'un oracle déterministe qui traite un plafond zéro comme invalid_input plutôt que comme une division par zéro, autorise des pourcentages hors plafond au-delà de cent et renvoie à la fois le rapport et le pourcentage. Comme l'implémentation est parse pure de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant, et une validation échouée ne consomme pas de solde. Gardez les requêtes petites et figez utilization_percent plus available_credit dans les tests. Conservez total_credit_limit strictement positif, envoyez les deux nombres dans une seule devise, et vous obtenez un pourcentage d'utilisation reproductible pour les pages d'atterrissage, les greffons LMS et les workers de bord sans monter un moteur par carte à vous.