How We Built a Scalable Reverse Transaction System for E‑Commerce

Background and Motivation

E‑commerce platforms generate many reverse‑transaction scenarios (order cancellation, after‑sale refunds, etc.). The original implementation bundled all reverse‑transaction logic in a shared JAR used by both C‑end and B‑end systems, causing documentation gaps, duplicated and tightly‑coupled code, and high coordination cost across teams.

Design Goals

Create a dedicated reverse‑transaction microservice to decouple refund logic from customer‑service, after‑sale, four‑end and payment systems, and expose its APIs via an interface platform.

Extract common cash‑and‑promotion reversal capabilities into a reusable domain service and use a workflow engine to make refund approval extensible.

Definition

A reverse transaction orchestrates the refund of cash and all promotional incentives for an already‑paid order.

Construction Approach

Boundary Governance: Analyse existing reverse‑transaction processes, code, and online issues; then encapsulate the domain in a microservice to improve reuse and reduce complexity.

Minimum Viable Delivery Unit: Split the project into phased deliveries, prioritising high‑value units such as the core refund capability.

Architecture Design

Modeling Phase: Conduct event‑storming workshops to agree on a shared domain model. Define domain capabilities (refund, refund query, refund calculation, order cancel, package cancel) and corresponding events (refund approved, refund succeeded, refund failed).

Implementation Phase: Adopt a classic four‑layer architecture (presentation, application, domain, infrastructure) within the defined business boundaries.

Key Application Scenarios:

Pre‑shipment customer cancel

Post‑shipment direct refund

Post‑shipment receipt‑then‑refund

Customer‑initiated direct refund

Pre‑shipment package cancel

Pre‑shipment user cancel

Post‑shipment refusal refund

Price protection

Return shipping fee

Customer‑service compensation refund

Channel refund

Channel compensation refund

Reward‑fund debt refund

Points debt refund

Core Process Design

Refund Approval (Extensible)

Manual approval reduces complaints and financial loss while providing a safety net for automated decisions. The workflow engine Activiti was chosen because it is open‑source, decouples refund creation from execution, matches the team’s expertise, and offers sufficient node granularity.

Refund Processing Flow

Two execution paths are defined:

Refund Execution: Handles regular refunds such as order cancel, package cancel, and after‑sale returns.

Compensation Refund Execution: Handles exceptional refunds like price protection and after‑sale compensation.

Both paths are orchestrated by Activiti without further node splitting to keep the design lightweight.

Maximum Refundable Amount Model

The system calculates the maximum refundable amount per order item; any request exceeding this amount is rejected, protecting against cash loss.

Special Refund Flows

For exchange orders, a new order is created for the replacement item while cash and promotions remain linked to the original order. Deposit‑purchase orders consist of a deposit order and a tail‑payment order; refunds must reverse cash and promotions across multiple payment records.

Message Handling

Non‑critical calls are decoupled via MQ. To further isolate business logic from message production, Guava EventBus is used, allowing observers to handle side‑effects independently.

Results

After migration to the microservice, refund, order cancel, and package cancel capabilities reduced operational effort by over 80% and lowered new‑feature integration cost by more than 50%. Ongoing work includes implementing refund query and calculation services to further improve efficiency.