DeliveryKing Documentation
DeliveryKing documentation for setup, orders, menu management, opening times, payments and technical interfaces.
What is DeliveryKing?
DeliveryKing is a WordPress ordering system for restaurants, delivery teams and caterers. It combines menu, cart, checkout, opening hours, delivery areas, payment methods and order status in one plugin.
The focus is real operation: orders should arrive clearly in the backend, be easy to process and, when needed, continue into receiver software.
The WordPress dashboard adds comfort functions such as quick closing, delivery and pickup mode, holidays, item pauses, disabled items and daily metrics.
Installation and basic setup
Install DeliveryKing like a normal WordPress plugin through Plugins -> Add New -> Upload Plugin. After activation, the DeliveryKing area appears in the WordPress backend.
Start with business data, default currency, order email addresses and the pages for menu, cart, checkout and success state.
If these pages are missing, create them before launch and check the shortcodes or block output in the frontend.
| Step | Why it matters |
|---|---|
| Activate plugin | Enables backend menus, shortcodes and order logic. |
| Set business data | Keeps emails, prices, taxes and sender details correct. |
| Check order pages | Prevents empty cart, checkout or success pages in the frontend. |
Quick Start: first test order
The fastest path starts with the assistant and then moves through the core screens: General, Opening Hours, Menu, Delivery Areas, Payment and Orders.
The goal is not perfect live operation yet. The goal is one complete test order with realistic data. Design, automation and fine tuning can follow after that.
| Step | Result |
|---|---|
| 1. Start assistant | Business basics, pages and the initial structure are prepared. |
| 2. Check General | Name, address, order intake, social media and operation mode are correct. |
| 3. Set opening hours | Delivery and pickup are available during the test window. |
| 4. Create menu content | At least one active category and one active item can be ordered. |
| 5. Set delivery area and payment | Address rules, minimum order value and at least one payment method work. |
| 6. Place a test order | The order appears in the backend and can move through the status flow. |
Opening hours and delivery logic
Define when orders are allowed and whether delivery, pickup or both are available. Opening hours, lead times, delivery areas and minimum order values should be realistic before the first test order.
Test edge cases: shortly before closing time, outside delivery hours, below the minimum order value and with an address outside the delivery area.
Process orders
Incoming orders land in the order dashboard. From there, status, customer details, line items, payment method and internal notes can be checked.
Use status changes consistently so kitchen, drivers and support see the same state. That reduces follow-up questions during service.
| Status | Typical meaning |
|---|---|
| New | The order arrived and needs review. |
| Processing | The order was accepted and is being prepared. |
| Completed | The order was picked up, delivered or finally recorded. |
Payment methods and mail log
Enable only payment methods the operation actually offers. For local restaurants, cash, card on pickup or external payment flows are often more useful than a heavy shop checkout.
The mail log helps when customers or operators do not receive confirmations. For problems, check recipient address, sender configuration and spam filtering first.
REST API and LegacyBridge
DeliveryKing can expose order data to receiver software. The REST API is the modern interface, while LegacyBridge exists for older receivers.
Enable interfaces only when needed and document which external system uses which credentials. After changing API access, always run a test order.
Backend screens overview
DeliveryKing separates daily work into focused screens. Operators usually work with Dashboard, Menu, Opening Hours and Orders. Agencies also use Design, Frontend Builder, Import/Export, Mail Log, Scheduled Tasks and Technical Settings.
The backend view can be switched between Simple, Advanced and Expert. Some diagnostic and maintenance screens only appear in Expert view.
Pre-launch test
Before launch, run at least one complete delivery test and one pickup test. Check frontend, backend, emails, status changes and external receivers.
Use a real mobile view. Restaurant orders often happen on the move, and small display issues show up there faster than on desktop.
| Check | Expected result |
|---|---|
| Menu | Items, prices and images are visible and correct. |
| Checkout | Required fields, time selection and payment method work. |
| Backend | The order appears with all items and customer details. |
| Notification | Customer and operator receive matching emails. |