ABOUT_THE_PROJECT

Atozpay is an enterprise-grade fintech and digital payment gateway platform engineered to drive financial inclusion through micro-transactions and digital billing solutions. The system empowers a dual-layered ecosystem of dedicated transactional Agents and Regular Users, processing millions in Gross Merchandise Value (GMV) monthly.

This case study breaks down the backend architecture designed to handle complex business domains, asynchronous transaction streams, and massive third-party API integrations smoothly.

1. Core Domain Service Architecture

To prevent architectural bottlenecks and maintain domain isolation, the core backend platform (structured across the latest API controller versions v6/v7) separates business logic into 7 Primary Core Domains encompassing 21+ Sub-services:

I. PPOB (Payment Point Online Bank) — 8 Sub-services

Handles automated utility billings and inquiries including PLN Prepaid (Tokens), PLN Postpaid (Bills), Telkom, PDAM (Water Utilities), BPJS (National Health Insurance), PGN (State Gas), Cable TV, and Postpaid Cellular Statements.

II. Ticketing Engine — 5 Sub-services

Manages real-time booking, seat inquiry, and ticketing pipelines for Bus, Shuttle, Train, Flight/Airlines, and Hotel bookings.

III. Transfer & Disbursement — 2 Sub-services

Transfer: Facilitates instant peer-to-peer ledger money transfers between agents, downlines, and Finnet networks.
Disbursement: Manages secure payouts and fund routing directly to national bank accounts.

IV. E-Money & Game Vouchers — 2 Sub-services

Processes instant top-ups for major digital wallets (E-Money) and digital game voucher distributions.

V. QRIS / QR Payment — 1 Sub-service

Handles instant dynamic/static QRIS Inquiry and Transaction settlement loops.

VI. Balance Management (Top-up & Withdraw) — 2 Sub-services

Manages atomic ledger balances for user deposits (Topup) and bonus/fund cashouts (Withdrawal).

VII. Cashless Ecosystem — 1 Sub-service

Integrates localized transaction loops tailored for school ecosystems and Learning Management Systems (LMS).

Database Optimization Note: At the data layer, products are highly indexed and classified utilizing a strict ProductType matrix (product_type_id: 1 for Pulsa, 2 for Data Packages, 3 for PLN Prepaid, 4 for E-Money, and 5 for Game Vouchers) ensuring optimal database lookup efficiency during high-concurrency transaction spikes.

2. Third-Party External API Integration Layer

Operating a robust payment gateway requires orchestrating communication with multiple external vendor endpoints. The backend securely connects with 10 External Domain Host APIs, managed via isolated environment configurations (config/env.rb, env.staging.rb, env.production.rb):

External Provider / ServiceDomain EndpointInfrastructure Purpose

Infobip API High-availability SMS & OTP Security Gateway
Finnet / Finpay API Core Payment Gateway & P2P Settlement
Tiket.com API Real-time Train & Hotel Booking Aggregator
Aeroticket API Flight & Airline Ticketing Pipeline
Redbus API Inter-city Bus Ticket Reservation System
Indotama API Localized EDC, Train, & Ticket Processing
Onesignal API Async Multi-platform Push Notifications
SSO Weypay/Atozpay Centralized Single Sign-On Authentication
Cashless Portal Dedicated Cashless Campus/School Ledger
Atozgo API On-demand Hyperlocal Delivery & Order Service

3. High-Volume Production Metrics & Validation

The architectural design choice to cleanly separate business domains and map them against optimized external API abstractions was validated by real-world high-traffic data:

User Scalability: The architecture fluidly onboarded 11,234 total registrations (8,555 business agents and 2,679 regular users) within a single month.
Transaction Throughput: Seamlessly processed over 181,870 transactions within October, translating to a Gross Merchandise Value (GMV) of Rp 8,679,478,985.
System Reliability under Load: On peak single-day stress tests, the system handled 6,431 concurrent transactional loops within a 24-hour window (amounting to Rp 365,478,291 in processed nominal value) with near-zero latency overhead.
Traffic Composition: The micro-transaction architecture smoothly prioritized high-frequency, low-latency traffic—allocating 80% volume (145,182 requests) to Mobile Top-ups (Pulsa) and 20% volume (36,688 requests) to heavy utility PPOB billing inquiries.

Technical Key Takeaways

Strict Domain Separation: Designing the application around 7 distinct Core Business Domains prevented data leaking across controllers and allowed the system to remain modular as new sub-services were added.
Robust External Service Integration: Abstracting the 10 third-party API gateways behind structured environment wrappers ensured absolute token rotation parity and secure payload parsing between sandbox, staging, and production environments.
Performant Ledger Management: Mitigated race conditions during concurrent atomic balance updates (Topup & Withdrawal) by deploying optimized ActiveRecord indexing patterns based on distinct product_type_id classifications.