Bachelor of Science in Computer Science
Session 2022–2026 Fall
B2B and B2C Digital Products and Services Platform
Submitted By:
Mohammad Rameez Imdad
Section B | Roll Number 58
Supervisor
Sir Umair Butt
School of Computer Science
Minhaj University, Lahore
DECLARATION
I declare that I completed the analysis, design, development, and testing of this final-year project myself. I have added references wherever I used information from documents or other writers. I have not submitted this report for any other academic award. I take full responsibility for this work.
Student: Mohammad Rameez Imdad
Section B | Roll Number 58
Signature: ____________________
DEDICATION
To
My Parents
For their prayers, patience, and sacrifices during my education.
My Teachers
For helping me learn, ask questions, and turn an idea into working software.
My Supervisor
For practical guidance and useful feedback during this project.
CERTIFICATE OF APPROVAL
This is to certify that Mohammad Rameez Imdad, Section B, Roll Number 58, has completed the project titled “B2B and B2C Digital Products and Services Platform” under the supervision of Sir Umair Butt at Minhaj University Lahore. The project meets the requirements of the BS Computer Science final-year project.
Supervisor: ______________________________
Sir Umair Butt
School of Computer Science, Minhaj University Lahore
Internal Examiner 1: ______________________________
Internal Examiner 2: ______________________________
FYP Coordinator: ______________________________
Head of Department: ______________________________
ACKNOWLEDGEMENT
First of all, I thank Allah Almighty for giving me the strength and patience to complete this project. I am thankful to my supervisor, Sir Umair Butt, for reviewing my work and guiding me throughout the project. I also thank the teachers of the School of Computer Science for the knowledge they shared during my degree. Most importantly, I am grateful to my parents for their prayers and continuous support.
ABSTRACT
This project is a web platform that handles two types of work in one place. It helps companies request custom software services, and it allows individual customers to buy digital products. Business clients can submit requirements, receive quotations, view tasks, and contact the team. Other customers can view products, source files, services, and plans. They can also use a cart and wishlist, make payments, and download approved purchases through secure links. The system gives separate access to customers, agents, employees, and administrators. It also works with Google sign-in, PayFast, manual payments, email, WhatsApp/WhatChimp, browser notifications, referrals, and YouTube checking. I tested various processes, including login, project submission, checkout, payment approval, support, and secure downloads. The platform keeps business work and digital sales organized instead of managing them through scattered messages and manually shared files. However, it still depends on the internet and third-party services.
TABLE OF CONTENTS
Use the links below to move through the document on screen. Check and update the page numbers before making the final PDF.
CHAPTER 1 INTRODUCTION
This chapter explains why I developed the platform and what it should achieve. It covers the business problem, weaknesses in the old work process, project scope, objectives, development plan, and report structure.
Background
A business that sells downloadable items and also develops custom projects deals with various types of customers. A normal buyer wants to find a product, pay, and get access quickly. A business client usually needs discussion, a quotation, progress updates, and support. When staff manage this work through separate pages, spreadsheets, and chat messages, it becomes hard to follow the complete history. My project brings these activities into one system.
Project Scope and Graph-Based Architecture Analysis
The application does more than a normal online store. I used Graphify to study the project source code. It found 244 files, about 1,756,293 words, 1,569 logical nodes, 2,176 links, and 325 communities. Around 83% of the links came directly from the source code. The remaining 17% came from meaning-based analysis. These results show that the project has various modules that use a smaller set of shared services.
I divided the project into three main areas. The customer area includes public pages, services, products, plans, bundles, free and paid files, cart, wishlist, checkout, purchases, points, referrals, profile, notifications, policies, and support. The service area manages B2B requirements, quotations, chats, tasks, progress, sales, expenses, and WhatsApp follow-up. The admin area manages users, catalogue content, payments, file access, security records, appearance settings, policies, cache, maintenance, and reports.
When I checked the dependency map, I found code that is used in more than one area. getAdminSetting() provides settings for registration, themes, catalogue pages, checkout, downloads, bundles, and messages. validateFingerprint() and handleAuthFailure() apply common session checks. WhatChimp helper functions connect chats with support, reminders, sales, tasks, and business-hour replies. Payment approval can also update access, sales, promotions, agent transactions, and outgoing messages. Because these shared functions affect various modules, I included them in repeat testing.
| Module | Purpose | Main Connected Areas |
|---|---|---|
| Public storefront | Public discovery and conversion | Landing, services, products, files, plans, FAQ, policies, SEO |
| Customer portal | Self-service account and access | Profile, plans, cart, wishlist, purchases, downloads, support |
| B2B service management | Collect and deliver custom project work | Requirements, quotes, chats, tasks, sales, WhatsApp updates |
| Commerce and payments | Calculate, collect, verify, and fulfil purchases | Cart, promo codes, points, PayFast, manual payments, receipts |
| Secure delivery | Protect purchased and free content | Assignments, signed tokens, rate limits, download logs |
| Administration | Operate and configure the platform | Users, content, payments, reports, security, settings, maintenance |
| Communication | Keep customers and staff informed | Email, in-app notifications, web push, WhatsApp, follow-ups |
Goals and Objectives
My main aim is to build one secure and responsive platform for custom software services and digital product sales. I want the system to provide role-based access, publish products and services, manage carts and wishlists, collect business requirements, handle quotations and tasks, process payments, provide secure downloads, connect required outside services, and keep a record of important actions.
Gap Analysis
Before developing this project, much of the work was handled through normal chat messages. Payments were checked by hand, and files were also shared manually. In this process, staff could miss a requirement, handle one payment twice, or send a file to the wrong person. My system uses proper forms, ownership checks, searchable records, clear payment status, secure file delivery, notifications, and controls based on the user role.
Project Plan
I developed the project in small stages. First, I collected the requirements and planned the database and access rules. Next, I worked on the storefront and B2B modules. I added payments, file delivery, staff panels, security, testing, deployment, and documentation in later stages.
Work Breakdown Structure
I divided the project work into analysis, database and security design, B2C sales, B2B project work, administration, integrations, testing, documentation, and deployment. Sales work includes the catalogue, plans, cart, wishlist, offers, checkout, callbacks, and delivery. Service work includes requirements, quotations, tasks, discussions, and support cases.
Gantt Chart
The schedule shows the planned time for analysis, design, development, integration, testing, report writing, and deployment. As I am the only student working on this project, I handled development, testing, evidence collection, documentation, and correction myself.
Project Responsibility
| Name | Section / Roll Number | Responsibility |
|---|---|---|
| Mohammad Rameez Imdad | B / 58 | Analysis, design, development, testing, deployment, and documentation |
Report Outline
Chapter 2 explains the system requirements, users, interfaces, and quality needs. Chapter 3 describes the main use cases. Chapter 4 explains the architecture, database, interactions, states, deployment, and screen designs. Chapter 5 discusses implementation. Chapter 6 covers testing, performance, stress testing, and future improvements.
- B2B project requirements, quotations, tasks, and support
- B2C product catalog, plans, cart, wishlist, and checkout
- Role-based access for administrators, employees, agents, and customers
- Payments, secure downloads, notifications, email, WhatsApp, and integrations
- Security, audit logging, reporting, responsive design, and maintainable PHP/MySQL architecture
CHAPTER 2 SYSTEM REQUIREMENTS AND SPECIFICATION
This chapter turns the project idea into clear requirements that can be developed and tested. It covers buying digital products, requesting custom work, and the staff tasks needed for payments, delivery, communication, content management, and support.
Document Conventions
The report follows the university format. The body text uses 12-point Times New Roman, headings are bold, and paragraphs use double spacing. In this report, B2B means services provided to a business, B2C means direct sales to customers, RBAC means access based on user roles, and CRUD means creating, reading, updating, and deleting records.
Intended Audience
This report is prepared for my supervisor and examiners. It can also help future developers, system staff, customers, and business clients understand the platform and its requirements.
Service Perspective
I built the system as a PHP 8+ web application with a MySQL database. PHP handles browser and AJAX requests. It checks the input and user permission before using PDO for database work. Sessions, CSRF tokens, roles, and database transactions protect important actions. The application also connects with payment, Google login, email, WhatsApp, browser push, and YouTube services.
Service Function
The platform keeps various activities connected. Public pages help people find products and services. Customer accounts save user details and history. The sales module changes a paid order into approved access, while project tools turn a business request into trackable work. Notifications and reports show updates, but outside messages are not treated as the main system record.
Product Functions
- User registration, login, password recovery, and Google OAuth
- B2B project requirements, quotations, tasks, and support
- B2C products, source files, plans, bundles, promo codes, cart, and wishlist
- Payment methods, PayFast checkout, manual payment review, and payment history
- Secure downloads, file assignments, access tokens, and rate limiting
- Notifications, email, WhatsApp, web push, referrals, and YouTube verification
- Admin dashboards, reports, logs, settings, themes, policies, and maintenance
User Functions
- Register or authenticate securely
- Browse and search products, files, plans, and services
- Manage profile, cart, wishlist, payment methods, plans, and purchased access
- Submit B2B requirements, communicate with staff, and track updates
- Download eligible files securely and submit support requests
Administrative and Staff Roles
Administrators can manage accounts, catalogue items, files, bundles, plans, offers, payments, projects, tasks, policies, settings, security records, and maintenance. Employees work on assigned delivery and support tasks. Agents handle only their assigned transactions. Customers can access only their own account, orders, projects, messages, notifications, and approved downloads.
Detailed Role and Permission Model
| Role | Primary Responsibility | Typical Permissions |
|---|---|---|
| Administrator | Full platform operation | Manage users, content, payments, projects, staff, settings, logs, security, and reports |
| Employee | Internal service delivery | Work on assigned projects, tasks, tickets, messages, and customer updates |
| Agent | Assigned transaction support | View and process assigned agent transactions according to role scope |
| Customer | B2B/B2C self-service | Manage own profile, requirements, purchases, downloads, support, and notifications |
| External provider | Payment or identity service | Exchange verified callback or identity data only; never receives internal admin access |
Design and Implementation Constraints
- PHP 8+ with PDO and MySQL are required.
- Internet access is required for hosted pages and external services.
- Payment, Google, WhatsApp, email, and YouTube provider availability can affect operation.
- Identity, payment, project, and downloadable-content data require server-side protection.
Assumptions and Dependencies
The system needs a current web browser, internet access, a working MySQL database, required PHP extensions, secure hosting, and valid service details. Returning from a payment page does not prove that payment was successful. The server checks the provider response and saved order status before approval.
External Interface Requirements
The system has four types of screens: public pages, the customer account area, employee or agent pages, and the administrator panel. Forms show useful messages, pages adjust for mobile screens, tables help users find records, uploads are checked on the server, and menus change according to the logged-in role.
System Features
User Authentication and Access Control
Users can register, log in with a password, recover a password, connect a Google account, continue a valid session, and log out. After login, the saved role decides which dashboard and actions are available. Wrong login details, too many attempts, invalid CSRF data, or a session fingerprint problem cause a safe rejection and a security log entry.
B2B Project Requirement Management
The B2B form asks for company details, the current problem, expected result, required features, user roles, estimated number of users, timeline, technology or hosting choice, budget, and extra notes. After submission, allowed staff can discuss the request, prepare a quotation, create tasks, and update its status.
B2B and B2C Commerce Fulfilment
At checkout, the server calculates the cart again, checks any discount or points, and saves a pending payment before opening the selected payment method. File or plan access is given only after payment verification. A late or repeated callback cannot deliver the same purchase twice.
Security, Notifications, and Support
The system uses security checks for requests, login, database work, and files. These checks include CSRF protection, PDO prepared statements, password hashing, session fingerprints, role checks, signed links with expiry, upload checking, request limits, HTTPS, and event logs. These controls follow relevant areas of OWASP ASVS [3]. Email, in-app messages, browser push, and WhatsApp only inform users; they cannot avoid permission checks.
Other Nonfunctional Requirements
Performance, Safety, and Reliability
Common pages should use proper database indexes, pagination, limited results, and cached settings instead of loading complete tables again and again. Private data must be shown only to its owner or an allowed role. If an outside service fails, an action may be delayed, but payment, purchase, project, task, ticket, and audit records must stay correct. A failure must never give access automatically.
Security and Ease of Use
The system should be secure and easy to understand. Important actions use strong checks, while normal users get short forms, clear status messages, responsive tables, a simple checkout process, and an easy way to contact support. Complex admin options stay inside the correct staff area.
CHAPTER 3 USE CASE ANALYSIS
Use cases explain what each user wants to do instead of showing source-code details. The human users are customers, business clients, administrators, employees, and agents. PayFast, Google sign-in, WhatsApp/WhatChimp, email, and the YouTube API are outside actors because their responses affect system tasks.
User Registration and Login
A user can make a local account or connect through Google. The user can then log in, recover a forgotten password, keep a valid session, and log out. After successful checking, the system creates a protected session and opens the dashboard allowed for that role.
| Use Case Name | User Registration and Login |
|---|---|
| Scope | Identity and access |
| Actor | Customer, staff, administrator, Google OAuth |
| Pre-condition | Valid account or registration data is available |
| Post-condition | Protected session and role dashboard are available |
| Success Scenario | User authenticates and receives permitted access |
| Failure Scenario | Invalid credentials or security checks deny access safely |
Submit B2B Project Requirement
A business client enters the reason for the project, its scope, needed features, users, schedule, technical choices, and budget. Staff can then use the saved request for discussion, quotation, task planning, messages, and progress updates.
| Use Case Name | Submit B2B Project Requirement |
|---|---|
| Scope | B2B service management |
| Actor | B2B client and staff |
| Pre-condition | Client can access the form and required fields are valid |
| Post-condition | Project is stored and visible to authorized users |
| Success Scenario | Request is submitted, reviewed, and tracked |
Browse Products, Plans, and Services
A visitor can view available services, products, source files, plans, examples, and help information. Search and detail pages make comparison easier. A logged-in customer can also save an item in the cart or wishlist.
| Use Case Name | Browse and Select |
|---|---|
| Scope | B2C catalog |
| Actor | Customer |
| Pre-condition | Published catalog is available |
| Post-condition | Item is viewed, saved, or added to cart |
| Success Scenario | Customer finds a suitable product or service |
Complete Purchase and Payment
At checkout, the customer reviews the allowed items and selects a payment method. The server calculates the amount again, checks discounts or points, and saves a pending payment. Access is not given until the provider verifies the payment or staff approves a manual payment.
| Use Case Name | Complete Purchase and Payment |
|---|---|
| Scope | B2C commerce and payment |
| Actor | Customer and payment provider |
| Pre-condition | Cart contains eligible items and a payment method is available |
| Post-condition | Verified payment creates eligible fulfilment |
| Failure Scenario | Pending, declined, or duplicate payment is controlled |
Access Purchased Content Securely
A file appears in the customer area after a verified purchase or proper assignment. Before downloading, the server checks ownership, token validity and age, file status, domain rules, and download limits. It sends the file only when all checks pass.
| Use Case Name | Access Purchased Content |
|---|---|
| Scope | Digital delivery |
| Actor | Customer and secure download service |
| Pre-condition | Ownership or assignment exists and token is valid |
| Post-condition | Eligible file is streamed and the attempt is logged |
Manage Operations and Support
Staff members can view and update only the records allowed for their roles. Their work may include users, catalogue content, projects, quotations, tasks, payments, sales, tickets, conversations, notifications, settings, and audit records.
| Use Case Name | Manage Operations and Support |
|---|---|
| Scope | Administration and service delivery |
| Actor | Administrator, employee, agent |
| Pre-condition | Actor has a permitted role and record scope |
| Post-condition | Record, status, message, or task is updated and audited |
CHAPTER 4 SYSTEM DESIGN
This chapter explains the technical design of the system. It shows how PHP handles browser requests, how MySQL records are connected, where security checks are used, how various modules work together, and how the application is hosted.
Architecture Diagram
The first layer contains the public, customer, staff, and admin screens. The middle layer contains PHP pages and AJAX endpoints. This layer checks input, user permission, and business rules before saving data. MySQL and protected file storage make the data layer. Payment, login, messaging, push notification, and video-checking services remain outside the application.
Detailed Runtime and Data Flows
Identity workflow: Registration, login, password recovery, and Google callback requests first pass format, CSRF, and request-limit checks. The login code checks the password or Google identity, starts a fingerprinted session, records the attempt, and opens the dashboard for the user's role. An expired session or fingerprint mismatch returns the user to a safe logged-out state.
Retail purchase workflow: When a customer selects a product or plan, the server calculates the cart again. It checks the discount, points, currency, and payment method. Checkout saves a pending order before PayFast or manual review starts. A verified result runs the delivery process once. It grants the plan or file, updates sales and offer use, removes purchased cart items, and sends customer messages. If the callback comes again, the system uses the existing result instead of delivering twice.
Business-project workflow: The requirement form saves the company, problem, required result, features, users, size, schedule, technical choices, hosting needs, budget, and attachments in one case. Allowed staff can discuss it, create a quotation, assign tasks, change progress, and send updates. This keeps the complete project linked with the first request.
Protected-delivery workflow: Files are not provided from a public storage link. The download page checks the user, file, purchase or assignment, signature, expiry, domain, and request limit before sending anything. It also records the decision. Free files use their own viewing rules, while paid files require confirmed ownership.
Communication workflow: An important action first creates an internal notification or history record. If enabled, the system may also send email, browser push, or WhatsApp/WhatChimp messages. WhatsApp is used for quick replies, invoices, task updates, reminders, after-hours replies, and verified webhook updates. If WhatsApp fails, the main business record remains saved.
| Flow | Start | Core Processing | End State |
|---|---|---|---|
| Authentication | Login/register request | CSRF, rate limit, credentials/OAuth, fingerprint, role redirect | Protected role session |
| B2C purchase | Cart checkout | Totals, discount, payment, callback verification, idempotent fulfilment | Payment, sale, access, receipt, notification |
| B2B project | Requirement form | Validation, ownership, chat, quote, task, status, staff update | Tracked project lifecycle |
| Secure download | File request | Ownership, token, expiry, domain, rate limit, audit log | Permitted file stream or controlled denial |
| Support messaging | Ticket/chat/task event | Assignment, response, notification, WhatsApp/email follow-up | Traceable communication history |
Graphify Findings and Architectural Risk
Graphify showed that most features are separated into modules. However, settings, login, WhatChimp, purchase delivery, and admin navigation are shared by many areas. This shows that the application works as one connected system. It also means that a change in a widely used service should be tested in all related customer and staff tasks.
The graph links do not all have the same level of proof. Calls and references found directly in the source code are treated as confirmed. Links suggested by meaning are treated as possible links until I check the code or test the complete process. The design keeps this point clear.
The report discusses 25 relationships. Important shared points include wcBotSweep(), getAdminSetting(), the WhatChimp API, follow-up and after-hours jobs, WhatsApp helpers, admin navigation, validateFingerprint(), and handleAuthFailure(). A fault in one of these areas can affect various modules, so I test more than the single page where a change is made.
Domain Model
The main domain starts with User and Role. Sales records include Product, SourceFile, Plan, Cart, Wishlist, Payment, Purchase, PromoCode, and Referral. Project records include ProjectRequirement, Quote, Task, and SupportTicket. FileAssignment, Notification, and ActivityLog support access, communication, and record keeping in both areas.
Entity Relationship Diagram
Each user account is linked with its projects, quotations, tasks, tickets, payments, access, notifications, referrals, sessions, and audit records. Products and source files can be used in bundles, carts, wishlists, order items, and access records. Plans are linked through subscription or plan-purchase records. Foreign keys keep these links and help the server check ownership.
Class Diagram
The logical classes are grouped by their jobs. These jobs include login and sessions, users and roles, catalogue and plans, cart and wishlist, payments, purchase delivery, projects and tasks, support, notifications, outside services, cache, security, and reports. Shared services use clear interfaces, so the same rule does not have to be written again on every page.
Sequence / Collaboration Diagram
A normal process starts when the browser sends a protected request. PHP checks the CSRF token, role, record owner, and form values. It then completes the database action and contacts an outside service only when needed. Notifications are created after the main action is saved. Payment callbacks repeat the security checks and use a process that prevents duplicate delivery.
Operation Contracts
| Operation Name | Authenticate User |
|---|---|
| Cross Reference | User Registration and Login |
| Pre-condition | Valid credentials and CSRF token |
| Post-condition | Secure session, role redirect, login log, and notification state |
| Operation Name | Submit Project Requirement |
|---|---|
| Cross Reference | Submit B2B Project Requirement |
| Pre-condition | Client is authorized and required fields are valid |
| Post-condition | Project is stored, staff is notified, and ownership is enforced |
| Operation Name | Browse and Select |
|---|---|
| Cross Reference | Browse Products, Plans, and Services |
| Pre-condition | Published catalog data is available |
| Post-condition | Customer views details or updates cart/wishlist |
| Operation Name | Complete Checkout |
|---|---|
| Cross Reference | Complete Purchase and Payment |
| Pre-condition | Cart, totals, discount, and payment method pass validation |
| Post-condition | Payment state is stored and verified fulfilment executes once |
| Operation Name | Access Purchased Content |
|---|---|
| Cross Reference | Access Purchased Content Securely |
| Pre-condition | Ownership, token, expiry, and rate checks pass |
| Post-condition | File is streamed and the download attempt is logged |
| Operation Name | Manage Operations and Support |
|---|---|
| Cross Reference | Manage Operations and Support |
| Pre-condition | Staff role and record scope permit the operation |
| Post-condition | Status, task, ticket, payment, message, or content is updated and audited |
Activity Diagram
The activity starts when a person opens the public pages. The person may log in, choose a product, or submit a business requirement. A purchase goes through item checking, total calculation, and payment verification before access is given. A service request goes to staff review and project tracking. Both paths show the result to the user and save an audit record.
State Transition Diagrams
The login process starts in the logged-out state. It can move to registration or login checking and then to the correct dashboard after success. A failed check moves to denied. Session expiry or logout ends the active session.
A project begins as a draft, is submitted, and is then reviewed. Staff can prepare a quotation, receive approval, and start the work. The project may wait for a client reply before completion. Cancelled and archived projects are kept as clear states instead of being silently deleted.
The purchase process moves from an active cart to started checkout and pending payment. A verified payment leads to completed delivery, while a failed payment is declined. A completed order can later be refunded or reversed. Access is created only after verification.
A download starts with an access request. The system checks ownership, issues and checks a signed token, and then sends the file. Expired, changed, over-limit, or unauthorized requests are denied and recorded without showing the storage location.
A support ticket is opened, assigned, and worked on. It may wait for more information from the customer before it is resolved and closed. If the customer replies later, the ticket can be opened again without removing the old discussion.
Component Diagram
The design separates the public website, login, customer portal, staff tools, admin panel, catalogue, cart, payments, delivery, projects, support, notifications, integrations, security, cache, and reports. The components connect through business actions and shared services instead of directly using each other's private code.
Deployment Diagram
Users open the system in a browser through HTTPS. An Apache-compatible server runs PHP and connects with MySQL, protected file storage, and configured outside services. Scheduled jobs handle maintenance and follow-up tasks. Database passwords, signing keys, API secrets, and environment settings are kept outside public files.
User Interface Screens
The public page first shows the main services and digital products. It also provides plans, source files, examples, common questions, policies, contact details, language selection, login, and cart access. A visitor can look around before creating an account.
The account screen provides login, registration, password recovery, and Google sign-in in one place. Its error messages give useful guidance without showing private account information.
The customer dashboard gives one place to view profile details, active plans, orders, points, business projects, support tickets, notifications, and allowed downloads.
A product or service page shows the title, category, details, price, access rules, and related options. According to the item, the customer can add it to the cart or wishlist, buy it, or contact support.
The cart contains items the customer plans to buy, while the wishlist keeps items for later. The cart shows quantity, currency, discounts or points, subtotal, and the button to continue to checkout.
Checkout shows the order calculated by the server, including currency, discounts, final amount, and available payment methods. After submission, it displays the saved status as pending, successful, or failed instead of assuming payment succeeded.
The business requirement form groups fields for client and company details, the current problem, expected result, required features, user roles, project size, schedule, technology, hosting, budget, notes, and attachments.
The administrator dashboard shows summary figures and links for users, catalogue items, plans, assignments, transactions, projects, tasks, traffic, settings, security, and audit records.
Staff can filter payment history by customer, date, method, amount, and status. An allowed reviewer can view the proof and invoice, approve or reject the payment, and check whether delivery has already taken place.
The support and communication pages show the project or ticket beside its conversation. Staff can use the task, assignment, reminder, attachment, and status options allowed for their role.
The downloads page uses active purchase and assignment records. A customer only sees files linked with that account and the current access status of each file.
At download time, the delivery page again checks ownership and the signed token. It also checks expiry, origin, and request frequency. It either sends the protected file or records and shows a safe access-denied result.
The reporting pages use payment, download, login, user, traffic, task, project, and admin records. Staff can filter this information for monitoring and later checking.
CHAPTER 5 IMPLEMENTATION
During implementation, I used shared helper code for login, permissions, database access, transactions, payments, file downloads, email, notifications, and screen messages. PHP 8+ and PDO apply server-side rules with MySQL. I used HTML, CSS, JavaScript, jQuery, DataTables, Chart.js, Font Awesome, and SweetAlert2 for the web interface. Important decisions remain on the server, and various pages can use the same checked functions.
Libraries and Frameworks
- PHP 8+ runs the main system logic, and PDO provides safe database queries.
- MySQL stores related business records and uses indexes for faster searches.
- HTML5, CSS3, JavaScript, and jQuery provide a responsive browser interface.
- DataTables manages lists, while Chart.js displays dashboard charts.
- Font Awesome provides icons, and SweetAlert2 shows clear messages.
Deployment Environment
- An Apache-compatible web server runs the PHP application through HTTPS.
- MySQL stores system data, while phpMyAdmin is used only for database management.
- Users can open the platform in current desktop and mobile browsers.
- Secret keys and environment settings stay outside public web files.
- I can use XAMPP during local development and later deploy the project to shared hosting or a VPS.
Tools and Techniques
- PHP pages and AJAX requests check important input again on the server.
- Prepared queries reduce SQL injection risk, and transactions stop incomplete database updates.
- Sessions, user roles, CSRF tokens, password hashing, ownership checks, and request limits protect private actions.
- Responsive pages, pagination, and searchable tables help users work with large record lists.
- Service adapters connect PayFast, Google, email, WhatsApp, YouTube, and browser push.
- Signed download links, upload checking, cache, monitoring, and audit logs help protect system work.
- Each dashboard shows only the controls required for that user role.
CHAPTER 6 TESTING AND EVALUATION
Testing checks whether each workflow saves the correct result in normal, invalid, delayed, and simultaneous situations. The plan covers functions, input limits, permissions, calculations, outside-service failure, response time, and data consistency for orders, file access, projects, tasks, tickets, and notifications.
Use Case Testing
Complete tests start from registration or login and continue through product selection, checkout, verified payment, file download, business requirement submission, staff action, support, and logout. I test each process with correct input and at least one failure case. Screenshots, database records, or logs are kept as proof of the result.
| No. | Step | Expected Result | Status |
|---|---|---|---|
| 1 | Authenticate or browse publicly | Correct page or dashboard opens | Record result |
| 2 | Submit project or select product | Validated project/cart state is created | Record result |
| 3 | Checkout or send requirement | Pending payment or project status appears | Record result |
| 4 | Verify payment or staff response | Access, receipt, message, or update is available | Record result |
| 5 | Open download/support area | Only permitted information is shown | Record result |
| 6 | Logout or close workflow | Session/status ends safely | Record result |
| No. | Exception | Expected Result |
|---|---|---|
| 1-a | Invalid login or expired session | Access denied and safe error shown |
| 2-a | Invalid project or checkout field | Validation message shown and no unsafe write occurs |
| 3-a | Payment provider unavailable | Transaction remains pending or retry is offered |
| 4-a | Duplicate callback | No duplicate purchase, points, access, or notification |
| 5-a | Unauthorized download | Request denied and activity recorded |
Boundary Value Analysis
For boundary testing, I use values just below, equal to, and just above each accepted limit. I also test empty, incorrect, duplicate, expired, and unauthorized values. This method is used for account fields, prices, quantities, discounts, uploads, project details, payments, token expiry, and searches.
Authentication and Identity Inputs
Login and registration tests use various lengths and formats for usernames, email addresses, passwords, and contact details. I also try already registered values and more login attempts than the allowed limit.
Commerce and Project Fields
Sales and project tests use zero, negative, decimal, very large, duplicate, expired, and unavailable values for prices, quantities, discounts, points, dates, file sizes, and required descriptions. Security tests use another user's record, a wrong CSRF token, an expired session, changed download data, unsupported files, long text, and special characters.
Performance Testing
Performance testing measures page display time, server response, database query time, completed requests, CPU and memory use, simultaneous users, failure rate, and recovery after an outside service delay. The values in the next tables are targets, not made-up results. I will fill the result cells after taking repeatable measurements from the deployed Hostinger website.
Performance Test Environment and Measurement Method
| Item | Test Configuration | Record Before Execution |
|---|---|---|
| Application | Deployed PHP/MySQL platform on Hostinger using HTTPS | Domain, PHP version, build date |
| Browser | Current Chrome or Edge, desktop and mobile viewport | Browser version, device, screen size |
| Network | Normal broadband, mobile/slow-network comparison | Download/upload speed, latency |
| Dataset | Representative users, products, files, payments, projects, tickets, notifications, and logs | Row count for each table |
| Load profile | 1 baseline user, then 5, 10, 25, and 50 concurrent users where hosting permits | Concurrent users and test duration |
| Tools | Browser DevTools, Lighthouse, server access logs, MySQL slow-query log, and an approved load tool | Tool version and test script |
| Evidence | Waterfall screenshot, response-time result, error log, query time, and screen recording where needed | Evidence filename or link |
| Metric | How to Measure | Acceptance Guidance | Actual Result |
|---|---|---|---|
| Response time | Time from request start until complete response | Record average, minimum, maximum, p95, and p99 | Record value |
| TTFB | Browser request start to first server byte | Prefer below 800 ms for normal pages | Record value |
| FCP / LCP | First Contentful Paint and Largest Contentful Paint | FCP below 1.8 s and LCP below 2.5 s where practical | Record value |
| Throughput | Successful requests or completed workflows per second/minute | Must meet expected peak workload without queue failure | Record value |
| Error rate | Failed requests ÷ total requests × 100 | Below 1% for normal load; no silent business failure | Record value |
| Database time | Query execution time and total queries per request | Indexed common reads preferably below 1 s p95 | Record value |
| Memory / CPU | Server and browser resource usage during the run | No uncontrolled growth, timeout, or worker exhaustion | Record value |
| Recovery | Time to return to normal after load or provider failure | Pending/retry state must be controlled and data must remain consistent | Record value |
Authentication and Session Performance
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-A01 | Public login page, cold and warm load | Open in a new session, reload three times, record DevTools waterfall | TTFB, FCP, LCP, total load | TTFB <800 ms; LCP <2.5 s where practical | Record value / Pending |
| PT-A02 | Successful customer login | Submit valid credentials 20 times with clean sessions | Response average, p95, DB time | Login response <2 s p95; correct dashboard every time | Record value / Pending |
| PT-A03 | Successful admin/employee login | Repeat with each permitted role and role-specific redirect | Response, redirect, error rate | <2.5 s p95; no cross-role page or data leakage | Record value / Pending |
| PT-A04 | Invalid login and rate limiting | Send repeated invalid passwords from one client, then wait for recovery | Response, rate-limit delay, CPU | Controlled denial; no server crash or user enumeration; recovery works | Record value / Pending |
| PT-A05 | Registration and duplicate account check | Submit valid, duplicate, long, malformed, and incomplete registration data | Response, validation time, DB writes | <3 s p95; only one valid account; no partial record | Record value / Pending |
| PT-A06 | Password recovery and reset | Request reset, use valid token, expired token, and reused token | Page response, token lookup, email queue time | <3 s excluding provider email delay; token is single-use and expiry is enforced | Record value / Pending |
| PT-A07 | Google OAuth callback | Complete success, denial, duplicate-email, and provider-timeout flows | Callback time, error rate, session creation | <5 s excluding Google network time; safe fallback for failure | Record value / Pending |
| PT-A08 | Session validation, fingerprint, timeout, logout | Open protected page, alter session conditions, expire session, logout, press Back | Validation time, redirect time | Protected request <1 s overhead; session cannot be reused after logout/expiry | Record value / Pending |
| PT-A09 | Concurrent authentication | Run 5, 10, 25, and 50 login requests with mixed valid/invalid accounts | Throughput, p95, error rate, CPU/memory | No session mix-up, deadlock, or uncontrolled error growth | Record value / Pending |
Catalog and Dashboard Performance
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-C01 | Landing page and public assets | Load page on desktop/mobile, cold cache and repeat visit | FCP, LCP, page weight, requests | LCP <2.5 s where practical; no broken assets or console errors | Record value / Pending |
| PT-C02 | Product/service catalog with 100, 1,000, and 10,000 records | Open catalog, change page, sort, and inspect query plan | TTFB, query time, rows transferred | Initial list <2 s p95; pagination prevents full-table transfer | Record value / Pending |
| PT-C03 | Product detail and source-file page | Open records with short and long descriptions, previews, and related items | Load time, image load, memory | <2.5 s p95 excluding large media; no layout-breaking content | Record value / Pending |
| PT-C04 | Customer dashboard | Load dashboard with purchases, plans, projects, tickets, notifications, and downloads | Server time, number of queries, JS time | <3 s p95; no N+1 query growth; widgets remain usable | Record value / Pending |
| PT-C05 | Admin dashboard and KPI cards | Load with large payment, user, project, log, and traffic datasets | Query time, render time, memory | <4 s p95; aggregates use indexed or precomputed queries | Record value / Pending |
| PT-C06 | Theme, language, notification, and menu settings | Switch settings and reload public/customer/admin pages | Settings lookup, response, visual delay | Setting lookup adds <300 ms; no repeated query explosion | Record value / Pending |
| PT-C07 | Mobile responsive performance | Run on mobile emulation and a real mobile device across slow network | LCP, input delay, layout shift | Readable page, usable controls, no horizontal overflow, controlled errors | Record value / Pending |
| PT-C08 | Concurrent catalog/dashboard visits | Mix public, customer, employee, and admin requests at 5–50 users | Throughput, p95, error rate, CPU | No timeout or cross-user data; degradation remains predictable | Record value / Pending |
Search, Filters, Tables, and Exports
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-S01 | Product and service keyword search | Use exact, partial, case-mixed, numeric, special-character, and empty searches | Response, query time, result count | Search <1 s p95; correct results; safe handling of special characters | Record value / Pending |
| PT-S02 | File, plan, and bundle search | Search titles, categories, tags, and unavailable records | Response, index use, transferred rows | <1.5 s p95; no unauthorized or unpublished result | Record value / Pending |
| PT-S03 | Admin users, payments, projects, and logs | Search with 1,000, 10,000, and 100,000-row test datasets if available | p95, DB plan, memory | Indexed/keyset or server-side search; no full-table browser load | Record value / Pending |
| PT-S04 | Combined filters and date ranges | Apply one filter, every filter, conflicting filters, and reset | Filter time, query count, accuracy | <1.5 s p95; result count and totals remain accurate | Record value / Pending |
| PT-S05 | Pagination and sorting | Open first, middle, last, next, previous, and invalid pages; sort each sortable column | Page response, rows, DB time | <1 s p95; stable ordering; no duplicate or missing rows | Record value / Pending |
| PT-S06 | Empty and no-result states | Search impossible value and filter an empty date range | Response, render time | <1 s; clear empty state; no PHP/JS warning | Record value / Pending |
| PT-S07 | CSV/PDF/print export | Export 100, 1,000, and maximum permitted rows with filters applied | Generation time, file size, memory | CSV <5 s and PDF/print <10 s for normal report size; filters preserved | Record value / Pending |
| PT-S08 | Concurrent search traffic | Run mixed keywords and filters from 5–50 virtual users | Throughput, p95, DB CPU, error rate | No lock escalation, timeout, SQL error, or result leakage | Record value / Pending |
Checkout and Payment Performance
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-P01 | Cart add, update, remove, and wishlist | Add one and many products; change quantity; remove; move items to wishlist | Request time, DB writes, browser response | <1 s p95 for cart actions; totals update correctly | Record value / Pending |
| PT-P02 | Totals, currency, promo, and points calculation | Test tax/discount/points/currency combinations, zero and maximum values | Calculation time, numeric accuracy | <1 s p95; 100% arithmetic accuracy; no rounding mismatch | Record value / Pending |
| PT-P03 | Checkout form validation | Submit valid, incomplete, duplicate, malformed, and oversized data | Response, validation time, failed writes | <1.5 s p95; no partial order or unsafe write | Record value / Pending |
| PT-P04 | PayFast/payment initiation | Start payment with valid cart, expired cart, changed price, and invalid amount | Initiation time, provider response, error rate | <5 s excluding provider delay; server recalculates totals | Record value / Pending |
| PT-P05 | Verified callback/webhook | Send success, failure, pending, malformed, delayed, and duplicate callbacks | Callback time, DB transaction time, duplicate count | <3 s processing; exactly-once fulfilment; safe response for invalid callback | Record value / Pending |
| PT-P06 | Manual payment upload and approval | Upload valid/invalid proof, approve, decline, and re-open record | Upload time, validation, approval time | File checks complete; state transition <2 s p95; no duplicate access | Record value / Pending |
| PT-P07 | Receipt, email, WhatsApp, and notification fan-out | Complete a purchase and observe all enabled notifications | Queue/response time, retries, duplicate messages | Checkout does not hang on provider delay; one logical notification per event | Record value / Pending |
| PT-P08 | Concurrent checkout and stock/access race | Run several users purchasing the same limited or gated item | Success count, lock time, duplicate fulfilment | Atomic state; no negative quantity, duplicate purchase, or access leak | Record value / Pending |
Secure Download and File Delivery Performance
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-D01 | Authorized purchased-file request | Request small, medium, and large files using valid ownership | Auth time, TTFB, throughput, memory | Authorization <1 s; streaming starts <3 s; memory remains bounded | Record value / Pending |
| PT-D02 | Assigned B2B file request | Request files assigned to a project/client and confirm scope | Lookup time, response, access accuracy | <1.5 s p95; only assigned project files stream | Record value / Pending |
| PT-D03 | Free-file watch-gated/rate-limited path | Complete valid gate, repeat within limit, then exceed limit | Token time, rate-limit response, log time | Valid request streams; repeat is controlled; no bypass | Record value / Pending |
| PT-D04 | Invalid, expired, reused, or altered token | Modify token, wait for expiry, reuse token, and change file ID | Denial time, error rate, audit log | Denied <1 s; no path disclosure; every denial is safely logged | Record value / Pending |
| PT-D05 | Unauthorized account and direct URL access | Use another account, logged-out browser, guessed path, and referrer change | Denial accuracy, response time | 100% unauthorized denial; storage path is never exposed | Record value / Pending |
| PT-D06 | Concurrent large downloads | Start 5, 10, and 25 simultaneous downloads within hosting limits | Time to first byte, throughput, CPU/memory, failures | No application crash; rate limits and server limits behave predictably | Record value / Pending |
| PT-D07 | Upload validation and storage handling | Test allowed type, wrong MIME, oversized, corrupt, duplicate, and long filename | Validation time, storage size, error rate | Only allowed content stored; no executable upload; clear rejection | Record value / Pending |
| PT-D08 | Download audit and notification | Complete and deny downloads while checking logs and user notifications | Log insertion time, duplicate logs | One accurate audit event; download response is not blocked by slow notification provider | Record value / Pending |
Database, Cache, Scheduled Jobs, and Integrations
| ID | Scenario and Workload | Steps / Measurement | Metrics | Target / Acceptance Criteria | Result / Status |
|---|---|---|---|---|---|
| PT-I01 | Indexed user/product/payment/project queries | Run common list, detail, filter, and ownership queries with realistic row counts | EXPLAIN plan, p95, rows examined | Uses intended indexes; common reads <1 s p95 | Record value / Pending |
| PT-I02 | Transactions and concurrent state changes | Approve payment, update project, assign file, and log activity concurrently | Lock wait, deadlock, rollback, consistency | Atomic result; no lost update, orphan record, or partial fulfilment | Record value / Pending |
| PT-I03 | Cache hit/miss and invalidation | Load cached settings/content, update source, reload, and inspect expiry | Hit ratio, lookup time, stale duration | Cache improves repeat response; updates invalidate within defined period | Record value / Pending |
| PT-I04 | Google OAuth and YouTube provider delay | Test normal response, denial, timeout, malformed response, and retry | External latency, retry count, page response | Timeout is bounded; user receives controlled message; no stuck session | Record value / Pending |
| PT-I05 | Email and web-push provider behavior | Trigger registration, payment, project, support, and download notifications | Queue delay, retry, duplicate count | Core transaction completes independently; failed delivery is logged/retriable | Record value / Pending |
| PT-I06 | WhatsApp/WhatChimp messages and webhooks | Send message, quick reply, invoice, reminder, off-hours response, and webhook | API latency, retry, duplicate messages, log time | API delay does not block core page; webhook is authenticated/idempotent | Record value / Pending |
| PT-I07 | Scheduled follow-up and bot sweeps | Run wcBotSweep(), follow-up, off-hours, and notification jobs on test data | Job duration, records processed, failures | Batch processing completes within schedule; no repeated message or skipped eligible record | Record value / Pending |
| PT-I08 | Activity logs and report growth | Insert and query high-volume login, payment, download, and admin events | Insert time, report time, table growth | Logging does not materially slow core action; reports stay paginated | Record value / Pending |
| PT-I09 | Provider outage and recovery | Disable or delay payment, email, WhatsApp, Google, or YouTube provider | Timeout, fallback, recovery time, data consistency | Controlled pending/retry state; no duplicate charge, fulfilment, or message | Record value / Pending |
Performance Result Summary
| Section | Tests | Passed | Failed | Blocked | Overall Evidence / Remarks |
|---|---|---|---|---|---|
| Authentication and sessions | PT-A01–PT-A09 | Enter count | Enter count | Enter count | Attach screenshots and response report |
| Catalog and dashboards | PT-C01–PT-C08 | Enter count | Enter count | Enter count | Attach waterfall and query evidence |
| Search and tables | PT-S01–PT-S08 | Enter count | Enter count | Enter count | Attach search/export evidence |
| Checkout and payments | PT-P01–PT-P08 | Enter count | Enter count | Enter count | Attach callback and fulfilment evidence |
| Secure delivery | PT-D01–PT-D08 | Enter count | Enter count | Enter count | Attach access-denial and throughput evidence |
| Database and integrations | PT-I01–PT-I09 | Enter count | Enter count | Enter count | Attach logs, EXPLAIN, and provider evidence |
Stress Testing
Stress testing increases searches, dashboard requests, project forms, support tickets, checkouts, and downloads until the hosting reaches a practical limit. I also repeat payment callbacks and notifications, increase audit records, and delay outside services. The aim is to see whether the system slows down safely, recovers properly, and avoids duplicate delivery or another user's data.
- Preserve payment, purchase, project, task, ticket, and audit data before failure.
- Prevent unauthorized access and duplicate payment fulfilment.
- Show a controlled retry or pending state when a provider is unavailable.
Future Improvements
Future work can add company accounts with several users, a complete B2B sales process, recurring payments, more local payment methods, help with quotation preparation, better reports, mobile applications, and improved WhatsApp automation. Automated testing, central monitoring, and deployment reports can also make future changes safer.
REFERENCES
- PHP Group. “PHP Manual.” https://www.php.net/manual/en/.
- Oracle Corporation. “MySQL 8.0 Reference Manual.” https://dev.mysql.com/doc/refman/8.0/en/.
- OWASP Foundation. “Application Security Verification Standard 5.0.” https://owasp.org/www-project-application-security-verification-standard/.
- PayFast. “PayFast Developer Documentation.” https://developers.payfast.co.za/api.
- Google for Developers. “Using OAuth 2.0 to Access Google APIs.” https://developers.google.com/identity/protocols/oauth2.
- DataTables. “DataTables Manual.” https://datatables.net/manual/.
- Chart.js. “Chart.js Documentation.” https://www.chartjs.org/docs/latest/.