Cash back calculator

A negative reward percentage is rejected as invalid_input and is not billed.

How cash back turns spend and a reward percent into money

Cash back is the share of a purchase that a rewards program returns as money rather than as miles or merchandise. A two-percent grocery card on a two-hundred-fifty spend returns five; a one-and-a-half-percent rotating category on one hundred twenty-three dollars and forty-five cents returns one dollar and eighty-five cents after ordinary money rounding. Amount is the purchase spend in one currency; percent is the advertised reward rate typed the way issuers print it on marketing pages, so two means two percent, not two hundred percent. Zero percent is a legitimate outcome and returns zero cash back rather than an error: a category with no bonus still belongs in a comparison. You supply both numbers; the calculator multiplies them and rounds the cash-back amount half-up to two decimal places so goldens compare byte-for-byte across runtimes. The identity this calculator uses is cash_back equals amount times percent divided by one hundred. The decimal form of that rate is also returned as rate_decimal so a spreadsheet can keep a fraction next to the percent people type. Net cost is the spend after subtracting the cash-back amount: it is what the purchase effectively costs if the reward posts as a statement credit. A negative reward percentage is not a rebate in this contract and is rejected as invalid_input, because a rewards table that prints a minus sign is almost always a data error, not a fee you meant to model. This endpoint does not look up issuer category lists, does not convert currencies, does not split a basket across rotating five-percent caps, and does not time when the credit posts. A promotional one-hundred-percent match is allowed and then cash_back equals amount and net_cost is zero.

Input contract, response shape, and error behaviour

POST a JSON body with two required finite numbers. amount is the purchase spend in one currency unit; aliases spent, purchase, purchase_amount, and spend map to the same field so a statement export can keep its column names. percent is the reward rate as a percentage, not a fraction: two means two percent, five means five percent; aliases rate, reward_percent, cash_back_rate, and reward_rate are accepted. Each numeric field may arrive as a JSON number or a numeric string. Missing fields, empty strings, and non-finite values fail with invalid_input naming the field. Zero percent is valid and returns cash_back of zero. On success the body echoes amount rounded to two decimal places and percent, then reports rate_decimal as percent divided by one hundred, cash_back as the earned reward rounded to two decimal places, net_cost as amount minus cash_back, and a formula string restating the identity. Example: two hundred fifty of spend at two percent yields cash_back of five and net_cost of two hundred forty-five. Pair the JSON with your own rule for which purchases share a rate—groceries, gas, or a flat everything rate—because this endpoint multiplies the two numbers you send; it does not assign a merchant category, apply a quarterly cap, or convert currencies. Keep requests small, pin the rounded cash_back in tests, and you get a reproducible reward figure for worksheets, LMS plugins, and edge workers without standing up a card-rewards engine of your own.

Where a cash back calculator earns its keep

Households comparing a two-percent flat card against a rotating five-percent category use a cash back calculator to turn last month's grocery or gas spend into one comparable dollar figure before they apply. Cash back prices one spend against one reward percent and returns money. Failed validation does not consume balance. Quarterly bonus caps, foreign-transaction fees, and annual fees stay outside this identity on purpose: fold them in your own layer after you have the raw cash-back dollars. Budgeters drop a planned purchase amount and the published percent, then pin net_cost so the rest of the month's envelope already reflects the statement credit they expect. Product teams wire the same contract into offer pages and onboarding quizzes that must show cash_back for a sample basket without calling an issuer API. This is a different search and a different job from sales tax, from a rule-of-seventy-eight loan rebate, and from travel points value: those tools add a tax on a subtotal, rebate prepaid interest on an installment loan, or convert award miles into cents per point. Keep percent non-negative, pin the rounded cash_back in tests, and you get a reproducible reward amount for teasers, statement checks, and edge workers without standing up a rewards ledger of your own.