Designing a Dedicated Takeaway Callback Service for Chain Store Order Integration

This article describes a practical architecture for integrating multiple takeaway platforms (Meituan, Douyin, JD Daojia) into a chain‑store order system. All platform callbacks are routed to a separate microservice named service‑take‑away , which centralizes signature verification, parameter parsing, persistence, and synchronization with the main order domain.

Why isolate the callbacks?

Each platform defines its own callback fields, signature algorithms, and status codes, and they may change independently of the merchant’s system. Embedding this logic in the core order service would expose the internal domain to frequent external changes, increasing risk. By keeping the external handling in service‑take‑away, the core order domain only interacts with internal APIs.

Order types in a chain‑store system

POS (offline) orders

Virtual orders

Takeaway orders, further split by channel (Meituan, Douyin, JD Daojia, etc.)

Group meals

拼单 (combined orders)

Other external orders

All these are eventually unified under a common order model in the order center.

Callback types and handling

Order push (paid) – /paid: store order, print receipt, sync finance; must return quickly and process asynchronously.

Delivery status – /delivery: update status and timestamps; synchronous handling.

Order cancellation – /cancel: issue refund, notify POS; printed and unprinted orders have different logic.

Full refund – /full/refund: record refund information; synchronous.

Partial refund – /part/refund: refund per SKU; ensure no duplicate refunds.

Urge order – /urge/msg: record urge information; synchronous.

Keeping this table as a reference helps avoid missing scenarios when adding new platforms.

Signature verification

All callbacks carry a signature field. Meituan’s algorithm concatenates the request URL, all parameters sorted by key, and the APP_SECRET, then applies MD5. Douyin and JD Daojia use different schemes, but service‑take‑away adapts each in a platform‑specific controller layer. Invalid signatures are rejected immediately.

A subtle decoding issue exists for the detail field, which contains a JSON string URL‑encoded. The + character inside the JSON must not be replaced by a space, otherwise FastJSON parsing fails. The correct handling is:

String decoded = "detail".equals(name)
    ? URLDecoder.decode(value, "UTF-8")
    : URLDecoder.decode(value, "UTF-8").replace("+", " ");

Idempotent processing

Platform callbacks may be retried if the merchant’s response times out. To prevent duplicate order insertion, the production system uses a Redisson distributed lock with a 10‑second expiration:

RLock lock = redissonClient.getLock("orders:mt:" + orderNo);
if (lock.isLocked()) {
    return null;
}
boolean saved = save(mtOrder);
if (saved) {
    lock.lock(10, TimeUnit.SECONDS);
}

The lock covers the whole insertion flow, handling both "already processing" and "duplicate insert" cases, which a simple database unique index cannot fully address.

Order push processing chain

When a user places and pays for an order on a takeaway platform, the platform pushes a payload containing order details, items, address, and amount. The service performs the following steps:

Parse the order payload.

Persist item and extra‑ingredient details.

Generate product serial numbers.

Save promotional information.

Call the main order service API to create a unified order record.

Confirm the order with the platform (e.g., Meituan’s confirmOrder) if the status is not POI_CONFIRM.

Push the order to the POS service for printing.

Printing and notifications are asynchronous: printing uses an async method, while financial and membership notifications go through a message queue. Fast responses are required because platforms will retry on timeout, and retries can clash with the distributed lock.

Key takeaways

The sole purpose of service‑take‑away is to absorb all protocol differences of external takeaway platforms, allowing the core order domain to remain stable and unaware of external changes. Proper signature verification and idempotent handling are the two non‑negotiable foundations; without them, duplicate orders or forged callbacks become serious risks.