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 Acquirer 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

1、Openness. The UPI QR Code solution provides an open platform. The transaction can be completed with any Apps that support UPI QR Code.

2、Security. Security is a basic requirement for payments. UPI adopts Tokenization technology to control the whole transaction process’s risks, ensuring safety and preventing account information leakage.

3、Interoperability. UPI QR Code is compatible with EMVCo standard, making it extendable for other international card schemes. Therefore, UPI QR Code payments is available globally.

4、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 UMPS.
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
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 
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
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.
41 Lost card
43 Stolen card
51 Insufficient balance
54 Expired card.
55 Invalid device id
57 Transaction not permitted to cardholder
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.
Sequence Chart
Sequence Chart

A.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 the UnionPay Mobile Payment System.

2. The UnionPay Mobile Payment System forwards the payment request to the acquirer.

3. The acquirer checks the validity of the Merchant Account Information and other merchant credentials and, when valid, sends the payment request to the UnionPay Switch & Clearing system. Otherwise, the acquirer sends a negative response to the UnionPay Mobile Payment System, and is responsible to notify the merchant of the negative transaction outcome.

4. The UnionPay Switch & Clearing system forwards the payment request to the issuer

5. The issuer returns the transaction outcome to the UnionPay Switch & Clearing system. 

6. The UnionPay Switch & Clearing system returns the payment response to the acquirer.

7. The acquirer returns the payment response to the UnionPay Mobile Payment system, and is responsible to notify the merchant of the transaction outcome.

8. The UnionPay Mobile Payment system 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.


B.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 sends the payment request to the UnionPay Switch & Clearing System. 

5. The UnionPay Switch & Clearing System forwards the payment request to the issuer.

6. The issuer returns the transaction outcome to the UnionPay Switch & Clearing System. 

7. The UnionPay Switch & Clearing System returns the payment response to the UnionPay Mobile Payment System 

8. 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.


C.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 UnionPay Switch & Clearing System.

2. The UnionPay Switch & Clearing System sends an additional processing request to the UnionPay Mobile Payment System. The UnionPay Mobile Payment System will check if the transaction amount is below the wallet’s CVM limit. If yes, the transaction flow goes to step 3. Otherwise, the transaction flow goes to step 7.

3. UnionPay Mobile Payment System sends ADDITIONAL_PROCESSING request to the application gateway.

4. The application gateway acknowledges by sending the ADDITIONAL_PROCESSING response. Then the application gateway will request the application to perform CDCVM validation. 

5. The application will perform additional CDCVM, which is beyond the scope of this document. 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 UnionPay Mobile Payment System by the ADDITIONAL_PROCESSING_RESULT request.

6. The UnionPay Mobile Payment System acknowledges by sending back the ADDITIONAL_PROCESSING_RESULT response.

7.The UnionPay Mobile Payment System sends the additional processing result notification to the UnionPay Switch & Clearing System. The GSCS system will continue to request authorization from the issuer if the additional processing response is positive. Otherwise, the GSCS will reject the payment and send the result to the acquirer (Transaction flow goes to step 10 in this case).

8. The UnionPay Switch & Clearing System sends the payment request to the issuer.

9. The issuer returns the transaction outcome to the UnionPay Switch & Clearing System. 

10. The UnionPay Switch & Clearing System returns the payment response to the acquirer, and the acquirer is responsible for notifying the merchant of the transaction outcome.

11. The UnionPay Switch & Clearing System sends the transaction outcome to the UnionPay Mobile Payment System.

12. UnionPay Mobile Payment System forwards the transaction outcome to the application gateway by the TRX_STATUS_NOTIFICATION request.

13. 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 UnionPay Mobile Payment System does not receive the additional processing advice within 60 seconds, the transaction will be rejected. 

 
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
Steps to Launch
Steps to Launch

Step 1 - Certificate

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


Step 2 - 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: 


● How to sign a message

1)  To-Be-Signed String: Prepare the message to be sent to 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) 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].


● How 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."


Step 3 - 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: 


● How 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.


● How 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."


Step 4 - Public Key Management


● KEY_INQUIRY_EXCHANGE request

The application gateway shall submit a KEY_INQUIRY_EXCHANGE request message to the UMPS system at least once per day.


a. The application gateway shall submit the UMPS Signature Certificate ID and UMPS Encryption Certificate ID in the Transaction Information so that the UMPS can check if the Certificates need updates.

b. The application gateway shall submit the New Application Signature Certificate ID and New Application Signature Public Key in the Transaction Information if they need updates.

c. The application gateway shall submit the New Application Encryption Certificate ID and New Application Encryption Public Key in the Transaction Information if they need updates.

d. The application gateway shall use the Old Application Signature Certificate ID and Old Application Signature Public Key for the message signature."


● KEY_INQUIRY_EXCHANGE response

After receiving the KEY_INQUIRY_EXCHANGE request from the Application:


a. The UMPS will check if the UMPS Signature Certificate ID is the latest ID. If not, the UMPS will return the New UMPS Signature Certificate ID and New UMPS Signature Public Key in the Transaction Information.

b. The UMPS will check if the UMPS Encryption Certificate ID is the latest ID. If not, the UMPS will return the New UMPS Encryption Certificate ID and New UMPS Encryption Public Key in the Transaction Information.

c. If the Application submits New Application Signature Certificate ID or New Application Encryption Certificate ID, the UMPS shall add the New Application Signature Certificate ID and New Application Signature Public Key, or New Application Encryption Certificate ID and New Application Encryption Public Key, in the system. If the UMPS fails to add them in the system, the UMPS will reject the transaction.

d. The UMPS shall use the Old UMPS Signature Certificate ID and Old UMPS Signature Public Key for the response message signature.


After receiving the KEY_INQUIRY_EXCHANGE response:

a. If the UMPS rejects the KEY_INQUIRY_EXCHANGE request, the application gateway shall continue to use Old Application Signature Public Key and Old Application Encryption Public Key for the following payment messages.

b. If the UMPS approves the KEY_INQUIRY_EXCHANGE request, the application gateway shall use New Application Signature Public Key and New Application Encryption Public Key for the following payment messages ."


● KEY_RESET_RESULT request

If the UMPS returns the New UMPS Signature Certificate ID or New UMPS Encryption Certificate ID, the Application shall add the New UMPS Signature Certificate ID and New UMPS Signature Public Key, or New UMPS Encryption Certificate ID and New UMPS Encryption Public Key, in its system. After this is done, the application gateway shall send the KEY_RESET_RESULT request to the UMPS.


● KEY_RESET_RESULT response

The UMPS returns KEY_RESET_RESULT response. The UMPS shall use the Old UMPS Signature Certificate ID and Old UMPS Signature Public Key for the response message signature.a KEY_INQUIRY_EXCHANGE request message to the UAIS system at least once per day."
  • Contact Us
  • If you have any further questions, please register and submit order in your user center.
©Copyright 2002 - 2019. All rights reserved