What Is the Grubhub App and How Does Delivery Dispatch Work?

At 7:42 on a Tuesday evening, a customer two kilometres from a small curry house taps a button that says Pay. Two curries, a naan, a bottle of water, 24.60 plus a delivery fee and a tip.

Nothing has been paid. No currency has moved to anyone, the restaurant has not seen the order, and no rider knows it exists.

This article follows that one order to the day each of the four parties is genuinely paid. Not the browsing before it, but the part after the commitment and past the doorstep into the settlement nobody explains. If you are building or buying a food delivery dispatch app, this order contains almost every hard problem you will meet.

Grubhub moves money between four parties on a single order, and almost none of it moves when the customer taps pay.

The Checkout Tap That Moves No Money in Delivery Dispatch

The tap a customer makes on Grubhub authorizes money. It does not actually move any.

The pay button asks her bank a question rather than making a demand. Roughly: if I came back for 24.60 in the next few days, would you honour it, and will you fence that amount off now.

The yes that returns in two seconds is an authorization, and an authorization is a reservation rather than a transfer. Almost every payment support ticket you will receive is somebody confusing those two states.

You hold rather than take because you do not yet know what the order is worth. Taking money for food nobody has cooked creates a refund obligation on every order that goes wrong, and refunds are slower and more visible than never having taken it.

What her bank actually shows her

Her app shows a pending line for 24.60, usually carrying your platform’s name rather than the restaurant’s. It will not say which dish she ordered, and it will not disappear when the food arrives.

Cancel the order and that pending line does not vanish, because releasing a hold is an instruction the bank applies on its own schedule. Change the total after acceptance and some issuers show the hold and the final charge together, which looks exactly like a double bill.

Why a hold can expire before the order closes

Authorizations lapse. Depending on scheme and acquirer the window runs to days, after which the reservation is released.

That matters when an order is disputed, or delivered but never marked complete because a phone died in a stairwell. An order stuck past its window is money you can no longer collect without asking the customer to pay twice, so close every order within a fixed number of hours whether or not a human remembered.

The Restaurant’s Moment of Acceptance

Four seconds later a tablet above the pass makes a noise. Somebody with flour on their hands reads two lines and presses Accept, and that press is the most consequential action in the order.

Before it, the order is an offer. After it, the kitchen owes a meal, the platform owes a rider, and a clock starts that every later complaint is measured against.

What the outlet can still change

A good accept flow offers one adjustable field and nothing else: how long this will take. That number is not a customer estimate, it is a promise about when a rider should be standing at the counter.

The outlet also needs to say that one item is unavailable; if the only route to that is refusing the whole order, whole orders get refused. Item availability that is genuinely current is how cheap systems poison restaurant relationships, as The Out-of-Stock Trap: Why Cheap Delivery Scripts Ruin Restaurant Relationships sets out.

What the accept commits the kitchen to

Once accepted, the price is fixed. The kitchen cannot decide the portion is worth more tonight, cannot substitute a dish without the customer agreeing, and cannot quietly extend the time.

An outlet that accepts at twenty five minutes and hands over at fifty has held a rider for twenty five minutes, a cost paid by a third party who never agreed to it. Treat the accept as a soft signal and every estimate you produce downstream is decorative.

Dispatch Assignment and the Counter Where Lateness Is Made

The order now needs a rider. The system estimates when the food will be ready, works out which riders could be at that counter by then, and offers the job with a short window to accept. Offers, timeouts, re-offers, claims and batching are covered in How to Build an App Like Grubhub: Inside the Food Delivery Dispatch Engine. Here the only thing that matters is that within ninety seconds a specific human has agreed to carry this bag.

The order starts collecting names and times

From assignment onward the order is not a status. It is a list of events, each with a name and a timestamp: authorized, accepted, assigned, arrived at outlet, collected, delivered.

That list is the only instrument for splitting blame fairly. A late order where the rider waited nineteen minutes at the counter is a kitchen problem; the same delay where he was assigned eleven minutes late is yours.

The counter is a queue, not a handover

The rider reaches the curry house at 8:04. The food was promised for 8:02 and is not ready, so he waits beside a counter that is also serving walk-in customers, and leaves at 8:11.

Those seven minutes appear in no complaint and nowhere in the customer’s model of what went wrong, yet across a zone at peak they are usually the largest single contributor to late orders.

Waiting is a cost, and it lands on somebody

Those seven minutes were not paid for by anyone unless you decide they were. Absorb the cost and your cost per delivery rises; charge the outlet and it is defensible but unpopular; pass it to the rider, the default if you do nothing, and you lose the riders who know your zone.

Most operators settle on an allowance: the first few minutes free, then a per minute amount accruing to the rider and recorded against the outlet. It sits directly upstream of Grubhub Revenue Model: Dispatch Cost Per Delivery Beats a Higher Fee.

The Dispatch Journey Between a Moving Dot and an Estimate

At 8:11 the rider marks the order collected and her screen becomes a map with an icon crawling along a road. She watches for ninety seconds, then stops.

The tracking map is the most photographed feature in delivery and the most misunderstood. It is an anxiety reducer, not an information source, and it does not tell her when the food will arrive.

What the moving dot really tells her

The dot is a position from a phone in a pocket, smoothed and sent at an interval. It lags, it jumps when signal returns after a tunnel, and on a batched run it shows a route that makes no sense to her.

How fresh that position can be without melting your infrastructure at peak is worked through in Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel. The product rule is narrower: never let the map be the only thing you say, because an icon with no words invites her to invent her own estimate.

What to say when the estimate is going to be wrong

Your system knows an order will be late several minutes before the customer does, because the collection timestamp came in nine minutes after the promise. That gap is the only window in which a late order becomes an acceptable one.

The honest pattern is a revised time with a reason, sent once and early. Customers forgive a late order with an explanation far more readily than a countdown that slides by a minute every ninety seconds for twenty minutes.

The Doorstep, and Why Delivery Dispatch Has Paid Nobody Yet

At 8:26 the rider arrives and the bag changes hands. What the platform records then, and can prove three days later when she says the order never came, has real depth to it: the evidence ladder, photographs and contactless drops are covered in Grubhub App Security Risks: Delivery Dispatch, Proof and Rider Safety. What concerns us is narrower: the delivered event is a financial trigger, not a status update.

Completion is the event the money waits for

Until the order is marked delivered, the rider has no earning, the restaurant has nothing to invoice, the platform has nothing to commission, and her money is still parked at her own bank. One tap on a doorstep in the rain releases all four.

That makes the reliability of the tap a treasury concern rather than a UX detail. An order physically delivered but never marked delivered is four parties waiting on a row that will never be written.

Capture, and what it is not

It is 8:27. The customer is eating, the restaurant has sold two curries, and financially almost nothing has happened.

Capture is the instruction that turns the reservation into a transfer, usually firing on the delivered event. It can be for less than the authorization but not more, which is why a tip added afterwards is a second charge rather than an edit to the first.

Capture does not put money in your account that evening either. The acquirer settles on its own cycle, commonly a few working days later, so even after capture the money is real but somewhere else.

Merchant of record, the question founders skip

There are two structures and they produce different businesses. The platform can collect the whole 24.60 in its own name and pay the restaurant its share, or the payment provider can split at capture and route the restaurant’s share straight to its account.

The first gives control and float, and makes you responsible for tax treatment, chargebacks and holding other people’s money. Software provides the controls for either; whether a structure is permitted where you operate is a question for your own advisors, settled before architecture rather than after.

One Payment, Five Destinations

The customer paid one number, and that number is not one thing. It is at least five obligations collected together, each owed to a different party on a different schedule.

The food subtotal belongs to the restaurant, less its agreed commission. The delivery fee belongs to the platform, which has separately agreed to pay a rider. The tip belongs to the rider and is never yours, and tax belongs to a government and was never yours at any point.

The restaurant share is not the menu price

The kitchen sold at its menu price and will be paid that less commission. If the outlet joined a promotion a further deduction applies, and an outlet that cannot see which orders carried one reads every deduction as a rate increase.

Commission is rarely one number in a mature operation. It varies by who delivered, by category and by whether the order came from a paid placement, which is a reconciliation problem unless the rate applied to an order is stored on it. The lines this creates are laid out on the business model page.

The delivery fee does not pay the rider

This is the most common misreading of the model. The customer paid a delivery fee of, say, 2.50, and the rider may earn more than that or less: the fee is what a customer tolerates, the rider payment is what gets a job accepted at 8pm in the rain.

On a long drop, or during a surge, the platform pays out more than it collected and takes that loss deliberately. How you manufacture the supply that sets that price is the subject of Grubhub Business Model: Dispatch Depends on an Hourly Rider Flow.

When Each Party Is Actually Paid

Three parties are owed money from one order and none are paid at the same time. The customer is charged within hours, the rider is paid next, and the restaurant is paid last by some distance.

The rider is paid on the shortest cycle

Riders are usually paid weekly, increasingly with an option to draw earnings sooner for a small fee. The cycle is short because somebody deciding at 5pm whether to work tonight is deciding partly on when the money lands.

A rider’s week is not one figure. It is base amounts per job, distance, waiting allowances, incentives and tips attached to specific orders, and a rider who cannot reconstruct his own week assumes he was shorted.

The restaurant is paid on a cycle, not per order

The curry house will not receive 24.60 less commission on Tuesday night. It receives one transfer covering a period, typically a week, arriving days after that period closes, so food sold on Tuesday can be money in the bank the following Wednesday.

Kitchens find this genuinely painful, because they buy ingredients with cash and pay staff on short cycles. It is also the most common reason an outlet quietly stops accepting orders.

What a Payout Run Actually Is

A payout run is a scheduled job that takes every order completed in a window, works out what each party is owed net of everything that has happened since, produces a statement, and issues one transfer per party.

Net is doing the heavy lifting. Between Tuesday’s order and Friday’s run, that order may have been partly refunded, disputed, adjusted for a missing item, or credited because the kitchen accepted responsibility.

Why it runs weekly rather than continuously

You could pay a restaurant the moment each order settles, and almost nobody does. Every transfer carries a cost, disputes arrive after delivery so paying instantly means clawing back later, and four hundred tiny credits are harder to reconcile than one credit with a statement behind it.

There is a fourth reason nobody says out loud, which is float. Money held between capture and payout is working capital, so be honest early about whether your cycle length is operationally justified or financially motivated.

A failed payout is a support ticket in waiting

Transfers fail. Details get mistyped, a bank rejects a name mismatch, an account closes when a restaurant changes hands. Treat a failed transfer as a first class event with an owner and a retry path, and treat a change of payout bank details as a security-sensitive action rather than a profile edit.

What the Restaurant’s Statement Has to Show

A statement is reconcilable when the restaurant’s own bookkeeper can start from the transfer that hit the bank and work backwards to individual orders without asking you a question. That is a high bar and most platforms fail it in their first year.

What Each Party Must Be Able To Verify Alone

Party	What they check without asking you	What goes wrong without it
Customer	One pending line, one final charge, the tip shown separately, any refund traceable to an order	Duplicate charge complaints and card disputes you lose on paperwork
Restaurant	Every order, the commission rate applied to it, promotion deductions, adjustments and the resulting transfer	Silent deactivation: the outlet stops accepting rather than arguing
Rider	Per job base, distance, waiting allowance, incentive progress and the tip attached to each drop	Zone-wide distrust, spreading rider to rider faster than you can answer
Operator	Gross collected, amounts owed out, float held, and the contribution left per delivered order	A business that looks profitable until the payout run lands

Order level lines, then adjustments

The statement needs two sections that are never mixed. First, one line per order: date, the reference the outlet sees on its tablet, gross food value, commission rate and amount, net. Second, everything that is not an order: refunds, promotion contributions, waiting recoveries, corrections.

Adjustments are where trust dies. Without a reason, a date and a reference, restaurants build their own spreadsheet from tablet screenshots, and the day it disagrees with yours the relationship turns adversarial.

The reconciliation test

Take a real week for one outlet, sum the order lines, apply the adjustments, and compare the result to the transfer that actually left your account, to the cent. Then hand it to somebody who was not involved and ask them to do the same unaided.

If it does not reconcile, you have a defect compounding silently every week. If it reconciles but nobody else can follow it, you have a support cost that grows with every restaurant you sign, which is why the features page treats statements and payouts as core rather than as reporting.

Cash Orders Run the Money Backwards

Run the same order again with one change. The customer chooses cash, and at the doorstep, instead of a tap releasing money you already control, the rider is handed 24.60 in notes.

The platform collected nothing, the restaurant is still owed its share, and the money for both is in a bag on a motorbike. In several large markets this is the majority of orders, which is why cash reconciliation belongs in the core rather than as a regional add-on.

The rider is briefly your debtor

From the moment the notes change hands, the rider owes the platform its portion of them, and the platform owes him his earnings for the shift. The two net off, and a rider carrying cash may end a shift owing you money.

Two controls make that workable and neither is optional: a running cash balance visible to the rider at all times, and a ceiling above which no further cash jobs are offered until he settles. Without the ceiling, your exposure to one rider grows all evening with nothing stopping it.

Float, exposure and the settlement moment

Settlement is the moment cash is handed over, at a hub or through a deposit matched against the balance. It produces a reconciliation: the balance the system says, the amount actually received, and a difference that is either zero or a conversation.

Small differences are normal and patterns are not. The system’s job is to make the pattern visible without anyone having to look, which is much of what separates a food delivery platform built for real markets from a demo that assumes everyone pays by card.

What a Refund Does to All Four Parties

Three hours later the customer reports that one curry was missing. This is the clearest test of whether the model is understood, because a refund is not one transaction reversed. It is four separate consequences and they do not cancel out.

The customer is made whole first

Whatever else is unresolved, she gets the value of the missing curry back and quickly, because the cost of a dish is almost always lower than the cost of the dispute and the lost account. A refund to the original card is clean but slow; credit on the platform is instant and cheaper for you, but it is not her money back.

The restaurant may or may not be charged back

A missing item is a kitchen error, so the value of the dish is deducted from that outlet’s next payout and appears on the statement with the order reference attached. That is the straightforward case, and most cases are not straightforward.

If the order arrived late and cold, that may be a dispatch failure and charging the restaurant is indefensible. If the same customer has reported a missing item on five of her last seven orders, the problem is none of the kitchens. Record a liability decision per refund, with a reason.

The rider is still paid, and somebody absorbs the rest

The rider collected the bag, carried it and handed it over, so his earning stands. Deducting from riders for kitchen errors is the fastest way to lose the riders who care.

That leaves arithmetic. The customer got money back, the rider was paid in full, and the restaurant was charged for the dish but not for the commission or the delivery, so somebody is short and that somebody is the platform.

The Four Parties, and What This Platform Is Not

Having followed one order through, the four parties look different from how they look in a pitch deck. None are buying software, and each leaves when the one thing it is buying stops arriving.

What each party is actually buying

The customer is buying the absence of a decision she has to manage, so anything that makes her chase or explain is a failure even when the food arrives on time. The rider is buying earnings per hour, not per job, and a well-paid job with a nineteen minute counter wait pays badly in the only unit he counts.

The restaurant is buying incremental orders at a predictable cost on a schedule it can plan around; it will never complain about your payout cycle, it will simply stop pressing accept on a Friday. The operator is buying a margin that survives refunds, waiting time and surge payments, which is what Which Features Does a Food Delivery Dispatch App Need for Order Assignment, Rider Tracking, and Fleet Control? assembles in one product.

Against a direct ordering page

A restaurant’s own ordering page has two parties, not four. The customer pays the restaurant, the restaurant is the merchant of record, and there is no commission to calculate and no payout run at all.

What it cannot do is deliver. The moment it needs a rider it has to acquire one, price the job, assign it, track it and pay it, which is why such pages either stay collection-only or rent dispatch from somebody else.

Against a discovery-led listings site

A listings site solves the half of the journey this article deliberately skipped. It helps the customer decide, hands the order to the restaurant and steps back: no rider, no assignment, no cash float, no payout run.

That is a real business and a lighter one. Choose which half you want to own; the delivery half is where a white label food delivery app saves the most time, and Ready-Made Delivery Food delivery dispatch app vs Custom Development: What Should Food Delivery Startups Choose? is worth reading before you commit.

Final Thoughts: One Order Contains the Whole Business

What Grubhub operates is a settlement pipeline with a map on the front of it.

Forty four minutes passed between a tap on a sofa and a bag changing hands at a door. In that time money was reserved but not taken, a kitchen made a commitment it could not revise, and seven minutes of invisible lateness were created at a counter. Nine days later, a restaurant received a transfer that had to explain itself.

If you can follow that sequence and say who holds the money at each step, you can explain this business without notes. Most people working in delivery cannot, because the front half is visible and the back half, where margin is decided, is not.

None of the pieces are exotic: authorization and capture, named timestamps, a waiting rule, a liability decision per refund, a reconcilable statement, a cash ceiling. They are rarely built together, which is why a purpose-built delivery dispatch app exists rather than a checkout bolted onto a menu. Our delivery scope and timelines separate what is ready-made from what is not, and you can book a working session to map your own version of these forty four minutes.

FAQs