Direct Online Ordering for Restaurants: System Requirements

Define the channel and operating model

Define direct ordering here. The website might own discovery and checkout while a third party provides payment and delivery; it might send orders into a point-of-sale system; or use a hosted product. List every participant and state who owns the catalogue, customer relationship, transaction record, payment account, delivery promise, invoice, support case, cancellation decision, refund execution, and reporting.

Map entities, locations, and system authority

Build catalogue and modifier rules

Create stable identifiers for categories, items, variants, modifier groups, choices, prices, tax treatments, service periods, and eligible locations. The display name can change without breaking order history. Each modifier group needs minimum and maximum selections, dependency rules, price effects, defaults, and availability behaviour. Test realistic combinations: half-and-half choices, add-ons limited by size, required spice level, packaging options, and an item whose only required choice is sold out.

Keep the menu, cart, and kitchen interpretation aligned

• State the active restaurant or fulfilment location where useful
• Show modifier price changes before an item enters the cart
• Distinguish scheduled availability from a live sold-out state
• Preserve readable item and choice descriptions in order history
• Define what happens when a required modifier becomes unavailable
• Make essential menu facts available as text, not only imagery

For menu readability and information governance, pair these rules with the restaurant digital menu compliance India guide covering current applicability checks, mobile HTML, accessible interactions, and alternatives to image-only menus.

“An order payload should preserve the decision the guest made and translate it into instructions the correct kitchen can execute.”

Calculate serviceability, taxes, and totals

Determine serviceability before making a fulfilment promise. Use the complete delivery location, outlet eligibility, current hours, preparation capability, capacity rules, delivery coverage, cart constraints, and partner availability. Address lookup and map pins can help but need correction paths for new buildings, campuses, boundary roads, and ambiguous localities. Pickup needs its own outlet, timing, arrival, and collection instructions rather than being treated as delivery with a zero fee.

Make every total explainable

Calculate item prices, modifier charges, discounts, taxes, packaging, delivery, and other applicable amounts from governed rules. Show a useful breakdown before payment and preserve the rule context used for the transaction. Obtain qualified advice for tax classification, invoicing, discount treatment, and mandatory disclosures. A developer should not infer tax logic from a competitor's checkout. When the address, outlet, fulfilment method, or cart changes, recalculate and present material changes before confirmation.

Orchestrate payments and order states

Design payment and order as related but separate state machines. A payment can be initiated, pending, successful, failed, cancelled, reversed, or refunded while an order can be draft, submitted, awaiting acceptance, accepted, rejected, preparing, ready, dispatched, delivered, or cancelled. Use names that match actual provider and restaurant behaviour. Customer messages must not convert a pending callback into a confirmed order or imply kitchen acceptance merely because the bank completed a payment.

Prevent duplicates and reconcile delayed callbacks

Use stable attempt and order references plus idempotent server operations. Verify provider notifications through supported mechanisms and reconcile uncertain browser returns against authoritative server records. If a customer retries, detect the previous attempt before taking another payment or sending another kitchen ticket. Restrict access to credentials and refund functions, avoid sensitive payment data in logs or analytics, and monitor differences among provider settlements, commerce records, and accepted orders.

1. Create a durable checkout reference for the validated cart
2. Start payment through an approved provider integration
3. Verify and reconcile the result on trusted server channels
4. Create or advance the order exactly once
5. Request acceptance from the bound restaurant location
6. Display the resulting state without overstating completion
7. Escalate mismatches into an owned operations queue

Route kitchen and fulfilment handoffs

Bind each order to an eligible location before production. The routing decision can consider address, service mode, menu capability, hours, current acceptance, and capacity, but it should be deterministic and auditable. If rerouting changes items, amounts, timing, entity, or policy context, do not hide it. Record why the route changed and obtain customer confirmation where needed. Maintain a default exception queue for orders that match no rule.

Define acceptance and production evidence

Specify whether an order is accepted automatically, after a point-of-sale acknowledgement, or by kitchen staff. Set a monitored timeout and escalation. A sent webhook or printed ticket is not necessarily evidence that someone can prepare the order. Kitchen screens should show unambiguous item and modifier details, customer notes within approved limits, fulfilment method, promised context, and exception controls. Staff changes should flow back to customer care and the guest where appropriate.

• Monitor failed integrations and unacknowledged orders centrally
• Prevent the same order from printing or displaying as new twice
• Record accept, reject, pause, ready, dispatch, and collection events
• Define ownership when restaurant and delivery statuses disagree
• Protect customer contact details from unnecessary kitchen exposure
• Provide a manual recovery process with complete audit history

Delivery-only operations should also use the cloud kitchen website checklist to review kitchen models, zone uncertainty, licence content, analytics controls, and fallback channels in greater depth.

Handle cancellations, refunds, and support

Publish understandable cancellation and refund access, then encode only rules the authorised business owners approve. Eligibility can depend on order state, preparation, fulfilment, payment method, issue type, and applicable obligations. The interface should not make a final legal or commercial decision from a simplistic timer. Give staff the evidence and permissions needed to decide supported cases, record reasons, and communicate the outcome consistently.

Give support a shared, privacy-conscious order view

Customer care needs safe access to the catalogue snapshot, totals, payment references and state, restaurant acceptance, fulfilment events, messages, cancellation actions, and refund status. It should not need full payment credentials or unrestricted exports. Use role-based permissions, audit significant actions, mask information where practical, and define escalation to kitchen, finance, delivery, technology, or management. Automated messages must provide a reference and a route to help.

Evaluate ONDC boundaries and test release

ONDC is an open network using specifications and participant roles; it is not simply one marketplace, payment gateway, delivery company, or fixed-price website package. A restaurant may engage through seller-side participants and become discoverable through buyer applications, with other parties involved in fulfilment, grievance handling, reconciliation, and network obligations. The exact model depends on current participant agreements, policies, technology, and operating choices. Map those roles separately from the restaurant's own direct channel.

Consult the current ONDC Network Policy resources and obtain specialist advice before defining participant, data, grievance, payment, settlement, fulfilment, or compliance responsibilities. Policies, commercial terms, and participant offerings can change.

Compare current roles and complete costs

1. Test representative outlets, zones, items, modifiers and tax cases
2. Trace successful, pending, failed, duplicate and reversed payments
3. Simulate kitchen rejection, integration loss and delivery failure
4. Verify cancellation, partial adjustment, refund and support permissions
5. Check mobile, keyboard, screen-reader and slow-network journeys
6. Reconcile restaurant, payment, fulfilment, analytics and support records
7. Approve release only with owners for every unresolved exception

Explore our restaurant web development service, understand more about our implementation process, view relevant work in the portfolio, or send requirements through the contact page. Teams can also review support in Delhi restaurant web development, Mumbai restaurant web development, and Pune restaurant web development.