LPG Self-Ordering

The Challenge: LPG tank shops face significant operational challenges: long customer wait times during peak hours create frustration and lost sales, high labor costs from maintaining multiple cashiers, vulnerability to fake transfer slip fraud that results in financial losses, and manual cash handling that increases errors and security risks. Traditional ordering processes require customers to wait in line, communicate with staff, verify payment manually, and wait for ticket printing—a time-consuming process that doesn't scale during busy periods. Shop owners struggle to verify QR payment transfers, often falling victim to fake screenshots or manipulated payment confirmations, leading to revenue loss and trust issues.

The Solution: I designed and built an automated self-service kiosk system that transforms the LPG ordering experience. Customers can independently browse available LPG tank sizes, select quantities, view real-time pricing and promotions, and complete purchases using either cash (via integrated cash dispensers) or QR payment through SCB Bank API integration. The system is built on top of the Cash Management Local System, leveraging its robust cash handling and transaction management capabilities. The kiosk automatically validates QR payments in real-time through SCB's secure API, eliminating fake transfer slip fraud. Automated ticket printing and transaction reporting provide shop owners with complete visibility into sales, payment methods (cash vs QR), and customer behavior. This solution reduces customer waiting time by 80%, eliminates the need for dedicated cashiers during peak hours, and provides fraud-proof payment verification.

System Architecture: Hybrid Cloud-Local Model

The LPG Self-Ordering system is architected as a kiosk application built on top of the Cash Management Local System, creating a layered architecture that maximizes code reuse and system reliability. The kiosk frontend is built with Next.js and TypeScript, providing a responsive touch-screen interface optimized for customer self-service. The backend leverages .NET Core for business logic and integrates with MongoDB for flexible product catalog, promotion rules, and transaction storage. The system communicates with the underlying Cash Management Local System via REST APIs, delegating all cash operations (dispensing, change calculation, inventory tracking) to the proven local system. This architecture ensures that cash handling remains secure and auditable while the kiosk layer focuses on customer experience and order management. The system operates in a hybrid mode: it can function independently for order processing and QR payments, while seamlessly integrating with the cash management layer when cash transactions occur.

Authentication & Authorization (OAuth + RBAC)

Authentication and security are implemented through multiple layers. The kiosk system authenticates with the Cash Management Local System using JWT tokens, ensuring that only authorized kiosk instances can request cash operations. For SCB API integration, OAuth 2.0 authentication is used to securely access SCB's payment services. Each API request includes encrypted credentials and request signatures to prevent tampering. The system implements role-based access control for shop administrators managing products, promotions, and viewing reports. Customer-facing operations require no authentication, but all transactions are logged with device identifiers and timestamps for audit purposes. Payment verification requests to SCB API are rate-limited and include retry logic with exponential backoff to handle network issues gracefully. This multi-layered security approach ensures that payment data remains secure while maintaining a frictionless customer experience.

Real-Time Data Pipeline & Consistency

The transaction data pipeline is designed for real-time processing and reliable reporting. When a customer completes an order, the system immediately creates a transaction record in MongoDB with order details (products, quantities, pricing, promotions applied). If the payment method is cash, the system calls the Cash Management Local System API to process the cash transaction, which handles dispensing, change calculation, and inventory updates. For QR payments, the system initiates a payment request to SCB API, receives a QR code for display, and polls the SCB API for payment confirmation. Once payment is verified, the transaction status is updated, a ticket is printed, and the order is marked as complete. All transactions are synchronized to a reporting database that aggregates data for analytics. The pipeline implements idempotency keys to prevent duplicate transactions if network issues cause retries. Background jobs process transaction data to generate daily reports, payment insights, and sales analytics. The system maintains a queue for failed operations (e.g., ticket printing failures, API timeouts) and retries them automatically, ensuring no transaction data is lost.

Database & Performance Optimization

The database architecture uses MongoDB for its flexibility in storing product catalogs with varying attributes, complex promotion rules, and transaction documents. Product collections are indexed on SKU, category, and active status for fast catalog queries. Transaction collections use compound indexes on (shop_id, created_at) for efficient time-range queries and (payment_method, status) for payment analytics. Promotion rules are stored as JSON documents, allowing complex conditional logic (e.g., 'buy 2 get 1 free on weekends') without schema changes. For reporting and analytics, a separate aggregation pipeline processes transactions daily, creating pre-computed summaries (sales by product, payment method breakdowns, peak hours analysis) stored in materialized collections. This design separates operational queries (fast, indexed lookups) from analytical queries (aggregated summaries), ensuring the kiosk interface remains responsive even during high transaction volumes. Connection pooling and query optimization ensure that the system can handle concurrent kiosk sessions without performance degradation. The MongoDB schema is designed to scale horizontally, supporting multiple shop locations with partitioned collections.