Vitalii Linevych on the Full-Stack Engineer’s Responsibility in the Face of Cyber Threats

Personal data breaches, fraudulent transactions, compromised payment systems — every year, the number of cyber incidents in eCommerce and digital platforms continues to grow.

For services processing financial operations of millions of users across dozens of countries, security is a requirement that can determine the very existence of a business.. A single successful breach can cost a company money, reputation, and audience trust..

Vitalii Linevych works as a Full-Stack Software Engineer at Eduki, an international EdTech company, where he led the development and integration of payment systems for international markets and implemented protection mechanisms at the API and authentication levels. In a conversation with our editorial team, he analyzes the systemic approach to cybersecurity applied on the platform and explains why an engineer’s responsibility extends far beyond writing secure code.

Authentication Layer: Protecting User Accounts

The first line of defense for any web platform is the authentication system — the mechanism that verifies a user’s identity. . Eduki uses JWT tokens (JSON Web Tokens) with a short lifespan. This means that even if a token is intercepted, an attacker has a very limited window to exploit it.

Additionally, a “refresh token rotation” mechanism has been implemented — each time a session is renewed, the previous token becomes invalid. Any password change immediately invalidates all of the user’s active sessions.

“Security is the core of the system, and only a holistic approach to data protection at every level can withstand modern threats,” Vitalii notes.

Payment Security: PCI DSS, PSD2, and Operating Across 27 Markets

Processing payments in 27 countries creates a multi-layered set of security requirements. The Eduki platform adheres to the PCI DSS (Payment Card Industry Data Security Standard) and does not store bank card data directly. Handling card data is delegated to payment providers such as Adyen, PayPal, Amazon Pay, and others, using client-side tokenization technology. This means that card numbers (PAN data) never even pass through Eduki’s servers.

For European users, SCA (Strong Customer Authentication) support has been implemented in accordance with the PSD2 directive — a European regulation that requires enhanced authentication for electronic payments within the European Economic Area. Every transaction is recorded with a full audit trail: initiator, IP address, timestamp, and result.

Vitalii Linevych served as the lead engineer for integrating these payment providers and adapting payment flows to the requirements of each market. The practical result of this work is that the platform processes transactions in multiple currencies across 27 markets without financial losses due to technical failures. For a service whose international expansion has already generated over €1.55 million in additional revenue, every vulnerability in the payment flow represents a direct financial risk. The security architecture built by Vitalii protects these revenue streams.

Fraud Detection and Protection Against Manipulation

To detect suspicious activity at the application level, the platform employs threshold limits and velocity checks — verifications that analyze the frequency and patterns of transactions. A separate threat comes from race conditions during simultaneous transactions — situations where two payment requests are processed in parallel, potentially leading to double charges. Vitalii Linevych explains that this is resolved through idempotency keys at the payment provider level and record-locking mechanisms in the database (optimistic/pessimistic locking).

Another risk specific to a multi-currency platform involves currency confusion attacks, where an amount in one currency is mistakenly or deliberately interpreted as another. Protection against this lies in the explicit passing of currency codes in all internal calls, with no implicit default values.

Vulnerability Patterns: What Internal Audits Reveal

Vitalii Linevych describes the categories of vulnerabilities that surface during internal code audits.

• The most common is IDOR (Insecure Direct Object Reference): a situation where a resource identifier is passed in a URL without verifying whether that resource belongs to the current user. The solution is authorization at the level of every request, rather than authentication only at login.

• The second category is mass assignment: vulnerabilities in ORM models where the list of fields permitted for writing is defined too broadly. This allows an attacker to write values into fields that should not be externally accessible.

• The third pattern involves leaks through overly detailed error responses, where technical information (stack traces) ends up in the API response. The solution is a centralized exception handler with different levels of detail for the development and production environments, along with monitoring through an error tracking system that filters sensitive fields.

GDPR and Financial Data Retention: An Architectural Challenge

A key architectural challengelies at the intersection of GDPR (the EU’s General Data Protection Regulation), which guarantees a user’s right to have personal data deleted, and regulatory requirements for retaining financial records.

Vitalii explains:

“We cannot simultaneously delete and retain the same record. The solution is anonymization instead of full deletion: the financial record is preserved for audit purposes, but personal data is extracted from it and rendered unidentifiable.”

At the scale of a platform with millions of users, the value of the database as a target for attackers increases significantly. This influences decisions regarding encryption at rest, network segmentation, and strict access control to the production environment based on the principle of least privilege, with no shared credentials.

Compliance-First Architecture: A Distinctive Engineering Approach

What sets Vitalii Linevych apart from most Full-Stack engineers in the industry is a specific architectural principle he consistently applies across projects: regulatory compliance is a foundational constraint built into the data model, workflows, and business logic from the very first line of code. Many engineering teams treat compliance as a later-stage layer, addressed after core functionality is complete. Vitalii Linevych designs systems in the opposite direction.

This approach has clear and practical implications. Systems built this way do not require costly rework when regulators update requirements, do not contain hidden gaps between product functionality and regulatory requirements, and can pass audits without emergency patches. In industries where a single compliance violation can halt business operations, this is a critical competitive advantage.

A Case in Point: The Gunsmith Work Order Management System

A clear example of this approach is Vitalii’s work as a Senior Full-Stack Software Engineer at 2acommerce, a company specializing in software solutions for licensed gunsmith shops in the United States. He independently designed and developed the Gunsmith Work Order Management System — a platform operating in a field regulated by the Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF).

Gunsmith shops in the U.S. are required to document every firearm accepted for service: make, model, caliber, and serial number at intake, along with a complete chain of custody through to its return to the owner. Despite the stringency of these requirements, the market had no specialized software that integrated work order management, parts tracking, a customer database, and compliance documentation within a single system. Shops relied on paper logbooks and spreadsheets — with no audit trail, no enforcement of record completeness, and no efficient search capability.

Vitalii was the sole engineer on the project, handling everything from architecture and database design to frontend development and deployment. The system’s data structures and documentation workflows were built around ATF requirements as a foundational architectural constraint: intake forms include all mandatory fields for federal reporting, every record carries a full audit trail with timestamps, and the data entry logic prevents incomplete records from being saved. The system was built using PHP/Laravel, MySQL, and Docker, with an interface adapted for users without technical backgrounds.

Within the first six months of launch, approximately 10 licensed gunsmith shops adopted the platform — a meaningful indicator of product-market fit in a niche industry with historically low rates of digitization. The platform became the first specialized digital solution in 2acommerce’s product portfolio designed for licensed gunsmiths.

The same principle — embedding regulatory requirements into the architectural core rather than bolting them on afterward — is what Vitalii applies today at Eduki when working with PCI DSS, PSD2, and GDPR requirements across 27 markets. It is a consistent engineering philosophy, not a one-time project decision.