When you book a trip on Chale, the request your browser or phone sends contains where you are, where you are going, and which category you chose. It does not contain a price. There is no field for one.
What that prevents
If a client could name a price, then a price could be changed by anything that can talk to our API — a modified app, a browser console, a proxy. The usual defence is to re-check the number on the server, which works right up until the day somebody forgets to. Removing the field removes the class of bug.
How a fare is actually produced
You set two points. The server routes between them, gets a real distance and duration, looks up the pricing rule configured for that city and that vehicle category, and produces an itemised breakdown with a quote id. The app shows you the breakdown. When you confirm, it sends the quote id — not the total — and the server checks the quote is still its own, still valid, and still for the trip you are booking.
Why the receipt never changes
A completed trip stores the pricing rule, the fare breakdown and the commission that applied at the moment it was quoted. If an operator changes a rate tomorrow, your trip from today does not move. A receipt that can be recalculated is not a receipt.
What it costs us
It makes some things slower. You cannot see a fare before you have an account, because a fare is calculated for a person against real coordinates, and we are not willing to print an estimate on a marketing page and call it a price. We think that is the right trade.