Skip to main content

Payment Service Architecture

Overview​

The Payment Service uses a provider abstraction pattern to support multiple payment providers while maintaining a consistent API.

Architecture Diagram​

┌─────────────┐
│   Gateway   │
└──────┬──────┘
       │
       ▼
┌─────────────────────┐
│  Payment Service    │
│   (Rust/Actix)      │
└──────┬──────────────┘
       │
       ├──► Provider Factory
       │         │
       │         ├──► PayFast Provider
       │         ├──► Yoco Provider
       │         └──► Stripe Provider (future)
       │
       └──► PostgreSQL
              ├──► Payments
              ├──► Subscriptions
              └──► Invoices

Components​

API Layer​

  • REST API - Standard REST endpoints
  • GraphQL API - GraphQL query interface
  • Health Endpoints - Service health monitoring

Provider Abstraction​

  • Provider Trait - Common interface for all providers
  • Provider Factory - Creates appropriate provider instance
  • Provider Implementations - PayFast, Yoco, Stripe

Storage​

  • PostgreSQL - Payment records, subscriptions, invoices
  • Migrations - SQLx migrations for schema management

Payment Flow​

  1. Receive Request - API receives payment request
  2. Select Provider - Choose provider based on request
  3. Create Payment - Initialize payment with provider
  4. Store Record - Save payment record to database
  5. Process Payment - Execute payment via provider
  6. Update Status - Update payment status based on result
  7. Webhook Handling - Process provider webhooks

Security​

  • PCI Compliance - Never store full card details
  • Tokenization - Use provider tokens for card data
  • Encryption - Encrypt sensitive data at rest
  • Audit Logging - Log all payment operations

Observability​

  • OpenTelemetry - Distributed tracing
  • Prometheus - Metrics collection
  • Structured Logging - Comprehensive logging