ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7050| Title: | Інтеграція платіжних систем інтернет-магазину при їх програмній реалізації за технологією React |
| Authors: | Немченко , Вадим В'ячеславович Смірнов, Олег Віталійович |
| Keywords: | ЕЛЕКТРОННА КОМЕРЦІЯ;ПЛАТІЖНІ СИСТЕМИ;ІНТЕРНЕТ-МАГАЗИН;REACT;NODE.JS;ІНТЕГРАЦІЯ API;ВЕБЗАСТОСУНОК;E-COMMERCE;PAYMENT SYSTEMS;ONLINE STORE;REACT;NODE.JS;API INTEGRATION;WEB APPLICATION |
| Issue Date: | 29-Jan-2026 |
| Abstract: | АНОТАЦІЯ
Смірнов О. В. Кваліфікаційна робота магістра на тему «Інтеграція платіжних систем інтернет-магазину при їх програмній реалізації за технологією React». Спеціальність 121 «Інженерія програмного забезпечення». Черкаський державний технологічний університет. Черкаси, 2025.
Кваліфікаційна робота присвячена дослідженню та практичній реалізації процесу інтеграції платіжних систем у вебзастосунок електронної комерції. У роботі проаналізовано особливості побудови сучасних інтернет-магазинів, вимоги до безпеки та надійності платіжних операцій, а також підходи до інтеграції зовнішніх платіжних сервісів. Розроблено архітектуру вебзастосунку з використанням клієнтської частини на базі React та серверної частини на платформі Node.js. Реалізовано підтримку кількох платіжних сервісів із можливістю гнучкого керування доступними методами оплати. Спроєктовано та реалізовано систему автентифікації користувачів, обробки замовлень і збереження даних. Проведено модульне, інтеграційне, системне та приймальне тестування, результати якого підтвердили коректність функціонування розробленого програмного забезпечення. Отримані результати засвідчили ефективність запропонованих архітектурних рішень і можливість практичного використання розробленого вебзастосунку в навчальних і комерційних цілях. ANNOTATION Smirnov O. V. Master’s qualification thesis on the topic “Integration of Payment Systems of an Online Store in Their Software Implementation Using React Technology”. Specialty 121 “Software Engineering”. Cherkasy State Technological University. Cherkasy, 2025. The master’s qualification thesis is devoted to the study and practical implementation of payment system integration in an e-commerce web application. The paper analyzes the features of modern online stores, security and reliability requirements for payment transactions, and approaches to integrating external payment services. A web application architecture was developed using a React-based client side and a Node.js-based server side. Support for multiple payment services with flexible management of available payment methods was implemented. User authentication, order processing, and data storage subsystems were designed and implemented. Unit, integration, system, and acceptance testing were conducted, the results of which confirmed the correctness and stability of the developed software. The obtained results demonstrate the effectiveness of the proposed architectural solutions and the possibility of practical use of the developed web application for educational and commercial purposes. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7050 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Смірнов Олег Віталійович.pdf Restricted Access | 2.65 MB | Adobe PDF | View/Open Request a copy | |
| ДОДАТОК В до кваліфікаційної роботи магістра Смірнова Олега Віталійовича.pdf Restricted Access | 3.06 MB | Adobe PDF | View/Open Request a copy | |
| ДОДАТОК А до кваліфікаційної роботи магістра Смірнова Олега Віталійовича.pdf Restricted Access | 542.29 kB | Adobe PDF | View/Open Request a copy | |
| ДОДАТОК Б до кваліфікаційної роботи магістра Смірнова Олега Віталійовича.pdf Restricted Access | 673.73 kB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
на тему: Інтеграція платіжних систем інтернет-магазину при їх програмній
реалізації за технологією React
Виконав: студент 2 курсу, групи МПЗ-2404
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Смірнов О.В.
(прізвище та ініціали)
Керівник Немченко В.В.
(прізвище та ініціали)
Рецензент Левченко С.П.
(прізвище та ініціали)
Черкаси 2025
ЧДТУ 252489 014 ПЗ
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С.В.
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Смірнов Олег Віталійович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи)Інтеграція платіжних систем інтернет-магазину при їх програмній
реалізації за технологією React
Керівник проекту (роботи) Немченко Вадим В’ячеславович к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 7 » жовтня
2025 року №307/03-03
2. Строк подання студентом проекту (роботи) 16 грудня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси
управління; вимоги до проекту; календарне планування проекту; управління ризиками
проекту; управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Існуючі методи та засоби розв’язання поставлених завдань;
Теоретичні та експериментальні дослідження;
Впровадження результатів досліджень у практику проєктування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
слайд 1, слайд 2, слайд 3, слайд 4, слайд 5, слайд 6, слайд 7, слайд 8, слайд 9, слайд 10, слайд 11,
слайд 12, слайд 13, слайд 14, слайд 15, слайд 16, слайд 17, слайд 18, слайд 19, слайд 20, слайд 21,
слайд 22, слайд 23, слайд 24.
2
ЧДТУ 252489 014 ПЗ
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання вересень 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ виконання
Назва етапів випускної роботи Примітки
п/п етапів випускної
роботи
1 Постановка задачі 02.09.2025 виконано
2 Підготовка завдання 13.09.2025 виконано
3 Погодження завдання 16.09.2025 виконано
4 Затвердження завдання 19.09.2025 виконано
Основна стадія
1 Підбір матеріалів 29.09.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 09.10.2025 виконано
3 Розрахунок основних параметрів роботи 14.10.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 25.10.2025 виконано
5 Оформлення первісної редакції роботи 03.11.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 15.11.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 28.11.2025 виконано
кінцевій редакції
3 Попередній захист роботи 07.12.2025 виконано
4 Затвердження роботи 10.12.2025 виконано
5 Рецензування роботи 13.12.2025 виконано
6 Захист роботи 16.12.2025
Студент _____________________ Cмірнов О.В.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Немченко В.В.
(підпис) (прізвище та ініціали)
3
ЧДТУ 252489 014 ПЗ
АНОТАЦІЯ
Смірнов О. В. Кваліфікаційна робота магістра на тему «Інтеграція
платіжних систем інтернет-магазину при їх програмній реалізації за технологією
React». Спеціальність 121 «Інженерія програмного забезпечення». Черкаський
державний технологічний університет. Черкаси, 2025.
Кваліфікаційна робота присвячена дослідженню та практичній реалізації
процесу інтеграції платіжних систем у вебзастосунок електронної комерції. У
роботі проаналізовано особливості побудови сучасних інтернет-магазинів,
вимоги до безпеки та надійності платіжних операцій, а також підходи до
інтеграції зовнішніх платіжних сервісів. Розроблено архітектуру вебзастосунку з
використанням клієнтської частини на базі React та серверної частини на
платформі Node.js. Реалізовано підтримку кількох платіжних сервісів із
можливістю гнучкого керування доступними методами оплати. Спроєктовано та
реалізовано систему автентифікації користувачів, обробки замовлень і
збереження даних. Проведено модульне, інтеграційне, системне та приймальне
тестування, результати якого підтвердили коректність функціонування
розробленого програмного забезпечення. Отримані результати засвідчили
ефективність запропонованих архітектурних рішень і можливість практичного
використання розробленого вебзастосунку в навчальних і комерційних цілях.
Ключові слова: ЕЛЕКТРОННА КОМЕРЦІЯ, ПЛАТІЖНІ СИСТЕМИ,
ІНТЕРНЕТ-МАГАЗИН, REACT, NODE.JS, ІНТЕГРАЦІЯ API,
ВЕБЗАСТОСУНОК.
4
ЧДТУ 252489 014 ПЗ
ANNOTATION
Smirnov O. V. Master’s qualification thesis on the topic “Integration of Payment
Systems of an Online Store in Their Software Implementation Using React
Technology”. Specialty 121 “Software Engineering”. Cherkasy State Technological
University. Cherkasy, 2025.
The master’s qualification thesis is devoted to the study and practical
implementation of payment system integration in an e-commerce web application. The
paper analyzes the features of modern online stores, security and reliability
requirements for payment transactions, and approaches to integrating external payment
services. A web application architecture was developed using a React-based client side
and a Node.js-based server side. Support for multiple payment services with flexible
management of available payment methods was implemented. User authentication,
order processing, and data storage subsystems were designed and implemented. Unit,
integration, system, and acceptance testing were conducted, the results of which
confirmed the correctness and stability of the developed software. The obtained results
demonstrate the effectiveness of the proposed architectural solutions and the possibility
of practical use of the developed web application for educational and commercial
purposes.
Keywords: E-COMMERCE, PAYMENT SYSTEMS, ONLINE STORE,
REACT, NODE.JS, API INTEGRATION, WEB APPLICATION.
5
ЧДТУ 252489 014 ПЗ
ЗМІСТ
ВСТУП ............................................................................................................... 8
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................. 11
1.1 Теоретичні засади інтеграції платіжних систем ........................................... 11
1.2 Аналіз існуючих рішень та актуальних проблем.......................................... 14
Висновки до розділу ...................................................................................... 17
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ
ДОСЛІДЖЕННЯ ..................................................................................................... 18
2.1 Теоретичні дослідження .................................................................................. 18
2.1.1 Аналіз суті процесів інтеграції платіжних систем ................................. 18
2.1.2 Процес оплати як взаємодія із зовнішнім середовищем ....................... 19
2.1.3 Формулювання теорії та гіпотези дослідження ...................................... 20
2.1.4 Теоретична модель динамічної інтеграції платіжних провайдерів ...... 21
2.1.5 Математичне дослідження часових характеристик системи ................ 22
2.1.6 Аналіз теоретичних рішень ....................................................................... 22
2.2 Експериментальні дослідження швидкості зміни платіжного
провайдера .............................................................................................................. 24
2.2.1 Експериментальне дослідження швидкості зміни платіжного
провайдера при статичній реалізації ................................................................. 24
2.2.2 Експериментальне дослідження швидкості зміни платіжного
провайдера при динамічній реалізації .............................................................. 25
2.3 Експериментальні дослідження швидкості оплати платіжних
провайдерів ............................................................................................................. 27
2.3.1 Дослідження швидкості оплати при введенні платіжних даних
вручну ................................................................................................................... 28
2.3.2 Дослідження швидкості оплати при автоматичному введенні
платіжних даних .................................................................................................. 28
Висновки до розділу ...................................................................................... 30
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................. 31
3.1 Моделювання предметної області .................................................................. 31
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області .............................................................................. 31
3.1.2 Елементи моделювання предметної області ........................................... 34
3.1.3 Робоча область моделювання ................................................................... 35
3.2. Формування та аналіз вимог .......................................................................... 36
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги .................................................................................... 36
3.2.2 Формування вимог за допомогою діаграми прецедентів ...................... 39
3.2.3 Проєктування логічної структури програмного комплексу ..................... 40
3.2.3.1 Діаграма класів ........................................................................................ 41
3.2.3.2 Діаграма пакетів ...................................................................................... 44
6
ЧДТУ 252489 014 ПЗ
3.2.4 Архітектурне проєктування ...................................................................... 45
3.2.4.1 Діаграма компонентів ............................................................................. 46
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання .......................................................................................................... 47
3.2.5 Моделювання поведінки системи ............................................................... 48
3.2.5.1 Діаграма діяльності ................................................................................. 48
3.2.5.2 Діаграма послідовності .......................................................................... 50
3.2.5.3 Діаграма комунікації .............................................................................. 51
3.2.5.4 Діаграма скінченного автомату ............................................................. 52
Висновки до розділу ...................................................................................... 55
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .................................................................................................... 56
4.1 Розробка програмного комплексу .................................................................. 56
4.1.1 Обґрунтування вибору засобів реалізації ................................................ 56
4.1.2 Опис структурної (функціональної) схеми ............................................. 57
4.1.3 Опис логічної схеми системи ................................................................... 59
4.1.4 Розробка бази даних .................................................................................. 62
4.1.5 Розробка інтерфейсу користувача ............................................................ 64
4.1.6 Опис розробки програмних компонентів ................................................ 66
4.2 Тестування системи ......................................................................................... 75
4.2.1 Модульне тестування ................................................................................ 75
4.2.2 Інтеграційне тестування ............................................................................ 76
4.2.3 Системне тестування ................................................................................. 77
4.2.4 Приймальне тестування ............................................................................ 78
4.3 Приклади впровадженого програмного комплексу ..................................... 79
Висновки до розділу ...................................................................................... 87
ВИСНОВКИ ................................................................................................... 88
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................. 90
ДОДАТОК А ............................................................................................................. 90
ДОДАТОК Б ............................................................................................................. 92
ДОДАТОК В ............................................................................................................. 118
7
ЧДТУ 252489 014 ПЗ
ВСТУП
Актуальність теми. У 2025 році електронна комерція залишається одним
із найбільш динамічних доменів застосування інженерії програмного
забезпечення. Глобальний ринок e-commerce оцінюється більш ніж у $1 трлн [1] і
демонструє стабільне зростання, що зумовлює ускладнення програмних систем,
які забезпечують електронну торгівлю. В Україні онлайн-торгівля також активно
розвивається: у 2024 році обсяг ринку становив близько ₴239 млрд [2], а
зростання кількості онлайн-покупців підвищує вимоги до якості, надійності та
масштабованості програмних рішень.
З точки зору інженерії програмного забезпечення, платформи електронної
комерції є складними програмними системами, що поєднують вебінтерфейси,
серверну бізнес-логіку та зовнішні сервіси. Однією з ключових підсистем таких
систем є платіжна інфраструктура, яка безпосередньо впливає на коректність
виконання бізнес-процесів, безпеку обробки даних та користувацький досвід. За
даними Baymard Institute, оптимізована платіжна інфраструктура сприяє
зменшенню кількості покинутих кошиків і підвищенню конверсії [3], що
підкреслює її значущість як об’єкта інженерного проєктування, а не лише бізнес-
функціональності.
Водночас традиційні підходи до інтеграції платіжних систем часто
суперечать базовим принципам інженерії програмного забезпечення. Жорстка
зв’язаність компонентів, складність супроводу та обмежені можливості
масштабування ускладнюють еволюцію програмного продукту, його тестування
та адаптацію до нових вимог. Особливо гостро ці проблеми проявляються в
сучасних застосунках, де критичними є модульність, чітке розмежування
відповідальностей і можливість незалежного розвитку окремих компонентів.
У цьому контексті актуальним завданням інженерії програмного
забезпечення є проєктування динамічної системи інтеграції платіжних сервісів,
яка дозволяє підключати та відключати платіжні модулі без змін у коді
застосунку. Такий підхід забезпечує зниження технічного боргу, підвищення
8
ЧДТУ 252489 014 ПЗ
масштабованості й безпеки системи, а також адаптацію програмного рішення до
змінних бізнес-вимог.
Зв’язок з науковими програмами, планами, темами. Дана робота
виконана в рамках наукових досліджень кафедри програмного забезпечення
автоматизованих систем.
Мета і завдання дослідження. Визначення впливу модуля динамічного
підключення на швидкість зміни доступних платіжних сервісів та дослідження їх
часових характеристик.
Для досягнення мети поставлено такі завдання:
1 Провести аналіз сучасних платіжних сервісів та підходів до їх інтеграції
у вебзастосунки.
2 Дослідити архітектуру React SPA та методи безпечної взаємодії з
платіжними API.
3 Розробити модель динамічного підключення платіжних модулів і
керування ними через панель адміністратора.
4 Реалізувати прототип інтернет-магазину.
Об’єкт дослідження. Процес інтеграції платіжних систем у вебзастосунки
електронної комерції.
Предмет дослідження. Методи динамічного підключення та конфігурації
платіжних сервісів у React-додатках.
Методи дослідження. У роботі використано такі методи:
1 Порівняння для вибору платіжних провайдерів, вибору технологічного
стеку.
2 Експериментальний метод для тестування коректної роботи додатку.
3 Вимірювання для оцінки швидкості виконання транзакцій.
4 Системний метод для узгодження модулів фронтенду, бекенду та
платіжних сервісів.
Наукова новизна. Наукова новизна полягає у створенні та дослідженні
модульної системи динамічної інтеграції платіжних сервісів, яка дозволяє
увімкнути/вимкнути будь-який платіжний модуль без змін у кодовій базі.
9
ЧДТУ 252489 014 ПЗ
Практичне значення. Розроблена система є робочим прототипом
динамічної платіжної інфраструктури, інтегрованої у інтернет-магазин на React.
Проєкт може бути використаний у реальних комерційних застосунках, як шаблон
для інтеграції платежів у стартапах, а також у навчальних курсах з веброзробки
та архітектури SPA.
Особистий внесок автора. Автором самостійно:
1 Розроблено архітектуру React-застосунку з динамічним підключенням
платіжних систем.
2 Спроєктовано та розроблено прототип інтернет-магазину.
3 Реалізовано адаптивний інтерфейс.
4 Налаштовано серверну частину для безпечної взаємодії з зовнішніми
сервісами.
5 Створено механізм адміністрування активних платіжних сервісів.
6 Проведено тестування та оптимізацію рішення.
7 Розгорнуто додаток в мережі Інтернет.
10
ЧДТУ 252489 014 ПЗ
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Теоретичні засади інтеграції платіжних систем
Історія платіжних систем в електронній комерції починається з 1990-х
років, коли з'явилися перші онлайн-магазини, такі як Amazon (1994) та eBay
(1995). На той час платежі здійснювалися переважно через кредитні картки з
ручним введенням даних, що було вразливим до шахрайства. У 1998 році
з'явилася PayPal, яка ввела концепцію електронного гаманця[4], спрощуючи
транзакції без прямого обміну картковими даними. Перша онлайн-платіжна
система, First Virtual Holdings, з'явилася ще у 1994 році, покладаючись на email-
підтвердження.
У 2000-х роках розвиток API дозволив інтегрувати платежі безпосередньо в
веб-додатки. Stripe, заснована у 2010 році, стала піонером у спрощенні інтеграції
для розробників, пропонуючи готові SDK для JavaScript та інших мов. У цей
період з'явилися стандарти безпеки, такі як PCI DSS (Payment Card Industry Data
Security Standard, 2004)[5], що регулюють обробку карткових даних.
З 2010-х років тенденції змінилися в бік мобільних платежів: Apple Pay
(2014) та Google Pay (2015) інтегрували біометрію та NFC. У контексті React,
який з'явився у 2013 році від Meta, інтеграція платежів стала частиною single-page
applications (SPA), де фронтенд обробляє UI, а бекенд – безпечні транзакції.
Сучасні системи, як LiqPay (від ПриватБанку, 2011) в Україні, адаптувалися до
локальних ринків, підтримуючи гривню та інтеграцію з React через вебхуки.
Історія свідчить про еволюцію від статичних форм до динамічних, API-
орієнтованих рішень, що забезпечують масштабованість та безпеку в React-
проєктах.
Далі наведено аналіз та короткий синтез праць зарубіжних авторів, які
допомогли краще ознайомитися з темою та поглибити знання в ній.
Згідно Methods-of-Payment Survey Report[6] частка оплати готівкою в
Канаді у 2021р. зменшилася до 22% порівнянно з 33% у 2017р., при цьому частка
11
ЧДТУ 252489 014 ПЗ
оплати картками збільшилась на 6%, що свідчить про підвищення популярності
безконтактної оплати. Це також вказує на необхідність реалізації основних
платіжних систем у інтернет-магазині.
Згідно з дослідженням A. Hazar та Ş. Babuşcu[7], сучасні платіжні сервіси
орієнтуються на інтеграцію з клієнтськими вебзастосунками, що зумовлює
зростання популярності односторінкових архітектур.
Згідно результатів емпіричного аналізу, наведених Buranasujja R. і
Kraiwanit T. [8] можна сказати, що обраний платіжний метод безпосередньо
впливає на поведінку користувачів і рівень завершення покупок.
Dahlberg та ін.[9](2008) виконали систематичний огляд досліджень
мобільних платежів і виокремили як технічні, так і соціально-економічні
фактори, що визначали їхній розвиток. Автори підкреслюють необхідність
відокремлення платіжної логіки від бізнес-логіки продавця та виділяють питання
довіри й безпеки як ключові драйвери прийняття платежів, що узгоджується з
подальшим впровадженням електронних гаманців і API-орієнтованих рішень.
Anderson та Moore[10](2006) показують, що значна частина проблем
інформаційної безпеки виникає через невирівнані економічні стимули між
учасниками екосистеми. З огляду на це використання сертифікованих платіжних
шлюзів і стандартів (наприклад, PCI DSS) виглядає виправданим механізмом
мінімізації ризиків, адже перекладає частину відповідальності за збереження
карткових даних на спеціалізованих провайдерів.
Огляд Almeida та ін. [11] узагальнює існуючі платіжні системи та пропонує
їх класифікацію за типом архітектури, способом інтеграції та роллю платіжного
провайдера. Автори підкреслюють, що сучасні e-commerce системи тяжіють до
використання зовнішніх платіжних шлюзів із API-орієнтованою взаємодією, що
дозволяє зменшити складність реалізації та підвищити рівень безпеки.
Згідно з результатами Arango та співавт.[12], вибір платіжного методу
значною мірою залежить від зручності та наявних стимулів у точці оплати.
Автори доводять, що користувачі частіше завершують транзакцію, якщо
12
ЧДТУ 252489 014 ПЗ
доступний знайомий та швидкий спосіб оплати, що підтверджує необхідність
підтримки популярних платіжних методів в інтернет-магазинах.
Дослідження Mallat[13] показує, що ключовими чинниками прийняття
цифрових платежів є сприймана зручність, довіра та сумісність з повсякденними
сценаріями користувачів. Ці результати підтверджують, що технічна реалізація
платіжної системи повинна враховувати не лише безпеку, але й простоту
інтеграції у користувацький інтерфейс.
Zachariadis та Ozcan[14] розглядають API як ключовий елемент цифрової
трансформації фінансових сервісів. Автори зазначають, що відкриті та добре
документовані API дозволяють швидко інтегрувати платіжні сервіси у сторонні
вебзастосунки, що безпосередньо вплинуло на розвиток сучасних платіжних
платформ і екосистем.
У роботі V. Garg, S.Khan та ін. [15] зазначається, що монолітна архітектура
платіжних систем ускладнює масштабування та впровадження нових платіжних
сервісів. Це зумовлює доцільність переходу до модульних або мікросервісних
архітектур для забезпечення масштабованості та спрощення інтеграції нових
платіжних методів.
У кваліфікаційній роботі Yufei Wang[16] узагальнив ключові етапи
платіжного workflow: підключення мерчанта, авторизація платежів, їх обробка,
підтримка рекурентних транзакцій, асинхронна взаємодія через webhooks та
управління поверненнями коштів. Аналіз роботи покращив розуміння принципу
роботи платіжних систем та надав додаткові знання для їх оптимальної реалізації.
На основі аналізу існуючих підходів до інтеграції блокчейн-платежів [17]
можна стверджувати, що, попри технічну реалізованість, їх широке використання
у вебзастосунках електронної комерції потребує подальшого вдосконалення як
технологічної, так і нормативної бази. Тому для даної роботи реалізація
блокчейн-платежів буде опущена.
Сучасні огляди, зокрема від MakersDen[18], підкреслюють, що React
забезпечує продуктивність та адаптивність інтерфейсу, що є важливим фактором
для зручності користувачів інтернет-магазинів
13
ЧДТУ 252489 014 ПЗ
Згідно з аналітичними оглядами компанії Prakash Software Solutions [19],
React стає одним із провідних інструментів для створення сучасних інтернет-
магазинів завдяки своїй гнучкості, масштабованості та підтримці SPA-
архітектури.
1.2 Аналіз існуючих рішень та актуальних проблем
Серед основних методів інтеграції платіжних систем можна виділити
декілька. Наведемо основні.
API-інтеграція. Один із базових та найгнучкіших підходів є використання
REST, які надають платіжні сервіси.
Переваги
‒ максимальний контроль над процесом платежу;
‒ можливість кастомізації під бізнес-вимоги;
‒ підтримка складних сценаріїв (підписки, часткові списання, рекурентні
платежі);
‒ гнучке керування обробкою подій через Webhooks.
Недоліки
‒ висока складність реалізації;
‒ потреба в окремій логіці безпеки на бекенді;
‒ залежність від стабільності API провайдера.
Інтеграція через SDK. Щоб спростити роботу з API, провайдери
пропонують SDK для JavaScript, Node.js, PHP, Python та інших мов.
Переваги
‒ зменшення кількості рутинного коду;
‒ зручні методи для створення платежів;
‒ автоматична обробка даних, шифрування і токенізація;
‒ швидша інтеграція, ніж при роботі через API напряму.
Недоліки
‒ прив’язка до певної версії SDK;
‒ менш гнучке налаштування, ніж при “чистому” API.
14
ЧДТУ 252489 014 ПЗ
Цей підхід є найпоширенішим у React SPA, адже дозволяє зменшити ризик
помилок при інтеграції та допомагає підтримувати сучасні UX-патерни.
Вбудовані платіжні віджети. Віджети дозволяють відображати платіжну
форму без переходу на нову сторінку.
Переваги
‒ кращий UX, адже процес проходить у рамках сторінки;
‒ адаптивні компоненти, що легко підключаються;
‒ менше вимог до бекенду.
Недоліки
‒ залежність від готових компонентів;
‒ обмеження кастомізації;
‒ можливі проблеми з безпекою транзакцій.
Вбудовані SDK/плагіни для CMS чи платформ. Підключення платіжних
модулів для WooCommerce, Shopify, OpenCart, Joomla.
Переваги
‒ мінімум коду;
‒ часті оновлення.
Недоліки
‒ обмежена гнучкість;
‒ залежність від екосистеми CMS.
Сервіс apix-drive[20] та iPaaS-платформи.
Переваги
‒ можливість відстежувати статуси оплат і обробляти інформацію без
залучення програмістів;
‒ можна швидко додавати нові платіжні сервіси для моніторингу, не
змінюючи код застосунку;
‒ інтеграція з різними сервісами.
Недоліки
‒ неможливість приймати платежі безпосередньо;
15
ЧДТУ 252489 014 ПЗ
‒ будь-які технічні збої в роботі даних сервісів можуть обмежити
видимість транзакцій;
‒ сервіс зазвичай платний, що додає фінансове навантаження на проєкт.
Даний сервіс та iPaaS-платформи загалом є корисними для адміністрування
та централізованого моніторингу транзакцій, спрощує життя програмістам і
адміністраторам, але не замінює пряме приймання платежів через SDK або API.
16
ЧДТУ 252489 014 ПЗ
Висновки до розділу
У результаті аналізу історії платіжних систем, наукових робіт, а також
існуючих підходів до інтеграції платіжних систем у вебзастосунки встановлено,
що традиційні рішення здебільшого реалізуються у вигляді статично
інтегрованих модулів. Такий підхід потребує постійної участі розробників під час
додавання, модифікації або відключення платіжних методів, що ускладнює
супровід програмного забезпечення та знижує гнучкість системи. Водночас
адміністративний персонал, як правило, позбавлений можливості самостійно
керувати доступними способами оплати без втручання у програмний код.
Аналіз сторонніх інтеграційних сервісів, зокрема apix-drive, показав, що
подібні платформи можуть бути використані як допоміжні інструменти для
синхронізації або моніторингу транзакцій, однак вони не забезпечують
повноцінної інтеграції платіжних сервісів.
Узагальнення наукових та прикладних джерел свідчить, що застосування
модульних та API-орієнтованих архітектур дозволяє підвищити масштабованість
і розширюваність платіжних систем, а також ізолювати платіжну логіку від
клієнтського рівня застосунку. У цьому контексті динамічна інтеграція платіжних
сервісів забезпечує декілька ключових переваг:
– для адміністраторів можливість оперативного підключення або
відключення платіжних методів без залучення розробників;
– для розробників наявність централізованої точки інтеграції платіжних
сервісів, що спрощує підтримку коду, зменшує дублювання логіки та полегшує
масштабування системи.
Зважаючи на аналіз існуючих рішень можна сказати, що отримані
результати підтверджують актуальність і доцільність розробки модульної
системи динамічної інтеграції платіжних сервісів у односторінкових
вебзастосунках на базі React.
17
ЧДТУ 252489 014 ПЗ
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
2.1.1 Аналіз суті процесів інтеграції платіжних систем
У системах електронної комерції процес оплати є ключовим елементом
взаємодії між користувачем та інформаційною системою інтернет-магазину,
оскільки саме він забезпечує завершення основного бізнес-процесу — здійснення
покупки. На відміну від внутрішніх підсистем, таких як керування товарами або
обробка замовлень, платіжна підсистема безпосередньо пов’язана з
використанням зовнішніх сервісів.
Платіжні провайдери належать до зовнішнього середовища системи та
функціонують незалежно від розробника інтернет-магазину. Вони
характеризуються власними правилами обробки транзакцій, часовими
затримками, протоколами взаємодії, вимогами до безпеки та можливими змінами
інтерфейсів доступу. Це зумовлює залежність інформаційної системи від
чинників, які не піддаються прямому контролю з її боку.
З точки зору інтеграції платіжних сервісів можна виокремити два
принципово різні підходи: статичний та динамічний.
При статичній інтеграції логіка взаємодії з конкретним платіжним
провайдером вбудовується безпосередньо в програмн ий код системи. У такому
випадку будь-яка зміна зовнішнього середовища, зокрема оновлення API
платіжного сервісу, тимчасова недоступність провайдера або необхідність його
заміни, призводить до потреби модифікації програмного коду та повторного
розгортання системи. Даний підхід формує жорсткий зв’язок між внутрішньою
архітектурою інформаційної системи та зовнішніми платіжними сервісами, що
ускладнює процес адаптації системи до змін зовнішнього середовища.
При динамічній інтеграції інформація про активні платіжні методи
відокремлюється від основної бізнес-логіки системи та зберігається у
конфігураційній моделі. Зміна платіжного провайдера здійснюється шляхом
оновлення конфігураційних параметрів без втручання у програмний код
18
ЧДТУ 252489 014 ПЗ
інформаційної системи. Таким чином, інтеграція платіжних систем може
розглядатися як окремий керований процес, властивості якого залежать від
обраного підходу до взаємодії з платіжними сервісами.
2.1.2 Процес оплати як взаємодія із зовнішнім середовищем
Процес оплати в інформаційних системах електронної комерції є
прикладом взаємодії відкритої системи з зовнішнім середовищем. На відміну від
внутрішніх підсистем інтернет-магазину, таких як керування товарами або
обробка замовлень, платіжна підсистема значною мірою залежить від зовнішніх
сервісів, які не контролюються розробником системи.
Зовнішнє середовище у даному випадку представлене платіжними
провайдерами, що здійснюють обробку фінансових транзакцій відповідно до
власних технічних регламентів, протоколів безпеки та бізнес-правил.
Інформаційна система інтернет-магазину виступає ініціатором платіжного
процесу, однак не має прямого впливу на внутрішні алгоритми обробки платежів,
що зумовлює необхідність адаптації системи до умов, заданих зовнішнім
середовищем.
Взаємодія між інформаційною системою та платіжним провайдером
відбувається за принципом обміну повідомленнями. Система формує платіжний
запит, який містить параметри транзакції, передає його зовнішньому сервісу та
очікує відповідь у вигляді підтвердження або відмови в оплаті. При цьому
платіжний процес включає як автоматизовані етапи, так і етапи взаємодії з
користувачем.
З теоретичної точки зору загальний час виконання платіжної транзакції є
сумою часу виконання внутрішніх операцій системи, часу взаємодії з
користувачем та часу обробки запиту зовнішнім платіжним сервісом. До
внутрішніх факторів належать формування платіжного запиту та обробка
відповіді, тоді як зовнішні фактори включають затримки мережевої взаємодії та
особливості обробки транзакцій платіжним провайдером. Окрему роль у процесі
оплати відіграє спосіб введення платіжних даних. Ручне введення реквізитів
19
ЧДТУ 252489 014 ПЗ
платіжної картки потребує активної участі користувача та збільшує тривалість
платіжного процесу. Натомість автоматизовані методи введення платіжних даних
дозволяють зменшити час взаємодії користувача з системою, що позитивно
впливає на загальний час виконання транзакції.
Таким чином, процес оплати доцільно розглядати як сукупність внутрішніх
і зовнішніх етапів, кожен з яких може вносити часові затримки. Це зумовлює
необхідність теоретичного аналізу факторів, що впливають на ефективність
взаємодії між інформаційною системою інтернет-магазину та платіжними
сервісами, і створює основу для подальших експериментальних досліджень
часових характеристик процесу оплати.
2.1.3 Формулювання теорії та гіпотези дослідження
Теорія
У класичних вебзастосунках інтернет-магазинів платіжні системи зазвичай
інтегруються статично, тобто кожен платіжний провайдер підключається
безпосередньо в коді клієнтської або серверної частини. Такий підхід є відносно
простим у реалізації, однак має низку обмежень, зокрема залежність бізнес-
логіки від конкретних платіжних API та ускладнення процесу заміни або
додавання нових платіжних провайдерів.
Зі зростанням кількості платіжних сервісів або необхідністю тестування на
реальних користувачах виникає потреба у більш гнучкому підході — динамічній
інтеграції платіжних систем. Даний підхід передбачає можливість підключення
або відключення платіжного провайдера без необхідності перерозгортання
застосунку, а лише шляхом перемикання вибраного сервісу у адмін-панелі.
Гіпотеза
Передбачається, що різні платіжні системи мають відмінні часові
характеристики завершення оплати, які визначаються їхніми особливостями
обробки транзакцій. Динамічний механізм вибору та підключення платіжного
провайдера дозволяє експериментально виміряти та порівняти ці часові
20
ЧДТУ 252489 014 ПЗ
характеристики, вивести середній час оплати для кожної платіжної системи і
обрати найдоцільнішу без внесення змін у структуру клієнтського застосунку.
При використанні механізму динамічної інтеграції платіжних систем зникає
необхідність перерозгортання додатку, а зміна методу оплати відбувається
майже миттєво. Це створює передумови для вибору оптимального платіжного
провайдера на основі експериментальних даних.
2.1.4 Теоретична модель динамічної інтеграції платіжних провайдерів
Для формалізації процесів інтеграції платіжних систем розглянемо
узагальнену модель системи електронної комерції у вигляді множини
взаємопов’язаних компонентів:
(2
.1)
де
U — користувач системи, який ініціює процес оплати;
A — інформаційна система інтернет-магазину;
— множина платіжних провайдерів;
C — конфігураційний механізм, що визначає набір активних платіжних
провайдерів;
R — механізм маршрутизації платіжних запитів;
E — зовнішнє середовище.
У межах динамічної інтеграції система A не взаємодіє безпосередньо з
конкретним платіжним провайдером, а використовує уніфікований механізм
маршрутизації R, який на основі конфігурації C визначає активний платіжний
сервіс з множини P.
Зміна параметрів конфігурації C призводить до зміни активного платіжного
провайдера без необхідності модифікації внутрішньої логіки системи A. Таким
чином, час зміни платіжного провайдера в даній моделі залежить лише від часу
оновлення конфігурації та застосування нових параметрів маршрутизації.
21
ЧДТУ 252489 014 ПЗ
Запропонована модель дозволяє абстрагуватися від особливостей
конкретних платіжних API та розглядати процес інтеграції платіжних систем як
універсальний для широкого класу інформаційних систем електронної комерції.
2.1.5 Математичне дослідження часових характеристик системи
Для кількісної оцінки ефективності інтеграції платіжних сервісів введемо
часові характеристики процесів у системі.
Час зміни активного платіжного провайдера визначається як:
(2
.2)
де
‒ — момент ініціації зміни конфігурації платіжного сервісу;
‒ — момент, коли зміну можна побачити в інтерфейсі користувача.
Швидкість транзакції
Час завершення транзакції можна описати формулою:
(2
.3)
де
‒ — момент часу, коли користувач натиснув кнопку оплати
вибраним сервісом;
‒ — момент часу, коли провайдер повернув підтвердження
оплати.
Звідси слідує, що чим менше значення тим швидше проходить процес
оплати, а чим менше значення тим швидше можна змінити активних
платіжних провайдерів.
2.1.6 Аналіз теоретичних рішень
22
ЧДТУ 252489 014 ПЗ
Запропоновані теоретичні моделі інтеграції платіжних провайдерів та
процесу платіжної транзакції дозволяють провести якісний аналіз впливу способу
інтеграції платіжних сервісів на експлуатаційні характеристики інформаційної
системи інтернет-магазину.
Введення показника часу зміни платіжного провайдера дає
можливість формалізувати процес адаптації системи до змін платіжної
конфігурації. У випадку статичної інтеграції значення включає додаткові
етапи, пов’язані з модифікацією програмного коду, повторною збіркою та
розгортанням застосунку. Таким чином, даний показник залежить не лише від
технічних характеристик системи, але й від організаційних факторів, що знижує
оперативність керування платіжними сервісами.
На відміну від цього, у межах динамічної інтеграції час
визначається переважно швидкістю оновлення конфігураційних параметрів та
застосуванням нових правил маршрутизації платіжних запитів. Теоретично це
дозволяє зменшити час зміни платіжного провайдера на порядки, що
безпосередньо підвищує гнучкість системи та знижує витрати на її супровід і
експлуатацію.
Аналіз теоретичної моделі також показує, що уніфікований механізм
інтеграції створює передумови для порівняльного аналізу різних платіжних
провайдерів у межах єдиного інформаційного середовища. Введення показника
часу виконання платіжної транзакції дозволяє оцінювати ефективність
процесу оплати незалежно від конкретної реалізації платіжного сервісу.
З точки зору теорії систем, уніфікація процесу взаємодії з платіжними
провайдерами зменшує вплив випадкових факторів на результати вимірювань та
підвищує достовірність експериментальних досліджень. Це забезпечує коректну
інтерпретацію отриманих результатів і дозволяє узагальнювати їх для широкого
класу систем електронної комерції.
Крім того, розглянуті теоретичні рішення дозволяють пояснити вплив
способу введення платіжних даних на часові характеристики процесу оплати.
23
ЧДТУ 252489 014 ПЗ
Таким чином, проведений аналіз теоретичних рішень підтверджує
доцільність використання динамічної інтеграції платіжних провайдерів як
ефективного підходу до побудови платіжних підсистем інтернет-магазинів та
обґрунтовує необхідність подальших експериментальних досліджень для
кількісної оцінки запропонованих рішень.
2.2 Експериментальні дослідження швидкості зміни платіжного
провайдера
2.2.1 Експериментальне дослідження швидкості зміни платіжного
провайдера при статичній реалізації
Для статичного варіанту припустимо, що час для
видалення/закоментування коду для 1-го сервісу ≈ 2хв. (залежить від швидкості
роботи програміста та зв’язків з іншими системами, які має конкретний сервіс).
Для вимірювання швидкості розгортання застосунку використаємо сервіс
Render на якому розгорнутий наш застосунок[21]. В логах розгортання можна
зручно подивитись часові штампи для подій. (рис. 2.1, 2.2) Розгорнемо наш
застосунок та обчислимо необхідний для цього час:
Рисунок 2.1 ‒ Лог початку розгортання додатку
Як бачимо з логів 11:50:59 — час початку розгортання.
Опустивши непотрібні логи подивимось час закінчення розгортання:
Рисунок 2.2 ‒ Лог завершення розгортання додатку
Як бачимо з логів 11:52:21— час завершення розгортання.
24
ЧДТУ 252489 014 ПЗ
Обчисливши різницю бачимо, що час необхідний для розгортання склав
1хв. 22 сек.
Для достовірності проведемо експеримент декілька разів. Результати
представимо в таблиці 2.1.
Таблиця 2.1
Швидкість розгортання застосунку при ручній зміні платіжних методів
Номер експерименту Час зміни платіжного методу
1 3хв. 22 сек.
2 3хв. 13 сек.
3 3хв. 19 сек.
4 3хв. 15 сек.
5 3хв. 20 сек.
Середній час розгортання склав 3хв. 18 сек.
2.2.2 Експериментальне дослідження швидкості зміни платіжного
провайдера при динамічній реалізації
Для динамічного варіанту, який і є основною ідеєю даної роботи
використаємо розроблену адмін-панель. Початкове положення перемикача буде
“disabled” (вимкнено) (рис. 2.3)
Рисунок 2.3 ‒ Кнопка перемикання платіжного провайдера PayPal у положенні
“вимкнено”
25
ЧДТУ 252489 014 ПЗ
В цьому випадку кнопка в кошику не повинна відображатись (рис. 2.4)
Рисунок 2.4 ‒ Вигляд корзини при вимкненому провайдері “PayPal”
Перемкнемо положення перемикача на “enabled” (увімкнено) (рис. 2.5). Це і
буде нашою точкою початку відліку.
Рисунок 2.5 ‒ Кнопка перемикання платіжного провайдера PayPal у положенні
“увімкнено”
Тепер відкриємо корзину ще раз та впевнемось, що кнопка дійсно
активувалась (рис. 2.6). Це буде нашою точкою завершення відліку
26
ЧДТУ 252489 014 ПЗ
Рисунок 2.6 ‒ Вигляд корзини при увімкненому провайдері “PayPal”
Завдяки логуванню у консолі можна перевірити час, який було витрачено
(рис. 2.7).
Рисунок 2.7 ‒ Лог часу перемикання провайдера
Повторимо експеримент декілька разів та занесемо отримані дані в
таблицю 2.2.
Таблиця 2.2
Швидкість зміни платіжного провайдера з адмін-панелі
Номер експерименту Час зміни платіжного методу
1 1263 мсек.
2 1105 мсек.
3 1195 мсек.
4 770 мсек.
5 927 мсек.
Середній час відображення нової кнопки склав 1052 мсек.
Тож згідно тестових даних = 1052 мсек., що в рази швидше аніж при
статичній реалізації (> 3 хв.).
2.3 Експериментальні дослідження швидкості оплати платіжних
провайдерів
Дане дослідження передбачає визначення найшвидшого методу оплати, що
прямо впливає на ефективність роботи інтернет-магазину. Для експерименту
було обрано 3 наступні провайдери: Paypal — найпопулярніша платіжна система
у Європі та Північній Америці після кредитних карток[22, 23], Stripe —
альтернатива Paypal, займає ≈ 25% частки ринку глобальної обробки платежів[23]
27
ЧДТУ 252489 014 ПЗ
та WayForPay — альтернатива для українського ринку з можливістю
підключення платіжного віджета.
2.3.1 Дослідження швидкості оплати при введенні платіжних даних вручну
Для цього дослідження будемо симулювати оплату з введенням даних
карти вручну за умови, що ми вже створили акаунт в усіх представлених
платіжних системах. Результати експерименту обробляються програмно та
зберігаються до бази даних SQLite завдяки чому ми можемо отримати
структуроване наглядне представлення отриманих результатів. Проведемо
експеримент 5 разів для кожної платіжної системи та оцінимо результати. Зібрані
дані представимо у таблиці 2.3.
Таблиця 2.3
Час оплати при введенні даних вручну
Час (мсек)
Платіжний
провайдер 1-ша 2-га 3-тя 4-та 5-та Середнє
спроба спроба спроба спроба спроба значення
Paypal 33238 24961 21642 21592 22894 24865,4
Stripe 20371 28776 18657 18380 19307 21098,2
WayForPay 43003 39587 41151 38042 41983 40753,2
Як бачимо з таблиці Stripe має незначну перевагу у швидкості над Paypal і
майже вдвічі випереджає WayForPay. Значно повільніший час для WayForPay
зумовлений необхідністю обов’язкового підтвердження оплати через мобільний
додаток банкінгу користувача.
2.3.2 Дослідження швидкості оплати при автоматичному введенні
платіжних даних
28
ЧДТУ 252489 014 ПЗ
Для цього дослідження будемо симулювати оплату максимально швидким
доступним методом для кожної з платіжних систем (автозаповнення, Google Pay,
Stripe Link тощо). Результати експерименту занесемо до таблиці 2.4.
Таблиця 2.4
Час оплати при автоматичному введенні даних
Час (мсек)
Платіжний
провайдер 1-ша 2-га 3-тя 4-та 5-та Середнє
спроба спроба спроба спроба спроба значення
Paypal 7060 5285 4705 5640 4420 5422
Stripe 9221 9266 8298 8929 8782 8899,2
WayForPay 28007 32161 26317 25789 35587 29572,2
Як бачимо автоматичне введення даних (за умови збережених даних
картки) значно пришвидшує процедуру оплати для усіх сервісів, а аутсайдером
знову виявився WayForPay з необхідністю обов’язкового підтвердження оплати
через мобільний застосунок.
29
ЧДТУ 252489 014 ПЗ
Висновки до розділу
Отримані результати показали, що при статичному підключенні платіжної
системи процес її заміни або відключення вимагає внесення змін у програмний
код та повторного розгортання застосунку, середній час якого склав приблизно 3
хвилини 18 секунд. Натомість динамічна реалізація, що базується на
використанні адміністративної панелі та конфігураційних параметрів, дозволяє
виконати зміну платіжного провайдера за середній час близько 1052 мс, що є на
порядок швидше.
Таким чином, експериментальні результати підтверджують гіпотезу про те,
що динамічна інтеграція платіжних систем суттєво підвищує гнучкість та
оперативність керування платіжною інфраструктурою інтернет-магазину без
необхідності повторного розгортання застосунку.
Дослідження швидкості оплати за допомогою реалізованої системи
показало, що PayPal та Stripe демонструють найкращі показники швидкості, тоді
як WayForPay значно їм поступається через особливості механізму
підтвердження транзакцій.
Таким чином, результати експериментальних досліджень доводять
доцільність застосування динамічної інтеграції платіжних провайдерів у React-
застосунках, оскільки вона забезпечує високу гнучкість, масштабованість та
можливість обґрунтованого вибору оптимального платіжного сервісу на основі
експериментально отриманих часових характеристик.
30
ЧДТУ 252489 014 ПЗ
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
3.1 Моделювання предметної області
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання охоплює процеси та інформаційні
взаємодії, пов’язані з функціонуванням системи електронної комерції,
призначеної для реалізації товарів через вебінтерфейс із використанням сучасних
платіжних сервісів. У межах даної предметної області розглядаються сценарії
взаємодії користувачів із системою, механізми обробки замовлень та виконання
платіжних операцій.
До предметної області належать процеси перегляду каталогу товарів,
формування кошика, оформлення замовлення, вибору способу оплати та
завершення платіжної операції. Окрему роль відіграють процеси автентифікації
та авторизації користувачів, які забезпечують контроль доступу до
функціональних можливостей системи та розмежування прав між звичайними
користувачами й адміністраторами.
Важливою складовою предметної області є взаємодія з зовнішніми
платіжними системами, що використовуються для виконання фінансових
транзакцій. Предметна область також включає сценарії керування доступністю
платіжних методів, що дозволяє адміністраторам системи гнучко налаштовувати
перелік підтримуваних платіжних сервісів.
Модель предметної області
На основі аналізу предметної області побудовано концептуальну модель,
яка відображає основні сутності системи електронної комерції та взаємозв’язки
між ними і зображено на рис. 3.1. Ключовою сутністю предметної області є
користувач, який здійснює перегляд доступних товарів і формує кошик із
31
ЧДТУ 252489 014 ПЗ
вибраних позицій. Кошик складається з позицій кошика, кожна з яких поєднує
конкретний товар та кількість одиниць, що дозволяє визначити склад
майбутнього замовлення.
Рисунок 3.1 ‒ Модель предметної області
У процесі оформлення покупки на основі вмісту кошика формується
замовлення, яке фіксує перелік вибраних товарів та відображає поточний стан
виконання покупки. Замовлення є центральним елементом процесу купівлі та
пов’язує користувача з результатом платіжної операції. Платіж відображає
процес оплати замовлення користувачем із використанням обраного способу
оплати.
Сутність способу оплати виділено окремо, оскільки вона безпосередньо
пов’язана з предметом дослідження — інтеграцією та порівняльним аналізом
платіжних систем, що використовуються в системі електронної комерції.
Словник предметної області
Словник предметної області використовується для формалізації основних
термінів і понять, що застосовуються під час опису та проєктування системи
32
ЧДТУ 252489 014 ПЗ
електронної комерції. Він забезпечує однозначне трактування сутностей
предметної області та використовується як основа для подальшого моделювання
системи, зокрема побудови діаграм і проєктування структури даних. Словник
представлений у таблиці 3.1.
Таблиця 3.1
Словник предметної області
Назва
№ Назва (укр.) Опис
(англ.)
Фізична особа, яка взаємодіє з вебзастосунком,
1 Користувач User переглядає товари, формує кошик та ініціює
оформлення замовлення.
Фіксує здійснення оплати замовлення
2 Платіж Payment
користувачем.
Окрема одиниця продукції, що доступна для
3 Товар Product перегляду та може бути додана до кошика
користувача.
Містить перелік позицій товарів, обраних
4 Кошик Cart користувачем для подальшого оформлення
замовлення.
Сутність, що поєднує конкретний товар та його
Позиція
5 Cart Item кількість і використовується для формування
кошика
складу кошика та замовлення.
Зафіксована сукупність позицій кошика,
6 Замовлення Order сформована користувачем у процесі оформлення
покупки. Містить результат платіжної операції.
Спосіб Payment
7 Метод оплати вибраного замовлення.
оплати Method
33
ЧДТУ 252489 014 ПЗ
3.1.2 Елементи моделювання предметної області
Для моделювання предметної області задіяна підмножина мови UML
представлена у таблиці 3.2.
Таблиця 3.2
Елементи моделювання предметної області
Графічний
Назва елемента
символ
дійова особа
варіант використання
клас
пакет
об’єкт
діяльність
компонент
стан
вузол
Логічний з’єднувач (розгалуджувач)
34
ЧДТУ 252489 014 ПЗ
лінія життя, фокус управління
початковий і кінцевий стан
Наступним кроком опишемо єднальні елементи UML, що плануються до
використання, що зображені у таблиці 3.3.
Таблиця 3.3
Єднальні елементи UML, що плануються до використання
Графічний Назва елемента
символ
відношення
асоціації
відношення
залежності
відношення
успадкування
відношення
агрегації
відношення
композиції
простий потік
управління
виклик
повернення
3.1.3 Робоча область моделювання
В якості робочої області моделювання розглядається вебзастосунок
електронної комерції, реалізований за клієнт-серверною архітектурою.
Клієнтська частина системи представлена інтерфейсом користувача, який
35
ЧДТУ 252489 014 ПЗ
забезпечує взаємодію користувача з каталогом товарів, кошиком та процесом
оформлення замовлення. Доступ до функціоналу оплати здійснюється через
даний інтерфейс шляхом вибору одного з доступних методів оплати.
Серверна частина системи відповідає за обробку запитів від клієнта,
валідацію даних замовлення та ініціацію платіжних операцій. Під час вибору
методу оплати сервер формує платіжну сесію та взаємодіє із зовнішніми
платіжними сервісами, передаючи необхідні параметри для виконання транзакції.
У відповідь система отримує результат обробки платежу, який може відповідати
успішному завершенню, скасуванню або помилці. Результат платіжної операції
повертається до клієнтської частини та відображається користувачу у вигляді
відповідного повідомлення. Для забезпечення стабільної роботи застосунку
передбачено механізми логування подій та централізованої обробки помилок, які
дозволяють фіксувати технічні збої та результати взаємодії з платіжними
провайдерами.
Окрему роль у робочій області моделювання відіграє адміністратор
системи, який через спеціалізований інтерфейс має можливість керувати
доступністю методів оплати. Зміни, внесені адміністратором, впливають на набір
платіжних інструментів, доступних користувачам під час оформлення
замовлення.
3.2. Формування та аналіз вимог
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення
На етапі формування та аналізу вимог визначається загальне бачення
майбутньої системи, її призначення та межі функціонування. Формування вимог
полягає у встановленні того, якою повинна бути система, які функції вона має
виконувати, які обмеження та умови експлуатації необхідно врахувати, а також
яких результатів очікують зацікавлені сторони.
36
ЧДТУ 252489 014 ПЗ
Вимоги до програмної системи поділяються на первинні та детальні.
Первинні вимоги, або вимоги замовника, відображають загальні очікування
щодо функціональності системи, її призначення та основних можливостей з
погляду кінцевого користувача. Вони формулюються на більш високому рівні
абстракції та не залежать від конкретних технічних рішень.
Детальні вимоги, або вимоги розробника, уточнюють первинні вимоги та
визначають особливості реалізації системи з урахуванням технічних аспектів,
архітектури, обраних технологій та обмежень середовища виконання. Такі
вимоги використовуються безпосередньо під час проєктування та реалізації
програмного забезпечення.
Крім того, всі вимоги класифікуються на функціональні та
нефункціональні.
Функціональні вимоги описують, які саме функції повинна виконувати
система, які дії доступні користувачам та як система реагує на певні події.
Нефункціональні вимоги визначають якісні характеристики системи,
зокрема вимоги до продуктивності, безпеки, надійності, масштабованості,
зручності використання та сумісності з іншими програмними й апаратними
засобами.
Первинна вимога замовника
Необхідно створити прототип системи електронної комерції у вигляді
вебзастосунку. Система повинна мати в своєму складі модуль для динамічного
підключення платіжних сервісів та надавати можливість для безпечних
транзакцій.
Детальні вимоги розробника
1 Забезпечення можливості перегляду каталогу товарів та інформації про
окремі товари.
2 Надання засобів для формування та редагування кошика користувача.
3 Забезпечення вибору одного з доступних методів оплати під час
оформлення замовлення.
4 Реалізація інтеграції з декількома платіжними сервісами.
37
ЧДТУ 252489 014 ПЗ
5 Забезпечення можливості керування доступністю методів оплати
адміністратором системи.
6 Забезпечення швидкої та стабільної роботи системи при одночасній
взаємодії декількох користувачів.
7 Гарантування безпеки передачі платіжних та персональних даних.
Функціональні вимоги описують поведінку системи та перелік сервісів
(функцій), які вона повинна виконувати. Формування функціональних вимог
здійснюється на основі аналізу предметної області та основних сценаріїв
взаємодії користувачів із системою. Вимоги визначають можливі варіанти
поведінки системи залежно від вхідних даних і поточного стану зовнішнього
середовища.
У даній системі можна виокремити такі функціональні вимоги:
1 Отримання та обробка запитів від клієнтської частини
2 Автентифікація та авторизація користувачів
3 Формування та керування кошиком користувача
4 Створення та обробка замовлень
5 Ініціація платіжних операцій
6 Взаємодія з платіжними сервісами
7 Отримання та обробка результатів платіжних операцій
8 Відображення результатів користувачу
Нефункціональні вимоги визначають загальні характеристики системи,
умови її експлуатації, критерії якості, безпеки та ефективності, а також
обмеження, що накладаються на процес розробки й використання програмного
забезпечення.
У даній системі можна виокремити такі нефункціональні вимоги:
1 Модульність архітектури
2 Масштабованість
3 Незалежність від конкретних платіжних сервісів
4 Безпека обробки даних
5 Надійність і стабільність роботи
38
ЧДТУ 252489 014 ПЗ
6 Продуктивність
7 Зручність використання
3.2.2 Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів є графічним представленням функціональних вимог
до системи з точки зору користувача та інших учасників взаємодії. Вона
відображає основні сценарії використання системи та дозволяє визначити, які
функції повинні бути реалізовані для задоволення вимог замовника. Діаграма
прецедентів є початковим етапом моделювання динаміки системи та
використовується для фіксації вимог у формі, придатній для подальшого
проєктування і реалізації.
Діаграма прецедентів представлена на рисунку 3.2.
Основним актором системи є користувач, який взаємодіє з вебзастосунком
з метою оформлення замовлення. До базових прецедентів користувача належать
перегляд каталогу товарів і перегляд інформації про окремий товар, що
забезпечує ознайомлення з асортиментом продукції. У процесі взаємодії з
системою користувач здійснює формування кошика, яке включає додавання,
видалення товарів та зміну їх кількості перед оформленням покупки.
39
ЧДТУ 252489 014 ПЗ
Рисунок 3.2 ‒ Діаграма прецедентів
Ключовим сценарієм є оформлення замовлення. Сценарій здійснюється
після вибору користувачем методу оплати та супроводжується автоматичною
ініціацією платіжної операції.
Для доступу до персоналізованого функціоналу передбачено
автентифікацію користувача.
Адміністратор змодельований як спеціалізований тип користувача, що
успадковує всі базові сценарії взаємодії з системою та додатково має доступ до
керування доступністю методів оплати.
Платіжний провайдер представлений на діаграмі як зовнішній актор, який
бере участь у виконанні прецеденту ініціації платежу. Він забезпечує обробку
платіжної транзакції та повертає результат її виконання системі, що надалі
відображається користувачу.
3.2.3 Проєктування логічної структури програмного комплексу
Проєктування логічної структури програмного комплексу є важливим
етапом розробки програмного забезпечення та полягає у формуванні абстрактної
моделі системи, яка визначає склад основних компонентів, їх функціональне
призначення та логіку взаємодії між ними. Даний етап передує безпосередній
реалізації системи та дозволяє заздалегідь спланувати її архітектуру.
У межах розроблюваної системи електронної комерції проєктування
логічної структури спрямоване на розділення функціоналу між клієнтською та
серверною частинами, а також на визначення логіки взаємодії з зовнішніми
платіжними провайдерами. Такий підхід забезпечує модульність системи,
спрощує підтримку та розширення функціоналу.
Логічна структура системи передбачає виділення окремих компонентів,
відповідальних за:
‒ взаємодію з користувачем через вебінтерфейс;
‒ управління каталогом товарів;
‒ роботу з кошиком та обраними товарами;
40
ЧДТУ 252489 014 ПЗ
‒ автентифікацію користувачів;
‒ оформлення замовлення;
‒ динамічне підключення платіжних методів;
‒ взаємодію із зовнішніми платіжними сервісами;
‒ обробку результатів платежів та помилок.
Проєктування логічної структури також включає визначення інтерфейсів
взаємодії між компонентами, що дозволяє забезпечити уніфікований обмін
даними між клієнтською частиною, сервером та платіжними провайдерами. Це
особливо важливо для реалізації механізму динамічного підключення та
відключення платіжних методів без зміни клієнтської логіки.
Окрему увагу під час проєктування приділено масштабованості та
гнучкості системи, що дозволяє у майбутньому додавати нові платіжні сервіси,
розширювати функціонал адміністративної частини та адаптувати систему до
зростання кількості користувачів.
Правильно спроєктована логічна структура забезпечує підвищення
надійності, зручність супроводу та ефективність роботи системи в цілому.
3.2.3.1 Діаграма класів
У розроблюваній системі діаграма класів використовується для
моделювання основних сутностей, таких як користувач, товар, кошик, позиція
кошика, замовлення, методи оплати та платіжні провайдери. Також на діаграмі
відображаються взаємозв’язки між цими класами, що дозволяє формалізувати
структуру предметної області та визначити характер взаємодії між її основними
об’єктами. (рис. 3.3)
41
ЧДТУ 252489 014 ПЗ
Рисунок 3.3 ‒ Діаграма класів концептуального рівня
Для уточнення логіки функціонування системи та відображення можливих
станів основних сутностей було побудовано узагальнену діаграму класів, яка
доповнює модель предметної області перелічувальними типами. Узагальнена
діаграма містить ключові класи, що відповідають основним об’єктам предметної
області, зокрема користувача, товар, кошик, замовлення та платіж. На цьому
етапі внутрішня структура класів не деталізується, що дозволяє зосередитись на
логічних зв’язках між сутностями, їх ролі у бізнес-процесах системи та можливих
сценаріях їх використання.
Побудована діаграма класів також слугує основою для подальшого
проєктування програмної архітектури та реалізації окремих компонентів системи.
Вона забезпечує єдине розуміння структури предметної області, полегшує
внесення змін на етапі розробки та сприяє узгодженості між концептуальною
моделлю, логічною структурою даних і практичною реалізацією програмного
комплексу.
На рисунку 3.4 подано фінальну UML-діаграму класів, яка відображає
логічну структуру програмного комплексу з урахуванням реалізаційних аспектів.
42
ЧДТУ 252489 014 ПЗ
Діаграма містить основні класи системи, їх атрибути, перелічувальні типи та
взаємозв’язки між ними, що визначають структуру даних і основу для подальшої
програмної реалізації.
User ідентифікується у системі за допомогою унікального ідентифікатора та
облікових даних. Роль користувача визначається значенням переліку UserRole,
що дозволяє розмежувати звичайних користувачів і адміністраторів без виділення
окремого підкласу.
Користувач має кошик (Cart), призначений для зберігання товарів. Кошик
містить позиції кошика (CartItem), де кожна позиція поєднує конкретний товар і
його кількість.
У процесі оформлення покупки на основі вмісту кошика формується
замовлення (Order). Замовлення містить перелік позицій, зафіксованих на момент
оформлення, загальну суму та поточний стан, що визначається переліком
OrderStatus.
Оплата замовлення моделюється за допомогою класу Payment, який
відображає здійснення оплати замовлення користувачем та має власний список
станів, який визначається переліком PaymentStatus.
Для відокремлення способу здійснення оплати від конкретної платіжної
операції та підкреслення результатів досліджень в моделі використовується клас
PaymentMethod, який описує доступні у системі варіанти оплати та їх поточну
доступність.
Взаємодія з зовнішніми платіжними сервісами винесена за межі доменної
моделі.
43
ЧДТУ 252489 014 ПЗ
Рисунок 3.4 ‒ Реалізаційна діаграма класів
3.2.3.2 Діаграма пакетів
Діаграма пакетів використовується для логічного групування класів за
функціональними ознаками та відображення залежностей між основними
підсистемами. Вона дозволяє узагальнено представити структуру програмного
комплексу без деталізації внутрішньої реалізації класів. У межах діаграми
виділено п’ять основних пакетів, кожен з яких відповідає окремому аспекту
функціонування системи, як видно на рисунку 3.5.
Пакет Frontend представляє клієнтську частину системи, яка відповідає за
взаємодію з користувачем, обробку подій інтерфейсу та ініціацію запитів до
серверної частини.
44
ЧДТУ 252489 014 ПЗ
Пакет Backend відповідає за серверну логіку системи. У межах цього пакета
реалізується обробка запитів клієнта, виконання бізнес-операцій, а також
координація взаємодії з зовнішніми сервісами та базою даних.
Пакет ExternalServices об’єднує зовнішні сервіси, які не є частиною
системи, але використовуються нею для реалізації окремих функцій, таких як
платіжні операції або автентифікація користувачів. Ці сервіси розглядаються як
зовнішні залежності системи.
Рисунок 3.5 ‒ Діаграма пакетів
Пакет Database забезпечує зберігання та доступ до бази даних системи.
Доступ до пакета здійснюється через Backend.
3.2.4 Архітектурне проєктування
Архітектурне проєктування відіграє ключову роль у розробці систем
електронної комерції, оскільки воно визначає загальну структуру програмного
комплексу, організацію його складових компонентів та характер їхньої взаємодії.
Від правильно спроєктованої архітектури залежить ефективність роботи системи,
її надійність, безпека та здатність адаптуватися до змін вимог і зростання
навантаження.
У контексті даної роботи архітектурне проєктування визначає клієнт-
серверну організацію системи, розподіл функціональності між клієнтською та
45
ЧДТУ 252489 014 ПЗ
серверною частинами, а також механізми взаємодії із зовнішніми платіжними
сервісами.
3.2.4.1 Діаграма компонентів
На рисунку 3.6 подано діаграму компонентів, яка відображає архітектурну
структуру програмного комплексу та взаємодію його основних складових на
рівні програмних модулів. Діаграма компонентів дозволяє проілюструвати
розподіл функціональності між окремими компонентами системи та способи їх
взаємодії через визначені інтерфейси.
Рисунок 3.6 ‒ Діаграма компонентів
Центральним компонентом діаграми є компонент OrderManagement, який
координує процес оформлення замовлення. Для виконання своїх функцій він
використовує інтерфейс UserAccess, що надається компонентом UserManagement
і забезпечує доступ до даних користувача та інформації про його стан.
Також компонент OrderManagement взаємодіє з компонентом
CartManagement через інтерфейс CartAccess з метою отримання інформації про
вміст кошика та сформовані позиції замовлення. Для ініціації та обробки
платіжної операції компонент OrderManagement використовує інтерфейс
PaymentAccess, реалізований компонентом PaymentManagement. Компонент
PaymentManagement відповідає за формування платіжних параметрів, керування
статусами платежів та обробку результатів транзакцій.
Взаємодія з зовнішніми платіжними сервісами винесена в окремий
компонент PaymentProviders, який представляє сторонні платіжні системи.
46
ЧДТУ 252489 014 ПЗ
Доступ до них здійснюється через інтерфейс ProviderAPI, що дозволяє ізолювати
внутрішню логіку системи від конкретних реалізацій платіжних провайдерів.
Компонент CartManagement відповідає за управління кошиком користувача
та використовує інтерфейс CatalogueAccess, який надається компонентом
CatalogueManagement. Через цей інтерфейс здійснюється доступ до інформації
про товари, їхні характеристики та актуальні ціни.
Діаграма компонентів відображає логічну структуру системи та взаємодію
між її основними функціональними підсистемами без деталізації конкретних
технологій або реалізаційних аспектів.
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання представлена на рисунку 3.7.
Рисунок 3.7 ‒ Діаграма розгортання
Вузол Client Device, позначений як пристрій, представляє клієнтське
середовище виконання. На ньому розгортається артефакт Web Application
(Frontend SPA), який реалізує користувацький інтерфейс вебзастосунку та
забезпечує взаємодію користувача із системою через браузер.
Вузол Application Server представляє сервер застосунку, на якому
розгортається серверна частина системи. У його межах розміщено артефакт
Backend API, що відповідає за обробку запитів клієнта, виконання бізнес-логіки
47
ЧДТУ 252489 014 ПЗ
та координацію взаємодії з іншими компонентами системи. Також на цьому ж
вузлі розгортається артефакт SQLite Database, що відображає використання
локальної файлової бази даних для зберігання інформації, пов’язаної з роботою
застосунку.
Вузол Firebase Authentication, позначений як хмарний сервіс, представляє
зовнішній сервіс автентифікації. На ньому розгортається артефакт Auth Service,
який забезпечує ідентифікацію та автентифікацію користувачів системи.
Взаємодія серверної частини із цим вузлом здійснюється через відповідний API з
використанням захищеного протоколу HTTPS.
Вузол Payment Provider, позначений як зовнішній сервіс, представляє
сторонній платіжний сервіс. Артефакт Payment API, розгорнутий на цьому вузлі,
забезпечує виконання платіжних операцій та повернення результату їх обробки.
Доступ до платіжного сервісу здійснюється з боку сервера застосунку через
платіжний API з використанням захищеного каналу зв’язку.
3.2.5 Моделювання поведінки системи
3.2.5.1 Діаграма діяльності
На рис. 3.8. показано діаграму діяльності користувача. На початковому
етапі користувач переходить на сторінку інтернет-магазину, після чого виконує
перегляд каталогу товарів. Даний етап є центральним у сценарії та може
повторюватися багаторазово, що реалізовано у вигляді циклу.
Під час перегляду каталогу користувач має можливість обрати конкретний
товар. У разі вибору товару відбувається перехід до картки товару, де користувач
може прийняти рішення щодо додавання його до кошика. Якщо товар не
додається до кошика, сценарій повертається до перегляду каталогу. Після
формування кошика користувач може ініціювати перехід до етапу керування
кошиком. На цьому етапі передбачена можливість редагування вмісту кошика,
зокрема зміни кількості товарів або видалення позицій. Дані дії є
необов’язковими та виконуються за рішенням користувача.
48
ЧДТУ 252489 014 ПЗ
Рисунок 3.8 ‒ Діаграма діяльності
Далі користувач приймає рішення щодо оформлення замовлення. У разі
підтвердження відбувається вибір методу оплати, формування замовлення,
виконання платіжної операції та відображення результату оплати. Якщо
49
ЧДТУ 252489 014 ПЗ
користувач відмовляється від оформлення замовлення, сценарій повертається до
перегляду каталогу товарів.
Після завершення платіжної операції користувач може продовжити
перегляд каталогу або завершити взаємодію із системою.
3.2.5.2 Діаграма послідовності
Діаграма послідовності (рис. 3.9) відображає основний сценарій виконання
оплати замовлення.
Рисунок 3.9 ‒ Діаграма послідовності
Ініціатором процесу є користувач (User), який на сторінці кошика (Cart
Page) виконує дію оформлення замовлення шляхом виклику операції placeOrder().
Після цього запит передається до серверного компонента Order Controller, який
відповідає за керування процесом оформлення замовлення.
На другому етапі Order Controller виконує перевірку коректності вмісту
кошика за допомогою операції validateCart(). У разі успішної валідації
створюється нове замовлення зі статусом очікування оплати шляхом виклику
операції createPendingOrder() на об’єкті Order.
Після створення замовлення користувач перенаправляється на сторінку
платіжного сервісу. Для цього Order Controller ініціює операцію
50
ЧДТУ 252489 014 ПЗ
redirectToPaymentPage(), що передає керування зовнішньому компоненту Payment
Provider.
Платіжний сервіс виконує платіжну операцію та після її завершення
повертає результат у систему через повідомлення paymentResult(). Отримавши
відповідь від платіжного провайдера, Order Controller оновлює стан замовлення
шляхом виклику операції updatePaymentStatus() на об’єкті Order.
На завершальному етапі система формує повідомлення про результат
платіжної операції та передає його до Payment Result Page за допомогою операції
displayPaymentMessage(), де користувачу відображається інформація про успішне
або неуспішне завершення платежу.
3.2.5.3 Діаграма комунікації
Подана діаграма (рис. 3.10) акцентує увагу не на часовій осі виконання
операцій, а на структурних зв’язках між об’єктами системи, що є її ключовою
відмінністю від діаграми послідовності.
Порядок виконання дій у даному випадку визначається нумерацією
повідомлень, а не їх вертикальним розташуванням. Унікальною особливістю цієї
діаграми є виділення контролера замовлення як центрального вузла взаємодії.
Саме через нього проходять усі ключові повідомлення, пов’язані з ініціацією
платежу, інтеграцією із зовнішнім платіжним провайдером та оновленням стану
замовлення. Такий підхід наочно демонструє централізовану модель керування
бізнес-логікою.
Діаграма також чітко підкреслює межі відповідальності системи
електронної комерції. Зовнішній платіжний провайдер представлений як окремий
актор, з яким система взаємодіє лише через обмежений набір повідомлень, не
беручи участі у введенні або обробці платіжних даних.
51
ЧДТУ 252489 014 ПЗ
Рисунок 3.10 ‒ Діаграма комунікації
Окремою особливістю діаграми є наявність доменного об’єкта “Order”,
який не ініціює взаємодію самостійно, але змінює свій стан у відповідь на події,
що надходять від контролера. Це відображає пасивну роль сутностей доменної
моделі та відокремлення їх від керуючої логіки.
Таким чином, діаграма комунікації доповнює діаграму послідовності,
надаючи альтернативне представлення того самого сценарію, яке дозволяє
проаналізувати архітектуру взаємодії компонентів, їх зв’язки та відповідальність
без прив’язки до часової шкали виконання операцій.
3.2.5.4 Діаграма скінченного автомату
Для діаграми опишемо життєвий цикл замовлення та кошику.
Діаграма скінченного автомату замовлення представлена на рисунку 3.11.
52
ЧДТУ 252489 014 ПЗ
Діаграма скінченного автомата моделює життєвий цикл замовлення та
відображає можливі стани, в яких воно може перебувати.
Початковим станом автомата є створення замовлення (Created), що
відповідає моменту фіксації наміру користувача здійснити покупку. Після цього
замовлення переходить у стан PaymentPending, який відображає очікування
оплати.
У разі успішної оплати замовлення переходить у стан Paid, а при скасуванні
у стан Cancelled.
Рисунок 3.11 ‒ Діаграма скінченного автомату замовлення
Діаграма скінченного автомату корзини представлена на рисунку 3.12.
Дана діаграма моделює життєвий цикл користувацької корзини та
відображає поведінкові сценарії формування замовлення.
Початковим станом корзини є стан Empty, у якому корзина не містить
товарів. При додаванні хоча б одного товару корзина переходить у стан Active,
що відповідає процесу формування замовлення користувачем. У разі видалення
всіх товарів корзина знову повертається у стан Empty.
53
ЧДТУ 252489 014 ПЗ
Рисунок 3.12 ‒ Діаграма скінченного автомату корзини
Після ініціації оформлення замовлення корзина переходить у стан
CheckedOut, що означає завершення її життєвого циклу та створення замовлення.
Якщо користувач не завершує взаємодію з корзиною протягом певного часу, вона
переходить у стан Abandoned, що відображає сценарій покинутої корзини.
54
ЧДТУ 252489 014 ПЗ
Висновки до розділу
У процесі аналізу предметної області та проєктування вебзастосунку
електронної комерції було встановлено, що попереднє формалізоване
моделювання структури та поведінки системи є ключовим етапом для побудови
логічно узгодженої й масштабованої архітектури.
У результаті аналізу варіантів використання було встановлено, що система
не зобов’язана здійснювати безпосередню обробку платіжних даних користувача,
а виконуватиме лише ініціацію платіжної операції та обробку її результату.
Відповідно, поведінкові діаграми були зосереджені на сценаріях створення
замовлення, перенаправлення до платіжного провайдера та оновлення стану
замовлення після завершення платежу.
Побудова діаграм послідовності та комунікації дала змогу формалізувати
основний сценарій оплати замовлення та показати характер взаємодії між
користувачем, клієнтською частиною застосунку, серверною логікою та
зовнішніми платіжними провайдерами. Окреме моделювання життєвого циклу
замовлення і платіжної операції за допомогою діаграм скінченного автомата
забезпечило чітке розуміння бізнес-станів замовлення.
Архітектурне проєктування з використанням діаграм компонентів і
розгортання дозволило сформувати узагальнену фізичну модель вебзастосунку, у
якій серверна, клієнтська частини і зовнішні сервіси взаємодіють через
стандартизовані інтерфейси. Такий підхід забезпечує ізоляцію платіжної логіки
та логіки автентифікації від основного застосунку.
Таким чином, результати проєктування підтверджують, що ретельний
аналіз предметної області та комплексне UML-моделювання є ефективним
інструментом для побудови зрозумілої, розширюваної та безпечної архітектури
вебзастосунку електронної комерції. Спроектовані архітектурні рішення
створюють надійну основу для подальшої реалізації системи.
55
ЧДТУ 252489 014 ПЗ
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
4.1.1 Обґрунтування вибору засобів реалізації
Вибір програмних та апаратних засобів для реалізації розроблюваного
програмного комплексу здійснювався на основі поставлених задач, особливостей
предметної області, а також розробленої архітектури та алгоритмів
функціонування системи.
Як мову програмування для клієнтської частини обрано JavaScript у
поєднанні з бібліотекою React. Даний вибір зумовлений широкою підтримкою
компонентного підходу до побудови інтерфейсу користувача, можливістю
динамічного оновлення стану застосунку без перезавантаження сторінки, а також
високою популярністю та активною спільнотою розробників. Це дозволяє
скоротити час розробки інтерфейсу та спростити його подальший супровід.
Для реалізації серверної частини застосунку також використано JavaScript
із застосуванням платформи Node.js, що забезпечує єдине середовище розробки
для клієнтської та серверної частин системи. Такий підхід зменшує складність
проєкту, спрощує обмін даними між компонентами та позитивно впливає на
швидкість розробки. Серверна частина відповідає за обробку запитів клієнта,
керування замовленнями та взаємодію з зовнішніми сервісами.
Для забезпечення автентифікації користувачів обрано хмарний сервіс
Firebase Authentication, який надає готові механізми керування обліковими
записами та дозволяє зменшити обсяг власної серверної логіки. Зберігання
експериментальних і службових даних реалізовано за допомогою СКБД SQLite,
що є легковаговим рішенням та є зручним для використання в
експериментальних дослідженнях. Розгортання програмного комплексу
здійснюється з використанням хмарної платформи Render, що дозволяє
56
ЧДТУ 252489 014 ПЗ
автоматизувати процес деплою, забезпечити доступність застосунку та спростити
масштабування.
Таким чином, обрані засоби реалізації забезпечують оптимальний баланс
між функціональними можливостями, вартістю впровадження та часовими
витратами на розробку, а також повністю відповідають вимогам до
розроблюваного програмного комплексу.
4.1.2 Опис структурної (функціональної) схеми
На рисунку 4.1 представлено структурну схему системи електронної
комерції.
Рисунок 4.1 ‒ Структурна схема
57
ЧДТУ 252489 014 ПЗ
Підсистема керування оплатою відповідає за виконання платіжних операцій
та взаємодію з іншими підсистемами. Вона використовує підсистему керування
методами оплати для отримання доступних платіжних методів. Для відображення
результатів роботи системи передбачено підсистему виведення даних.
Обробка помилкових та виняткових ситуацій здійснюється за допомогою
підсистеми обробки помилок, яка використовується як підсистемою керування
оплатою, так і підсистемою автентифікації.
Структурна схема (рис. 4.2) відображає логічний розподіл відповідальності
між основними підсистемами та їх підпорядкованість центральній системі.
Діаграма використовується для загального уявлення про архітектуру системи і є
основою для подальшої деталізації структури на рівні компонентів і процесів.
Рисунок 4.2 ‒ Функціональна схема
58
ЧДТУ 252489 014 ПЗ
Система електронної комерції відповідає за координацію основних бізнес-
процесів, серед яких виділено підсистему автентифікації, для роботи якої
необхідно введення логіну та паролю користувачем. Після цього підсистема
автентифікації виконує перевірку облікових даних із використанням бази даних
авторизації (Firebase).
Платіжний функціонал реалізовано у вигляді послідовного ланцюга
спеціалізованих підсистем. На першому етапі підсистема керування методами
оплати визначає перелік доступних платіжних інструментів відповідно до
конфігурації системи. Після вибору методу оплати керування процесом
передається до підсистеми керування оплатою, яка в свою чергу отримує
платіжні дані введені користувачем і відповідає за контроль стану платежу.
У разі виникнення помилок під час виконання платіжних транзакцій або
автентифікації керування передається до підсистеми обробки помилок, що
забезпечує централізовану обробку виняткових ситуацій. Після оброблення
помилки керування переходить до підсистеми виведення даних.
Підсистема виведення даних забезпечує відображення статусу оплати,
повідомлень про помилки, а також збереження експериментальних даних у
відповідній базі даних, що використовується для тестування, аналізу та валідації
роботи системи.
Таким чином, структурна схема демонструє логічно впорядковану та
модульну організацію системи електронної комерції, у якій кожна підсистема
виконує чітко визначені функції.
4.1.3 Опис логічної схеми системи
Сценарій, наведений на рис. 4.3, відображає логічний алгоритм взаємодії
між основними підсистемами під час обробки платіжної операції.
На початковому етапі система звертається до підсистеми керування
методами оплати з метою отримання переліку доступних платіжних інструментів.
Після вибору методу оплати формуються необхідні платіжні параметри, а
керування передається до підсистеми керування оплатою, яка виконує ініціацію
59
ЧДТУ 252489 014 ПЗ
та обробку платіжної операції. Подальший перебіг процесу залежить від
результату виконання транзакції.
Рисунок 4.3 ‒ Системний сценарій платіжної операції
У разі успішного завершення платежу формується результат платіжної
операції, який передається до підсистеми виведення даних для відображення
статусу оплати користувачеві. Якщо під час виконання платіжної операції
виникає помилка, відповідна інформація передається до підсистеми обробки
помилок, де здійснюється її аналіз та формується повідомлення, яке надалі
відображається користувачеві через підсистему виведення даних.
60
ЧДТУ 252489 014 ПЗ
Сценарій на рис. 4.4 відображає внутрішній логічний алгоритм взаємодії
між основними підсистемами під час автентифікації.
У разі вибору сценарію реєстрації система передає реєстраційні дані до
підсистеми автентифікації, де здійснюється перевірка їх коректності. Якщо дані є
коректними, створюється новий обліковий запис у базі даних, після чого система
переходить до авторизованого режиму роботи. У випадку некоректних
реєстраційних даних формується інформація про помилку, яка передається до
підсистеми обробки помилок та відображається користувачу через підсистему
виведення даних.
Рисунок 4.4 ‒ Системний сценарій автентифікації
У разі вибору сценарію логіну система передає облікові дані користувача
до підсистеми автентифікації та виконує запит до бази даних авторизації. Якщо
61
ЧДТУ 252489 014 ПЗ
автентифікація проходить успішно, система переходить до авторизованого
режиму роботи. У разі помилки автентифікації формується відповідна
інформація, яка обробляється підсистемою обробки помилок та передається до
підсистеми виведення даних.
4.1.4 Розробка бази даних
Концептуальна модель даних (рис. 4.5) призначена для узагальненого опису
предметної області системи електронної комерції з точки зору бізнесу та
замовника. На даному рівні моделювання визначено основні сутності предметної
області та взаємозв’язки між ними без деталізації внутрішньої структури даних.
Рисунок 4.5 ‒ Концептуальна модель даних
Центральною подієвою сутністю концептуальної моделі є Замовлення
(Order), яке відображає факт здійснення покупки. Замовлення пов’язане з
користувачем(User), що його оформлює, товарами(Product), які входять до складу
замовлення, а також з платіжними операціями(Payment). Окремо виділено
сутність Спосіб оплати(PaymentMethod), яка характеризує обраний платіжний
інструмент і використовується при здійсненні платежів.
62
ЧДТУ 252489 014 ПЗ
Логічна модель даних (рис. 4.6) є деталізацією концептуальної моделі та
описує логічну структуру бази даних. На цьому рівні визначено склад сутностей,
їх атрибути, а також первинні та зовнішні ключі, що реалізують зв’язки між
таблицями.
Рисунок 4.6 ‒ Логічна модель даних
У логічній моделі введено сутність Позиція замовлення (OrderItem), яка
використовується для розв’язання зв’язку типу «багато-до-багатьох» між
замовленнями та товарами. Дана сутність дозволяє фіксувати кількість товарів у
замовленні та ціну на момент покупки. Таким чином забезпечується коректне
відображення структури замовлення та збереження історичних даних.
Сутність Платіж (Payment) використовується для опису платіжних
операцій, пов’язаних із замовленням. Логічна модель підтримує можливість
виконання декількох платежів для одного замовлення, що дозволяє моделювати
63
ЧДТУ 252489 014 ПЗ
повторні спроби оплати або різні сценарії завершення платіжної операції.
Сутність Спосіб оплати (PaymentMethod) реалізована як довідникова та
використовується багатьма платежами.
Фізична модель даних (рис. 4.7) відображає конкретну реалізацію логічної
моделі у вигляді таблиць бази даних із визначеними типами даних, первинними
та зовнішніми ключами. Дана модель призначена для безпосереднього
використання при створенні бази даних у СКБД.
Структура фізичної моделі відповідає вимогам третьої нормальної форми,
що дозволяє мінімізувати дублювання інформації та спростити подальше
масштабування системи.
Фізична модель даних побудована у відповідності до логічної моделі та
зберігає ієрархічну структуру зв’язків, що забезпечує однозначну інтерпретацію
даних і можливість прямої реалізації.
Рисунок 4.7 ‒ Фізична модель даних
4.1.5 Розробка інтерфейсу користувача
64
ЧДТУ 252489 014 ПЗ
Процес проєктування інтерфейсу користувача в даній роботі ґрунтується на
дотриманні загальновизнаних принципів зручності використання (usability),
запропонованих Якобом Нільсеном. Запропоновані ним евристики є
універсальним набором рекомендацій, які дозволяють створювати інтерфейси,
орієнтовані на потреби користувачів, та забезпечувати високу ефективність
взаємодії з інформаційною системою.
У межах розроблюваної системи електронної комерції інтерфейс
користувача спроєктовано таким чином, щоб забезпечити інтуїтивну навігацію,
швидкий доступ до основного функціоналу та мінімізувати кількість дій,
необхідних для досягнення цільового результату. Особлива увага приділяється
тому, щоб інтерфейс залишався зрозумілим як для нових користувачів, так і для
користувачів із досвідом роботи з подібними системами.
Реалізація евристик Якоба Нільсена в інтерфейсі системи:
1 Інтерфейс забезпечує постійний зворотний зв’язок із користувачем
шляхом відображення поточного стану системи. При виконанні ключових
операцій, таких як додання товару до кошику, оформлення замовлення, ініціація
платіжної операції або при виникненні критичних помилок, користувач отримує
чітку інформацію про результат дії або поточний етап виконання процесу.
2 Усі елементи інтерфейсу використовують зрозумілу термінологію, що
відповідає предметній області електронної комерції. Назви кнопок, повідомлень
та розділів відображають реальні дії користувача.
3 Інтерфейс передбачає можливість скасування або зміни дій користувача
без негативних наслідків. Користувач має змогу редагувати вміст кошика,
змінювати обраний метод оплати або повернутися до попереднього етапу без
втрати введених даних.
4 Всі елементи інтерфейсу виконані в єдиному стилі, а їх поведінка є
передбачуваною на всіх сторінках системи. Однакові елементи керування мають
однакове призначення незалежно від контексту використання, що відповідає
загальноприйнятим веб-стандартам.
65
ЧДТУ 252489 014 ПЗ
5 Проєктування інтерфейсу спрямоване на мінімізацію можливості
виникнення помилок. Перед виконанням критичних дій система здійснює
перевірку введених даних, а потенційно небезпечні операції супроводжуються
відповідними підказками або обмеженнями.
6 Інтерфейс мінімізує необхідність запам’ятовування інформації шляхом
автоматичного заповнення форм та візуального виділення активних елементів.
7 Інтерфейс адаптований для швидкої взаємодії з боку досвідчених
користувачів, водночас залишаючись доступним для новачків. Основні дії
виконуються за мінімальну кількість кроків, що підвищує загальну ефективність
використання системи.
8 Інтерфейс не перевантажений другорядною інформацією, а візуальні
елементи використовуються лише тоді, коли вони безпосередньо підтримують
виконання користувацьких завдань. Такий підхід підвищує читабельність та
зручність взаємодії.
9 У разі виникнення помилок інтерфейс надає зрозумілі повідомлення, які
пояснюють причину проблеми та пропонують можливі шляхи її усунення, без
використання технічної термінології.
10 Інтерфейс орієнтований на інтуїтивне використання, тому відсутність
окремої документації компенсується простотою інтерфейсу, логічною
структурою навігації та контекстними повідомленнями, які супроводжують
виконання ключових операцій.
4.1.6 Опис розробки програмних компонентів
Розроблювана система побудована за компонентним принципом, що
забезпечує розділення відповідальності, підвищує масштабованість рішення та
спрощує супровід і розширення функціоналу. Кожен компонент виконує чітко
визначені функції та взаємодіє з іншими компонентами системи через
стандартизовані інтерфейси.
Опис основних компонентів
Компонент управління станом застосунку
66
ЧДТУ 252489 014 ПЗ
Компонент управління станом забезпечує централізоване зберігання та
оновлення стану застосунку. (рис. 4.8) У ньому зберігається інформація про вміст
кошика та методи для його редагування, обрані товари, а також інші глобальні
стани інтерфейсу. Для реалізації компоненту використано Redux Toolkit
Централізоване управління станом забезпечує узгодженість даних між різними
компонентами інтерфейсу.
Рисунок 4.8 ‒ Фрагмент коду компоненту управління станом застосунку
Компонент автентифікації
67
ЧДТУ 252489 014 ПЗ
Даний компонент відповідає за реєстрацію та вхід користувачів у систему,
управління сесіями. Він реалізує перевірку прав доступу та обмежує доступ до
функціоналу, призначеного лише для автентифікованих користувачів. (рис. 4.9)
Компонент побудовано з використанням Firebase Authentication, що дозволяє
реалізувати надійний механізм автентифікації без зберігання облікових даних на
власному сервері.
Рисунок 4.9 ‒ Фрагмент коду компоненту автентифікації
Компонент обробки платіжних операцій
Компонент платіжних систем відповідає за повний цикл обробки платіжних
операцій у межах інформаційної системи та забезпечує інтеграцію з зовнішніми
платіжними сервісами (рис. 4.10). Його основним призначенням є безпечне та
надійне виконання фінансових транзакцій, а також узгодження внутрішнього
стану замовлень із результатами платежів.
68
ЧДТУ 252489 014 ПЗ
Система підтримує кілька методів оплати, зокрема Stripe, PayPal та
WayForPay, що дозволяє підвищити гнучкість платформи та надати користувачам
можливість обирати зручний для них спосіб оплати. Кожен платіжний метод
інкапсулює специфіку взаємодії з відповідним зовнішнім API, включно з
форматами запитів, механізмами автентифікації та сценаріями підтвердження
платежу.
Рисунок 4.10 ‒ Фрагмент коду компоненту обробки платіжних операцій
Компонент панелі сортування
Компонент панелі сортування (рис. 4.11) призначений для керування
відображенням товарів у каталозі шляхом вибору параметрів упорядкування та
фільтрації. Його основною функцією є забезпечення зручного доступу
69
ЧДТУ 252489 014 ПЗ
користувача до інструментів впорядкування товарів без необхідності
перезавантаження сторінки.
Панель сортування інтегрується з каталогом товарів і впливає на порядок їх
відображення відповідно до вибраних критеріїв, таких як ціна, назва або інші
характеристики. Компонент реалізовано таким чином, щоб зміна параметрів
сортування миттєво відображалась у списку товарів, зберігаючи загальну
структуру сторінки та забезпечуючи безперервність користувацького досвіду.
Крім цього панель доступна при прокрутці сторінки для кращого UX.
Рисунок 4.11 ‒ Фрагмент коду компоненту панелі сортування
70
ЧДТУ 252489 014 ПЗ
Компонент каталогу товарів
Компонент каталогу зображений на рис. 4.12 забезпечує відображення
списку товарів.
Рисунок 4.12 ‒ Фрагмент коду компоненту каталогу товарів
71
ЧДТУ 252489 014 ПЗ
Завантаження даних про товари здійснюється з використанням
FakeStoreAPI, який надає тестові дані для імітації роботи реального сервісу
каталогу товарів. Такий підхід дозволяє зосередитися на реалізації клієнтської
логіки, навігації та інтеграції платіжних механізмів без необхідності розгортання
власної бази даних для керування каталогом товарів.
Компонент картки товару
Компонент картки товару зображений на рис. 4.13 використовується для
відображення основної інформації про окрему товарну позицію у каталозі.
Картка товару містить ключові дані, зокрема назву товару, зображення, ціну та
елементи керування взаємодією користувача з товаром.
Рисунок 4.13 ‒ Фрагмент коду компоненту картки товару
72
ЧДТУ 252489 014 ПЗ
Компонент підтримує виконання основних користувацьких дій, таких як
перехід до сторінки з детальною інформацією, додавання товару до кошика або
до списку обраного.
Компонент обробки помилок
Компонент обробки помилок (рис. 4.14) реалізує централізований механізм
перехоплення, форматування та відображення помилок.
Рисунок 4.14 ‒ Фрагмент коду компоненту обробки помилок
73
ЧДТУ 252489 014 ПЗ
На клієнтській стороні він відповідає за інформування користувача про
помилки та логування помилкових ситуацій. На серверній стороні
використовується middleware, що забезпечує єдиний формат API-помилок.
Централізація обробки помилок підвищує надійність системи та спрощує
діагностику проблем.
Компонент панелі навігації
Компонент панелі навігації (рис. 4.15) виконує функцію основного засобу
переміщення користувача між ключовими розділами вебзастосунку.
Рисунок 4.15 ‒ Фрагмент коду компоненту панелі навігації
74
ЧДТУ 252489 014 ПЗ
Панель навігації реалізована як постійний елемент інтерфейсу, що
відображається незалежно від поточного розділу системи. Компонент також
може відображати динамічну інформацію, наприклад кількість товарів у кошику,
що підвищує інформативність інтерфейсу.
Таким чином, програмна система складається з взаємопов’язаних модулів,
кожен з яких реалізує окрему частину функціональності.
4.2 Тестування системи
Об’єктом тестування є вебзастосунок електронної комерції, що складається
з клієнтської і серверної частини та інтеграцій із зовнішніми сервісами.
Основною метою тестування є перевірка коректності виконання основних
сценаріїв роботи системи та перевірка обробки помилкових і граничних ситуацій.
4.2.1 Модульне тестування
Модульне тестування проводилося на ранніх етапах розробки та було
спрямоване на перевірку коректності роботи окремих програмних модулів у
відокремленому середовищі. Основною метою цього виду тестування було
виявлення логічних помилок у бізнес-логіці системи до моменту інтеграції
компонентів між собою та підключення зовнішніх сервісів.
Об’єктами модульного тестування стали серверні та клієнтські модулі, які
реалізують ключові функції вебзастосунку, зокрема створення та обробку
замовлень, формування платіжних запитів, перевірку вхідних даних користувача,
а також управління кошиком. Для забезпечення ізольованості тестування
зовнішні залежності, такі як база даних і платіжні провайдери, були замінені
імітованими об’єктами (моками).
Під час тестування розглядалися як позитивні, так і негативні сценарії
виконання, включаючи коректні вхідні дані, граничні значення та помилкові
ситуації. Результати модульного тестування наведено у таблиці 4.1.
Таблиця 4.1
Результати модульного тестування
75
ЧДТУ 252489 014 ПЗ
Тестовий Вхідні Очікуваний Фактичний
№ Компонент
сценарій дані результат результат
Замовлення
Створення Дані створено зі
1 OrderService Відповідає
замовлення кошика статусом
CREATED
Створення
замовлення з Порожній Помилка
2 OrderService Відповідає
порожнім список валідації
кошиком
Формування Коректний
Сума,
3 PaymentService платіжного платіжний Відповідає
валюта
запиту payload
Оновлення
Обробка Статус
4 PaymentService статусу Відповідає
статусу PAID PAID
замовлення
Обробка
Статус Повернення
5 PaymentService помилки Відповідає
FAILED помилки
платежу
Product
Додавання
6 CartService ID, Товар додано Відповідає
товару
quantity
Видалення
7 CartService Product ID Товар видалено Відповідає
товару
4.2.2 Інтеграційне тестування
Після завершення модульного тестування було проведено інтеграційне
тестування, метою якого є перевірка коректності взаємодії між окремими
програмними модулями системи. На цьому етапі основна увага приділялася
76
ЧДТУ 252489 014 ПЗ
перевірці обміну даними між клієнтською та серверною частинами
вебзастосунку, а також коректності інтеграції з зовнішніми платіжними
сервісами.
Інтеграційне тестування виконувалося з використанням реальних з’єднань
між компонентами системи. Платіжні провайдери підключалися у тестовому
(sandbox) режимі, що дозволило відтворити повний сценарій оформлення
замовлення без здійснення реальних фінансових операцій. Перевірялися сценарії
створення замовлення, ініціації платежу, отримання результату оплати та
оновлення статусу замовлення.
Окрема увага приділялася обробці помилкових ситуацій, таких як
некоректні відповіді API платіжних сервісів, помилки з’єднання або повторні
запити. Результати інтеграційного тестування наведено у таблиці 4.2.
Таблиця 4.2
Результати інтеграційного тестування
Очікуваний Фактичний
№ Компоненти Сценарій
результат результат
Надсилання запиту на HTTP 200,
1 UI – Order API Відповідає
створення замовлення orderId
Отримання складу
2 Order – Cart Коректні позиції Відповідає
кошика
Order – Створення
3 Ініціація платежу Відповідає
Payment платежу
Payment – Отримання результату
4 Статус PAID Відповідає
Provider оплати
Повернення статусу
5 Backend – UI Статус оновлено Відповідає
замовлення
Payment – Обробка
6 Помилка з’єднання Відповідає
Provider помилки
4.2.3 Системне тестування
77
ЧДТУ 252489 014 ПЗ
Системне тестування проводилося з метою перевірки роботи вебзастосунку
в цілому як єдиного програмного продукту. На цьому етапі система розглядалася
без поділу на окремі внутрішні модулі, а тестування виконувалося в середовищі,
максимально наближеному до реальних умов експлуатації.
У межах системного тестування перевірялися основні користувацькі
сценарії, зокрема перегляд каталогу товарів, формування кошика, оформлення
замовлення, вибір способу оплати та перегляд результату платіжної операції.
Також оцінювалася коректність навігації між сторінками, збереження стану
користувача та відображення актуальної інформації після виконання дій.
Крім функціональних аспектів, під час системного тестування оцінювалися
нефункціональні характеристики системи, такі як стабільність роботи при
багаторазових діях користувача, коректність обробки помилок та відповідність
інтерфейсу вимогам зручності використання. Результати системного тестування
наведено у таблиці 4.3.
Таблиця 4.3
Результати системного тестування
Очікуваний Фактичний
№ Сценарій Опис
результат результат
Перегляд Каталог
1 Відображення товарів Відповідає
каталогу відображено
Додавання/видалення Дані
2 Кошик Відповідає
товарів оновлюються
Оформлення
3 Повний цикл покупки Оплата успішна Відповідає
замовлення
Помилка Повідомлення
4 Відхилений платіж Відповідає
оплати про помилку
5 Авторизація Вхід користувача Доступ надано Відповідає
Переходи між
6 Навігація Без помилок Відповідає
сторінками
4.2.4 Приймальне тестування
78
ЧДТУ 252489 014 ПЗ
Приймальне тестування проводилося на завершальному етапі перевірки
якості програмного продукту з метою оцінювання його готовності до введення в
експлуатацію. На цьому етапі система оцінювалася з точки зору кінцевого
користувача та відповідності вимогам технічного завдання.
У межах кваліфікаційної роботи приймальне тестування виконувалося
автором роботи. Основними критеріями прийнятності були можливість
завершення повного користувацького сценарію оформлення замовлення,
коректне відображення результату платіжної операції, відсутність критичних
збоїв та відповідність реалізованого функціоналу поставленим вимогам.
Результати приймального тестування наведено у таблиці 4.4 та свідчать про
досягнення мінімально допустимого рівня якості програмного продукту.
Таблиця 4.4
Результати приймального тестування
№ Критерій Опис Результат
1 Повний сценарій Замовлення з оплатою Виконано
2 Відображення результату Статус платежу Виконано
3 Надійність Відсутність критичних збоїв Виконано
4 Відповідність ТЗ Реалізація вимог Виконано
4.3 Приклади впровадженого програмного комплексу
У даному підрозділі наведено приклади практичного використання
розробленого веб-застосунку. Описані кроки відображають типовий сценарій
взаємодії користувача з системою.
1 Відкриття головної сторінки. Після переходу за адресою веб-застосунку
користувач потрапляє на головну сторінку (рис. 4.16), яка містить навігаційне
меню, перелік доступних товарів та основні елементи керування.
79
ЧДТУ 252489 014 ПЗ
Рисунок 4.16 — Головна сторінка додатку
Інтерфейс головної сторінки забезпечує швидкий доступ до каталогу,
авторизації, обраного та кошика.
80
ЧДТУ 252489 014 ПЗ
2 Перегляд каталогу товарів. Користувач переглядає каталог товарів,
представлений у вигляді списку карток із короткою інформацією про кожен
товар. Для зручності передбачено можливість перегляду детальної інформації
(рис. 4.17), можливість швидкого додавання до корзини та обраного, а також
навігаційне меню в якому можна відсортувати товари за необхідними
параметрами.
Рисунок 4.17 — Сторінка окремого товару
81
ЧДТУ 252489 014 ПЗ
3 Додавання товару до кошика. Після вибору потрібного товару
користувач додає його до кошика за допомогою відповідної кнопки (синя
піктограма корзини). Обраний товар додається до кошика і замість піктограми
корзини з’являється синя піктограма типу чекбокс, а в правому верхньому куті
головної сторінки з’являється зелена піктограма корзини, яка відображає
кількість позицій в ній (рис. 4.18)
82
ЧДТУ 252489 014 ПЗ
Рисунок 4.18 ‒ Сторінка окремого товару уже доданого до корзини
4 Перегляд кошика. Після переходу до кошика шляхом натискання на
зелену кнопку корзини або синього чекбокса користувач бачить перелік доданих
товарів, їх кількість та загальну вартість замовлення, разом з кнопками оплати,
які адміністратор вирішив додати. (рис. 4.19) Інтерфейс кошика дозволяє
змінювати кількість товарів, видаляти позиції продовжити оформлення
замовлення або закрити вікно.
83
ЧДТУ 252489 014 ПЗ
Рисунок 4.19 ‒ Вікно корзини з доданими товарами
5 Перехід до оплати. Після натискання на будь-яку кнопку “Pay with…”
користувач перенаправляється на сторінку оплати або бачить вікно віджету у
випадку WayForPay, де може оплатити замовлення зручним для нього методом
(рис. 4.20). При цьому вартість замовлення збігається з проміжною сумою
вказаною в кошику.
Рисунок 4.20 ‒ Вікно оплати платіжного провайдера Stripe
6 Підтвердження успішної операції. У разі успішного завершення оплати
користувач автоматично перенаправляється на сторінку підтвердження. На цій
сторінці відображається повідомлення про успішне оформлення замовлення та
кнопка для повернення на головну сторінку. (рис. 4.21)
84
ЧДТУ 252489 014 ПЗ
Рисунок 4.21 ‒ Сторінка успішної оплати
Далі буде наведено типовий сценарій взаємодії адміністратора з системою:
1 Відкриття головної сторінки. Як і у випадку зі звичайним користувач ем
адміністратор потрапляє на головну сторінку, на якій у верхньому правому кутку
натискає кнопку “Login” для авторизації.
2 Авторизація. Після переходу на сторінку авторизації адміністратор
вводить свої облікові дані для доступу до особистого кабінету. (рис. 4.22)
Рисунок 4.22 ‒ Сторінка автентифікації
3 Доступ до платіжних методів. Після успішної авторизації
адміністратору стає доступний функціонал особистого кабінету, а саме керування
методами оплати. (рис. 4.23)
85
ЧДТУ 252489 014 ПЗ
Рисунок 4.23 ‒ Особистий кабінет адміністратора
4 Зміна платіжних методів. Для зміни активних платіжних методів
адміністратор може натиснути перемикач “Enable/Disable” навпроти кожного з
методів. Після цього платіжні кнопки автоматично відображаються зникають у
корзині. (рис. 4.24)
Рисунок 4.24 ‒ Вікно корзини після зміни доступних платіжних методів
5 Вихід із системи. Після зміни необхідних платіжних методів у цілях
безпеки адміністратору рекомендується вийти зі системи натиснувши червону
кнопку “Logout” розташовану під списком доступних методів оплати.
86
ЧДТУ 252489 014 ПЗ
Висновки до розділу
У процесі розробки функціональних і логічних схем було встановлено, що
попереднє формалізоване моделювання структури системи є визначальним
чинником для узгодженості програмних компонентів. Побудова схем дозволила
чітко визначити склад підсистем, їхні взаємозв’язки та послідовність виконання
операцій, що зменшило кількість логічних помилок на етапі реалізації.
Під час проєктування бази даних було виявлено, що структурована схема з
чітко визначеними зв’язками між сутностями користувачів, замовлень, товарів і
платежів забезпечує цілісність даних та спрощує контроль стану замовлення.
Практична реалізація показала, що використання зовнішніх ключів і обмежень
дозволяє уникнути суперечливих станів даних під час виконання операцій
оформлення замовлення.
Розробка інтерфейсу користувача підтвердила важливість узгодження
елементів інтерфейсу з бізнес-логікою системи. У ході реалізації було
встановлено, що послідовна навігація та чітке відображення результатів
виконаних дій підвищують зрозумілість процесу оформлення замовлення та
зменшують імовірність помилкових дій з боку користувача.
Під час реалізації програмних компонентів було встановлено, що чітке
розділення відповідальності між модулями спрощує налагодження системи та
підвищує її стабільність.
Результати тестування показали, що найбільш критичні помилки
виникають не в окремих модулях, а на рівні узгодженості логіки між
компонентами системи. Це підтвердило доцільність поетапного тестування та
перевірки завершених користувацьких сценаріїв як основного критерію
готовності програмного продукту до практичного використання.
Вцілому можна сказати, що виявлені під час роботи особливості
підтверджують ефективність комплексного підходу до проєктування та реалізації
вебзастосунків.
87
ЧДТУ 252489 014 ПЗ
ВИСНОВКИ
На сучасному етапі розвитку електронної комерції інтернет-магазини
залишаються одним із найпоширеніших типів вебзастосунків, що потребують
поєднання зручного користувацького інтерфейсу, коректної обробки замовлень
та надійної інтеграції платіжних систем. Проведений аналіз існуючих рішень
показав, що у більшості систем платіжна логіка реалізується статично, що
ускладнює супровід програмного забезпечення та обмежує його адаптацію до
змін бізнес-вимог.
У кваліфікаційній магістерській роботі розв’язано актуальну науково-
практичну задачу з проєктування та реалізації модульної системи динамічної
інтеграції платіжних сервісів у вебзастосунки електронної комерції.
Було проведено аналіз сучасних платіжних сервісів та підходів до їх
інтеграції, який підтвердив, що традиційні методи “жорсткого кодування”
перешкоджають масштабованості систем. Визначено, що найбільш
перспективним напрямком є перехід до слабозв’язаних архітектур, що
дозволяють адаптувати платіжну логіку до змін бізнес-вимог без рефакторингу
основного коду.
Також було досліджено архітектуру React SPA та специфіку безпечної
взаємодії з платіжними API. Встановлено, що використання паттернів
проектування на стороні фронтенду у поєднанні з серверною валідацією дозволяє
забезпечити високий рівень безпеки транзакцій та гнучкість користувацького
інтерфейсу.
Розроблена модель динамічного підключення платіжних модулів, яка й
була науковою новизною роботи дозволила здійснювати конфігурацію,
увімкнення та вимкнення платіжних методів через панель адміністратора в
режимі реального часу. Досяглося це шляхом абстрагування логіки платежів від
компонентів відображення.
Реалізовано повнофункціональний прототип інтернет-магазину на базі
стеку React. У системі впроваджено адаптивний інтерфейс, серверні компоненти
88
ЧДТУ 252489 014 ПЗ
для безпечного обміну даними та механізм адміністрування активних сервісів.
Практична реалізація підтвердила життєздатність розробленої архітектури.
За допомогою експериментальних методів та вимірювань оцінено
швидкість виконання транзакцій та вплив модуля динамічного підключення на
часові характеристики системи. Результати тестування довели, що впровадження
додаткового рівня абстракції не створює критичних затримок, при цьому час на
зміну платіжного провайдера в системі скорочується до мінімуму.
Практичне значення отриманих результатів підтверджується створенням
готового до використання програмного рішення. Розроблений проєкт може бути
використаний у реальних комерційних застосунках, як шаблон для інтеграції
платежів у стартапах, а також у навчальних курсах з веброзробки та архітектури
SPA.
89
ЧДТУ 252489 014 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 van Gelder K. E-commerce worldwide — statistics & facts [Електронний
ресурс] // Statista. — 2025. — Режим доступу:
https://www.statista.com/topics/871/online-shopping/ (дата звернення: 12.12.2025).
2 Frąckiewicz M. War-Fueled E-Commerce Boom: Inside Ukraine’s Online
Shopping Surge in 2025 [Електронний ресурс] // ts2.tech. — 2025. — Режим
доступу: https://ts2.tech/en/war-fueled-e-commerce-boom-inside-ukraines-online-
shopping-surge-in-2025/ (дата звернення: 15.11.2025).
3 50 Cart Abandonment Rate Statistics 2025 [Електронний ресурс] //
Baymard Institute. — 2025. — Режим доступу: https://baymard.com/lists/cart-
abandonment-rate (дата звернення: 30.10.2025).
4 History & facts [Електронний ресурс] // PayPal. — Режим доступу:
https://about.pypl.com/who-we-are/history-and-facts/default.aspx (дата звернення:
05.12.2025).
5 Payment Card Industry Data Security Standard (PCI DSS): PCI DSS
Explained [Електронний ресурс] // Zenarmor. — Режим доступу:
https://www.zenarmor.com/docs/network-security-tutorials/what-is-payment-card-
industry-data-security-standard-pci-dss (дата звернення: 29.11.2025).
6 Henry C., Shimoda M., Zhu J. Methods-of-Payment Survey Report 2021
[Електронний ресурс] // Bank of Canada. — 2021. — Режим доступу:
https://www.bankofcanada.ca/wp-content/uploads/2022/12/sdp2022-23.pdf (дата
звернення: 20.10.2025).
7 Hazar A., Babuşcu Şenol. Financial Technologies: Digital Payment Systems
and Digital Banking // Today’s Dynamics. Journal of Research Innovation and
Technologies (JoRIT). — 2023. — P. 166.
8 Buranasujja R., Kraiwanit T.
Factors affecting consumers’ decisions in selecting payment gateways for online
shopping // Journal of Asian Finance, Economics and Business. – 2018. – Vol. 5, No. 4.
– P. 135–145.
90
ЧДТУ 252489 014 ПЗ
9 Dahlberg T., Mallat N., Ondrus J., Zmijewska A. Past, present and future of
mobile payments research: A literature review // Electronic Commerce Research and
Applications. — 2008. — Vol. 7, No. 2. — P. 165–181.
10 Anderson R., Moore T. The economics of information security // Science. —
2006. — Vol. 314, No. 5799. — P. 610–613.
11 Almeida F., Santos J. D., Monteiro J. A. E-commerce payment systems: A
review and classification // Information Systems and e-Business Management. — 2020.
— Vol. 18. — P. 429–454.
12 Arango C., Huynh K. P., Sabetti L. How do you pay? The role of incentives
at the point-of-sale // Journal of Banking & Finance. — 2015. — Vol. 50. — P. 1–14.
13 Mallat N. Exploring consumer adoption of mobile payments – A qualitative
study // Journal of Strategic Information Systems. — 2007. — Vol. 16, No. 4. — P.
413–432.
14 Zachariadis M., Ozcan P. The API economy and digital transformation in
financial services // MIS Quarterly Executive. — 2017. — Vol. 16, No. 4. — P. 203–
218.
15 Garg V., Khan S. Microservice Architectures for Secure Digital Wallet
Integrations // Stallion Journal for Multidisciplinary Associated Research Studies. —
2024. — С. 166–167.
16 Wang Y. Optimizing Payment Systems with Microservices and Event-Driven
Architecture: The Case of Mollie Platform. — 2024. — 33 с.
17 Suprun O., Provotar O., Suprun O. Development of modern payment
gateways using blockchain technology [Електронний ресурс] // CEUR Workshop
Proceedings. — Режим доступу: https://ceur-ws.org/Vol-4024/paper06.pdf (дата
звернення: 03.11.2025).
18 Bertell K. The Role of React.js in Modern E-commerce: Faster, Smarter,
Better [Електронний ресурс] // MakersDen. — 2025. — Режим доступу:
https://makersden.io/blog/the-role-of-react-js-in-modern-e-commerce-faster-smarter-
better/ (дата звернення: 22.10.2025).
91
ЧДТУ 252489 014 ПЗ
19 Why ReactJS is the Future of eCommerce Website Development?
[Електронний ресурс] // Prakash Infotech. — 2025. — Режим доступу:
https://prakashinfotech.com/why-reactjs-is-the-future-of-ecommerce-website-
development/ (дата звернення: 01.12.2025).
20 ApiX-Drive [Електронний ресурс]. — Режим доступу: https://apix-
drive.com/ (дата звернення: 28.10.2025).
21 Render [Електронний ресурс]. — Режим доступу: https://render.com/
(дата звернення: 05.11.2025).
22 Drozdovica J. Most Popular Payment Methods by Country and Region
[Електронний ресурс] // noda. — Режим доступу: https://noda.live/articles/most-
popular-payment-methods-by-country (дата звернення: 14.11.2025).
23 What is the market share of Stripe in 2025? [Електронний ресурс] // Red
Stag Fulfillment. — 2025. — Режим доступу: https://redstagfulfillment.com/what-is-
the-market-share-of-stripe/ (дата звернення: 09.12.2025).
24 Payment Card Industry Data Security Standard (PCI DSS) 4.0.1 : [стандарт].
— 2024.
92