Payment Bridge Api

📖 Overview

PaymentBridge.Api is a mini-concept educational project demonstrating modern software design patterns in .NET 10. It simulates a payment gateway system that integrates with multiple payment providers through a unified interface.

What does it do?

The project acts as a payment bridge/gateway that:

• Accepts payment requests with operation codes (Pay, Refund, Query) and company codes
• Routes requests to the appropriate payment provider adapter
• Returns standardized responses regardless of the underlying provider
• Demonstrates clean architecture with separation of concerns

Why was it built?

This project serves as a learning resource for developers who want to understand:

• How to implement design patterns in real-world scenarios
• How to structure a clean, maintainable codebase
• How to use modern .NET features and C# 14 syntax

Key Features

• Multiple Payment Providers: Unified interface
• Design Patterns: Adapter, Factory, and CQRS (via MediatR)
• Modern .NET: Built with .NET 10 and C# 14 features
• RESTful API: Follows REST standards with proper HTTP status codes
• Mock Data: All adapters return mock data for safe testing
• Pipeline Behaviors: Logging, performance monitoring, and validation
• Error Handling: Comprehensive exception handling with appropriate HTTP status codes
• Unified Response Model: Consistent response format across all providers

📐 Architecture

Minimal API (Program.cs)
  └─ Route Groups (/api/v1.0/payment)
      ├─ POST /api/v1.0/payment → ProcessPaymentCommand
      ├─ GET /api/v1.0/payment/{companyCode}/{transactionId} → GetPaymentQuery
      └─ Pipeline Behaviors
          ├─ LoggingBehavior
          ├─ PerformanceBehavior
          └─ ValidationBehavior
      └─ AdapterFactory
          └─ IAdapter (Adapter Pattern)
              ├─ PayPalAdapter
              ├─ StripeAdapter
              └─ XBankAdapter

Adapters contain provider-specific logic while maintaining a unified interface. The Factory Pattern resolves the correct adapter based on CompanyCode, and MediatR handles command/query separation with pipeline behaviors for cross-cutting concerns.

🎯 Purpose

Learning resource for understanding:

• Adapter Pattern for multiple payment providers
• Factory Pattern for adapter resolution
• MediatR for Command/Query separation
• Pipeline behaviors (logging, performance, validation)
• Minimal API with route groups
• RESTful API design

📁 Structure

src/PaymentBridge.Api/
├── Adapters/          # Adapter Pattern
│   ├── PayPal/
│   ├── Stripe/
│   └── XBank/
├── Commands/          # Write operations
├── Queries/           # Read operations
├── Handlers/          # Business logic
├── Behaviors/         # Pipeline middleware
├── Factory/           # Factory Pattern
├── Models/            # Domain models
└── Configuration/     # Configuration loading

🏗️ Design Patterns

Adapter Pattern

Each payment provider implements IAdapter for unified interface. All adapters return mock data for demonstration purposes.

Factory Pattern

AdapterFactory resolves adapters by CompanyCode.

MediatR (CQRS)

• Commands: Change state (Pay, Refund)
• Queries: Read data (Get payment)
• Behaviors: Cross-cutting concerns (logging, performance, validation)

🧪 Testing

Use the payment.http file in Rider/VS Code with REST Client extension to test endpoints directly from the IDE.

📝 Notes

• All adapters return mock data for demonstration purposes
• Payment providers (PayPal, Stripe, XBank) are simulated
• Uses modern C# 14 features (file-scoped namespaces, primary constructors, collection expressions)
• RESTful API design following HTTP status code standards

📦 Technologies

• .NET 10 - Latest .NET framework
• C# 14 - Modern C# language features
• MediatR - CQRS and mediator pattern implementation
• Minimal APIs - Lightweight API development
• System.Text.Json - Modern JSON serialization