Order handling fee calculator
The order handling fee calculator combines a flat handling amount with a percentage of the order subtotal, then shows the complete charge and checkout total.
Run — free
It is useful when packaging, administration, special processing, or fulfillment costs cannot be covered by one fee method alone. Enter the subtotal and either or both fee components to get a transparent breakdown, with monetary results rounded to two decimal places so the figures can be reviewed before they are added to a store, quote, invoice, or checkout workflow.
Set the subtotal and both fee components
Start with the order subtotal before handling fees. This should be the merchandise or service amount that your policy says is eligible for the percentage charge; do not include the handling fee itself, because doing so would compound the calculation. Next, enter the fixed fee, which can represent a base amount for packaging, paperwork, warehouse picking, or another cost that applies equally to every qualifying order. Finally, enter the percentage fee as a percentage rather than a decimal fraction: enter 4.5 for four and a half percent, not 0.045. Either fee component may be zero, so the calculator also works for fixed-only and percentage-only policies. All inputs must be non-negative. The percentage is limited to 100, and the monetary fields have generous explicit bounds to reject accidental or unprocessable values. Keeping each component separate makes the result easier to explain to customers and easier to compare with the configuration in your commerce platform. It also prevents a common spreadsheet mistake in which a fixed charge is mistakenly included in the percentage base.
Understand the calculation and rounding
The calculator first multiplies the subtotal by the percentage fee divided by 100. That percentage amount is rounded to two decimal places, reflecting the cent precision normally used for a checkout charge. It then adds the fixed fee to that rounded percentage amount and rounds the combined handling charge to two decimals. The final order total is the original subtotal plus the combined handling charge, again rounded to two decimals. For example, a policy with a fixed component and a percentage component produces one handling charge while still returning both pieces in the output. The response includes the normalized subtotal, fixed fee, percentage rate, calculated percentage amount, total handling charge, and final order total. This breakdown is deliberate: it lets an integration display a single fee at checkout while retaining enough detail for testing and reconciliation. The calculation does not add taxes, shipping, discounts, tips, payment processing fees, or currency conversion. Apply those according to the ordering rules and legal requirements of your own checkout system.
Use the result safely in checkout workflows
Use this calculator as a deterministic pricing step after you have established the eligible subtotal and before you present the final checkout summary. A storefront can call it when a cart changes, an operations team can use it to test a proposed fee schedule, and a back-office process can compare the expected handling charge with completed orders. Because the function has no network calls, saved state, randomness, or current-date dependency, the same inputs always produce the same output. That makes it suitable for automated tests and repeatable audits. Store the input values alongside the returned breakdown if you may need to explain how a historical charge was produced. Before launching a fee policy, verify how your commerce platform sequences discounts, shipping, tax, and fees; this calculator intentionally operates only on the subtotal you provide. Also make the fee visible before the customer commits to payment and use clear language appropriate to your market. The API price is $0.002 per request, while the browser experience can run the same pure calculation without sending the values to a third-party service.
What you can do with it
Configure a store checkout
Calculate the exact combined handling charge to mirror a fixed-plus-percentage fee policy in an ecommerce checkout.
Test a proposed fee schedule
Compare handling charges across representative subtotals before publishing a new fulfillment or processing policy.
Reconcile completed orders
Recalculate the expected fee from recorded inputs and compare it with the charge stored on an order.
FAQ
What subtotal should I enter?
Enter the amount your policy uses as the percentage-fee base, before adding this handling charge. Whether discounts, shipping, or taxes belong in that base depends on your checkout policy.
Can I calculate only a fixed fee?
Yes. Set percentage_fee to zero or omit it. The handling charge will equal the fixed fee.
How are fractional cents handled?
The percentage amount is rounded to two decimal places before it is combined with the fixed fee. The handling charge and final total are also rounded to two decimals.
Does this calculator include tax or shipping?
No. It only calculates the handling fee from the subtotal you supply. Tax, shipping, discounts, and other checkout adjustments must be calculated separately.
What does the API cost?
The API costs $0.002 per request. The browser version runs the same deterministic calculation locally.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/ecom/handling-fee \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"subtotal":125.5}'const res = await fetch("https://api.kit.forhosting.com/ecom/handling-fee", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"subtotal": 125.5
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/ecom/handling-fee",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"subtotal": 125.5
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/ecom/handling-fee", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"subtotal":125.5}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"subtotal":125.5}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/ecom/handling-fee", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"subtotal": 125.5
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "ecom.handling_fee",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |