How to Prevent Payment Order Loss (Drop Orders) in E‑Commerce Systems

Why Does a Paid Order Suddenly Appear Unpaid?

In e‑commerce, a "drop order" occurs when a user completes payment in their wallet but the order remains marked as unpaid in the app, leading to user frustration and complaints.

Payment Flow Overview

The typical wallet payment process includes:

User initiates payment from the app, client sends a request to the server.

Payment service forwards the request to a third‑party payment channel.

The app launches the corresponding wallet.

User completes payment inside the wallet.

Wallet redirects back to the app.

Client polls the order service for the order status.

Payment channel sends a callback to the payment service with the result.

Payment service notifies the order service to update the order status.

Order Statuses

Unpaid : Before the payment service contacts the channel.

Paying : Between launching the wallet and receiving the final result; the system is uncertain.

Success / Failure / Cancel / Close : Final state determined by the third‑party wallet.

Drop orders happen when the payment status fails to synchronize to the order service in time.

Preventing Internal Drop Orders

Server‑Side Measures

To ensure the payment service reliably updates the order service, adopt two complementary strategies:

Synchronous retry : When the payment service calls the order service, retry on failure to handle network glitches.

Asynchronous reliable messaging : After a successful payment, the payment service publishes a message; the order service consumes it and acknowledges only after updating the order status.

These sync‑plus‑async tactics greatly reduce internal drop orders. Introducing distributed transactions (e.g., Seata) is usually unnecessary.

Client‑Side Measures

After payment, the client polls the order status for a few seconds. If the status is still unpaid, it may be due to the server not updating promptly. Ensure the server pushes updates promptly, either via client polling or server‑push mechanisms such as WebSocket or custom push notifications.

Preventing External Drop Orders

External drop orders stem from third‑party channel issues and are more common. The key is active query: the payment service should proactively query the channel instead of waiting solely for callbacks.

Scheduled Task Query

Periodically scan payments that are still in the Paying state and query the channel for the final result, then update the order service.

@XxlJob("syncPaymentResult")
public ReturnT<String> syncPaymentResult(int hour) {
    // Query pending payments within the last 'hour'
    List<PayDO> pendingList = payMapper.getPending(now.minusHours(hour));
    for (PayDO payDO : pendingList) {
        // Actively query third‑party
        PaymentStatusResult paymentStatusResult = paymentService.getPaymentStatus(paymentId);
        if (PaymentStatusEnum.PENDING.equals(paymentStatusResult.getPayStatus())) {
            continue;
        }
        // Update payment record and notify order service
        payMapper.updatePayDO(payDO);
        orderService.notifyOrder(notifyLocalRequestVO);
    }
    return ReturnT.SUCCESS;
}

Drawbacks: query latency depends on the task interval, and frequent scans add database load.

Delayed‑Message Query

Instead of fixed‑interval scans, use a delayed‑message queue to query payment status with decreasing intervals (e.g., 10 s, 30 s, 1 min, …). When a payment is still pending, send the next delayed message; once a final state is reached, update the order.

// Build a queue of delay intervals (seconds)
Deque<Integer> queue = new LinkedList<>();
queue.offer(10);
queue.offer(30);
queue.offer(60);
// ... send first delayed message (10 s)
Message message = new Message();
message.setTopic("PAYMENT");
message.setKey(paymentId);
message.setTag("CONSULT");
long delayTime = System.currentTimeMillis() + 10 * 1000;
message.setStartDeliverTime(delayTime);
producer.send(message);

When the consumer processes a delayed message, it queries the channel. If the payment is still pending, it pops the next interval from the queue and schedules another delayed message; otherwise it updates the payment record and notifies the order service.

@Component
@Slf4j
public class ConsultListener implements MessageListener {
    @Override
    public Action consume(Message message, ConsumeContext context) {
        String body = new String(message.getBody(), StandardCharsets.UTF_8);
        PaymentConsultDTO dto = JsonUtil.parseObject(body, new TypeReference<PaymentConsultDTO>() {});
        if (dto == null) return Action.ReconsumeLater;
        PayDO payDO = payMapper.selectById(dto.getPaymentId());
        PaymentStatusResult result = payService.getPaymentStatus(dto.getPaymentId());
        if (PaymentStatusEnum.PENDING.equals(result.getPayStatus())) {
            Long nextDelay = dto.getIntervalQueue().poll();
            long delayTime = System.currentTimeMillis() + nextDelay * 1000;
            Message next = new Message();
            next.setTopic("PAYMENT");
            next.setKey(dto.getPaymentId());
            next.setTag("CONSULT");
            next.setStartDeliverTime(delayTime);
            next.setBody(toJSONString(dto).getBytes(StandardCharsets.UTF_8));
            producer.send(next);
            return Action.CommitMessage;
        }
        // Update payment status and notify order service
        // ...
        return Action.CommitMessage;
    }
}

Delayed‑message querying offers better timeliness and reduces database pressure compared with simple scheduled scans.

Conclusion

Drop orders—especially those caused by external channel failures—can be mitigated by actively querying payment status. Two common approaches are scheduled‑task polling and delayed‑message querying; the latter provides finer‑grained timing and lower DB impact.

Key term: active query Solutions: scheduled task query,

delayed‑message query