Introduction
First, let’s take a look at an overview of cashless payments. Over the last few years, the opportunities for “cashless payments” to be used daily have skyrocketed.
The Ministry of Economy, Trade, and Industry are supporting the use of cashless payments in society by formulating “Cashless Vision” and “API * Guidelines for Credit Card Data Usage” in April 2018. You can see that promoting a cashless society is expected to lead to the revitalization of the Japanese economy.
API = Application Programming Interface
Against this backdrop, cashless payment systems are predicted to become more overall in Japan, where digital transformation (DX) is advancing, and the development of related systems is accelerating rapidly.
However, as you all know, at the same time, reports and reports on accidents, troubles, and problems related to cashless payments continue. It seems that there are many people involved who say, “Something happens in the cashless system.”
Therefore, this time, we will introduce “a certain case” of a problem that may occur in the development of a cashless payment system, which is pointed out by software testing experts, by dividing it into “payment system” and “point recovery system”.
2. Problems with cashless payment systems
First, let’s take a look at an overview of cashless payments.
Cashless payments are broadly classified into three categories: (1) prepaid (prepayment), (2) real-time (immediate payment), and (3) postpay (postpay) when payments occur. Other tools used for cashless payment may be divided into smartphone payments and card payments. There are also contact types, non-contact types, and classifications by the provider.
(Example of classification)
| When payments occur | Service case |
|---|---|
| Prepaid | Electronic money (transportation / distribution) |
| Real-time (immediate payment) | debit card |
| Postpay | Credit card / e-commerce |
The feature of the cashless payment system is that it is not completed by one company, and the payment company and FinTech (Finance Technology) company are operating in cooperation with API. Therefore, it is said that the system and development system often have a complicated structure.
This time, we classify the problems that may occur in the development of cashless payment systems into “payment system” and “point return system”.
The “payment system” here is a system that withdraws money when cashless payment is “pip”. The “point redemption system” is an event or service that triggers a purchase behavior and grants point when it is determined that the content meets the conditions of the campaign. The flow is as follows: payment system → point redemption system.
2-1. Examples of problems with cashless payment systems (1) -For payment systems-
Cases where you have money but cannot pay on the due date
This is a problem that users who mainly use post-pay (post-payment) cannot pay even though they can pay.
Cause
Database registration timing deviation. The data at the time of purchase could not be registered normally, or the registration timing was different, so there is a problem in the subsequent processing.
Points to verify
The important point is to make sure that the purchase data is properly registered.
Preventive measures
It is necessary to guarantee “idempotence” at the time of development so that duplicate data will not be sent. If idempotency is not guaranteed, problems such as being able to cancel twice may occur.
Since these problems are likely to occur when communicating with the outside via API, it is important to carefully verify the cooperation status with the external system and service that goes through when using the payment system. ..
Cases where unintended amounts are withdrawn
In cashless payment, when you make a “pip”, a telegram with parameters such as user ID, payment, and currency used is instantly sent to an external service via the API. .. If you make a mistake in this setting, problems such as the unintended amount being deducted may occur during development.
Cause
There is a discrepancy in the contents of the telegram between the sender and the receiver. Inconsistencies occur when a telegram that is different from what the recipient expects is sent. This is a problem that often occurs when conducting connection tests between two developing companies. It is often caused by a setting error, and in a sense, it is a human defect.
Points to verify
It is important to think that something will happen when conducting a connection test with an external company, and to carry out the test with a margin. Since it is a problem that is likely to occur, it is also important to consider countermeasures in advance as possible problems.
Preventive measures
In cashless payment, the main process is to exchange telegrams from the “pip” at the time of purchase, so troubles such as data mismatch tend to occur. Since this discrepancy is a fraudulent transaction, it is normally played by the system, but if it is not processed, it will lead to problems such as an incorrect withdrawal amount.
To prevent this, it is important not to finish the test by yourself, but to have a good understanding of the outside. Verification such as looking through a case with an external company is also required.
Before the production, it will be necessary to have a temporary message created in the test environment, receive it, and check whether it works correctly when the API response is returned. If possible, you can prevent troubles by making detailed verification, such as simulating “one-stop communication”.
Cases where problems occur due to problems specific to smartphone terminals
In cashless payment, a phenomenon (problem) may occur in which the operation stops when operating an application, etc. on a specific client (smartphone) model.
Cause
In many cases, it is caused by a function or defects specific to the client terminal. It will be a trouble that you can not settle as an individual problem, not as an overall problem. You may also see a trend to have issues with certain working systems and devices.
Points to verify
It is said that it is quite challenging to detect and it is hard to predict the happening of a problem. The only way to verify it is to test it before release with as many test machines as possible.
However, it is not possible to check all models, so it is necessary to test at least for each version of Android and iOS. At this time, it is important to test in advance even models that are likely to have problems and popular models that are sold in large numbers.
Also, the screen display may “collapse”, so be sure to combine and verify “OS ✕ terminal type ✕ screen size”.
Preventive measures
Since it cannot be tested on all models and all environments, performing as many verifications as possible will help prevent problems. It is also effective as a preventive measure to identify terminals that have special movements or terminals where problems are likely to concentrate in advance and add them to the test environment.
2-2. Example of a problem with a cashless payment system (2) -In the case of a point redemption system-
Cases where behavior after point confiscation is not taken into consideration
Points will be forfeited if payments that meet the conditions for participation in the campaign occur, points are awarded, and the original payment is canceled. It should not be counted as the number of times it has been redeemed because it has been confiscated even if the points are redeemed once, but there may be omissions in consideration of the behavior after confiscation, such as counting.
Cause
It seems that it is often caused by an architect’s mistake, deletion of consideration, or omission of performance due to forgetfulness even if it meets the conditions.
Points to verify
Considering that it is common for users to cancel after payment, the minimum point of view is to constantly check both the behavior of point awarding and forfeiture even if there is no new implementation function.
Regarding the behavior after confiscation, for example, the action to restore the number of reductions, it is important to consider the scenario that can occur due to confiscation and to be careful as one with grant and confiscation. Assuming that such a problem will occur in advance will also lead to countermeasures.
Preventive measures
When implementing a new movement, make sure that there are no logic leaks, and that the execution policy is firmly determined by the development team.
As a preventive measure, thorough coordination of specifications and implementation policies, behavior after point confiscation, behavior after reaching the upper limit of return, etc. are assumed for all use cases, and all concerned parties are concerned about it, and recognition of acceptable cases is matched. It is possible to do this.
Cases where points have been given to people who are not eligible for the campaign
Due to the excess or deficiency of data in the table that summarizes the information necessary for each user to determine whether or not they are eligible for the campaign, points may be returned to those who are not eligible.
Cause
Incorrect data (list). Most are artificial. In some cases, old user data may be leaked when updating the data table. It is recognized as a problem that can occur not only in cashless payments but also in other genres.
Points to verify
Even if the system is operating properly, it is a problem that occurs because there is excess or deficiency in the data in the table, and in a sense, it can be said that there is no way to prevent it. If you disregard the cost of testing, it is possible to take measures such as bringing the production data to the verification environment so that not only the team like the data analyst but also the tester can verify it. ..
Preventive measures
It is important to check not only whether the table is updated correctly, but also whether the data existing in the table is sufficient in the first place. In addition, the best preventive measure is to create an environment that can be verified using the same data as the actual product as much as possible without incurring costs and to perform the maximum checks.
The case where the display/operation of the LP (Landing Page) of the campaign does not go as intended
When sorting out the content according to the user’s condition on the campaign page or LP, problems that are not intended by the specifications may occur. For example, it is a bug that the lead wire to move to the next step is not displayed to the user who has confirmed the identity, or the display prompting the identity verification is displayed again.
In addition, the intent of the campaign may not be communicated to the user, or the meaning may be lost due to typographical errors.
Cause
Suspicious behavior is often attributed to engineer mistakes. In the case of the notation, it seems that it often occurs as an implementation omission or an implementation defect because the requirement for sorting was not correctly communicated to the members.
Points to verify
Most of these problems are “look at the screen and read and understand”, and most of them seem to be able to be dealt with before the release because of the omission of the specification check. The QA (Quality Assurance) department and personnel who guarantee the overall quality of the development are the last bastions. The point is to spare no effort in checking with the QA staff.
Preventive measures
When the specifications of the campaign are finalized, it is a preventive measure to hold a spec review meeting, etc. before entering the implementation phase and make the members aware of each other. Depending on the company, the legal department or customer support department may add reviews to the campaign outline and precautions, but there may still be omissions.
Since campaigns are often carried out continuously, it is effective to check the specifications repeatedly even if you do not have time.
3. Be careful here! About the entire development of the cashless payment system
The causes of problems that are common in the development of cashless payment systems can be broadly divided into (1) external factors and (2) omission of specification checks. It is a development that is at the forefront of the times, but surprisingly, it seems that defects such as “missing checks” are often caused by analog causes.
(1) External factors
Since cashless payment systems are basically realized by cooperation between payment companies and companies using APIs, there are many cases where problems occur when communicating with the outside. On a media basis, in 2020, cases such as “implementation error of communication processing of gateway system”, “authentication failure”, and “problem that information is not reflected in information management system” are reported.
If there is an external factor, it often leads to big trouble. The API that supports the cashless payment system communicates, but the people who develop it also exchange development information, that is, “communication”. To operate the API correctly, the specifications and their confirmation are the most important, and it seems that the point at the time of development is not to finish the test by ourselves, but to firmly match the recognition with the outside.
(2) Missing check of specifications
As I mentioned earlier, surprisingly, it seems that there are many cases where problems are caused by basic mistakes such as missing specifications. Fortunately, it seems that we are often able to deal with it before it is released, but there is a negative effect that it causes a loss of time, etc., and reduces the efficiency of the entire development.
When changing logic, there can be differences between pre-release and post-release issues that can cause problems. It’s a good idea to review the whole thing from the perspective of whether there are any differences before and after the release.
In particular, if you hold a campaign using the point redemption system, the interest of users will increase at once. The company that provides the service will also increase the number of active users, and it will be a high-impact event where a large number of funds will move, so careful logic checks and verification are essential.
If points are given to customers who are not eligible, the service provider will waste money. In addition, if points are not awarded to customers who are eligible for the campaign, inquiries will be concentrated on customer support, and there is a disadvantage that costly work such as dealing with them and manually awarding points after the fact will occur.
It is true that cashless payments, which continue to grow rapidly, require an extraordinary sense of speed in development, but it is necessary to go back to the basics and confirm the specifications firmly. It may be “rush around”.
In conclusion
With the support of the government, the development of a cashless payment system will become more and more important in the future. High-quality service can be realized by being aware of the occurrence of defects in advance. For that purpose, it is important to repeat the test systematically by checking the specifications and seeking advice from test professionals.
It is also important to have a “user’s perspective” only on systems that often come into contact with users. It may be the most important thing to develop with the first consideration not to damage the user.
This time, we have introduced some “common problems” in the development of cashless payment systems. I hope this article has helped you a little.
If you ever want to know about similar things, check out the Facebook page Maga Techs.
