Payment Gateway Service

Tech Stack

• Python
• FastAPI
• PostgreSQL
• Redis
• Docker

Key Features

• Dual payment gateway (Midtrans + Xendit) with automatic failover — if primary fails, switches to backup transparently
• QRIS payment flow: QR code generation → customer scan → webhook confirmation → status update
• Webhook handlers with SHA-512 signature verification (Midtrans) and callback-token verification (Xendit)
• Real-time order status broadcast via Redis Pub/Sub to kitchen displays and cashier monitors
• Multi-schema ORM support — dynamically handles both POS and ERP database structures
• Payment simulator endpoint for development and testing without real transactions

Architecture

POS → Gateway Factory → Provider → Webhook → Pub/Sub

• 1.POS application submits payment request to Payment Service
• 2.Gateway Factory selects primary provider, falls back to backup on failure
• 3.Payment record saved to PostgreSQL, QR string returned to POS
• 4.Provider sends webhook → Payment Service verifies and updates order status
• 5.Redis Pub/Sub broadcasts payment event to subscribed systems (kitchen, cashier)

Data / Processing Flow

1. 01Cashier creates transaction in POS — POST /transaction/payments
2. 02Service fetches order data, prepares item details and total
3. 03Gateway Factory attempts primary provider, falls back to secondary if needed
4. 04QR string and transaction ID returned to POS for display
5. 05Customer scans QR and pays — provider sends webhook
6. 06Service verifies webhook signature and updates payment + order status
7. 07Redis Pub/Sub publishes event to order:channel:{store_id}

Highlights & Metrics

• Automatic failover between Midtrans and Xendit without client awareness
• Real-time order status broadcast via Redis Pub/Sub
• Dual-database support covering POS and ERP schemas at runtime

Use Cases

• QRIS payment processing in F&B POS systems (restaurants, cafes)
• Real-time kitchen and cashier display notifications
• Failover payment processing to maintain uptime during provider outages
• POS and ERP dual-system payment integration

My Contributions

Technical Highlights

• Factory + Abstract Base Class enforces consistent interface across Midtrans and Xendit
• Failover is fully transparent — client never knows which provider processed the transaction
• Singleton gateway instances avoid redundant provider connections
• Automatic decimal rounding adjustment handles Midtrans item-total validation requirements

Challenges Solved

• !Single-provider dependency causing full transaction failure on outages — solved with dual-gateway automatic failover
• !Slow order status sync between kitchen and cashier — solved with Redis Pub/Sub real-time broadcast
• !Multiple database schemas (POS and ERP) with different structures — solved with dynamic ORM model switching