Building a restaurant's own ordering infrastructure

The starting point

A restaurant's biggest problem with online ordering is usually not technical but economic: marketplace platforms take a commission on every order, and the customer data never reaches the restaurant. Her Mutfak wanted out of that loop.

The decision was to use WooCommerce as the core rather than write ordering software from scratch. Cart, stock, order status, tax and refunds are all mature in WooCommerce. What had to be written was the part the core does not know: meal cards, kitchen screens, couriers and shift staff.

The site was split in two. The menu and marketing side, hermutfak.com, is static HTML; the ordering side, siparis.hermutfak.com, runs on WordPress. Marketing pages therefore carry none of WordPress's weight, and the ordering system takes no risk every time a landing page changes.

Meal-card payments

In Turkey a large share of office workers pay for lunch with meal cards such as Multinet, Sodexo or Setcard. A restaurant ordering site that cannot accept them loses a significant part of its audience at the first step. None of these cards ship with WooCommerce.

So a custom WooCommerce payment gateway was written for Multinet. It extends WC_Payment_Gateway and manages this flow:

• Showing the meal card as its own payment method at checkout
• Sending a transaction-start request to the provider and redirecting the customer to its verification screen
• On return, confirming with the provider that the transaction really was approved — information coming from the customer's browser is never trusted; the status is queried server-side
• Marking the WooCommerce order paid on approval so it reaches the kitchen
• Leaving the order unpaid on failure or cancellation, with a message the customer can understand

The last two points are the critical ones. The most common mistake in payment integrations is reading the parameters on the URL the provider redirects to and treating the order as paid. That URL passes through the customer's browser and can be edited. The correct behaviour is a separate server-to-server query on return to learn the real transaction state. That is how this flow was built.

The kitchen panel

The real problem starts after the order is placed. WooCommerce's admin order list was designed for an e-commerce warehouse, not for a kitchen worker standing at a screen with both hands full.

So a separate kitchen panel was built. Its design decisions came straight from watching the kitchen:

• Today only. The panel shows only the current day's orders by default. Yesterday's orders do not clutter the screen.
• Waiting time and colour. Every order shows how long it has been waiting, and the card changes colour as the wait grows. Staff see the late order without reading the list.
• NEW badge. An incoming order is clearly marked so it is not missed during a rush.
• Flicker-free refresh. The panel refreshes regularly, but the first version redrew the whole list each time and the screen flickered. Refresh was changed to update only the cards that actually changed.

The real engineering in a panel like this is not on the data side; it is in keeping the screen readable during a busy service.

Courier and delivery

Once an order is ready it has to move to distribution. A webhook integration passes the order to the courier system when the WooCommerce order status reaches the relevant stage, handing delivery to a separate system.

The integration was written as its own plugin for maintainability: when the delivery provider changes or the contract ends, one plugin is disabled. Nothing else in the ordering system is touched.

Staff permissions

Not everyone who opens the panel should see the same thing. Someone on shift needs to manage orders; they do not need daily revenue, sales reports or the full customer database.

So role-based limited staff access was set up, driven by predefined permission presets. A user in the staff role can run the order flow, while revenue and reporting screens are hidden for those roles. Because it sits on WordPress's own capability system, adding a new staff member is just assigning a role.

Speed and mobile

The overwhelming majority of food orders come from phones, often on mobile data. Performance here is not cosmetic — it is lost orders.

• Image format. Server-side WebP generation was enabled on upload. Food photography is the heaviest asset on this site; the format change alone is a serious win.
• LCP preload. The first large visible image (the Largest Contentful Paint element) is announced to the browser with preload, so it starts fetching without waiting for CSS.
• Logo-induced layout shift. The header logo had no declared size, so content jumped while the page loaded (Cumulative Layout Shift). Fixed with explicit dimensions.
• Live open/closed badge. The badge showing whether the restaurant is currently taking orders has to be correct even when the page is served from cache. It was therefore made a separate component that fetches live data independently of the rest of the page. A cached page saying "open" while the restaurant is closed is one of the most common — and most complained about — failures on sites like this.

Result

Her Mutfak now takes orders on its own domain, with its own payment methods and its own customer data. The system is live and in active use.

The transferable lesson: when building a restaurant ordering system, writing software from scratch is rarely the right call. The right call is to take a mature core (WooCommerce) and custom-build only what that core does not know — meal cards, kitchen screens, couriers, shift staff. Maintenance stays small and the system can grow with the restaurant.