Spring Boot UPI failure and reconciliation simulator
A deterministic Indian payment-failure laboratory for studying idempotency, uncertain outcomes, RBI T+1 and T+5 reversal rules, and reconciliation without moving real money.
Project definition
Problem statement
A digital payment request can be accepted by one participant while another response is delayed or lost. Retrying carelessly can create duplicate effects, while treating every timeout as a failure can leave a debit and displayed status inconsistent.
The engineering problem is to represent payer, beneficiary, response, and settlement evidence independently, suppress duplicate financial effects, apply the correct deadline class, and explain why a prepared case succeeds, requires reversal, remains uncertain, or needs manual review.
Project objectives
- Model selected Indian payment-failure states with synthetic records and integer paise.
- Prevent a duplicate operation identifier from applying the same debit or credit twice.
- Preserve delayed, missing, duplicate, contradictory, and out-of-order evidence in a readable timeline.
- Apply the prepared RBI T+1 transfer and T+5 merchant-payment deadline rules.
- Compare expected and observed state and finding sets across repeated deterministic trials.
Project structure
Project components
Scenario catalogue
Defines ten immutable synthetic scenarios with payment class, amount, ordered actions, expected state, and expected findings.
Simulation engine
Applies debit, credit, response, decline, reversal, settlement, merchant, duplicate, and time-advance actions to a fresh run context.
Reconciliation engine
Compares participant effects, response evidence, duplicate suppression, logical day, and settlement amount to produce named findings and a decision.
Run store
Persists complete synthetic results and timeline JSON in PostgreSQL through parameterised JDBC operations.
Audit path
Publishes a simulation-completed event to RabbitMQ and records receipt through a local consumer.
Evidence interface
Vue presents the catalogue, prepared sequence, returned event trace, record deltas, findings, and repeated evaluation.
Methodology
Project workflow
- 01Select a prepared scenario
The student chooses one of ten documented transaction paths and reviews its ordered event sequence.
- 02Execute the events
The engine applies each action once per operation identifier and records whether the attempt changed state.
- 03Reconcile the records
The project evaluates payer and beneficiary deltas, response state, elapsed logical day, duplicate count, and settlement amount.
- 04Store and publish
The completed result is stored in PostgreSQL and an audit event is sent through RabbitMQ.
- 05Evaluate the oracle
Observed state and findings are compared exactly with the scenario declaration across thirty trials.
Demonstration scenario
A synthetic Rs 500.00 transfer debits the payer and credits the beneficiary, but the payer-facing success response is absent. A duplicate operation attempt is retained as suppressed rather than applying a second financial effect. The final view distinguishes response uncertainty from the participant balance effects and shows the complete event trace.
Engineering
Tools and method
- Application core
- Java records and services separate immutable scenario definitions, mutable run context, event application, reconciliation, and evaluation.
- HTTP boundary
- Spring Boot exposes a small versioned API with validation, bounded bodies, and no arbitrary event-program input.
- Persistence and audit
- PostgreSQL retains complete run evidence while RabbitMQ demonstrates an asynchronous completion-audit path.
- Interface
- Vue and TypeScript present a three-column engineering laboratory behind an unprivileged Nginx reverse proxy.
- Reproducibility
- Digest-pinned containers, locked packages, tests, retained JSON and CSV, and a documentation builder support repeatable study.
- Isolation
- All published service ports bind to localhost and no component connects to NPCI, a bank, a merchant, or a live payment endpoint.
Testing
Evaluation
Evaluation measures
- Exact expected-state and finding-set agreement across ten prepared scenarios
- Thirty deterministic trials per scenario and 300 trials in total
- 300 correct classifications and prepared classification accuracy of 1.0
- Separate median and P95 in-process timing for every scenario
- Unit, API, persistence, messaging, Vue build, container, and security checks
- Explicit exclusion of HTTP, storage, broker, browser, network, and real UPI performance from timing claims
Project boundaries
- The project is a classroom simulator and does not connect to UPI, NPCI, banks, or real accounts.
- It stores only synthetic run evidence and does not collect UPI PINs, account details, customer data, buyer details, or student information.
- The T+1 and T+5 logic uses simplified whole logical days and a public RBI source.
- The 300-run result evaluates only the deterministic prepared model and does not certify a production payment system or describe real UPI performance.
Included
- 01Deterministic transaction state and reconciliation engines
- 02Ten prepared success, timeout, duplicate, reversal, ordering, merchant, and settlement scenarios
- 03PostgreSQL run history and RabbitMQ audit-event integration
- 04Vue evidence interface with scenario, timeline, record, finding, and evaluation views
- 05300-run retained evaluation with exact expected-result comparison
- 06Complete source code in a private GitHub repository
- 0782-page project documentation in PDF and editable Word formats
- 0811-page setup and usage guide in PDF and editable Word formats
Project record
No information is collected on this page.
- Permanent project ID
- GP-CS-0QJ6D29
- Catalogued
- 21 Aug 2026
- Completed
- 23 Aug 2026
- Verified
- 23 Aug 2026
- Demonstration
- Included in repository
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.