Before the user commits

I don't mind paying a delivery fee. I do mind finding out about it after I've already compared three options, picked the items, and started treating the cart like a real order.

The annoying version is not just "fee exists." It is the fee appearing only after one more detail is handed over: address, phone number, account login, payment method, delivery window, or a tiny service-area check. At that point the price record has changed, but the earlier screen still feels like it made a promise.

A cleaner record for this kind of case needs to separate five things:

- the visible base price
- the condition that unlocks the fee, such as district, distance, time, basket size, payment method, or building rule
- the point in the flow where the fee first appeared
- whether the number was an estimate or a final charge
- what a guest or first-time visitor could see before making an account

I think the trigger point matters more than the fee label. "Service fee" is not enough if nobody can tell whether it was caused by distance, peak time, payment method, or a minimum-order rule. Support also gets worse when people can only say, "it changed at checkout." That sentence does not tell the next person which screen to fix.

There is one fair exception. Some fees really cannot be final until an address or slot is known. But even then, the page can say the range early: delivery may add 2-5 dollars after address, wallet payments may carry a different surcharge, or night slots may change the estimate. That is a much better promise than a clean-looking price that grows teeth at the last step.

The small rule I would keep is this: if a required fee can change the decision, show the possibility before the user starts committing time. If the exact amount depends on later information, record the missing condition and the screen where it becomes final.

Otherwise every complaint becomes a vague "hidden fee" story, even when the real bug is just late timing.

The fee showed up too late

// COMMENTS

ON THIS PAGE