How a Delivery App Decides Your Price
The price is not a price, it’s an output
Open a delivery app twice in the same city, thirty minutes apart, and the delivery fee on an identical order can be different both times. That’s not a glitch. The number you see at checkout is the output of a pricing model running fresh calculations for every request, and it’s built to move. Understanding how it moves, and why platforms guard the inputs so carefully, says a lot about the broader fight over who gets to see and shape what a system decides.
Dynamic pricing on delivery platforms is descended from the same idea as ride-hailing surge pricing: when demand for couriers in an area outstrips the supply of available drivers, the price goes up to pull more couriers into that zone and to gently discourage some orders from being placed at all. When supply is loose, the price drops to keep couriers busy and volume flowing. It’s a market-clearing mechanism dressed up as a delivery fee.
Zones, ETAs and the demand curve
Most platforms carve a city into small geographic zones, sometimes just a few blocks wide, and track a live ratio of open orders to available couriers in each one. That ratio feeds a multiplier applied to a base fee calculated from distance, estimated prep time at the restaurant or store, and traffic conditions on the route. A kitchen running twenty minutes behind pushes the promised delivery window out, which itself affects the price, because a longer promise ties up a courier for longer and the platform has to compensate for that.
Weather, local events, and time of day all move the underlying ratio rather than being separate line items. Rain doesn’t have its own surcharge code; it just pulls more people onto the app at once while fewer couriers want to be out on a bike in it, and the zone-level ratio does the rest.
The device signals riding along with every request
Alongside the order itself, the app sends a stream of device and account metadata with the request. Some of it is functional: GPS coordinates for the delivery address, connection quality, whether the app is foregrounded. Some of it feeds fraud and abuse models rather than pricing directly: device model, OS version, jailbreak or root status, how long the account has existed, order history, and how the account was created.
The distinction matters. Pricing models are demand-and-supply driven at the zone level, not usually built to charge one identifiable person more because of who they are. What personalization does show up tends to be at the level of promotions, not the base fare: which discount codes, loyalty perks or first-order deals a given account is offered, based on order frequency and how price-sensitive that account’s history suggests it is.
The battery level story and why it won’t die
No conversation about ride and delivery app pricing gets far without someone bringing up the claim that a phone’s battery level affects the price shown, the idea being that a user with 5 percent battery is more desperate and less likely to shop around. It’s a claim that has circulated widely, that at least one major platform has acknowledged studying user psychology around low battery states, and that the company has also explicitly denied using as a pricing input.
The reason it’s worth mentioning here isn’t to settle which version is true. It’s that the story illustrates exactly why people are suspicious of pricing algorithms in the first place: the inputs are opaque, the model is proprietary, and a phone genuinely does report its battery percentage to the OS and, depending on permissions, to apps running on it. Whether or not any given platform uses that particular signal, the technical capability to do so exists, and that gap between what’s technically possible and what’s actually happening is where a lot of pricing folklore lives.
Why some people go looking for a lower number
Because the fee is sensitive to zone, device state and account history, some users try to manipulate those inputs to land on a cheaper price. The common moves are predictable: clearing app data or reinstalling to look like a first-time user and trigger a new-customer discount, changing the delivery address slightly to shift zones, running a VPN to make the app think the order is coming from a different region with lower base prices, or creating additional accounts to farm referral and first-order credits repeatedly.
None of this is presented here as a playbook, because platforms have spent years building detection specifically around these patterns, and the people who try it are, functionally, testing a fraud model that is very good at its job.
How platforms build a device graph to catch it
The core defense against account multiplication is the device graph: a map of which accounts have logged in from the same physical device, the same payment instrument, the same phone number, or overlapping GPS histories. A hardware identifier, an install ID tied to the device’s advertising identifier, or even font and screen metrics collected at app launch can link accounts that never shared an obvious credential.
Reinstalling the app resets very little of this. The device itself still has an identifier baked into the OS or derivable from hardware characteristics, and the platform’s backend doesn’t need the old app data locally, it already has everything logged server-side from the prior sessions. A device that has churned through five “new customer” accounts in a month stands out clearly in that graph regardless of how clean each individual account looks.
Card fingerprints, phone numbers and the parts you can’t spoof
Payment cards carry their own fingerprint through the bank identification number, the tokenized card reference many processors expose to merchants, and the billing details attached. A new account using a card that’s already tied to three other accounts on the platform is an immediate signal, and it’s one that’s much harder to launder than a device ID, since spoofing a valid, chargeable card is a different order of problem entirely from clearing app cache.
Phone number verification adds another layer. SMS-based signup checks are cheap to bypass at small scale with disposable numbers, but platforms weight the reputation of the number itself, whether it’s from a known VOIP range commonly used for verification farming, and how many prior accounts share it. Momentary wins on one signal tend to get caught by the aggregate.
Mock locations, rooted phones and the attestation layer
Location spoofing to shift into a cheaper pricing zone runs into a similar wall. Android exposes a developer option and a flag that marks a location as “mock” when it’s set by another app rather than the real GPS radio, and a rooted device that hides this flag is itself detectable through root and integrity checks like Google’s Play Integrity API, which many delivery apps call before processing a request. iOS has an equivalent in App Attest and DeviceCheck, which let a backend verify that a request is genuinely coming from an unmodified copy of the app running on real Apple hardware rather than an emulator or a tampered binary.
None of these checks are perfect, and every platform runs a constant internal tally of false positives against real fraud caught. But the direction of travel over the past several years has been toward requiring cryptographic attestation from the device itself, not just trusting whatever the app client reports, which is a much harder thing to fake convincingly than a spoofed GPS coordinate.
Why the arms race keeps going
Platforms spend real engineering budget on this because the incentives are asymmetric. A dynamic pricing model that can be reliably gamed doesn’t just lose the discount amount on individual orders, it undermines the whole supply-and-demand signal the model depends on to keep couriers moving to where they’re needed. If enough users can reliably suppress the surge signal in a zone, the platform loses the mechanism it uses to solve actual courier shortages, which is a much bigger problem than a handful of underpriced orders.
That’s the pattern across most of this adversarial territory: what looks like a narrow fight over a delivery fee is really a fight over whether a demand-signaling system can be trusted to reflect real demand. The device graphs, card fingerprints and attestation checks exist because the pricing model only works if the inputs are real.
If you’re curious about the rest of this world, the fingerprinting, the fraud scoring, and the systems built to catch or evade them, Hidden Internet covers it from the inside, one mechanism at a time.
Get new guides and videos first — join the Telegram channel.