Financial systems / Quality engineering

CreditFlow QE

A transactional credit-card simulator with independent Java, Cucumber and REST Assured automation, plus executed CI and browser-test evidence.

Inspect the system

Explore synthetic accounts, post purchases and payments, and inspect the source, test framework and verified execution evidence.

Backend
Java 21, Spring Boot, PostgreSQL and Flyway; exact money, atomic ledger updates and original receipt replay.
API automation
Independent Cucumber/REST Assured HTTP tests, JUnit Jupiter and a separate TestNG module.
UI and CI
Java Selenium/Playwright, Bruno and GitHub Actions; Jenkins pipeline executed on an isolated local controller.

Overview

A synthetic banking application and independent automation framework built with AI-assisted development and human-reviewed validation for reproducible engineering and interview practice.

Problem

A successful HTTP response does not prove a correct financial ledger. Duplicate requests, concurrent updates, and database failures can change balances twice or leave a receipt inconsistent with account state. This project tests those failures instead of relying only on happy-path purchases and payments.

From transaction to verification

  1. Create a short-lived synthetic account
  2. Validate ownership, exact USD input, and available balance
  3. Lock account state and atomically post a ledger entry
  4. Return the original receipt or an explicit error
  5. Recheck API behavior, PostgreSQL state, and browser workflow

The sandbox models purchases and payments against a fixed synthetic credit limit. Account-scoped idempotency checks the operation and normalized amount. An identical retry returns its original receipt, even when later activity has changed the current balance; conflicting key reuse returns HTTP 409.

Selected interfaces

CreditFlow QE hosted simulator after a synthetic $50 payment
Actual Playwright journey: $200 outstanding, $800 available and one committed payment. View full-size screenshot

Technical highlights

  • Independent Java/Cucumber automation validates a synthetic transactional credit-card API.
  • Real PostgreSQL rollback, ownership, idempotency and concurrency checks.
  • Custom-host HTTPS, isolated synthetic sessions and genuine test evidence.

Architecture

Railway hosts the Next.js command center, Java 21 / Spring Boot API and PostgreSQL ledger. The API uses private verify-full TLS, a dedicated CA and a restricted runtime role; Flyway migrations run separately with administrative authority. Reviewed web/API releases remain pinned. A Next.js command center mediates selected synthetic visitor workflows. Cucumber/REST Assured and TestNG modules exercise the running HTTP API independently of application source; Java Selenium and Playwright cover selected UI journeys.

What I built

Recorded tests exercise per-account row locking, original-receipt replay after intervening activity, and rollback when a deliberately injected database insert failure occurs in an isolated integration database. Browser tests cover ambiguous response handling and safe retry/reconciliation. These checks prove specified scenarios, not every possible concurrency interleaving.

Engineering decisions

  • Use actual PostgreSQL rather than an in-memory substitute so integration checks exercise locks, uniqueness constraints, and transaction rollback.
  • Use one transactional API instead of unneeded microservices; make the external HTTP test clients independent of application implementation classes.
  • Keep dated, source-bound reports and hashes so historical CI and Jenkins evidence cannot be mistaken for validation of later changes.

Validation

Recorded October 15 source verification passed 31 application unit tests, 18 PostgreSQL integration tests, and 31 Cucumber scenarios in each private/public mode. The hosted release separately passed ten banking checks and eleven Java UI/BFF tests. These are distinct dated executions, not one aggregate current test total.

GitHub Actions run 38820309474 passed core and browser jobs at main revision 631948a. A separate isolated local Jenkins build published 123 passing cases, with 32 separate evidence-framework tests, from an earlier pinned source revision. Neither the Jenkins record nor historical hosted checks establish current production banking operation or availability guarantees.

Lessons / constraints

Synthetic data only; no real cards, funds, settlement or regulatory-compliance claim. Sessions expire after 30 minutes and public quotas are conservative. API sleep is disabled; the Railway frontend may wake from idle. Local Jenkins execution is recorded; sustained-load behavior and availability/SLA remain unverified. Off-volume backups and WAL recovery are verified within the documented scope; the first scheduled daily-backup closeout and resource retirement remain pending as of October 25, 2026.