By continuing your navigation on our website, you consent to the use of cookies to provide you with better services. To learn more, read our cookies policy.
x
Search
APIs
Solutions
Partner
Support
Sign in
Search
International
中国站
Open API >Payment >UPI QR Code App Gateway
UPI QR Code App Gateway
Payment Developer Issuer Mobile Payment
UPI QR Code is a low-cost, convenient and secure payment solution. Through UPI system with APIs, mobile App providers outside of mainland China will be able to provide UPI QR Code payment service to their users.
Sandbox Testing
API Introduction
API Introduction
What is it?

UPI QR Code product can be integrated into mobile Apps to support a low-cost, convenient and secure innovative payment method, where consumers can either display a payment QR Code for merchants to scan (Consumer-Presented) or scan merchant's static/dynamic QR Code (Merchant-Presented) to enter payment amount.  

This set of APIs provide all the necessary functions, allowing mobile App providers to connect to UPI system and support UPI QR Code payment in both Merchant-Presented and Consumer-Presented mode.


Key Features

Cost-effective

UPI QR Code is a low-cost payment solution that can work on any smart phone with screen and camera, and on any mobile OS platform, including Android and iOS, with no reliance on mobile phone manufacturers for cardholders.


Security

Security is a basic requirement for payments. UPI adopts various anti-risk measures to ensure whole transaction’s safety, including CDCVM evolved from PIN or signature for user's authentication & verification, together with tokenization technology to avoid exposure risk of card or account info.


Interoperability

UPI QR Code is compatible with EMVCo standard, making it standardized and globally interoperable. 


Integrity

UPI QR Code payment sticks to four-party mode which is consistent with bank card transaction except for information interaction. UPI QR Code payment has a whole integrated business mechanism, risk control and techniques to assure cardholders' capital safety.


When to Use it?

When mobile App providers want to integrate UPI QR Code Payments function and connect to UPI system to provide QR Code payment service to their users.

Who Use it?
Mobile App providers outside of mainland China (Could be issuers, merchants, third-party payments companies and software developers)
Where to Use it?
This API is available globally except for mainland China
Things to Know

1. APIs in QR Code App Gateway include message flows and message requirements for mobile App gateway to support UPI QR Code payments, such as PAN enrollment, Account Verification, Token service, Lifecycle management of cards, etc. Please find 16 APIs in ‘APIs Included’ column. 

2. Mobile App shall support both Merchant-Presented and Consumer-Presented QR Code payments mode to work in different scenarios;

3. Mobile App that integrate UPI QR Code payment shall support both EMV mode (mainly used outside of mainland China) and URL mode (mainly used in mainland China)

4. Before using QR code payment service, mobile App shall guide users to link intra-bank/inter-bank UnionPay card in that App. Users provide card no. and pass cardholder identification and OTP verification to complete card registration. 

5. Customer-Presented QR Code: When consumer clicks “QR Code Pay” in the App main page, App will request both EMV QR code and URL mode barcode from UnionPay system and display them separately for merchant to scan. When App fails to detect consumer’s location, it shall allow users to manually switch the QR Code by clicking “Global QR Code” or “QR Code in China” at the bottom of the page.

6.Merchant-Presented QR Code: Merchant-Presented QR Code payment allows consumers to scan merchants’ QR code, then initiate payment in the mobile App. After completing transaction, both merchant and consumer will receive notification.

7.For encoding specification of consumer-presented and merchant-presented code, please refer to 'Documentation' column.


Flow Chart
Flow Chart

QR CODE App gateway.png
API Document
API Document
  • Pan Enrollment
  • Account Verification
  • Sending OTP
  • Token Provisioning
  • Token State Update
  • Cardface Downloading
  • Token Request
  • Token State Notification
  • Mpqrc Payment Emv
  • Trx Result Inquiry
  • Qrc Info Inquiry
  • Mpqrc Payment Url
  • Cpqrc Generation
  • Additional Processing
  • Additional Processing Result
  • Trx Status Notification
Interface description
The mobile application allows the user to scan or enter the details of existing cards in order to digitize these cards. The application gateway sends PAN_ENROLLMENT request to the UPI.
Request Method
HTTP POST
Request Parameter
Field name Identifier Type Length Request Default value Note
Message Information msgInfo object M-Must
Version Number versionNo ANS 5 M-Must
Message ID msgID AN 17-49 M-Must It is used to match a response to its request. The value must uniquely identify any message that the application provider initiates on any day. The value in the response must match the value in the request. Components: “A”+Wallet ID+serial code
Time Stamp timeStamp N 14 M-Must Format : YYYYMMDDhhmmss . The value in the response must match the value in the request. Example:"20170714235911". Format: YYYYMMDDhhmmss
Message Type msgType ANS 1-50 M-Must Valid Value: "PAN_ENROLLMENT".
Wallet ID walletID AN 8 M-Must The distinctive value associated to a wallet "00010344"
Transaction Information trxInfo object M-Must
Device ID deviceID ANS 1-64 M-Must The distinctive value associated to a device
Primary Account Number pan AN 48 M-Must Encrypted with the public key of the Encryption Certificate. Please refer to Encrypt sample code in Documentation
Risk Information riskInfo object O-Optional
GPS gps ANS 1-64 O-Optional Components: +(-) latitude/+(-) longitude "+37.12/-121.23"
SIM Card simCard array 1-200 O-Optional The mobile number of the SIM cards. The mobile phone may have more than one SIM card. 　
Application User ID appUserID ANS 1-64 O-Optional An alias for the application user ID. 　
User Enrollment Date usrEnrolDate N 6 O-Optional The date when the cardholder registers in the wallet. "161230" Format:(YYMMDD)
Card Number Capture Method captureMethod ANS 1-64 O-Optional Valid Values: "MANUAL" "NFC" "CAMERA" "UNKNOWN" "MANUAL"
IP Address ipAddress ANS 1-64 O-Optional The public network IP address of the device 　
Device Type deviceType ANS 1-20 O-Optional Valid Values: “MOBILE” Reserved Values: “WATCH” “PAD” “PC”
Device Score deviceScore N 1 O-Optional Valid Values: “1” to “5”;“5” indicates the device is very reliable, and “1” indicates the device is less reliable.
Certificate and Signature certificateSignature object M-Must
Application Signature Certificate ID appSignCertID AN 1-128 M-Must The serial number of the certificate. The application gateway uses the private key of this certificate for signature.
UMPS Encryption Certificate ID umpsEncCertID AN 128 C-Condition The serial number of the certificate. The application gateway uses the public key of this certificate for encryption.
Signature signature ANS 1-2048 M-Must Please refer to the Signature for details
Synchronous Response parameters
Filed name Identifier Type Length Request Default value Note
Message Information msgInfo object M-Must
Version Number versionNo ANS 5 M-Must Valid Value: "1.0.0"
Message ID msgID AN 17-49 M-Must It is used to match a response to its request. The value must uniquely identify any message that the application provider initiates on any day. The value in the response must match the value in the request. Components: “A”+Wallet ID+serial code
Time Stamp timeStamp N 14 M-Must Format : YYYYMMDDhhmmss. Format: YYYYMMDDhhmmss
Message Type msgType ANS 1-50 M-Must Valid Value: "PAN_ENROLLMENT".
Wallet ID walletID AN 8 M-Must The distinctive value associated to a wallet. "00010344"
Transaction Information trxInfo object M-Must
Device ID deviceID ANS 1-64 M-Must The distinctive value associated to a device. It shall be IMEI for Android mobile, and IDFV for iOS mobile.
Enrollment ID enrolID N 16 C-Condition It is used to match the message sets within an enrollment process. The Enrollment ID is populated by UnionPay system and shall be the same in all related messages: PAN_ENROLLMENT, ACCOUNT_VERIFICATION, SENDING_OTP, TOKEN_PROVISIONING, TOKEN_STATE_UPDATE. The value must be unique for each enrollment process..
Cardholder Verification Method cvm array 1-255 C-Condition Present if the Response Code is "00". List of the cardholder verification (CV) methods required. The mobile application shall collect these information from the cardholder. Valid CVs are : "expiryDate"; "cvn2"; "name"; "idType"; "idNo", "mobileNo". Note1:The "idType" and "idNo" shall be present together. Note 2: If no CV method is required, the object shall be "cvm": [ ] .
TNC ID tncID AN 1-20 C-Condition The unique identifier of Terms and Conditions (TNC) “TNC01”　
TNC URL tncURL AN 1-50 C-Condition The URL link displaying the Terms and Conditions 　
Message Response msgResponse object M-Must
Response Code responseCode AN 2 M-Must It contains a code that defines the response to a request. Please refer to the Response Code and Message for the valid values. "00"
Response Message responseMsg S 1-100 M-Must It contains the transaction result and the rejection reason if the transaction fails. The value of this field can be displayed on the mobile application to notify the consumer of the payment outcome. Please refer to the Response Code and Message for details. "Approved"
Certificate and Signature certificateSignature object M-Must
UMPS Signature Certificate ID umpsSignCertID AN 1-128 M-Must The serial number of the certificate. The UMPS uses the private key of this certificate for signature.
Signature signature ANS 1-2048 M-Must Please refer to the Signature for details
Sample code
Request code
Java Other 
public class PanEnrolV1 implements Participant {

    private static final Logger logger = LoggerFactory.getLogger(PanEnrolV1.class);
    
    @Autowired private UPIAppGwClientServiceManager UPIAppGwClientServiceManager;
    @Autowired private EnrolDataService enrolDataService;
    @Value("${appGw.encryption:true}") private boolean encryptionEnabled;
    @Override
    public void prepareAbort(Context context) throws Exception {
    logger.debug("prepareAbort");
    }

    @Override
    public boolean prepare(Context context) throws Exception {
        logger.debug("prepare");
        AppGwEnrolRequestV1 request = (AppGwEnrolRequestV1)context.get(AppGwContextKey.REQUEST);
        AppGwEnrolResponseV1 response = (AppGwEnrolResponseV1)context.get(AppGwContextKey.RESPONSE);
        // create UPI app gw request
        UPIAppGwEnrolRequestV1 UPIRequest;
        try {
            UPIRequest = createUPIRequest(request);
        } catch (Exception e) {
            logger.error("unable to create UPIRequest", e);
            return false;
        }
    //set CertificateSignature info in message and send to UPI app gw
    UPIAppGwClientResult UPIResult = UPIAppGwClientServiceManager.sendRequest(UPIRequest);
    if (UPIResult.hasError()) {
        logger.error("exception caught", UPIResult.getError());
        return false;
    }
    UPIAppGwEnrolResponseV1 UPIResponse = (UPIAppGwEnrolResponseV1)UPIResult.getResponse();
    if (UPIResponse == null) {
        logger.error("no response received from UPI app gw");
        return false;
    }
    if (UPIResult.hasValidationError()) {
        logger.error("invalid response " + UPIResult.getValidationResult());
        return false;
    }
    // update response
    updateUPIResponse(response, UPIResponse);
    if ((UPIResponse.getTrxInfo() != null)&&(request.getTrxInfo()!=null)) {
        String enrolId = UPIResponse.getTrxInfo().getEnrolId();
        String deviceId = request.getTrxInfo().getDeviceId();
        String pan = request.getTrxInfo().getPan();
        enrolDataService.add(enrolId, new EnrolData(pan, deviceId, enrolId));
    }
    return true;
}

    @Override
    public void abort(Context context) throws Exception {
        logger.debug("abort");
    }

    private UPIAppGwEnrolRequestV1 createUPIRequest(AppGwEnrolRequestV1 request) throws Exception {
        UPIAppGwEnrolRequestV1 UPIRequest = new UPIAppGwEnrolRequestV1();
        if(request.getTrxInfo() !=null){
            UPIAppGwTrxInfo trxInfo = new UPIAppGwTrxInfo();
            trxInfo.setDeviceId(request.getTrxInfo().getDeviceId());
            if (request.getTrxInfo().getPan() != null) {
                if (encryptionEnabled) {
                    String umpsEncCertId = UPIAppGwClientServiceManager.getUmpsEncCertId();
                        if (umpsEncCertId == null) {
                            logger.error("unable to encrypt cvmInfo: umpsEncCertId is null");
                            throw new Exception("unable to encrypt cvmInfo: umpsEncCertId is null");
                        }
    UPIRequest.getCertificateSignature().setUmpsEncCertId(umpsEncCertId);
    try {
        String encryptedPan = UPIAppGwClientServiceManager.encryptData(umpsEncCertId, request.getTrxInfo().getPan());
        trxInfo.setPan(encryptedPan);
    } catch (Exception e) {
        throw new Exception("unable to encrypt cvmInfo", e);
        }
        } else {
            logger.warn("no encryption of pan");
            trxInfo.setPan(request.getTrxInfo().getPan());
        }
    }
    UPIRequest.setTrxInfo(trxInfo);
}
    if(request.getMsgInfo() !=null){
        UPIAppGwMsgInfo msgInfo = new UPIAppGwMsgInfo();
        msgInfo.setMsgType(request.getMsgInfo().getMsgType());
        msgInfo.setVersionNo("1.0.0");
        msgInfo.setMsgId(request.getMsgInfo().getMsgId());
        msgInfo.setTimeStamp(request.getMsgInfo().getTimeStamp());
        msgInfo.setWalletId(request.getMsgInfo().getWalletId());
        UPIRequest.setMsgInfo(msgInfo);
    }
    return UPIRequest;
}

    private void updateUPIResponse(AppGwEnrolResponseV1 response, UPIAppGwEnrolResponseV1 UPIResponse) {
        if (UPIResponse.getTrxInfo() != null) {
            AppGwTrxInfo trxInfo = new AppGwTrxInfo();
            trxInfo.setDeviceId(UPIResponse.getTrxInfo().getDeviceId());
            trxInfo.setEnrolId(UPIResponse.getTrxInfo().getEnrolId());
            trxInfo.setCvMethod(UPIResponse.getTrxInfo().getCvMethod());
            trxInfo.setTncId(UPIResponse.getTrxInfo().getTncId());
            trxInfo.setTncUrl(UPIResponse.getTrxInfo().getTncUrl());
            response.setTrxInfo(trxInfo);
        }
        if (UPIResponse.getMsgResponse() != null) {
            response.getMsgResponse().setResponseCode(UPIResponse.getMsgResponse().getResponseCode());
            response.getMsgResponse().setResponseMsg(UPIResponse.getMsgResponse().getResponseMsg());
        }
    }
}
Response Code Reference
Response Code Reference
Response code Description
00 Approved
01 Please refer to the card issuer
02 Duplicated QRC transaction and expired QRC
03 Invalid merchant
04 Pending. Transaction result is unknown. Please check later.
05 Cardholder verification fails.
08 TSP error
12 Invalid transaction
13 Invalid amount
14 Invalid card number
15 No such issuer
21 Card status error
25 Unable to locate the original transaction
30 Message format error
32 Exceed OTP max tries
34 Fraud card
40 The transaction is not supported by the issuer. Cross-border QRC transaction is not applicable for the card
41 Lost card
43 Stolen card
51 Insufficient balance
54 Expired card.
55 User input invalid PIN or didn’t input PIN
55 Invalid device id
57 Transaction not permitted to cardholder or QRC transaction is not applicable for the card
61 Exceeds approval amount limit
62 Restricted transaction
70 Validation error from issuer
71 Issuer declined
72 Issuer verify mac failed
73 Enrollment not found
74 OTP expired
75 Invalid OTP
76 OTP not found
77 IDV not set
78 Duplicate request
88 Card already provisioned
89 Card profile not found
90 The system is in cut-off.
91 Issuer system error
92 Network error
93 Invalid enrol state
94 Duplicated transaction
95 Enrolment timed out
96 UnionPay system error
98 Timeout
99 Other error
A0 Signature verification fails.
Use Cases
Use Cases

More than 170 Apps, including Apps from 17 main banks and more than 110 regional banks , support UnionPay QRC payment. In South Asia, UnionPay QR code merchants have increased steadily.

案例.png
Getting Started
Getting Started

1. Data Elements and Message

Message Format

Messages exchanged between the application gateway and the UMPS shall be in the JSON data interchange format as defined in [RFC 7159].

Message Flow

The solid line in a Sequence Chart 's processing flow indicates that once the flow begins, the message is mandatory. The dotted line indicates that the message is optional or conditional.

Data Elements Dictionary

In each interface, Message Information ("msgInfo") shall always be present and be the first data object of all request and response messages; 

Transaction Information ("trxInfo") contains different data elements according to the Message Type. The Transaction Information may be present in a request message or a response message;

Certificate and Signature ("certificateSignature") Certificate and Signature shall always be present as the last data object of the request messages and response messages. Please refer to Security Requirement for details;

Message Response ("msgResponse") shall always be present in a response message:

• When it is an acknowledgement response, "responseCode”: “00” indicates the request message is well-received. The processing result will be sent in another message later. For example, the “responseCode” of the “ADDITIONAL_PROCESSING” indicates the application gateway has received the request from the UMPS. The result of “ADDITIONAL_PROCESSING” will be sent in the “ADDITIONAL_PROCESSING_RESULT” message.

• When it is a processing result response, "responseCode”: “00” indicates the request message is approved.

Please refer to Response Code Referrence for details.


2. APIs Included

UPI QR Code App Gateway 's 16 APIs can be categorized into following sets and their calling sequence can be found in Sequence Chart.

The set of Account Enrollment APIs performed by the mobile application:

• Pan Enrollment

• Account Verification

• Sending OTP

• Token Provisioning

• Cardface Downloading

• Token State Update


The set of Enrollment Notification APIs performed after mobile application has completed the account enrollment through its own network

• Token Request

 

The set of Token Life Management APIs used to change the Token state in UnionPay system

• Token State Notification


The set of Transaction Processing APIs

In a Merchant-presented QRC-based transaction, the Consumer can make a purchase in a mobile application by scanning the QRC displayed by the Merchant. In a Consumer-presented QRC-based transaction, the Merchant can make a purchase by scanning the QRC displayed in a Consumer mobile device. For encoding specification, please refer to Consumer-presented QR Code and Merchant-presented QR Code in this page. 

APIs included:

• Mpqrc Payment Emv

• Trx Result Inquiry

• Qrc Info Inquiry

• Mpqrc Payment Url

• Cpqrc Generation

• Additional Processing

• Additional Processing Result

• Trx Status Notification


Please be noted that only consumer-presented QRC-based transaction sandbox testing is available now.
Sequence Chart
Sequence Chart

Account Enrollment

The following figure illustrates the flow of account enrollment performed by the mobile application through UnionPay network.

绑卡.png


1. PAN_ENROLLMENT request 

The mobile application allows the user to scan or enter the details of existing cards in order to digitize these cards. The application gateway sends PAN_ENROLLMENT request to the UPI. 

a. Device ID is the unique identifier in the mobile handset, such as Android ID or IMEI number. 

b. Wallet ID is the identifier assigned by the UPI to identify the mobile application, as the Issuer may have more than one mobile application with different risk parameters for the tokens. 

c. PAN is the card number of the payment card 


2. PAN_ENROLLMENT response 

The UPI sends a request to Issuing Host to check the status of the physical card, and returns the result in the PAN_ENROLLMENT response with the following information: 

a. Enrollment ID is the unique identifier to keep track of this account provisioning process. 

b. List of CV is the list of account verification data to be captured from the Cardholder for verification of the identity of the Cardholder. 

c. TNC URL is a link of the Terms and Conditions (TNC) to be displayed to the Cardholder 


3. ACCOUNT_VERIFICATION request 

The mobile application will download and display the Terms and Conditions for the Cardholder to accept or decline. If the TNC is declined, the enrollment process will terminate. Otherwise, the mobile application will capture the Cardholder Verification Information that was requested from the UPI, and send them in the ACCOUNT_VERIFICATION request. 


4. ACCOUNT_VERIFICATION response 

The UPI can send these data to the Issuer to validate the Cardholder Verification Information captured from the Cardholder, and return the validation result in the ACCOUNT_VERIFICATION response message. If the OTP is required, the UPI will also inform the mobile application of the allowed OTP methods: 

a. SMS OTP 

b. Email OTP 

c. Call Center OTP 

d. Web Application OTP 


5. SENDING_OTP request 

The mobile application will display the allowed methods to the Cardholder. After the Cardholder chooses one, the mobile application will send SENDING_OTP message to the UPI, and the Issuer, or a processor on behalf of the Issuer, will send an OTP to the mobile phone number of the Cardholder. 


6. SENDING_OTP response 

The UPI will return the OTP length, expiry time, and maximum attempt number in the response message. If the Cardholder does not receive the OTP, the application can send another SENDING_OTP message to the UPI.

 

7. TOKEN_PROVISIONING request 

The Cardholder enters the OTP in the mobile application, and the mobile application will send it in the TOKEN_PROVISIONING request, along with the accepted TNCID. 


8. TOKEN_PROVISIONING response 

The UPI sends the OTP data for validation. If the validation is successful, the UPI will return the Token information to the application gateway. 


9. CARDFACE_DOWNLOADING request 

The mobile application can request to download the card face to display it to the Cardholder. 


10. CARDFACE_DOWNLOADING response 

The UPI returns the card face data and the recommended PAN location in the CARDFACE_DOWNLOADING response. 


11. TOKEN_STATE_UPDATE request 

After loading Token information and completing the mobile application offline configuration, such as Consumer device, Cardholder Verification method, transaction amount limit, etc., the mobile application will send the TOKEN_STATE_UPDATE request to activate the Token for use in the payment. 


12. TOKEN_STATE_UPDATE response 

The UPI returns the result and the latest Token state in the TOKEN_STATE_UPDATE response message, and the enrollment process is completed. 


Merchant-presented QR Code Payment (EMV Mode)

After the consumer scans an EMV standard merchant-presented QR code, the merchant information shall be displayed on the application. After the consumer input required information, such as amount, loyalty number, etc. and confirm a purchase, the mobile application will initiate a QRC payment message to request an authorization from issuer. The payment message can be a purchase message, authorization message, etc. The message flows are as follow.

主扫emv.png

1. The application gateway submits a MPQRC_PAYMENT_EMV request message to  UMPS (UnionPay Mobile Payment system).

2. The UMPS returns the transaction outcome to the application gateway in the MPQRC_PAYMENT_EMV response.


Exceptional flows: 

Application gateway: When the application gateway does not receive the MPQRC_PAYMENT_EMV response message within 65 seconds, the application shall initiate a TRX_RESULT_INQUIRY message to check if the payment is successful.


Merchant-presented QR Code Payment (URL Mode)

After the consumer an URL standard merchant-presented QR code, the mobile application will initiate a merchant information inquiry message to request the merchant name, merchant ID etc. Once the consumer confirms the payment, the mobile application will initiate a payment message to request an authorization from issuer. The payment message can be a purchase message, authorization message, etc. The message flows are as follow. 

主扫url.png

1. The application gateway submits a QRC_INFO_INQUIRY request to the UnionPay Mobile Payment System.

2. The UnionPay Mobile Payment System returns the merchant information details to the application gateway in the QRC_INFO_INQUIRY response. 

3. After the consumer confirms the payment and enters the transaction amount (if required), the application gateway submits a MPQRC_PAYMENT_URL request message to the UnionPay Mobile Payment System.

4. The UnionPay Mobile Payment System returns the transaction outcome to the application gateway in the MPQRC_PAYMENT_URL response message, and is responsible to notify the acquirer of the transaction outcome.


Exceptional flows: 

Application gateway: 

1. When the application gateway does not receive the QRC_INFO_INQUIRY response within 10 seconds, it may initiate the inquiry again. 

2. When the application gateway does not receive the payment response message within 65 seconds, it shall initiate a TRX_RESULT_INQUIRY message to check if the payment is successful.


Consumer-presented QR Code Payment

After the merchant scans the QR Code presented in the mobile application, the merchant will a QRC payment message to request an authorization from issuer. The payment message can be a purchase message, authorization message, etc. The message flows are as follow. 

被扫.png

1. The merchant submits a payment request message to the UPI System.  The UPI System will check if the transaction amount is below the wallet’s CVM limit. If yes, the transaction flow goes to step 2. Otherwise, The UPI request authorization from the issuer if the additional processing response is positive. If not, UPI will reject the payment and send the result to the acquirer, which is beyond this work flow

2. UPI sends ADDITIONAL_PROCESSING request to the application gateway.

3. The application gateway acknowledges by sending the ADDITIONAL_PROCESSING response. Then the application gateway will request the application to perform CDCVM validation.  The application will perform additional CDCVM, which is beyond the scope of this flow. 

4.The application can approve or reject the transaction for a risk reason at this moment and send the result back to the application gateway. The application gateway will inform the UPI by the ADDITIONAL_PROCESSING_RESULT request.

5. The UPI acknowledges by sending back the ADDITIONAL_PROCESSING_RESULT response.

6. The UPI returns the transaction outcome to the application gateway by the TRX_STATUS_NOTIFICATION request.

7. The application gateway returns the TRX_STATUS_NOTIFICATION response message to acknowledge that the advice is well-received.


Exceptional flows: 

1. Application gateway: When the application Gateway does not receive the TRX_STATUS_NOTIFICATION, no action is required.

2. When the UPI does not receive the additional processing advice within 60 seconds, the transaction will be rejected. 
Security Requirement
Security Requirement

Certificate

The certificate used shall be X.509 standard. RSA key is 2,048-bit size.


Signature

Signature is used to validate the integrity and authenticity of the message. In order to generate a signature or to verify the signature, the application gateway shall follow the steps below: 


● To sign a message

1. To Be Signed String: Prepare the message to be sent to the UPI system in JSON format. Fill the “signature” with “00000000”. Messages shall contain no white space between fields.

2. Use the SHA 256 algorithm to calculate the Hash Value from the To Be Signed String, and the Hash Value will be represented as a hexadecimal string in lower case.

3. Use the private key of Application Signature Certificate and RSA (PKCS1_PADDING) algorithm to encrypt the Hash Value.

4. Base64 encode the encrypted Hash Value and put it as the value of “signature”. The Base64 encoding and decoding are defined in [RFC 4648].


● To verify a message

1. To Be Signed String: Prepare the message received from the UMPS system in JSON format. Fill the “signature” with “00000000”. Messages shall contain no white space between fields.

2. Use the SHA 256 algorithm to calculate the Hash Value from the To Be Signed String, and the Hash Value will be represented as a hexadecimal string in lower case.

3. Base64 decode the value of “signature” to get the Encrypted Hash Value from the sender.

4. Use the public key of UMPS Signature Certificate and RSA (PKCS1_PADDING) algorithm to decrypt the result from step 3 and check if it is consistent with the result from step 2.



Encryption

"For sensitive information such as cardholder verification information (“cvmInfo”), Primary Account Number (“pan”), etc., UMPS requires to encrypt the value of it before transmitting it in the message. The application gateway shall follow the steps below: 


●To encrypt data element

1) Use the UMPS public key of Application Encryption Certificate and encrypt them with RSA (PKCS1_PADDING) algorithm.

2) Base64 encode the encrypted result and fill it in the value of the field.


● To decrypt data element

1) Base64 decode the value of the field.

2) Use the private key of Application Encryption Certificate and decrypt the result of step1 with RSA (PKCS1_PADDING) algorithm.


For encryption sample code, please refer to UPI QR Code App Gateway-encryptPan sample codeV1.0.txt in Documentation
Consumer-presented QR Code
Consumer-presented QR Code

The QR Code has the same structure as the EMVCo QRC does. 1 Application Template is shown below.

E_个人码-模板_1.png
Merchant-presented QR code
Merchant-presented QR code

Merchant-presented QR Code data elements and formatting are as follows

E_商户码-模板_end.png
FAQ and Documentation
FAQ and Documentation
Documents:
  • Contact Us
  • If you have any further questions, please register and submit order in your user center.
©Copyright 2002 - 2020. All rights reserved