How JD.com’s Payment Platform Balances Speed and Accuracy: Architecture, High Availability, and Money Integrity

Introduction

In online cash transactions, even a one‑cent error can cause serious issues, so payment systems must prioritize accuracy and consistency. For an O2O e‑commerce platform where an order’s lifecycle is under an hour, any payment delay degrades service quality and reduces user demand.

1. Payment Platform Overview

The platform provides five core payment products: Cashier (multiple payment capabilities), Direct Pay (immediate payment activation), Withholding Service (recurring deductions), Pay‑on‑Behalf (friend payments), and Protocol Pay (quick pay, password‑less pay). Core functions are payment and refund, supporting scenarios such as deposit‑first payments and various refund types. Marketing capabilities (regional payment routing, coupons, interest‑free offers, discounts) are layered on top.

To accommodate diverse business lines (home delivery, rider services, fast delivery, etc.), the platform is designed for configurability, allowing per‑channel feature toggles and merchant‑specific configurations.

2. Fast Integration of Payment Capabilities

The integration flow hides third‑party payment complexities: after an order is created, the business line requests a payment link, receives an encrypted cashier URL, and the front‑end renders the H5 cashier page. Users interact directly with the payment system, bypassing the business service.

Key design goals are to shield business services from payment provider intricacies and to provide a seamless user experience.

3. Configurable Payment Methods

Payment methods are configured per channel; for example, high‑risk channels can be disabled, and each merchant may have distinct merchant IDs and fee structures on third‑party platforms.

4. Payment Order Lifecycle

A payment order can be processed from multiple devices and channels simultaneously, and both payment and refund traverse multiple systems (payment platform, third‑party providers, banks). The system must ensure strong consistency of monetary amounts across these asynchronous flows.

Four amount fields are recorded: receivable, received, refundable, and refunded. The invariant receivable + refundable = received + refunded guarantees correct amount changes.

To avoid over‑refunds, the system enforces that the actual received amount never exceeds the expected amount; any discrepancy triggers immediate investigation.

5. High‑Availability Practices

5.1 Classification

High availability is addressed at three levels: business‑level, disaster‑recovery level, and architectural level.

5.2 Real‑Time Guarantees

Online payments must complete within milliseconds; delays cause user complaints and potential loss of marketing incentives.

5.3 Deployment Isolation

Resources are partitioned between ToC (consumer‑facing) and ToB (business‑to‑business) workloads to prevent interference. CPU, thread pools, database connections, and GC pauses are carefully managed.

5.4 Multi‑Level Local Caching

High‑traffic SKU requests are first filtered by a Bloom filter in Redis, then cached in Caffeine for hot items, reducing Redis load and CPU usage.

5.5 Monitoring

Comprehensive monitoring spans machine metrics (CPU, memory, network, disk, container threads), application metrics (database/Redis/RPC errors, business‑level exceptions), and business metrics (payment, refund, marketing, notification) across horizontal and vertical dimensions.

Q&A Highlights

Delay queues are implemented with JD’s JMQ; RocketMQ also supports delayed messages.

To prevent duplicate payments/refunds, the system performs reconciliation on each notification and refunds excess payments.

Monetary values should use BigDecimal (or long representing cents) to avoid floating‑point errors.

At least two independent amount checks are required to guarantee correctness.

Payment amounts must always meet or exceed the receivable amount; over‑payments are handled by refunding the excess.

SKU cache uses Redis with Bloom filters and Caffeine for hot items; persistence is in MySQL.

Images