The first fork: per-offer pay vs earn-by-time
Most of this site assumes per-offer pay: each offer arrives as a single headline payout, you accept or decline within a short window, and your hourly rate is simply whatever your accepted offers add up to divided by the hours you were out. Nobody schedules you and nobody pays you to wait. Every minute of idling is a cost you absorb, which is why the discipline of a decline sheet matters more here than anywhere else. In per-offer mode, saying no is the job.
Earn-by-time arrangements invert that bargain. Instead of pricing each delivery, the platform quotes a rate for the period you spend working, and the offers stop being a negotiation. The tradeoff is that the definition of a paid minute becomes the whole ballgame. If the clock only advances while you are assigned to an order, the gaps between orders are unpaid in both modes and the guarantee is thinner than it sounds; if it advances whenever you are logged in and available, it is much stronger. Our source ledger does not document how any specific platform defines its paid clock, so we will not tell you. Read the terms shown inside your own app before you opt in, because that single definition decides whether the mode helps you on a slow evening or costs you on a busy one. Whatever it says, compare it against your own history using total working time, not the platform's activity clock, or you are comparing two different denominators.
One offer number, three separate ingredients
The figure on the acceptance screen is usually a sum, and the pieces behave nothing alike. Base pay is the platform's own contribution, generally scaled to the effort of the job. Promotions (the extra amounts attached to particular hours, zones, or streaks) are conditional and temporary by design. Tips come from the customer, not the company. Summing them into one bold number is convenient for a two-second decision and useless for understanding your week: a shift carried by promotions is a shift whose earnings vanish the moment the promotion window closes, while a shift carried by base pay is repeatable.
We deliberately publish no base-pay minimums, per-order averages, or promotion amounts on this page. They vary by market, change without notice, and a static page quoting them would be misleading within weeks. Structures age well; dollar figures do not. If you want to know what the mix looks like where you drive, the only trustworthy source is your own earnings history, broken out by component in your app's payout detail.
The second fork: delivering vs shopping
A restaurant order's effort is mostly driving, plus a wait at a counter you cannot control. A shop-and-deliver batch is a different occupation wearing the same app. Instacart's shopper earnings documentation describes batch pay as reflecting "the total expected effort... including travel to the store and to the customer, quantity and weight of items, and expected time needed to shop the batch," and says it is "based solely on job-related criteria, such as driving distance, number of items, and expected shopping time." Read that closely: two of the three named criteria have nothing to do with mileage.
The consequence for your arithmetic is severe. A short batch with a long item list is a time problem: aisles, weights, out-of-stock substitutions, the checkout queue, loading. A per-mile screen will flatter it badly. That is precisely why our flagship calculator is scoped to restaurant and pickup-ready offers, with a shopping mode still to come. Other apps also mix shopped work into their offer feeds; we have not verified how each of them describes that pay, so we describe only Instacart's published wording here. In the meantime, evaluate any shopping batch by overriding the estimated minutes with a realistic number, and be pessimistic — the store is where the clock disappears.
Stacked offers and what they do to the per-order math
Platforms bundle work: two pickups, two drop-offs, one payout. DoorDash's dasher help states "You have 50 seconds to choose to accept the offer (unless otherwise stated in the app)," and describes the same 50-second window when a new order is offered while you are already on an active one. Fifty seconds is not much time to evaluate a route with twice the stops. Grubhub publishes a longer window and a sharper consequence: orders "neither accepted nor rejected within approximately 90 seconds of being sent will disappear from your screen and will count as a rejected offer" — the word "approximately" is Grubhub's own, and the part worth noticing is that letting an offer expire is scored the same as declining it, so a phone face-down in your pocket costs you acceptance rate exactly like a decline does. Those two are the only figures we quote, because Uber Eats, Instacart and Walmart Spark do not publish a delivery-acceptance timer anywhere on their own help sites. Uber does publish a 15-second figure, but it belongs to a rideshare trip request, not a delivery offer, and we will not borrow it across.
The structural trap is that a bundle adds stops, and every stop carries fixed minutes that a per-mile view simply cannot see: parking, walking, waiting, handing off. Two orders sharing a corridor genuinely can beat two separate trips, because the deadhead between them collapses. Two orders pointed in different directions do the opposite: the second customer's clock starts running while you are still standing in the first lobby, and one slow kitchen delays the entire chain. The number to test is not the combined payout, which always looks larger, but the combined payout measured against the combined minutes and the combined miles.
Tips: an estimate with upside, not a promise
Treat the tip portion of any pre-acceptance figure as a forecast. It is generated before the customer has seen the delivery happen, and the amount finally paid can land elsewhere. Where the apps genuinely differ is whether that movement can go down, and only two of them publish a window for it. Instacart's shopper earnings page tells shoppers that customers "can increase their tip for up to 14 days after delivery, but can't decrease it after 2 hours." Walmart Spark's driver help says customers "have up to 3 hours to adjust their tip after the service so the amount you see may change before it is confirmed." Two hours on Instacart, three on Spark. Those are the only published downward windows we have been able to verify in a platform's own documentation.
Nothing here should be read as saying DoorDash, Uber Eats or Grubhub reduce a tip after drop-off. What those three publish points the other way: DoorDash describes the acceptance-screen figure as the minimum guaranteed amount for the offer and describes a post-checkout tip only as something added afterward, Uber says additional tips are added after the trip, and Grubhub says a driver views the tip only after accepting the order. Whether a customer can cut a tip on any of the three, and on what timetable, is not something we found stated on their own help pages, so we will not guess at it.
The practical posture that follows is much the same wherever you drive. Treat the visible number as the number you are deciding on and anything above it as upside: an offer that clears your threshold on what is shown is safe on the apps that can only add to it, and on Instacart and Spark it is safe as long as you would still take the job with the tip trimmed. An offer that only clears the bar if the tip turns out bigger than shown is a gamble you are funding with your own fuel. Over a full week the surprises in both directions mostly cancel, which is why reviewing a whole shift in the real hourly calculator tells you far more than relitigating any single order.
Acceptance-rate programs and what chasing one costs
Several platforms operate status or priority tiers, and acceptance rate is a common input. Our source ledger does not document any specific program's thresholds, benefits, or how a rate is calculated, so we will not describe them, and you should be skeptical of any site that states them confidently without a citation, because those rules get revised quietly.
The arithmetic, though, belongs to you and does not depend on the fine print. Suppose keeping a threshold means accepting several offers per shift that fall below your personal floor. Each one has a measurable gap: the hourly it actually pays versus the hourly you needed, multiplied by the time it consumes. Add those gaps across a week and you have the real price of admission. Then ask whether the tier's advantages plausibly exceed that price. Sometimes the answer is yes, particularly in markets where better order access is scarce. Sometimes drivers pay the toll for a benefit they never quantified. The point is not that chasing status is wrong; it is that you can only justify it with your own numbers, and almost nobody runs them.
Multi-apping, honestly
Running two or more apps at once is common, and the appeal is obvious: more offers to choose among means fewer minutes of unpaid waiting, and a fuller pipeline makes a strict floor easier to hold, since declining costs you nothing when another offer is already queued. The costs are just as real. Attention splits. Accepting on one app while committed on another creates overlap you cannot always unwind, and a late arrival caused by juggling is a real person's dinner. Record-keeping gets harder too. Your mileage log has to cover every business mile of the shift regardless of which app was open, and reconstructing that afterward from two payout histories is miserable. Platform terms may also address concurrent work, and we have not documented what any of them say, so check yours. Whatever you decide, do the deciding while parked.
Promotions, surge windows, and local pay rules
Time-limited incentives are the strongest argument against assuming any flat hourly rate. They shift the value of identical offers by hour, by zone, and by day, which means a rule of thumb formed on a Tuesday afternoon can be wrong on a Friday night. Rather than memorize a number, memorize the habit: recheck your floor against the conditions you are actually working in.
Separately, some jurisdictions have adopted pay standards for app-based delivery work that change this arithmetic outright. We have not researched or documented any specific ordinance, so this page names no city, no rate, and no effective date, only the fact that local rules exist and can override the general picture described here. If you drive somewhere with one, its text governs, not ours.
What the public documentation does not settle
Being explicit about the gaps is more useful than papering over them. Working from the platform help pages we have verified, these questions remain open: the formula behind base pay on any app; whether tip amounts are capped on the offer screen; whether DoorDash, Uber Eats or Grubhub let a customer reduce a tip after drop-off, and on what timetable, given that only Instacart and Spark publish a downward window; how each earn-by-time mode defines a paid minute; the offer-decision timer on apps other than DoorDash; and the exact criteria behind acceptance-rate tiers. Where a platform publishes an answer, we will cite it. Until then, the honest position is that your own recorded shifts are better evidence than anyone's confident summary, including ours.
Why dollars per mile still beats dollars per order
Whatever the platform, an offer is a bid for two things you own in limited supply: miles and minutes. A per-order figure prices neither. Dollars per mile at least prices the driving, and once you pair it with a true cost per mile you know your margin instead of your revenue. Your personal floor (decline under $X plus $Y per mile) prices the stop time and the distance together, which is the whole decision in one line. That rule survives a pay-model change, a new promotion, a move to another city, and every app on this page.