Endterm_Secure_Online_Payment_System_Slides_Fixed

1.

Secure Online
Payment System
End-Term Project Stage 2
Finance and Cybersecurity
Astana IT University | 2026/2027
Zhangirkhan • Talap • Malik • Dastan

2.

Problem, users and design changes
QR checkout with safe recovery on an unstable connection
Customer
Scans merchant QR,
authenticates and confirms
payment on a smartphone.
Merchant
Receives order and payment status
through the merchant service.
SECURE ONLINE PAYMENT SYSTEM | 2
Changes after defenses
• Administrative client moved from a
discrete GPU to integrated graphics.
• Failed login, password or PIN now returns
the user to a retry path with an attempt
limit.
• Connection recovery checks the original
payment status before any retry.

3.

System map
Route, database and threat map
SECURE ONLINE PAYMENT SYSTEM | 3

4.

From URL to stored record
Checkout URL: https://pay.securepay-project.kz/checkout
1
DNS lookup
Phone asks a resolver for the checkout host
2
TCP handshake
SYN, SYN-ACK, ACK establish the connection
3
HTTPS request
QR order ID, authentication result and idempotency key
4
Routing
Mobile ISP and Internet carry TCP segments
5
Server rebuild
TCP orders the stream before delivery to the API
6
DB transaction
PAYMENT write and ORDER update commit together
7
Response
Phone shows Paid, Failed or Pending
If the connection drops after the database commit, durability preserves the record. On reopening, the app
checks the same idempotency key before it offers any retry.
SECURE ONLINE PAYMENT SYSTEM | 4

5.

Cloud and phone
Hybrid deployment supports public access while separating personal data
Hybrid deployment
Phone and cloud split
Public web/API tier
Phone
PS Cloud Services, Astana
QR scanner, payment review, passkey/PIN, status
display
Private PostgreSQL segment
Personal data and transaction records
Separate encrypted backup
Almaty (pgBackRest, read-only)
Cloud
Authentication, payment API, PostgreSQL, audit and
backup scheduling
Mobile recovery
Retained input, Pending state and idempotency
checks.
Cloud characteristics in this design: on-demand provisioning, broad network access, pooled API capacity, temporary
elasticity and metered usage.
SECURE ONLINE PAYMENT SYSTEM | 5

6.

One payment record
From QR confirmation to a design decision
Capture
Transmit
Store
Access
Protect
Backup
Decide
Phone creates
payment
metadata and
idempotency
key
HTTPS/TLS 1.3
over TCP
through
mobile data
PostgreSQL
writes
PAYMENT and
updates
ORDER
Customer and
merchant read
own records;
API writes
Validation,
parameterised
queries, roles
and rate limit
Daily full
backup plus
5-minute WAL
to isolated
copy
Review retries
and pending
states to
improve
recovery
Riskiest stage: access. A stolen privileged credential can expose many stored records, so the design limits
direct table access and protects sensitive fields separately.
Survey connection: PAYMENT records answer reliability questions, while the supplied survey answers the suspicious-link
awareness question.
SECURE ONLINE PAYMENT SYSTEM | 6

7.

Suspicious bank links in the supplied survey
20 responses recorded in Assignment 4
Question
Did a respondent receive a suspicious
bank link in the last three months?
1
5
1
0
Result
9 of 20 respondents reported a
suspicious link. The result supports a
proposed in-app warning and reporting
route, not a claim about all customers in
Kazakhstan.
SECURE ONLINE PAYMENT SYSTEM | 7
9
11
5
0
Yes
No
Responses
Decision: add anti-phishing education and
a suspicious-link reporting option.