SwiftSend Documentation

Everything you need to know about the project — setup, features, and viva prep.

What is SwiftSend?

SwiftSend is a web-based courier delivery management system. It lets customers book deliveries and track their packages, drivers manage and update delivery status, and admins oversee the entire system. Built with PHP, Tailwind CSS, and JavaScript — no frameworks, just clean code.

Features

Registration & Profile

Sign up, login, edit profile, change password. Works for all user roles.

Booking & Dispatch

Customers create bookings with pickup/drop details. Admin assigns a driver.

Tracking System

Status-based tracking: Pending → In Transit → Delivered. Public tracking page available.

Notifications

Toast notifications for actions. Inline messages show delivery status updates.

Payment System

Dummy payment with card, mobile, or cash. Includes printable receipt.

Feedback & Ratings

Customers rate deliveries 1–5 stars. Visible to both driver and admin.

Tech Stack

Backend: PHP 7.4+ with PDO
Frontend: Tailwind CSS (CDN)
Database: MySQL 5.7+
Icons: Font Awesome 7.0.1
JavaScript: Vanilla (no jQuery)
Server: Apache + mod_rewrite

Setup Guide

1

What You Need

Install XAMPP, WAMP, or MAMP. This gives you Apache, PHP, and MySQL — all in one.

2

Copy the Files

Extract the courier-app folder into your web server root. For XAMPP, that's xampp/htdocs/courier-app/

3

Create the Database

Open phpMyAdmin at http://localhost/phpmyadmin. Click Import, choose the file database/schema.sql, and run it. Done — all tables are created.

4

Enable Clean URLs

In XAMPP, open httpd.conf and make sure this line is NOT commented out: LoadModule rewrite_module modules/mod_rewrite.so Also set AllowOverride All for your htdocs folder. Restart Apache.

5

Open the App

Go to http://localhost/courier-app/ in your browser. That's it!

Default Accounts

Role Email Password
Admin admin@swiftsend.com admin@swiftsend.com
Customer john.williams34@gmail.com john.williams34@gmail.com
Customer mary.green84@protonmail.com mary.green84@protonmail.com
Customer james.jackson70@gmail.com james.jackson70@gmail.com
Customer richard.johnson36@gmail.com richard.johnson36@gmail.com
Customer robert.wright90@protonmail.com robert.wright90@protonmail.com
Driver elizabeth.davis84@yahoo.com elizabeth.davis84@yahoo.com
Driver sarah.scott26@icloud.com sarah.scott26@icloud.com
Driver michael.lewis61@outlook.com michael.lewis61@outlook.com
Driver susan.clark21@gmail.com susan.clark21@gmail.com
Driver ava.white38@protonmail.com ava.white38@protonmail.com

Register new customer and driver accounts from the sign up page.

Project Structure

courier-app/
├── config/
│   ├── app.php              ← All app settings in one place
│   └── db.php               ← Database connection + helper functions
├── includes/
│   ├── header.php           ← Shared navbar and page head
│   └── footer.php           ← Shared footer, toast system, modal
├── customer/
│   ├── dashboard.php        ← Book, track, view orders
│   ├── payment.php          ← Pay for deliveries
│   ├── feedback.php         ← Rate completed deliveries
│   └── profile.php          ← Edit account info
├── driver/
│   └── dashboard.php        ← View assigned orders, update status
├── admin/
│   └── dashboard.php        ← Manage users, bookings, feedback
├── assets/
│   └── app.js               ← Form validation, toasts, modals
├── database/
│   └── schema.sql           ← MySQL tables + default admin
├── index.php                ← Landing page
├── register.php             ← Login and sign up
├── track.php                ← Public package tracking
├── logout.php               ← Ends session safely
├── docs.php                 ← This documentation page
├── .htaccess                ← Clean URLs and security rules
└── README.md                ← Text version of this doc

Security Measures

SQL Injection Protection

All database queries use prepared statements. User input is never put directly into SQL.

XSS Protection

Every piece of output is escaped with htmlspecialchars() to stop script injection.

CSRF Protection

Every form has a hidden token. The server checks this token before doing anything. Stops fake requests from other sites.

Password Hashing

Passwords are hashed with bcrypt. Even if someone sees the database, they can't read the passwords.

Secure Sessions

Session cookies are HTTP-only (JavaScript can't touch them), and session IDs are regenerated to stop fixation attacks.

Role-Based Access

Every page checks if you're logged in AND if your role is allowed. A customer can't open admin pages.

HTTP Security Headers

Headers like X-Frame-Options and X-XSS-Protection are set to block clickjacking and other browser-level attacks.

File & Directory Protection

The .htaccess file blocks access to config files, SQL files, and directory listings.

Database Design

Four tables, all connected with foreign keys:

users

Stores all accounts — customers, drivers, and admins. The role column tells them apart. Passwords are hashed.

bookings

Each delivery request. Links to a customer (who made it) and a driver (who delivers it). Status goes: pending → in_transit → delivered.

payments

One payment per booking. Stores the amount, method (cash/card/mobile), and whether it's been paid.

feedback

Customer ratings (1–5 stars) with optional comments. One review per completed delivery.

How they connect:

users (1) ──▸ (many) bookings ──▸ (1) payments
  │                      │
  │                      └──▸ (1) feedback
  └──────────────────────────────────┘

Viva Questions & Answers

Common questions your examiner might ask — with clear, simple answers.

Why did you use plain PHP instead of a framework like Laravel?
Plain PHP shows that we understand the basics — how sessions work, how to talk to a database, how routing works. Frameworks hide these things behind built-in tools. For a university project, it's better to show we can do it ourselves.
Why is your tracking system status-based and not using real GPS?
Real GPS needs a mobile app with access to the phone's location sensor. That's beyond the scope of a web-based project. Our status-based system (Pending → In Transit → Delivered) is the standard approach for academic projects and clearly shows the delivery flow.
How does your payment system work?
It's a simulated system. The user picks a payment method (card, mobile, or cash), enters the amount, and clicks "Pay Now". The payment is saved in the database. We don't connect to a real payment gateway like Stripe — that's not needed for a university project.
How do you protect against SQL injection?
We use PDO prepared statements everywhere. This means the SQL query and the user input are sent to the database separately. The database treats the input as data, never as code. So even if someone types SQL commands, they won't run.
How does login and authentication work?
When a user logs in, we check their email in the database. If found, we compare the password they typed with the hashed password using password_verify(). If it matches, we save their ID, name, and role in the session. Every protected page calls requireRole() to check if the session has the right role.
What is CSRF and how do you prevent it?
CSRF stands for Cross-Site Request Forgery. It's when a bad website tricks your browser into sending a request to our app (like deleting something). We prevent it by putting a secret token in every form. When the form is submitted, we check if the token matches. If it doesn't, we reject the request.
Why do you store all user roles in one table?
All roles share the same fields (name, email, phone, password). Using separate tables would mean repeating the same columns three times. A single table with a role column is cleaner and easier to manage. We filter by role when needed.
How does the public tracking page work without login?
The tracking page doesn't call requireLogin(), so anyone can use it. The user enters a tracking ID like SWF-0001, we convert it to a number, and look it up in the database. We only show safe information — no private details like customer email or phone.
What makes your UI responsive?
We use Tailwind CSS utility classes like md:grid-cols-2 and flex-wrap. These make the layout adapt to different screen sizes. On mobile, things stack vertically. On desktop, they sit side by side. The navbar also has a hamburger menu for small screens.
What would you add if you had more time?
Real GPS tracking with a map, email notifications using PHPMailer, a real payment gateway like Stripe, image upload for package photos, and an API for mobile app integration.