Reconstructing Ctrip's Payment Engine: Architecture, Design, and Operational Practices

This presentation details Ctrip's payment engine reconstruction, describing the limitations of the legacy system, the new service‑oriented architecture separating payment planning and execution, channel‑specific services, the reconciliation system, and the operational measures taken to achieve high payment availability.

Qunar Tech Salon
Qunar Tech Salon
Qunar Tech Salon
Reconstructing Ctrip's Payment Engine: Architecture, Design, and Operational Practices

Speaker Hong Guangming, Development Director of Ctrip's Financial Business Unit, introduces the reconstruction of Ctrip's payment backend system.

The legacy payment platform, handling millions of daily transactions and trillions of annual transaction volume, suffered from lack of unified payment flow design, missing independent accounting system, heavy reliance on stored procedures, inflexible database design, and complex inter‑service call graphs that hindered new financial product development.

The redesign splits the system into two core services: a Payment Planning service responsible for request validation, acquisition, routing, risk checks, and plan generation; and a Payment Engine service that executes plans, connects to payment channels, and notifies results. Each payment channel (bank cards, third‑party services, gift cards, wallet balance, etc.) is encapsulated in an independent service.

The new architecture is illustrated with diagrams (images omitted here) showing a clearer, simpler call relationship compared to the old system.

A dedicated settlement reconciliation system matches funds settled through multiple channels against internal accounting records, automatically processing daily reconciliation for nearly a hundred channels, improving operational efficiency and ensuring fund safety.

To meet high stability requirements, Ctrip monitors payment availability (ATP) and improves it through architectural choices (order‑payment separation, asynchronous processing with automatic retries), technical measures (distributed services, high‑availability design, eliminating single points of failure), and operational practices (comprehensive monitoring, alerting, and rapid incident response).

The talk concludes with an overview of the payment engine reconstruction project.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

System ArchitectureOperationspaymentCtripreconstruction
Qunar Tech Salon
Written by

Qunar Tech Salon

Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.