adarshnanu/payment_app repository overview

⁠Payment App

⁠Overview

Payment App is a C++ backend application built using the Drogon web framework and PostgreSQL. The project was developed as a learning and demonstration platform for modern backend engineering concepts including REST APIs, asynchronous processing, connection pooling, worker thread management, retry processing, health monitoring, metrics collection, CI/CD and containerization.

The foundation of the application is designed with payment processing in mind, which is reflected in the project name. The current version does not connect to external payment networks or core banking systems. However, integration with Visa and Mastercard staging environments is part of the planned roadmap and will be implemented in future releases.

⁠Application Flow

The application accepts transaction requests in JSON format through REST APIs.

⁠Transaction Creation

Clients submit transaction requests using an HTTP POST request. Each request must contain a unique idempotency key to prevent duplicate transaction processing.

Upon receiving a valid request:

1. The transaction is persisted to PostgreSQL.
2. The transaction is placed into an internal processing queue.
3. An HTTP 200 response is returned to the client.

At this stage the request has been accepted for processing but may not yet have reached a final state.

⁠Transaction Processing

Worker threads continuously monitor the processing queue and immediately wake when new transactions become available.

The worker:

1. Retrieves the idempotency key from the queued message.
2. Loads the complete transaction details from PostgreSQL.
3. Performs transaction processing.
4. Updates the transaction status in the database.

In the current implementation, all successfully processed transactions are marked as:

SUCCESS

Future versions will replace this simulated processing with real integrations to external payment systems.

⁠Transaction Status Retrieval

After receiving the HTTP 200 response from the POST request, clients can query the transaction status using the idempotency key.

Possible transaction states include:

PENDING
PROCESSING
SUCCESS
FAILED
FAILED_RETRYABLE

⁠Retry Processing

Transactions that fail due to temporary technical issues are not immediately discarded.

A dedicated retry worker periodically scans for retryable transactions and attempts reprocessing. This design provides resilience against transient failures and mimics behavior commonly found in payment processing systems.

⁠Health Monitoring and Metrics

The application exposes operational endpoints that can be used for monitoring and deployment automation.

Supported capabilities include:

• Liveness checks
• Readiness checks
• Real-time metrics
• Connection pool monitoring
• Worker thread monitoring
• Queue depth monitoring

These endpoints are designed to support future deployment in containerized and orchestration environments.

⁠Technical Highlights

• C++20
• Drogon HTTP Framework
• PostgreSQL
• Connection Pooling
• Worker Thread Pool
• Retry Processing Worker
• Condition Variables
• Thread-Safe Logging
• Health Endpoints
• Metrics Endpoints
• GitHub Actions CI Pipeline
• Docker Containerization

⁠Roadmap

Planned enhancements include:

• Visa Sandbox Integration
• Mastercard Sandbox Integration
• Enhanced Transaction Validation
• Additional Metrics and Monitoring
• Authentication and Authorization
• Docker Compose Support
• Production Deployment Enhancements