Credit card payoff math
The Credit Card Payoff Calculator is three small functions
in the site's credit engine: cardPayoff, which counts the months a fixed payment
takes to clear a balance; cardPaymentForMonths, which solves for the payment that
clears it by a chosen month; and balanceTransfer, which runs the same fixed payment
down two paths and reports the cost of each. This guide walks through what each one computes,
where it stops, and how to read what it returns.
Every figure below is computed when the page is built, by the same engine that runs in your browser, from inputs invented for the examples and labelled as such — chiefly one fictional card: a $4,800 balance at 21% APR. None of the inputs is a quote or a typical figure; they are chosen to make the arithmetic visible. If the copy and the code ever disagreed, the site would fail to build. The guides index covers the rest of the engine.
The convention: APR ÷ 12, one month at a time
Everything here rests on one convention: interest accrues monthly at the card's APR divided by twelve, on whatever balance remains. For the example card the monthly rate is 21% ÷ 12, and the first month's interest is the balance times that rate — $84.00.
cardPayoff runs a loop. Each month it computes interest on the remaining balance, adds
it to the balance, subtracts the fixed payment, and counts the month, until the balance is cleared,
to the engine's tolerance. Nothing is rounded between months: the engine keeps the full precision
of IEEE-754 double-precision arithmetic and rounds only when a figure reaches the screen. The result
carries three fields — months, totalInterest and totalPaid — and
totalPaid is the original balance plus the interest, not months multiplied by the payment,
because the final month only pays what is left.
The balance is treated as frozen: the model has no input for new purchases, and it holds the payment fixed from the first month to the last. It also compounds monthly rather than daily. Card issuers typically accrue interest daily on your average balance, which compounds slightly faster than the monthly model used here.
Worked example: a fixed payment
Example: $4,800 at 21% APR, paying $160 a month.
43 months (3 yr 7 mo), $2,065.81 of interest, $6,865.81 paid in all.
In the first month, $84.00 of the $160 is interest, so only the remainder reduces the balance. In the second month the balance is smaller, the interest on it is smaller, and a little more of the same payment reaches the balance. That shift repeats every month, which is why the balance falls slowly at first and quickly at the end — the mechanism of a loan's amortization schedule, with the payment chosen by you rather than solved by a formula.
Why a payment near the interest floor takes so long
The first month's interest is the floor. A payment at or below it can never reduce the balance, so the engine refuses it, because the balance would never fall and any month count it returned would be meaningless. Asked to apply $80 a month to the example card, it returns its own message, produced here at build time:
That payment never pays the card off — the first month's interest alone is more. Pay more than $84.00 per month.
Just above the floor the arithmetic is valid but slow. At $95 a month, only the part of each payment above the interest charge touches the balance, and the engine counts 125 months (10 yr 5 mo) and $7,006.18 of interest. The same card at five fixed payments:
| Monthly payment | Months | Payoff time | Total interest | Total paid |
|---|---|---|---|---|
| $95 | 125 | 10 yr 5 mo | $7,006.18 | $11,806.18 |
| $120 | 70 | 5 yr 10 mo | $3,528.09 | $8,328.09 |
| $160 | 43 | 3 yr 7 mo | $2,065.81 | $6,865.81 |
| $240 | 25 | 2 yr 1 mo | $1,159.72 | $5,959.72 |
| $320 | 18 | 1 yr 6 mo | $817.07 | $5,617.07 |
The relationship is not linear. Doubling the payment from $160 to $320 takes the count from 43 months to 18 and the interest from $2,065.81 to $817.07, because every extra dollar lands on the balance at once and leaves less for the next month's interest to accrue on. The engine has no notion of a minimum payment recalculated from the balance each month; it takes one amount and holds it.
Solving for the payment instead
cardPaymentForMonths answers the reverse question: given the balance, the APR and a number
of months, what fixed payment lands on zero in exactly that month? It does not loop. It uses the standard
annuity formula on the card's monthly rate — the same formula behind the site's loan payments. For
the example card it returns $446.95 a month to clear in 12 months, $246.65 for 24 and $180.84 for 36.
The two functions agree with each other: feed the 24-month payment back into
cardPayoff and it reports 24 months with $1,119.63 of interest. They also agree with the mortgage engine, because the formula is the same. The methodology
page's reference loan — $200,000 at 6% over 30 years — gives $1,199.10 through monthlyPayment, and the same principal and rate over 360 months
through cardPaymentForMonths gives $1,199.10.
One special case is coded explicitly. At a 0% APR the formula would divide by zero, so the engine divides the balance evenly across the months instead: $200.00 a month over 24 months for the example balance.
Balance-transfer arithmetic
balanceTransfer runs two payoffs with the same fixed payment and puts the costs side
by side. The stay path is cardPayoff on the current card, unchanged. The transfer path first adds the transfer fee — a percent of the balance moved — to the balance itself, so the
payments during the introductory months are clearing the fee as well as the balance; whatever is left
when the intro period ends accrues interest at the post-intro APR ÷ 12. For the intro months the monthly
rate is zero, and the loop is otherwise the one described above.
The result reports each path's cost beyond the balance itself — stayCost, the
interest on the current card, and transferCost, the fee plus the post-intro
interest — and
savings, which is stayCost minus transferCost. A negative
savings comes with a flag, feeExceedsBenefit, so the sign of the
comparison is never hidden inside a rounded total.
Example: the $4,800 card at 21% moved onto a fictional offer with a 4% fee, 12 months at 0% and 19% after that, paying $160 a month on either path.
Fee: $192.00. Staying costs $2,065.81 of interest over 43 months. The transfer path clears in 36 months with $619.20 of post-intro interest, for a transfer cost of $811.20.
savings = $1,254.61
Change the inputs and the sign can flip. A second fictional card — $1,500 at 15%, paid at $400 a month — clears in 4 months with $46.17 of interest where it is. On an offer with a 4% fee, 6 intro
months and 19% afterwards, the fee is $60.00, the
transfer path takes 4 months and pays $0.00 of interest,
and savings comes out at -$13.83 with
feeExceedsBenefit set to true. The
engine reports the figure and its sign; it draws no conclusion from either.
Where the engine stops
Every function validates its inputs and returns an explicit, human-readable error instead of a number when a value is outside what it models. The messages below are the engine's own, produced at build time by inputs chosen to be refused:
- An APR above the supported range:
Enter an APR between 0 and 200 percent. - A target payoff time beyond the supported span:
Enter a payoff time from 1 to 600 months. - A transfer fee above the supported range:
Enter a transfer fee between 0 and 20 percent. - An intro period beyond the supported span:
Enter a 0% intro period from 0 to 60 whole months. -
A payment that covers interest during the 0% months but not afterwards — a $9,000 balance
with a 3% fee, 3 intro months, 24%
after that and $160 a month:
After the 0% period, that payment never clears the card — the monthly interest alone is $175.80. Pay more than that.
Beyond those checks, the model takes one fixed payment and a frozen balance, compounds monthly at APR ÷ 12, and knows no fee other than the transfer fee: there is no field for an annual fee, a late fee, or a rate that changes at any point other than the end of an intro period. Both payoff loops are bounded, and the transfer path returns an explicit out-of-range error at its bound.
How to read the output
- Months is a count of payments, including the final partial one; the calculator renders it as years and months — 43 becomes 3 yr 7 mo.
- Total paid is the balance plus the interest, usually less than the month count multiplied by the payment, because the last payment is only what remained.
- Interest is the sum of each month's charge at full precision, rounded to the cent on screen. A statement figure may differ by a few cents depending on the issuer's rounding and day-count conventions — the difference is presentational, not an error.
- Savings on a transfer is a signed difference between two costs under identical payments; a negative figure means the fee was larger than the interest the transfer avoided.
Frequently asked questions
Why does the engine refuse a payment at or below the first month's interest?
Because the balance would never fall: interest is the remaining balance times APR ÷ 12, and a payment no larger than that leaves the balance where it was, or raises it, so any month count the engine returned would be meaningless. For the example card the floor is $84.00.
Does the calculator model a minimum payment that shrinks with the balance?
No. cardPayoff takes one fixed monthly payment and holds it for every month of the payoff. A payment recalculated from the balance each month is outside the model; the calculator answers what a fixed amount does, and nothing else.
How is the balance-transfer fee treated?
It is a percent of the balance moved, added to the transferred balance before the first month, so the 0% months are clearing the fee as well as the balance. In the example, a 4% fee on $4,800 is $192.00.
Is cardPaymentForMonths the same formula as a loan payment?
Yes — the standard annuity formula on the monthly rate, the one monthlyPayment uses for mortgages and loans; the methodology page's reference loan returns $1,199.10 through either function. At 0% APR the engine divides the balance evenly across the months instead.
Why might a card statement differ from the calculator?
Two reasons, neither an error in the arithmetic. The engine compounds monthly at APR ÷ 12, while card issuers typically accrue interest daily on your average balance, which compounds slightly faster. And figures are rounded to the cent only on screen, so a statement can differ by a few cents depending on the issuer's rounding and day-count conventions.
Related tools and guides
- Credit Card Payoff Calculator — the three functions on your own inputs.
- Debt Payoff Calculator — several balances under the same monthly convention.
- Snowball vs avalanche, as the engine runs them — how the multi-debt engine orders payoffs and rolls freed minimums forward.
- All guides and the methodology page.
Not financial advice: a general educational explanation of the arithmetic, using monthly compounding at APR ÷ 12; card issuers typically accrue daily, which differs slightly. The calculator models the arithmetic; it does not know your lender's terms. Figures are kept at full precision internally and rounded only on screen, so a figure here and a figure on a statement can differ by a few cents through rounding alone — the difference is presentational, not an error. Values entered on the calculator are processed locally in your browser and never transmitted. See the methodology page.