Just Eat-style Takeaway Marketplace — Custom-Built for Your Market

The diner has paid, but the takeaway has not accepted the order

A family orders two pizzas, selects different bases and pays. The restaurant terminal loses its connection before the kitchen sees the ticket. The customer sees a confirmation, calls the takeaway and learns that no meal is being prepared. This is the decision a takeaway marketplace must make understandable: payment activity, order transmission and restaurant acceptance are different facts. A reassuring success screen cannot stand in for a kitchen commitment.

A Just Eat-style takeaway marketplace connects diners with independent restaurants for collection and delivery. The proposed product is independently branded software, not access to Just Eat restaurants, couriers, proprietary systems or support. Its value depends on accurate menus, a reliable acceptance loop and an accountable response when dinner cannot be supplied. Start the buying decision with how participating kitchens work, not with the number of restaurant cards a homepage can display.

Make restaurant acceptance visible rather than implied

The official Just Eat Ireland rejected-order guidance identifies capacity, unavailable items and courier availability as reasons an order may be declined. This illustrates why rejection is a normal operating path. Its regional payment guidance is not a refund promise for your marketplace; agree your own lawful terms and provider handling before launch.

Show whether the request is awaiting acknowledgement, accepted, declined or expired. Each status needs an owner and a customer-facing explanation. A terminal receipt means the message arrived; it does not necessarily mean staff have accepted the preparation obligation. Decide who can accept, what information they must review and when the response becomes final. If capacity is unavailable, the kitchen should decline clearly instead of keeping the diner waiting behind an optimistic countdown.

Keep the branch menu aligned with the kitchen that receives it

A restaurant group can share a name while branches differ in prices, stock, opening hours and equipment. Bind the basket to the selected branch and menu version. Check availability again at submission, then preserve the purchased configuration for staff and support. A later menu edit should not change what the diner ordered. Give branch users only the authority they need; one manager disabling an item should not accidentally close every restaurant in the group.

Define who updates the menu when the POS feed and order terminal disagree. Do not silently merge incompatible prices or assume a successful synchronization means the kitchen can make every item. A controlled walkthrough should remove a popular dish while a customer has it in their basket. The result should identify the affected item and explain the available choice without accepting an impossible order or replacing dinner automatically.

Treat modifiers as preparation instructions with limits

A pizza base, required size and optional topping are not interchangeable text notes. Model required groups, minimum and maximum choices, price changes and incompatible combinations. Validate the same rules on the customer screen and the server. Keep each selection attached to its specific item so two similar meals remain distinguishable on the kitchen ticket. A note such as “no cheese” should not become an unnoticed substitute for a required structured choice.

Allergen information needs an accountable restaurant source and a way to ask before committing. Do not infer safe consumption from a modifier name or advertise an allergy guarantee from a generic menu flag. Surface relevant limitations and review local food-information obligations with qualified advisers. Staff should see the submitted instructions clearly, including when a printer truncates long text or a terminal reconnects. The buyer should inspect the actual kitchen view, not only the basket summary.

Collection needs its own readiness promise and handover

A customer collecting dinner needs the correct branch address, collection hours and an understandable readiness estimate. Restaurant opening hours alone do not prove a collection slot is available. Distinguish an estimated ready time from staff confirmation that the meal is packed. Explain changes promptly, preserve the earlier promise and let operations see whether the diner has already travelled. The interface should not instruct a customer to drive to a branch that has declined the order.

Agree how staff identify the collecting customer and record handover without exposing unnecessary personal information. A no-show, a wrong-person collection and a meal still waiting on the counter require different review. Define the food-handling and financial policy for each case rather than inventing a universal cancellation charge. Customer collection should not create a courier job, transport fee or delivery-location tracking simply because those components exist elsewhere in the system.

Declare whether the restaurant or the platform delivers

A restaurant-operated driver and a platform-assigned courier create different operational responsibilities. State the fulfillment party before checkout and keep it visible to support. Restaurant delivery may rely on a branch-controlled service area and manual updates; platform delivery needs eligible courier capacity and a dispatch process. Neither model should display precise live tracking unless the required data and permissions actually exist. Define which party communicates delays and investigates an undelivered meal.

If a diner changes from collection to delivery, revalidate address eligibility, charges and capacity instead of relabelling the same order. A kitchen acceptance does not establish transport availability. Compare a delivery-first alternative through the Grubhub-style fulfillment comparison when transport ownership is the primary scope decision. For this takeaway model, keep the restaurant acceptance loop central and add courier orchestration only where the operator can support it.

Recover terminal outages without preparing dinner twice

An acknowledgement can be lost after the kitchen accepts. Retrying the message must recover that acceptance rather than print a second preparation ticket. Use stable order identifiers, request versions and durable event handling. Decide how staff recognize retries and how the customer regains the current state after reconnecting. If the acceptance deadline passes, a late response needs review; it must not revive an already cancelled order silently.

Define an outage procedure that the merchant can actually operate during a busy shift. Pausing new orders, displaying an unavailable branch and routing unresolved requests to support may be safer than unlimited retries. Any telephone fallback must preserve the order identifier and authorized decision. Test the terminal offline before submission and immediately after acceptance. The expected result is one understood meal commitment or one explicit failure, not a queue of duplicate orders.

Rejected orders need a financial ending, not just a red label

The restaurant declines after payment authorization. Whether money was reserved, captured or still uncertain determines the next action. Agree the payment sequence with the provider and explain the result accurately to the diner. Releasing a reservation and refunding a captured charge are different operations. Keep provider references and pending outcomes visible. Do not promise immediate bank availability from an internal status change or copy another platform’s refund timetable.

A repeated rejection event must not issue repeated refunds. Match the original payment, permitted amount and reason before acting, then reconcile the provider response. If an event is missing, inspect the payment result instead of creating another charge to find out. A diner who starts a replacement order needs a new clear commitment, not a hidden reuse of the failed one. Support should be able to explain both orders without editing history.

Correct a missing item without erasing the accepted basket

The customer receives the main meal but not a paid extra. Preserve the original configuration, kitchen acknowledgement and fulfillment evidence while support reviews the claim. Define whether a remedy is a partial refund, replacement or another agreed action. A corrected receipt must distinguish the supplied items from the adjustment. Restrict staff authority and record the reason so the diner remedy, restaurant proceeds and platform accounting remain consistent.

Keep food concerns separate from transport evidence. A collected bag does not prove every modifier was prepared correctly, and a refund does not close a food-safety report automatically. Limit personal data shared with restaurants and couriers to what the reviewed process requires. Retain evidence under an appropriate policy and provide escalation for unresolved issues. Demonstrate a disputed extra and a wrong-branch complaint; these reveal more than a flawless sample order.

Price restaurant services against completed obligations

Specify what attracts a commission or service charge and how rejection, partial refunds and funded promotions change the settlement. A diner discount might be restaurant-funded, platform-funded or shared; store the agreed allocation rather than deducting every promotion from the takeaway by default. Sponsored restaurant placement needs clear disclosure and should not be confused with food quality or kitchen reliability. Commercial terms belong in the agreement, not in assumptions copied from a reference brand.

Reconcile the merchant statement with accepted, fulfilled and adjusted orders. Kitchen waiting costs and courier compensation need their own basis where relevant. Give finance a trail from basket charges to provider transactions and net settlement, including unresolved differences. Buyers should request a sample statement containing a declined basket and a partial remedy. A dashboard reporting gross order value alone cannot show whether the marketplace and its restaurants have been paid correctly.

Inspect handover evidence before promising dispatch accuracy

The official Just Eat UK courier reimbursement guidance distinguishes restaurant arrival from food collection and asks couriers to identify the order. This is a useful reference for separate handover events, not an entitlement to that network’s compensation scheme. Your contract and reviewed operation must define any waiting payment and the evidence used.

For platform delivery, capture which order was handed to which authorized courier and when staff confirmed release. Arrival near the branch is not collection. Avoid distributing full customer contact details before the courier has a legitimate task. For restaurant delivery, agree what the branch can report reliably and show missing evidence honestly. Do not draw a moving vehicle on the customer map when the restaurant only supplies a manual dispatched status.

Buy the acceptance and recovery loop, not a screenshot catalogue

Illustrative screens help explain discovery, basket choices and the merchant terminal; they are not proof of a connected restaurant network or a working POS adapter. Request a controlled walkthrough with sample data and sandbox payments. Submit an invalid modifier, disconnect the terminal, send a late acceptance and reject an authorized order. Inspect customer messages, kitchen tickets, operations queues and financial records together. Buyer acceptance should identify who resolves each failure.

Start with a defined restaurant set, a supported fulfillment policy and a documented financial closeout. Test readable mobile choices, keyboard operation, useful error messages and permission boundaries. The proposal should distinguish configured components, new engineering, provider dependencies and merchant responsibilities. Integration rights, source-code terms, operating access and handover documentation need explicit agreement. Expansion is easier to judge once one takeaway can accept, supply or refuse a basket without losing the customer or the money trail.

Bring a sample menu and a rejected-order scenario to a takeaway marketplace scope discussion so the acceptance rules and dependencies can be reviewed before implementation.

Use the delivery process to agree checkpoints for branch onboarding, terminal recovery, financial rehearsal and operational handover.