One Back Office for Orders, Couriers, WhatsApp and COD
A custom operations portal now runs Darjaah's cash-on-delivery business in Saudi Arabia. Orders arrive from six channels and go through call-centre confirmation, courier booking, live tracking, inventory and COD reconciliation in a single system.
Darjaah, Saudi Arabia
E-commerce, dropshipping & COD fulfilment
Custom Web Portal, API & Webhook Integrations, WhatsApp Automation
ASP.NET MVC 5, ASP.NET Web API, SQL Server
Darjaah is a Saudi-based e-commerce, dropshipping and cash-on-delivery fulfilment business. It sells through its own Shopify store and also ships for third-party merchants (3PL) and resellers. Most orders are paid in cash at the door, so the business depends on confirming orders quickly, getting them to the right courier, and collecting and reconciling the cash afterwards.
We built the Darjaah Portal to cover the whole order lifecycle. It has two parts: an ASP.NET MVC back office used by operations, call-centre and finance staff, and a Web API integration hub. The hub receives store orders and courier updates, sends WhatsApp notifications and serves the driver mobile app.
A short walkthrough of orders, courier labels and WhatsApp updates.
Order channels in one queue: Shopify, YouCan, WhatsApp, Excel import, single manual orders, and API / mobile app
Courier and COD partner integrations: iMile, SMSA, Shipa, JD Logistics and CODSolutions
Application controllers: 55 in the portal and 16 in the webhook and integration API
Database tables behind orders, inventory, couriers, stores, payouts and users
Country time zones supported, with KSA time as the operating default and SAR as the main currency
These figures describe the delivered system and are taken from the codebase, not business performance metrics. Dashboard numbers in the screenshots are sample data.
Darjaah's orders came in through several storefronts and messaging channels. Each courier used its own booking API, label format and status names. Before an order could ship, a call centre had to reach the customer and confirm it, and duplicate orders had to be caught first. After delivery, cash collected by couriers had to be matched against delivery charges and paid out to the right merchant.
Doing this across spreadsheets and courier dashboards made it slow to see where an order was, easy to mismatch statuses, and hard to reconcile COD. The business needed one system of record from the first order to the final payout.
Every channel, courier and payment flows through one order model and one shared status workflow.
Shopify store webhooks, YouCan orders, WhatsApp orders, Excel bulk uploads, single manual orders and the REST API all write to the same order model. A duplicate detection service flags repeat orders before they reach the call centre. The Order Management screen gives staff one place to search by order number, phone or AWB, filter by status and act on any order.
Orders move through a defined status workflow. It runs from Unconfirmed and Confirmed, through Supplier Assigned, Branch Courier Assigned and Out for Delivery, to Delivered, Returned or Cancelled. Confirmation is also pushed to an n8n call-centre (CSR) workflow and synced back through an API, so agents work from the same data as operations.
Access is controlled through ASP.NET Identity roles. The sidebar menu is built from the database by a navigation builder, and stores and pages are assigned to each user. Grid columns can be hidden by role, so each team sees only the data it needs.
From the Label Creation screen, staff select orders, choose a courier and create the shipment through that courier's API. The portal supports iMile, SMSA, Shipa and JD Logistics, which uses OAuth waybills. It then prints barcode labels. For couriers that only send Excel files, a column and status mapping tool converts their reports into Darjaah statuses.
A separate Web API project receives status webhooks from iMile, Shipa, JD Logistics and CODSolutions, with signature checks where the courier provides them. It maps each status to the Darjaah workflow and keeps a full status history.
Customers get WhatsApp messages at each key step. Their replies and shared locations come back into the order, and locations are reverse-geocoded to help drivers. The same API serves the driver mobile app for dispatch and return (RTO) batches, and provides public tracking endpoints.
An inventory ledger records each SKU movement by warehouse: stock received, dispatched, returned and transferred. Separate ledgers cover 3PL clients.
On the finance side, the portal updates COD amounts and delivery charges, builds merchant payout invoices, exports them to PDF and marks them paid with proof of transfer. A SKU performance report shows confirmation, delivery and return rates by product, store and date range.
Screens rebuilt with the portal's own theme and filled with sample data. Select any screen to enlarge it.
Putting every channel into one order model gave operations a single queue and a single status history for each order.
Mapping each courier's statuses to one shared workflow is what makes tracking, WhatsApp updates and COD reconciliation reliable.
A separate webhook API keeps courier and store traffic away from the staff-facing portal and gives the mobile app a stable endpoint.
Courier credentials, signatures and messaging keys should be kept in configuration or a secrets store, not in source code, as the integration surface grows.
