In earlier articles, I introduced how to build Alipay and WeChat Pay integrations in WordPress. Those articles explained how to handle the synchronous return flow, but they did not cover asynchronous payment notifications. Without asynchronous notification handling, the implementation is incomplete. If the user finishes payment and closes the payment page before returning to the original site, the merchant site may never receive the result through the normal return flow.
This article focuses on the missing part: adding proper asynchronous notification handling on the payment-initiating site.
The similarities and differences between asynchronous and synchronous notifications
The response data returned by synchronous and asynchronous notifications is basically the same. The main differences are these:
- Synchronous return data arrives through a
GETrequest, so it is easy to inspect directly through$_GET. - Asynchronous notifications arrive through a
POSTrequest, so debugging is less convenient and the payload often needs to be logged or saved before inspection.
Once those differences are clear, the handling logic becomes easier to understand. The business rules are mostly the same. The biggest difference is simply how the notification data arrives.
Important details when processing asynchronous notifications
Whether the notification is synchronous or asynchronous, the payment site usually performs the same order-processing logic after the payment is confirmed. Following the DRY principle, it makes sense to merge the two code paths and only branch where Alipay and WeChat Pay actually differ.
The following example shows how to get the order number from different notification sources. If the notification is synchronous, the order number can be read from $_GET. If the notification is asynchronous, Alipay data comes from $_POST, while WeChat Pay sends XML that needs to be converted before reading the order number.
/**
* Get out_trade_no from the payment gateway callback
*/
if ( $notify == 'return' ) {
$out_trade_no = $_GET[ 'out_trade_no' ];
} else {
if ( $method == 'alipay' ) {
$out_trade_no = $_POST[ 'out_trade_no' ];
} else {
$out_trade_no = Helper::xml2array( file_get_contents( 'php://input' ) )[ 'out_trade_no' ];
}
}Once the notification has been verified successfully, the merchant site should return a success string to the gateway. Otherwise the payment platform may continue retrying the same notification.
if ( $response->isPaid() ) {
if ( $notify == 'notify' ) {
echo 'success';
}
}With asynchronous notification handling in place, the payment integration becomes much more complete. Even if the user closes the payment page immediately after finishing payment, the merchant site can still determine the correct order state and continue with follow-up actions such as marking the order as paid or triggering delivery logic.
The real focus of Alipay and WeChat Pay development
In practice, the API integration itself is not the most important part of payment development. The gateway-side rules are relatively fixed, and once you understand the notification mechanics they do not change very often. The real complexity lies in the business logic that runs after a payment succeeds.
Because payment systems involve real transactions, that post-payment workflow needs to be designed with extreme care. Think carefully about repeated notifications, edge cases, retries, and possible failures so the final behavior remains safe and reliable.
