gaurav-gt01/meshpay

Purpose and Entry Points

This is a Java payment-mesh demo centered on simulated devices, encrypted payment packets, bridge ingestion, and account settlement. The application starts at src/main/java/com/demo/upimesh/MeshPayApplication.java. HTTP-facing entry points are split between API operations in src/main/java/com/demo/upimesh/controller/ApiController.java and a dashboard route in src/main/java/com/demo/upimesh/controller/DashboardController.java, backed by src/main/resources/templates/dashboard.html.

Application Configuration

src/main/java/com/demo/upimesh/config/AppConfig.java is the central application wiring/configuration boundary. Runtime properties reside in src/main/resources/application.properties. Maven packaging and dependency/runtime selection are defined by pom.xml; the repository uses the Maven wrapper (mvnw, .mvn/wrapper/maven-wrapper.properties).

Payment and Mesh Domain

Core domain records model account balances, payment requests, mesh transport, and resulting transactions:

• src/main/java/com/demo/upimesh/model/Account.java

• src/main/java/com/demo/upimesh/model/PaymentInstruction.java

• src/main/java/com/demo/upimesh/model/MeshPacket.java

• src/main/java/com/demo/upimesh/model/Transaction.java

PaymentInstruction is the likely business-level payment payload, while MeshPacket establishes a separate transport/envelope boundary for movement through the mesh.

Mesh Simulation and Bridge Ingestion

src/main/java/com/demo/upimesh/service/MeshSimulatorService.java orchestrates simulated mesh behavior, using src/main/java/com/demo/upimesh/service/VirtualDevice.java as the device-level abstraction. src/main/java/com/demo/upimesh/service/BridgeIngestionService.java is the boundary where packets arriving from the mesh are accepted into the server-side payment flow.

The principal control path is therefore: controller or simulator creates a payment instruction → it is packaged/transmitted through virtual devices → bridge ingestion accepts it for server processing.

Cryptographic Boundary

src/main/java/com/demo/upimesh/crypto/HybridCryptoService.java provides cryptographic handling for mesh/payment payloads. src/main/java/com/demo/upimesh/crypto/ServerKeyHolder.java owns or exposes server key material. These classes separate encrypted packet handling from controller, device, and settlement logic; mesh-facing data should cross this boundary as MeshPacket rather than as trusted business objects.

Processing, Idempotency, and Settlement

src/main/java/com/demo/upimesh/service/IdempotencyService.java protects the ingestion/processing path from duplicate payment handling, which is important for retransmitted mesh packets or concurrent delivery. src/main/java/com/demo/upimesh/service/SettlementService.java applies the resulting financial state transition and creates/updates transaction outcomes. src/main/java/com/demo/upimesh/service/DemoService.java likely supplies demo orchestration or seeded scenario behavior around these services.

The expected transactional sequence is: validate/decrypt an ingested packet → enforce idempotency → settle against accounts → record a transaction.

Persistence and Operational Boundaries

Persistence is represented by repository interfaces:

• src/main/java/com/demo/upimesh/model/AccountRepository.java

• src/main/java/com/demo/upimesh/model/TransactionRepository.java

Accounts and transaction history are therefore distinct persistence concerns. Controllers should remain request/response boundaries, services own orchestration and state changes, repositories own storage access, and crypto/device classes own untrusted mesh and key-handling concerns. The included concurrency test at src/test/java/com/demo/upimesh/IdempotencyConcurrencyTest.java signals that duplicate/concurrent processing is a material correctness constraint.