Evolution and Service Decomposition of Qunar's Payment System

Lu Bo, a R&D engineer in Qunar's finance division and a Jilin University graduate, introduces his work on the payment platform and its foundational services.

Since its inception in 2011, Qunar's payment system has transformed over five years from a single, high‑coupling monolith into a distributed architecture composed of numerous subsystems, supporting a wide range of transaction types, payment methods (bank cards, vouchers, coupons, points, etc.), and both non‑collection and collection scenarios, as well as multi‑order and multi‑payment flows.

1. Payment System 1.0 – In the early stage, business logic was simple and traffic low, so all functions were tightly integrated into one system to enable rapid development and deployment. The system comprised five key modules: cashier, transaction, payment, gateway, and accounting.

As business volume grew, the monolithic design revealed several drawbacks: poor fault isolation, limited scalability, high development cost, inability to accommodate complex new features, and blurred responsibilities among modules.

2. Payment System 2.0 – To address these issues, a service‑oriented decomposition was performed:

Gateway split : extracted the gateway as an independent foundational service, enabling better abstraction and independent evolution.

Accounting split : upgraded from simple transaction logging to a professional double‑entry accounting system.

Member system split : separated member‑related functions (balance, real‑name verification, asset management) into an autonomous service.

Base services split : consolidated common utilities such as security, signature verification, notification, and basic data queries into a shared service (e.g., the Talos system).

The decomposition follows the natural payment flow – order → transaction → cashier → payment → gateway → bank – allowing targeted splitting of each stage (excluding the external bank gateway).

Core components after splitting:

1. Transaction Core (Apollo) – Handles acquiring methods and various transaction types, including single and batch orders, direct, escrow, split‑payment, pre‑authorization, refunds, and more, supporting mixed transaction types and multi‑account settlements.

2. Payment Core (Minos) – Manages payment method combinations and execution, supporting bank cards, Alipay, WeChat, credit‑pay, vouchers, points, coupons, and more, with flexible composition rules (e.g., one bank card but multiple auxiliary funds).

3. Cashier (checkout) – Provides multiple front‑end variants (native app, web, PC, multilingual) to improve user experience and conversion rates.

4. API Access Layer – Exposes backend services via read‑write separated APIs (e.g., Ares for query services, Odin for write operations such as freeze, refund, cancel).

The overall architecture now consists of loosely coupled services, each responsible for a specific domain, resulting in higher resilience, easier scaling, and reduced development overhead.

The article concludes by noting that upcoming posts will discuss challenges encountered during the service split, including database handling, asynchronous processing, monitoring, and alerting.