Security threats are analyzed in the lifecyle of merchant-presented codes, which includes the following stages:

• Code storage
• Code processing
• Message transmission (Communication)

In addition to the threats, general guidelines are also provided in the Code Storage and code Processing stage to protect business security.

Overview

For merchant-presented codes, the code value are relatively open. You can see security threats for merchant-presented codes in the figure below:

Figure 4.2 Threats of merchant-presented mode

For each threat, a guideline is introduced for you to mitigate the threat.

Code storage

Threat:

1. Merchant-presented code is replaced. The merchant-presented code that the user scans is not a real transaction order code or merchant code, resulting in fraudulent transactions.
2. Merchant-presented code is modified. Key information, such as merchant information or transaction amount, is modified when the merchant-presented code is generated.

Guideline:

After scanning and parsing the merchant-presented code, the Digital Wallet app shall prompt key transaction parameters to the user for confirmation, including but not limited to merchant name.

General guidelines:

Acquirers should ensure that the barcode generated for the merchant and the corresponding collection account information are associated with the merchant.

Acquirers should remind the merchant to take actions to prevent the code from being overwritten or replaced, and regular check the integrity of the code.

Acquirers should have measures to monitor the code usage. If any code misuse is detected, Acquirers should suspend the code usage for the related merchant in time. The code should not be used in other places or for other business purposes. For example, when a merchant is registered as an offline merchant, the code applied should only be used in in-store payment scenarios and within the business scope this merchant registered with.

Code scanning and processing by digitial wallet app

Threat:

Merchant-presented code contains malicious code, which may be implanted into a user's mobile device. Attacker may obtain sensitive user information through phishing.

Guideline:

When consumers open a Digital Wallet app to scan and parse the merchant-presented QR code, the Digital Wallet app shall have security measures to verify whether the contents of the QR code are secure and valid, for example by identifying whether it contains malicious code or points to a phishing website. For QR codes with risks, risk management systems shall be available in the Digital Walletapp to handle risks, for example by prompting user of the risks and preventing malicious code execution.

App Client should comply with the security requirements defined in Client Software Security Requirements.

Threat:

User's sensitive data stored in App Client is stolen or disclosed. Attacker may use the stolen sensitive information to act as an legitimate user to login and initiate payment transactions from other devices.

Guideline:

App Client shall be able to check the login state. Code-scanning payment service shall only be available in App Client after the user has logged in.

App Client should comply with the security requirements defined in Client Software Security Requirements.

Threat:

Key transaction parameters are modified in App Client. Attackers may (or an user acts evil subjectively to) modify key transaction parameters, such as transaction amount and merchant information, for attacking purposes.

Guideline:

App Client should comply with the security requirements defined in Client Software Security Requirements.

General guidelines:

The merchant-presented code may be of a variety of types and issued from different issuing institutions. Acquirers should be able to identify the type and issuing institution of the codes to process the payment.

Acquirers should evaluate the transaction risk based on merchant information and bar code usage scenarios, and then set transaction limits accordingly, such as single or daily cumulative transaction limits.

During the validity period of the code usage, Acquirers should periodically verify whether the qualification of the merchant is still valid. If the qualification expires, Acquirers should suspend the code usage for the related merchant in time.

Code processing by the application server

Threat:

Vulnerabilities may exist in system security, such as physical security, host security, network security, and application security. Merchant or transaction information may be disclosed or modified.

Vulnerabilities may exist in data processing and transaction information on bar code application server. Merchant or transaction information may be disclosed or modified.

Guideline:

The application server should meet the security requirements as defined by local regulators for mobile internet servers.

Code processing by Payment Servers

Threat:

The user authentication mechanism is not strong enough. The real identity of the operator may not be correctly recognized by using weak user authentication mechanisms, especially for risk transactions, which may lead to user fund losses.

Guideline:

Switch and Digital Wallet's system should have risk management ability, such as identifying and managing risks based on account environment (IP, location, and so on), consumption habits, seller account characteristics, and user equipment.

Threat:

The risk management system is not effective enough to identify and prevent risk transactions. To ensure the overall transaction security, the back-end server should provide strong and comprehensive risk management capabilities.

Guideline:

Digital Wallet's system should have effective technical means to verify the user's identity.

Communication between the client and the server

Threat:

Man-in-the-middle attack. Attacker maliciously modifies the transaction parameters returned to clients from the application server, such as transaction amount and merchant information.

App Client should comply with the security requirements defined in Client Software Security Requirements.

Guideline:

After scanning and parsing the merchant-presented code, the Digital Wallet app shall prompt key transaction parameters to the user for confirmation, including but not limited to merchant name.

To ensure the confidentiality and integrity of the data in the transmission process, security methods such as digital signature and encryption should be adopted to protect the sensitive information enclosed in the transaction message.

Threat:

Disclosure of sensitive information during communications. Attacker eavesdrops on the communication channel to obtain sensitive data in the transmission of messages.

Guideline:

To ensure the confidentiality and integrity of the data in the transmission process, security methods such as digital signature and encryption should be adopted to protect the sensitive information enclosed in the transaction message.

Communication between clients and payment servers

Threat:

1. Man-in-the-middle attack. Attacker may modify transaction messages for attacking purposes.
2. Disclosure of sensitive data during communication. Attacker eavesdrops on the communication channel to obtain sensitive data, such as the user identification information, in the message transmission.

Guideline:

To ensure the confidentiality and integrity of the data in the transmission process, security methods such as digital signature and encryption should be adopted to protect the sensitive information enclosed in the transaction message.

Secure and reliable mutual authentication should be performed when establishing a connection between the app client and the server. The app client and the server should use security protocols and encryption algorithms with enough strength for secure and reliable data interaction. The security protocols should be updated to the latest and stable versions timely. For example, use SSL certificate and HTTPS protocol in the network communication.

Threat:

Replay attack. Attackers may replay a transaction request multiple times by using a previously successful transaction message.

Guideline:

The transaction message should contain dynamic parameters such as random number, time stamp, or one-time session token, to prevent replay attacks.

More information

In addition to these security guidelines, you also need to comply with other guidelines, requirements and recommendations. For more information, see General Guidelines, Requirements and Recommendations.