Double discount calculator

A discount that exceeds one hundred percent is rejected as invalid_input and is not billed.

How two successive discounts actually compound

Two successive percentage discounts are not the same as one combined percent. A retailer prints twenty percent off, then a coupon takes another ten percent off what is left; an employee extra sits on a clearance tag; a marketplace stacks a seller markdown then a site-wide code. Adding twenty and ten and calling the deal thirty percent overstates the savings, because the second cut never sees the original price. Zero percent on either step is a legitimate outcome and leaves that step unchanged rather than an error: a SKU that only carries one of the two offers still belongs in a comparison cart. One hundred percent on either step is a free remaining balance: that step's result is zero and later steps stay zero. You supply three numbers; the calculator multiplies them in order and rounds each money figure half-up to two decimal places so goldens compare byte for byte across runtimes. The identity this calculator uses is final_price equals price times one minus first_discount divided by one hundred, times one minus second_discount divided by one hundred. The first markdown produces an intermediate price_after_first, which is then reduced by the second rate. Total savings is the original price minus that final_price, which is the same as price times the equivalent combined percent once money rounding is applied on each step so the parts still add back to the list. Price is the original amount in one currency; first_discount and second_discount are the two advertised rates typed the way banners print them, so twenty means twenty percent, not twenty hundredths. The single percent that would match the stacked result is also returned as equivalent_percent so a spreadsheet can keep one number next to the two percents people type. A discount that exceeds one hundred percent is not a markdown in this contract and is rejected as invalid_input, because a banner that prints one hundred twenty percent off is almost always a data error, not a rebate you meant to model. This endpoint does not scrape retailer catalogs, does not add a third coupon on top of the two percents you send, does not add sales tax or shipping, and does not convert currencies.

Input contract, response shape, and error behaviour

Zero percent on a step is valid and leaves that step's money unchanged. One hundred percent on a step is valid and zeros the remaining price. POST a JSON body with three required finite numbers. price is the original amount in one currency unit before either successive discount; aliases original_price, list_price, original, and amount map to the same field so a catalog export can keep its column names. first_discount is the first successive percent-off rate applied to the original price, not a fraction: twenty means twenty percent off; aliases first_percent, discount1, first, and percent1 are accepted. second_discount is the second successive percent-off rate applied to what remains after the first markdown; aliases second_percent, discount2, second, and percent2 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. On success the body echoes price rounded to two decimal places, first_discount, and second_discount, then reports price_after_first as the money after only the first markdown, final_price as the checkout figure after both cuts rounded to two decimal places, savings as price minus final_price, equivalent_percent as the single percent that would match the stacked result, and a formula string restating the identity. Example: one hundred at twenty then ten yields price_after_first of eighty, final_price of seventy-two, savings of twenty-eight, and an equivalent_percent of twenty-eight. Pair the JSON with your own rule for which SKUs share which two rates—storewide plus coupon, clearance plus employee extra, or seller markdown plus site code—because this endpoint multiplies the three numbers you send; it does not look up a retailer, apply a third coupon, or convert currencies. Keep requests small, pin the rounded final_price in tests, and you get a reproducible stacked figure for worksheets, LMS plugins, and edge workers without standing up a promotions engine of your own.

Where a double discount calculator earns its keep

Deal-site editors drop a published list and the two advertised percents, then pin final_price and savings so a post does not quote a made-up thirty-percent figure that later disagrees with checkout. Keep both discounts between zero and one hundred inclusive, pin the rounded final_price in tests, and you get a reproducible stacked figure for teasers, carts, and edge workers without standing up a promotions engine of your own.