Skip to content

Software Achitecture

1 INTRODUCTION

The chapter gives an overview of the design.

1.1 Purpose and coverage

This document describes the software architecture of the PrestaShop deployment project conducted in a virtualized Ubuntu environment. The target audience includes project team members, instructors, and reviewers. The main purpose is to document the system structure, key components, and integration of external services (e.g., payment modules). This design focuses on system configuration, modular structure, and deployment architecture. No custom backend code was written, and database structure or UI layout are not included in this document.

1.2 Product and environment

  • Product: PrestaShop-based web store
  • Purpose: E-commerce platform installation and configuration
  • Operating Environment: Ubuntu 20.04 VM, Apache2, PHP 7.4, MariaDB, LAN

1.3 Definitions, notations and abbreviations

  • VM – Virtual Machine
  • DB – Database
  • PrestaShop – Open-source e-commerce platform written in PHP
  • Module – A plugin used in PrestaShop to add features (e.g., payment methods)

1.4 References

https://wimma-capstone.pages.labranet.jamk.fi/support-material/

1.5 Overview of the document

  • Chapter 2 describes the deployment environment and integration.
  • Chapter 3 contains the main architecture, including C4 diagrams.
  • Chapter 4 is omitted (no custom modules).
  • Chapters 5–8 cover optional and future topics where relevant.

2. SYSTEM OVERVIEW

2.1 Description of the application area

This project focuses on deploying a PrestaShop-based e-commerce platform as part of a course exercise. The system is configured to support real-world usage with integrated payment services.

2.2 The integration of the system into its environment

PrestaShop runs in a standalone Ubuntu VM with Apache, and it integrates with external payment services via official modules. The system is self-contained and not part of a larger system.

2.3 Hardware environment

Describes the hardware environment in which the system operates. For example, what peripherals are needed, what is expected of the CPU, what features of the program are used by the program, what features of the hardware limit the technical solutions and what are the interfaces with other computers. - Virtual Machine running on cPouta servers
- At least 2 vCPU, 2 GB RAM, 10 GB disk space recommended

2.4 Software Environment

  • OS: Ubuntu 20.04
  • Web server: Apache2
  • Scripting language: PHP 7.4.3-4
  • Database: MariaDB 10.3.39
  • Other software: PrestaShop 8.2.0, Paytrail, Klarna, Stripe modules

2.5 Key boundary conditions for implementation

  • Open-source software only
  • No backend programming
  • Configuration done through CLI and PrestaShop admin panel
  • Security handled via platform defaults and cPouta configurations

2.6 Agreements and Standards

  • Followed PrestaShop documentation and payment provider integration guides
  • No internal coding standards or development conventions used (no custom development)

3. DESCRIPTION OF THE ARCHITECTURE

This chapter provides an overview of the system architecture. It outlines the key technologies, implementation philosophy, modular structure, database design, and error handling principles that are essential for understanding the system. The goal is to describe how the system works, why it was designed this way, and how the components interact.

3.1 Design principles

The project was built on top of the open-source PrestaShop platform, which uses a modular architecture based on PHP, MariaDB, and the Apache web server. The main design principles were:

  • No custom backend code was written; all extensions were implemented using official PrestaShop modules

  • Minimal manual configuration changes to maintain compatibility and upgradability

  • Modular and extensible structure: all additional functionality (e.g., payment integrations) was added via modules

  • Standardized deployment environment: the system was deployed inside a Ubuntu VM using Apache, PHP, and MariaDB

This philosophy ensured maintainability, consistency, and ease of deployment. All decisions followed the official PrestaShop documentation and best practices.

3.2 Software architecture, modules and processes

The PrestaShop architecture includes the following main components:

  • FrontController – receives all HTTP requests and routes them to the correct components

  • Smarty Template Engine – handles front-end rendering

  • Admin Panel – back-office interface for shop administrators

  • Payment Modules – plug-ins for Stripe, Klarna, and Paytrail integrations

  • Database Access Layer – abstracts and executes database queries

The modular architecture allowed us to install all required functionality without modifying PrestaShop core code. Payment modules were installed and configured via the admin interface. They operate as independent components that interact with PrestaShop’s internal services and APIs.

Modules used in this project were all pre-built third-party components. No custom scripts, classes, or processes were created. The communication between components happens via HTTP requests, internal function calls, and external REST APIs for payments. uml diagram

3.3 Database Architecture

PrestaShop uses a relational database (MariaDB in our setup). The database contains tables for:

  • Products and categories

  • Customers and orders

  • Payment transactions

  • Module configuration and system settings

The database schema was created automatically during the PrestaShop installation. No manual schema changes were made during the project.

  • Data access and maintenance:

  • All data is accessed via PrestaShop’s internal ORM (Object-Relational Mapping)

  • No direct SQL statements were used by the team

Database snapshots and backups were handled via VM-level tools

Security:

  • Only PrestaShop has access to the database

  • Default MariaDB settings were used for authentication and security

  • No external services had direct access to the database

3.4 Error and Exception Procedures

Error handling was managed by PrestaShop’s built-in mechanisms:

  • Installation and runtime errors were visible in the admin panel

  • PHP-level errors appeared in Apache logs

  • Payment module errors were shown directly to users during checkout (e.g., declined transactions)

Exception handling philosophy:

  • The system was designed to recover gracefully from errors such as power loss or service restarts

  • Data persistence ensured that orders, customer data, and settings were retained after recovery

  • No additional custom error logging or handling was implemented

4. MODULE / CATEGORY / PROCESS DESCRIPTIONS

This chapter describes the modules used in the PrestaShop project, their role in the system, interactions with other components, and behavior. Since no custom modules were developed, this section focuses on the use and configuration of external, official payment modules. Each module acts as an independently installed and configured component within the PrestaShop architecture.

4.1 Module Payments (Klarna, Stripe, Paytrail)

4.1.1 Overview

  • Module name: Stripe, Klarna, Paytrail
  • Module type: PrestaShop external payment modules
  • Overview:
    These modules enable integration with external payment providers. Each one allows customers to select a payment method during checkout, process payments securely, and receive confirmation via the provider's API.
  • Customers (internal):
    Used on the front office checkout page by customers and in the back office by administrators.
  • Dependencies and interfaces:
  • Each module requires its own API credentials (e.g., public/private key)
  • Modules interact with PrestaShop’s order and payment processing system
  • Communicate externally via HTTPS with the provider’s API

4.1.2 Interface in General

  • Exposes payment option on checkout page
  • Sends payment data securely to Stripe's servers
  • Receives confirmation from Stripe and marks order as paid
  • Admin interface allows configuration of API keys, currencies, supported payment methods
  • Error messages from Stripe are displayed to the user in case of failed payment
  • Follows Stripe’s REST API standard and PrestaShop's module conventions

4.1.3 Interface Functions (generealized logic)

Function Name Parameters / Return Action Preconditions Post-conditions Errors
processPayment() Order ID, amount → Boolean success Sends payment to Stripe Valid order, payment method selected Order is marked paid if successful Stripe API errors, network failures
validateResponse() Stripe webhook → status Validates incoming confirmation Stripe server sends response Updates order status Invalid signature, timeout
getConfigurationForm() None → Form object Renders admin settings Admin access Settings page is shown Configuration missing

Describes error and exception handling at the module level.

4.1.4 Implementing the Module

  • The module is implemented by Stripe and downloaded from PrestaShop’s Addons marketplace
  • No source code was modified
  • The module uses Stripe’s official PHP SDK
  • All configuration is done through the PrestaShop back office
  • The module registers itself via PrestaShop’s PaymentModule base class and hooks into payment-related events

4.1.5 Error Handling

  • All Stripe-related errors are caught and displayed to the user at checkout
  • Error messages are also logged in PrestaShop's back office
  • Webhook failures (e.g., payment not confirmed) result in order remaining in "pending" state
  • If API credentials are incorrect or missing, admin is notified in module settings

5. FINISHED COMPONENTS AND SPECIAL TECHNICAL SOLUTIONS

This project used several finished components (external modules) as part of the PrestaShop deployment. These components were integrated into the system through standard PrestaShop functionality and required no source code modification.

🔹 Finished Components

Component Source Purpose Placement
Stripe Module PrestaShop Addons Marketplace Enables credit card and Apple Pay payments Installed via admin interface
Klarna Module Klarna official module Offers invoice and installment-based payments Installed via admin interface
Paytrail Module Paytrail developer portal Enables Finnish online banking payments Installed via admin interface

All modules were configured through the PrestaShop back office and validated with sandbox/test credentials where applicable.

🔹 Use and Integration

  • Modules appear automatically in the checkout process once activated
  • API credentials were required and entered via module settings
  • No direct code-level integration was necessary
  • Modules communicate externally using HTTPS and REST APIs
  • Orders are updated automatically via provider callbacks (webhooks)

🔹 Special Technical Considerations

While no unconventional or low-level programming was done, a few technical points are noteworthy:

  • Recovery: The system runs inside a virtual machine, so full backups were created using VM snapshots. This allows fast recovery in case of system failure or update issues.
  • Portability: The system is fully portable — it can be exported as a VM image or reinstalled using the same configuration.
  • Security: No sensitive data (e.g., card information) is stored by PrestaShop. All payment data is handled by the external providers. HTTPS is recommended for production use (was not enabled in the demo).
  • Maintainability: All components are modular and can be updated individually through PrestaShop’s module manager.
  • Implementation tools: The system was set up manually using Linux terminal commands and the PrestaShop web UI. No automated deployment scripts or CI/CD pipelines were used.

No solutions deviated significantly from standard practices, but the modular, low-code integration approach was chosen to minimize risk and ensure compatibility with PrestaShop updates.

6. SOLVED SOLUTIONS

During the project, several alternative or advanced solutions were considered but ultimately rejected due to technical limitations, time constraints, or compatibility issues. Recording these decisions helps document the reasoning behind the final system setup.

Date Considered Solution Reason for Rejection
2025-04-04 Mounting shared folders for real-time editing Mounting between host and VM was attempted to allow real-time file editing with the host system, but was unsuccessful due to permission issues and configuration complexity within the VM environment.
2025-04-04 Modifying the PHP version (7.4 → 8.1) Upgrading PHP version caused incompatibilities with the installed PrestaShop version; the project proceeded with the recommended version (7.4).

These rejections reflect practical constraints and conscious choices made during the project. They also offer potential directions or lessons for future iterations or production-grade implementations. end of the project, this chapter is collected at the end of the project plan. The ideas for further development can also be presented as a separate appendix, which can be appended to other project documents if necessary.

7. IDEAS FOR FURTHER DEVELOPMENT

Below are development ideas that were discussed or identified during the project but were not implemented due to time limitations, technical constraints, or the defined project scope. These ideas may be useful for future iterations or when transitioning the system to production use.

# Idea Description Date Proposer
1 Add order confirmation emails Configure or develop a feature to automatically send order confirmation messages to customers after a successful purchase. 2025-04-22 LB
2 Implement MobilePay or PayPal Additional payment options that would expand user choice and improve customer experience. 2025-04-22 LB
3 Real-time file editing via mounting Resolve the technical issues with folder mounting to allow faster configuration and development workflow. 2025-04-22 LB
4 Add customer analytics or reporting tools Use modules or dashboards to give admins insight into customer behavior, order history, and sales performance. 2025-04-22 LB
5 Backup automation Implement scheduled database and file backups using cron or external tools to improve fault tolerance. 2025-04-22 LB
6 Install and configure a custom theme Improve the user interface by using or modifying a professional PrestaShop theme. 2025-04-22 LB

*LB stands for LinearB

These ideas can be revisited in future projects, or if the current system is extended or moved to a production environment.

Business Case 2. Information viewpoint -- > 3. Computational viewpoint 4. Engineering viewpoint 5. Technology viewpoint

  • Link Jari Suni here :) -->

Original Source http://www.cs.tut.fi/ohj/dokumenttipohjat/pohjat/suunnittelu/hytt_drsuunnittelu.doc

Thank you for original authors!