BanglaPay

BanglaPay is a simulated mobile financial service built for the PSTU National Hackathon 2026. It demonstrates secure registration, virtual OTP and PIN authentication, OCR-assisted NID KYC, BDT wallets, transfers, payment requests, receipts, device control, and atomic double-entry financial transactions.

A Bangla-first simulated mobile financial service designed around secure authentication, trustworthy money movement, and auditable financial records.

BanglaPay is a full-stack fintech simulation I built for the PSTU National Hackathon 2026.

The goal was not simply to create another wallet interface.

I wanted to explore a more important engineering question:

How should a digital financial system be designed so that every balance-changing operation is secure, atomic, traceable, and internally consistent?

BanglaPay demonstrates a complete mobile financial service experience including registration, identity verification, wallet management, transfers, payment requests, receipts, device security, and financial ledger management.

It is an educational closed ecosystem and does not process real money or connect to real NID, banking, card, mobile operator, or payment networks.

A financial interface can look simple from the outside.

A user enters an amount, presses Send, and expects the money to move.

Behind that interaction, however, several things must remain correct:

• The sender must be authenticated.
• The account must have sufficient funds.
• The same request must not accidentally execute twice.
• The debit and credit must succeed together.
• Concurrent requests must not corrupt balances.
• Every movement of money must remain auditable.
• Cached account balances must agree with the underlying ledger.

That meant the project had to be designed around financial correctness, not just UI functionality.

I was responsible for the primary application engineering, including:

• Application architecture
• Full-stack development
• Database architecture
• Financial transaction model
• Authentication flows
• KYC workflow
• UI/UX implementation
• Supabase integration
• Deployment
• Technical documentation

Team

I structured BanglaPay around clear boundaries between routing, business logic, data access, and financial database operations.

Rather than allowing financial logic to be spread throughout frontend components, balance-changing operations are pushed toward controlled server and database boundaries.

This makes important financial rules easier to reason about, secure, and test.

A money transfer passes through several controlled stages before it is committed.

This helps ensure that a transfer cannot partially succeed.

One of the most important architectural decisions was using an append-only double-entry ledger.

Instead of thinking about a transfer as simply subtracting money from one balance and adding it to another, BanglaPay records both sides of the financial event.

The complete transaction must remain balanced.

This creates a historical financial record instead of relying solely on a mutable balance field.

Financial writes are executed atomically in PostgreSQL.

A transfer should never reach a state where:

• the sender was debited,
• but the receiver was not credited.

The transaction either completes successfully or the entire operation fails.

This protects the system from partial financial updates.

BanglaPay avoids floating-point values for financial calculations.

Money is stored as integer poisha using bigint.

For example:

৳100.00 = 10,000 poisha

This avoids floating-point precision problems in monetary calculations.

BanglaPay maintains account balances for efficient reads, but the ledger remains the financial record behind those balances.

The architecture follows an important invariant:

Cached account balances must always reconcile with the financial ledger.

If the two disagree, the system should treat that as a financial integrity problem rather than silently accepting the mismatch.

BanglaPay includes several layers of simulated account security.

Registration

Users can register using a mobile-number-based account flow.

Virtual OTP

A simulated OTP flow demonstrates phone verification without connecting the project to a real telecom provider.

Secure PIN

Users authenticate sensitive financial operations using a PIN-based workflow.

One Active Device

The system demonstrates a single-active-device model, adding another layer of account-session control.

The general security flow looks like this:

BanglaPay includes an identity verification workflow designed around Bangladeshi National ID documents.

The project does not connect to Bangladesh's real NID infrastructure.

The workflow exists to demonstrate how identity verification could fit into a financial application architecture.

Financial software requires more than testing whether a page renders correctly.

BanglaPay includes multiple verification layers.

npm run lint
npm run test:run
npm run test:e2e
npm run build

Testing Layers

Database Integration Tests

Financial integration tests run against a real local PostgreSQL environment.

This is important because simple database mocks cannot reliably verify:

• Row locks
• Database constraints
• Atomic transactions
• Idempotency
• Concurrent balance updates
• Ledger consistency

Browser Testing

Playwright is used for critical end-to-end application flows.

This helps verify that the complete user journey works across the actual application boundary.

BanglaPay was designed as a Bangla-first financial experience.

Rather than treating Bengali as a secondary translation, the interface was designed around local-language financial interactions.

The visual system uses:

• Dark fintech-inspired surfaces
• Purple and magenta accent gradients
• High-contrast financial information
• Mobile-first layouts
• Clear transactional actions
• Simple Bangla terminology
• Familiar wallet-style interaction patterns

The objective was to make the experience feel modern while still being locally understandable.

The hackathon version uses a modular monolith because financial transfers between two accounts benefit from remaining inside a single ACID transaction boundary.

If the application needed to scale significantly, the architecture provides several possible paths.

1. Transaction-Mode Connection Pooling

Useful for handling larger amounts of serverless application traffic.

2. Read Replicas

Transaction-history reads could move to replicas while balance authorization remains on the primary database.

3. Ledger Partitioning

As the transaction history grows, ledger data could be partitioned by time.

4. Account-Based Sharding

At substantially larger scale, accounts could eventually be distributed across database shards.

The key principle is to avoid introducing distributed-system complexity before it is actually necessary.

It would be easy to describe microservices as automatically more scalable.

For this project, however, a modular monolith is the more appropriate starting architecture.

A single transfer affects at least two accounts.

Keeping the transaction within one PostgreSQL database allows the system to maintain:

• ACID transactions
• Strong consistency
• Row-level locking
• Simple reconciliation
• Easier debugging

The architecture can evolve when scale demands it rather than introducing unnecessary complexity at the beginning.

BanglaPay was not primarily an exercise in building the largest possible feature list.

The main engineering focus was building a system whose financial behavior could be explained and defended.

That meant prioritizing:

• Correctness
• Security
• Transaction integrity
• Clear architectural boundaries
• Testability
• Maintainability
• Understandable code

BanglaPay was built for the PSTU National Hackathon 2026 at Patuakhali Science and Technology University.

The project gave us an opportunity to combine product design, fintech architecture, database engineering, security considerations, testing, and presentation within a competitive development environment.

The complete source code and technical documentation are available on GitHub:

View BanglaPay on GitHub

BanglaPay helped me explore a principle that matters far beyond fintech:

A system is not reliable merely because its UI appears to work.

For financial applications, correctness must exist at the architectural and database levels.

The project therefore became an exercise in designing not only a modern interface, but also a system where authentication, transactions, balances, and financial history have clear responsibilities and predictable behavior.