KuberKosh

Because user authentication passes securely through official Google OAuth2 validation layers, KuberKosh never reads, parses, or tracks password credentials locally on its application instances.

TOTP forms a barrier during standard session validation phases to prevent account takeovers. The six-digit wallet PIN exists as an independent authorization step designed explicitly to sign actual transaction properties.

When loading cash into KuberKosh, your banking ledger registers only a single bulk record. All subsequent small transactions occur cleanly inside the separate wallet environment, preventing statement clutter.

The system handles transaction logs systematically. Before any balance is modified, a unique, deterministic transaction ID is generated via a SHA3-256 hash using the sender, receiver, amount, and timestamp metrics. If a system failure or network dropout occurs mid-execution, the database engine rolls back the operations, and the transaction is logged in the transaction_logs table with a status of "Failed" and the corresponding error details for auditing.

Relational integrity and financial accounting precision require absolute ACID compliance. MariaDB provides a robust, high-performance relational database management system structured in a 3rd Normal Form (3NF) normalized database schema. This architecture ensures complete data integrity, prevents duplicate transaction redundancy, and handles standard sub-queries and table joins far more efficiently than NoSQL alternatives.

KuberKosh follows OWASP core security guidelines to safeguard the data pipeline. For database communication, the backend relies completely on prepared statements via mysqli ($stmt->prepare) and parameterized data binding ($stmt->bind_param), rendering SQL injection vectors impossible. Furthermore, strict server-side and client-side parameter sanitization filters are implemented to clean incoming integer inputs and block potential payload insertions.

The application does not store temporary request sessions on the server for standard request links. Instead, when a user creates a payment request, all query parameters—including the target wallet address, amount, purpose, and remarks—are natively encoded directly into URL parameters processed via QRCode.js on the client side. When scanned by the payer, the system decodes the string and dynamically pre-fills the standard "Send Money" form securely, keeping the handshake lightweight and fast.

The testing phase utilized a multi-tier framework consisting of unit testing, integration testing, and automated vulnerability scanning. Individual functional components were validated via unit tests, while systemic module handshakes were targeted via integration tests. To guarantee security testing across raw HTTP data boundaries, BurpSuite was deployed as an intercepting proxy to capture, parse, and analyze traffic requests between the browser viewport and server endpoints—allowing the verification of edge cases like character-injected transaction values and negative amount limits.