Buy one get one discount calculator

How buy-X-get-Y-free discount percent is computed

That figure is unit_price: the shelf price of one identical item before the promotion, kept in one unit for the whole calculation so no silent currency conversion creeps in. Then set buy_qty to X and free_qty to Y for the deal wording buy X get Y free. List total is unit_price times quantity; payable total is unit_price times paid items; savings is list total minus payable total. The pipeline is deterministic floating-point arithmetic: no random seeds, no wall-clock timestamps, no network calls, and no model drift, so identical inputs always produce identical JSON. Quantity, buy_qty, and free_qty must be finite positive integers; zero or negative quantities fail with invalid_input rather than inventing a discount. Negative unit_price fails; zero unit_price is allowed and yields zero totals and zero discount percent.

What you send and what you get back

Classic checks include unit price ten with quantity five under buy one get one free: free items two, paid items three, list fifty, payable thirty, savings twenty, discount percent forty. Another check is unit price twelve with quantity seven under buy two get one free: free items two, paid items five, list eighty-four, payable sixty, savings twenty-four, discount percent about twenty-eight point five seven. Send four required fields. unit_price is a finite number greater than or equal to zero for the list price of one item. quantity is a positive integer for how many items you take. buy_qty is a positive integer X for the paid side of the deal cycle. free_qty is a positive integer Y for free items granted after each full paid block of X. Missing fields, non-numeric strings, NaN, Infinity, fractional quantity fields, zero or negative quantity fields, and negative unit_price fail with invalid_input and are not charged. On success the response echoes cleaned unit_price, quantity, buy_qty, and free_qty, reports group_size as X plus Y, deal_cycles as complete groups, remainder as leftover items, paid_items and free_items as the checkout split, list_total and payable_total and savings as money figures in the same unit, and discount_percent as the effective percentage off the list total. deal_label is a short human string such as buy 1 get 1 free, method is bogo_discount, and formula documents free_items equals floor of quantity over X plus Y times Y plus max of zero and remainder minus X so blogs and offer letters can cite the same expression. A zero or negative quantity request fails with a hard invalid_input mentioning non-positive quantities. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.

Where BOGO discount calculators show up in real work

Personal finance educators teaching consumer math assign BOGO worksheets and need deterministic JSON for auto-graders rather than hand-typed totals that drift under rounding. Product teams shipping cart widgets reuse the same cycle arithmetic in browser and API so offline mockups and production never disagree. Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.