Why Do Payment Orders Disappear? Causes and Prevention Strategies for E‑Commerce

Why Do Payment Orders Disappear?

In e‑commerce, a "drop order" occurs when a user completes payment in the wallet, but the order status in the app remains unpaid.

We examine the complete payment flow:

User clicks pay in the app; client sends request to server.

Payment service calls third‑party channel and receives a URL.

Client launches the corresponding wallet app.

User completes payment in the wallet.

Wallet redirects back to the e‑commerce app.

Client polls the order service for status.

Payment channel callbacks the payment service with the result.

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

The order can be in several states:

Unpaid – before the payment service contacts the channel.

Paying – after the user initiates payment but before the final result is known; the system is in a “fog” state.

Success / Failure / Cancel / Closed – final result determined by the third‑party wallet.

Drop orders happen when the payment status is not synchronized in time.

Three typical causes:

Payment channel callback fails, so the payment service never receives the notification.

Payment service encounters an internal error and does not forward the status to the order service.

Client polling does not retrieve the updated status within its interval, so the user sees "unpaid".

Cause 1 is an external drop; causes 2 and 3 are internal drops.

How to Prevent Internal Drops

Server‑Side Measures

Ensure the payment service reliably notifies the order service, typically by:

Retrying synchronous calls when they fail.

Using reliable asynchronous messaging: the payment service publishes a "payment succeeded" event, and the order service consumes it, confirming consumption before completing.

Combining sync retries with async messaging greatly reduces internal drops. Distributed transactions are usually unnecessary.

Client‑Side Measures

After payment, the client polls the order status for a few seconds. If the status is not updated, the client may show "unpaid". The root cause is usually server‑side, so fixing server synchronization is essential.

Synchronization between client and server can be achieved by:

Polling with a countdown timer.

Server push (WebSocket for web, custom push for apps), though push reliability can be limited.

How to Prevent External Drops

The key is

主动查询

: instead of waiting for the third‑party callback, the payment service periodically queries the channel for the order status.

Scheduled‑Task Query

A simple approach is to run a scheduled job that scans "paying" orders and queries the channel until a final state is reached, then updates the order and notifies the order service.

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

Drawbacks: result is not real‑time, and frequent scans add load to the database.

Delayed‑Message Query

Instead of periodic scans, send a delayed message after payment initiation. The message queue holds the next query interval (e.g., 10 s, 30 s, 1 min, …). When the consumer processes the message, it queries the channel; if still pending, it sends another delayed message with the next interval.

<code>// Build interval queue
Deque<Integer> queue = new LinkedList<>();
queue.offer(10);
queue.offer(30);
queue.offer(60);
// … send delayed message …
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);
</code>

The consumer logic:

<code>@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(paymentStatusContext);
        if (PaymentStatusEnum.PENDING.equals(result.getPayStatus())) {
            // send next delayed message
            Integer delaySeconds = dto.getIntervalQueue().poll();
            long nextDelay = System.currentTimeMillis() + delaySeconds * 1000;
            Message next = new Message();
            next.setTopic("PAYMENT");
            next.setKey(dto.getPaymentId());
            next.setTag("CONSULT");
            next.setStartDeliverTime(nextDelay);
            next.setBody(toJSONString(dto).getBytes(StandardCharsets.UTF_8));
            producer.send(next);
            return Action.CommitMessage;
        }
        // update order status and notify order service
        return Action.CommitMessage;
    }
}
</code>

Delayed messages provide better timeliness and lower database pressure compared with scheduled scans, though they may require a commercial message‑queue service for flexible delays.

Conclusion

This article explained the "drop order" problem, its causes, and how to prevent it. Internal drops are rare; most issues stem from external drops. The essential solution is active querying, implemented either with scheduled tasks or delayed‑message queues.