The personal collection referred to in the title is not the ordinary scan code, but that can support callback, for example, after the online mall payment, the mall can know the payment status and automatically modify the order status to “paid”. This form of payment, whether wechat, Alipay or UnionPay, is currently closed to individuals and requires enterprise qualifications to apply. But for many developers, sometimes is a small verification application, want to have payment function, and they do not have enterprise qualifications, naturally can not apply for wechat alipay interface, even the third-party aggregation payment (Ping++) can not apply. This paper introduces an idea of using personal Alipay (wechat is also available) to realize the payment function. The cost is an old Android phone, and the rest are completely free. With alipay’s payment code (cash withdrawal is free), you can achieve zero rate.

First, the basic idea

The basic idea of this scheme is very simple, similar to the common crawler used to crawl the webpage bill data, but here we use a mobile phone App. Relatively speaking, it is easier to intercept the mobile App push messages, and there is no need to take various anti-crawling measures for wechat Alipay; But the disadvantage is that we can get less information, no such information as serial number, payer, only one amount.

So, the idea is:

  1. Create an order and show the QR code (quota or non-quota) to the user
  2. After payment, merchants will receive payment push from Alipay on their mobile App
  3. The Android App intercepts Alipay’s payment push and sends the payment information to the server
  4. Based on the amount paid, the server determines which order it is, marks it as “paid,” and does things like callback notifications as needed.

Key issues and their solutions

The key issues in this plan are as follows:

1. Notification interception of Alipay App

This question actually has a lot of online solutions, the use of the Android NotificationListenerService in this class, by registering the Listener, can push notification pop up, get sent to the App, title, content and other information. What we care about most is apps and push content.

Determine that the package sent by the App is alipay’s package, and then obtain the specific content from the pushed content to obtain the payment amount.

Example code is as follows:

public class AlipayNotificationListenerService extends NotificationListenerService { public AlipayNotificationListenerService() { } @Override public void onNotificationPosted(StatusBarNotification sbn) { // Here you can get the package name, you can judge according to need. 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 ! 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"); }}Copy the code

Of course, in order for the App to work smoothly, it should also be given the permission to obtain notifications, to ensure that it is not cleaned, and so on, some corresponding protection measures need to be taken.

2. Order confirmation

As we said just now, after the server receives the payment information from App, it needs to find the corresponding order. This step is relatively difficult, because we know that there may be many orders with the same amount. Which one is the order just paid?

Here, we can think about it in detail. In fact, this order is not only determined by this amount, but by a multiple group. The simplest way to do this is (order amount – payment status). An order can be determined from this binary. The implication is that if the order has already been paid, then I can ignore it when I look for the order, I just need to look for the (specified amount – unpaid) order.

This will basically solve the problem. However, we take into account that there may be other scenarios beyond the normal payment. For example, after the user creates an order, he suddenly does not want to pay and does not proceed with the following operation. Or, someone creates a lot of orders on the site and doesn’t pay them. As a result, the status of these orders will never be paid, and when you want to continue to create orders, you will be restricted from creating orders of the same amount as these orders, or your system will not be able to tell which orders were paid.

In order to deal with this situation, we realized that many payments are time-limited, that is, the order has an expiration date, after which the order cannot be paid. Therefore, we can also add an effective time limit to the order, such as 5 minutes. Once the payment is not made within 5 minutes, the order will be considered invalid. At this point, the order confirmation method becomes a triplet (order amount – payment status – overdue). To find, you only need to find orders (specified amount – unpaid – not expired). That is, any order will only take up this amount for 5 minutes at most, and once you have exceeded 5 minutes, you can continue to create the same amount of orders, whether you pay or not.

However, we are still not satisfied with this, especially for some cases where the payment amount is relatively single. We may need to create orders of the same amount each time. In this case, we can only process an order every five minutes in the worst case, which is very inefficient.

Here, we propose a trade-off solution. This method is not acceptable for normal payment, but for us, it is acceptable to some extent in order to avoid the certification of enterprise qualification and commission fee.

This way in the current system is that it has a certain amount of orders, if we want to continue to create the same amount of the order, then we have to float on the specified amount, such as down a penny, this amount can distinguish and before the order, avoid the situation that is not at the same time pay. In this way, although we may have a certain loss in the case of high concurrency (the more people pay at the same time, the bigger the gap), our high concurrency requirements are met.

Tips: If the amount fluctuates, you can tell the user that it is a random decrease, which can avoid the problem caused by the difference between the price 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 vertical addition).

Third, summary

Generally speaking, I think this scheme is an acceptable scheme for ordinary individual users. Its advantages and disadvantages are summarized as follows:

Advantages:

  1. Corporate qualifications are not required
  2. No handling fee
  3. It will not conduct any operation on Alipay, and there is no risk controlled by Alipay

Disadvantages:

  1. Need to have a mobile phone always running, and the network condition is good, otherwise payment data will be lost (manual solution can be available)
  2. At high concurrency, the order amount will fluctuate
  3. If the amount of floating strategy is unreasonable, and is explored out of the law, may cause property losses!! (For example, create a large number of orders in a short period of time, so that the order price will continue to drop, need to take precautions against this situation)

Reference: PaysApi: www.paysapi.com