Wechat Pay notification rules

After the user completes the payment, wechat will send relevant payment results and user information to the merchant, who needs to receive and process the message and return the reply.

In the interaction of background notification, if wechat receives non-standard response or time-out from merchants, wechat will consider the notification as a failure. Wechat will periodically initiate notification through certain strategies to improve the success rate of notification as much as possible. However, wechat does not guarantee the final success of notification. (notice frequency for 15 s/s / 30/10 m/s / 3 m 20 30 30 m/m/m/m / 60 m / 3 h / 3 h / 3 h / 6 h/h – a total of 24 h4m)

Two kinds of deduction stock mode

1. Inventory is deducted before payment (i.e., inventory is locked after placing an order), and the payment will be automatically cancelled when the order expires, and inventory will be rolled back

In this mode, oversold can be avoided, but orders to be paid will occupy the inventory in the uncanceled time cycle. The gap between placing orders and paying should be controlled within a short time cycle. When the callback is received after payment, only the order status needs to be modified

2. Inventory deduction after payment (i.e. inventory deduction after successful order and payment), order cancellation has no impact on inventory

In this mode, oversold may occur. When the system receives payment callback, it needs to check whether the inventory is still available. If not, it needs to design automatic refund or replenishment logic.

Order cancellations compete with callbacks

This scenario is the point in time when the order is about to be canceled, the user completes the payment, and when the system receives a callback, the order has been automatically canceled.

Under the two inventory modes, different processing:

1. Inventory deduction before payment

After the order is cancelled and the inventory has been returned, you can make two choices: 1, direct automatic refund, 2, check the inventory (inventory)–> deduct the inventory –> restore the order status,(inventory is insufficient)–> automatic refund

2. Inventory is deducted after payment

After the order is cancelled, the payment callback comes back, you can directly check the inventory according to the original logic to complete the order

Because some activities are rules that limit the customer’s status level or purchase times, the specific logic needs to be handled when a callback is received.

Transaction time conflicts with multiple callbacks

Ideally, after receiving the callback, we just need to consider basic items, order correlation, update order status, payment status, payment time, update product sales, style sales, and keep some valuable logs. But in normal scenarios, we need to do a lot of plug-ins, activities, statistics system data records, which inevitably need to increase the length of transactions and processing business time.

In some competitive scenarios, the transaction wait time in the callback exceeds the 15s wait time of our callback, and in extreme scenarios, the second or even third callback comes back before the transaction of the first callback has finished, we need to lock to ensure atomicity of the business


      
  // Check whether there is a lock
  if(Cache::hasLock($orderNo)) {return;
  }
	Db::beginTransaction();
  try{
    // Lock the transaction
    Cache::lock($orderNo.60); . Db::commit(); }catch(\Throwable $e){
    Db::rollback();
    // Transaction failed to unlock
    Cache::unlock($orderNo);
  }finally{
    // No further action is required
    Cache::unlock($orderNo)}Copy the code

Here we have designed the lock time to be 60 seconds, but it will automatically unlock after normal completion or failure, but when there is a transaction longer than 60 seconds, it is time to consider the code and design issues.

The presence of extremely long transactions themselves is also a reminder to business organizations that we need to consider splitting long transactions here

1. It is necessary to ensure that key processes are not affected. Core businesses such as order status modification, inventory deduction and verification code entry must be timely carried out at the time of callback and cannot be affected by other minor business process abnormalities

2, split according to the module, but there should be a compensation mechanism

The order callback process often involves membership, distribution, events, statistics, settlement, warehousing and external plug-ins, which are independent of each other and can be considered as queued for consumption.

There is a risk of rollback in the transaction and no logic is allowed to send the queue until the transaction commit