What Is Mobile Payment and How Does It Work?

Introduction

Mobile payment is becoming the mainstream payment method around the world, and users can link bank cards to pay for goods and services through mobile phones. On the merchant’s side, mobile payment can be aggregated in the merchant's own app to provide efficient payment guidance and bill management.

In this article, I explain from a developer’s perspective how the mobile payment process works, what issues you might face, and how to mitigate potential risks.

Mobile payment process using the WeChat app as an example

The graphic above illustrates the process of a WeChat app payment:

1. The user enters the app to select a product for purchase. The user's system order (pending payment status) is generated at the time of internal settlement in the app. The order information and payment method list are returned at this time.
2. The user confirms that the amount is correct and selects the payment method. The app then passes the order ID and payment method to the server, and the server places a prepaid order in an external payment system based on the order amount and payment method, and returns the 'payment data' to the app that can evoke a response to the payment tool.
3. The app obtains the 'payment data' call response payment SDK (software development kit), and the user will see the WeChat Pay or Alipay payment page, at which point the user needs to confirm the payment amount and enter the correct password.
4. The SDK will check whether the user's password information is correct and return the payment result. The app receives the payment result of the SDK synchronization notification and submits it to the server. The server will record the status of the payment. Remember: the payment result uploaded by the APP cannot be used as the final payment result, and the front-end data cannot be trusted.
5. After the payment is processed, the external payment system will call back the callback interface set by the server to notify the server of the final payment status of the payment. When receiving a notification, you need to be aware of the following:
   • The same notification may be sent to the merchant system multiple times. The merchant system must be able to handle duplicate notifications correctly.
   • During the interaction of background notifications, if WeChat receives a response from the merchant that does not meet the specifications or times out, WeChat will determine that the notification has failed and resend the notification until it is successful, but WeChat does not guarantee that the notification will be successful in the end.
   • If the order status is unclear, or the merchant has not received the notification of the WeChat Pay result, it is recommended that the merchant take the initiative to call the WeChat Pay [Query Order API] to confirm the order status.
   • The merchant system must verify the signature of the content of the payment result notification and verify whether the returned order amount is consistent with the order amount on the merchant's side. This is done to prevent data leakage from causing "fake notifications" and causing financial losses.
   • When a notification is received for processing, the system first checks the status of the corresponding business data to determine whether the notification has been processed. Before performing state check and processing of business data, data locks should be used for concurrency control to avoid data confusion caused by function reentrant.

Potential issues with mobile payments

The above reflects the official process of WeChat and Alipay, and it is also the most standard process. When an external payment system is not as good as WeChat and Alipay, however, our system cannot operate normally according to the process that is shown above.

There are two key issues that may arise:

1. The server does not receive the callback of the payment result.
2. Even if you actively check the payment status, 'Bad Pay' still returns the unpaid status.

These two issues might lead to more complex problems:

1. Since there is no payment callback, the order status will not be sent, and the user will pay again, resulting in duplicate payment.
2. The system did not anticipate the occurrence of duplicate payments, and there is no strategy to compensate for it.
3. Since the system does not know that the payment has been successful, the user will not receive a refund when they cancel the order.

Steps to address potential risk

First, determine the payment channel that you need for your app:

1. WeChat app payment
2. Alipay app payment
3. PayPal
4. Other payment app

How to ensure a successful payment:

1. The callback notification after the external payment system is successful.
2. The system actively checks the order status of the external payment system.

How to avoid duplicate payments for users：

1. The system checks whether the 'order number' has a successful payment record when initiating the payment.
2. The system checks whether the 'order number' has been submitted to the payment record when initiating the payment, and whether there is a need to simultaneously query the payment status of the order in the external payment system.

How the system handles duplicate payments if a user experiences them:

1. The system needs to regularly check whether there are multiple successful payment records for the same 'order number' and if there is a need to keep one payment, the rest will be refunded.
2. 'Payment' is a record of a single payment. It may include the payment amount for multiple orders, because the user will split the order according to the merchant when the user generates an order for the purchase of goods.
3. 'Implication of payment and order' indicates all the order information in the payment. Each 'map' records the amount and payment status of the order, and the repeated payment also occurs on the 'map,' because an order intelligence has a record of the final successful payment. The map that is valid in the end is determined by 'whether it is currently used,' and only one map is valid for an order at any time.
4. 'Payment' may have multiple refund records. The total amount of the refund cannot exceed the payment amount. Each refund requires a unique refund transaction number to ensure that there will be no duplicate refunds, and the refund transaction number is generated by the specific business system (such as returns, cancellations, duplicate payments).
5. All refunds must be successful.
6. The system needs to actively check the payment status as 'initiating payment.' The payment status of 'app synchronization notification successful' is recorded in the external payment system. If the payment is successful in the external payment system, the payment status needs to be reset to 'completed.'
7. The external transaction number of the payment is unique to the refund transaction number of the refund.
8. To ensure the proper operation of the system, we also need some timers as a last line of defense:
   • Check the payment close scheduler.
   • Check the payment repeat scheduler.
   • Check the payment success scheduler.
   • Check the refund success scheduler.

Interface implementation

IPaymentApplicationService is the interface for your app to implement the payment feature. It provides some key functions:

1. Create payment: this method should be called after orders are generated. The payment result can include payment amount, payment time and current status.
2. Synchronized callback: this method should be called after a mobile accessed a payment channel successfully; it will help confirm the interim status of the payment record. Different payment channels provide different parameters.
3. Async callback: this method will receive the real status of the payment record, and it should be called after the payment channel sends a message to your backend server. Different payment channels provide different parameters.

Here's a code example of service interface that provides the payment methods:

Conclusion

Mobile payments can provide us with a more convenient payment method, but they are also more complicated to develop due to unreliable network transmissions. In business application software development, we usually support multiple payment channels for users to choose from, and we also need to consider how to protect and track data consistency in a distributed system.