eMart — Multi-Service Delivery Platform (Ecommerce, Multivendor, On Demand, Parcel, Cab & Rental)

eMart includes several Flutter (Dart) applications — the Customer App, the Store App, the Delivery Boy / Driver App, the Service Provider App and the Worker App. Each is a separate project with its own source folder, package name and store listing, but they share one Firebase project and the setup below is identical for all of them: install Flutter once, then repeat sections 4–10 for each app. The official reference is docs.flutter.dev, but you should not need it to complete this guide.

3.1. System Requirements

• OS: Windows 10/11 (64-bit), macOS, or Linux. iOS builds require macOS + Xcode.
• Disk space: ~2.8 GB for the Flutter SDK (plus your IDE / Android Studio).
• Tools: Git, and PowerShell 5.0+ on Windows.

3.2. Install the Flutter SDK

1. Download the SDK for your platform from docs.flutter.dev.
2. Extract it to a path without spaces — for example C:\src\flutter on Windows, or ~/development/flutter on macOS/Linux.
3. Add the flutter/bin folder to your system PATH so the flutter command works from any terminal.

3.3. Install the Platform Toolchains

• Android: install Android Studio, then open the SDK Manager and install the Android SDK, the SDK Command-line Tools and the Platform Tools. Accept the licences with flutter doctor --android-licenses.
• iOS (macOS only): install Xcode from the App Store, run sudo xcodebuild -runFirstLaunch, then install CocoaPods with sudo gem install cocoapods.

3.4. Verify the Installation

Run the doctor command and fix anything it reports:

flutter doctor -v

Every item that matters for your target platform should show a green check.

3.5. Install the IDE Plugins

• VS Code: install the Flutter and Dart extensions.
• Android Studio: install the Flutter plugin (it pulls in Dart).

3.6. Open the eMart Project

Unzip the application source, open the app's folder in your IDE, and fetch the dependencies:

flutter pub get

3.7. Run the App

Start an emulator/simulator or connect a physical device, then run:

flutter devices
flutter run

Hot reload (r in the terminal) applies code changes instantly while the app keeps running.

The package name (Android) and bundle identifier (iOS) uniquely identify an app on the stores. Use reverse-domain form, and give each app its own identifier — they are published as separate listings and registered as separate apps in Firebase:

com.yourcompany.emart            ← Customer App
com.yourcompany.emart.store      ← Store App
com.yourcompany.emart.driver     ← Delivery Boy / Driver App
com.yourcompany.emart.provider   ← Service Provider App
com.yourcompany.emart.worker     ← Worker App

Change the identifier before registering the app in Firebase, because the Firebase config files are tied to it. The steps below apply to one app — repeat them in each project folder.

4.1. Change the Android package name

On current Flutter versions the identifier lives in android/app/build.gradle, not in the manifest. Open that file and change both values:

android {
    namespace = "com.yourcompany.emart"
    ...
    defaultConfig {
        applicationId = "com.yourcompany.emart"
        ...
    }
}

• namespace — the package the generated R class and MainActivity belong to.
• applicationId — the identifier Google Play and Firebase key off. This is the one that must match your google-services.json.
• On older projects the same value also appears as the package attribute of the <manifest> tag in android/app/src/main/AndroidManifest.xml (and in the debug / profile variants) — update it there too if your copy still has it.

4.2. Update the Android source-code references

Rename the folders under android/app/src/main/kotlin/ (or .../java/) to match the new package, and update the package declaration at the top of MainActivity.kt / MainActivity.java.

4.3. Change the iOS bundle identifier

• Open ios/Runner.xcworkspace in Xcode.
• Select the Runner project → Runner target → General.
• Set Bundle Identifier to your new identifier.

5.1. Prepare your new icons

Start from a single square PNG at 1024×1024, with no transparency for iOS.

• Android: replace ic_launcher.png inside each android/app/src/main/res/mipmap-* folder (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi), keeping the same file names and sizes.
• iOS: replace the AppIcon image set in ios/Runner/Assets.xcassets (open the project in Xcode and drop the sizes in).

5.2. Flutter launcher-icon package (recommended)

Generating every size by hand is error-prone. Add the helper package to pubspec.yaml:

dev_dependencies:
  flutter_launcher_icons: ^0.13.1

flutter_launcher_icons:
  android: "launcher_icon"
  ios: true
  image_path: "assets/icon/icon.png"

Then generate all sizes at once:

flutter pub get
dart run flutter_launcher_icons

This is the name shown under the launcher icon on the device.

6.1. For Android

Open android/app/src/main/AndroidManifest.xml, find the <application> tag and change android:label:

<application android:label="Your App Name" ... >

6.2. For iOS

Open ios/Runner/Info.plist and set both display keys:

<key>CFBundleDisplayName</key>
<string>Your App Name</string>
<key>CFBundleName</key>
<string>Your App Name</string>

The apps use Google Maps for store locations, address selection, cab and rental pick-up points and live driver tracking. Create the key first — see Create Google Map API Key — then add it to both platforms.

7.1. For Android

Open android/app/src/main/AndroidManifest.xml and set the key inside the <application> element:

<meta-data
    android:name="com.google.android.geo.API_KEY"
    android:value="YOUR_API_KEY_HERE"/>

7.2. For iOS

Open ios/Runner/AppDelegate.swift and set the key in didFinishLaunchingWithOptions:

GMSServices.provideAPIKey("YOUR_API_KEY_HERE")

Rebuild the app after changing the key on either platform.

All the apps talk to the same Firebase project as the web panels. Create the project first — see Create Firebase Project — then register every app inside it.

8.1. Register the apps

Repeat this for each app:

1. Open the Firebase console and select your project.
2. Click Add app → Android and enter that app's package name; add its SHA-1 and SHA-256 fingerprints (see Generate SHA Keys) — these are required for Google and Phone sign-in. Download google-services.json.
3. Click Add app → iOS and enter that app's bundle identifier. Download GoogleService-Info.plist. iOS does not need SHA fingerprints.

8.2. Place the config files

• Android: put google-services.json in android/app/.
• iOS: open ios/Runner.xcworkspace in Xcode and drag GoogleService-Info.plist into the Runner group (tick "Copy items if needed").

8.3. Configure with the FlutterFire CLI (alternative)

Instead of downloading the files by hand, you can let the FlutterFire CLI generate lib/firebase_options.dart for both platforms:

npm install -g firebase-tools
firebase login
dart pub global activate flutterfire_cli
flutterfire configure --project=YOUR_PROJECT_ID

The CLI writes a firebase_options.dart holding the per-platform configuration, which main.dart passes to Firebase.initializeApp():

import 'package:firebase_core/firebase_core.dart';
import 'firebase_options.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(MyApp());
}

8.4. Firebase dependencies

The Firebase plugins the app uses are already declared in pubspec.yaml — Core, Auth, Firestore, Storage, Messaging and Cloud Functions. Just fetch them:

flutter pub get

8.5. Enable the sign-in providers

In the Firebase console open Authentication → Sign-in method and enable the providers eMart uses:

• Email/Password — standard customer, vendor, driver and admin sign-in.
• Phone — OTP login (requires the SHA fingerprints on Android).
• Google — used by the apps and the web panels.
• Apple — required by Apple if you offer other social logins on iOS.

Then open Authentication → Settings → Authorized domains and add the domains of your Website, Store and Provider panels.

8.6. Website address used by the apps

The apps send push notifications and emails and delete accounts through the Website Panel, and pay through the payment Cloud Functions. They read the website address from Settings → Global Settings → Version → User Panel URL in the Admin Panel, so fill it in before testing the apps.

9.1. Using Gradle (recommended)

From the android folder of the project:

# macOS / Linux
./gradlew signingReport

# Windows
gradlew signingReport

The report lists the SHA-1 and SHA-256 values for each build variant.

9.2. Using Keytool

# Debug keystore
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystore
# Password: android

# Release keystore
keytool -list -v -keystore path/to/your-release-key.jks -alias your-key-alias

9.3. Add the keys to Firebase

1. Open Firebase Console → Project Settings → Your apps → Android app.
2. Click Add fingerprint and paste the SHA-1; repeat for the SHA-256.
3. Download the refreshed google-services.json and replace the one in android/app/.

Each app is published as an independent listing on each store, so this section runs once per app. You can sign all of them with the same keystore; only the package name, the store listing and the artwork differ.

10.1. Create a release keystore

Android release builds must be signed with your own keystore. Create it once and keep it safe — if you lose it you cannot update the app on Google Play.

keytool -genkey -v -keystore ~/my-release-key.jks -keyalg RSA \
        -keysize 2048 -validity 10000 -alias my-key-alias

• -keystore — where the .jks file is written.
• -keyalg RSA, -keysize 2048 — the signing algorithm and key length.
• -validity 10000 — validity in days (about 27 years).
• -alias — the name of the key inside the keystore.

You are prompted for a keystore password, a key password and your organisation details.

10.2. Reference the keystore from the project

Create android/key.properties (never commit this file):

storePassword=your-store-password
keyPassword=your-key-password
keyAlias=my-key-alias
storeFile=/Users/yourusername/my-release-key.jks

Gradle reads this file at build time, so the keystore password never lives in the tracked sources. Add android/key.properties and the .jks file itself to .gitignore.

10.3. Build a release version

# Android App Bundle (required by Google Play)
flutter build appbundle --release

# Android APK (for direct distribution / testing)
flutter build apk --release

# iOS (macOS only)
flutter build ipa --release

Outputs are written to build/app/outputs/ (Android) and build/ios/ipa/ (iOS).

10.4. Publish to Google Play

1. Create a developer account at the Google Play Console.
2. Create one Play app per eMart app and complete each store listing (title, description, screenshots, feature graphic, icon) plus its Data Safety, Content Rating and Privacy Policy sections.
3. Upload the .aab to a Production (or Internal Testing) release.
4. Increment version: in pubspec.yaml for every new upload — Play rejects duplicate version codes.
5. Submit for review.

10.5. Publish to the Apple App Store

1. Enrol in the Apple Developer Program.
2. Create the App ID and the app record in App Store Connect.
3. In Xcode set the team and signing certificates, then Product → Archive and upload with the Organizer (or upload the .ipa with Transporter).
4. Complete the listing, privacy details and App Review information, then submit for review.

What should I do if I get the error "Missing project_info object"?

This Android build error means the google-services.json file is missing, in the wrong place, or does not match the package name.

Solution

1. Check the file location. google-services.json must sit in android/app/ — not in android/ and not in the project root.
2. Check the package name. The package_name inside the JSON must match the applicationId in android/app/build.gradle. If you renamed the package, register the new one in Firebase and download the file again.
3. Verify the Firebase setup. Confirm the Android app is registered in the Firebase console under Project Settings → Your apps.
4. Update the Google Services plugin. Make sure the com.google.gms:google-services classpath in android/build.gradle is a current version.
5. Re-sync and rebuild. Sync Gradle in Android Studio, then run:

flutter clean
flutter pub get
flutter run

Payments or push notifications do not work in the app

• Deploy the Cloud Functions package (Deploy Firebase Cloud Functions); the apps pay through its payment functions.
• Fill the User Panel URL in the Admin Panel; the apps send push notifications and emails through the Website Panel at that address.
• Upload the service-account key in the Admin Panel (Admin Panel Setup, section 19.8).

The mobile apps read almost everything from Firebase, but a few things come from the web side. Before testing an app, make sure these are in place:

• Firestore demo data imported — the settings collection must exist (Firestore Import / Export).
• Cloud Functions deployed — delivery dispatch, account deletion and every online payment of the apps run there (Deploy Cloud Functions).
• User Panel URL filled in the Admin Panel under Settings → Global Settings → Version — the apps call the Website Panel at that address for push notifications (/api/send-notification), emails (/api/send-email) and account deletion (/api/delete-user), always with the user's Firebase ID token.
• Service-account key uploaded in the Admin Panel (section 19.8) so the website can send those notifications and emails.
• Payment gateways enabled under Settings → Payment Methods (Payment Gateway Setup); the apps only see which gateways are on and their public keys.
• Google Maps key in each app (Google Maps API Key (Flutter)) and in the Admin Panel.
• App version and store links under Settings → Global Settings → Version, so users are prompted to update.
• API Secure Key under Settings → Global Settings if you use the AI features from the apps.

All four web panels — Admin, Store, Provider and Website — are Laravel 13 applications and share the same server requirements. To run eMart smoothly your hosting must provide:

13.1. Server & Runtime

• Web server: Apache (with mod_rewrite) or NGINX.
• PHP 8.3 or above, with the extensions Laravel requires: BCMath, Ctype, cURL, DOM, Fileinfo, JSON, Mbstring, OpenSSL, PCRE, PDO, Tokenizer, XML, GD (or Imagick) and ZIP.
• The PHP functions proc_open, shell_exec and exec must not be disabled — the Admin Panel's scheduled tasks start Node.js with them (see Cron & Scheduled Tasks).
• MySQL 5.7+ / MariaDB 10.3+ — used for panel authentication, sessions and jobs. All platform data lives in Firestore.
• Composer for PHP dependencies.
• Node.js 18+ and npm — required by the Firebase CLI and by the scheduled scripts the Admin Panel runs from cron.
• FTP / SFTP or SSH access for transferring and extracting the packages.
• Cron job support for Laravel's scheduler.
• SSL certificate (HTTPS) — mandatory for Firebase Authentication, Google login and payment-gateway callbacks.

13.2. Domains

Each panel needs its own domain or subdomain, for example:

• https://yourdomain.com — Website (Customer) Panel
• https://admin.yourdomain.com — Admin Panel
• https://store.yourdomain.com — Store (Vendor) Panel
• https://provider.yourdomain.com — Provider Panel (On Demand add-on)

The Admin Panel stores these three addresses under Settings → Global Settings → Version (User Panel URL, Store Panel URL, Provider Panel URL). The mobile apps and the service-account distribution use them, so fill them in as soon as the domains exist.

13.3. External Services

• Google Firebase project upgraded to the Blaze plan (required for Cloud Functions and for outbound network calls).
• Google Maps API key with Maps JavaScript, Places, Geocoding and Directions enabled — used for store search, address selection, zones and delivery / ride tracking.
• SMTP account for outgoing email (order receipts, password resets, templates).
• Payment gateway accounts for the gateways you plan to enable.
• OpenAI API key (optional) for the AI product-listing features.

Node.js is needed for the Firebase CLI (indexes, rules and Cloud Functions), for the Firestore import/export utility, and for the scheduled scripts the Admin Panel executes.

14.1. Install Node.js

Download the LTS installer from nodejs.org/en/download and run it. npm is installed alongside Node. Verify:

node -v
npm -v

14.2. Find the Node binary path

The Admin Panel needs the absolute path to the Node executable so its scheduled commands can run. On Linux/macOS:

which node

On Windows:

where node

The command prints something like /usr/local/bin/node. Copy that value into the NODE_PATH variable of the Admin Panel's .env file:

NODE_PATH='/usr/local/bin/node'

On shared hosting Node is often installed through nvm; the path then looks like /home/username/.nvm/versions/node/v20.19.5/bin/node.

14.3. Install the Firebase CLI

npm install -g firebase-tools
firebase login

firebase login opens a browser window; sign in with the Google account that owns your Firebase project.

Firebase is the backend for the whole platform. Create one project and use it for the Admin Panel, the Store Panel, the Provider Panel, the Website Panel and every mobile app.

15.1. Go to firebase.google.com and click Go to console in the top-right corner.

15.2. Click Add project, enter a project name and click Continue. Choose whether to enable Google Analytics, select the default account for Firebase, then click Create project.

15.3. From the project overview, click the Web (</>) icon to register a web app.

15.4. Enter an app nickname and click Register app. Scroll down to the configuration snippet and copy the values — these are the FIREBASE_* credentials you will paste into every panel's .env file.

The same values can be read again at any time from Project Settings → General → Your apps:

15.5. In the left sidebar open Firestore Database and click Create database. Pick a location close to your users and start in the mode you prefer — the rules are replaced in step 15.9.

15.6. Open Realtime Database and click Create Database. It is used for live driver and cab location tracking.

15.7. Open Storage and click Get started. Firebase Storage holds all uploaded images — store and product photos, banners, avatars and verification documents.

15.8. Open Authentication → Sign-in method and enable Email/Password, Phone, Google and, for iOS, Apple. Under Authentication → Settings → Authorized domains, add the domains of your Website, Store and Provider panels.

15.9. Security rules. Do not publish open rules (allow read, write: if true) in the console. eMart ships its Firestore and Storage rules as files inside the Cloud Functions package (firestore.rules, firestore.rules.strict and storage.rules). They are deployed with the Firebase CLI after the panels are installed and the service-account key is uploaded — see Deploy Firebase Cloud Functions, section 18.6. Until then the database may keep the rules the console created it with.

15.10. Upgrade the project to the Blaze (pay-as-you-go) plan. Cloud Functions and any outbound call to a payment gateway require it.

15.11. Generate the service account key. Open Project Settings → Service accounts, choose Node.js and click Generate new private key. A JSON file downloads — you will upload it once in the Admin Panel (which installs it on every panel as storage/app/firebase/credentials.json), and use it for the import/export utility.

See Video:

The product ships with a demo dataset (settings, sections, categories, currencies, email templates, CMS pages and sample stores). Import it so the panels start with working defaults instead of empty screens.

16.1. Install Node.js if you have not already — see Installing Node.js & npm.

16.2. Unzip the source file named "Firebase Import Export Collections.zip".

16.3. Create your Firebase project first if you have not — see Create Firebase Project.

16.4. Replace credentials.json in the extracted folder with the service account key you generated in step 15.11.

16.5. Open a terminal in the extracted folder. On Windows, hold Ctrl+Shift, right-click inside the folder and choose "Open PowerShell window here".

16.6. Run the import or export command:

# Import every collection into your Firestore
npx -p node-firestore-import-export firestore-import -a credentials.json -b collections.json

# Export every collection out of your Firestore
npx -p node-firestore-import-export firestore-export -a credentials.json -b collections.json

The export writes a collections.json file you can keep as a backup.

See Video:

Firestore needs a composite index for every query that filters and sorts on more than one field. eMart uses many of these (nearby stores, order lists, rides, reports), so deploy the supplied index definitions before going live — otherwise those screens fail with "The query requires an index".

17.1. Install Node.js — see Installing Node.js & npm.

17.2. Unzip the source file named "Firebase Indexing.zip".

17.3. Open a terminal in the extracted folder (Ctrl+Shift + right-click → "Open PowerShell window here" on Windows).

17.4. Log in to Firebase, if you have not already:

firebase login

17.5. Initialise Firestore configuration in the folder:

firebase init

17.6. Confirm with Y and press Enter.

17.7. Choose Firestore: Configure security rules and index files for Firestore.

17.8. Choose Use an existing project.

17.9. Select your eMart project.

17.10. Press Enter to accept the default rules file name (firestore.rules).

17.11. Press Enter to accept the default index file name (firestore.indexes.json).

17.12. Open the generated firestore.indexes.json, delete its contents, and paste in everything from the supplied firestore_indexes.json file.

17.13. Deploy the indexes:

firebase deploy --only firestore:indexes

Building the indexes takes a few minutes. Watch the progress in Firebase Console → Firestore Database → Indexes and wait until every index shows Enabled.

See Video:

The Cloud Functions eMart needs are already written — you only have to deploy them to your own Firebase project. The package deploys:

• deliveryDispatch — a Firestore trigger on the vendor_orders collection. It runs whenever a delivery order is written and drives the driver-assignment flow, following the broadcast or sequential mode you chose under Settings → Driver Nearby.
• deleteUser — a callable function that removes a user from Firebase Authentication when an account is deleted. Only the signed-in user themselves or an admin may call it.
• The payment functions the mobile apps call (one create and one verify function per gateway, plus paymentGateways) — see section 18.7.

Without this package deployed, delivery orders are created but never dispatched to a driver and the apps cannot take online payments, so deploy it before going live. The same package also carries the Firestore and Storage security rules (section 18.6).

gcloud services enable compute.googleapis.com cloudbuild.googleapis.com \
  artifactregistry.googleapis.com run.googleapis.com eventarc.googleapis.com \
  cloudfunctions.googleapis.com --project=YOUR_PROJECT_ID

18.1. Install Node.js and the Firebase CLI

npm install -g firebase-tools

18.2. Log in to Firebase

firebase login

A browser window opens; sign in with the Google account that owns your Firebase project.

18.3. Point the package at your project and database

Extract the supplied Cloud Functions package. It contains:

Cloud Function/
├── firebase.json                deploy configuration: functions + the database the rules go to
├── .firebaserc                  which Firebase project to deploy to
├── firestore.rules              Firestore security rules (deploy now)
├── firestore.rules.strict       stricter rules for after the mobile apps are updated
├── storage.rules                Storage security rules
├── README.md                    short deploy guide
└── functions/
    ├── .env                     which Firestore database the functions use
    ├── index.js                 the function list (one line per function)
    ├── products/delivery.js     the delivery-order dispatch trigger
    ├── products/payments.js     the payment functions for the apps
    └── package.json             dependencies (Node 22 runtime)

Step 1 — set the project. From the folder containing firebase.json:

firebase use YOUR_PROJECT_ID

This writes .firebaserc for you. Run firebase projects:list if you are unsure of the exact project ID. You can also edit .firebaserc by hand:

{
  "projects": {
    "default": "YOUR_PROJECT_ID"
  }
}

Step 2 — set the database. Open functions/.env and set DATABASE to the Firestore database your panels use. Keep (default) unless you deliberately created a named database:

DATABASE=(default)

If you use a named database, also change "database" in firebase.json so the rules are deployed to the same one.

Step 3 — install the dependencies:

cd functions
npm install
cd ..

No service-account file is needed inside this package: the deployed functions run with your project's own Firebase identity.

18.4. Deploy the functions

Run this from the folder containing firebase.json — the root of the extracted package, not the functions/ sub-folder:

firebase deploy --only functions

When the deploy finishes, open Firebase Console → Functions to confirm every function is listed. Each function has its own logs, which are the fastest way to debug a failing order or payment.

18.5. Payment functions do not need a redeploy for key changes

The payment functions read the gateway keys from the settings you save in the Admin Panel, so rotating a gateway key or enabling a new gateway never requires a redeploy. To remove a gateway from the package, delete its lines in functions/index.js and deploy again.

18.6. Deploy the Firestore and Storage security rules

Deploy the rules after the Admin, Store, Provider and Website panels are installed and the service-account key is uploaded (Admin Panel Setup, section 19.8). Panels older than version 6.9 do not work with these rules, so update the panels first.

firebase deploy --only firestore
firebase deploy --only storage

In PowerShell, quote combined targets: firebase deploy --only "firestore,storage". The Firestore rules go to the database named in firebase.json.

Once the mobile apps are updated to version 6.9 or later, rename firestore.rules.strict to firestore.rules and deploy again. The strict rules keep every setting that holds keys private to the server; apps from version 6.9 use the payment functions and the website API instead.

18.7. Payment functions

The mobile apps pay through these functions instead of calling the gateways directly. Each gateway has a pair of callable functions in functions/products/payments.js: one creates the order, intent, invoice or payment link on the server and returns only what the app's SDK or web view needs; the other verifies the payment with the gateway. paymentGateways returns the on/off flag, the sandbox flag and the public keys of every gateway for the payment-method list. All functions need a signed-in Firebase user. The full list is in the package's README.md.

After deploying: make sure the app functions are reachable

The apps call these functions over HTTPS, so the Cloud Run service behind each callable function must allow public access. Sign-in is still enforced: the function itself checks the Firebase user and rejects anyone who is not logged in. The Firebase CLI sets this permission when it creates a function, but on a large first deploy it sometimes fails for a few of them and prints Unable to set the invoker for the IAM policy on the following functions. Deploying again does not repair it. The apps then get [firebase_functions/unauthenticated] UNAUTHENTICATED for those gateways while the other gateways work. To check and fix:

1. Open Google Cloud Console → Cloud Run → Services for your Firebase project.
2. Look at the Authentication column. Every payment function and deleteuser must say Public access. Only deliverydispatch (a Firestore trigger) stays on Require authentication.
3. Tick every function that says Require authentication (not deliverydispatch), click Permissions in the top bar, then Add principal.
4. New principals: allUsers. Role: Cloud Run → Cloud Run Invoker. Click Save and confirm Allow public access.

Nothing needs to be redeployed. The same can be done from the command line (service name = function name in lower case):

gcloud run services add-iam-policy-binding razorpaycreateorder --region us-central1 --member allUsers --role roles/run.invoker

18.8. Scheduled scripts run by the Admin Panel

Recurring tasks that do not need a Cloud Function run from the Laravel Admin Panel instead, so you can control their timing from the panel. The scripts live in:

root > storage > app > firebase

1. multivendorOrderAutoCancel.js — cancels multivendor orders that were never accepted.
2. multivendorScheduledOrderNotification.js — sends reminders for scheduled orders.
3. parcelOrderAutoCancel.js — cancels parcel orders that were never accepted.
4. rentalOrderAutoCancel.js — cancels rental orders that were never accepted.
5. onDemandOrderAutoCancel.js — cancels old on-demand bookings.
6. cabScheduleRide.js — assigns cab rides to drivers (sequential or broadcast).

Important notes

1. These scripts are executed by Laravel's scheduler, which needs a server cron job — see Cron & Scheduled Tasks.
2. They talk directly to Firebase Firestore using the panel's storage/app/firebase/credentials.json.
3. Their timing values come from the Admin Panel settings (auto-cancellation durations, the driver radius and the accept/reject time under Settings → Driver Nearby).

See Video:

The Admin Panel is a Laravel 13 application. Make sure your server meets the requirements in Server Requirement, then upload the Admin Panel package to your domain or subdomain and extract it.

19.1. Upload the files

19.1.1. Connect over FTP/SFTP. Use a client such as FileZilla with your server IP, username and password — port 21 for FTP, port 22 for SFTP.

19.1.2. Transfer the ZIP file to the target path on the server, for example /var/www/html.

19.1.3. Extract it from the server terminal, or with the cPanel File Manager:

unzip your-application.zip

19.1.4. Point the domain's document root at the project's public/ folder.

19.2. Create the database

The admin panel uses MySQL only for panel authentication (users, roles, permissions), sessions and jobs — every piece of platform data lives in Firestore. Create a database and user from your control panel, then import the supplied .sql file into it (step 19.3.6).

19.2.1. Open MySQL Databases in cPanel.

19.2.2. Enter a name and create the database.

19.2.3. Create a database user with a strong password.

19.2.4. Add the user to the database, grant ALL PRIVILEGES, and click Make Changes.

19.3. Configure the panel

19.3.1. Install the dependencies and generate the application key:

composer install
cp .env.example .env
php artisan key:generate

19.3.2. Edit .env and set the database connection and your Firebase web app credentials (copied in step 15.4):

APP_NAME=eMart
APP_URL=https://admin.yourdomain.com

DB_DATABASE=your_database
DB_USERNAME=your_db_user
DB_PASSWORD=your_db_password

# Firestore named database — '(default)' unless you created a named one
FIREBASE_PROJECT_DB=(default)

FIREBASE_APIKEY=
FIREBASE_AUTH_DOMAIN=
FIREBASE_DATABASE_URL=
FIREBASE_PROJECT_ID=
FIREBASE_STORAGE_BUCKET=
FIREBASE_MESSAAGING_SENDER_ID=
FIREBASE_APP_ID=
FIREBASE_MEASUREMENT_ID=

# Absolute path to the Node binary — used by the scheduled scripts
NODE_PATH=''

# Timezone
APP_TIMEZONE='Asia/Kolkata'

19.3.3. Install the Node modules the scheduled scripts need, from the panel root:

npm install

19.3.4. Set NODE_PATH in .env to the absolute path of your Node binary — see Installing Node.js & npm.

19.3.5. The Firebase service account file (storage/app/firebase/credentials.json) is installed later from the panel itself — see section 19.8. It is required for server-side sign-in checks, push notifications and the scheduled scripts.

19.3.6. Import the panel's database. Import emart_admin_database.sql from the package into the database you created in step 19.2. Do not run php artisan migrate; the supplied .sql file already contains the tables and the default data.

Using phpMyAdmin / cPanel: open phpMyAdmin, select your database from the left-hand list, open the Import tab, choose the .sql file and click Go.

Using the command line:

mysql -u your_db_user -p your_database < emart_admin_database.sql

19.3.7. Set writable permissions on the runtime folders:

chmod -R 755 storage bootstrap/cache

19.4. Import the demo data

The panel reads its configuration from Firestore, so before your first login import the supplied Firestore collections — see Firestore Database Collection Import / Export. They contain the settings documents, sections, currencies, email templates, CMS pages and the sample catalogue.

19.5. Log in

Open the panel at your domain, for example https://admin.yourdomain.com, and sign in with the default account that came with the imported .sql file:

Email:    admin@emart.com
Password: 12345678

Right after login the panel also signs you in to Firebase. Until the service-account key is installed (section 19.8) that step shows a message with a Continue anyway link — continue to Settings and finish the steps below.

19.6. Map configuration

Choose your map provider under General Settings → Map Tracking Options and paste your Google Maps API key — see Create Google Map API Key.

Google Maps is recommended for accurate location, search and distance results.

19.7. Panel URLs

Open Settings → Global Settings → Version and fill the User Panel URL, Store Panel URL and Provider Panel URL with the addresses of your website, store and provider panels (for example https://yourdomain.com, no trailing slash). Save. The mobile apps use the User Panel URL for their server calls, and the next step uses all three.

19.8. Notification settings and the service-account key

Push notifications are delivered through Firebase Cloud Messaging (FCM). The same service-account key also lets every panel verify sign-ins on the server. Install it as follows:

1. Generate the Firebase credentials file

• Open the Firebase console and select your project.
• Go to Project Settings → Service accounts.
• Click Generate new private key — a JSON file downloads (for example firebase-adminsdk-xxxxx.json).
• Keep this file safe; it grants administrative access to your Firebase project.

2. Upload it in the admin panel

• Go to General Settings → Notifications Settings.
• Enter the Sender ID from Project Settings → Cloud Messaging and upload the JSON file.
• The file is saved on the admin server at storage/app/firebase/credentials.json and sent over HTTPS to the Store, Provider and Website panels, which save it at the same path. The message after the upload shows the result for each panel.
• If a panel reports failed or no URL set, fix its URL (section 19.7) and upload again, or copy the file to that server by hand (same path).

3. Verify

• Log in once on the Store, Provider and Website panels to confirm they work.
• Place a test order from the Customer App; the store and the assigned driver should receive a push notification, and the customer should receive the status updates.

19.9. AI settings

Open Settings → AI Settings and paste your OpenAI API key.

With AI enabled, a product can be generated from its image plus a title and short description — the model returns an expanded description, specifications, variations and other attributes, which speeds up catalogue creation and keeps listings consistent.

The API secure key used by the mobile apps for AI features is set under Settings → Global Settings.

20.1. Dashboard

The Dashboard provides a summarized view of the platform’s key metrics and activities. It helps the admin monitor business performance in real time.

20.2. Point of Sale

Point of Sale

Manage in-person or counter sales using the Point of Sale system. This feature allows staff to quickly create orders, add products or services, apply taxes, and process payments in real time. It’s ideal for handling walk-in customers, improving checkout efficiency, and keeping all transactions synchronized with platform order records.

POS Orders

View and manage all orders generated through the Point of Sale system. This section provides access to order details, item breakdowns. It helps track sales activity, resolve disputes, generate reports, and maintain accurate records.

20.3. Access Management

Create and manage admin permission groups (e.g., Super Admin, Editor, Dispatcher). Control what each admin role can view or edit within the system

20.4 Driver Management

Used to manage all drivers who handle deliveries or rides on the platform, including individual drivers and fleet drivers associated with registered fleet owners. From this section, the admin can add new drivers, review and approve registrations, verify driver and vehicle documents, track their real-time location and activity, manage payouts, and monitor performance metrics such as completed trips, ratings, and earnings. It ensures that only verified, active, and reliable drivers and fleets operate efficiently within the system.

20.5. Vendor Management

Used to manage all vendors or businesses registered on the platform. From this section, the admin can add new vendors, verify their details, approve or reject registrations, update business information, set commission rates, and monitor their sales, orders, and overall performance. It helps ensure that only verified and active vendors operate on the platform while maintaining quality and compliance.

20.6. Store Management

Used to manage all stores or branches associated with vendors on the platform. From here, the admin can create new stores, edit existing details, update business hours, manage delivery areas, and monitor performance metrics such as orders, earnings, and ratings. It ensures each store operates correctly within its assigned vendor account and follows platform policies.

20.7. Customer Management

Used to manage all customer accounts registered on the platform. From this section, the admin can view customer profiles, contact details, order history, wallet balance, and activity status. It allows the admin to verify users, handle support issues, manage account status (active or blocked), and monitor user engagement across different services. This helps maintain a secure and well-managed customer base.

20.8. Zone Management

Used to define and manage geographic zones or service areas where the platform operates. From this section, the admin can create, edit, or remove zones by setting map boundaries or pin locations. It helps assign vendors, drivers, and delivery coverage based on specific regions, ensuring efficient order allocation and accurate service availability for users within defined areas.

20.9. Section / Service Management

Used to manage different service sections or business types available on the platform, such as stores, groceries, pharmacies, or salons. From this section, the admin can create and configure sections, assign them to specific service types (e.g., Multivendor Delivery, On-Demand, etc.), and customize related settings like categories, menus, and delivery options. It helps control which services are active on the platform and how their data and menus appear in the admin and user apps.

20.10. Settings

Used to configure and control all core features and operational settings of the platform. This section allows the admin to define system-wide preferences such as business logic, currency, taxes, payments, delivery configurations, and application content. It ensures the platform runs smoothly and aligns with business requirements, branding, and policies.

Global

Used to set general platform configurations such as app name, logo, contact information, and default preferences applied across all services.

Currency

Used to manage supported currencies on the platform. The admin can add or update currency codes, symbols, and conversion rates for multi-country operations.

Business Model

Used to define the platform’s operational model—such as commission-based, subscription-based, or hybrid—determining how revenue is generated from vendors and drivers.

Tax

The Tax Settings page allows administrators to configure taxes applicable across all services. Admins can define tax types such as GST, VAT, or other local taxes and specify rates for each service category. This page ensures that all fare calculations include accurate tax amounts, maintains compliance with local tax regulations, and provides transparency for customers and drivers. Proper tax configuration also helps in generating accurate financial reports and simplifies accounting and regulatory reporting. Now supports scope options: Product Level, Order Level, Tax on Delivery Fee, Tax on Packing Charge, and Tax on Platform Fee, along with country-wise tax.

Note: Admin Commission Tax and Vendor Subscription Tax is used only for admin tax reports to calculate taxes on income.

Admins can also select which tax scope applies for users, allowing flexibility to apply taxes at either the product level or order level. Also Platform Fee and Packing Charge is enabled, the configured tax will also apply to these components.

Note: Packing & Platform tax setting located under Section & Tax Scope setting located under Settings > Global Settings

Payment Method

Used to configure available payment gateways and methods (like Stripe, PayPal, Razorpay, COD). The admin can enable or disable specific gateways and manage related credentials.

Radius Configuration

Used to define service and delivery radius limits for vendors and drivers. This ensures that orders or rides are assigned within specific distance boundaries for efficient service.

App Banners

Used to manage promotional banners displayed in the app or website. The admin can upload banner images, set redirection links, and control their display order or duration.

Schedule Order Notification

Used to configure automatic notifications for scheduled orders or deliveries. The admin can set time intervals and message templates for reminders and updates.

Delivery Charges

Used to set up and manage delivery fee rules. The admin can configure base charges, per-kilometer or per-mile rates, and free delivery thresholds.

AI Settings

This section allows administrators to manage AI-powered features integrated into the platform using OpenAI. It enables the automatic generation of complete product details — including descriptions, keywords, and specifications — based on the product title and an uploaded image. Admins can configure the API key, control AI usage limits, and adjust feature availability. This feature streamlines the product creation process, saving time for vendors while ensuring high-quality and consistent product data across the platform.

Document Verification

Used to manage required documents for user verification, such as IDs for drivers, vendors, or owners. The admin can define mandatory fields, document types, and approval processes.

Languages

Used to manage language options for multi-lingual support. The admin can add or update languages and upload translation files for the user and admin interfaces.

Special Offer

Used to create and manage platform-wide promotional offers or limited-time discounts to attract users and boost sales.

Terms & Conditions

Used to update and maintain the platform’s official terms of service, ensuring users understand the rules and responsibilities when using the application.

Privacy Policy

Used to define and manage the platform’s privacy and data protection policies, explaining how user data is collected, used, and secured.

Landing Page Template

Used to design and manage the structure and content of the website’s landing page. The admin can configure banners, sections, and promotional content to enhance presentation.

Footer Template

Used to customize the footer section of the website or app. The admin can add quick links, contact details, social media handles, and copyright information for branding consistency.

20.11. Content Management

Used to manage all visual and informational content displayed in the app and website. This section helps the admin control banners, static pages, onboarding screens, and email templates to ensure consistent branding, user engagement, and communication throughout the platform.

Banner Items

Used to create and manage promotional or featured banners displayed in various sections of the app or website. The admin can upload images, set redirect links, define display order, and schedule banners for specific time periods or service types.

CMS Pages

Used to manage static content pages such as About Us, Help Center, or Refund Policy. The admin can create, edit, and publish pages without modifying the code, ensuring quick updates to informational content.

Onboarding Screens

Used to manage the introductory screens displayed when users first open the app. The admin can set up multiple slides with titles, descriptions, and images to guide new users through the platform’s key features and benefits.

Email Templates

Used to create and customize automated email templates for system notifications, such as registration, order confirmation, password reset, or promotional campaigns. The admin can edit content, design, and placeholders to match the brand’s tone and style.

20.12. Category & Items Management

Used to manage all product or service categories and the items listed under them. From this section, the admin can create, edit, or delete categories, assign subcategories, and manage items with details like name, price, description, and images. It helps organize the platform’s catalog so users can easily browse and purchase or book products and services under the correct categories.

20.13. Brand Management

Used to manage all brands available on the platform. From this section, the admin can add new brands, update existing brand details such as name, logo, and description, and associate brands with relevant products or categories. It helps maintain a structured catalog and allows users to filter or search items by specific brands for a better shopping experience.

20.14. Report and Analytics

Reports

The Reporting and Analytics section in the admin panel provides comprehensive insights into platform activity, allowing administrators to monitor performance, make data-driven decisions, and identify trends. Reports can be customized using various filters and options to generate precise and actionable information. Key options include:

Store: Filter reports by the store.

Driver: Filter reports by the driver.

Date Options: Quickly generate reports based on preset time frames like Today, This Week, This Month, or This Year.

File Format: Export reports in multiple formats such as CSV, or PDF for offline analysis, record-keeping, or sharing with stakeholders.

Sales Reports

This section provides a detailed overview of the platform’s sales performance and transaction history. Administrators can track total orders, revenue, commissions, and payment summaries over specific date ranges. Reports can be filtered by vendor, customer, or delivery type for deeper insights. It helps analyze business trends, monitor growth, and identify top-performing vendors or menu items. The data can also be exported for accounting or financial analysis, ensuring complete transparency and accurate record-keeping.

Tax Reports

This section provides a comprehensive overview of all taxes collected across the platform. Administrators can track taxes on orders, products, delivery fees, packing charges, platform fees, admin commissions, and vendor subscriptions over specific date ranges. Reports can be filtered by tax type for more detailed insights. It helps analyze tax liabilities, monitor compliance, and ensure accurate calculation of taxes owed for admin income. The data can also be exported for accounting or regulatory reporting, providing complete transparency and precise record-keeping.

20.15. Business Setup

Used to manage the platform’s subscription system for vendors or service providers. From this section, the admin can create and configure various subscription plans by defining their duration, price, and included features. It also allows tracking of all subscription activities, including active, expired, or cancelled plans, payment history, and renewals. This helps ensure smooth monetization management and clear visibility of each vendor’s subscription status.

20.16. Order & Promotions Management

Used to manage all customer orders and promotional activities across the platform. From this section, the admin can track, update, and manage orders along with handling promotional tools like gift cards, coupons, and advertisements. It also includes document verification features for user approvals, ensuring compliance and authenticity.

Orders

Used to view and manage all orders placed on the platform. The admin can check order details, update statuses (pending, confirmed, delivered, cancelled), and monitor payment and delivery progress across different service types.

Giftcard

Used to create and manage digital gift cards that customers can purchase or redeem. The admin can define card values, usage limits, and validity periods to boost customer engagement and sales.

Coupons

Used to manage discount coupons available on the platform. The admin can create, edit, or disable coupons, set discount types (percentage or fixed), and apply usage conditions like minimum order value or category restrictions.

Ad List

Used to manage all active and past advertisements displayed on the platform. The admin can view, edit, or remove ads and monitor their performance or expiration status.

Ad Request

Used to handle advertisement requests submitted by vendors or businesses. The admin can review, approve, or reject these ad requests based on compliance, duration, and payment.

Documents

Used to manage and verify required documents submitted by owners, drivers, and vendors. The admin reviews and approves identity, business, or vehicle documents to ensure all users meet platform verification and safety standards.

20.17. Notification Management

Used to manage all types of notifications sent through the platform. From this section, the admin can create, schedule, and send push notifications or in-app alerts to users, vendors, or drivers. It allows customizing notification titles, messages, and target audiences based on service type or user group. This helps in sharing important updates, promotions, or alerts to keep users informed and engaged.

20.18. Help & Support

This section provides a centralized space for managing user inquiries, complaints, and support requests. Admins can view, respond to, and resolve tickets submitted by customers, vendors, drivers, providers & workers. It may include categories such as general queries, order issues, payments, or technical assistance. The system helps track the status of each request to ensure timely resolutions. This feature enhances user satisfaction by maintaining effective communication and reliable customer support across the platform.

20.19. Disbursement Management

Used to manage all payout and commission settlements across the platform. From this section, the admin can track and release payments to vendors, store owners, and drivers based on completed orders or services. It ensures transparent and accurate financial transactions between the platform and its partners.

Store Disbursement

Used to view and process payouts related to individual stores. The admin can review earnings, commissions, and pending payments, and manually or automatically release funds to store accounts.

Driver Disbursement

Used to manage payments to drivers for completed deliveries or rides. The admin can verify trip earnings, adjust commissions, and process driver payouts efficiently.

Provider Disbursement

Used to handle payouts for service providers. The admin can track total earnings, deduct applicable fees or commissions, and disburse the remaining balance to ensure timely and accurate settlements.

20.20. Live Tracking

Used to monitor active delivery orders in real time. The admin can view the live locations of drivers, check delivery progress, and track the status of orders from pickup to drop-off. This feature ensures timely deliveries, improves customer satisfaction, and allows quick intervention in case of delays or issues.

20.21. Cab Service Management

Used to manage all operations related to the cab or ride-hailing service within the platform. This section allows the admin to monitor rides in real time, manage vehicles and drivers, handle user safety alerts, and configure promotions and vehicle details for smooth and secure transportation services.

Rides

Used to manage all cab ride records on the platform. The admin can view ride details, update statuses, check payments, assign drivers, and resolve ride-related issues.

SOS Rides

Used to handle emergency alerts triggered by users or drivers during a ride. The admin can view SOS details, contact relevant users or authorities, and ensure safety actions are taken promptly.

Promo

Used to create and manage promotional offers or discounts specific to cab rides. The admin can define promo codes, set validity periods, and monitor their usage to boost bookings.

Complaints

Used to review and resolve complaints raised by customers or drivers related to cab rides. The admin can track issue types, communicate with involved parties, and take necessary action to maintain service quality.

Vehicle Type

Used to define and manage various vehicle categories such as Sedan, SUV, Mini, or Luxury. Each type can have its own pricing structure and capacity.

Make

Used to manage the list of vehicle manufacturers (e.g., Toyota, Honda, Tesla) available for cab registration. It helps standardize vehicle data across the system.

Model

Used to manage specific vehicle models under each make (e.g., Toyota Corolla, Honda City). This ensures accurate identification and classification of vehicles in the fleet.

20.22. On-Demand Service Management

Used to manage all operations related to on-demand services such as home cleaning, beauty, repair, or other professional services. This section helps the admin oversee service providers, service listings, workers, and bookings to ensure efficient service delivery and customer satisfaction.

Providers

Used to manage all service providers registered on the platform. The admin can view provider profiles, verify documents, approve or reject applications, and monitor their performance and earnings.

Categories

Used to organize and manage various service categories (e.g., Cleaning, Plumbing, Beauty). The admin can create, edit, or delete categories to structure the service catalog effectively.

Coupons

Used to create and manage discount coupons specific to on-demand services. The admin can define coupon codes, discount amounts, usage limits, and validity periods to attract and retain customers.

Services

Used to manage individual service listings under each category. The admin can add or edit service details such as name, description, pricing, duration, and availability.

Workers

Used to manage workers associated with service providers. The admin can view worker details, assign them to providers, verify their documents, and track their service performance and availability.

Bookings

Used to view and manage all service bookings made by customers. The admin can track booking statuses, assign providers or workers, update schedules, and handle cancellations or customer issues.

20.23. Parcel Service Management

Used to manage all operations related to parcel pickup and delivery services. This section allows the admin to monitor active parcel deliveries, manage parcel types and weights, handle discount coupons, and track order statuses to ensure smooth and timely deliveries.

Parcel Category

Used to create and manage parcel categories based on the type or size of items (e.g., Documents, Electronics, Fragile Items). This helps in applying appropriate delivery charges and handling requirements.

Parcel Weight

Used to define and manage different weight ranges for parcels. The admin can set pricing rules and delivery fees based on parcel weight to maintain accurate billing.

Parcel Coupons

Used to create and manage discount coupons specific to parcel delivery services. The admin can set coupon details such as code, discount amount, usage limit, and validity period.

Parcel Orders

Used to view and manage all parcel delivery orders. The admin can monitor order details, pickup and drop-off locations, driver assignments, payment status, and delivery progress.

20.24. Rental Service Management

Used to manage all activities related to the vehicle rental services on the platform. This section helps the admin oversee vehicle listings, rental orders, discounts, and packages to ensure a smooth and efficient rental experience for users and vendors.

Rental Vehicle Type

Used to define and manage various types of vehicles available for rent (e.g., Cars, Bikes, Scooters, Vans). Each type can have its own pricing, features, and capacity settings.

Rental Discount

Used to create and manage promotional discounts or special offers specific to rental services. The admin can define discount codes, percentage or fixed value discounts, and their validity period to attract more users.

Rental Orders

Used to view and manage all rental bookings made by customers. The admin can check booking details, vehicle availability, payment status, and track rental durations or extensions.

Rental Vehicle

Used to manage all vehicles listed for rent on the platform. The admin can add or update vehicle details such as model, registration number, condition, pricing, and availability status.

Rental Packages

Used to create and manage predefined rental plans or packages (e.g., hourly, daily, weekly). The admin can set rates, duration, mileage limits, and terms for each package to offer flexible rental options to customers.

eMart runs six recurring jobs from the Admin Panel, all triggered by Laravel's scheduler:

• app:multivendor-order-auto-cancel (every minute) — cancels multivendor orders that were never accepted within the window you configure.
• app:multivendor-scheduled-order-notification (every minute) — sends reminders for orders customers scheduled for later.
• app:parcel-order-auto-cancel (every 5 minutes) — cancels unaccepted parcel orders.
• app:rental-order-auto-cancel (every 5 minutes) — cancels unaccepted rental orders.
• app:ondemand-order-auto-cancel (daily) — cancels old on-demand bookings.
• app:cab-schedule-ride (every minute) — offers new cab rides to nearby drivers, one at a time (sequential) or all at once (broadcast).

All of them start the Node scripts in storage/app/firebase/, so they will not run until the Node path is set and npm install has been run in the panel root.

21.1. Configure the Node binary path

Set NODE_PATH in the Admin Panel's .env to the absolute path of your Node executable — for example /usr/local/bin/node on Linux, or C:/Program Files/nodejs/node.exe on Windows. Find it with which node (see Installing Node.js & npm).

NODE_PATH='/usr/local/bin/node'

21.2. Add the Laravel scheduler to cron

Add a single cron entry that runs the scheduler every minute. Laravel then decides which of its commands are due.

* * * * * cd /path-to-your-admin-panel && php artisan schedule:run >> /dev/null 2>&1

In cPanel or hPanel, open Cron Jobs, choose Once Per Minute, and paste the command.

21.3. If the cron job does not run the scripts

Open storage/logs/laravel.log in the Admin Panel folder. The scheduled tasks start Node.js from PHP, and some hosts disable the PHP functions this needs. If the log shows The Process class relies on proc_open, which is not available or Call to undefined function shell_exec(), enable those functions in your hosting PHP configuration: remove proc_open, shell_exec and exec from the disable_functions list (in Hostinger hPanel: Advanced → PHP Configuration → PHP options → disableFunctions), save, and wait a minute for the next cron run. The log then shows lines such as Running command: … node … rentalOrderAutoCancel.js followed by the script output.

If the host does not allow enabling them, run the scripts from cron directly instead of the Laravel scheduler, one line per script (use your Node path and admin panel path):

* * * * * /path/to/node /path/to/admin/storage/app/firebase/multivendorOrderAutoCancel.js
* * * * * /path/to/node /path/to/admin/storage/app/firebase/multivendorScheduledOrderNotification.js
*/5 * * * * /path/to/node /path/to/admin/storage/app/firebase/parcelOrderAutoCancel.js
*/5 * * * * /path/to/node /path/to/admin/storage/app/firebase/rentalOrderAutoCancel.js
0 0 * * * /path/to/node /path/to/admin/storage/app/firebase/onDemandOrderAutoCancel.js
* * * * * /path/to/node /path/to/admin/storage/app/firebase/cabScheduleRide.js

A line such as Notification skipped … device token is no longer registered in the output is normal: that customer's device token has expired, the order itself was still processed.

21.4. Timing values

The cron entry only decides how often Laravel is asked. The actual timings come from the admin panel: the auto-cancellation windows under Settings, the reminder lead time under Settings → Schedule Order Notification, and the driver search radius and accept/reject time under Settings → Driver Nearby.

Customer payments, store and provider subscription payments, gift cards and wallet top-ups all run through the gateways you enable under Settings → Payment Methods in the admin panel. Credentials are stored in Firestore and used only on the server — by the Laravel panels and by the payment Cloud Functions the mobile apps call — so secret keys are never bundled into the apps or exposed to the browser. Each gateway has a sandbox/live toggle — test in sandbox before switching to live.

eMart integrates 16 online payment gateways, plus Cash on Delivery and the in-app Wallet:

• Stripe, PayPal, Razorpay, PayFast, Paystack, Flutterwave, MercadoPago, Xendit, OrangePay, MidTrans, PhonePe, Instamojo, Cashfree, Foloosi, MTN MoMo and PayMongo.

22.1. How to enable a gateway

1. Go to Settings → Payment Methods in the admin sidebar and open the gateway's tab.
2. Tick Enable.
3. Paste the credentials from that provider's dashboard.
4. Choose sandbox or live mode.
5. Click Save.

22.2. Credentials each gateway needs

• Stripe — Stripe Key (publishable) and Stripe Secret.
• PayPal — PayPal App ID (Client ID), PayPal Secret and the Live Mode toggle.
• Razorpay — Razorpay Key and Razorpay Secret.
• PayFast — Merchant ID, Merchant Key, plus Return, Cancel and Notify URLs.
• Paystack — Public Key, Secret Key, Callback URL and Webhook URL.
• Flutterwave — Public Key, Secret Key and Encryption Key.
• MercadoPago — Public Key and Access Token.
• Xendit — Xendit API Key.
• OrangePay (Orange Money) — Merchant Key, Client ID and Client Secret (or the Auth token), plus Return, Cancel and Notify URLs.
• MidTrans — Server Key.
• PhonePe — Client Key, Client Secret Key and Merchant Key (Standard Checkout v2); Flow ID and Salt Key are only needed for the older salt-key integration.
• Instamojo — Instamojo Key (client ID) and Secret Key.
• Cashfree — Cashfree Client Key (App ID) and Secret Key.
• Foloosi — Foloosi Merchant Key.
• MTN MoMo — Primary Key, Secondary Key, Target Environment, Callback URL and expiry time in seconds.
• PayMongo — PayMongo Secret Key.
• Cash on Delivery (COD) — no credentials; just enable it.
• Wallet — no credentials; enable it to let customers pay from their in-app wallet balance. Top-ups still go through one of the gateways above.

22.3. Where the secret keys are used

Gateways that use a secret key perform their sensitive operations — creating and verifying transactions — on the server: inside the Laravel panels for the website, store and provider checkouts, and inside the payment Cloud Functions for the mobile apps (see Deploy Firebase Cloud Functions, section 18.7). The browser and the apps send only non-sensitive data (amount, currency, reference) and receive only what the gateway's SDK or checkout page needs, so no secret key is ever shipped in the apps or exposed to the browser.

This is also why the payment callback URLs must point at your live HTTPS domain: the provider redirects back into the panel, which then verifies the transaction before the order is marked paid.

The Store (Vendor) Panel is the Laravel 13 application store owners and their employees log into. Upload the package to its own domain or subdomain (for example store.yourdomain.com) and extract it.

23.1. Upload the files

23.1.1. Connect over FTP/SFTP with FileZilla or a similar client — port 21 for FTP, port 22 for SFTP.

23.1.2. Transfer the ZIP file to the server, for example /var/www/html.

23.1.3. Extract it from the terminal or the cPanel File Manager:

unzip your-application.zip

23.1.4. Point the subdomain's document root at the project's public/ folder.

23.2. Configure the panel

23.2.1. Install the dependencies and generate the application key:

composer install
cp .env.example .env
php artisan key:generate

23.2.2. Create a MySQL database for this panel and import emart_store_database.sql from the package — through phpMyAdmin → Import, or from the command line:

mysql -u your_db_user -p your_database < emart_store_database.sql

There is no php artisan migrate step; the .sql file already contains the tables and default data.

23.2.3. Add the same Firebase credentials you used for the Admin Panel, including the same database name:

APP_NAME=eMart Store
APP_URL=https://store.yourdomain.com

DB_DATABASE=your_database
DB_USERNAME=your_db_user
DB_PASSWORD=your_db_password

FIREBASE_PROJECT_DB=(default)
FIREBASE_APIKEY=
FIREBASE_AUTH_DOMAIN=
FIREBASE_DATABASE_URL=
FIREBASE_PROJECT_ID=
FIREBASE_STORAGE_BUCKET=
FIREBASE_MESSAAGING_SENDER_ID=
FIREBASE_APP_ID=
FIREBASE_MEASUREMENT_ID=

23.2.4. Set writable permissions on storage/ and bootstrap/cache/ (chmod -R 755).

23.2.5. The Firebase service-account key is installed by the Admin Panel when you upload it there (Admin Panel Setup, section 19.8), provided the Store Panel URL is filled in the admin panel's Global Settings. If the automatic copy fails, copy the file to storage/app/firebase/credentials.json by FTP.

23.3. Google login

"Sign in with Google" uses the Google provider of your Firebase project. Enable it and authorise your domains:

1. Firebase Console → Authentication → Sign-in method → Google: enable it and expand Web SDK configuration to see the Web client ID.
2. Google Cloud Console → APIs & Services → Credentials: open that OAuth 2.0 Client ID (Web application type) and add your panels under Authorized JavaScript origins:
   • https://yourdomain.com
   • https://store.yourdomain.com
   • https://provider.yourdomain.com
3. Add the same domains with /__/auth/handler under Authorized redirect URIs, for example https://store.yourdomain.com/__/auth/handler.
4. Add all of them under Firebase Console → Authentication → Settings → Authorized domains.

23.4. First login

The panel is now ready at your chosen address, for example https://store.yourdomain.com/. Store owners register from this panel and then wait for admin approval, unless automatic approval is enabled in the Admin Panel settings. If document verification is switched on, the owner must upload the required documents before the rest of the menu unlocks.

24.1. Dashboard

Provides an at-a-glance overview of the vendor’s business operations. Displays analytics such as total drivers, active orders, completed orders, ongoing orders, latest orders, top-performing drivers, and overall earnings summary. Helps vendors quickly monitor performance, track fleet efficiency, and make informed operational decisions.

24.2. My Store

Used to manage the store’s profile and settings. The vendor can update business details such as name, address, contact info, operating hours, delivery settings, and logo or banner images. It helps keep the store’s information accurate and up to date on the platform.

24.4. Document Verification

Document Verification allows vendors to securely upload and submit required documentation for approval. This can include identity proof, business licenses and other necessary certificates. The system ensures that all submitted documents are verified before activating the vendor’s account, helping maintain compliance, safety, and trust on the platform.

24.3. Change Subscription

Used to view available subscription plans and upgrade the current plan. The vendor can select a new plan based on features, duration, or pricing to continue offering services on the platform.

24.4. My Subscriptions

Used to view all current and past subscription details. The vendor can track plan validity, renewal dates, payment history, and active benefits associated with each subscription.

24.5. Items

This section allows owners to manage all the items listed under their store. Vendors can add, edit, or delete menu items and define details such as name, category, price, description, image, and availability status. They can also manage add-ons or variations like size and flavor. This section helps stores keep their menus organized, accurate, and appealing to customers, ensuring that available dishes are always up to date for online ordering. Additionally, vendors can access and add items imported by the admin through the import items from Global Menu, allowing them to quickly populate their store with pre-created products.

24.6. Orders

This section allows owners to view and manage all customer orders received by their store. Vendors can track order details such as customer information, order items, total amount, payment status, and delivery type. They can update order statuses — for example, accepted, preparing, ready for pickup, or delivered — in real time. The section also supports order cancellation and delivery assignment. This feature ensures smooth order processing, efficient communication, and timely service for customers.

24.7. Coupons

Used to create and manage discount coupons specific to the store. The vendor can define coupon codes, set discount values, usage limits, and validity periods to attract more customers and boost sales.

24.8. Advertisements

This section allows store owners to create and manage advertisements to promote their store or specific menu items. Vendors can upload banner images, set titles, add links, and choose where the ads will appear on the platform (such as homepage or category sections). They can also define the duration and visibility of each advertisement. This feature helps stores increase visibility, attract more customers, and highlight special offers or new dishes effectively.

24.9. Deliveryman

This section allows store owners to manage their own delivery staff when using the self-delivery option. Vendors can add, edit, or remove deliverymen and assign them to specific orders. Each deliveryman profile includes details such as name, contact information, and current status (available, busy, or inactive). store owners can track delivery performance and ensure timely order completion. This feature provides flexibility for stores that prefer to handle deliveries independently rather than relying on the platform’s driver network.

24.8. Payouts

Used to view the store’s earnings and payment disbursements from the platform. The vendor can check completed and pending payouts, commission details, and overall financial summaries.

24.9. Special Offer

Used to create and manage limited-time offers or discounts on selected items. The vendor can set offer periods, discount percentages, and eligible products to increase visibility and sales.

24.10. Wallet Transaction

Used to track all wallet-related transactions within the store account. The vendor can view credits, debits, refunds, and order-related adjustments for complete financial transparency.

24.11. Withdrawal Methods

Used to manage payment methods for receiving payouts. The vendor can add or edit bank details, digital payment accounts, or other withdrawal options for smooth and secure fund transfers.

The Provider Panel is the Laravel 13 application on-demand service providers log into to manage their services, workers and bookings. It is part of the On Demand add-on. Upload the package to its own domain or subdomain (for example provider.yourdomain.com) and extract it.

25.1. Upload and configure

Follow the same steps as for the Store Panel:

1. Upload and extract the package, and point the subdomain's document root at public/.
2. Install the dependencies and generate the application key:

   composer install
   cp .env.example .env
   php artisan key:generate

3. Create a MySQL database for this panel and import the .sql file supplied with the Provider Panel package (phpMyAdmin → Import, or mysql -u your_db_user -p your_database < emart_provider_database.sql). There is no php artisan migrate step.
4. Edit .env: APP_URL, the database connection, and the same FIREBASE_* credentials and FIREBASE_PROJECT_DB as the other panels.
5. Set writable permissions on storage/ and bootstrap/cache/.
6. Fill the Provider Panel URL in the Admin Panel (Global Settings → Version) so the service-account key is installed here automatically when it is uploaded in the Admin Panel; otherwise copy it to storage/app/firebase/credentials.json by FTP.
7. Authorise https://provider.yourdomain.com for Google login exactly as described in section 23.3.

25.2. First login

The panel is now ready at https://provider.yourdomain.com/. Providers register from this panel, choose a subscription plan when the subscription model is enabled, and then add their services and workers.

26.1. Dashboard

The Dashboard provides a summarized view of the platform’s key metrics and activities. It helps the provider monitor business performance in real time.

26.2. Change Subscription

Used to view available subscription plans and upgrade the current plan. The provider can select a new plan based on features, duration, or pricing to continue offering services on the platform.

26.3. My Subscriptions

Used to view all current and past subscription details. The provider can track plan validity, renewal dates, payment history, and active benefits associated with each subscription.

26.4. Services

Used to manage all on-demand services offered by the provider. From this section, providers can add, edit, or remove services, set pricing, availability, and service details, upload media, and monitor performance through ratings and bookings.

26.5. Workers

Used to manage the provider’s team members who deliver on-demand services. Providers can add new workers, assign them to specific services, track their availability, view performance metrics, and manage their status (active/inactive).

26.6. Bookings

Used to manage all service bookings received by the provider. From this section, providers can view booking details, update statuses (accepted, in-progress, completed, or canceled), track assigned workers, and communicate with customers in real time.

26.7. Coupons

Used to create and manage discount coupons for customers. Providers can set coupon codes, discount types, usage limits, and validity periods to attract more bookings and retain customers.

26.8. Payouts

Used to view and manage earnings received from completed service bookings. Providers can track payout history, payment status, and details of each transaction processed by the admin.

26.9. Wallet Transaction

Used to track all wallet-related activities, including credits, debits, bonuses, and payments for services. Providers can view their wallet balance and detailed transaction history.

26.10. Withdrawal Methods

Used to manage the payment methods available for withdrawing earnings. Providers can add, edit, or remove withdrawal options such as bank transfer, PayPal, or other supported methods.

The Website Panel is the customer-facing site — a Laravel 13 application that reads and writes Firestore through the Firebase JS SDK and serves every section: Ecommerce, Multivendor, On Demand, Parcel, Cab and Rental. Upload it to your main domain (recommended) and extract it.

27.1. Upload the files

27.1.1. Connect over FTP/SFTP using your server IP, username and password — port 21 for FTP, port 22 for SFTP.

27.1.2. Transfer the ZIP file to the server, for example /var/www/html.

27.1.3. Extract it from the terminal or the cPanel File Manager:

unzip your-application.zip

27.1.4. Point the domain's document root at the project's public/ folder.

27.2. Configure the panel

27.2.1. Install the dependencies and generate the application key:

composer install
cp .env.example .env
php artisan key:generate

27.2.2. Create a MySQL database for this panel and import emart_website_database.sql from the package — through phpMyAdmin → Import, or from the command line:

mysql -u your_db_user -p your_database < emart_website_database.sql

There is no php artisan migrate step; the .sql file already contains the tables and default data.

27.2.3. Add the same Firebase credentials used by the other panels:

APP_NAME=eMart
APP_URL=https://yourdomain.com

DB_DATABASE=your_database
DB_USERNAME=your_db_user
DB_PASSWORD=your_db_password

FIREBASE_PROJECT_DB=(default)
FIREBASE_APIKEY=
FIREBASE_AUTH_DOMAIN=
FIREBASE_DATABASE_URL=
FIREBASE_PROJECT_ID=
FIREBASE_STORAGE_BUCKET=
FIREBASE_MESSAAGING_SENDER_ID=
FIREBASE_APP_ID=
FIREBASE_MEASUREMENT_ID=

27.2.4. Set writable permissions on storage/ and bootstrap/cache/.

27.2.5. Fill the User Panel URL in the Admin Panel (Global Settings → Version) with this domain. The service-account key is then installed here when it is uploaded in the Admin Panel (section 19.8); if the automatic copy fails, copy it to storage/app/firebase/credentials.json by FTP. The mobile apps also use this URL for push notifications, emails and account deletion.

27.3. Google login

Enable the Google provider in Firebase and authorise your website domain exactly as described for the Store Panel (section 23.3): add https://yourdomain.com to the OAuth client's Authorized JavaScript origins, https://yourdomain.com/__/auth/handler to the Authorized redirect URIs, and the domain under Firebase Authentication → Settings → Authorized domains.

27.4. Landing page

The package also contains a Landing Panel: a static HTML marketing page (index.html, css/, js/, img/). It needs no PHP or database — edit the texts and links in index.html, then upload the folder to any domain or sub-folder you like.

The website's own home page (the section chooser with the location picker) is editable from the Admin Panel under Settings → Home page template.

27.5. Go live

The site is now ready at your domain, for example https://yourdomain.com/. Its sections, banners, CMS pages and home page template are all driven from the Admin Panel — see Customizing Branding.

eMart uses Google Maps for store search, address selection, zone drawing, delivery-distance calculation, cab fares and live driver tracking. One key can serve the panels and the apps, but restricting it per platform is safer.

28.1. Go to the Google Maps Platform and click Get started.

28.2. Open the Google Cloud Console, go to Billing, and confirm your billing details are up to date — Google Maps returns a grey map or a watermark without an active billing account.

28.3. Go to APIs & Services → Credentials and select or create a project.

28.4. Click Create credentials → API key. Copy the key that is displayed.

28.5. Enable the APIs eMart uses under APIs & Services → Library:

• Maps JavaScript API — the maps rendered in the web panels.
• Maps SDK for Android and Maps SDK for iOS — the maps in the mobile apps.
• Places API — address autocomplete and store search.
• Geocoding API — converting between addresses and coordinates.
• Directions API and Distance Matrix API — delivery and ride routes, distance and ETA.

28.6. Restrict the key to your domains (HTTP referrers) for web use, and to your package name + SHA-1 for Android, then save.

28.7. Add the key in the admin panel under General Settings → Map Tracking Options, and in each mobile app — see Google Maps API Key (Flutter).

All four panels follow the standard Laravel 13 layout. If you plan to customise the code, these are the folders that matter.

emart-admin/  (also emart-store/, emart-provider/ and emart-web/)
├── app/                 Application code
│   ├── Console/         Artisan commands + the scheduled tasks
│   │   └── Commands/    the six auto-cancel, reminder and cab-dispatch commands (admin)
│   ├── Helpers/         Shared helper functions (FirestoreHelper, …)
│   ├── Http/
│   │   ├── Controllers/ Request handlers (thin — data is read from Firestore)
│   │   └── Middleware/  Auth & the per-menu permission gate
│   ├── Mail/            Mailables for the email templates
│   ├── Models/          Eloquent models (panel auth: User, Role, Permission)
│   ├── Providers/       Service providers
│   └── Services/        Firebase services (ID-token verification, Auth admin, Firestore REST)
├── Modules/
│   └── AI/              The OpenAI product-listing module (admin & store panels)
├── bootstrap/           Framework bootstrap + cache
├── config/              Configuration files (app, database, …)
├── database/
│   ├── migrations/      MySQL schema reference (you import the shipped .sql)
│   └── seeders/         Base data
├── public/              Web root — index.php, css/, js/, images/
├── resources/
│   ├── views/           Blade templates (pages, layouts, partials)
│   └── lang/            Translations (en/, ar/)
├── routes/
│   ├── web.php          All web routes (route names double as permission keys)
│   └── api.php          API routes used by the mobile apps and the other panels
├── storage/
│   └── app/firebase/    credentials.json + the scheduled Node scripts (admin)
├── vendor/              Composer dependencies (generated — not edited)
├── .env                 Environment config (DB + Firebase credentials)
├── artisan              Laravel command-line entry point
└── composer.json        PHP dependencies

This section maps the external services eMart integrates with and where each one is configured, so developers can extend or replace them. Every client — the mobile apps, the Admin Panel, the Store Panel, the Provider Panel and the Website Panel — talks to the same Google Firebase backend.

30.1. Architecture at a glance

• Flutter apps → Firebase directly (Firestore, Auth, Storage, FCM, Realtime Database for live tracking), the payment Cloud Functions for online payments, and the website API for push notifications, emails and account deletion.
• Website Panel → Firebase JS SDK in the browser, with Laravel verifying the Firebase ID token to create the server session, and a server-side payment broker for every checkout.
• Admin, Store & Provider Panels → Firebase JS SDK in the browser plus the Firebase Admin SDK on the server (via credentials.json) for privileged operations and push notifications. The Admin Panel signs in to Firebase with an admin claim.
• Cloud Functions → the deliveryDispatch trigger, the deleteUser callable and the payment functions.
• Laravel scheduler → the recurring Node scripts (auto-cancel, scheduled-order reminders, cab dispatch).

There is no separate REST API layer to configure: Firestore is the API, and every client reads and writes the same collections in real time.

30.2. Firebase Firestore (primary data store)

All platform data lives in Firestore. The main collections are:

• users — customers, vendors, drivers, providers and workers, each with a role.
• sections — the service sections (Ecommerce, Multivendor, On Demand, Parcel, Cab, Rental).
• vendors, vendor_categories, vendor_products, vendor_attributes, vendor_filters, brands — stores and their catalogue.
• vendor_orders, parcel_orders, rental_orders, rides, provider_orders, booked_table, order_transactions — orders, rides, bookings and payments per section.
• providers_services, provider_categories, providers_workers, services — the On Demand catalogue.
• car_make, car_model, vehicle_type, rental_vehicle_type, rental_packages, parcel_categories, parcel_weight, popular_destinations — cab, rental and parcel configuration.
• coupons, gift_cards, cashback, promos, advertisements, story — promotions.
• subscription_plans, subscription_history, payouts, driver_payouts, withdraw_method, wallet — money movement.
• zone, tax, currencies, documents, documents_verify — operational configuration.
• settings — every configurable option, one document per settings screen.
• chat, dynamic_notification, email_templates — communication.
• cms_pages, banner_items, on_boarding — content.

Configured by the FIREBASE_* keys in each panel's .env. Access is governed by the security rules you deploy (see Deploy Firebase Cloud Functions), and multi-field queries need composite indexes (see Deploy Firestore Indexes).

30.3. Firebase Authentication

Handles email/password, phone (OTP), Google and Apple sign-in for every client. Providers are enabled in the Firebase console; the web panels additionally need the domain listed under Authorized domains and a matching OAuth 2.0 client for Google login. The panels verify the Firebase ID token on the server before creating a session.

30.4. Firebase Storage

Holds every uploaded file — store and product images, banners, avatars and verification documents. Upload quality is controlled by IMAGE_COMPRESSOR_QUALITY in the Admin and Store panels' .env.

30.5. Cloud Messaging (FCM — push notifications)

Delivers order, ride, chat and status notifications to customers, stores, drivers and providers. Configured by uploading the service-account JSON and Sender ID under General Settings → Notifications Settings; the notification text itself comes from Dynamic Notifications. The mobile apps send their notifications through the website API (POST /api/send-notification).

30.6. Firebase Realtime Database

Used for live driver and cab location, which changes far more often than order state. It powers the customer's tracking map and the admin's live map.

30.7. Payment gateways

16 gateways plus COD and the wallet. Public keys are read by the clients; secret-key operations run server-side in the Laravel panels and in the payment Cloud Functions, which read the credentials from the settings documents the Admin Panel manages. See Payment Gateway Setup.

30.8. Website API for the mobile apps

The Website Panel exposes a small API the apps call with the user's Firebase ID token (Authorization: Bearer <ID token>); the base address is the User Panel URL from the Admin Panel:

• POST /api/send-notification — push notification to a device token (60 per minute).
• POST /api/send-email — transactional email through the panel's SMTP account (10 per minute).
• POST /api/delete-user — removes the website login of the signed-in user.
• POST /api/firebase-credentials (also on the Store and Provider panels) — receives the service-account key from the Admin Panel; accepts only an admin ID token.

30.9. Google Maps

Store search, address selection, zone drawing, delivery distance, cab fares and live tracking. One key, configured in General Settings → Map Tracking Options and in each mobile app.

30.10. OpenAI

The Modules/AI module in the Admin and Store panels. Given a product image, title and short description it drafts the full listing — description, specifications, variations and attributes. Configured under Settings → AI Settings; billed by OpenAI per request.

30.11. Email (SMTP)

Order receipts, password resets, vendor approvals and campaign mail. Set the SMTP host, port, username, password and encryption under General Settings → Email Settings in the Admin Panel; the message bodies come from Email Templates.

30.12. Where each integration is configured

• .env (each panel) — database, all FIREBASE_* keys, FIREBASE_PROJECT_DB and NODE_PATH (admin).
• storage/app/firebase/credentials.json — the Firebase service account, installed from the Admin Panel.
• Admin Panel → Settings — branding, map key, notifications, SMTP, AI key, panel URLs, delivery charges, business model, feature toggles, taxes and payment gateways.
• Firebase console — auth providers, authorised domains, Cloud Functions.
• Cloud Functions package — the security rules and the payment functions.
• Google Cloud console — Maps APIs, the API key restrictions and the OAuth 2.0 client.

30.13. Extending eMart (developer guide)

• Add a menu item. Add the route in routes/web.php wrapped in the permission: middleware, add the entry to the layout menu, and grant the permission to the roles that need it. Route names double as permission keys, so keep them stable.
• Add a language. Copy resources/lang/en to a new locale folder, translate lang.php, and register the language under Languages in the admin panel.
• Add a payment gateway. Follow an existing gateway end to end: its settings page under Payment Methods, its settings document, its flow in the panels' payment broker (SecurePaymentController), and its create/verify pair in functions/products/payments.js for the apps.
• Change business rules. Prefer the admin settings over code edits — commission, delivery charges, radius, taxes, driver assignment mode and the feature toggles are all configurable, so upgrades stay painless.

All four panels are Laravel applications and can run on shared hosting (cPanel / hPanel) or on a VPS/dedicated server. Choose the approach that matches your hosting.

31.1. Shared hosting (cPanel / hPanel)

Best for getting started quickly when you do not have SSH/root access.

1. Create a MySQL database and user per panel (see Admin Panel Setup).
2. Upload each panel's ZIP to its domain/subdomain folder and extract it. Point the document root at the panel's public/ directory.
3. Shared hosting usually has no Composer, so run composer install on your own machine first and upload the project with its vendor/ folder already installed.
4. Configure .env (database + Firebase credentials).
5. Set writable permissions (typically 755) on storage/ and bootstrap/cache/.
6. Import that panel's .sql file into its database through phpMyAdmin → Import. No Artisan or shell access is needed for this step.
7. In the Admin Panel fill the panel URLs and upload the service-account key (section 19.7 and 19.8).
8. Add the Laravel scheduler as a cron entry under Cron Jobs — see Cron & Scheduled Tasks.

31.2. VPS / dedicated server

Recommended for production — you get SSH access, Composer, Node.js and full control.

1. Install the stack: PHP 8.3+, Composer, MySQL/MariaDB, Node.js and a web server (Nginx or Apache).
2. Upload or clone each project, then run composer install (and npm install for the Admin Panel).
3. Copy .env.example to .env, set the database and Firebase credentials, then run php artisan key:generate.
4. Import that panel's supplied .sql file: mysql -u user -p database < panel.sql.
5. Point each server block's document root at that project's public/ directory.
6. Set ownership/permissions so the web server can write to storage/ and bootstrap/cache/.
7. Add the scheduler to the system crontab (* * * * * php /path/artisan schedule:run) — see Cron & Scheduled Tasks.
8. For production, run php artisan config:cache and php artisan route:cache, and serve everything over HTTPS.

31.3. Common deployment pitfalls (.htaccess & shared hosting)

• Only the home page works; every other route returns 404. mod_rewrite is disabled or AllowOverride is not All, so Laravel's public/.htaccess is ignored.
• App installed in a sub-folder. Add a RewriteBase to public/.htaccess, e.g. RewriteBase /emart/.
• Document root points at the project root instead of public/. Point the domain at public/, or add a root .htaccess that rewrites into it. Never serve the project root — it makes .env and storage/app/firebase/credentials.json reachable from the internet.
• 404 on uploaded images / assets. Run php artisan storage:link (or create the public/storage link manually if symlinks are blocked).
• 500 error after upload. Usually permissions — set 755 on storage/ and bootstrap/cache/, and confirm PHP is 8.3+.
• "No input file specified". A PHP handler / CGI mismatch on some cPanel hosts — add the host's recommended handler line (or Options -MultiViews) to .htaccess.
• Mixed-content warnings over HTTPS. Set APP_URL to your https:// domain and force HTTPS in .htaccess.
• A page changed but the server still shows the old one. Run php artisan view:clear and php artisan optimize:clear after every upload.

31.4. SSL / HTTPS configuration (production)

Always serve all four panels over HTTPS. Firebase Authentication, payment-gateway callbacks and secure cookies all require it, and browsers block mixed content on pages that are not fully secure.

Shared hosting (cPanel). Most hosts issue a free certificate automatically. Open cPanel → Security → SSL/TLS Status (or Let's Encrypt / AutoSSL), select your domains, and click Run AutoSSL.

VPS / dedicated server. Install a free Let's Encrypt certificate with Certbot:

# Nginx
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d admin.yourdomain.com -d store.yourdomain.com -d provider.yourdomain.com

# Apache
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d yourdomain.com

Certbot installs the certificate and adds an automatic renewal timer.

Force HTTPS. Add this at the top of each panel's public/.htaccess, just inside <IfModule mod_rewrite.c> and before Laravel's front-controller rules:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Then finish up:

• Set APP_URL=https://… in every panel's .env, and the three panel URLs in the Admin Panel.
• In Firebase console → Authentication → Settings → Authorized domains, add all HTTPS domains so sign-in works.
• Update the OAuth 2.0 client's authorised origins and redirect URIs to the HTTPS versions.
• Re-cache the config: php artisan config:cache.

To update the Admin, Store, Provider and Website panels, upload the latest source package to the root directory of each respective panel and extract it.

If your project includes custom modifications, we strongly recommend updating with Git so your customisations are preserved while the latest changes are merged in.

36.1. Updating via Git (recommended)

• Commit and push your existing changes to a dedicated Git branch.
• Download the latest source package from CodeCanyon.
• Replace the source files in your working copy with the new version.
• Review the diff, resolve any conflicts, and confirm your customisations survived.
• Import the new .sql file if the release changed the database (see the note above).
• Commit and deploy.

36.2. Replacing the source code

• Back up your current panel folder and your database.
• Keep a copy of .env and storage/app/firebase/credentials.json — they are not part of the package.
• Upload the new package and extract it over the existing installation.
• Restore .env and credentials.json, then compare .env against the new .env.example and add any new keys.
• Import the updated .sql file from the new package if the release changed the database. Back up your existing database first — importing replaces the tables it contains.
• Run the post-update commands:

composer install
php artisan config:clear
php artisan cache:clear
php artisan view:clear

36.3. Upgrading to version 6.9

Version 6.9 adds server-side payments, the updated Firebase Cloud Functions package and Firestore security rules. Follow this order:

• Servers must run PHP 8.3 (Laravel 13). Upload the new code to all four panels, run composer install, then php artisan optimize:clear.
• Log in to the admin panel. Until the key is installed, the Firebase sign-in page after login shows a message with a Continue anyway link; continue to Settings.
• Fill the User Panel URL, Store Panel URL and Provider Panel URL under Global Settings → Version, then upload the service-account JSON under Notifications Settings (section 19.8). Check that each panel reports installed.
• Log in once on the store, provider and user panels to confirm they work.
• Install the dependencies and redeploy the Cloud Functions (section 18.4), then deploy the security rules (section 18.6).
• Make sure the admin server's cron job runs php artisan schedule:run every minute (section 21): cab ride dispatch runs from it.
• Update the mobile apps to version 6.9 (section 37.3). When most users have updated, deploy firestore.rules.strict; as a routine security measure, delete any copy of the key from Firebase Storage, remove the serviceJson field from settings/notification_setting if present, and generate a new private key.

To update the Customer App, Store App, Delivery Boy / Driver App, Service Provider App or Worker App, download the latest source package and replace that app's project source. Each app updates independently, so you can ship one without rebuilding the others — but keep them on the same release when a version changes shared Firestore fields. As with the panels, Git is the safer route if you have customised the code.

37.1. Updating via Git (recommended)

• Commit and push your existing changes to a dedicated Git branch.
• Download the latest source package from CodeCanyon.
• Replace the source files with the new version.
• Review the diff, resolve conflicts, and keep your customisations.

37.2. Replacing the source code

• Back up your current project, and keep your google-services.json, GoogleService-Info.plist, android/key.properties and release keystore — none of them ship in the package.
• Extract the new source and restore those files.
• Re-apply your branding changes (app name, launcher icon, package name, Maps API key).
• Rebuild and test:

flutter clean
flutter pub get
flutter run

Then increment version: in pubspec.yaml and publish the new build — see Signing, Building & Publishing the Apps. Update the version number and store links under Settings → Global Settings → Version in the admin panel so existing users are prompted to upgrade.

37.3. Version 6.9 and the security rules

Apps older than 6.9 use the previous settings structure. They keep working with firestore.rules but stop working once firestore.rules.strict is deployed, so update the apps first. Apps from version 6.9 pay through the payment Cloud Functions (section 18.7), send push notifications and emails through the website API (/api/send-notification, /api/send-email with the user's Firebase ID token) and send the ID token when deleting an account (/api/delete-user). The website address the apps use is the User Panel URL from the admin panel's Global Settings → Version.