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
Umair Butt
School of Computer Science
School of Computer Science
Minhaj University, Lahore
DECLARATION
I declare that this project report is my original work, except where sources are acknowledged in the text and references. This work has not been submitted in any form for another degree or diploma at any university or institution. I accept responsibility for the accuracy and timely submission of this report.
Student: Mohammad Rameez Imdad
Section B | Roll Number 58
Signature: ____________________
DEDICATION
To
My Parents
For their unconditional support, prayers, encouragement, and sacrifices throughout my education.
My Teachers
For sharing knowledge, guidance, and motivation during the development of this project.
My Supervisor
For valuable direction and feedback throughout the project.
CERTIFICATE OF APPROVAL
It is certified that the project titled “B2B and B2C Digital Products and Services Platform” was carried out by Mohammad Rameez Imdad, Section B, Roll Number 58, under the supervision of Umair Butt, Minhaj University Lahore. The project is adequate in scope and quality as a final year project for the degree of Bachelor of Science in Computer Science.
Supervisor: ______________________________
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 am thankful to Allah Almighty for giving me the strength and guidance to complete this project. I express my sincere gratitude to my supervisor, Umair Butt, for his guidance, feedback, and support. I am also thankful to the faculty of the School of Computer Science and to my parents for their prayers, encouragement, and continuous support.
ABSTRACT
The B2B and B2C Digital Products and Services Platform is a secure PHP and MySQL web application that connects business clients, individual customers, and platform administrators through one digital commerce and service environment. The B2B side allows clients to submit project requirements, request quotations, communicate with staff, track tasks, and receive updates. The B2C side allows customers to browse digital products, source code, plans, and services, manage carts and wishlists, apply promotional offers, make payments, and access purchased files through secure downloads. The system provides role-based dashboards for administrators, employees, agents, and customers. It integrates authentication, Google OAuth, payment processing, email and WhatsApp communication, notifications, YouTube verification, referral features, and activity logging. The application reduces manual coordination, improves payment and delivery tracking, and gives users a clearer self-service experience. Its main limitation is dependency on internet availability and external services such as payment gateways and messaging APIs. The implemented workflows are validated through authentication, project submission, product purchase, payment approval, access delivery, support, and security test scenarios. The final outcome is a unified, responsive, and maintainable platform for managing both business-to-business service workflows and business-to-consumer digital sales.
TABLE OF CONTENTS
Use the links below for screen navigation. Page numbers will be created automatically when this document is printed or saved as PDF.
CHAPTER 1 INTRODUCTION
This chapter introduces the B2B and B2C Digital Products and Services Platform, its business context, objectives, problem area, project plan, responsibility, and report organization. The platform combines digital commerce with custom software-service workflows in one role-based web application.
Background
Businesses and individual customers increasingly expect digital platforms to provide product discovery, online purchasing, secure content delivery, and direct support. Software-service providers also need structured ways to collect requirements, prepare quotations, track tasks, manage payments, and communicate with clients. The platform centralizes these activities and provides a single source of operational data.
Project Scope and Graph-Based Architecture Analysis
The implemented system is a complete PHP/MySQL digital business platform rather than a single-purpose storefront. Graphify analysis of the project corpus identified 244 files, approximately 1,756,293 words, 1,569 logical nodes, 2,176 relationships, and 325 communities. About 83% of the relationships were extracted directly from the source structure and 17% were inferred from semantic connections. This analysis shows that the project has a central core of shared services surrounded by specialized business modules.
The first major business boundary is the public storefront and customer portal. It contains landing pages, services, products, source-code files, plans, bundles, free files, cart, wishlist, checkout, payment methods, purchases, points, referrals, downloads, policies, courses, profile, sessions, notifications, and support. The second boundary is the B2B service operation: structured project requirements, client quotes, staff communication, tasks, status updates, sales records, expenses, and WhatsApp follow-up. The third boundary is the administration suite, which controls content, users, payments, security, logs, themes, policies, cache, system maintenance, and reporting.
Graphify identifies shared hubs that connect these boundaries. getAdminSetting() links storefront, checkout, downloads, bundles, registration, themes, and messaging configuration. validateFingerprint() and handleAuthFailure() connect authentication and security boundaries. The WhatChimp functions connect support, sales, tasks, reminders, business hours, notifications, and conversation handling. Payment approval connects payment history to user access, sales synchronization, promo usage, email, and agent transactions. These hubs are important because a change in one shared helper can affect several user journeys.
| 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
The primary objective is to develop a secure, responsive, and maintainable web platform for both B2B service operations and B2C digital sales. The objectives are to provide role-based authentication; publish digital products, plans, and services; support cart and wishlist workflows; collect B2B project requirements; manage quotations, tasks, payments, support requests, and notifications; grant purchased content through secure downloads; integrate external services; and maintain audit logs.
Gap Analysis
Traditional arrangements often rely on manual messaging, unstructured requirement descriptions, separate payment confirmations, and manual file delivery. These practices can cause missed requirements, delayed responses, duplicate records, weak access control, and limited reporting. The proposed platform addresses these gaps through structured forms, searchable records, role-based access, payment workflows, secure delivery, notifications, and activity history.
Project Plan
The project follows an incremental lifecycle: requirement analysis, database and access-control design, storefront development, B2B workflow development, payment and delivery integration, administrator and staff dashboards, security hardening, testing, documentation, and deployment.
Work Breakdown Structure
The work is divided into business analysis, database and security design, customer-facing commerce, B2B service management, administration, integrations, quality assurance, and deployment. Commerce development covers products, plans, cart, wishlist, promo codes, checkout, payment callbacks, and purchase fulfilment. Service management covers requirements, quotes, tasks, conversations, and support tickets.
Gantt Chart
The Gantt chart should show the planned duration and dependencies of analysis, design, implementation, integrations, testing, documentation, and deployment. Since this is a single-student project, the development, testing, documentation, and review activities are assigned to the same project owner.
Project Responsibility
| Name | Section / Roll Number | Responsibility |
|---|---|---|
| Mohammad Rameez Imdad | B / 58 | Analysis, design, development, testing, deployment, and documentation |
Report Outline
Chapter 1 introduces the business problem and objectives. Chapter 2 defines requirements and constraints. Chapter 3 presents actors and use cases. Chapter 4 explains architecture, database, interactions, states, deployment, and interfaces. Chapter 5 describes implementation technologies and security. Chapter 6 documents 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
The purpose of this specification is to describe a web platform supporting two related business models. B2B users can request and manage custom software services, while B2C users can browse and purchase digital products, plans, and other services. Administrators and staff operate the workflows needed to approve payments, deliver access, manage content, and support users.
Document Conventions
This report uses Times New Roman, 12-point body text, bold section headings, and double line spacing. “B2B” means business-to-business service interaction. “B2C” means business-to-consumer digital purchase interaction. “RBAC” means role-based access control. “CRUD” means create, read, update, and delete.
Intended Audience
The intended audience includes the project supervisor, examiners, software developers, administrators, employees, sales agents, B2B clients, B2C customers, and future maintainers.
Service Perspective
The platform is a web-based PHP 8+ and MySQL application. A browser communicates with PHP pages and AJAX endpoints. The backend uses PDO prepared statements, session authentication, CSRF controls, role gates, and database transactions where required. External services provide payment processing, Google authentication, email, WhatsApp communication, web push, and YouTube verification.
Service Function
The main function is to connect customer-facing commerce with internal service operations. The platform manages product and plan discovery, requirements intake, quotations, tasks, payments, file access, support, notifications, and administrative reporting.
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
The administrator manages users, products, source files, plans, bundles, promo codes, payments, sales, tasks, project requirements, policies, notifications, settings, security, logs, and maintenance. Employees support client projects and operational tasks. Agents handle assigned transaction workflows. Customers manage their own profile, purchases, projects, downloads, support, and notifications according to permissions.
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 assumes a modern browser, stable internet, a working MySQL database, correctly configured PHP extensions, valid payment credentials, Google OAuth configuration, WhatsApp configuration, and secure hosting. Payment success is confirmed through verified callbacks and server-side checks.
External Interface Requirements
The interface provides a public storefront, authenticated customer portal, agent/employee workspace, and administrator workspace. Forms include validation, feedback, mobile-friendly controls, secure file handling, searchable records, and clear navigation.
System Features
User Authentication and Access Control
Users can register, log in, recover passwords, connect Google accounts, maintain sessions, and receive a dashboard based on their role. Invalid credentials, rate limits, CSRF checks, or fingerprint failures deny access safely and record the relevant security event.
B2B Project Requirement Management
A B2B client submits company information, project overview, problem statement, expected outcomes, features, roles, timeline, scale, technology preferences, hosting needs, budget, and notes. Authorized staff can review, update status, communicate, create tasks, and notify the client.
B2B and B2C Commerce Fulfilment
A customer selects products, plans, or services, reviews totals, applies eligible offers, chooses a payment method, and submits checkout. The server stores a pending transaction, verifies the result, preserves payment history, and fulfils the order only once.
Security, Notifications, and Support
The platform uses CSRF tokens, prepared statements, password hashing, session fingerprinting, RBAC, signed download tokens, upload validation, rate limiting, HTTPS expectations, and activity logs. Email, WhatsApp, in-app notifications, and web push provide operational updates.
Other Nonfunctional Requirements
Performance, Safety, and Reliability
Pages should use indexed queries, pagination, caching, and minimized repeated database calls. Only authorized users may access private records and files. Payment, purchase, project, task, ticket, and audit records must remain consistent. Provider failures must return controlled pending or error states without granting unauthorized access.
Security and Ease of Use
The platform protects data with password hashing, secure sessions, CSRF controls, prepared statements, RBAC, signed tokens, rate limiting, upload validation, and audit logs. Clear role-based navigation, understandable forms, responsive tables, status messages, simple checkout, and support options improve usability.
CHAPTER 3 USE CASE ANALYSIS
A use-case model explains how actors interact with the platform to complete business goals. The main actors are Customer, B2B Client, Administrator, Employee, Agent, Payment Provider, Google OAuth, WhatsApp, Email Service, and YouTube API.
User Registration and Login
This use case supports registration, normal login, password recovery, Google OAuth, session timeout, and logout. Successful authentication creates a protected session and routes the actor to the correct dashboard.
| 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 B2B client submits structured project information so the provider can review the business need, scope, features, roles, timeline, technology, and budget. Authorized staff can review the request, communicate, create tasks, and update status.
| 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 B2C customer browses public products, source files, plans, services, case studies, and information pages. The customer can search, inspect details, compare options, add items to a cart, and save items to a 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
A customer checks out products, plans, or eligible digital services. The system calculates the payable amount, applies valid promo or points rules, selects an available payment method, stores a pending transaction, and verifies the provider or manual approval before fulfilment.
| 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
After verified payment or administrator assignment, a customer opens the purchased area and downloads eligible content through a secure endpoint. Ownership, signed tokens, expiry, allowed domains, rate limits, and download permissions are checked before delivery.
| 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
An administrator, employee, or agent manages operational records assigned to the role. This includes users, projects, quotes, tasks, sales, payment reviews, tickets, messages, notifications, content, settings, and audit history.
| 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
The system design describes the architecture, operating environment, subsystems, database entities, interfaces, processing logic, security boundaries, deployment arrangement, and user-interface screens.
Architecture Diagram
The browser presents public, customer, staff, and administrator interfaces. PHP pages and AJAX endpoints perform validation, authorization, business logic, database access, and integrations. MySQL stores the system of record. External services handle payments, Google authentication, email, WhatsApp, web push, and YouTube verification.
Detailed Runtime and Data Flows
Authentication flow: a visitor submits login, registration, password-reset, or Google OAuth information. The application validates the request, applies rate limits and CSRF checks, verifies credentials or the external identity, creates a session fingerprint, records login activity, and redirects according to the role. Session timeout and fingerprint mismatch are handled by the shared authentication layer.
B2C purchase flow: a customer browses the catalog, adds a product or plan to the cart, applies a promo code or points rule, selects a country-appropriate payment method, and submits checkout. The application creates a pending payment record. PayFast or manual-payment handlers verify the result. Successful fulfilment grants file or plan access, synchronizes sales and agent records, increments eligible promo usage, sends branded email/WhatsApp notifications, and clears the cart. Repeated callbacks are checked so the same payment cannot grant access twice.
B2B project flow: a client submits a structured requirement containing company, problem, outcomes, features, roles, timeline, technology, hosting, budget, and notes. The record is scoped by account or contact ownership. Staff review it, exchange messages and attachments, update status, create tasks, send progress updates, and close or continue the project. This creates a traceable alternative to scattered chat messages.
Secure delivery flow: a customer requests a purchased or assigned file. The secure endpoint checks ownership or assignment, signed token, expiry, allowed domain, IP/download rate, and file state before streaming the file. The attempt is logged. Free-file delivery uses a separate watch-gated and rate-limited path, while paid delivery is linked to verified purchases or administrator assignments.
Communication flow: business events such as new projects, payment changes, purchases, ticket replies, task updates, downloads, and login activity create in-app notifications and may trigger branded email, web push, or WhatsApp/WhatChimp actions. WhatChimp also supports conversations, quick replies, invoices, task updates, reminders, business-hours responses, and webhook-based status handling.
| 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
The graph shows a modular system with high coupling around configuration, authentication, WhatChimp, payment fulfilment, and administrator navigation. This is useful for the FYP because it demonstrates that the platform is an integrated information system with cross-module business rules, not a collection of unrelated pages. It also identifies testing priorities: shared hubs should be regression-tested whenever authentication, payment, settings, notifications, or messaging code changes.
Graphify also marks some relationships as inferred rather than directly extracted. These relationships are treated as architectural hypotheses and should be confirmed through code review and end-to-end testing. The final system design therefore separates confirmed source relationships from assumptions and documents the important flows that require validation.
The graph report also identifies 25 grouped relationships and high-connectivity core nodes: wcBotSweep(), getAdminSetting(), the WhatChimp API integration, follow-up and off-hours sweep functions, shared WhatsApp message helpers, administrator navigation, validateFingerprint(), and handleAuthFailure(). These nodes represent the platform’s operational control points. They should receive focused regression tests because they influence multiple communities at once.
Domain Model
The domain model contains User, Role, Product, SourceFile, Plan, Cart, Wishlist, ProjectRequirement, Quote, Task, SupportTicket, Payment, Purchase, FileAssignment, Notification, PromoCode, Referral, and ActivityLog entities. Ownership, role permissions, payment state, fulfilment, and secure access connect the core workflows.
Entity Relationship Diagram
The ERD should show users connected to projects, quotes, tasks, tickets, payments, purchases, file assignments, notifications, referrals, sessions, and audit logs. Products and files connect to bundles, carts, wishlists, purchases, and access records. Plans connect to users and plan purchases.
Class Diagram
The class design represents authentication and sessions, user and role management, products and plans, cart and wishlist services, payments, projects, tasks, support, notifications, integrations, security, caching, and reporting.
Sequence / Collaboration Diagram
A representative sequence begins when a customer submits a checkout or project form. The browser sends a protected request, PHP verifies CSRF and role, validates input, writes the database record, calls an external provider where required, stores the resulting state, creates notifications or emails, and returns a controlled response. Payment callbacks repeat verification and execute idempotent fulfilment.
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 main activity flow is: visitor opens the platform, authenticates if needed, browses or submits a requirement, selects a product or service, checks eligibility and totals, submits payment or a staff request, waits for verified processing, receives a notification, and accesses the resulting purchase or project workspace.
State Transition Diagrams
The authentication state model includes unauthenticated, registration pending, login pending, authenticated, session expired, access denied, and logged out.
The project state model includes draft, submitted, under review, quotation prepared, approved, in progress, awaiting client response, completed, cancelled, and archived.
The checkout state model includes cart active, checkout started, payment pending, payment verified, payment declined, fulfilment completed, and refunded or reversed.
The secure-download state model includes access requested, token generated, token validated, file streamed, rate limited, expired, and denied.
The support state model includes ticket opened, assigned, in progress, waiting for customer, resolved, closed, and reopened.
Component Diagram
The component design groups the application into public pages, authentication, customer portal, admin panel, employee/agent tools, commerce and cart, payment processing, secure download, project management, support, notification, integration, security, cache, and reporting components.
Deployment Diagram
The deployment arrangement contains a user browser, Apache/PHP application server, MySQL database server, protected upload/storage locations, and external provider endpoints. HTTPS, environment configuration, database credentials, API secrets, and scheduled maintenance tasks must be protected.
User Interface Screens
Public landing pages introduce services, digital products, plans, source files, case studies, FAQs, policies, contact options, language controls, and login/register actions.
The authentication screen supports login, registration, password recovery, Google connection, and safe error messages.
The customer dashboard summarizes purchases, plans, points, notifications, projects, tickets, and downloads.
Product details provide descriptions, prices, access type, related content, and cart or wishlist actions.
The cart and wishlist screens show selected items, quantities, promo rules, currency, and checkout actions.
The checkout screen shows payment method, total, discount, currency, order details, and pending or verified status.
The B2B requirements screen captures client, company, project, problem, outcome, features, roles, timeline, and budget information.
The administrator dashboard provides KPI summaries and management areas for users, files, plans, assignments, payments, traffic, projects, tasks, settings, and logs.
Payment history provides filters, customer and amount details, approval controls, invoices, and fulfilment records.
Support, tasks, and WhatsApp operations show project updates, tickets, replies, reminders, notifications, and role restrictions.
Secure downloads show only the files for which the customer has verified ownership or assignment.
The protected delivery flow validates ownership, signed token, expiry, allowed domain, and rate limits before streaming a file and recording the activity.
Reports and activity history provide operational visibility into payments, downloads, logins, users, traffic, tasks, projects, and system events.
CHAPTER 5 IMPLEMENTATION
The implementation uses reusable authentication, security, database, payment, email, notification, and interface helpers. The browser layer uses HTML, CSS, JavaScript, jQuery, DataTables, Chart.js, Font Awesome, and SweetAlert2. The backend uses PHP 8+, PDO prepared statements, session controls, and MySQL.
Libraries and Frameworks
- PHP 8+ and PDO for server-side application logic
- MySQL for relational persistence and indexed queries
- HTML5, CSS3, JavaScript, jQuery, DataTables, and Chart.js
- Font Awesome and SweetAlert2 for interface feedback
Deployment Environment
- Apache or compatible PHP web server
- MySQL database server and phpMyAdmin
- Modern desktop and mobile browsers
- HTTPS hosting with protected environment configuration
- Local XAMPP-style development or production shared/VPS hosting
Tools and Techniques
- PHP pages and AJAX endpoints with server-side validation
- PDO prepared statements and transaction-safe state changes
- Session authentication, RBAC, CSRF protection, password hashing, and rate limiting
- Responsive HTML/CSS/JavaScript interface with searchable records
- PayFast, email, Google OAuth, WhatsApp, YouTube, and web-push integrations
- Signed download tokens, upload validation, caching, performance monitoring, and audit logging
- Role-aware dashboards and least-privilege access
CHAPTER 6 TESTING AND EVALUATION
Testing verifies that the platform behaves correctly, protects private data, calculates commerce values accurately, handles provider failures, and maintains consistent purchase, access, project, task, support, and notification states. The plan covers functional use cases, alternate paths, boundaries, security, performance, and stress conditions.
Use Case Testing
The main end-to-end scenarios cover registration/login, browsing and selecting an item, cart and checkout, verified payment and secure access, B2B project submission, staff update, support response, and logout. Each scenario should be executed with valid and invalid data and recorded with evidence.
| 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
Boundary testing checks empty, minimum, maximum, malformed, duplicate, expired, and unauthorized values for usernames, passwords, emails, phone values, prices, quantities, promo codes, upload sizes, project fields, payment amounts, token expiry, and search inputs.
Authentication and Identity Inputs
Test empty, minimum, maximum, duplicate, malformed, rate-limited, and already-registered values for username, email, password, and contact fields.
Commerce and Project Fields
Test zero, negative, maximum, decimal, duplicate, expired, and unavailable values for amounts, quantities, discounts, points, timelines, file sizes, and required project fields. Test unauthorized ownership, invalid CSRF tokens, expired sessions, invalid download tokens, disallowed uploads, long text, and special characters.
Performance Testing
Performance testing measures page loading, server response, database access, browser responsiveness, throughput, concurrent-user behavior, error rate, and recovery from slow external providers. The values below are acceptance targets for the FYP test plan; the measured-result fields must be completed with evidence from the deployed Hostinger environment.
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 evaluates stability when many users search products, open dashboards, submit requirements, create tickets, perform checkout, or request downloads at the same time. It also tests repeated payment callbacks, notification bursts, large audit histories, and temporary provider unavailability.
- 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 improvements may include a richer B2B CRM pipeline, multi-tenant organizations, recurring invoices, additional payment gateways, advanced analytics, automated quotation generation, mobile applications, expanded WhatsApp workflows, stronger automated test coverage, and deployment observability.
REFERENCES
- PHP Documentation. PHP 8+ language and server-side web development reference.
- MySQL Documentation. Relational database, indexing, constraints, and transaction reference.
- OWASP Foundation. Web application security, authentication, access control, and secure coding guidance.
- PayFast Documentation. Payment initiation, callback verification, and transaction integration reference.
- Google Developers Documentation. OAuth and Google API integration reference.
- DataTables Documentation. Search, pagination, responsive tables, and export controls.