The personal collection mentioned in the title does not refer to the ordinary scan code, but to the kind that can support callback. For example, after the online mall pays, the mall can know the payment status and automatically modify the status of the order to "paid". This form of payment, whether it is WeChat, Alipay or UnionPay, is currently not open to individuals, and must have enterprise qualifications to apply. However, for many developers, it is sometimes a small verification application. If they want to have payment functions, but they do not have corporate qualifications, they naturally cannot apply for an interface such as WeChat Alipay, or even a third-party aggregate payment. (Ping++) is also unable to apply. This article introduces an idea of using personal Alipay (WeChat is also possible) to realize the payment function by yourself. The cost is an old Android phone , and the rest are completely free. With the payment code of Alipay (withdrawal is free), you can Do it at zero rate .
1. Basic idea
The basic idea of this solution is very simple, similar to the commonly used crawler to crawl web page billing data, but here we use a mobile app. Relatively speaking, it is simpler to intercept the push messages of the mobile app, and it does not need various anti-crawling measures that should be used for WeChat Alipay; but the disadvantage is that there is less information that can be obtained, and there is no information such as serial number and payer. There is only one amount.
So, our idea is:
- Create an order and display the QR code (either fixed or non-quota) to the user
- After the user pays, the merchant's mobile app receives a payment push from Alipay
- The Android App intercepts the payment push of Alipay, and then sends the payment information to the server
- The server determines which order is based on the payment amount, then marks the order as "paid", and then performs callback notifications as needed.
2. Key issues and their solutions
The key issues in this plan are as follows:
1. Alipay App notification interception
In fact, there are many solutions to this problem on the Internet. It uses NotificationListenerServicethis class in Android. By registering this Listener, when the push notification pops up, you can get the App, title, content and other information sent by it. What we care about most is the App and push content.
Judging that the package sent to the App is the Alipay package, and then obtaining the specific content from the pushed content, the payment amount can be obtained.
The sample code is as follows:
public class AlipayNotificationListenerService extends NotificationListenerService {
public AlipayNotificationListenerService() {
}
@Override
public void onNotificationPosted(StatusBarNotification sbn) {
// 这里可以拿到包名，可以按照需要判断。
String packageName = sbn.getPackageName();
Notification notification = sbn.getNotification();
if (notification == null) {
return;
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
Log.e("SevenNLS","in 1");
Bundle extras = notification.extras;
if (extras != null) {
// 这里是具体的title和content，可以从中提取金额
String title = extras.getString(Notification.EXTRA_TITLE, "");
String content = extras.getString(Notification.EXTRA_TEXT, "");
Log.d("Zachary", "title:" + title + " content:" + content);
}
}
}
@Override
public void onListenerConnected()
{
Log.e("Zachary","connected");
}
}
Of course, in order for the app to run smoothly, it is also necessary to give it permission to obtain notifications, to ensure that it is not cleaned up, etc., and some corresponding protection measures need to be taken.
2. Confirmation of order
As we said just now, after the server receives the payment information sent by the App, it needs to find the corresponding order. This step is relatively difficult, because we know that there may be many orders of the same amount. Which one is the order that has just been paid?
Here, we can think about it in detail. In fact, this order is not only determined by this amount, but is determined by a tuple. The simplest implementation is (order amount - payment status) . An order can be determined from this 2-tuple. The meaning is that if this order has already been paid, then when I look up the order, I can ignore it, I just need to find the order (specified amount - unpaid) .
This basically solves the problem. However, we consider that in addition to the normal payment, there may be other situations. For example, after a user creates an order, he suddenly does not want to pay, and does not perform the next operation. Or, someone maliciously creates a large number of orders on the website and does not pay. The consequence of this is that the status of these orders is always the same 未支付. When you want to continue to create orders, you will be restricted, and you cannot create orders with the same amount as these orders, otherwise your system will not be able to tell which one is which. The order was paid.
In order to cope with this situation, we thought that many payments are time-limited, that is to say, the order has an expiration date. Once the expiration date has passed, the order cannot be paid. Therefore, we can also add a valid time limit to the order, such as 5 minutes. Once it is not paid within five minutes, the order is considered to be invalid. At this time, the way of determining the order becomes a triple (order amount - payment status - expired or not) . When searching, you only need to find the order (specified amount - unpaid - unexpired) on it. That is to say, any order will only occupy this amount for 5 minutes at most. Once it exceeds 5 minutes, you can continue to create orders of the same amount regardless of whether you have paid or not.
However, we are still not satisfied with this, especially for some cases where the payment amount is relatively single, it may be necessary to create an order of the same amount every time. In this case, in the worst case, we can only process one order every five minutes. This efficiency can be said to be very inefficient.
Here, we propose a trade-off solution. General normal payment will not use this method, and it is difficult to accept, but for us, in order to avoid enterprise qualification certification and handling fees, it is acceptable to a certain extent.
This method is that when there is already an order of a certain amount in the system, if we want to continue to create an order of the same amount, then we will float up and down the specified amount , such as a penny, so that the amount will be It can be distinguished from the previous order to avoid the situation that cannot be paid at the same time. In this way, although we may have a certain loss in the case of high concurrency (the more people who pay at the same time, the greater the gap), our high concurrency requirements are met.
Friendly reminder: If the amount fluctuates, you can tell the user that this is a random instant reduction, which can avoid problems caused by the gap between the pricing and the actual payment amount to a certain extent. (In this case, you can only float down, not up, otherwise it will become a random increase).
3. Summary
Overall, I think this solution is an acceptable solution for ordinary individual users. Its advantages and disadvantages are summarized as follows:
advantage:
- No business qualification required
- no handling fee
- No operation on Alipay, no risk of risk control by Alipay
shortcoming:
- There needs to be a mobile phone running all the time, and the network conditions are required to be good, otherwise the payment data will be lost (there can be a manual solution)
- When there is high concurrency, the order amount will fluctuate
- If the amount floating strategy is unreasonable and the rules are discovered by others, property damage may be caused! ! (For example, a large number of orders are created in a short period of time, so that the order price will continue to drop, and precautions need to be taken against this situation)
Reference:
PaysApi: www.paysapi.com