What We Can Learn from WeChat Pay's Callback Retry Schedule

First published at: https://www.sunai.net/t/446

If you've integrated WeChat Pay, you know that after a successful payment, WeChat sends a "callback notification" to your server. But have you ever noticed how it retries that notification if your server doesn't respond or takes too long to process it?

There's quite a bit of thought behind WeChat Pay's callback mechanism, and it's worth borrowing for our own projects. Here's a quick overview:

How often does WeChat send callbacks?

WeChat doesn't send payment results just once and call it a day. It has a pretty persistent delivery schedule. If you don't respond, or your response doesn't meet its requirements (for example, it times out or has the wrong content), WeChat keeps trying like this:

0秒 / 15秒 / 15秒 / 30秒 / 180秒 / 1800秒 / 1800秒 / 1800秒 / 1800秒 / 3600秒

In plain English:

• The first notification is sent immediately,
• Another is sent 15 seconds later,
• Then another after 15 more seconds,
• Then one after 30 seconds,
• Then one after 3 minutes (180 seconds),
• After that, things get more relaxed: one notification every half hour (1800 seconds), 4 times in a row,
• Finally, one last notification after an hour.

That's 10 attempts in total. If you keep ignoring them (by not responding or using the wrong response format), WeChat stops trying.

Why does WeChat do it this way?

The idea is to be both fast and resource-efficient.

• It retries quickly at first, in case there's a temporary network glitch or your server briefly stalls.
• Later, it spaces out the retries to avoid wasting its own resources or constantly hitting your server. It's easier on both sides.
• If it still can't get through, it won't keep hammering away forever. It caps delivery at 10 attempts, which is a reasonable effort.

Put simply, the schedule says: "I'll try hard at first, then ease off as time goes on."

We can borrow this approach for our own projects

This pattern of callbacks, multiple retries, and progressively longer intervals works well for all sorts of message notifications and asynchronous tasks:

• If you're sending users SMS messages, push notifications, or emails, or running asynchronous processing, you can use this "frequent at first, less frequent later" retry logic to handle failures.
• It keeps occasional network issues from causing tasks to fail outright and gives messages the best chance of being delivered!
• It saves resources and helps prevent excessive load.

For example, if you're building an order callback or an API for awarding points, you could do something similar: retry after 1 minute at first, wait 5 minutes after another failure, then try once more after 1 hour. Give up after a few unsuccessful attempts.

The key is to avoid an endless loop, or you might accidentally overload your own server.

Summary

WeChat's callback schedule isn't arbitrary; it reflects practical experience. We can borrow the same idea in our own development to build retry mechanisms that are reliable without being disruptive. It's especially useful for message notifications, automated tasks, and outbound notifications to external systems.

Next time you're deciding whether to retry and how often, don't just wing it. WeChat's approach is a solid reference!

And if a colleague asks, you can say: That's how WeChat does it too.