Technical Specifications on Bankcard Interoperability

Part II Online Message

Version 23.1

October 2022
THIS PAGE IS INTENTIONALLY LEFT BLANK.
 Part II: Online Message

Copyright
UnionPay International Co. Ltd. (“UnionPay International”) retains intellectual property rights concerning this
specifications document and all other documents referenced, attached, and produced by UnionPay International,
including but not limited to copyright, patents, trademarks, and trade secrets. Any use of this specifications
document by any legal and/or natural person is limited by the rules specified in the agreement signed by UnionPay
International Institution Services Portal (https://inst.unionpayintl.com) and UnionPay International. UnionPay
International shall not be liable for any errors or omissions in this specifications document or any losses resulting
therefrom.
Without UnionPay International’s written consent, you may not use this specifications document for uses and
purposes aside from matters involving cooperation with UnionPay International. Without UnionPay International’s
written consent, you may not download, forward, or, publically or in any other form, provide this specifications
document to third parties. If any legal and/or natural person used illegal means to obtain this specifications document,
please immediately delete it and notify UnionPay International.
UnionPay International makes no representations or warranties, including but not limited to, whether or not this
specifications document or its related documents infringe upon the intellectual property rights of third parties. The
user agrees that UnionPay International shall not be liable relating to whether or not the use of this specifications
document infringes on third party rights.

© 2012-2022 UnionPay International Co. Ltd. All rights reserved.

Trademarks
UnionPay International Co. Ltd. (“UnionPay International”) and its various forms are registered trademarks of
UnionPay International Co. Ltd. and its Affiliate(s). All other company or product names mentioned herein are
trademarks of their respective companies.

© 2012-2022 UnionPay International Co. Ltd. All rights reserved.

QR Code is a registered trademark of DENSO WAVE.

UPI CONFIDENTIAL I
 Part II: Online Message

Table of Contents
ABOUT THIS DOCUMENT ....................................................................................................................................... 4
SUMMARY OF REVISIONS ...................................................................................................................................... 6
1 MESSAGE STRUCTURE .................................................................................................................................. 10
1.1 MESSAGE STRUCTURE OVERVIEW ........................................................................................................................10
1.2 MESSAGE HEADER ............................................................................................................................................10
1.3 MESSAGE TYPE IDENTIFIER .................................................................................................................................21
1.4 BITMAP ..........................................................................................................................................................21
1.5 PROCESSING RULES ...........................................................................................................................................22
2 MESSAGE MATCHING ................................................................................................................................... 23
2.1 CORRELATION BETWEEN KEY FIELDS AND MESSAGE .................................................................................................23
2.2 KEY FIELD FOR MATCHING ..................................................................................................................................24
2.3 DEMONSTRATION OF INTER-BANK TRANSACTION ....................................................................................................28
3 MESSAGE FIELD DEFINITION ......................................................................................................................... 29
3.1 MESSAGE FIELD ATTRIBUTE ................................................................................................................................29
3.2 USAGE OF MESSAGE FIELD BY GSCS.....................................................................................................................31
3.3 MESSAGE TYPE IDENTIFIER .................................................................................................................................31
3.4 FIELD 2 PRIMARY ACCOUNT NUMBER (PAN) .........................................................................................................34
3.5 FIELD 3 PROCESSING CODE .................................................................................................................................35
3.6 FIELD 4 AMOUNT, TRANSACTION .........................................................................................................................39
3.7 FIELD 5 AMOUNT, SETTLEMENT ..........................................................................................................................40
3.8 FIELD 6 AMOUNT, CARDHOLDER BILLING ..............................................................................................................41
3.9 FIELD 7 TRANSMISSION DATE AND TIME ................................................................................................................42
3.10 FIELD 9 CONVERSION RATE, SETTLEMENT ..............................................................................................................43
3.11 FIELD 10 CONVERSION RATE, CARDHOLDER BILLING ................................................................................................44
3.12 FIELD 11 SYSTEM TRACE AUDIT NUMBER ..............................................................................................................45
3.13 FIELD 12 TIME, LOCAL TRANSACTION ...................................................................................................................46
3.14 FIELD 13 DATE, LOCAL TRANSACTION ...................................................................................................................47
3.15 FIELD 14 DATE, EXPIRATION................................................................................................................................48
3.16 FIELD 15 DATE, SETTLEMENT ..............................................................................................................................49
3.17 FIELD 16 DATE, CONVERSION..............................................................................................................................50
3.18 FIELD 18 MERCHANT’S TYPE...............................................................................................................................51
3.19 FIELD 19 MERCHANT COUNTRY CODE ..................................................................................................................52
3.20 FIELD 22 POINT OF SERVICE ENTRY MODE CODE ....................................................................................................53
3.21 FIELD 23 CARD SEQUENCE NUMBER ....................................................................................................................55
UPI CONFIDENTIAL 1
 Part II: Online Message

3.22 FIELD 25 POINT OF SERVICE CONDITION CODE .......................................................................................................56

3.23 FIELD 26 POINT OF SERVICE PIN CAPTURE CODE ....................................................................................................59
3.24 FIELD 28 AMOUNT, TRANSACTION FEE .................................................................................................................60
3.25 FIELD 32 ACQUIRING INSTITUTION IDENTIFICATION CODE .........................................................................................61
3.26 FIELD 33 FORWARDING INSTITUTION IDENTIFICATION CODE ......................................................................................62
3.27 FIELD 35 TRACK 2 DATA .....................................................................................................................................63
3.28 FIELD 36 TRACK 3 DATA .....................................................................................................................................64
3.29 FIELD 37 RETRIEVAL REFERENCE NUMBER .............................................................................................................65
3.30 FIELD 38 AUTHORIZATION IDENTIFICATION RESPONSE ..............................................................................................66
3.31 FIELD 39 RESPONSE CODE ..................................................................................................................................67
3.32 FIELD 41 CARD ACCEPTOR TERMINAL IDENTIFICATION .............................................................................................68
3.33 FIELD 42 CARD ACCEPTOR IDENTIFICATION CODE....................................................................................................69
3.34 FIELD 43 CARD ACCEPTOR NAME/LOCATION .........................................................................................................70
3.35 FIELD 44 ADDITIONAL RESPONSE DATA .................................................................................................................71
3.36 FIELD 45 TRACK 1 DATA .....................................................................................................................................72
3.37 FIELD 48 ADDITIONAL DATA-PRIVATE ...................................................................................................................73
3.38 FIELD 49 CURRENCY CODE, TRANSACTION.............................................................................................................89
3.39 FIELD 50 CURRENCY CODE, SETTLEMENT ..............................................................................................................90
3.40 FIELD 51 CURRENCY CODE, CARDHOLDER BILLING ..................................................................................................91
3.41 FIELD 52 PIN DATA...........................................................................................................................................92
3.42 FIELD 53 SECURITY RELATED CONTROL INFORMATION..............................................................................................93
3.43 FIELD 54 ADDITIONAL AMOUNTS.........................................................................................................................95
3.44 FIELD 55 IC CARD DATA .....................................................................................................................................97
3.45 FIELD 56 TOKEN PAYMENT ACCOUNT REFERENCE (PAR) ........................................................................................100
3.46 FIELD 57 ISSUER ADDITIONAL DATA - PRIVATE ......................................................................................................102
3.47 FIELD 60 SELF-DEFINED FIELD ...........................................................................................................................109
3.48 FIELD 61 CARDHOLDER AUTHENTICATION INFORMATION ........................................................................................135
3.49 FIELD 62 SWITCHING DATA (NOT USED) ..............................................................................................................145
3.50 FIELD 63 FINANCIAL NETWORK DATA .................................................................................................................146
3.51 FIELD 70 NETWORK MANAGEMENT INFORMATION CODE .......................................................................................153
3.52 FIELD 90 ORIGINAL DATA .................................................................................................................................155
3.53 FIELD 96 MESSAGE SECURITY CODE ...................................................................................................................157
3.54 FIELD 100 RECEIVING INSTITUTION IDENTIFICATION CODE ......................................................................................158
3.55 FIELD 102 ACCOUNT IDENTIFICATION 1 ..............................................................................................................159
3.56 FIELD 103 ACCOUNT IDENTIFICATION 2 ..............................................................................................................160

UPI CONFIDENTIAL 2
 Part II: Online Message

3.57 FIELD 104 TRANSACTION AND INDUSTRY APPLICATION INFORMATION.......................................................................161

3.58 FIELD 113 ADDITIONAL INFORMATION ................................................................................................................171
3.59 FIELD 117 NATIONAL AND REGIONAL INFORMATION .............................................................................................174
3.60 FIELD 121 GSCS RESERVED..............................................................................................................................177
3.61 FIELD 122 ACQUIRER INSTITUTION RESERVED ......................................................................................................180
3.62 FIELD 123 ISSUER INSTITUTION RESERVED ...........................................................................................................181
3.63 FIELD 125 SECURITY AND RISK ASSESSMENT INFORMATION ....................................................................................182
3.64 FIELD 128 MESSAGE AUTHENTICATION CODE ......................................................................................................194
4 EXPLANATIONS ON MESSAGE FORMAT ...................................................................................................... 195
4.1 EXPLANATION OVERVIEW .................................................................................................................................195
4.2 MESSAGE DEFINITION FOR CLEARING AND SETTLEMENT, AND DAY-END BATCH PROCESSING .........................................202
4.3 MESSAGE DEFINITION FOR SECURITY CONTROL MESSAGE.......................................................................................203
4.4 MESSAGE DEFINITION FOR MANAGEMENT MESSAGE.............................................................................................204
4.5 MESSAGE DEFINITION FOR UNIONPAY CARD INTERNATIONAL TRANSACTION ..............................................................205
4.6 MESSAGE DEFINITION FOR IC CARD TRANSACTION BASED ON UICS DEBIT/CREDIT STANDARD ......................................266
4.7 MESSAGE DEFINITION FOR E-COMMERCE TRANSACTION CERTIFIED BY GSCS CUPSECURE (CURRENTLY NOT USED) ..........283
4.8 MESSAGE DEFINITION FOR RISK CONTROL TRANSACTION (CURRENTLY NOT USED) ......................................................283
4.9 MESSAGE DEFINITION FOR STAND-IN AUTHORIZATION TRANSACTION .......................................................................283
4.10 MESSAGE DEFINITION FOR PAYMENT TOKEN TRANSACTION ....................................................................................287
4.11 MESSAGE DEFINITION FOR QRC-BASED PAYMENT TRANSACTION .............................................................................292
4.12 MESSAGE DEFINITION FOR U-PLAN PAYMENT COUPON MANAGEMENT TRANSACTION .................................................302
4.13 MESSAGE DEFINITION FOR STAGED DIGITAL WALLET OPERATOR (SDWO) TRANSACTION .............................................304

UPI CONFIDENTIAL 3
 Part II: Online Message

About this Document

Purpose
The Technical Specifications on Bankcard Interoperability - Part II Online Message is one of the six parts comprising
the Technical Specifications on Bankcard Interoperability. The document describes the specifications on the structure,
format, and field content of online messages between Members and UnionPay International.

Audience
The audience of this document are UnionPay International (UPI) staff and UPI Members and Special Participants who
have adopted message format version 2.1 (the message format version is indicated in the online message header).

Document Version
Version 23.1 replaces the previous version.

Revisions
UPI will periodically issue updates to this document, as enhancements and changes are implemented or corrections
are required. Occasionally, updates to this document will be published in an Operation Bulletin.
Please refer to the Summary of Revisions for changes in this version.

Time Expressed
UPI has operation centers in several locations, including Shanghai and Beijing. For operational purposes, the time
frame in this document, unless particularly indicated, refers to “Beijing time”. Coordinated Universal Time (UTC) is
the global standard time by which the world follows. Beijing time is 8 hours ahead of UTC. There is no Daylight Saving
Time in China.
Unless otherwise specified, the “day” mentioned in this document refers to the calendar day. The “business day”
refers to the working day subject to local regulations of the country where the processing Member is located.

Application Scope
This document applies to all UPI Members and Special Participants.
References
The terms and conditions in this document have quoted the following publications. Any later versions of these
publications will be applied in this document unless otherwise specified. Members are encouraged to study the latest
versions of such documents and decide whether to apply.
OR UPI Operating Regulations
UICS UnionPay Integrated Circuit Card Specifications
EMV 4.3 Integrated Circuit Card Specification for Payment Systems: Book 1 ~ Book 4

Support
Please address your questions to your UnionPay representatives.

UPI CONFIDENTIAL 4
 Part II: Online Message

Word Convention
Convention Tone Implication
Shall Mandatory Must be followed without exception
Should Optional but recommended Required to follow but optional
Must Mandatory Required without exception
Must not Mandatory Not required
Could Optional Hypothetical
Can Optional Stating a capability
Cannot Optional Stating an incapability
May Optional Stating a possibility

Style Convention
Convention Description
boldface Note/emphasis
italic Publications/book titles
monospace Filename/Command

UPI CONFIDENTIAL 5
 Part II: Online Message

Summary of Revisions
Description of Changes Location
Added a description: “For reversal, this field shall be filled with the same value 3.29 Field 37 Retrieval
as that of the original transaction” to clarify transmission requirement. Reference Number
Clarified that Field 38 padding is subject to subscription of the dual-message 3.30 Field 38 Authorization
Acquirer: Identification Response
Original description:
“… UPI fills Field 38 with all 0s or with 5- byte alphanumeric characters and a
letter “U” as the 6th byte.”
Modified as:
“… UPI fills Field 38 with all 0s or with 5- byte alphanumeric characters and a
letter “U” as the 6th byte subject to the Acquirer’s subscription.”
Changed textual description of Field 43 to clarify language requirement of 3.34 Field 43 Card Acceptor
Merchant Name. Name/Location
Original description:
“If Issuers from Hong Kong and Macao choose to support Chinese Merchant
Name, GB18030－2000 coding rules should be supported.”
Modified as:
“If Issuers from Hong Kong and Macao choose to support reception of Chinese
Merchant Name sent by Chinese Mainland Acquirers in this field, GB18030－
2000 coding rules should be supported … For merchant name in other
languages, please refer to description on Usage ML in Field 117 (See 3.59.3).”
Clarified that account verification transaction is temporarily “not involved” “not 3.37.11.8 Tag AO:
used in combination with primary credit transactions outside of Chinese Transaction Relevance
Mainland.”
Renamed “secondary merchant” into “sub-merchant” to align with the term 3.37.11.9 Tag PM: Sub-
used in UPI Operating Regulations. merchant Information
Changed the description of Fields 48 and 57 to clarify the formatting 3.37 Field 48 Additional
requirements: Data-Private
For usage AS: Tag-Length-Value (TLV) combination is required for sub-tags; 3.46 Field 57 Issuer
Additional Data-Private
For other usages: Identifier-data combination is required.
Added additional valid values for Tag “ID types” to allow submission of IDs other 3.46.3 Usage CI: Cardholder
than “identification card” in Usage CI and Usage AS+CI under Field 57. Information
Added the requirement that “Effective 23:00 April 14, 2023, when the 3.47.5 Field 60.3 Additional
transaction currency is the Icelandic Krona, this field shall be filled with Transaction Information
‘a00’, indicating the number of decimal places of Field 4 (Transaction
Amount) and Field 28 (Transaction Fee Amount) is 0”.
Modified the Field 60.2.8 (ECI) transmission logic of “GSCSIssuer” node from 3.47.6.1 Transmission
“” to “C16”, and added an description on downgraded non-3DS- Requirement of Field 60 in
authentication-mode transaction processing: Original Request

UPI CONFIDENTIAL 6
 Part II: Online Message

Description of Changes Location

“For Acquirers not certified of UnionPay 3DS services, a declared 3DS- Transactions
authentication-mode transaction will be downgraded to a non-3DS-
3.47.6.2 Transmission
authentication-mode transaction: ECI “05”, “06” or “07” in the request will be
Requirements of Field 60 in
replaced with “10” by UPI, with AV (in Usage AM of F61.6) intercepted.”
Subsequent Transactions on
the Same Day
3.47.6.3 Transmission
Requirements of Field 60 in
Subsequent Transactions on
Different Days
Modified the Field 60.2.8 (ECI) transmission logic of the GSCS from “” to 3.47.6.4 Transmission
“C16”, and added descriptions on downgraded non-3DS-authentication-mode Requirements of Field 60 in
transaction processing: Advice Transactions
For transmission from the GSCS to the Acquirer: “For Acquirers not certified of
UnionPay 3DS services, a declared 3DS-authentication-mode authorization will
be downgraded to a non-3DS-authentication-mode authorization: ECI “05”, “06”
or “07” will be replaced with “10” by UPI.”
For transmission from the GSCS to the Acquirer: “In a downgraded non-3DS-
authentication-mode authorization: UPI fills the subfield with “10”.”
Added a description: “For cross-border remittance in Primary Credit Transaction, 3.48.3 Field 61.1 ID Number
Field 61.1 can be used to store the ID Type and ID Number of the payee, namely
the cardholder.”
Added the transmission requirement of AV verification indicator in downgraded 3.48.8.8 Usage AM: Issuer
non-authenticated transaction: When neither ACS nor UnionPay generates the Verification Mode Required
AV, ECI will be altered to “10”, and the AV verification indicator will be set as “0” by Acquirer (F61.6)
by the GSCS.
Added a description to usage TK: “This usage is delivered to subscribing 3.50.3 Usage TK: Token-
Issuers”, to clarify the transmission logic. related information
Added a description on Field 102: “For the Issuer, only subscriber of this field will 3.55 Field 102 Account
receive it”. Identification 1
Defined Tag 18 (counterparty’s ID type) and Tag 19 (counterparty’s ID number) 3.57.6 Usage SI: Sending
and reserved the tags for transactions in Chinese Mainland. Information
Changed textual description of Usage ML in Field 117 to clarify language 3.59.3 Usage ML: Multi
requirement of Merchant Name. Language Merchant Name
and Address
Original description:
“Note 2: For the Acquirer outside of Mainland China, this usage will be filled with
Merchant name and address in the local language.
Note 3: For the Acquirer inside Mainland China, this usage will be filled with
Merchant name and address in English characters.”
Modified as:
“Note 2: For the Acquirer outside of Mainland China, this usage will be filled with
Merchant name and address in the local language, with Field 43 filled in with

UPI CONFIDENTIAL 7
 Part II: Online Message

Description of Changes Location

English.
Note 3: For the Acquirer inside Mainland China, this usage will be filled with
Merchant name and address in English characters, with Field 43 filled in with
English.”
Reserved Tags 07, 0B, 0C and 0D under Usage QR in Field 125 for future use on 3.63.5 Usage QR: QRC-based
non-UnionPay standard QRC-based payment product. Payment
Modified the description of Field 125 Usage IP Tag 01 as “a defining indicator for 3.63.6 Usage IP: Innovative
UnionPay innovative payment transactions”, and listed key fields that identify in- Payment
APP and APP-innovative-payment (Transit QR Code, O2O and Online) scenarios.
Added the data source of Tag 04, Usage IP in Field 125 “Innovative payment 3.63.6 Usage IP: Innovative
additional information”: “channel app of the APP Innovative Payment”. Payment
Modified the description of Tag 01, Usage TF in Field 125 into “Applied when the 3.63.8 Usage TF:
value of Field 60.2.8 in the Acquirer request equals to ‘05’, ‘06’, or ‘07’” to Authentication Transaction
include the processing of this usage in downgraded non-authenticated Identifier
transaction.
Modified the textual description of Conditional Data Element “C16” to clarify its 4.1.3 Explanation on
transmission requirement to avoid potential misunderstanding. Conditional Data Element in
Message Field
Original description:
“…the current node will change the value of the field according to the business
requirement. This field will be assigned a value by the current node according to
the business requirement when last node does not send it.”
Modified as:
“… the current node may change the value of the field according to the business
requirement. When last node does not send it, a new value may be assigned to
this field based on the business requirement and/or subscribed services.”
Changed the transmission requirement of Field 128 from the switch system to 4.3.2 Key Reset
the receiver from “C9” to “M” (mandatory), in compliance with current system
implementation.
An editorial modification is made to clarify that Field 38 padding is subject to 4.5.1.1.2 Pre-authorization
subscription of the dual-message Acquirer:
Original description:
“… Issuers in Mainland China may not return authorization code (Field 38). Dual
message Acquirers shall be able to identify and process it correctly.”
Modified as:
“… Issuers in Mainland China may not return authorization code (Field 38). Dual
message Acquirers shall be able to identify and process it correctly, if it does not
subscribe to Field 38 padding.”
Clarified the transmission requirement of Field 57 in remittance verification 4.5.1.1.19 Remittance
and remittance (online): conditional in Issuer Response and the GSCS (Online)
forwarding.
Used “C16: This field shall be present when the last node sends it. And the 4.5.1.1.19 Remittance

UPI CONFIDENTIAL 8
 Part II: Online Message

Description of Changes Location

current node may change the value of the field according to the business (Online)
requirement. When last node does not send it, a new value may be assigned to
this field based on the business requirement and/or subscribed services” as the
transmission requirement of Field 102 from the GSCS to the Issuer in remittance
verification and remittance (online).
Added a footnote for transmission requirement of Field 60 “reserved”: “All 4.9.3 Message Definition
sub-fields of Field 60 (60.1 - 60.3.10) will be sent to the Issuer.” for Stand-in Authorization
Transaction Transmission
Advice (Online)

UPI CONFIDENTIAL 9
 Part II: Online Message

1 Message Structure
1.1 Message Structure Overview
The online transaction message includes four parts, i.e. the message header, the message type identifier, the bitmap,
and the message field. The structure is shown as follows:

Message Header Message Type Identifier Bitmap Message Field

Message Header 0100 Bitmap 1 Bitmap 2 2 3 4 5 ... 123 125 128

Figure 1 Message Structure

As the first element of the message, the message header records basic information of the message such as length,
routing, and batch number.
The message type identifier, the second element of the message, defines the general categories of message, e.g.
financial message or management message.
The bitmap defines message fields which appear in the message, including either one bitmap or two bitmaps. The
number of bitmaps is determined by transaction type. Bitmap 1 and bitmap 2 are used in magnetic stripe card
transactions and IC card transactions. The difference between them is that IC card transactions involve IC card
characteristic information defined in Field 55. Bitmap 1 defines Fields 2 to 64; bitmap 2 defines Fields 66 to 128.
The message field section is the major part of the message. Most of message fields are defined by ISO 8583 and the
others are defined and used by UnionPay. For detailed definitions of message fields, please refer to Section 3 Message
Field Definitions. For transmission requirements on each field for different transaction messages, please refer to
Section 4 Explanations on Message Format. For requirements on key fields, please refer to Section 2 Message
Matching.

1.2 Message Header

This section describes the composition of the message header and the usage of each field. The ‘b’ represents bit and
the ‘n’ represents decimal number in this section. In addition, all decimal numbers are coded in ASCII.
Position and Basic Explanation
The message header together with the message type identifier, the bitmap and the message field composes a
complete message. The message header is required for all online messages.
The 8000# series messages for file transfer do not use the message header.
1.2.1.1 Composition
The message header length is 46 bytes in total and all fields shall be filled. The composition of the message header
is listed as follows:
Table 1 Composition of the Message Header

Field Field Name Length (byte)

Field 1 Header Length 1
Field 2 Header Flag and Version 1
Field 3 Total Message Length 4

UPI CONFIDENTIAL 10
 Part II: Online Message

Field Field Name Length (byte)

Field 4 Destination ID 11
Field 5 Source ID 11
Field 6 Reserved for Use 3
Field 7 Batch Number 1
Field 8 Transaction Information 8
Field 9 User Information 1
Field 10 Reject Code 5
The header contains 45 bytes in total and all fields should be filled.
Field 10 Reject Code is filled with “00000” in the message header generated by Members. GSCS will fill in the field
with position and reason for error when it finds any format or structure error in the message. Meanwhile, GSCS will
transmit the original message header and content of the message to the message initiator to inform it of the message
error so that the message initiator can process accordingly. Members cannot generate but may receive the Reject
Code field with non-all-zero. Therefore, the message generated by Members and the message generated by GSCS
with no error detected should be as shown in the following figure:

Message Header Message Type Identifier Bitmap Message Field

Figure 2 Normal Output Message Structure

The message generated by GSCS with error detected is shown as follows:

New Message Header Original Message Header

Message Type Identifier Bitmap Message Field
(Reject Code Indicating Error) (Reject Code 000000)

Figure 3 Abnormal Output Message Structure

1.2.1.2 Structure
When a Member generates a request or advice message, it needs to construct a message header according to the
message data to be sent. When a Member receives a request or advice message, it must store some information in
the message header for responding to the sender. The fields to be stored are Fields 4, 5, 6, 7, 8, and 9.
When a Member generates a response message, it should construct the message header of the response message
according to the information stored from the message header of the request message. The requirement is as follows:
 Two scenarios of source ID and destination ID processing.
When the response message is generated by the Member that connects with GSCS directly, the values of Field 4 and
Field 5 in the message header of the response message will be the values of Field 5 (source ID) and Field 4 (destination
ID) in the message header of the request message sent by GSCS. An illustration is as follows (suppose the Acquiring
Institution Identification Code is 01030000, the Issuer Institution Identification Code is 01020000, and GSCS
Institution Identification Code is 00010344):

UPI CONFIDENTIAL 11
 Part II: Online Message

Destination ID: 00010344 Destination ID: 01020000

Source ID: 01030000 Source ID: 00010344

Acquirer GSCS Issuer

Destination ID: 01030000 Destination ID: 00010344

Source ID: 00010344 Source ID: 01020000

Figure 4 Illustration 1 of Source ID and Destination ID Processing

When the response message is generated by the Member’s branch that connects with GSCS through the Member,
the value of field 5 (source ID) in the message header of the response message is the ID of the institution that actually
generates the response message. The illustration is as follows (suppose the Acquiring Institution Identification Code
is 01030000, the Issuer Institution Identification Code is 01020000, the branch Institution Identification Code of the
Issuer is 01026400, and GSCS Institution Identification Code is 00010344):

Destination ID: 00010344 Destination ID: 01020000

Source ID: 01030000 Source ID: 00010344

Issuer
Acquirer GSCS Issuer
Branch

Destination ID: 01030000 Destination ID: 00010344

Source ID: 00010344 Source ID: 01026400

Figure 5 Illustration 2 of Source ID and Destination ID Processing

 The values of the following fields should be returned unchanged:

Field 7 (batch number), Field 6 (UnionPay system internally reserved code), Field 8 (transaction information), and
Field 9 (user information); Members should generate the values of other fields according to the related requirements.

Field Description
This document illustrates the meaning of each field of the message header according to the following table:
Table 2 Field Elements Description

Element Description
Attribute For the length and format of the field, please refer to Section 3.1.1.
Generator Indicating which institution can set the non-zero value in the field
Description Content and definition of the field
Usage Some special limitations on processing the field
Remark Other explanations

UPI CONFIDENTIAL 12
 Part II: Online Message

Element Description
Field Value Available range and limitation of field value
Reject Code Code which indicates the error in the rejected header

1.2.2.1 Field 1- Header Length

Attribute
b8, 8-bit binary data
Generator
Members, GSCS
Description
Length of the message header in byte
Usage
To specify the length of the message header
Field Value
The field value must be 46
Reject Code
00015= invalid value
1.2.2.2 Field 2- Header Flag and Version
Attribute
b8, 8-bit binary data
Generator
Members, GSCS
Description
The first bit of this field indicates the following:
a) 0 indicates a production message
b) 1 indicates a testing message
This bit is filled by the transaction initiator and remains unchanged during transmission. The last 7 bits define the
message format version, and the current value has been changed from 000 0001 to 000 0010. 000 0001 applies to
versions released prior to April 2011. This revision is tagged with the new header flag and version.
Reject Code
00025= invalid value
1.2.2.3 Field 3- Total Message Length
Attribute
n4, 4 numeric characters with fixed length
Generator
Members, GSCS

UPI CONFIDENTIAL 13
 Part II: Online Message

Description
This field specifies the total number of bytes, namely the total length of a message from the beginning of the message
header to the end of the message, as shown below:

Message Header
Message Type Identifier Bitmap Message Field
(F3 = Message Length)

Figure 6 Normal Message Total Length Example

If this message header indicates any message error, Field 3 of the new message header indicates the total length of
the message, whereas Field 3 of the original message header indicates the length of the original message, as shown
below:

New Message Header Original Message Header

Message Type Identifier Bitmap Message Field
(F3 = Total Message Length) (F3 = Original Message Length)

Figure 7 Abnormal Message Total Length Example

Field Value
In correct messages, the field value must be greater than 46 and not more than 1,846 bytes.
In rejected messages, the field value is: new message header length + original outgoing message length, which means
the value must be greater than 46+ 46= 92 and not more than 1,846+ 46= 1,892.
Reject Code
00035= invalid value
1.2.2.4 Field 4- Destination ID
Attribute
ans11, 11 alphanumeric characters with fixed length, with right-aligned blanks if less than 11 alphanumeric
characters.
Generator
Members, GSCS
Description
The field indicates the routing information of the message.
Usage
When a Member inside Mainland China generates a request or advice message, the field is filled with the CUPS
Institution Identification Code, 00010000. For a Member outside of Mainland China, the field is filled with the GSCS
Institution Identification Code, 00010344. When a Member responds to a request message, the field is filled with
the value of Field 5 (source ID) of the request message.
Field Value
The field must be filled with CUPS Institution Identification Code, 00010000 in the message generated by a Member
inside Mainland China, and the GSCS Institution Identification Code, 00010344 in the message generated by a
Member outside of Mainland China. The field must include a valid Institution Identification Code in the message
generated by UnionPay system. Please refer to the illustrations in Section 1.2.1.2 for the processing of filling in the
field.
The field value is provided in detail in Appendix A Code Definitions in the Technical Specifications on Bankcard
Interoperability - Part VI Annex. The unique identifiers of Members are provided in this document.

UPI CONFIDENTIAL 14
 Part II: Online Message

Reject Code
00045= invalid value
1.2.2.5 Field 5- Source ID
Attribute
ans11, 11 alphanumeric characters with fixed length, with right-aligned blanks if less than 11 alphanumeric
characters
Generator
Members, GSCS
Description
This field indicates the message sender that is not sure to be the acceptor of the original transaction data.
Usage
In general, when the message receiver connecting with GSCS directly responds to the received request or advice, the
original destination ID in the request or advice message will be used as the source ID of the response message.
In the request message, the field should be filled with the valid Institution Identification Code of sender connecting
with GSCS directly, even if the connecting institution is not the real generator of this request message, but only the
transmitter of the request message (for instance, the request message is generated by a branch of the Member). In
the response message, the field is filled with the Institution Identification Code of the real response message
generator.
Field Value
Every outgoing message must contain a valid source ID. In the request and response message generated originally by
an Acquirer, the field must indicate a valid Acquiring Institution Identification Code. In the request and response
messages generated by the Issuer, the field must also indicate a valid Issuer Institution Identification Code. Please
refer to the illustrations in Section 1.2.1.2 for the processing of filling in the field.
The field value is provided in detail in Appendix A Code Definitions in the Technical Specifications on Bankcard
Interoperability - Part VI Annex. The unique identifiers of Members are provided in this document.
Reject Code
00055= invalid value
1.2.2.6 Field 6- Reserved for Use
Attribute
b24, 24 bits binary data
Generator
UnionPay
Description
This field is generated and used by UnionPay.
Usage
The field value is 0 if the request message is sent by a Member, whereas the field value will be the same as that in
the request message if it is the response message.
Field Value

UPI CONFIDENTIAL 15
 Part II: Online Message

The field value is 0 in the message generated by a Member.

Reject Code
00065= invalid value
1.2.2.7 Field 7- Batch Number
Attribute
b8, 8 bits binary data
Generator
GSCS
Description
The field includes the batch number assigned by GSCS. When GSCS receives a new request or advice message, it
inserts the current batch number into this field. If what GSCS receives is a message related to a previously processed
message, the field value will be the same as that in the previous message.
Usage
If the request message is initiated by a Member, the field value shall be 0; if a Member returns response to GSCS, the
field value shall be the same as the corresponding value in the request message.
Field value in the reconciliation message sent by GSCS after cutoff is decimal 99 (only applied to Members inside
Mainland China).
Field Value
The field shall be 0 in the request message generated by a Member.
Reject Code
00075= invalid value
1.2.2.8 Field 8- Transaction Information
Attribute
ans8, 8 alphanumeric and special characters
Generator
GSCS
Description
This field is generated by GSCS in the following format:
Table 3 Transaction Information Field Details

Subfield Name Subfield Usage

Format
Transaction ans1 This subfield is used to distinguish transactions.
Identifier
Valid values:
0- UnionPay Card intra-country transaction inside Mainland China
1- UnionPay Card cross-border transaction: either the Acquirer or the Issuer
is located in Mainland China, while the counterparty is outside of Mainland
China.
2- Acquiring transaction of other card brands inside Mainland China: the

UPI CONFIDENTIAL 16
 Part II: Online Message

Acquirer is an institution inside Mainland China, and the card is from a card
scheme other than UnionPay.
3- UnionPay Card transaction outside of Mainland China: the Acquirer and
the Issuer are both outside of Mainland China (Members inside Mainland
China will not receive such kind of transaction).
Advice ans1 This subfield is used to distinguish some special advice transactions. For
Transaction general advice transactions and all request transactions, this subfield is
Identifier filled with the default value “0”.
Valid values:
0- Default Value
1- Reserved for Use
2- Reserved for Use
3- Reserved for Use
Reserved for Use ans6
Usage
Refer to the above table.
Field Value
In a request message sent by a Member, the field value is all zero. The field value in the response message returned
to GSCS by a Member should remain unchanged. The field value should be valid in the message sent by GSCS
Reject Code
00085= invalid value
1.2.2.9 Field 9- User Information
Attribute
b8, 8 bits binary data
Generator
Members
Description
The field value is filled by the Acquirer. For example, the value can be used to identify the source of a request. The
value is only used by a Member internally.
Usage
The value defined by the user at a Member’s option shall be included in the request message. The field must be filled
with 0 if user information is unnecessary. The Member must preserve the field value in the request and return it
unchanged in the response message.
Field Value
N/A
Reject Code
N/A
1.2.2.10 Field 10- Reject Code
Attribute

UPI CONFIDENTIAL 17
 Part II: Online Message

n5, 5 numeric with fixed length

Generator
GSCS
Description
The field is filled by GSCS to indicate the reason for rejecting the message in the following two situations:
 GSCS will fill the field to indicate the error field when it finds any format error in the message sent by a Member.
The 1st digit of this field is either 0 or 1, 0 standing for header error and 1 for message field error. The 2nd to
4th digits stand for the field with error, and the 5th digit stands for the error type.
 The field should be filled to indicate the reason for rejecting the message if it is rejected due to a GSCS error. The
1st digit is 2, indicating the message is rejected due to a GSCS error; the 2nd to 5th digits indicate the error type.
The field is filled with “00000” in the message header generated by a Member. For the detailed definition of reject
code, please refer to the reject code list of Appendix A Code Definitions in the Technical Specifications on Bankcard
Interoperability - Part VI Annex.
Usage
N/A
Field Value
N/A
Reject Code
N/A

Message Header in Transmission

1.2.3.1 Abbreviation
The related abbreviations in this document are defined as follows:
Table 4 Abbreviation Description

Abbreviation Description
Message Sender AC Acquirer
SW GSCS
IS Issuer
SD Sender
RC Receiver
OB Original Bank
CB Cardholder Bank
Field Presence Logic M Field, mandatory
M+ Field, mandatorily added
Field, mandatorily eliminated
C Field, conditional

UPI CONFIDENTIAL 18
 Part II: Online Message

Abbreviation Description
C+ Field, conditionally added
C- Field, conditionally eliminated
O Field, optional
 Field, forwarded and unchanged
Field, with the same value as the corresponding field of the previous message.
00 Private field, must be filled with 0

1.2.3.2 Transmission of Message Header

Table 5 Transmission of the Message Header for Transaction Initiated by the Acquirer and Validated by GSCS

Field Field Name AC SW IS SW Note

No.
1 Header Length M  M  The length of the message header remains unchanged
during transmission.
2 Header Flag and M M M M The version may vary according to message interface.
Version
3 Total Message M M M M It depends on the length of message fields.
Length
4 Destination ID M M M M The Acquirer shall fill in the Destination ID with the
Institution Identification Code of GSCS, i.e. 00010344.
5 Source ID M M M M GSCS will fill in the Source ID with the Institution
Identification Code of GSCS, i.e. 00010344.
6 Reserved for Use M M M  The Acquirer shall fill in this field with all zeroes.
The value is provided by GSCS and the Issuer must not
change it in the response message.
7 Batch Number M M M  The Acquirer shall fill in this field with all zeroes.
The value is provided by GSCS and the Issuer must not
change it in the response message.
8 Transaction M M M  The Acquirer shall fill in this field with all zeroes.
Information
The value is provided by GSCS and the Issuer must not
change it in the response message.
9 User Info M  M 
10 Reject Code M  M  The Acquirer shall fill in this field with all zeroes.
This field is forwarded if no error is detected.

Table 6 Transmission of the New Message Header for Transaction Initiated by the Acquirer and Failed to Pass the Validation by
GSCS

UPI CONFIDENTIAL 19
 Part II: Online Message

Field Field Name AC SW Note

No.
1 Header Length M  The length of the message header remains unchanged during
transmission.
2 Header Flag and M M The version may vary according to message interface.
Version
3 Total Message M M It depends on the length of message fields.
Length
4 Destination ID M M The Acquirer shall fill in the Destination ID with the Institution
Identification Code of GSCS, i.e. 00010344.
5 Source ID M M GSCS will fill in the Source ID with the Institution Identification Code
of GSCS, i.e. 00010344.
6 Reserved for Use M M The Acquirer shall fill in this field with all zeroes.
The value is provided by GSCS and the Issuer must not change it in
the response message.
7 Batch Number M M The Acquirer shall fill in this field with all zeroes.
The value is provided by GSCS and the Issuer must not change it in
the response message.
8 Transaction M M The Acquirer shall fill in this field with all zeroes.
Information
The value is provided by GSCS and the Issuer must not change it in
the response message.
9 User Info M 
10 Reject Code M C+ The Acquirer shall fill in this field with all zeroes.
Reject Code is generated by GSCS, and the message will be returned
to the Acquirer instead of being forwarded when an error is detected.

Table 7 Transmission of the Message Header for Transaction Initiated by the GSCS

Field Field Name SD(SW) RC Note

No.
1 Header Length M M The length of the message header remains unchanged during
transmission.
2 Header Flag and M M The version may vary according to message interface.
Version
3 Total Message M M It depends on the length of message fields.
Length
4 Destination ID M M The Receiver shall fill in the Destination ID with the
Institution Identification Code of GSCS, i.e. 00010344.
5 Source ID M M GSCS will fill in the Source ID with the Institution
Identification Code of GSCS, i.e. 00010344.
6 Reserved for Use M M The value is provided by GSCS and the Receiver must not

UPI CONFIDENTIAL 20
 Part II: Online Message

Field Field Name SD(SW) RC Note

No.
change it in the response message.
7 Batch Number M M The value is provided by GSCS and the Receiver must not
change it in the response message.
8 Transaction M M The value is provided by GSCS and the Receiver must not
Information change it in the response message.
9 User Info M M This field shall be filled with all zeroes.
10 Reject Code M M This field shall be filled with all zeroes.

1.3 Message Type Identifier

The section describes the message type identifier and explains how to use the message type.
The length of the message type identifier is four bytes. Each message is required to have a message type identifier
followed by the main bitmap.
The message type in ISO8583-1987 standard is mainly defined according to the source and destination of the
message. It includes the Acquirer message sent to the Issuer and the Issuer message sent to the Acquirer, but how
the switch system uses the message type is not defined. This document defines the message type transmitted
between GSCS and Members.
For detailed information, please refer to the description of the message field.

1.4 Bitmap
The bitmap is used to identify fields which appear in the message or not. A message can contain one or two bitmaps.

Bitmap 1
The first bitmap is the main bitmap. Each message has the main bitmap. It is composed of 64 binary bits (8 bytes)
following the message type identifier. Except the first bit, every bit corresponds to a field, i.e. to one of Field 2 to
Field 64. Field 55 in Bitmap 1 is specially used for IC card transactions, i.e. if there is Field 55 in Bitmap 1, this is an IC
card transaction. The value of each bit indicates whether the field appears in the message or not:
If a bit is 0, the corresponding field does not appear in the message.
If a bit is 1, the corresponding field appears in the message.
There is no field with the field number “1”. The first bit of the main bitmap is used to indicate whether it is followed
by Bitmap 2. Bitmap 2 is described in the next section.
The following chart indicates the location and function of the bitmap. In this example, the first bit of the bitmap is 0,
which indicates there is no bitmap 2. The second, third and fourth bits are 1, which indicate that Fields 2,3,4 appear
in the message .The fifth and sixth bits are 0, which indicate that Fields 5 and 6 do not appear in the message. The
seventh bit is 1, which indicates that Field 7 appears in the message, etc.

UPI CONFIDENTIAL 21
 Part II: Online Message

Bit 1~8 Bit 9~16 Bit 17~24 Bit 25~32 Bit 33~40 Bit 41~48 Bit 49~56 Bit 57~64

01110010 00000100 01000100 10000001 00101000 11000000 10000000 00010000

Message Field
Bitmap 1 Bitmap 2
2 3 4 7 14 18 22 25 32 35 37 41 42 49 60

Figure 8 An Example of Bitmap 1 and the Corresponding Message Fields

Bitmap 2
The first bit of the main bitmap indicates whether it is followed by Bitmap 2. Like the main bitmap, Bitmap 2 is
composed of 64 binary bits (8 bytes). Bitmap 2 corresponds to Field 66 to Field 128, and can be considered as an
extension of the main bitmap. There is no field with field number 65.
Bitmap 2 will be used only when the message contains fields in Field 66 to Field 128. Bitmap 2 follows the main
bitmap and is followed by message fields. The following chart indicates the location and function of Bitmap 2. The
first bit of the main bitmap indicates the existence of Bitmap 2. If a certain position of the bitmap is 1, the
corresponding field exists. For example, if the bit 26 (90-64= 26) of Bitmap 2 is 1, Field 90 exists in the message.

Bitmap 1 Bitmap 2
Message Field
Bit 1 Bit 2~64 Bit 1 Bit 2~64

0 XX...XXX 0 00...000 Field 2~64 Field 66~128

1 XX...XXX 0 XX...XXX Field 2~64 Field 66~128

Figure 9 The Correlation between Bitmap 1 Bit 1 and Bitmap 2

1.5 Processing Rules

This section gives detailed rules of how GSCS processes the message.

Message Length
The maximum length of the correct message does not exceed 1,846 bytes.
The maximum length of the incorrect message does not exceed 1,892 bytes.

Data Representation
When the field of ISO 8583 message is defined as numeric, it is coded in ASCII in GSCS as follows:
 nx, x bytes fixed length numeric
When the field of ISO 8583 message is defined as alphanumeric, it is coded in ASCII in GSCS as follows:
 anx, x bytes fixed length alphanumeric

UPI CONFIDENTIAL 22
 Part II: Online Message
Though some fields are defined as alphanumeric, their actual values may be only numeric. For instance, Field 37---
Retrieval Reference Number.
When the field of ISO 8583 message is defined as alphanumeric and special characters, such as dash and slash, it is
coded in ASCII in GSCS as follows:
 ansx, x bytes fixed length alphanumeric and special characters
Field Alignment
All fields are aligned on a byte boundary

Field Length
The maximum length of the variable field defined in ISO standard can be 999 bytes. The field description in this
document defines the maximum length of each variable field. The length limitation applies to the entire field. The
total length of all subfields in the specified field should not be more than the length of the entire field.
The value in a length subfield never includes its own length. The meaning of message field length depends on the
attribute of the field, which can be alphabetic, numeric or binary bit.
This above specification permits other networks and systems to skip this field correctly.
For each bit-string field (for example Bitmap or PIN), its bit string must be constructed correctly.

Padding Unused Position

The following applies to fixed length field when the data entered does not fill the field:
 If the field is numeric, right-justified, and left padded with zeroes
 If the field is not numeric, left-justified, and right padded with spaces

Message Transmission
In GSCS, messages are encoded and transmitted in ASCII.

Field with Optional Subfield

If a field contains subfields and not all of the subfields are required in a message, the bit for that field in the bitmap
must be set 1, if any one of the subfields appears.

2 Message Matching
The online message in GSCS is composed of a pair of messages: a request message and a response message. GSCS
compares key fields after receiving a message so as to match the message into a transaction set. The message
matching is one of the most important concepts in the switch system.
This section outlines the message matching concept, describes types of transaction sets, and specifies the fields key
to defining processing procedures.

2.1 Correlation between Key Fields and Message

Key fields are used to identify a transaction. The Issuer, GSCS and the Acquirer must use these key fields to match
the request (advice) and response of a transaction, original transactions, and subsequent related transactions.
When a Member finds any error in processing or transmitting a transaction, it can generate a message for correction.
For example, the Acquirer’s system or POS equipment itself can generate a reversal.
Related transactions include the following:
a) Original transaction and its reversal

UPI CONFIDENTIAL 23
 Part II: Online Message

b) Original transaction and its cancellation

c) Original transaction and its credit adjustment, debit adjustment, chargeback, and exceptional processing within
the specified time frame
d) Debit Adjustment and credit adjustment
e) The chargeback transaction and its corresponding debit adjustment transaction
f) Pre-authorization transaction and its settlement transaction
g) Authentication Transaction and its related transactions (e.g. remittance verification transaction and remittance
transaction)
h) The balance inquiry transaction has no related transaction

2.2 Key Field for Matching

The following tables explain circumstances under which key fields must match those in previous messages and
circumstances under which new values must be assigned. Shaded cells in the following tables indicate that these
fields shall be filled with the same values as those in their related transactions.
A Member can use additional fields to match messages at its discretion. For example, Field 2 (PAN) and Field 37
(Retrieval Reference Number) are usually used to match messages, while Field 90 (the original data element) can be
used to match reversal messages.

Authorization and Pre-authorization Transactions

Table 8 Key Fields of Authorization and Pre-authorization Transactions

Transaction Transmission Date and System Trace Audit Acquiring Institution Forwarding
Type Time (Field 7) Number (Field 11) Identification Code Institution
(Field 32) Identification Code
(Field 33)
Request System date and time A new value Acquiring Institution Forwarding
0100 when the Acquirer assigned to the Identification Code Institution
initiates the transaction transaction Identification Code
Response The same value as that The same value as The same value as The same value as
0110 in the request 0100 that in the request that in the request that in the request
message 0100 message 0100 message 0100 message

Authorization Cancellation, Pre-authorization Cancellation, and Pre-authorization

Completion (Request/Advice) Transactions
Table 9 Key Fields of Authorization Cancellation, Pre-authorization Cancellation, and Pre-authorization Completion
(Request/Advice) Transactions

Transaction Type PAN (Field 2) Authorization Identification Card Acceptor

Response (Field 38) Identification Code (Field
42)
Request The same value as that in Response code of the The same value as that in
0100/0200 the original authorization authorization ID in the the original authorization
transaction original authorization transaction
Advice 0220
transaction
Response The same value as that in Optional The same value as that in
the request 0100/0200 or the request 0100/0200 or

UPI CONFIDENTIAL 24
 Part II: Online Message

Transaction Type PAN (Field 2) Authorization Identification Card Acceptor

Response (Field 38) Identification Code (Field
42)
0110/0210/0230 advice 0220 message advice 0220 message
Note: For pre-authorization completion cancellation, please refer to Section 2.2.5 Financial Cancellation Transaction
for message matching, please refer to Section 4.5.1.1.12 Financial Cancellation for message definition of F38 during
switching. For pre-authorization reversal, pre-authorization completion reversal, and authorization reversal, please
refer to Section 2.2.7 Reversal Advice for message matching.

Balance Inquiry Transaction

Table 10 Key Fields of Balance Inquiry Transaction

Transaction Transmission Date and System Trace Audit Acquiring Institution Forwarding
Type Time (Field 7) Number (Field 11) Identification Code Institution
(Field 32) Identification Code
(Field 33)
Request System date and time A new value Acquiring Institution Forwarding
0200 when the Acquirer assigned to the Identification Code Institution
initiates the transaction transaction Identification Code
Response The same value as that The same value as The same value as The same value as
0210 in the request 0200 that in the request that in the request that in the request
message 0200 message 0200 message 0200 message

Financial Transaction
Table 11 Key Fields of Financial Transaction

Transaction Transmission Date and System Trace Audit Acquiring Institution Forwarding
Type Time (Field 7) Number (Field 11) Identification Code Institution
(Field 32) Identification Code
(Field 33)
Request System date and time A new value Acquiring Institution Forwarding
0200 when the Acquirer assigned to the Identification Code Institution
initiates the transaction transaction Identification Code
Response The same value as that The same value as The same value as The same value as
0210 in the request 0200 that in the request that in the request that in the request
message 0200 message 0200 message 0200 message

Financial Cancellation Transaction

Table 12 Key Fields of Financial Cancellation

Transaction Transmission System Trace Acquiring Forwarding Original Data

Type Date and Time Audit Number Institution Institution Elements
(Field 7) (Field 11) Identification Identification (Field 90)
Code (Field 32) Code (Field 33)
Request System date and A new value The same value as The same value as Extracted
0200 time when the assigned to the that in the original that in the original from the
Acquirer initiates transaction financial request financial request original
the transaction message message financial

UPI CONFIDENTIAL 25
 Part II: Online Message

Transaction Transmission System Trace Acquiring Forwarding Original Data

Type Date and Time Audit Number Institution Institution Elements
(Field 7) (Field 11) Identification Identification (Field 90)
Code (Field 32) Code (Field 33)
request
message
Response The same value as The same The same value as The same value as
0210 that in the value as that in that in the request that in the request
request 0200 the request 0200 message 0200 message
message 0200 message

Financial Advice Transaction

Table 13 Key Fields of Financial Advice Transaction

Transaction Transmission Date System Trace Acquiring Institution Forwarding Institution

Type and Time (Field 7) Audit Number Identification Code Identification Code
(Field 11) (Field 32) (Field 33)
Advice 0220 System date and time A new value The same value as that The same value as that
when the Acquirer assigned to the in the original financial in the original financial
initiates the transaction request message request message
transaction
Response The same value as The same value as The same value as that The same value as that
0230 that in the advice that in the advice in the advice 0220 in the advice 0220
0220 message 0220 message message message

Reversal Advice Transaction

Table 14 Key Fields of Reversal Advice

Transaction Transmission Date System Trace Acquiring Forwarding Original Data

Type and Time (Field 7) Audit Number Institution Institution Elements
(Field 11) Identification Identification (Field 90)
Code (Field 32) Code (Field 33)
Advice System date and A new value The same value The same value Extracted
0420 time when the assigned to the as that in the as that in the from the
Acquirer initiates transaction original original original
the transaction transaction transaction transaction
Response The same value as The same value The same value The same value
0430 that in the advice as that in the as that in the as that in the
0420 message advice 0420 advice 0420 advice 0420
message message message

Network Management Advice Transaction

Table 15 Key Fields of Network Management Advice Transaction

Transaction Transmission Date and Time (Field 7) System Trace Audit Number (Field 11)
Type
Advice 0820 System date and time when the sender initiates A new value assigned to the transaction

UPI CONFIDENTIAL 26
 Part II: Online Message

Transaction Transmission Date and Time (Field 7) System Trace Audit Number (Field 11)
Type
the transaction
Response 0830 The same value as that in the advice 0820 The same value as that in the advice
message 0820 message

Key Reset Transaction

Table 16 Key Fields of Key Reset Transaction

Transaction Transmission Date and Time (Field 7) System Trace Audit Number (Field 11)
Type
Request 0800 System date and time when the sender initiates A new value assigned to the transaction
the transaction
Response 0810 The same value as that in the request 0800 The same value as that in the request
message 0800 message

Remittance Transaction
Table 17 Remittance Transaction

Transaction Transmission System Trace Acquiring Forwarding Original Data

Type Date and Time Audit Number Institution Institution Elements
(Field 7) (Field 11) Identification Identification (Field 90)
Code (Field 32) Code (Field 33)
Request System date and A new value The same value as The same value as Extracted
0200 time when the assigned to the that in the that in the from the
sender initiates transaction remittance remittance original
the transaction verification verification transaction
transaction transaction
Response The same value as The same The same value as The same value as
0210 that in the value as that in that in the request that in the request
request 0200 the request 0200 message 0200 message
message 0200 message

Correlation between PCT and AFT

When a PCT is used for P2P transfer business (Usage BI Tag 01 in Field 104 equals ‘08’) and its related AFT is processed
by GSCS, the Acquirer shall submit Field 90 in the PCT and the subfields of Field 90 shall be filled with the values of
the corresponding key fields in the related AFT.
Below is the guide for the Acquirer to fill the subfields of Field 90 under the above scenario.
Table 18 Values of Subfields in Field 90 in PCT for P2P Transfer

Subfield Value when related AFT is processed by GSCS

Field 90.1 Message Type Identifier of the related AFT
Field 90.2 Field 11 System Trace Audit Number of the related AFT
Field 90.3 Field 7 Transmission Date and Time of the related AFT
Field 90.4 Field 32 Acquiring Institution Identification Code of the related AFT

UPI CONFIDENTIAL 27
 Part II: Online Message

Subfield Value when related AFT is processed by GSCS

Field 90.5 Field 33 Forwarding Institution Identification Code of the related AFT

2.3 Demonstration of Inter-bank Transaction

Assume that,
Table 19 Background Assumption for An Inter-bank Transaction Example

Assumption Assumption Details

Item
Transaction POS Purchase
Type
The Acquirer Ji’nan Branch of China Construction Bank which connects with CUPS through China
Construction Bank head office
The Issuer Wuhan Branch of Bank of China which connects with CUPS through Bank of China head office
The process of the inter-bank transaction is shown below:

1 2 3 4

Acquirer Issuer
Acquirer GSCS Issuer
Branch Branch

8 7 6 5

Figure 10 An Example of Inter-bank Transaction Processing

1. Ji’nan Branch of China Construction Bank, the Acquirer, submits the purchase request message to China
Construction Bank Headquarter, the head office of Acquirer;
2. China Construction Bank Headquarter, the head office of the Acquirer, submits the purchase request message
to CUPS according to the message format defined in this document; The key fields are as follows:
 Field 7 (Transmission Date and Time): 0222092010 (Beijing time 9:20:10 on February 22)
 Field 11 (System Trace Audit Number): 666666
 Field 32 (Acquiring Institution Identification Code): 01054510
 Field 33 (Forwarding Institution Identification Code): 01050000
 Field 100 (Receiving Institution Identification Code): not present

3. CUPS forwards the purchase request message to Bank of China, the head office of the Issuer; The key fields are
as follows:
 Field 7 (Transmission Date and Time): 0222092010 (Beijing time 9:20:10 on February 22)
 Field 11 (System Trace Audit Number): 666666
 Field 32 (Acquiring Institution Identification Code): 01054510
 Field 33 (Forwarding Institution Identification Code): 01050000

UPI CONFIDENTIAL 28
 Part II: Online Message
 Field 100 (Receiving Institution Identification Code): 01040000

4. Bank of China Headquarter, the head office of the Issuer, forwards the request to Wuhan Branch of Bank of
China, the branch of the Issuer;
5. Wuhan Branch of Bank of China, the branch of the Issuer, returns the response to Bank of China Headquarter,
the head office of the Issuer;
6. Bank of China Headquarter, the head office of the Issuer, returns the response to GSCS; The key fields are as
follows:
 Field 7 (Transmission Date and Time): 0222092010 (Beijing time 9:20:10 on February 22)
 Field 11 (System Trace Audit Number): 666666
 Field 32 (Acquiring Institution Identification Code): 01054510
 Field 33 (Forwarding Institution Identification Code): 01050000
 Field 100 (Receiving Institution Identification Code): 01040000

7. CUPS returns the response to China Construction Bank Headquarter, the head office of the Acquirer; The key
fields are as follows:
 Field 7 (Transmission Date and Time): 0222092010 (Beijing time 9:20:10 on February 22)
 Field 11 (System Trace Audit Number): 666666
 Field 32 (Acquiring Institution Identification Code): 01054510
 Field 33 (Forwarding Institution Identification Code): 01050000
 Field 100 (Receiving Institution Identification Code): 01040000

8. China Construction Bank Headquarter, the head office of the Acquirer, returns the response to Ji’nan Branch of
China Construction Bank, the branch of the Acquirer.
It can be concluded from the above process flow that in a transaction cycle, the values of key fields, i.e. Field 7, 11,
32, 33 in a message, remain unchanged in switch processing between Members and GSCS (GSCS is consistent in CUPS
in terms of transaction processing). Moreover, the combination of the four values is unique in the whole process and
can be used to identify a transaction clearly.

3 Message Field Definition

3.1 Message Field Attribute
Characters
In the message between GSCS and each Member, the data type, length attribute, and format of every message field
are listed as follows:
Table 20 Data Type, Length Attribute, and Format of Message Fields

Characters Meanings
a Letters, from A to Z, from a to z, left-justified, right padded with spaces
b Binary form of data, followed by numbers indicating bits of data
B Binary number with variable length, followed by numbers indicating the bytes of binary data
n Numeric value, from 0 to 9, right-justified, filled with heading 0s.
p Filling characters, such as blanks
s Special characters, such as dash and slash

UPI CONFIDENTIAL 29
 Part II: Online Message

Characters Meanings
an Letters and numbers, left-justified, right padded with spaces
as Letters and special characters, left-justified, right padded with spaces
cn Compressed numeric code, namely BCD code
ns Numbers and special characters, left-justified, right padded with spaces
ans Letters, numbers, and special characters, left-justified, right padded with spaces
ansb Letters, numbers, special characters, and binary numbers, left-justified, right padded with spaces
MM Month, from 01 to 12
DD Date, from 01 to 31
YY Year, from 00 to 99
hh Hour, from 00 to 23
mm Minute, from 00 to 59
ss Second, from 00 to 59
LL Followed by the variable length value of data element, from 01 to 99
LLL Followed by the variable length value of data element, from 001 to 999
VAR Data element with variable length
3 The fixed length of 3 characters
..17 Variable length of 17 characters at the maximum. All the variable length fields should contain
another 2 or 3 bytes before data element, indicating the byte number after that to the ending of
the data element. a
X Credit and debit symbols, with “C” indicating credit and “D” indicating debit, and they are always
connected with a numeric currency amount data element. For example, X+ N16 in net
reconciliation amount represents the prefixes “C” or “D” and the 16 bit numbers of net
reconciliation amount.
Z Code set of the Track 2 and Track 3 on magnetic stripe cards as defined in ISO 4909 and ISO 7813
Note a: The 2 or 3 bytes indicating the field length before data element only apply to the main fields rather
than subfields, usages, TLVs, or sub-TLVs.
Note 1: There are 2 additive bytes before any data element with variable length of less than 100 characters,
indicating the length of the data element that follows, and the format is LLVAR. There are 3 additive bytes
before any data element with variable length of less than 1,000 characters, indicating the length of the data
element that follows, and the format is LLLVAR.
Note 2: The fields used in this document follow the field sequence number in the ISO8583, sequencing from
the small number to the larger. Reserved fields in ISO8583 are used in this document, and special usages are
defined.
Note 3: The coding mode in this document is ASCII code. The numeric characters are also expressed by ASCII
code instead of compressed BCD code.
Note 4: Please refer to the Appendix A Code Definitions in the Technical Specifications on Bankcard
Interoperability - Part VI Annex for a summary of reject codes in this chapter.

UPI CONFIDENTIAL 30
 Part II: Online Message

Characters Meanings
Note 5: When the value of data field is not blank, the first byte of the field shall not be filled with a space.

3.2 Usage of Message Field by GSCS

Please refer to the subsequent sections of this chapter for the specifications of each message field.

3.3 Message Type Identifier

Attribute
n4, 4-byte numeric characters with fixed length
Description
Message type Identifier, or Message Type ID is defined as follows:
3.3.2.1 Single Message Transaction Messages
 0100/0110 Authorization request/request response message:
 Pre-authorization request/request response
 Pre-authorization cancellation (online/manual) request/request response
 Remittance verification request/request response
 MO/TO pre-authorization request/request response
 MO/TO pre-authorization cancellation (online/manual) request/request response
 Account verification request/request response
 Establish/Revoke commission relationship
 0200/0210 Financial transaction request/request response message:
 Balance inquiry request/request response
 Cash withdrawal request/request response
 Pre-authorization completion (online) request/request response
 Pre-authorization completion cancellation request/request response
 MO/TO pre-authorization completion (online)request/request response
 MO/TO pre-authorization completion cancellation request/request response
 Purchase request/request response
 Purchase cancellation request/request response
 MO/TO purchase request/request response
 MO/TO purchase cancellation request/request response
 Remittance request/request response
 Recurring request/request response
 Recurring cancellation request/request response
 Primary credit request/request response
 Account funding request/request response

UPI CONFIDENTIAL 31
 Part II: Online Message

 Chip loading request/request response based on UICS debit/credit standard

 Cash loading request/request response based on UICS debit/credit standard
 0220/0230 Financial transaction advice /advice response message:
 (Advice) Pre-authorization completion advice/advice response
 Settlement advice/advice response
 (Online) refund advice/advice response
 (Advice) MO/TO pre-authorization completion advice/advice response
 MO/TO refund (online) advice/advice response
 MO/TO settlement advice/advice response
 Primary credit confirmation advice/advice response
 Stand-in Authorization transaction transmission advice/advice response
 0420/0430 Reversal advice/advice response message:
 Pre-authorization reversal advice/advice response
 Pre-authorization cancellation (online/manual) reversal advice/advice response
 Cash withdrawal reversal advice/advice response
 Purchase reversal advice/advice response
 Purchase cancellation reversal advice/advice response
 Pre-authorization completion reversal advice/advice response
 Pre-authorization completion cancellation reversal advice/advice response
 MO/TO pre-authorization reversal advice/advice response
 MO/TO pre-authorization cancellation (online/manual) reversal advice/advice response
 MO/TO pre-authorization completion reversal advice/advice response
 MO/TO pre-authorization completion cancellation reversal advice/advice response
 MO/TO purchase reversal advice/advice response
 MO/TO purchase cancellation reversal advice/advice response
 Recurring reversal advice/advice response
 Recurring cancellation reversal advice/advice response
 Establish/ Revoke commission relationship reversal advice/advice response
 Cash loading advice/advice response based on UICS debit/credit standard
 Account funding reversal advice/advice response
3.3.2.2 Dual Message Transaction Messages
 0100/0110 Authorization request/request response message:
 Authorization request/request response
 Authorization cancellation request/request response
 Balance inquiry request/request response

UPI CONFIDENTIAL 32
 Part II: Online Message

 MO/TO authorization request/request response

 MO/TO authorization cancellation request/request response
 Recurring authorization request/request response
 Recurring authorization cancellation request/request response
 0420/0430 Reversal advice/advice response message:
 Authorization reversal advice/advice response
 Authorization cancellation reversal advice/advice response
 Stand-in authorization reversal advice/advice response
 MO/TO authorization reversal advice/advice response
 MO/TO authorization cancellation reversal advice/advice response
 Recurring authorization reversal advice/advice response
 Recurring authorization cancellation reversal advice/advice response
3.3.2.3 Other Messages
 0600/0610 Administrative request/request response message:
 UnionPay Card conversion rate inquiry request/request response
 0620/0630 Administrative advice/advice response message:
 Stand-in authorization parameter update advice/advice response
 0800/0810 Network management request/response message:
 Key reset request/request response
 0820/0830 Network management advice/advice response message:
 GSCS sending network management advice/advice response
 Member sending network management advice/advice response
 key reset request advice/advice response
 Stand-in authorization network management advice/advice response
 Stand-in authorization online transmission activate/suspend advice/advice response

UPI CONFIDENTIAL 33
 Part II: Online Message

3.4 Field 2 Primary Account Number (PAN)

Attribute
n..19(LLVAR), 2-byte field length + PAN of numeric characters of 19 bytes at a maximum

Description
The user’s PAN. The PAN of UnionPay Card contains 13 to 19 numeric digits. In Token transactions, this field is filled
with a Token of 13 to 19 numeric digits.
Usage
This field, which should exist in all message types of balance inquiry, authorization, and financial request, response
and advice, is used to determine the Issuer and the routing of transaction messages. If this field exists in the original
transaction request message, it must also exist in the subsequent related messages. If this field exists in the request
or advice message, it should be returned unchanged in the response message.
3.4.3.1 Usage 1: PAN
 For card-present transaction:
In a magnetic stripe card transaction, Field 2 is filled with the PAN captured from Track 2. In an IC card transaction,
Field 2 is filled with the PAN captured from Application PAN (tag ‘5A’) or Track 2 Equivalent Data (tag ‘57’). In a
Consumer-presented QRC-based Payment transaction, this field is filled with the PAN/token captured from tag ‘57’
in the QRC data.
 For card-not-present transaction:
In a card-not-present transaction, such as e-commerce transaction, this field should be filled manually or by the
institution that stores the Cardholder’s credentials.

Reject Code
10023= invalid characters in length field
10024= length value exceeding 19
10025= invalid characters in PAN

UPI CONFIDENTIAL 34
 Part II: Online Message

3.5 Field 3 Processing Code

Attribute
n6, 6-byte numeric characters with fixed length

Description
This field is composed of 6-digit decimal numbers, indicating the transaction type, and the type of the Cardholder’s
account.
Table 21 Composition of Processing Code

1st-2nd Digits 3rd-4th Digits 5th-6th Digits

Transaction Type Account Type (From) Account Type (To)
The 1st and 2nd digits of the transaction processing code are defined as follows:
Table 22 Definitions of the 1st-2nd Digits of Field 3 Processing Code

The 1st-2nd Digits Description

00~19 Debits
00 Goods and service
01 Cash
02 Adjustment
03 Cheque guarantee (funds guaranteed)
04 Cheque verification (funds available but not guaranteed)
05 Euro-cheque
06 Traveler cheque
07 Letter of credit
08 Giro (postal banking)
09 Goods and service with cash withdrawal transfer
10~13 Reserved for ISO use
14~16 Reserved for national use
17~19 Reserved for private use
20~29 Credits
20 Returns
21 Deposits
22 Adjustment
23 Cheque deposit guarantee
24 Cheque deposit
25, 26 Reserved for ISO use

UPI CONFIDENTIAL 35
 Part II: Online Message

The 1st-2nd Digits Description

27 Reserved for national use
28 Reserved for private use
29 Primary credit
30~39 Inquiry services
30 Available funds inquiry
31 Balance inquiry
32~35 Reserved for ISO use
36, 37 Reserved for national use
38, 39 Reserved for private use
40~49 Transfer services
40 Cardholder accounts transfer
41~45 Reserved for ISO use
46, 47 Reserved for national use
48 Reserved for private use
49 Account funding
50~99 Reserved
70 PIN change
89 Establish commission relationship
92 Revoke commission relationship

Note: Please refer to the Technical Specifications on Bankcard Interoperability - Part VI Annex for valid values and
applicable transaction types of the first two digits of Field 3 Processing Code.
The 3rd and 5th digits of the transaction processing code are defined as follows:
Table 23 Definitions of the 3rd and 5th Digits of Field 3 Processing Code

The 3rd and 5th Digits Description

0 Default
1 Saving account
2 Cheque account
3 Credit facility
4 Universal account number
5 Investment account
6, 7 Reserved for ISO use
8 Reserved for national use

UPI CONFIDENTIAL 36
 Part II: Online Message

The 3rd and 5th Digits Description

9 Reserved for private use
The 4th and 6th digits of the transaction processing code are defined as follows:
Table 24 Definitions of the 4th and 6th Digits of Field 3 Processing Code

The 4th and 6th Digits Description

0 Default
1, 2 Reserved for ISO use
3~7 Reserved for national use
8, 9 Reserved for private use

Usage
In a response transaction, this field must be the same as that in the request transaction.
In a reversal transaction, this field must be same as that in the original transaction.
The usage of this field is listed as follows:
Table 25 The Values of Field 3 in Different Transaction Types

Transaction Type Card Type Saving Cheque Credit Universal

Not Account Account Account Account
Selected
Balance Inquiry 300000 301000 302000 303000 304000
Pre-authorization/Pre-authorization 030000 031000 032000 033000 034000
Reversal
Pre-authorization Cancellation/Pre- 200000 201000 202000 203000 204000
authorization Cancellation Reversal
Pre-authorization 000000 001000 002000 003000 004000
Completion/Reversal/Chargeback
Authorization/ Authorization Reversal 000000 001000 002000 003000 004000
Authorization Cancellation/Authorization 200000 201000 202000 203000 204000
Cancellation Reversal
Purchase/Reversal/Chargeback 000000 001000 002000 003000 004000
Pre-authorization Completion (Advice)/ 000000 001000 002000 003000 004000
Settlement Advice/Pre-authorization
Completion (manual)/Chargeback
Coupon Write-off/Reversal 000000 001000 002000 003000 004000
Purchase Cancellation / Reversal 200000 201000 202000 203000 204000
Refund 200000 201000 202000 203000 204000
Pre-authorization Completion Cancellation/ 200000 201000 202000 203000 204000
Reversal

UPI CONFIDENTIAL 37
 Part II: Online Message

Transaction Type Card Type Saving Cheque Credit Universal

Not Account Account Account Account
Selected
Cash Withdrawal/Reversal/Chargeback 010000 011000 012000 013000 014000
Credit Adjustment 220000 221000 222000 223000 224000
Debit Adjustment/Chargeback 020000 021000 022000 023000 024000
Loading of a Specific Account of IC Card 600000 601000 602000 603000 604000
Based on E-cash Application of UICS
Standards
Loading of IC Card Based on E-cash 630000 631000 632000 633000 634000
Application of UICS Standards
Fee collection/fund disbursement-Debit 190000 191000 192000 193000 194000
Fee collection/fund disbursement -Credit 290000 291000 292000 293000 294000
Exceptional Processing 220000 221000 222000 223000 224000
Remittance Verification/Remittance 240000 241000 242000 243000 244000
Primary Credit/Primary Credit Confirmation 290000 290010 290020 290030 290040
Account Verification 330000 331000 332000 333000 334000
Stand-in Authorization Transaction 930000 931000 933000 933000 934000
Transmission Advice
Account Funding Transaction 490000 491000 492000 493000 494000
Note: For each transaction, the first 2 bytes of Field 3 shall be a fixed value to differentiate the transaction type, and
the last 4 bytes that are not used as the transaction type indicator can be filled with the recommended value meeting
the requirements of Field 3.
For a transaction without the card type specified in the message, the Issuer can determine the card type at its own
discretion to process the account according to the account number.
The Issuer can further differentiate transactions with the same Field 3 Processing Code based on Usage 2 in Field 25
Point of Service Condition Code. Please refer to Section 3.22.4 for details.

Reject Code
10035= invalid processing code or invalid characters

UPI CONFIDENTIAL 38
 Part II: Online Message

3.6 Field 4 Amount, Transaction

Attribute
n12, 12-byte numeric characters with fixed length

Description
Transaction amount. No decimal point appears in this field. The decimal place is based on the transaction currency.

Usage
Generally, this field is filled with the value that only contains the transaction amount. However, for cross-border
transactions, the value of this field may include not only the transaction amount but also the additional transaction
fee charged from the Cardholder, such as ATM access fee (for cross-border ATM transaction) or convenience fee.
Field 49 Currency Code, Transaction indicates the transaction currency code and must be present together with this
field. For an Issuer participating in multi-currency transactions, Field 49 indicates the currency in the request
submitted by the Acquirer.
When the transaction currency is RMB, the last two digits on the right of this field should contain jiao and cent of
RMB.
When the transaction currency is non-RMB and has no decimal digit, this field reflects the actual transaction amount.
If the currency is non-RMB and has two decimal digits, the way to fill the field is the same as that for RMB; while if it
has three decimal digits, the last three digits are decimal digits. For valid decimal digits of currencies, please refer to
description on Currency Codes in Part VI Annex of Technical Specifications on Bankcard Interoperability. Examples of
usage are shown as follows:
Table 26 Usage of Transaction Amount

Currency Type Decimal Digits Actual Amount Field Value

RMB 2 1000.02 000000100002
Non-RMB None 1000 000000001000
2 1000.02 000000100002
3 1000.112 000001000112
The field will not exist in balance inquiry requests.
Note for Incremental Pre-authorization/Authorization: For each Incremental Pre-authorization/Authorization
transaction, Field 4 is filled with the value that only contains the incremental amount; For the reversal transaction,
the Acquirer shall submit the same transaction amount of the reversed transaction in Field 4; For the cancellation
transaction, the Acquirer shall submit the accumulated transaction amount in Field 4; For the pre-authorization
completion transaction, the Acquirer shall submit the total transaction amount in Field 4.

Reject Code
10045= invalid characters

UPI CONFIDENTIAL 39
 Part II: Online Message

3.7 Field 5 Amount, Settlement

Attribute
n12, 12-byte numeric characters with fixed length

Description
Settlement amount = transaction amount (Field 4) × settlement conversion rate (Field 9). Decimal point is not
included in this field, and the decimal place is based on the settlement currency.
Usage
This field is used as a basis for the settlement between Members. Field 50 (Currency Code, Settlement) indicates the
settlement currency. If this field exists, Field 50 must appear.
When the settlement currency is RMB, the last two digits on the right of this field should contain Jiao and cent of
RMB.
When the currency is non-RMB and has no decimal digit, this field reflects the actual settlement amount. If the
currency is non-RMB and has two decimal digits, the way to fill the field is the same as that for RMB; while if it has
three decimal digits, the last three digits are decimal digits. Examples of usage are shown as follows:
Table 27 Usage of Settlement Amount

Currency Type Decimal Digits Actual Amount Field Value

RMB 2 1000.02 000000100002
Non-RMB None 1000 000000001000
2 1000.02 000000100002
3 1000.112 000001000112
This field will not appear in authorization and balance inquiry messages.
This field will be filled by GSCS in financial transactions settled by UPI independently; for transactions not settled by
UPI independently, it shall be filled by settlement institutions. When an Issuer outside of China Mainland adopts the
single message mode, this field will and must appear only when the transaction currency is different from the
settlement currency. If this field appears, Field 9 (Settlement Conversion Rate), Field16 (Exchange Date), and Field 50
(Currency Code, Settlement) must appear.

Reject Code
10055= invalid characters

UPI CONFIDENTIAL 40
 Part II: Online Message

3.8 Field 6 Amount, Cardholder Billing

Attribute
n12, 12-byte numeric characters with fixed length

Description
Cardholder billing amount = transaction amount (Field4) × Cardholder billing conversion rate (Field 10). There is no
decimal point in this field, and the decimal place is based on the Cardholder billing currency.
Usage
This field is used for deducting or freezing the fund in the Cardholder account and only present in international
transaction messages. In a single-message transaction such as an ATM cash withdrawal transaction, the amount filled
in this field can be used as the reference amount for the Issuer to deduct the fund from the Cardholder account;
while in a dual-message transaction such as an authorization transaction, the amount can be used as the reference
amount for the Issuer to freeze the fund in the Cardholder account.
In UnionPay Card international transactions, this field is filled by GSCS, only containing transaction amount without
any transaction fee except for additional transaction fee charged by the Acquirer. Therefore, the amount deducted
by the Issuer from the Cardholder account should contain two parts, this amount and other fees. This value is only
for reference, and the Issuer can calculate the Cardholder billing amount itself.
When the Cardholder billing currency is RMB, the last two digits on the right of this field should contain Jiao and cent
of RMB.
When the Cardholder billing currency is non-RMB and has no decimal digit, this field reflects the actual settlement
amount. If the currency is non-RMB and has two decimal digits, the way to fill the field is the same as that for RMB;
while if it has three decimal digits, the last three digits are decimal digits. Examples of usage are shown as follows:
Table 28 Usage of Cardholder Billing Amount

Currency Type Decimal Digits Actual Amount Field Value

RMB 2 1000.02 000000100002
Non-RMB None 1000 000000001000
2 1000.02 000000100002
3 1000.112 000001000112
This field is used only when the transaction currency is different from the Cardholder billing currency. When this field
appears, Field 10 (Cardholder Billing Conversion Rate) and Field 51 (Cardholder Billing Currency Code) must appear.

Reject Code
10065= invalid characters

UPI CONFIDENTIAL 41
 Part II: Online Message

3.9 Field 7 Transmission Date and Time

Attribute
n10, 10-byte numeric characters with fixed length

Description
The system working date and time of the transaction initiator
Format: MMDDhhmmss, MM= month, DD= day, hh= hour, mm= minute, ss= second.
Usage
When the Acquirer receives a transaction request message, it should fill this field with the system working date and
time of the Acquirer (Beijing time).
When GSCS initiates a dispute resolution advice message, it fills this field with the system working date and time of
GSCS.
A Member should save this field when it receives a message, and then return the original value in the response
message. The value of this field must remain the same in the whole transaction lifecycle.
This field is a key field that will be used to match the request message when a Member receives a transaction
response message. The combination set of Field 11 with Field 7, Field 32, and Field 33 is the unique identifier of a
transaction.
When sending a reversal message, the reversal initiator will fill this field with a new transaction time which will not
be changed when the reversal is resent.
The range of transaction transmission time is:
Table 29 The Valid Range of Transaction Transmission Time

MM DD hh mm ss
01-12 01-31 00-23 00-59 00-59

Reject Code
10075= invalid numbers or invalid characters

UPI CONFIDENTIAL 42
 Part II: Online Message

3.10 Field 9 Conversion Rate, Settlement

Attribute
n8, 8-byte numeric characters with fixed length

Description
It is the currency conversion rate from the transaction currency to the settlement currency, which is agreed on by
UnionPay and the Member. The 1st digit indicates the number position where the decimal point should be moved
from the right (allowed values are 0–7). The 2nd-8th digits indicate the value of the conversion rate, and are right
justified with no decimal point.
For example, 71212345 indicates that the conversion rate is 0.1212345.
Usage
This field is used only when the transaction currency (Field 49) is different from the settlement currency (Field 50).
It will be filled by GSCS in financial transactions settled by UnionPay independently. In the request message that GSCS
sends to the Issuer, it is the currency conversion rate from the Acquirer’s transaction currency to the Issuer’s
settlement currency. And in the response message that GSCS returns to the Acquirer, it is the currency conversion
rate from the Acquirer’s transaction currency to its settlement currency. In financial transactions not settled
independently by UnionPay, this field will be filled by settlement institutions.
This field must appear when the transaction amount (Field 4) and the settlement amount (Field 5) appear in the
message. The Field 16 (conversion date) and Field 50 (settlement currency code) must appear when this field is used.

Reject Code
10095= invalid characters

UPI CONFIDENTIAL 43
 Part II: Online Message

3.11 Field 10 Conversion Rate, Cardholder Billing

Attribute
n8, 8-byte numeric characters with fixed length

Description
It is the currency conversion rate from the transaction currency to the Cardholder billing currency. The 1st digit
indicates the number position where the decimal point should be moved from the right (allowed values are 0-7). The
2nd-8th digits indicate the value of the conversion rate, and are right justified with no decimal point.
For example, 71212345 indicates that the conversion rate is 0.1212345.

Usage
The field only appears in international transaction messages, and is filled by UnionPay.
It is present when Field 6 (Cardholder billing amount) appears.
Reject Code
10105= invalid characters

UPI CONFIDENTIAL 44
 Part II: Online Message

3.12 Field 11 System Trace Audit Number

Attribute
n6, 6-byte numeric characters with fixed length

Description
Field 11 is a series of numbers filled by the transaction initiator, and the combination set of Field 11 with Field 7,
Field 32, and Field 33 is the unique identifier of a transaction.
Usage
The transaction initiator must assign a system trace audit number for every transaction. For re-sent reversal messages,
the number must be the same as that of the original reversal transaction. The number remains unchanged
throughout the whole transaction cycle.
It is also a key field. Combining with the value of this field and those of other key fields (Field 7, Field 32, and Field
33), the whole value set should be unique. The Member will use this value to match the original request message
when receiving the transaction response message.

Reject Code
10115= invalid characters

UPI CONFIDENTIAL 45
 Part II: Online Message

3.13 Field 12 Time, Local Transaction

Attribute
n6, 6-byte numeric characters with fixed length

Description
The local time of the Acquirer location when the transaction occurs
Format: hhmmss, hh= hour, mm= minute, ss= second.
Usage
In the 0100 and 0200 request messages, the Acquirer must fill this field with its local time. The Acquirer’s local time
in the related transactions of the original transaction, such as reversal and primary credit confirmation, should be
the time in the original transaction, including but not limited to purchase, pre-authorization, pre-authorization
completion, authorization, primary credit transaction, etc.
Table 30 The Valid Range of Local Transaction Time

hh mm ss
00-23 00-59 00-59

Reject Code
10125= invalid numbers or invalid characters

UPI CONFIDENTIAL 46
 Part II: Online Message

3.14 Field 13 Date, Local Transaction

Attribute
n4, 4-byte numeric characters with fixed length

Description
The local date of the Acquirer location when the transaction occurs
Format: MMDD, MM= month, DD= day.
Usage
In the 0100 and 0200 request messages, the Acquirer must fill this field with its local date.
The Acquirer’s local date in the reversal message should be the same as that in the original message.
This field is the original financial transaction date in the dispute resolution advice message and in credit adjustment
transaction message.
In a debit adjustment transaction, the local date should be that of the original financial transaction or credit
adjustment transaction.
In a chargeback transaction message, the local date should be that of the original financial transaction or debit
adjustment transaction.
Table 31 The Valid Range of Local Transaction Date

MM DD
01-12 01-31

Reject Code
10135= invalid numbers or invalid characters

UPI CONFIDENTIAL 47
 Part II: Online Message

3.15 Field 14 Date, Expiration

Attribute
n4, 4-byte numeric characters with fixed length

Description
The expiration date of bank card is the year and month after which the card expires. For example, the expiration date
of the card is April 2005, meaning the card is invalid from May 1, 2005.
The card expiration date is contained in the magnetic stripe.
Format: YYMM, YY= year, MM= month.

Usage
This field is filled with the expiration date of bank card.
This field will be filled out by the Cardholder in an e-commerce transaction, and then be sent to GSCS by the payment
gateway.
In the response message, this field can be filled with “0000”.

Reject Code
10145= invalid numbers and characters

UPI CONFIDENTIAL 48
 Part II: Online Message

3.16 Field 15 Date, Settlement

Attribute
n4, 4-byte numeric characters with fixed length

Description
This field is the transaction settlement date between the Acquirer and the Issuer.
Format: MMDD, MM= month, DD= day.
Usage
UPI assigns a settlement date for each received or initiated 0100, 0200, 0220, or 0420 message, indicating that the
transaction will participate in the settlement on that day. The next settlement day should be indicated in the cutoff
message (0820/0830).
The Member should return the original settlement date in the response message. In a re-sent message, it is the
settlement date in the original message.
Table 32 The Valid Range of Settlement Date

MM DD
01-12 01-31

Reject Code
10155= invalid numbers or invalid characters

UPI CONFIDENTIAL 49
 Part II: Online Message

3.17 Field 16 Date, Conversion

Attribute
n4, 4-byte numeric characters with fixed length

Description
This field is the effective date of the currency conversion rate from the original transaction currency to the settlement
currency.
Format: MMDD, MM= month, DD= day.

Usage
This field is filled by UPI when the transaction currency is different from the settlement currency.
Table 33 The Valid Range of Settlement Date

MM DD
01-12 01-31

Reject Code
10165= invalid numbers or invalid characters

UPI CONFIDENTIAL 50
 Part II: Online Message

3.18 Field 18 Merchant’s Type

Attribute
n4, 4-byte numeric characters with fixed length

Description
This field indicates Merchant Category Code (MCC).

Usage
It indicates the service range and type of a Merchant. It must exist in the 01xx, 02xx, and 04xx messages.
Reject Code
10185= invalid characters

UPI CONFIDENTIAL 51
 Part II: Online Message

3.19 Field 19 Merchant Country Code

Attribute
n3, 3-byte numeric characters with fixed length

Description
It is the country code of the Merchant. Please refer to Section A.5 Country/Region and Currency Code in the Technical
Specifications on Bankcard Interoperability - Part VI Annex.
Usage
This field contains a code that identifies the country of the Merchant or the ATM.

Reject Code
10195= invalid characters

UPI CONFIDENTIAL 52
 Part II: Online Message

3.20 Field 22 Point of Service Entry Mode Code

Attribute
n3, 3-byte numeric characters with fixed length

Description
Field 22 Point of Service Entry Mode Code is the entry mode of Cardholder data (for example, PAN/token and PIN).
Point of service means the place where the transaction is initiated. The definitions of point of service codes are
specified in the following table.
Table 34 Definition of Each Digit of Point of Service Entry Mode

1st-2nd PAN/token Entry Mode 3rd PIN Entry Mode

Digits Digit
00 Unspecified 0 Unknown
01 Manual 1 PIN included in the
transaction
02 Magnetic stripe read 2 PIN excluded in the
transaction
03 Consumer-presented QR Code (QRC), chip information 3-5 Reserved for ISO use
included
04 Consumer-presented QRC (barcode also), chip 6-7 Reserved for national use
information excluded
05 Integrated circuit card read, card data reliable (contact) 8-9 Reserved for private use
06 Reserved for ISO use
07 qUICS Debit/Credit Integrated Circuit Card read
(contactless)
08-60 Reserved for ISO use
61-89 Reserved for national use
90 Magnetic stripe data read and reliable; Track 2 data must
exist.
92 Reserved for national use
93 Merchant-presented QRC, chip information included
94 Merchant-presented QRC (barcode also), chip
information excluded
95 Integrated circuit card, card data may be unreliable
(contact)
96 Reserved
97 Reserved
98 Standard UICS Debit/Credit Integrated Circuit Card read
(contactless)

UPI CONFIDENTIAL 53
 Part II: Online Message

1st-2nd PAN/token Entry Mode 3rd PIN Entry Mode

Digits Digit
99 Reserved for private use
Note: If the value of the first 2 digits of F22 POS Entry Mode Code is “03” or “93”, F23, F35, and F55 may be present
in the message; if the value of the first 2 digits of F22 POS Entry Mode Code is “04” or “94”, F23, F35, and F55 are not
present.
Usage
The values of the first and second digits in this field are related to Field 60.2.2 (terminal capability). Together with
Field 60.2.3, this field can be used to tell the medium of the transaction. Please refer to the values of Field 60.3.6 for
rules of transaction medium.
Reject Code
10225= invalid characters

UPI CONFIDENTIAL 54
 Part II: Online Message

3.21 Field 23 Card Sequence Number

Attribute
n3, 3-byte numeric characters with fixed length

Description
Field 23 contains a number assigned to a specific IC card when two or more individual cards are associated with the
same PAN, thereby enabling Issuers to distinguish among different cards linked to the same account.
The sequence number can also act as a tracking tool when cards are reissued. For example, the initial card is issued
with sequence number one, and when it expires, the card can be reissued with sequence number two, and so on.

Usage
It is used for distinguishing between separate cards sharing the same PAN, and is only used in IC card transactions.

Reject Code
10235= invalid characters

UPI CONFIDENTIAL 55
 Part II: Online Message

3.22 Field 25 Point of Service Condition Code

Attribute
n2, 2-byte numeric characters with fixed length

Description
Table 35 Point of Service Condition Code

Code Meaning Note

00 Normal present
01 Customer not present PIN data not allowed
02 Unattended terminal PIN must be entered.
03 Suspicious Merchant
05 Customer present, card not It must be the 01x0 authorization message
present
06 Pre-authorized request Pre-authorization code required
08 MO/TO authorization, MO/TO
purchase
10 Customer identity verified
11 Suspected Fraud Message type must be 0100 or 0200
12 Security reason Message type must be 0100 or0200
17 Chargeback
18 MO/TO pre-authorization
28 Recurring authorization
42 Normal submission of e- Currently not used
commerce transaction
43 Pre-authorization request of e- Currently not used
commerce transaction
45 Chargeback of e-commerce Currently not used
transaction
61 Manual refund (original
transaction found )
62 Credit voucher (original
transaction not found)
63 Coupon write-off and coupon It indicates that the transaction shall be forwarded to the U-plan
reversal platform for processing.
64 Installment payment Applicable to installment payment transactions
66 Account funding transaction Applicable to account funding refund
68 Credit Applicable to primary credit confirmation transaction

UPI CONFIDENTIAL 56
 Part II: Online Message

Code Meaning Note

70 Push cash withdrawal (reserved) reserved
71 Push purchase (reserved) reserved
73 Incremental authorization Applicable to incremental pre-authorization and incremental
transaction authorization
82 Exceptional processing
83 The credit adjustment of deposit The credit adjustment of general transactions (e.g. purchase) is
initiated by the Issuer initiated by the Acquirer, but the credit adjustment of deposit is
initiated by the Issuer.
91 Loading of IC card E-cash Applicable to loading transactions based on E-cash application of
application based on UICS UICS Debit/Credit standards (including account loading, cash
Debit/Credit Standard loading, and cash loading cancellation) and related reversal

Usage
3.22.3.1 Usage 1: Point of Service Condition
It indicates the condition under which the point of service initiates the transaction. In this usage, the currently
allowed value range is:
 00: normal submission
 02: ATM cash withdrawal, ATM balance inquiry
3.22.3.2 Usage 2: Expanded Processing Code
It is used as the supplement to Field 3 Processing Code to further distinguish different transaction types with the
same processing code. The value and its corresponding indication of F25 are listed as follows:
 06: Pre-authorization completion, used to distinguish from purchase (00)
 08: MO/TO purchase, used to distinguish from purchase (00)
 18: MO/TO pre-authorization, used to distinguish from pre-authorization (06)
 28: Recurring: used to distinguish from purchase (00)
 63: Coupon write-off and coupon reversal: used to indicate that these two transactions shall be forwarded to
the U-plan platform for processing.
 64: Installment payment: used to distinguish from purchase (00)
 66: Account funding refund: used to distinguish from refund (online) (00)
 73: Incremental authorization transaction: used to distinguish incremental pre-authorization from normal pre-
authorization (06), and incremental authorization from purchase and normal authorization (00).
 82: Special credit adjustment, used to distinguish from credit adjustment (00)
 83: Credit adjustment for general transactions (e.g. purchase), used to distinguish from credit adjustment for
deposit transaction
 91: Cash loading cancellation/Reversal

Reject Code
10255= invalid characters

UPI CONFIDENTIAL 57
 Part II: Online Message

UPI CONFIDENTIAL 58
 Part II: Online Message

3.23 Field 26 Point of Service PIN Capture Code

Attribute
n2, 2-byte numeric characters with fixed length

Description
Table 36 Point of Service PIN Capture Code

Code Meaning

00-03 Reserved for ISO use

04-12 The maximum number of PIN characters accepted by point of service device
13-59 Reserved for ISO use
60-73 Reserved for national use
80-99 Reserved for private use

Usage
This field describes the maximum number of PIN characters accepted by point of service device.

Reject Code
10265= invalid characters

UPI CONFIDENTIAL 59
 Part II: Online Message

3.24 Field 28 Amount, Transaction Fee

Attribute
x+n8, 1-byte flag + 8-byte numeric characters with fixed length

Description
This field is filled with the additional transaction fee charged by the Acquirer, namely the surcharge. For example,
this field is filled with the ATM access fee by the Acquirer in cross-border ATM cash withdrawal. Surcharge shall be
included in the total transaction amount which shall be filled in Field 4 Amount, Transaction.
To sum up, Field 28 indicates the surcharge, and Field 4 indicates the sum of the transaction amount and the
surcharge. The Issuer can learn about the surcharge according to the value of Field 28.
Usage
The first byte is “C” for crediting and “D” for debiting the Cardholder’s account. The 2nd-9th bytes indicate the
amount of the transaction fee for crediting or debiting the Cardholder’s account. The currency of the transaction fee
amount is indicated by Field 49. If it is RMB, it should contain jiao and cent of RMB. For foreign currency, if this
currency has no decimal point, the value of this field represents the real amount; if this currency has two decimal
points, the representation method is the same as that for RMB; if it has three decimal points, the last three bytes are
the value of decimal points. For valid decimal digits of currencies, please refer to description on Currency Codes in
Part VI Annex of Technical Specifications on Bankcard Interoperability. Examples of usage are shown as follows:
Table 37 Usage of Transaction Amount

Currency Type Decimal Digits Actual Amount The 2nd-9th bytes of Field 28
RMB 2 1000.02 00100002
Non-RMB None 1000 00001000
2 1000.02 00100002
3 1000.112 01000112
Note: For higher transaction success rate, it is recommended that the Acquirer should not submit Field 28 in the
message when the 2nd-9th bytes of Field 28 is equal to 00000000.
In a cash withdrawal, when the Acquirer submits the field in the request under specified conditions, it is
recommended that the Issuer return the field in the response message. If returned by the Issuer, the value shall be
the same as that in the request, with the GSCS forwarding it back to the Acquirer. If not returned by the Issuer, the
GSCS will echo the value from the original request, and return it to the Acquirer.

Reject Code
10285= non-numeric characters

UPI CONFIDENTIAL 60
 Part II: Online Message

3.25 Field 32 Acquiring Institution Identification Code

Attribute
an..11(LLVAR), 2-byte length value + Acquiring Institution Identification Code of maximum 11 bytes alphanumeric
characters
Description
This field is the Acquiring Institution Identification Code. The acquiring institution should be a Member that is approved
to connect to UnionPay network and can provide ATM cash withdraw service or acquiring service for the Merchant.

Usage
This code identifies the ATM or POS acquiring institution. For e-commerce gateway directly connected to UPI, it
stands for the Institution Identification Code of the bank in which the Merchant opens the account.
It is a key field. The Issuer and UPI use this value, along with transaction transmission date/time, system trace audit
number, and forwarding institution identification code to match the original request message, and then find the
return routing. It should remain the same in the subsequent related transactions.
The Acquirer must provide the Acquiring Institution Identification Code in 01xx, 02xx, and 04xx messages.
The Issuer should save this field to process transactions, such as fee collection/fund disbursement, chargeback, etc.

Reject Code
10323= invalid characters in length field
10324= length value exceeding 11

UPI CONFIDENTIAL 61
 Part II: Online Message

3.26 Field 33 Forwarding Institution Identification Code

Attribute
an..11(LLVAR), 2-digit length value + Forwarding Institution Identification Code of maximum 11 bytes alphanumeric
characters
Description
This field is the Forwarding Institution Identification Code. The forwarding institution should be a Member that is
approved to connect to UnionPay network and sends a transaction request or advice message.

Usage
It is used to identify a UnionPay Network Member. It provides the unique identification code of each Member.
Forwarding Institution Identification Code is a key field. The Issuer and UnionPay will use this value, along with
transaction transmission date/time, system trace audit number and Acquiring Institution Identification Code to
match the original request message, and then find the return routing. It should remain the same in the subsequent
related transactions initiated by the sender.

Reject Code
10333= invalid characters in length field
10334= length value exceeding 11

UPI CONFIDENTIAL 62
 Part II: Online Message

3.27 Field 35 Track 2 Data

Attribute
z..37(LLVAR), 2-byte length value + Track 2 data of maximum 37 bytes (characters)

Description
This field is the Track 2 data on the card.

Usage
It is read from the 1st character after the beginning character (;) of Track 2, including field separators, and excluding
the ending sentinel and LRC characters. It is not used in e-commerce transaction or settlement advice.
The field separator may appear as “D” or “d” in addition to “=”. It is strongly recommended that Issuer’s system
support the field separator “D” and “d”.

Reject Code
10353= invalid characters in length field
10354= length value exceeding 37
10355= invalid Track 2 data or invalid characters

UPI CONFIDENTIAL 63
 Part II: Online Message

3.28 Field 36 Track 3 Data

Attribute
z..104(LLLVAR), 3-digit length value+ Track 3 data of maximum104 bytes (characters)

Description
This field is the Track 3 data on the card.

Usage
It is read from the first character after the beginning character (;) of Track 3, including field separators, and excluding
the ending sentinel and LRC characters. It is not used in e-commerce transaction or settlement advice.
The field separator may appear as “D” or “d” in addition to “=”. It is strongly recommended that the Issuer’s system
support the field separator “D” and “d”.

Reject Code
10363= invalid characters in length field
10364= length value exceeding 104
10365= invalid Track 3dataor invalid characters

UPI CONFIDENTIAL 64
 Part II: Online Message

3.29 Field 37 Retrieval Reference Number

Attribute
an12, 12-byte alphanumeric characters with fixed length

Description
This field is a system reference number for the transaction assigned by Members, POS terminals or Merchants.

Usage
This field is used as a system reference number assigned by the acquiring institution to locate the original transaction.
It should remain unchanged throughout the whole transaction cycle.
The acquiring institution must assign a new value to each new transaction, including purchase, cash withdrawal, pre-
authorization, authorization, MO/TO pre-authorization, MOTO authorization, MO/TO purchase and recurring. For
the associated cancellation and financial advice transactions, this field may be filled with a new value or the same
value as that of the original transaction. For reversal, this field shall be filled with the same value as that of the
original transaction. For the specific requirements, please refer to the definition of the message format hereinafter,
and fill the value according to the requirements for this field of each transaction. The Issuer should return this field
value in the response message and in related chargeback transactions. In addition, the value should be printed on
the receipt of ATM or POS transaction.
Note: For better transaction success rate and the Cardholder's payment experience, it is recommended that the
Issuer should not reject the transaction because of the non-unique value of Field 37, if it is not against the Issuer’s
risk rules.

Reject Code
10375= invalid characters

UPI CONFIDENTIAL 65
 Part II: Online Message

3.30 Field 38 Authorization Identification Response

Attribute
an6, 6-byte alphanumeric characters with fixed length

Description
The authorization code for the approved transaction assigned by the Issuer or the stand-in authorization code
generated by GSCS when a stand-in authorization transaction is processed
Usage
If the authorization code is less than 6 bytes, then it should be left justified, and right padded with spaces. There
should not be any blank within the code.
In a pre-authorization completion request message, this field should be filled with the authorization code obtained
in the pre-authorization transaction, and then be sent to the Issuer.
For a reversal, the value of this field may be obtained from the request message of the original transaction. For
cancellation, the value of this field should be obtained from the response message of the original transaction. For
pre-authorization completion cancellation, the value shall be obtained from the response message of the original
pre-authorization transaction. For refund, if it is required to match the refund transaction with its original transaction,
the value of this field should be obtained from the response message of the original transaction.
This field is not present in the messages of transactions that credit the Cardholder, including remittance (online), and
the related transactions.
A fixed-amount authorization transaction initiated by a dual-message Acquirer is converted to a purchase transaction
when it is forwarded to a single-message Issuer. In this case, the Issuer may not return Field 38. To address this
concern, UPI fills Field 38 with all 0s or with 5- byte alphanumeric characters and a letter “U” as the 6th byte subject
to the Acquirer’s subscription, and fill Field 39 with successful response code “00” in the response message. If the
authorization code is filled by UPI, it will not be present in related cancellation or reversal transactions sent from UPI
to the Issuer, but should be present in the messages sent from the Acquirer to UPI (Please refer to the description of
Field 48 Usage AA).
Field 38 is a key field for authorization and pre-authorization transactions. If Field 38 is returned, the combined set
of Field 38, Field 2, and Field 42 shall be unique before transaction settlement.
Note for Incremental Pre-authorization/Authorization: In a pre-authorization completion request message, this
field should be filled with the authorization code obtained in the first pre-authorization transaction, and then be sent
to the Issuer. For cancellation/refund, the value of this field should be obtained from the response message of the
original transaction.

Reject Code
10385= invalid characters

UPI CONFIDENTIAL 66
 Part II: Online Message

3.31 Field 39 Response Code

Attribute
an2, 2-byte alphanumeric characters with fixed length

Description
The response code from the Issuer or UnionPay to the acquiring institution indicates the processing information of
the received transaction, such as successfully processed, not processed, or declined. If the transaction is not
processed or declined, this field should be filled with the reason, and in some cases, this field will remind the card
acceptor or POS terminal to pick up the card.

Usage
For each received request message, the Issuer should return the processing result in this field to the acquiring
institution. GSCS will directly send a response to the acquiring institution if GSCS fails to forward the message to the
Issuer. Please refer to Appendix A Code Definitions in the Technical Specifications on Bankcard Interoperability - Part
VI Annex for details.

Reject Code
10395= invalid characters

UPI CONFIDENTIAL 67
 Part II: Online Message

3.32 Field 41 Card Acceptor Terminal Identification

Attribute
ans8, 8-byte alphanumeric and special characters with fixed length

Description
Card acceptor terminal identification code. It must be unique for each terminal in the network of the acquiring
institution.
Usage
If the terminal identification code is less than 8 bytes, then it should be left-justified, and right padded with spaces.
The terminal identification code is assigned by the acquiring institution. It must exist in every transaction request
and remain unchanged throughout the whole transaction cycle.

Reject Code
10415= invalid characters

UPI CONFIDENTIAL 68
 Part II: Online Message

3.33 Field 42 Card Acceptor Identification Code

Attribute
ans15, 15-byte alphabetic, numeric, and special characters with fixed length

Description
This field is the card acceptor identification code, namely the Merchant code. It is the unique identification code of
the Merchant in the acquiring institution network.
Usage
It is assigned by the acquiring institution. It must exist in each transaction request message and remain unchanged
throughout the whole transaction cycle.
For ATM cash withdrawal, if the specific Merchant code cannot be filled, this field shall be padded by default value
0.
Reject Code
10425= invalid characters

UPI CONFIDENTIAL 69
 Part II: Online Message

3.34 Field 43 Card Acceptor Name/Location

Attribute
ans40, 40-byte alphabetic, numeric, and special characters with fixed length

Description
This field is filled with the card acceptor name/location, namely the Merchant’s name/location.
The format is listed as follows:
Table 38 The Sequence and Value Information of Field 43

Subfield Definition Attribute Description

43.1 Card acceptor ans25 Filled with Merchant name, ATM location, or the name of the
name or ATM Staged Digital Wallet Operator (padded with spaces).
location
43.2 City name ans12 Filled with City’s name (padded with spaces). If the value of the
subfield is “in-transit” 1, it means it is in flight commerce, right
padded with spaces.
43.3 Country code ans3 Filled with the alpha 3 Country/Region Code, for the coding rules
refer to Section A.5 Country/Region and Currency Code in the
Technical Specifications on Bankcard Interoperability - Part VI
Annex.
Note 1: Case insensitive.

Usage
Field 43 is filled by the Acquirer or the Merchant; the Merchant name/ATM location and city name shall be coded in
Standard ASCII printable characters (Refer to the Technical Specifications on Bankcard Interoperability - Part VI Annex,
A.6). If Issuers from Hong Kong and Macao choose to support reception of Chinese Merchant Name sent by Chinese
Mainland Acquirers in this field, GB18030－2000 coding rules should be supported. It shall appear in every card
transaction request message, and remain the same in the whole transaction lifecycle. For merchant name in other
languages, please refer to description on Usage ML in Field 117 (See 3.59.3). For E-Commerce transactions, subfield
43.2 and 43.3 may not be present in the message sent from UPI to the Issuers.

Reject Code
10435= invalid characters

UPI CONFIDENTIAL 70
 Part II: Online Message

3.35 Field 44 Additional Response Data

Attribute
ans..25(LLVAR), 2-byte length value + additional response data of maximum 25 bytes (alphabetic, numeric, and
special characters)
Description
This field is the identifier assigned by the Issuer for an approved transaction. It can be used by the Issuer for
identifying the original transaction.

Usage
The additional response data of the Issuer must be effective digits. It will be input into the response message when
the Issuer approves the transaction, and not processed by the Acquirer or GSCS.
It is an optional field.
The field value of the original response message should be sent to the Issuer if a reversal is initiated after an approved
response message has been received.

Reject Code
10443= invalid characters in length field
10444= length value exceeds 25

UPI CONFIDENTIAL 71
 Part II: Online Message

3.36 Field 45 Track 1 Data

Attribute
z..76(LLVAR), 2-byte length value + Track 1 data of maximum 76 bytes (characters)

Description
This field is Track 1 data in the card, including field separators, but excluding beginning, ending, and LRC characters.

Reject Code
10453= invalid characters in length field
10454= length value exceeds 76
10455= invalid characters

UPI CONFIDENTIAL 72
 Part II: Online Message

3.37 Field 48 Additional Data-Private

Attribute
ansb..512(LLLVAR), 3-byte length value + private additional data of maximum 512 bytes (alphabetic, numeric, and
special characters and binary numbers)
Description
This field is defined by ISO as a private-use field. This document defines multiple usages for this field.
The general format is listed as follows:
Table 39 The General Format of Field 48 Additional Data-Private

Field Length Usage Identifier Data

3 bytes 2 bytes maximum 510 bytes
 <Field Length>
It indicates the total length (including the field identifier) of this field, i.e. 3 bytes.
 <Usage Identifier>
It indicates the type of the data following the field length, with the length of 2 bytes. Valid values include:
• “AA” – Acquirer Additional Information
• “NK” – New Key
• “KB” – Key Block Format Key
• “IN” – CUPSecure Certification Information
• “IP” – Installment Payment
• “BC” – Suspicious Fraudulent Transaction Advice Information (Currently Not Used)
• “SI” – Stand-in Authorization Additional Information
• “CB” – Cash Rebate
• “AS” – Usage Combination
 <Data>
It contains the detailed data. The format is defined by <field identifier> and the maximum length is 510 bytes.
• For data composition of Usages AA, NK, KB, IN, IP, BC SI and CB, please refer to the descriptions below of each
usage.
• Exceptionally, Usage AS adopts TLV (tag-length-value) composition, to meet the demand of combined usage in
certain special transactions. Under this usage, each subfield consists of tag label (T), subfield length (L), and
subfield value (V). The data field of Usage AS is constructed as below:
Table 40 Subfield Structures of Usage AS

Usage Identifier “AS” Data

2 bytes Subfield 1 Subfield 2
Tag Length Value Tag Length Value ..
2 bytes 3 bytes X bytes 2 bytes 3 bytes X bytes ..

UPI CONFIDENTIAL 73
 Part II: Online Message

 <Subfield Tag>
It is used to define the business meaning of the following data, with the length of 2 bytes, and in the format of an.
 <Subfield Length>
It is used to define the total length of each subfield defined by the subfield tag, with the length of 3 bytes, in the
format of n, and left padded with zeroes if the total length is less than 3 bytes.
 <Subfield Value>
It is defined by each tag in Usage AS. The data presentation in each usage of Field 48 is indicated in the subsequent
sections.
In the procedure of a transaction, the Member should be able to process all the usages and all the sub-usages within
Usage AS in Field 48. The Acquirer needs to submit usages according to its actual business needs, while the Issuer
may choose to decline the transaction if a certain usage is not supported, and system abnormality or transaction
disruption caused by its inability to process this usage should be avoided.
Usage AA: Acquirer Additional Information
3.37.3.1 Attribute
ans..512, 2-byte usage identifier + 26-byte additional transaction data + maximum 484 bytes of free text data
3.37.3.2 Description
It is used by the Acquirer to transmit some specific information of the transaction (it can be used in the public
payment program). The maximum length is 510 bytes, excluding usage identifier.
This usage is used to identify whether the transaction amount in the authorization request is fixed or estimated. For
the authorization request with a fixed transaction amount, GSCS converts it into a purchase transaction and sends it
to the single-message Issuer, in which case the single-message Issuer may choose not to return F38 Authorization
Identification Response, but the dual-message Acquirer should be able to process the transaction. For the
authorization request with an estimated amount, GSCS converts it into a pre-authorization request and sends it to
the single-message Issuer.
A normal authorization transaction will be considered as an estimated-amount authorization transaction by default
if this usage not filled by the Acquirer.
MO/TO authorization will be considered as an estimated-amount authorization transaction no matter whether this
usage is filled by the Acquirer or not.
Recurring authorization will be considered as a fixed-amount authorization transaction no matter whether this usage
is filled by the Acquirer or not.
The sequence and value of information are shown in the following table:
Table 41 The Sequence and Value information of Usage AA

Seq. Definition Length Description

1 Usage identifier 2 bytes Valid value:
AA- Acquirer additional information
2 Function code 3 bytes Valid values:
100- Original authorization: fixed-amount
101- Original authorization: estimated-amount
Note: If the Acquirer cannot provide the value of the current sequence
and the value of the following sequences, Usage AA should not be used.
If the Acquirer cannot provide the value of the current sequence but

UPI CONFIDENTIAL 74
 Part II: Online Message

Seq. Definition Length Description

can provide the value of the following sequences, the current sequence
should be filled with spaces.
3 The information 23 The information of the original transaction amount and currency. It is
of the original bytes applicable to the transaction for which the currency conversion has
transaction been conducted before it is sent to GSCS.
amount and
currency Subfield Attribute Description
Original transaction n12 Transaction amount before the
amount first currency conversion
Original transaction an3 Transaction currency before the
currency first currency conversion
Original conversion n8 Conversion rate for the first
rate currency conversion

4 Free text ans..484 Filled with additional information.

3.37.3.3 Usage
For transactions other than authorization or authorization cancellation (dual message), Acquirers must not fill F48
Usage AA.
It is mandatory for Acquirers to fill Field 48 Usage AA in messages of authorization transactions and authorization
cancellation transactions with fixed-amount original transactions.
Note: For authorization of installment payment transaction, F48 Usage IP will be used instead of F48 Usage AA for
providing installment purchase information, given that installment payment is fixed-amount by default.

Usage NK: New Key

3.37.4.1 Attribute
ans..512, 2-byte usage identifier + maximum 510-byte new key information.
3.37.4.2 Description
It is used in the key reset 0800 message to store the new key which is defined by UnionPay and the Member. It can
meet the requirement of the key with double or triple or even longer length.
Table 42 The Sequence and Value Information of Usage NK

Seq. Definition Length Description

1 Usage identifier 2 bytes Valid value:
NK- New key information
2 New key Maximum 510 bytes Filled with the cipher text of the new key being reset.
Note 1: The key consists of 4,080 bit binary numbers.

3.37.4.3 Usage
It is used in the transaction in which GSCS initiatively resets the key or GSCS resets the key upon the request of the
Member. When GSCS resets the ECB-enciphered data key, the newly generated key which is encrypted by the
member master key (MMK) will be put in this field and sent to the Member.

UPI CONFIDENTIAL 75
 Part II: Online Message
The new key is generated by the Hardware Security Module (HSM) of GSCS. After the Member receives the new key
distributed by GSCS, the key should be decrypted by HSM before being installed and used.

Usage KB: Key Block Format Key

3.37.5.1 Attribute
ans..146, 2-byte usage identifier + maximum 144-byte key block format key information.
3.37.5.2 Description
It is used in the key reset 0800 message to store the ANSI X9 TR-31 key block format key (variable length) which is
defined by UnionPay and the Member.
Table 43 The Sequence and Value Information of Usage KB

Seq. Definition Length Description

1 Usage identifier 2 bytes Valid value:
KB- Key block format key information
2 Key block format Maximum 144 Filled with the key block information of the key being
key bytes reset.

3.37.5.3 Usage
It is used in the transaction in which GSCS initiatively resets the TR-31 key block format key or GSCS resets the key
upon the request of a TR-31 key block format key from the Member. When GSCS resets the data key, the newly
generated key block format key will be put in this field and sent to the Member.
The key block format key is generated by the Hardware Security Module (HSM) of GSCS. After the Member receives
the key block format key distributed by GSCS, the key should be unwrapped and decrypted by HSM before being
installed and used.
For more detailed information about the key block format, please refer to the Technical Specifications on Bankcard
Interoperability, Part IV Data Secure Transmission Control.

Usage IN: CUPSecure Certification Information

3.37.6.1 Attribute
ans..257, 2-byte usage identifier + maximum 255 bytes
3.37.6.2 Description
This usage is applicable to the E-commerce transaction certified with CUPSecure. The sequence and value of
information in the usage are shown as follows:
Table 44 The Sequence and Value Information of Usage IN

Seq. Definition Length Description

1 Usage identifier 2 bytes Valid value:
IN- CUPSecure certification information
2 Value of certification Maximum 255 The unique identification code of the user
DN bytes certification

3.37.6.3 Usage
For E-commerce transaction certified by GSCS CUPSecure, Usage IN applies to the messages of transactions including

UPI CONFIDENTIAL 76
 Part II: Online Message

but not limited to:

• Purchase
• Pre-authorization/Authorization
• Refund
• Account Verification
• Balance Inquiry
The Acquirer does not need to fill field 48 of Usage IN which is filled by UnionPay according to the requirement of
CUPSecure certification.

Usage IP: Installment Payment

3.37.7.1 Attribute
ans64, 2-byte usage identifier + 62 bytes installment payment information
3.37.7.2 Description
This usage is used to transmit the installment payment related information from the Acquirer to the Issuer.
The sequence and value of information are shown in the following table:
Table 45 The Sequence and Value Information of Usage IP

Seq. Definition Attribute Description

1 Usage identifier a2 Valid value:
IP- Installment payment information filled by the Acquirer
2 Number of payments n2 Filled with the number of installment payments (right-justified, left
padded with zeroes) by the Acquirer.
3 Reserved for use ans30 Filled with spaces by default.
4 Characteristic data ans30 Filled with the characteristic data of installment payment.
of installment
payment Subseq. Format Description
1 ans1, Reserved Filled with spaces by
default
2 ans1, Reserved Filled with spaces by
default
3 n6, installment It is the rate determined by
payment commission the merchant and the
fee rate Issuer.
Filled with actual
commission fee
rate*100000.
For example, 004500
indicates that the
commission fee rate is
4.5%.

UPI CONFIDENTIAL 77
 Part II: Online Message

Seq. Definition Attribute Description

4 n6, Additional It is the rate which shall be

installment payment paid to the Issuer by the
commission fee rate Acquirer side.
Filled with actual
commission fee
rate*100000.
For example, 001000
indicates that the
commission fee rate is 1%.
5 ans16, Reserved Filled with spaces by
default

3.37.7.3 Usage
This field shall be present in the request message sent by the Acquirer if the transaction is an installment payment
purchase transaction or installment payment fixed-amount authorization transaction.
It shall be present in the installment payment online refund transaction.
It shall not be present in the messages of the following transactions sent by the Acquirer: installment payment
purchase reversal, installment payment purchase cancellation, installment payment purchase cancellation reversal,
installment payment authorization reversal, installment payment authorization cancellation, and installment
payment authorization cancellation reversal.
It is mandatory for the Issuer to fill F57 of Usage IP in the response message if the installment payment transaction
is accepted by the Issuer.

Usage BC: Suspicious Fraudulent Transaction Advice Information (Reserved)

Usage SI: Stand-in Authorization Additional Information
3.37.9.1 Attribute
ans28, 2-byte usage identifier + 26 bytes
3.37.9.2 Description
It is used to send the additional information of stand-in authorization.
The sequence and value of information are shown in the following table:
Table 46 The Sequence and Value Information of Usage SI

Seq. Definition Attribute Description

1 Usage identifier a2 Valid value:
SI- Stand-in authorization additional information
2 Original message type n4 Used to indicate the F0 of the original transaction.
3 Original transaction n6 Used to indicate the F3 Processing Code of the original
processing code transaction.
4 Original point of service n2 Used to indicate the F25, point of service condition code of the
condition code original transaction.

UPI CONFIDENTIAL 78
 Part II: Online Message

Seq. Definition Attribute Description

5 VIP card or not n1 Used to indicate if it is a VIP card transaction.
Valid values:
1- Yes
2- No
6 Reason for failure of ans2 Used to indicate the 1st item that failed stand-in authorization
Stand-in authorization check. When the stand-in authorization is successful, this field
shall be filled with spaces.
Valid values:
01- Card number length verification failed
02- Card number check digit verification failed
03- Card expiry date verification failed
04- CVN (CVN2) verification failed
05- PVN verification failed
07- ARQC verification failed
08- TVR&CVR verification failed
09- DCVN&ICVN verification failed
10- ARPC generation failed
11- Failed stop-payment list check
12- Exceeds the single transaction amount control of classic card
13- Exceeds the accumulative transaction amount control of
classic card
14- Exceeds the single transaction amount control of VIP card
15- Exceeds the accumulative transaction amount control of VIP
card
16- Exceeds transaction count limits
17- Failed stop-payment acquiring region check
18- Failed stop-payment Merchant check
96- System abnormality
7 The Issuer’s Institution ans11 Used to indicate the Issuer’s Institution Identification Code.
Identification Code

3.37.9.3 Usage
F48 Usage SI is filled by GSCS. It is mandatory in the online Stand-in authorization Transaction Transmission advice
(0220) message sent from GSCS to stand-in authorized Members.

Usage CB: Cash Rebate Identifier

3.37.10.1 Attribute
ans64, 2-byte usage identifier + 62 bytes cash rebate information
3.37.10.2 Description
F48 Usage CB is filled by the Acquirer or initiator of the primary credit transaction. It is used to send information
about cash rebate to the Issuer.
The sequence and value of information are shown in the following table:
Table 47 The Sequence and Value Information of Usage CB

UPI CONFIDENTIAL 79
 Part II: Online Message

Seq. Definition Attribute Description

1 Usage a2 Valid value:
identifier CB- Cash rebate information
2 Payment n2 Used to help the Issuer identify business types, such as cash rebate
type program, tax refund, or other possible business types.
Valid value:
01- cash rebate transaction
3 Payment ans30 In a cash rebate program, it is used to notify the Issuer of the program code
code to which this cash rebate item belongs, with a maximum of 30 bytes.
4 Payment ans30 Used to fill in additional information of cash rebate transactions, with a
reason maximum of 30 bytes.

3.37.10.3 Usage
Usage CB in F48 is only applied to cards issued inside Mainland China and acquired outside of Mainland China. For
primary credit transactions, cash rebate can be identified by F48 Usage CB. The Issuer does not need to verify the
Cardholder name or ID, or check whether the name and ID information match the card number. The Issuer can
directly transfer the specified amount into the Cardholder’s account.

Usage AS: Usage Combination

3.37.11.1 Attribute
ans..512, 2-byte usage identifier + maximum 510 bytes
3.37.11.2 Description
This usage in the format of TLV is used to support the data transmission requirement in the following situations:
 The combination of usages in the forementioned sections as required by the UPI Operating Regulations
 The requirement for transmitting data aside from the Usage AA, BC, NK, KB, IN, IP, SI, and CB (Add a new tag in
Usage AS instead of adding a new usage)
Currently, the tag defined in Usage AS is listed in the following table.
Table 48 The Subfields of Usage AS

Subfield Name Subfield Subfield Length Subfield

Tag (bytes) Attribute
Acquirer additional transaction information AA Maximum 505 an
CUPSecure certification information IN Maximum 255 ans
Installment information IP 062 n
Recurring, primary credit and commission relationship PZ 137 ans
related transaction information
Transaction relevance AO 002 an
Sub-merchant information PM 055 ans
Stand-in authorization additional information SI 026 ans
Stand-in authorization parameter synchronization AG 064 ans

UPI CONFIDENTIAL 80
 Part II: Online Message

Subfield Name Subfield Subfield Length Subfield

Tag (bytes) Attribute
information
Order number ON 040 ans
Settlement currency information of specific Merchants CC 004 an

3.37.11.3 Usage
Field 48 Usage AS is used in multiple combinations, for example, Usage AS+AO+ON, in the following format:

054 AS AO 002 XX ON 040 XXXXXXXX...XXXXX

Total Usage Subfield 1 Subfield 1 Subfield 1 Subfield 2 Subfield 2

Subfield 2 Value
Length Identifier Tag Length Value Tag Length

Figure 11 Example of Field 48 Usage AS+AO+ON Combination

 Subfield Value
The format of the subfield value depends on the subfield tag, with maximum length of 510 bytes:
3.37.11.4 Tag AA: Acquirer Additional Information
Table 49 The Sequence and Value Information of Tag AA

Seq. Description Attribute Description

1 Tag a2 Valid value:
Identifier AA- Acquirer additional information
2 Tag length n3 Valid value:
026
3-4 Tag Value Please refer to Table 41 The Sequence and Value information of Usage AA Seq.
2-3 for detailed information.
Note: The subfield “Free text” with maximum 484 bytes exists when Usage AA
is used exclusively. It does not exist in combination usage due to the total
length limit.

3.37.11.5 Tag IN: CUPSecure Certification Information

Please refer to 3.37.5 for detailed information.
Table 50 The Sequence and Value Information of Tag IN

Seq. Description Attribute Description

1 Tag a2 Valid value:
Identifier IN- CUPSecure Certification Information
2 Tag length n3 Valid values:
001~255
3 Tag Value Please refer to Table 44 The Sequence and Value Information of Usage IN Seq.

UPI CONFIDENTIAL 81
 Part II: Online Message

Seq. Description Attribute Description

2 for detailed information.

3.37.11.6 Tag IP: Installment Payment

Please refer to 3.37.6 for detailed information.
Table 51 The Sequence and Value Information of Tag IP

Seq. Description Attribute Description

1 Tag a2 Valid value:
Identifier IP- Installment Payment
2 Tag length n3 Valid values:
062
3-5 Tag Value Please refer to Table 45 The Sequence and Value Information of Usage IP Seq.
2-4 for detailed information.

3.37.11.7 Tag PZ: Recurring, Primary Credit and Commission Relationship Related Transactions
Information
This field is used to store the information related to commission relationship and recurring/primary credit
transactions. The sequence and value of information are shown in the following table:
Table 52 The Sequence and Value Information of Tag PZ

Seq. Definition Attribute Description

1 Subfield tag a2 Valid value:
PZ- Recurring, primary credit and commission relationship related
transactions information
2 Subfield length n3 Valid value:
137
3 User ID category ans2 Valid values:
01- Mobile phone (in terms of payment method, it means paid
through mobile phone)
02- Fixed phone (in terms of payment method, it means paid through
fixed phone)
03- Water
04- Electricity
05- Gas
06- Social security
07- Ling tong card
08- Credit card repayment
09- Tobacco
10- Credit card center
11- Cable bill
12- Insurance
13- Tax
14- Security firms

UPI CONFIDENTIAL 82
 Part II: Online Message

Seq. Definition Attribute Description

15- Financial institution
16- Loans
CS- Financial taxes
RZ- Merchant bills
OT- Others
4 User ID (payment ans40 Used to store information of payment item in primary credit
item) transactions
5 Region code ans4 Not applicable to Members outside of Mainland China
6 Additional region ans4 Not applicable to Members outside of Mainland China
code
7 Payment method n1 Valid values:
tag 0- CAT transaction
2- Commissioned Merchant
8 Payment method ans2 If the payment method tag is not “0”, it shall be filled with spaces.
type
Valid values:
01- Via text message
02- Via voice mail
03- Via UnionPay Member
9 Payment method ans40 If the payment method tag is not “0”, it shall be filled with spaces.
number
The length of phone number may vary by country.
Other methods are at the operator’s discretion.
10 Time span of n3 Calculated by month. If it is filled by “000” or blanks, it is of long
commission validity; if it is filled by other numbers, it indicates the valid month
relationship number since transaction initiation date. Its maximum value is 999.
11 Maximum n12 12-digit fixed length number. The last two digits are decimal
mandatory amount numbers. This field is filled with 0 when no maximum mandatory
amount is applicable.
12 Minimal n12 12-digit fixed length number. The last two digits are decimal
mandatory amount numbers. This field is filled with 0 when no minimum mandatory
amount is applicable.
13 Payment period ans17 The format is yyyymmdd-yyyymmdd, indicating the starting and
ending dates of the payment period.
It represents the billing period in recurring transactions and the
payment period in primary credit transactions.
14 Payment frequency ans6 Reserved (Applicable in Mainland China only)
 Usage:
For a recurring transaction, it is optional for the Acquirer to send F48 of Usage AS+PZ in a request message for
providing the information of user ID category, user ID, region code and payment period (region code refers to country
code, and other fields shall be filled with default values if the value cannot be provided).
For tax refund program in primary credit transaction, F48 of Usage AS+PZ could be filled by the Acquirer.

UPI CONFIDENTIAL 83
 Part II: Online Message

For cash rebate program in primary credit transaction, Usage CB (refer to Section 3.37.9) will be used instead.
The establishment/revocation of commission relationship is only used in Thailand e-commerce transactions currently.
3.37.11.8 Tag AO: Transaction Relevance
It is used to indicate the business type related to the transaction, which is generally the account verification
transaction or commission relationship related transaction. If it is the account verification transaction, the Acquirer
shall submit Field 48 in the request message.
The sequence and value of information are shown in the following table:
Table 53 The Sequence and Value Information of Tag AO

Seq. Definition Attribute Description

1 Subfield tag a2 Valid value:
AO- Transaction relevance information
2 Subfield n3 Valid value:
length 002
3 Transaction an2 The valid values of transaction relevance tag are listed as follows:
relevance
tag Value Value Definition Note
01 Card-present Commission relationship required when
Cardholder- used at household terminals
activated Terminal
(CAT) Purchase
02 Card-not-present Commission relationship required when
(CNP) self-service used at card-no-present terminal
Purchase
03 E-commerce To be specified separately
04 MO/TO Account verification can be adopted
before transaction is initiated.
09 Recurring Account verification and commission
relationship establishment can be
adopted.
10 Primary credit Account verification can be used before
transaction is initiated.
12 One-time password It indicates the account verification
(OTP) triggering in transaction is followed by payment in
card-not-present CNP self-service purchase. Upon
self-service receiving value ‘12’, the Issuer sends the
transaction OTP to the Cardholder. After receiving
the subsequent CNP self-service
purchase transaction, the Issuer then
completes the CNP payment of the
corresponding bankcard.
13 OTP triggering in The Issuer sends the OTP to the
card-not-present Cardholder.
establishment of

UPI CONFIDENTIAL 84
 Part II: Online Message

Seq. Definition Attribute Description

commission
relationship
14 Card-not-present To implement card-not-present self-
self-service service purchase establishment and
purchase revocation in commission establishment
establishment and and suspension
revocation
18 OTP triggering in It is used for card status inquiry and
card-not-present payment in card-not-present self-service
self-service transaction for UnionPay online payment.
transaction The Issuer sends the OTP to the
Cardholder, and if the card status is
normal, returns the last 4 digits of the
Cardholder’s mobile phone number to
the Acquirer (by using Usage AS+SE in
Field 57). The Issuer then processes the
payment in subsequent CNP self-service
purchase.
28 OTP triggering in Upon receiving value “28”, the Issuer
CNP self-service shall send the OTP to the Cardholder. The
transaction for Issuer then decides its verification mode
UnionPay mobile according to the value of F61.6 Usage AM
payment service Byte 10.
29 Cardholder Upon receiving value “29”, the Issuer
information shall verify the Cardholder’s information,
verification in CNP including PAN (if present) and other CNP
self-service verification elements (if the
transaction for corresponding indicator in F61.6 Usage
UnionPay mobile AM = 1).
payment service

 Usage:
Account verification transaction is an optional transaction for Members outside of Mainland China. Field 48 Usage
AS+AO can be used in many transaction scenarios, including:

MO/TO (value “04”). The Acquirer can initiate account verification transaction before the MO/TO transaction based
on its own business needs. It can be used together with Field 61 for Cardholder verification.

Recurring and primary credit (value “09”/“10”). The Acquirer can initiate account verification transaction before the
recurring and primary credit transaction based on its own business needs. It can be used together with Field 61 for
Cardholder verification. Please refer to Field 104 Usage BI for available business types of primary credit transactions,
and account verification transaction is temporarily not used in combination with primary credit transactions outside
of Chinese Mainland.

Card-not-present self-service transaction (value “12”/“18”). The Acquirer can initiate account verification transaction
before the card-not-present self-service transaction for UnionPay online payment. It can be used together with Field
57 or Field 61 to complete the following 2 actions:

UPI CONFIDENTIAL 85
 Part II: Online Message

 Inquire about the card status (the card status should be returned by the Issuer in Field 57, and the last 4 digits
of the Cardholder’s mobile phone number should be returned by the Issuer if the card status is normal)

 Trigger OTP (afterwards, the Acquirer should send OTP in Field 61 for verification)

Card-not-present self-service transaction for UMPS (value “28”/“29”). The UMPS may initiate account verification
transaction before the CNP self-service transaction for mobile payment. The Issuer outside of Mainland China decides
its verification mode using the combination of Field 48 Usage AS+AO with Field 61.6 Usage AM.

Note: Card-not-present self-service transaction message has the same format as general purchase, pre-authorization,
and authorization messages. It can be differentiated from general purchase, pre-authorization, and authorization by
the first 2 bytes of Field 22 (value “01”- card-not-present) and Field 60.3.5 (value “2”- unattended).

The establishment/revocation of commission relationship is only used in Thailand e-commerce transactions currently.

3.37.11.9 Tag PM: Sub-merchant Information

It is sent by the Acquirer to indicate the Merchant ID and address information in the card-no-present self-service
transactions.
Table 54 The Sequence and Value Information of Tag PM

Seq. Description Attribute Description

1 Subfield tag a2 Valid value:
PM- Sub-merchant information
2 Subfield length n3 Valid value:
055
3 Sub-merchant ID ans15 Used to indicate the sub-merchant ID
4 Sub-merchant name ans40 Used to indicate the name and address of the sub-merchant.
& address Compliance with the UPI Operating Regulations is required.
Card-Not-Present self-service transaction message has the same format as purchase, pre-authorization, and
authorization messages. It can be differentiated from general purchase, pre-authorization, and authorization by the
first 2 bytes of Field 22 (value “01”- card-not-present) and Field 60.3.5 (value “2”- CAT).
It’s optional for the Acquirer to send this usage in Card-Not-Present self-service transaction.
3.37.11.10 Tag SI: Stand-in Authorization Additional Information
Please refer to 3.37.9 for detailed information.
3.37.11.11 Tag AG: Stand-in Authorization Parameter Synchronization Information
It is used to synchronize parameter of stand-in authorization. Tag AG is listed as follows when it is used for sending the
black card list for stand-in authorization.
Table 55 The Sequence and Value Information of Tag AG

Seq. Definition Attribute Description

1 Subfield tag a2 Valid value:
AG- Stand-in authorization parameter synchronization information
2 Subfield length n3 Valid value:
064

UPI CONFIDENTIAL 86
 Part II: Online Message

Seq. Definition Attribute Description

3 Parameter type a3 Valid value:
STP- Synchronize black card list parameter record
4 The Issuer’s an11 Filled with spaces when it is less than 11 digits.
Institution
Identification Code
5 Operation indicator a1 Valid values:
I- Add the record
U- Renew corresponding record
D- Delete corresponding record
6 PAN length n2 Filled with the actual length of the PAN.
7 PAN n19 Filled with spaces when it is less than 19 digits.
8 Description ans20 Reserved for the Issuer.
9 Expiry date n8 Filled with the expiration date of the record whose format is
YYYYMMDD. If the system time is later than the recorded time, the
card is regarded as expired and this field is filled with spaces.
 Usage:
In Stand-in Authorization Parameter Update Advice (0620), the presence of F48 Usage AS + AG is mandatory.
3.37.11.12 Tag ON: Order Number Information
It is used by the Acquirer to send the Merchant-provided purchase order number to the Issuer via the account
verification transaction. For account verification transaction that is used to trigger OTP, it is required to use tag ON
in Usage AS to submit order number information.
For purchase, pre-authorization, pre-authorization completion, recurring, and authorization transactions, the
Acquirer can transmit order number information via Usage AS+ON in Field 48.
Table 56 The Sequence and Value Information of Tag ON

Seq. Definition Attribute Description

1 Subfield tag a2 Valid value:
ON- Order number information
2 Subfield length n3 Valid value:
040
3 Order Number ans40 Used to label the order number provided by the Merchant.
 Usage:
If account verification transaction is used to trigger OTP in card-not-present self-service transaction for UnionPay
online payment, it is mandatory for the Acquirer to fill F48 Usage AS + AO + ON in order to submit order number
information.
3.37.11.13 Tag CC: Settlement Currency Information of Specific Merchants
Tag CC is used for marking the agreed settlement currency of overseas Merchants and shall be submitted by Acquirers.
With the tag CC, RMB will be the settlement currency between UnionPay and Acquirers as well as Acquirers and
Merchants instead of the original settlement currency.
The sequence and value of information are shown in the following table:

UPI CONFIDENTIAL 87
 Part II: Online Message

Table 57 The Sequence and Value Information of Tag CC

Seq. Definition Attribute Description

1 Subfield tag a2 Valid value:
CC- Settlement currency information of specific merchants
2 Subfield length n3 Valid value:
004
3 Specific settlement n1 Used to mark whether to activate the specific currency settlement
currency indicator function.
Valid values:
0- specific currency settlement function not activated
1- specific currency settlement function activated
4 Settlement an3 Used to mark the type of the settlement currency. Please refer to ISO
currency 4217 standard and the Technical Specifications on Bankcard
Interoperability - Part VI Annex for details.
 Usage:
In RMB settlement transactions, F48 (Usage AS + CC) must be present in the following messages sent by Acquirers
for marking the settlement currency of such transactions as RMB:
 Purchase/MOTO Purchase
 Authorization/ MOTO Authorization
 Pre-Authorization/MOTO Pre-Authorization
 Pre-Authorization Completion (Advice)/MOTO Pre-Authorization Completion (Advice)
 Refund (online)
 Online recurring
It is not necessary for tag CC to appear in the reversal message sent by the Acquirer, and it is optional to appear in
the cancellation message.
Note: Please pay attention to the usage of F48 in some types of transactions. For example, in recurring transactions
which are settled in RMB, Acquirers shall use combined usage AS + PZ + CC in the message.

Reject Code
10483= Invalid characters in the length field
10484= length value exceeds 512
10485= invalid characters

UPI CONFIDENTIAL 88
 Part II: Online Message

3.38 Field 49 Currency Code, Transaction

Attribute
an3, 3 alphabetic and numeric characters with fixed length

Description
It identifies the currency for Field 4 Amount, Transaction.

Usage
Please refer to Section A.5 Country/Region and Currency Code in the Technical Specifications on Bankcard
Interoperability - Part VI Annex, which is consistent with ISO 4217 standard.
Note: UnionPay uses numeric currency code.

Reject Code
10495＝invalid characters

UPI CONFIDENTIAL 89
 Part II: Online Message

3.39 Field 50 Currency Code, Settlement

Attribute
an3, 3 alphabetic and numeric characters with fixed length

Description
It embodies settlement currency. It is used to designate the currency of Field 5 Amount, Settlement.
This field is filled by GSCS.
Usage
Please refer to Section A.5 Country/Region and Currency Code in the Technical Specifications on Bankcard
Interoperability - Part VI Annex, which is consistent with ISO 4217 standard.
When the settlement currency and the transaction currency are different, the settlement currency must be identified
in the settlement request message and response message.
Note: UnionPay uses numeric currency code.

Reject Code
10505= invalid code

UPI CONFIDENTIAL 90
 Part II: Online Message

3.40 Field 51 Currency Code, Cardholder Billing

Attribute
an3, 3 alphabetic and numeric characters with fixed length

Description
This field contains the Cardholder billing currency.

Usage
The field only exists in the international transaction message. It is filled by GSCS, and is used to identify the currency
code of Field 6 (Amount, Cardholder Billing). If Field 6 (Amount, Cardholder Billing) appears, the field is required.
Please refer to Section A.5 Country/Region and Currency Code in the Technical Specifications on Bankcard
Interoperability - Part VI Annex, which is consistent with ISO 4217 standard.
Note: UnionPay uses numeric currency code.
Reject Code
10515＝invalid characters

UPI CONFIDENTIAL 91
 Part II: Online Message

3.41 Field 52 PIN Data

Attribute
b64, 64 bits binary data

Description
Cipher text of PIN

Usage
If Field 22 Point Of Service Entry Mode Code identifies that the PIN is entered, the field must appear. The PIN must
been encrypted before it is put into this field. The format of PIN and the encrypting algorithm are designated in Field
53 Security Related Control Information.
The maximum length of PIN is 12 digits. For the detailed algorithm, please refer to the Technical Specifications on
Bankcard Interoperability - Part IV Data Secure Transmission Control.
Reject Code
N/A

UPI CONFIDENTIAL 92
 Part II: Online Message

3.42 Field 53 Security Related Control Information

Attribute
n16, 16 numeric characters with fixed length

Description
The control information related to security.

Usage 1: Usage in Key Management Message

The field is used in the key management message (0800/0810 and 0820/0830). The data structure is defined as
follows:
Table 58 Field 53 Data Structure Definition in Key Management Message

Seq. Definition Attribute Description

1 Key Type n1 Used to indicate the type of the key being reset.
Valid values:
1- PIK
2- MAK
2 Data Key n1 Used to indicate the encryption algorithm or MAC calculation algorithm
Algorithm of the key being reset.
Valid values for PIK:
0- Single-length DES
6- Double-length TDEA
7- Triple-length TDEA
Valid values for MAK:
0- Single-length Key Algorithm
6- Double-length Key Algorithm
7- Triple-length Key Algorithm
3 Key Format n1 Used to indicate the format of the key being reset.
Valid values:
0- ECB enciphered key (corresponding to Field 48 Usage NK)
1- ANXI X9 TR-31 key block format key (corresponding to Field 48 Usage
KB)
4 Reserved n13 Reserved for use. Filled with all “0”s.

Usage 2: Usage in Transaction Message

The field is used to identify the PIN type in the transaction message. The data structure is defined as follows:
Table 59 Field 53 Data Structure Definition Transaction Message

Seq. Definition Attribute Description

1 PIN Format Used n1 Used to indicate the format of PIN.
Valid values:
1- ANSI X9.8 Format (without PAN)
2- ANSI X9.8 Format (with PAN)

UPI CONFIDENTIAL 93
 Part II: Online Message

Seq. Definition Attribute Description

2 PIN Encryption Algorithm n1 Used to indicate the PIN encryption algorithm.
Valid values:
0- Single-length DES
6- Double-length TDEA
7- Triple-length TDEA
3 Reserved n14 Reserved for use. Filled with all “0”s.
Note: For the ANSI X9.8 PIN Format, please refer to the Technical Specifications on Bankcard Interoperability -
Part IV Specification on Data Security Transmission Control.

Reject Code
10535= invalid characters

UPI CONFIDENTIAL 94
 Part II: Online Message

3.43 Field 54 Additional Amounts

Attribute
an..040(LLLVAR), 3-byte length value + maximum 40 bytes alphabetic and numeric characters

Description
The field is divided into two sections, i.e. the ledger balance amount and the available balance amount.
The ledger balance amount is the amount of the fund in the account. For a saving account, the ledger balance is the
usable amount of actual balance in the account. For a credit account, when excessive payable exists, the ledger
balance amount is excessive payable amount (positive); when this credit card is in overdraft condition, the ledger
balance amount is overdraft amount (negative).
The available balance amount is the amount which can be used on the current day. No matter what type of account
it is, it shall be combined with the transaction type and the terminal type where the transaction is initiated for
consideration. If the combination of these two elements is subject to the requirement of current-day accumulative
or accumulative transaction amount limit, then the available balance amount = current-day accumulative or
accumulative transaction amount limit - current-day used transaction amount; if the current-day accumulative or
accumulative transaction amount limit does not exist, or the current ledger balance amount is less than the
difference calculated before, then the available balance amount shall be equal to its ledger balance amount. For
example, for the ATM cash withdrawal transaction of the saving account, the available balance amount = ATM cash
withdrawal current-day accumulative amount - current-day accumulative withdrawn amount. For POS inquiry
transaction of credit card account, the available balance amount = accumulative usable expenditure - used
expenditure; for ATM cash withdrawal transaction of credit card account, the available balance amount = the lesser
of accumulative available withdrawal amount and current-day accumulative withdrawal amount - current-day
accumulative withdrawn amount. For E-commerce transaction on PC, the available balance amount = the lesser of
current-day expenditure amount set by the Cardholder, current-day accumulative expenditure amount limit of the
Issuer, and usable expenditure amount - current-day accumulative used expenditure amount.
During a POS purchase transaction, if the balance is not sufficient, the Issuer may respond with the available balance
amount of the Cardholder for reference.
When the field only has one section of balance, the balance amount (n12) of the other section is filled with all “0”s.

Usage
The name of the field is user-defined. The standard field “Additional Amounts” with variable length is adopted. The
length is 40. Twenty bytes compose a record and there are 2 records altogether. The content is defined as follows:

Account Balance Currency Balance Account Balance Currency Balance

Balance Balance
Type Type Code Symbol Type Type Code Symbol

n2 n2 an3 an1 n12 n2 n2 an3 an1 n12

Figure 12 The Sequence and Value Information of Field 54

If this field appears in the transaction message, it shall be present in the fixed format with the length of 40 bytes, as
indicated in the above figure. However, this field should be processed as variable length by the Member’s system,
that is, the actual length is indicated by 3-byte length value.
The values of the above data are listed as follows:
Table 60 Value of Data Item of Actual Balance Field

UPI CONFIDENTIAL 95
 Part II: Online Message

Seq. Definition Attribute Description

1 Account type n2 Valid values:
10- Saving account
20- Cheque account
30- Credit account
2 Balance type n2 Valid values:
01- Ledger balance amount
02- Available balance amount
3 Currency an3 If it is an RMB account, the field is filled with 156.
code
If it is a non-RMB account, the field is filled based on ISO currency code
standard.
Note: UnionPay uses numeric currency code.
4 Balance an1 Valid values:
symbol D- Debit amount (the amount is negative, representing account arrear age,
usable for credit card account)
C- Credit amount (the amount is positive, representing balance amount in
the account, usable for all account types)
5 Balance n12 If the transaction fails, the value is all “0”s.

Reject Code
10543= invalid characters in length field
10544= length value not equal to 40
10545= invalid characters

UPI CONFIDENTIAL 96
 Part II: Online Message

3.44 Field 55 IC Card Data

Attribute
ansb..255(LLLVAR), 3 bytes length value + maximum 255 bytes
Attributes of data supported:
 b: Binary (binary number or bit combination).
 cn: Binary Coded Decimal ("BCD").
Numeric data elements consist of two numeric digits (having values in the range Hex '0' - '9') per byte. These digits
are right justified with leading hexadecimal zeros.
Example: Amount, Authorized (Numeric) is defined as "Cn (including 12-digit valid number)" with a length of six bytes.
A value of 12345 is stored in Amount, Authorized as Hex '00 00 00 01 23 45'.
 an: Each byte includes an alphanumeric data element (A-Z, a-z, 0-9).
 var. up to N: A variable length of N at the maximum.
Description
This field will include different subfields according to different types of transactions. GSCS only forwards this unique
data for IC card transactions between the Acquirer and the Issuer, and will not change or process the data in any
manner. For the flexibility of filling the subfields, this field uses a TLV (tag-length-value) representation, i.e. each
subfield consists of tag (T), length of subfield value (L), and subfield value (V).
The attribute of tag is bit and is represented with a hexadecimal system occupying 1~2 bytes. For example, “9F33” is
a tag that occupies two bytes, while “95” is a tag that occupies one byte. If the last five bits of the first byte of the
tag (note: bytes are sequenced from the left to the right, so the first byte is the byte at the far left; bit sequencing
follows the same rule) are “11111”, it shows this tag occupies two bytes, e.g. “9F33”; otherwise the tag occupies one
byte, e.g. “95”.
The attribute of subfield length (i.e. L itself) is also bit with a length of 1~3 bytes. Specific coding rules are listed as
follows:
 When the far left bit of the far left byte of the L field (namely bit 8) is 0, it means the L field occupies one byte,
and the next 7 bits (namely bit 7~ bit 1) indicate the length of subfield value, with a binary number used to
represent the decimal value of the length of subfield value. For example, when a field value occupies 3 bytes,
its subfield length is represented by “00000011”. Therefore, if the length of subfield value is between 1~127
bytes, then the L field itself only occupies one byte.
 When the far left bit of the far left byte of the L field (namely bit 8) is 1, it means the L field occupies more than
one byte, and the decimal value of the next 7 bits (namely bit 7~ bit 1) determines the length of the field. For
example, if the far left byte is 10000010, it means the L field has another two bytes after this byte. The decimal
value of the following bytes indicates the length of the subfield value. For example, when the L field is “1000
0001 1111 1111”, it means the subfield values occupy 255 bytes. Therefore if the subfield value length is
between 128~255 bytes, the L field itself should occupy two bytes.
 If the value of L is “0”, then the value of V can disappear, but the system should be able to analyze the sub-field
correctly.
Subfields adopt different values based on different meanings of subfields. As the subfields of this field contain
information that is unique to IC cards and IC terminals instead of characteristic information of Switch Center, which
is only a bridge for data transmission, specific values of the subfields shall be determined with reference to IC cards
and IC card terminal specifications and change correspondingly as such specifications change. However, as all these
organizations (including UnionPay) define cards and terminals based on EMV2000 standards, the tags will be the
same regardless of the specific values adopted. Therefore only tags are provided in this document and network

UPI CONFIDENTIAL 97
 Part II: Online Message
institutions may use tags to find specific values of different organizations correspondingly. Tag, length value, and
attribute of each subfield are shown in the following tables.
In the procedure of a transaction, Members should be able to process all the subfields in the definition of Field 55.
The Acquirer needs to submit subfields according to its actual business needs, while the Issuer may choose to decline
the transaction if a certain subfield is not supported. System abnormality and transaction outage should be avoided.
Usage
Table 61 List of Basic Information Subfields of Field 55

Subfield Name Tag Length (byte) Attribute

Application Cryptogram (AC) 9F26 8 b
Cryptogram Information Data 9F27 1 b
Issuer Application Data (IAD) 9F10 Maximum 32 b
Unpredictable Number 9F37 4 b
Application Transaction Counter (ATC) 9F36 2 b
Terminal Verification Result (TVR) 95 5 b
Transaction Date 9A 3 cn (including a 6-digit valid number,
format YYMMDD)
Transaction Type 9C 1 cn (including a 2-digit valid number)
Transaction Amount or Amount 9F02 6 cn (including a 12-digit valid number)
Authorized a
Transaction Currency Code 5F2A 2 cn (including a 3-digit valid number)
Application Interchange Profile 82 2 b
Terminal Country Code 9F1A 2 cn (including a 3-digit valid number)
Amount Other 9F03 6 cn (including a 12-digit valid number)
Terminal Capabilities 9F33 3 b
Note a: For an IC card transaction, the value of 9F02 tag in Field 55 records the transaction amount transmitted
from terminal to IC Card. This value could be the same as, or different from, the value in Field 4, which indicates
the actual transaction amount charged to the Cardholder.

Table 62 List of Additional Information Subfields of Field 55

Subfield Name Tag Length Attribute

(byte)
Cardholder Verification Method Result 9F34 3 b
(CVMR)
Terminal Type 9F35 1 cn (a 2-digit valid number)
Interface Device Serial Number (IFD) 9F1E 8 an
Dedicated File Name (DF) 84 5~16 b
Terminal Application Version Number 9F09 2 b

UPI CONFIDENTIAL 98
 Part II: Online Message

Subfield Name Tag Length Attribute

(byte)
Transaction Sequence Counter 9F41 2~4 cn (including a 4-digit to 8-digit valid
number)
Issuer Authentication Data 91 8~16 b
Issuer Script Template 1 71 1~128 b
Issuer Script Template 2 72 1~128 b
Issuer Script Results DF31 5~21 b
Issuer Authorization Code-Electronic Cash 9F74 6 an
(ECIAC)
Card Product Identification Information 9F63 16 b

Note: When the QRC data contains chip information, the Acquirer shall submit chip information in Field 55
with the same transmission requirements.
Reject Code
10553= Invalid characters in length field
10554= Length value exceeds 255
10555= Invalid character

UPI CONFIDENTIAL 99
 Part II: Online Message

3.45 Field 56 Token Payment Account Reference (PAR)

Attribute
ansb..512(LLLVAR), 3-byte length value + maximum 512 bytes alphabetic, numeric, and special characters and binary
numbers
Description
This field is defined as a multiple usage field to transmit detailed transaction and industry application information,
etc.
The general format of this field is:
<Field length><Usage ID1><Usage ID1 length><Usage ID1 content (TLV element)>...<Usage IDn><Usage IDn
length><Usage IDn content (TLV element)>
Note: The usage can be used separately or in a combined way based on different transaction scenarios.
The following table illustrates the format of Field 56:
Table 63 The General Format of Field 56

Field Usage Usage ID 1 Usage ID 1 Content .. Usage Usage ID n Usage ID n Content

Length ID 1 Length (TLV Element) ID n Length (TLV Element)
n3 an2 n3 ansb..507 an2 n3 ansb..507

Table 64 The Usages in Field 56

Usage Definition Usage Identifier Attribute

Token PAR account reference PR ans..512

Usage PR: Token Payment Reference Number

3.45.3.1 Attribute
ans..512, 2-byte usage identifier + 3-byte Usage length + maximum 507 bytes sub-TLVs
3.45.3.2 Description
It is used to transmit the reference number of Token Payment transaction.
The value of the usage is PR + 3 bytes of total length of Usage PR Content + subTLV1 + subTLV2 + .... + subTLVn. According
to different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence. TLV
format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 65 The Sub-TLVs of Usage PR

Definition Tag Format Description

PAR 01 an29 PAR enables Merchants, Acquirers and Payment Processors to link
transactions initiated with affiliated Payment Tokens to transactions based on
the underlying PAN. The PAR Data is a composite field consisting of 29
alphanumeric characters with two components:
Position Definition
Byte 1~4 Registered BIN Controller Identifier assigned by EMVCo

UPI CONFIDENTIAL 100

 Part II: Online Message

Definition Tag Format Description

Byte 5~29 Unique value assigned to each underlying PAN

Reserved 02 ans..471 Reserved for use.

3.45.3.3 Usage
When the Token is generated by UPI TSP, the transmission requirement of Usage PR is listed as follows:
 Transmission Requirements of Usage PR in Request Transactions
Table 66 Transmission Requirements of Usage PR in Request Transactions

Definition Tag Format Transmission Description

Requirements
AC SW IS SW
PAR 01 an29 C6+ C6+ For a token-based transaction, Usage PR will be present
in request messages if the Issuer opts to receive Field 56
Usage PR, and present in response messages if the
Acquirer opts to receive Field 56 Usage PR.
 Transmission Requirements of Usage PR in Advice Transactions
Table 67 Transmission Requirements of Usage PR in Advice Transactions (ACSW)

Definition Tag Format Transmission Description

Requirements
AC SW
PAR 01 an29 C6+ For a token-based transaction, Usage PR will be present in
response messages if the Acquirer opts to receive Field 56
Usage PR.

Table 68 Transmission Requirements of Usage PR in Advice Transactions (SWIS)

Definition Tag Format Transmission Description

Requirements
SW IS
PAR 01 an29 C6+ For a token-based transaction, Usage PR will be present in
advice messages if the Issuer opts to receive Field 56
Usage PR.

Reject Code
10563= Invalid character in the length field
10564= Length value exceeds 512
10565= Invalid character

UPI CONFIDENTIAL 101

 Part II: Online Message

3.46 Field 57 Issuer Additional Data - Private

Attribute
ans..100(LLLVAR), 3-byte length value + additional transaction data of maximum 100 bytes alphabetic, numeric and
special characters
Description
This field is defined by ISO as private-use field. This document defines multiple usages for this field.
The general format is listed as follows:
Table 69 The General Format of Field 57 Issuer Additional Data-Private

Field Length Usage Identifier Data

3 bytes 2 bytes maximum 98 bytes
 <Field Length>
It indicates the total length (including the field identifier) of this field, i.e. 3 bytes.
 <Usage Identifier>
It indicates the type of the data following the field identifier, with the length of 2 bytes. Valid values include:
“CI” – Cardholder Information
“IP” – Installment Payment
“AS” – Usage Combination
 <Data>
It contains the detailed data. The format is defined by <field identifier> and the maximum length is 98 bytes.
• For data composition of Usages CI and IP, please refer to the descriptions below of each usage.
• Exceptionally, Usage AS adopts TLV (tag-length-value) composition, to meet the demand of combined usage in
certain special transactions. Under this usage, each subfield consists of tag label (T), subfield length (L), and
subfield value (V). For detail description about Usage AS format, please refer to the introduction of Usage AS in
Field 48 (in 3.37.2).
During transaction processing, Members should be able to process all the usages and all the sub-usages within
Usage AS in Field 57. The Acquirer needs to submit usages according to its actual business needs, while the
Issuer may choose to decline the transaction if a certain usage is not supported. System abnormality and
transaction outage should be avoided.
Usage CI: Cardholder Information
3.46.3.1 Attribute
ans..100, 2-byte usage identifier + maximum 98 bytes (alphabetic, numeric and special characters)
3.46.3.2 Description
In processing some transactions like remittance verification, the Issuer needs to return information such as
Cardholder name, to make it convenient to verify the Cardholder’s information.
The sequence and value of this usage are listed as follows:
Table 70 The Sequence and Value information of Usage CI

UPI CONFIDENTIAL 102

 Part II: Online Message

Seq. Definition Attribute Description

1 Usage an2 Valid value:
identifier CI- Cardholder information
2 Name ans20 Letter or Chinese character. If the subsequent field is present and this field
is less than 20 bytes, this field will be padded with spaces on the right.
3 ID type n2 Valid value:
01- Identification card
02- Serviceman Card
03- Passport
04- Home-Visiting Certificate
05- Taiwan Visitor Certificate
06- Police Card
07- Soldier Card
08- PBOC Travel Document
09- Foreign Passport
10- Foreigners Permanent Residence Card
11- Border Exit and Entry Permit
99- Other ID card
4 ID number ans20 Padded with spaces on the right if it is less than 20 bytes.
5 Other ans..54 Reserved for use.
information

3.46.3.3 Usage
It is mandatory for the Issuer to fill F57 of Usage CI with the Receiver’s name and Identification information in the
response message of Remittance Verification Transaction if the Issuer authorizes the transaction request. For security
consideration, GSCS will not forward the information to the Sending Institution.

Usage IP: Installment Payment

3.46.4.1 Attribute
ans85, 2 byte usage identifier + 83 bytes (alphabetic, numeric and special characters)
3.46.4.2 Description
This field is filled by the Issuer and is used to transmit the information associated with Installment Payment to the
Acquirer. It shall be present in the response message of the successful Installment Payment transaction.
The sequence and value of this usage are listed as follows:
Table 71 The Sequence and Value information of Usage IP

Seq. Definition Attribute Description

1 Usage identifier an2 Valid value:
IP- Installment payment information
2 First installment n12 It is filled by the Issuer (mandatory), right-justified, and left padded
amount with zeroes.
3 Installment n3 It is filled by the Issuer (mandatory), used to indicate the currency
payment currency code of the installment payment and commission fee for the
code Cardholder.

UPI CONFIDENTIAL 103

 Part II: Online Message

Seq. Definition Attribute Description

4 Cardholder n12 It is filled by the Issuer, right-justified, and left padded with zeroes. If
installment there is no fee, this field is filled with all 0s. The currency of the fee is
payment indicated in Sequence 3.
commission fee
This field means the amount of commission fee if the commission fee
is paid one time. This field means the total amount of commission
fee, if the commission fee is paid in terms.
Note: when the additional installment payment commission fee
exists, the Issuer should deduct the fee from installment payment
commission fee.
5 Reserved n6 Reserved for use.
6 Characteristic data ans50 Reserved for installment payment method. It is subdivided into
of installment installment payment character fields, including bonus, commission
payment fee payment methods, the installment payment and periodical
payment of commission fees, if it is not paid one time.
Subseq. Format Description
1 n12 Bonus
Filled with zeros if there is no bonus.
2 an1 Payment method. If the value is 0, it means
the commission fee is paid in one time; if the
value is 1, it means the commission fee is paid
in terms.
The Issuer must provide this information in
the response message.
3 n12 The commission fee of first installment
payment
Filled with zeros if subsequence 2 is 0. Issuers
must provide this information if subsequence
2 is 1.
4 ans12 Periodical commission fee
Filled with zeros if subsequence 2 is 0. The
Issuer must provide this information if
subsequence 2 is 1.
5 ans13 Reserved
Filled with spaces by default.

3.46.4.3 Usage
It is mandatory for the Issuer to fill F57 of Usage IP in the response message of installment payment purchase and
installment payment authorization, if the installment payment transaction is supported by the Issuer.
Note: It shall not be present in the response messages of installment payment reversal, installment payment
cancellation, installment payment cancellation reversal, installment payment authorization reversal, installment
payment authorization cancelation, and installment payment authorization cancelation reversal.

UPI CONFIDENTIAL 104

 Part II: Online Message

Usage AS: Usage Combination

3.46.5.1 Attribute
ans..100, 2-byte usage identifier + maximum 98 bytes (alphabetic, numeric and special characters)
3.46.5.2 Description
• This usage’s format is TLV, used to support the data transmission requirement in the following situations: The
combination of usages in the aforementioned sections as required by the UPI Operating Regulations
• The requirement to transmit data aside from Usage CI and IP (adding new tag in usage AS instead of adding new
usage)
Currently, the Tag defined in usage AS is listed in the following table:
Table 72 The Sub-TLVs of Usage AS

Subfield Name Subfield Subfield Subfield

Tag Length Attribute
Cardholder Information CI 042 ans
Installment Information IP 083 ans
Card-Not-Present self-service purchase establishment SE 023 ans
information
Additional Response Code AR 003 ans
Coupon Yield CY 064 ans

3.46.5.3 Usage
 <Subfield Value>
The format of the subfield value depends on the subfield tag, with maximum length of 510 bytes:
3.46.5.4 Tag CI: Cardholder Information
Please refer to Section 3.46.3 for detailed description.

Table 73 The Tag, Length and Value Information of Tag CI

Seq. Definition Attribute Description

1 Tag an2 Valid value:
identifier CI- Cardholder information
2 Tag length n3 Valid Value:
042
3-5 Tag value See Table 70 The Sequence and Value information of Usage CI (seq. 2-4) for
detailed information
Note: The subfield “Other information” with maximum 54 bytes exists when
Usage CI is used exclusively. It does not exist in combination usage due to the
total length limit.

3.46.5.5 Tag IP: Installment Payment

Please refer to Section 3.46.4 for detailed description.

UPI CONFIDENTIAL 105

 Part II: Online Message

Table 74 The Tag, Length and Value Information of Tag IP

Seq. Definition Attribute Description

1 Tag an2 Valid value:
identifier IP- Installment Payment
2 Tag length n3 Valid Value:
083
3-7 Tag value See Table 71 The Sequence and Value information of Usage IP (seq. 2-6) for
detailed information.

3.46.5.6 Tag SE: Card-not-present Self-service Purchase Establishment Information

It is used by the Issuer to send the last 4 digits of the Cardholder’s mobile phone number to the Acquirer in the
response message of Account Verification transactions, if the card status is normal.
The sequence and value of this usage are listed as follows:
Table 75 The Tag, Length and Value Information of Tag SE

Seq. Definition Attribute Description

1 Tag identifier an2 Valid value:
SE- Card-not-present self-service purchase establishment information
2 Tag length n3 Valid Value:
023
3 Card status an3 Filled with spaces by default.
Valid value for abnormal card status:
OFF- Card is frozen or suspended by the Issuer.
4 Mobile phone ans20 Used to store the masked digits and the last 4 digits of mobile phone
number number of the Cardholder, left-aligned, and right-fill spaces.
For example, the mobile phone number is 12345678, and ****5678 should
be returned.
 Usage:
It is mandatory for the Issuer to fill Field 57 of Usage AS+SE in the response message of Account Verification
Transaction, for returning the last 4 digits of the Cardholder’s mobile phone number to the Acquirer if the card status
is normal, when it recognizes the relevant transaction for account verification is Card-Not-Present self-service OTP
trigger and card status inquiry (Field 48 of Usage AS+AO, value “18”). Meanwhile, the Issuer shall sends the OTP to
the Cardholder (afterwards, the Acquirer shall send OTP in field 61.6 of Usage AM for verification).
3.46.5.7 Tag AR: Additional Response Code
In order to indicate the initiator of the response code in the response message in the case of transaction failure, and
elaborate the transaction scenario corresponding to the response code, the usage of AS+AR is to transmit more
detailed transaction failure information in the response message.
The sequence and value of this usage are listed as follows:
Table 76 The Tag, Length and Value Information of Tag AR

UPI CONFIDENTIAL 106

 Part II: Online Message

Seq. Definition Attribute Description

1 Tag identifier an2 Valid value:
AR- Additional response code
2 Tag length n3 Valid Value:
003
3 The indicator of the an1 Used to indicate the initiator of the response code.
response code
Valid values:
1- Response code provided by the GSCS
2- Response code provided by the Issuer
4 Detailed response code an2 Valid values:
00- Default value, indicating that no detailed response code will be
provided
01~99- Please refer to the Technical Specifications on Bankcard
Interoperability - Part VI Annex, Section A.2.2.
 Usage:
Currently, this usage is only applied in cross-border remittance (including remittance transaction and remittance
verification transaction). The usage AS+AR of Field 57 presented in other transactions can be omitted by the Acquirer.
For a detailed response code value definition, please refer to the “applicable condition” column in the Technical
Specifications on Bankcard Interoperability- Part VI Annex, Section A.2.2.
The usage AS+AR of Field 57 is used during cross-border remittance processing (including remittance transaction and
remittance verification transaction), if the Issuer presents the response code (F39) that is not included in the detailed
response code definition (the Technical Specifications on Bankcard Interoperability -Part VI Annex, Section A.2.2). If
the usage AS+AR of Field 57 is used, it can be omitted by the Acquirer.
For example, when the remittance verification transaction fails due to exceedance of single-transaction amount limit,
GSCS will return “61” in Field 39. Meanwhile, the detailed response code will be provided through Field 57 Usage
AS+AR (value: ASAR003107).
It is mandatory for the Issuer to fill Field 57 of Usage AS+AR in the response message of Remittance Verification
Transaction or Remittance Transaction if the response code of Field 39 is not “00”, for providing detailed failure
information.
3.46.5.8 Tag CY: Coupon Yield
Field 57 Usage AS+CY is adopted in UPI marketing program, such as instant discount program or exchange rate
discount program, to transmit discount details in response messages.
The sequence and value of this usage are listed as follows:
Table 77 The Tag, Length and Value Information of Tag CY

Seq. Definition Attribute Description

1 Tag identifier an2 Valid value:
CY- Coupon yield information
2 Tag length n3 Valid Value:
064
2 Original n12 The format of this sequence is the same as that of Field 4 Amount,

UPI CONFIDENTIAL 107

 Part II: Online Message

Seq. Definition Attribute Description

Amount Transaction.
3 Discount n12 The deduction amount of the discount coupon. It is in the currency
Amount indicated by Field 49. The format of this subfield is the same as that of Field
4 Amount, Transaction.
In exchange rate discount program, this field is filled with all 0s.
4 Discount ans20 Padded with spaces on the right if the information is less than 20 bytes.
Description
The discount description may vary according to the specific discount
program. The information can be displayed in the Merchant receipt or the
terminal screen (if it exists).
For example, in instant discount program, the format is “Discount: X”,
where X is the value of Discount Amount, with the preceding 0s removed
and a decimal point added according to the precision of the transaction
currency, e.g., 10.00 in HKD.
In exchange rate discount program, this field is filled with “UnionPay”.
5 Payment ans20 Padded with spaces on the right if the information is less than 20 bytes.
Description
The payment description may vary according to the specific discount
program. The information can be displayed in the Merchant receipt or the
terminal screen (if it exists).
For example, in instant discount program, the format is “Paid: X”, where X is
the result of Original Amount minus Discount Amount, with the preceding
0s removed and a decimal point added according to the precision of the
transaction currency, e.g., 90.00 in HKD.
In exchange rate discount program, this field is filled with “better exchange
rate”.
 Usage:
It is used by the GSCS to send Field 57 Usage AS+CY in the response message of purchase, authorization, pre-
authorization, pre-authorization completion (request and advice) and cash withdrawal transactions.

Reject Code
10573= Invalid character in the length field
10574= Length value exceeds 100
10575= Invalid character

UPI CONFIDENTIAL 108

 Part II: Online Message

3.47 Field 60 Self-Defined Field

Attribute
ans..100(LLLVAR), 3-byte length value + data of maximum 100 bytes alphabetic, numeric, and special characters

Description
This is a self-defined field. It includes the following subfields.
Table 78 Composition of Field 60

Position Byte 1~4 Byte 5~15 Byte 16~30 Byte 31~100

Subfield 60.1 60.2 60.3 Reserved for future use.

Field 60.1 Message Reason Code

3.47.3.1 Attribute
n4, 4-byte number
3.47.3.2 Description
This field is filled by the message sender in the message of reversal. It is used to describe the reason for sending the
message. 0000 is filled when not applicable.
For detailed reason code, please refer to Appendix A Code Definitions in the Technical Specifications on Bankcard
Interoperability - Part VI Annex.

Field 60.2 Additional Point of Service Information

3.47.4.1 Attribute
ans11, 11-byte letters, numbers or special characters with a fixed length
3.47.4.2 Description
It is used to distinguish the differences of transactions with the same transaction type in the initiating method,
location, or terminal (ATM, POS, counter, the Internet, etc.).
This field is divided into 9 sub-fields:
Table 79 The Sequence and Value Information of Field 60.2

Position Definition Attribute Description

Byte 5 F60.2.1: Account ans1 It indicates the account holder type. For example, individual card
Holder Type account, corporate card account, etc. If Account Holder Type is
not certain, fill with default value “0” (Individual card account).
Valid values:
0- Individual card account
1- Individual non-card account
2- Corporate non-card account
3- Corporate card account
9- Unknown or irrelevant Account Holder Type
Byte 6 F60.2.2: Terminal n1 It indicates whether the terminal could read the IC card in IC
Entry Capability card transaction.
Valid values:

UPI CONFIDENTIAL 109

 Part II: Online Message

Position Definition Attribute Description

0- Unknown
2- Magnetic stripe read capability
5- Chip-capable terminal, contact IC card read capability:
optional to read magnetic stripe card, cannot read contactless IC
card.
6- Chip-capable terminal, contactless IC card read capability:
optional to read magnetic stripe card and magnetic stripe card.
Byte 7 F60.2.3: Chip n1 It indicates whether the IC card reading capability of IC card
Condition Code a terminal is available when IC card magnetic information on it is
used. Whether the card or terminal is damaged can be judged
according to the field value. At the same time whether it is a
counterfeit card transaction can also be judged.
Note a: Fallback transaction is a defective transaction in IC card
transactions. It refers to the transactions conducted via swiping
the magnetic stripe instead of chip reading due to malfunction in
the chip or chip-reading terminal. The values in Field 60.2.2,
Field 60.2.3 and Field 22 jointly feature the fallback transaction.
Detailed value combination is shown in the description of
F60.3.6 (Transaction Medium).
Valid values:
0- Not applicable, subsequent subfields are present
1- Last read was not a chip transaction or was a successful chip
transaction. If the value is 1, it means that the transaction is
conducted through direct magnetic stripe swiping without
inserting for chip reading, which is not a standard operation.
2- Last read at terminal was a chip transaction, but the
transaction failed, e.g., chip had been used as the transaction
channel yet could not read the application. The terminal read
the magnetic stripe instead. The very last transaction of this
magnetic stripe transaction is the failed chip card reading
transaction and therefore value 2 shall be used. Using value 2
means that a fallback transaction happened because of
malfunction of either chip or terminal.
Byte 8 F60.2.4: Reserved ans1 Filled with 0.
Byte F60.2.5: Terminal n2 Refer to F60.2.9 for description details. b
9~10 Type
Byte 11 F60.2.6: Signature- This Identifier includes 2 Usages: 1) Signature-Only Indicator: the
only value is a decimal number code. It is used to indicate whether
Indicator/Receiver’ the Acquirer’s network is secure enough to be allowed to submit
s Currency the transaction without PIN information. This Identifier is
Indicator provided by GSCS to the Issuer for informing the Issuer whether
the Acquirer or the Merchant has joined Signature-based Credit
Card Network or not. 2) Receiver’s Currency Indicator indicates
the Receiver’s account currency requirement in cross-border
remittance.
Valid values for cross-border remittance:

UPI CONFIDENTIAL 110

 Part II: Online Message

Position Definition Attribute Description

0- The recipient currency is the primary currency of the
receiver’s account.
2- The recipient currency is the original currency of funds
remitted by the sender.
Valid values for other transactions:
0- Non Signature-based Credit Card Network
1- Signature-based Credit Card Network
Byte 12 F60.2.7: IC Card n1 It indicates the reliability of the card authentication in IC card
Authentication transaction. The Acquirer will set the value when problems occur
Reliability Identifier to the Merchant or terminal c; or GSCS will set the value when
either the Acquirer or the Issuer cannot carry out card
authentication. In Payment Token transaction, this subfield
allows the Issuer to recognize that the transaction has been
applied with Token Service provided by UnionPay.
Note c: The Acquirer shall fill this value with either “0” or “1”.
Valid values:
0- This subfield or subsequent position/s are present.
1- The Acquirer indicates that Card Authentication may not be
reliable.
2- The Switch Centre indicates the Acquirer inactive for Card
Authentication.
3- The Switch Centre indicates the Issuer inactive for Card
Authentication.
4- The Switch Centre indicates that the transaction has applied
with Token Service provided by UnionPay.
Byte F60.2.8: E- n2 For e-commerce transactions, it indicates the security status of
13~14 commerce transaction in an open network (e.g., the Internet). It is used to
Identifier (ECI) tag UP3DS Authentication Mode, Issuer Authentication Mode
and Issuer Non-Authentication Mode in card-no-present self-
service transactions. The identifier is provided by the Acquirer
and will be switched by GSCS to the Issuer for verification in
request and advice messages. If it could not be verified by the
Issuer or the Issuer chooses not to receive it, it will be truncated
in switching.
Valid values:
00- Not applicable
01- Conducted UnionPay safe entry mode authentication, and
Cardholder security information is input successfully.
02- Conducted the certification of Issuer SAA direct
authentication authorization, and the SAA authentication
authorization is successful.
03- The Switch Centre indicates the Issuer inactive for Card
Authentication.
05- UP3DS Authentication Mode. The Issuer has authenticated
the cardholder successfully through UnionPay 3-D Secure
authentication service.
06- UP3DS Authentication Mode. The Merchant had attempt to

UPI CONFIDENTIAL 111

 Part II: Online Message

Position Definition Attribute Description

authenticate the cardholder, and the UnionPay Attempt Service
responded on behalf of the Issuer. UnionPay Attempt Service is a
stand-in authentication service offered by UnionPay to Issuers
when their ACS is temporarily unavailable.
07- UP3DS Authentication Mode. The Authentication could not
be performed due to technical or other problems.
08- Failed CUPSecure safe authentication, and did not adopt the
security technology of encryption.
09- Issuer Authentication Mode in card-no-present self-service
transactions.
10- Issuer Non-Authentication Mode in card-no-present self-
service transactions.
Byte 15 F60.2.9 Interactive ans1 It indicates the interactive mode upon F60.2.5 Terminal Type. d
Mode Identifier
Valid values:
0- Default
1- Internet
2- Text Message
3- Voice
Note b, d: The situation of terminal depends on the combination of F60.2.5 Terminal Type and F60.2.9
Interactive Mode shown as follows:
F60.2.5 F60.2.5 Value F60.2.9 Situation
Value Definition Value
00 Unknown 0 Undefined channel
01 ATM, CDM 0 The Cardholder initiated transactions like inquiry, deposit,
withdraw, and fund transfer.
02 Reserved 0 n/a
03 POS 0 POS
04 Reserved 0 n/a
05 Multimedia 0, 1, 2, It applies to terminals such as electricity bills payment terminals
terminal 3 and vending machines.
06 Counter 0 It applies to manual transactions at bank counter.
Note: For cross-border remittance, the terminal type includes
attended terminals such as bank counter, checkout counter,
newsstand, currency exchange counter.
07 PC 0, 1, 2, It applies to the situation where computer is used as the
3 transaction channel.
Note: For cross-border remittance, the terminal type indicates the
website platform of the Sending Institution.
08 Mobile phone 0, 1, 2, It applies to the situation where mobile phone is used as the
3 transaction channel.
Note: For cross-border remittance, the terminal type indicates the

UPI CONFIDENTIAL 112

 Part II: Online Message

Position Definition Attribute Description

mobile application of the Sending Institution.

09 I-type fixed 0, 1, 3 I-type fixed phone refers to telephone without PIN pad and the
phone transaction was encrypted by TSAM card without anti-disassemble
function. It could be used at household for transactions like
purchase and fund transfer initiated by the Cardholder. It can also
be used as the MO/TO transaction channel through voice
interaction.
10 Reserved 0 n/a
11 Wireless POS 0 Wireless POS
12 CDRS 1 CDRS
14 Merchant’s 0 Transactions initiated from the Merchant’s System. For example,
System recurring.
15 The third 0, 1 Transactions initiated from the third party system.
party system
16 Setup Box 0, 1 It applies to transactions that use the setup box as the terminal.
17 II-type fixed 0, 2, 3 II-type fixed phone
phone

18 Reserved 0 n/a
19 Reserved 0 n/a
20 Batch File 0 Batch Transactions initiated by Batch File Processing System of the
Processing Acquirer.
System
Note: when F60.2.5 = “20”, the Acquirer should fill F60.3.5 with
“4”.
21-22 Reserved 0 n/a
23 mPOS 0, 1 Used for mPOS initiated transactions
24-99 Reserved 0 n/a

Field 60.3 Additional Transaction Information

3.47.5.1 Attribute
ans15, 15-byte alphabetic, numeric, and special characters with fixed length
3.47.5.2 Description
Field 60.3 is used to describe key additional information of transactions. It is divided into 10 subfields:
Table 80 The Sequence and Value Information of Field 60.3

Position Definition Attribute Description

Byte F60.3.1: ans2 Not used outside of Mainland China currently.
16~17 Special
These positions shall be filled with “00” by the Acquirer. The Issuer
Pricing Type

UPI CONFIDENTIAL 113

 Part II: Online Message

Position Definition Attribute Description

must not reject transactions for non-zero values of these positions.
Valid value:
00- No special pricing type
Byte 18 F60.3.2: ans1 Not used outside of Mainland China currently.
Special
This position shall be filled with “0” by the Acquirer. The Issuer must
Pricing Level
not reject transactions for non-zero value of this position.
Valid value:
0- No special pricing level
Byte F60.3.3: ans3 Currently applicable only to VND (Vietnamese Dong), IDR (Indonesian
19~21 Minor Unit Rupiah) and ISK (Icelandic Krona) transactions.
of
When the transaction currency is Vietnam Dong or Indonesian Rupiah,
Transaction
this field indicates the number of decimal places of both Field 4
Currency
(Transaction Amount) and Field 28 (Transaction Fee Amount). For VND,
Field 60.3.3 shall be filled with “a00”, which means the number of
decimal places is 0; For IDR, Field 60.3.3 shall be filled with “200”,
which means the number of decimal places is 2.
Effective 23:00 April 14, 2023, when the transaction currency is the
Icelandic Krona, this field shall be filled with ‘a00’, indicating the
number of decimal places of Field 4 (Transaction Amount) and Field 28
(Transaction Fee Amount) is 0.
For other transaction currencies, Field 60.3.3 shall be filled with default
value “000”.
Valid values:
a00- 0 minor unit (currently applicable only to VND and ISK
transactions)
100- 1 minor unit
200- 2 minor unit (currently applicable only to IDR transactions)
300- 3 minor unit
000- Default value
Byte 22 F60.3.4: ans1 Valid values:
Partial 0- Not supported
Approval 1- Supported
Indicator
Byte 23 F60.3.5: ans1 This subfield could be used to further differentiate transaction type
Transaction when key field transaction type is of the same value.
Initiation
Valid values:
Mode
0- Unknown (indicating unknown or irrelevant payment method)
1- Supported (indicating transactions are initiated on attended
terminals. The Cardholder and the Merchant’s cashier or bank
employees at counter complete the transaction face-to-face, e.g.
purchase)
2- Unattended, including card-present transaction initiated from the
Cardholder-activated terminal (CAT), ATM transaction and card-not-
present self-service transaction (indicating transactions initiated by

UPI CONFIDENTIAL 114

 Part II: Online Message

Position Definition Attribute Description

Cardholders at unattended terminals such as multimedia terminals. It
includes ATM withdrawal, unattended cash deposit, online payment,
voice payment, mobile payment. etc)
3- Agent (indicating transactions initiated by the Merchant on behalf of
the Cardholder who is not present, like recurring and MO/TO)
4- Batch Agent (indicating all kinds of agent transactions that are
initiated by the Merchant in batch on behalf of the Cardholder who is
not present, like batch recurring and batch MO/TO)
5- Deferred online authorization, unattended card-present payment
(indicating deferred online authorizations initiated by Cardholders at
unattended terminals such as subway gates and car park gates. This
value can be used in CAT purchase, pre-authorization and authorization
messages.)
6- Deferred online authorization, attended card-present payment
(indicating Cardholders and Merchant cashiers or bank employees at
counter complete the transaction face-to-face first, but the online
message is sent later. This value can be used in purchase,
preauthorization and authorization messages.)
Byte 24 F60.3.6: ans1 This subfield is used to distinguish transaction medium because
Transaction payment medium can be pure characters, biological traits, virtual cards
Medium etc., especially in card-not-present situations. It is hard to judge the
real transaction situation based on card number.
The transaction medium value is associated with the values of F22 PAN
Entry Mode, F60.2.2 Terminal Entry Capability and F60.2.3 Chip
Condition Code shown as follows:
F60.3.6 Valid F22 F60.2.2 Terminal F60.2.3 Chip
values: PAN Entry Capability Condition
Entry Code
Mode
0- Unknown Could not identify the transaction medium
1- Magnetic stripe 02, 90 Irrelevant 0
card transaction
2- Chip card 05, 95 5, 6 Irrelevant
transaction via chip
07, 98 6 Irrelevant
3- Magnetic stripe 02, 90 5, 6 1 (non-
transaction of chip standard
and magnetic operation)
stripe hybrid card 2 (fallback
transaction)
4- Virtual card Reserved
transaction
5- QRC-based 03, 04, Irrelevant, filled Irrelevant,
payment 93, 94 by the terminal filled with
transaction with its chip- default 0

UPI CONFIDENTIAL 115

 Part II: Online Message

Position Definition Attribute Description

reading capability
6- Biological traits Reserved
transaction
7- Card-not- 01, 04 Irrelevant Irrelevant
present transaction

Byte 25 F60.3.7: IC ans1 Valid values:

Card 0- Unknown
Application 1- Debit/credit application (both contact and contactless)
Type 2- EMV standard debit/credit application
3- Electronic cash application (both contact and contactless)
4- Reserved.
Byte F60.3.8: ans2 Valid values:
26~27 Account 00- Unknown
Attribute 01- Debit account
02- Credit account
03- Quasi credit account
04- Credit and debit compound account
05- Pre-paid account
Byte 28 F60.3.9: Card ans1 Valid values:
Level 0- Unknown
1- UnionPay Classic
2- Reserved
3- UnionPay Gold
4- UnionPay Platinum
5- UnionPay Diamond
6- Reserved
Byte F60.3.10: ans2 Valid values:
29~30 Card Product 00- Unknown
01- Official card
02- Fee payment card
03- Airline card
04- Student card
05- Social security card
06- Health card
07- Fu’nong card
08- Military card
09- Family card
10- Settlement card
40- Travel card
41- UnionPay Benefit Card
42~79- Reserved for personal card product
80- Corporate card, commercial
81- Business travel card, commercial
82- Purchase card, commercial
83~99- Reserved for commercial card product

UPI CONFIDENTIAL 116

 Part II: Online Message

Transmission Requirements of each subfield

Field 60 contains 20 subfields. The difference in definition of each field leads to different transmission requirements.
This section will summarize the transmission requirement of each subfield in Field 60 as it provides key information
for transaction type identification. This part will not be covered again in Chapter 4 unless there is special requirement.
For message format description, please refer to Section 4.1.2. For message field data unit, please refer to Section
4.1.3.
3.47.6.1 Transmission Requirement of Field 60 in Original Request Transactions
 Online original request transactions include: balance inquiry, pre-authorization, MO/TO pre-authorization,
authorization, cash withdrawal, purchase, MO/TO purchase, online recurring, remittance verification, account
verification, online primary credit, and account funding.
Table 81 Transmission Requirements of Field 60 in Online Original Request Transactions

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.1 Message Reason n4 M  M 
Code
60.2.1 Account Holder ans1 M  M  This field must be filled. If Account
Type Holder Type is not certain, fill with
default value 0.
60.2.2 Terminal Entry n1 M  M 
Capability
60.2.3 Chip Condition n1 M  M 
Code
60.2.4 Reserved n1 M  M  Fill with default value because
subsequent subfields have valid value.
60.2.5 Terminal Type n2 M  M 
60.2.6 Signature-Only n1 M C16 C0  If the Acquirer has valid content in
Indicator subsequent subfield, it shall be filled
with default value. GSCS will revise the
default value based on whether only
signature is required.
60.2.7 IC Card n1 M C6 M C16 The Acquirer must fill it with default
Authentication value 0.
Reliability For PAN-based transaction, GSCS will
Identifier forward it in the request and response
messages.
For the request message in Payment
Token transaction, GSCS will replace it
with value 4 if the transaction used
Token Service provided by UnionPay. In
the response message, GSCS will replace
it with 0.

UPI CONFIDENTIAL 117

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.2.8 E-commerce n2 M C16 M  It shall be filled with true value if there is
Identifier (ECI) E-commerce Identifier (ECI). Otherwise
it shall be filled with default value to
indicate the existence of subsequent
subfields.
For Acquirers not certified of UnionPay
3DS services, a declared 3DS-
authentication-mode transaction will be
downgraded to a non-3DS-
authentication-mode transaction: ECI
“05”, “06” or “07” in the request will be
replaced with “10” by UPI, with AV (in
Usage AM of F61.6) intercepted.
60.2.9 Interactive Mode n1 M  M 
Identifier
60.3.1 Special Pricing ans2 M  M  It shall be filled with true value if there is
Type special pricing type indicator. Otherwise
it shall be filled with default value to
indicate the existence of subsequent
subfields.
60.3.2 Special Pricing ans1 M  M  It shall be filled with true value if there is
Level special pricing level indicator. Otherwise
it shall be filled with default value to
indicate the existence of subsequent
subfields.
60.3.3 Minor Unit of ans3 M  M  When the transaction currency is
Transaction Vietnam Dong, it indicates that the
Currency number of decimal places of both Field 4
(Transaction Amount) and F28
(Transaction Fee Amount) is ‘0’ by filling
Field 60.3.3 with ‘a00’.
For other transaction currencies, Field
60.3.3 shall be filled with default value
‘000’ until UPI releases new decimal
place change for other transaction
currencies.
60.3.4 Partial Approval ans1 M  M  It shall be filled with true value if there is
Indicator Partial Approval Indicator. Otherwise it
shall be filled with default value to
indicate the existence of subsequent
subfields.
60.3.5 Transaction ans1 M  M 
Initiation Mode

UPI CONFIDENTIAL 118

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.3.6 Transaction ans1 M M  It is filled by GSCS.
Medium
60.3.7 IC Card ans1 M M  It is filled by GSCS.
Application Type
60.3.8 Account ans2 M M  It is filled by GSCS based on system
Attribute configuration. The Issuer should not
revise it even if the value does not
match its definition. The Issuer shall
send it back to GSCS as what it was.
GSCS will switch it to the Acquirer.
60.3.9 Card Level ans1 M  It is filled by the Issuer. GSCS will switch
it directly to the Acquirer.
60.3.10 Card Product ans2 M  It is filled by the Issuer. GSCS will switch
it directly to the Acquirer.
 Batch original request transactions include: batch recurring and batch primary credit.
Table 82 Transmission Requirements of Field 60 in Batch Original Request Transactions

Subfield Definition Format Transmission Description

Requirements
AC SW
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder ans1 M M This field must be filled. If Account Holder Type
Type is not certain, fill with default value 0.
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition n1 M M
Code
60.2.4 Reserved n1 M M Fill with default value because subsequent
subfields have valid value.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M C0 If the Acquirer has valid content in subsequent
Indicator subfield, it shall be filled with default value.
GSCS will revise the default value based on
whether only signature is required.
60.2.7 IC Card n1 M M It shall be filled with default value.
Authentication
Reliability Identifier
60.2.8 E-commerce n2 M M It shall be filled with true value if there is E-

UPI CONFIDENTIAL 119

 Part II: Online Message

Identifier (ECI) commerce Identifier (ECI). Otherwise it shall be

filled with default value to indicate the
existence of subsequent subfields.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing Type ans2 M M It shall be filled with true value if there is special
pricing type indicator. Otherwise it shall be filled
with default value to indicate the existence of
subsequent subfields.
60.3.2 Special Pricing ans1 M M It shall be filled with true value if there is special
Level pricing level indicator. Otherwise it shall be
filled with default value to indicate the
existence of subsequent subfields.
60.3.3 Minor Unit of ans3 M M When the transaction currency is Vietnam Dong,
Transaction it indicates that the number of decimal places of
Currency both Field 4 (Transaction Amount) and F28
(Transaction Fee Amount) is ‘0’ by filling Field
60.3.3 with ‘a00’.

60.3.4 Partial Approval ans1 M M It shall be filled with true value if there is Partial
Indicator Approval Indicator. Otherwise it shall be filled
with default value to indicate the existence of
subsequent subfields.
60.3.5 Transaction ans1 M M
Initiation Mode
60.3.6 Transaction ans1 M M It is filled by GSCS.
Medium
60.3.7 IC Card Application ans1 M M It is filled by GSCS.
Type
60.3.8 Account Attribute ans2 M M It is filled by GSCS based on system
configuration. The Issuer should not revise it
even if the value does not match its definition.
The Issuer shall send it back to GSCS as what it
was. GSCS will switch it to the Acquirer.
60.3.9 Card Level ans1 M It is filled by the Issuer. GSCS will switch it
directly to the Acquirer.
60.3.10 Card Product ans2 M It is filled by the Issuer. GSCS will switch it
directly to the Acquirer.

3.47.6.2 Transmission Requirements of Field 60 in Subsequent Transactions on the Same Day

 Subsequent transactions on the same day include: pre-authorization completion cancellation, MO/TO pre-
authorization completion cancellation, purchase cancellation, MO/TO purchase cancellation, recurring
cancellation, fixed-amount authorization cancellation and remittance.
Table 83 Transmission Requirements of Filed 60 in Subsequent Transactions on the Same Day

UPI CONFIDENTIAL 120

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.1 Message Reason n4 M  M 
Code
60.2.1 Account Holder ans1 M  M 
Type
60.2.2 Terminal Entry n1 M  M 
Capability
60.2.3 Chip Condition n1 M  M 
Code a
60.2.4 Reserved n1 M  M  This field must be filled with default value
since there are valid values in subsequent
subfields.
60.2.5 Terminal Type n2 M  M 
60.2.6 Signature-Only n1 M C16 C0 
Indicator b
60.2.7 IC Card n1 M C6 M C16 The Acquirer must fill it with default value 0.
Authentication For PAN-based transaction, GSCS will
Reliability forward it in the request and response
Identifier messages.
For Payment Token transaction, in the
request message GSCS will replace it with
value 4 if the transaction has used Token
Service provided by UnionPay. In the
response message, GSCS will replace it with
0.
60.2.8 E-commerce n2 M C16 M  For Acquirers not certified of UnionPay 3DS
Identifier (ECI) c services, a declared 3DS-authentication-
mode transaction will be downgraded to a
non-3DS-authentication-mode transaction:
ECI “05”, “06” or “07” in the request will be
replaced with “10” by UPI, with AV (in Usage
AM of F61.6) intercepted.
60.2.9 Interactive Mode n1 M  M 
Identifier
60.3.1 Special Pricing ans2 M  M 
Type
60.3.2 Special Pricing ans1 M  M 
Level
60.3.3 Minor Unit of ans3 M  M 
Transaction
Currency c

UPI CONFIDENTIAL 121

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.3.4 Partial Approval ans1 M  M 
Indicator d
60.3.5 Transaction ans1 M  M 
Initiation Mode
60.3.6 Transaction ans1 M M  This subfield is judged and filled by GSCS.
Medium
60.3.7 IC Card ans1 M M  This subfield is judged and filled by GSCS.
Application Type
60.3.8 Account Attribute ans2 M M 
60.3.9 Card Level ans1 M 
60.3.10 Card Product ans2 M 
Note a, b, c, d: For remittance (online), the message sender must fill F60.2.3, F60.2.6, F60.2.8, and F60.3.4
with the same value as the corresponding field of remittance verification.

3.47.6.3 Transmission Requirements of Field 60 in Subsequent Transactions on Different Days

 Subsequent transactions on different days include: pre-authorization cancellation, MO/TO pre-authorization
cancellation, manual pre-authorization cancellation, pre-authorization completion (request), MO/TO pre-
authorization completion (request), and estimated amount authorization cancellation.
Table 84 Transmission Requirements of Filed 60 in Subsequent Transactions on Different Days

Subfield Definition Format Transmission Description

Requirements
AC SW IS SW
60.1 Message Reason n4 M  M 
Code
60.2.1 Account Holder ans1 M  M 
Type
60.2.2 Terminal Entry n1 M  M 
Capability
60.2.3 Chip Condition n1 M  M 
Code
60.2.4 Reserved n1 M  M  This field must be filled with default value
since there are valid values in subsequent
subfields.
60.2.5 Terminal Type n2 M  M 
60.2.6 Signature-Only n1 M C16 C0 
Indicator
60.2.7 IC Card n1 M C6 M C16 The Acquirer must fill it with default value 0.

UPI CONFIDENTIAL 122

 Part II: Online Message

Authentication For PAN-based transaction, GSCS will

Reliability forward it in the request and response
Identifier messages.
For Payment Token transaction, in the
request message, GSCS will replace it with
value 4 if the transaction has used Token
Service provided by UnionPay. In the
response message, GSCS will replace it with
0.
60.2.8 E-commerce n2 M C16 M  For Acquirers not certified of UnionPay 3DS
Identifier (ECI) services, a declared 3DS-authentication-
mode transaction will be downgraded to a
non-3DS-authentication-mode transaction:
ECI “05”, “06” or “07” in the request will be
replaced with “10” by UPI, with AV (in Usage
AM of F61.6) intercepted.
60.2.9 Interactive Mode n1 M  M 
Identifier
60.3.1 Special Pricing ans2 M  M 
Type
60.3.2 Special Pricing ans1 M  M 
Level
60.3.3 Minor Unit of ans3 M  M  Currently only used for VND/IDR
Transaction transactions
Currency
60.3.4 Partial Approval ans1 M  M 
Indicator
60.3.5 Transaction ans1 M  M 
Initiation Mode
60.3.6 Transaction ans1 M M  This subfield shall be judged and filled by
Medium GSCS.
60.3.7 IC Card ans1 M M  This subfield shall be judged and filled by
Application Type GSCS.
60.3.8 Account Attribute ans2 M M 
60.3.9 Card Level ans1 M 
60.3.10 Card Product ans2 M 

3.47.6.4 Transmission Requirements of Field 60 in Advice Transactions

 Reversal and primary credit confirmation advices:
Table 85 Transmission Requirements of Field 60 in Reversal and Primary Credit Confirmation Advices (ACSW)

UPI CONFIDENTIAL 123

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder ans1 M M
Type
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition n1 M M
Code
60.2.4 Reserved n1 M M This field must be filled with default value since
there are valid values in subsequent subfields.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M
Indicator
60.2.7 IC Card n1 M M This field shall be filled with default value.
Authentication
Reliability
Identifier
60.2.8 E-commerce n2 M C16 For Acquirers not certified of UnionPay 3DS
Identifier (ECI) services, a declared 3DS-authentication-mode
transaction will be downgraded to a non-3DS-
authentication-mode transaction: ECI “05”, “06” or
“07” will be replaced with “10” by UPI.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing ans2 M M
Type
60.3.2 Special Pricing ans1 M M
Level
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR transactions
Transaction
Currency
60.3.4 Partial Approval ans1 M M
Indicator
60.3.5 Transaction ans1 M M Fill default value 0 for script processing result
Initiation Mode advice.
60.3.6 Transaction ans1 M This subfield shall be judged and filled by GSCS
Medium
60.3.7 IC Card Application ans1 M This subfield shall be judged and filled by GSCS

UPI CONFIDENTIAL 124

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW
Type
60.3.8 Account Attribute ans2 M This subfield shall be filled by GSCS based on
system configuration and sent directly to the
Acquirer.

Table 86 Transmission Requirements of Field 60 in Reversal and Primary Credit Confirmation Advices (SWIS)

Subfield Definition Format Transmission Description

Requirements
SW IS
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder Type ans1 M M
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition Code n1 M M
60.2.4 Reserved n1 M M This field must be filled with default value
since there are valid values in subsequent
subfields.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M
Indicator
60.2.7 IC Card n1 C16 M For PAN-based transaction, UnionPay
Authentication system fills it with 0.
Reliability Identifier For Payment Token transaction, UnionPay
System will replace it with value 4 if the
transaction has used Token Service
provided by UnionPay.
60.2.8 E-commerce n2 C16 M In a downgraded non-3DS-authentication-
Identifier (ECI) mode transaction: UPI fills the subfield
with “10”.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing Type ans2 M M
60.3.2 Special Pricing Level ans1 M M
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR
Transaction Currency transactions
60.3.4 Partial Approval ans1 M M
Indicator

UPI CONFIDENTIAL 125

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
SW IS
60.3.5 Transaction Initiation ans1 M M
Mode
60.3.6 Transaction Medium ans1 M M This subfield shall be judged and filled by
GSCS.
60.3.7 IC Card Application ans1 M M This subfield shall be judged and filled by
Type GSCS.
60.3.8 Account Attribute ans2 M M It is filled by GSCS based on system
configuration. The Issuer should not revise
it even if the value does not match its
definition. The Issuer shall send it back to
GSCS as what it was. GSCS will switch it to
the Acquirer.
60.3.9 Card Level ans1 M This subfield is filled by the Issuer.
60.3.10 Card Product ans2 M This subfield is filled by the Issuer.
 Script processing result advice:
Table 87 Transmission Requirements of Field 60 in Script Processing Result Advice (ACSW)

Subfield Definition Format Transmission Description

Requirements
AC SW
60.1 Message Reason Code n4 M M
60.2.1 Account Holder Type ans1 M M
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition Code n1 M M
60.2.4 Reserved n1 M M This field must be filled with default
value since there are valid values in
subsequent subfields.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M
Indicator
60.2.7 IC Card Authentication n1 M M This field shall be filled with default
Reliability Identifier value.
60.2.8 E-commerce Identifier n2 M C16
(ECI)
60.2.9 Interactive Mode n1 M M
Identifier

UPI CONFIDENTIAL 126

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW
60.3.1 Special Pricing Type ans2 M M
60.3.2 Special Pricing Level ans1 M M
60.3.3 Minor Unit of ans3 M M
Transaction Currency
60.3.4 Partial Approval ans1 M M
Indicator
60.3.5 Transaction Initiation ans1 M M Fill default value 0 for script processing
Mode result advice.
60.3.6 Transaction Medium ans1 M This subfield shall be judged and filled by
GSCS
60.3.7 IC Card Application ans1 M This subfield shall be judged and filled by
Type GSCS
60.3.8 Account Attribute ans2 M This subfield shall be filled by GSCS based
on system configuration and sent directly
to the Acquirer.

Table 88 Transmission Requirements of Field 60 in Script Processing Result Advice (SWIS)

Subfield Definition Format Transmission Description

Requirements
SW IS
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder ans1 M M
Type
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition n1 M M
Code
60.2.4 Reserved n1 M M This field must be filled with default value since
there are valid values in subsequent subfields.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M
Indicator
60.2.7 IC Card n1 M M This field shall be filled with default value.
Authentication
Reliability Identifier
60.2.8 E-commerce n2 C16 M

UPI CONFIDENTIAL 127

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
SW IS
Identifier (ECI)
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing Type ans2 M M
60.3.2 Special Pricing ans1 M M
Level
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR transactions
Transaction
Currency
60.3.4 Partial Approval ans1 M M
Indicator
60.3.5 Transaction ans1 M M
Initiation Mode
60.3.6 Transaction ans1 M M This subfield shall be judged and filled by GSCS.
Medium
60.3.7 IC Card Application ans1 M M This subfield shall be judged and filled by GSCS.
Type
60.3.8 Account Attribute ans2 M M It is filled by GSCS based on system configuration.
The Issuer should not revise it even if the value
does not match its definition. The Issuer shall
send it back to GSCS as what it was. GSCS will
switch it to the Acquirer.
60.3.9 Card Level ans1 M This subfield is filled by the Issuer.
60.3.10 Card Product ans2 M This subfield is filled by the Issuer.
 Pre-authorization Completion (Advice) and Settlement Advice:
Table 89 Transmission Requirements of Field 60 in Pre-authorization Completion (Advice) and Settlement Advice (ACSW)

Subfield Definition Format Transmission Description

Requirements
AC SW
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder ans1 M M
Type
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition n1 M M
Code

UPI CONFIDENTIAL 128

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW
60.2.4 Reserved n1 M M It shall be filled with default value because there
is valid content in subsequent subfield.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M It shall be filled with default value because there
Indicator is valid content in subsequent subfield.
60.2.7 IC Card n1 M M It shall be filled with default value because there
Authentication is valid content in subsequent subfield.
Reliability
Identifier
60.2.8 E-commerce n2 M C16 For Acquirers not certified of UnionPay 3DS
Identifier (ECI) services, a declared 3DS-authentication-mode
transaction will be downgraded to a non-3DS-
authentication-mode transaction: ECI “05”, “06”
or “07” will be replaced with “10” by UPI.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing ans2 M M
Type
60.3.2 Special Pricing ans1 M M
Level
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR transactions
Transaction
Currency
60.3.4 Partial Approval ans1 M M It shall be filled with true value based on real
Indicator transaction situation. Otherwise, it shall be filled
with default value to indicate the existence of
subsequent subfield.
60.3.5 Transaction ans1 M M
Initiation Mode
60.3.6 Transaction ans1 M This subfield shall be filled by GSCS.
Medium
60.3.7 IC Card Application ans1 M This subfield shall be filled by GSCS.
Type
60.3.8 Account Attribute ans2 M This subfield shall be filled by GSCS directly
based on system configuration and sent directly
to the Acquirer.

Table 90 Transmission Requirements of Field 60 in Pre-authorization Completion (Advice) and Settlement Advice (SWIS)

UPI CONFIDENTIAL 129

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
SW IS
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder Type ans1 M M
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition Code n1 M M
60.2.4 Reserved n1 M M This subfield shall be filled with default value
because there is valid content in subsequent
field.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M This subfield shall be filled with default value
Indicator because there is valid content in subsequent
field.
60.2.7 IC Card n1 C16 M For PAN-based transaction, GSCS fills it with
Authentication 0.
Reliability Identifier
For Payment Token transaction, GSCS will
replace it with value 4 if the transaction has
used Token Service provided by UnionPay.
60.2.8 E-commerce n2 C16 M In a downgraded non-3DS-authentication-
Identifier (ECI) mode authorization: UPI fills the subfield with
“10”.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing Type ans2 M M
60.3.2 Special Pricing Level ans1 M M
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR transactions
Transaction Currency
60.3.4 Partial Approval ans1 M M
Indicator
60.3.5 Transaction Initiation ans1 M M
Mode
60.3.6 Transaction Medium ans1 M M This subfield is judged and filled by GSCS.
60.3.7 IC Card Application ans1 M M This subfield is judged and filled by GSCS.
Type
60.3.8 Account Attribute ans2 M M This subfield is filled by GSCS based on system
configuration. The Acquirer shall return it
without revision even if the definition is

UPI CONFIDENTIAL 130

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
SW IS
different from its own.
60.3.9 Card Level ans1 M This subfield is filled by the Issuer.
60.3.10 Card Product ans2 M This subfield is filled by the Issuer.
 Refund (Online) and MO/TO Refund (Online):
Table 91 Transmission Requirements of Field 60 in Refund (Online) and MO/TO Refund (Online) (ACSW)

Subfield Definition Format Transmission Description

Requirements
AC SW
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder ans1 M M
Type
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition n1 M M
Code
60.2.4 Reserved n1 M M This subfield shall be filled with default value
because there is valid content in subsequent
field.
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M This subfield shall be filled with default value
Indicator because there is valid content in subsequent
field.
60.2.7 IC Card n1 M M This subfield shall be filled with default value
Authentication because there is valid content in subsequent
Reliability field.
Identifier
60.2.8 E-commerce n2 M C16 For Acquirers not certified of UnionPay 3DS
Identifier (ECI) services, a declared 3DS-authentication-mode
authorization will be downgraded to a non-3DS-
authentication-mode authorization: ECI “05”,
“06” or “07” will be replaced with “10” by UPI.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing ans2 M M
Type
60.3.2 Special Pricing ans1 M M

UPI CONFIDENTIAL 131

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
AC SW
Level
60.3.3 Minor Unit of ans3 M M Currently only used for VND/IDR transactions
Transaction
Currency
60.3.4 Partial Approval ans1 M M This subfield shall be filled with true value based
Indicator on real situation. Otherwise, it shall be filled
with default value to indicate the existence of
subsequent subfields.
60.3.5 Transaction ans1 M M Filled by the Acquirer when the original
Initiation Mode transaction could not be traced.
60.3.6 Transaction ans1 M This subfield is filled by GSCS.
Medium
60.3.7 IC Card Application ans1 M This subfield is filled by GSCS.
Type
60.3.8 Account Attribute ans2 M This subfield shall be filled by GSCS based on
system configuration and sent directly to the
Acquirer.

Table 92 Transmission Requirements of Field 60 in Refund (Online) and MO/TO Refund (Online) (SWIS)

Subfield Definition Format Transmission Description

Requirements
SW IS
60.1 Message Reason n4 M M
Code
60.2.1 Account Holder Type ans1 M M
60.2.2 Terminal Entry n1 M M
Capability
60.2.3 Chip Condition Code n1 M M
60.2.4 Reserved n1 M M
60.2.5 Terminal Type n2 M M
60.2.6 Signature-Only n1 M M This subfield shall be filled with default value
Indicator because there is valid content in subsequent
subfield.
60.2.7 IC Card n1 M M For PAN-based transaction, GSCS fills it with
Authentication 0.
Reliability Identifier For Payment Token transaction, GSCS will
replace it with value 4 if the transaction has
used Token Service provided by UnionPay.

UPI CONFIDENTIAL 132

 Part II: Online Message

Subfield Definition Format Transmission Description

Requirements
SW IS
60.2.8 E-commerce n2 C16 M In a downgraded non-3DS-authentication-
Identifier (ECI) mode authorization: UPI fills the subfield with
“10”.
60.2.9 Interactive Mode n1 M M
Identifier
60.3.1 Special Pricing Type ans2 M M
60.3.2 Special Pricing Level ans1 M M
60.3.3 Minor Unit of ans3 M M
Transaction Currency
60.3.4 Partial Approval ans1 M M
Indicator
60.3.5 Transaction Initiation ans1 M M This subfield shall be filled with default value.
Mode
60.3.6 Transaction Medium ans1 M M This subfield is judged and filled by GSCS.
60.3.7 IC Card Application ans1 M M This subfield is judged and filled by GSCS.
Type
60.3.8 Account Attribute ans2 M M This subfield shall be filled by GSCS based on
system configuration. The Issuer shall send it
without revision even if its definition does not
match its own.
60.3.9 Card Level ans1 M This subfield is filled by the Issuer.
60.3.10 Card Product ans2 M This subfield is filled by the Issuer.

Key Field Value for E-commerce Transaction

E-commerce transaction adopts the same message format and transmission requirement as purchase, pre-
authorization, and authorization do. However, it can be further differentiated from general purchase, pre-
authorization, and authorization by the value of several subfields within Field 60.
The detailed values of key fields for e-commerce are listed as below:
Table 93 Key Fields for E-commerce

Transaction Type F3 F22 F25 F60.2.5 F60.2.8 F60.2.9 F60.3.5

Purchase 00x000 011, 00 07, 08 05, 06, 07, 09, 0, 1, 2, 2
012 10 3
Purchase cancellation 20x000 00
Refund 20x000 00
Pre-authorization 03x000 06
Pre-authorization cancellation 20x000 06

UPI CONFIDENTIAL 133

 Part II: Online Message

Transaction Type F3 F22 F25 F60.2.5 F60.2.8 F60.2.9 F60.3.5

Pre-authorization completion 00x000 06
Pre-authorization completion 20x000 06
cancellation
Authorization 00x000 00
Authorization cancellation 20x000 00

Reject Code
10603= Invalid characters in length field
10604= Length value exceeds 100
10605= Invalid characters

UPI CONFIDENTIAL 134

 Part II: Online Message

3.48 Field 61 Cardholder Authentication Information

Attribute
ans..200(LLLVAR), 3-byte length value + Cardholder authentication information of maximum 200 bytes alphabetic,
numeric, and special characters
Description
This field is a self-defined field with 6 subfields as follows:
Table 94 The General Format of Field 61

Field Field 61.1 Field 61.2 Field 61.3 Field 61.4 Field 61.5 ARQC Field 61.6 Security
Length ID Number CVN Check PVV Check CNP Check Authentication Information Check
Result result Value Result Value
n3 ans22 ans1 ans1 ans7 ans1 ans..168
Note 1: If the subsequent subfield appears and the previous subfield is not required, the value of the unused
subfield should be filled with spaces.
Note 2: There is no length field for Subfield 61.6 because there is already one for the whole Field 61.

Field 61.1 ID Number

3.48.3.1 Attribute
ans22, 22-byte alphabetic, numeric and special characters with fixed length
3.48.3.2 Description
The field is used to save ID number, telephone number and certificate serial number of the Cardholder. The sequence
and value information are listed as follows:
Table 95 The Sequence and Value Information of Field 61.1

Seq. Definition Attribute Description

1 ID type n2 Valid values:
01- ID Card
02- Serviceman Card
03- Passport
04- Home-Visiting Certificate
05- Taiwan Visitor Certificate
06- Police Card
07- Soldier Card
08- PBOC Travel Document
09- Foreign Passport
10- Foreigners Permanent Residence Card
11- Border Exit and Entry Permit
99- Other ID card
2 ID ans20 a Filled with the serial number of the corresponding ID type.
number
Note a: If the serial number is less than 20 bytes, spaces will be padded to the
right.

UPI CONFIDENTIAL 135

 Part II: Online Message

3.48.3.3 Usage
For MO/TO and recurring transactions, it is optional for Acquirers to fill F61.1, which is used as an auxiliary verification
element. When the value in F61.1 is used for verification purpose, the identification card verification indicator in
F61.6 of Usage AM shall be set as “1”.
For remittance verification transaction in cross-border remittance, the presence of the remitter’s ID card number in
F61.1 is optional according to the Acquirer's business need. (The remittee's identification information shall be
provided by the Issuer through Field 57 of Usage CI in the response message of remittance verification).
For account funding transaction (AFT), Field 61.1 is used to store the ID Type and ID Number of the payer. The payer’s
name, ID Number and mobile phone number are three recommended verification elements in AFT. For detailed
requirements on these verification elements and the value of the payer’s name and mobile phone number, please
refer to Field 61.6 Usage AM.
For cross-border remittance in Primary Credit Transaction, Field 61.1 can be used to store the ID Type and ID Number
of the payee, namely the cardholder. For detailed verification requirements on this verification element, please refer
to Field 61.6 Usage AM.
For the purpose of security, this subfield in the response message returned by the Issuer shall be filled with zeros only.

Field 61.2 CVN Check Result

3.48.4.1 Attribute
ans1, 1-byte alphabetic, numeric or special character with fixed length
3.48.4.2 Description
If the Member requests UnionPay to verify the CVV, this field is used to store the check result. The sequence and
value information are listed as follows:
Table 96 The Sequence and Value Information of Field 61.2

Seq. Definition Attribute Description

1 CVN check result ans1 Valid values:
1- Succeeded
2- Failed
3- Unverified

3.48.4.3 Usage
This field is filled by GSCS in stand-in authorization transactions. If the Member does not request UnionPay to verify
CVV, this field is filled with space.

Field 61.3 PVN Check Result

3.48.5.1 Attribute
ans1, 1-byte alphabetic, numeric or special character with fixed length
3.48.5.2 Description
If the Member requests UnionPay to verify PVV, this field is used to store the check result. The sequence and value
information are listed as follows:
Table 97 The Sequence and Value Information of Field 61.3

UPI CONFIDENTIAL 136

 Part II: Online Message

Seq. Definition Attribute Description

1 PVN check result ans1 Valid values:
1- Succeeded
2- Failed
3- Unverified

3.48.5.3 Usage
This field is filled by GSCS in stand-in authorization transactions. If the Member does not request UnionPay to verify
PVV, this field is filled with space.

Field 61.4 Card-not-present Check Value

3.48.6.1 Attribute
ans7, 7-byte alphabetic, numeric and special characters with fixed length
3.48.6.2 Description
This field is used as an additional verification element for conducting the identity authentication in card-not-present
transactions. The sequence and value information are listed as follows:
Table 98 The Sequence and Value Information of Field 61.4

Seq. Definition Attribute Description

1 Switch center ans3 Valid value:
identifier CUP- China UnionPay
2 Card-not-present n3 For UnionPay and VISA, this field is filled with the CVN2 check value;
check value For MasterCard, this field is filled with the CVC2 check value.
3 Card-not-present ans1 If the Member requests UnionPay to verify the CVN2, this field is
check result used to store the check result.
Valid values:
1- Succeeded
2- Failed
3- Unverified

3.48.6.3 Usage
Switch Center Identifier Value is filled with fixed value “CUP”, Card-not-present Check Value is used as Verification
Element (mandatory or auxiliary element) in MO/TO and e-commerce transactions. It is mandatory for the Acquirer
to fill F61.4 Switch Center Identifier Value and Card-not-present Check Value if CVN2 is used as a mandatory
Verification Element. In this case, the CVN2 verification indicator in F61.6 Usage AM should be set as 1. For the
purpose of security, the Card-not-present Check Value in the response message returned by the Issuer shall be filled
with zeros only.
For the specified rules about mandatory/auxiliary Verification Element for various transactions, please refer to the
UPI Operating Regulations and Business Guide for card-not-present transactions.
Card-not-present Check Result is filled by GSCS in stand-in authorization transactions. For other transactions in which
Members do not request GSCS to verify CVN2, this field is filled with space. If the Issuer checks CVN2 by itself, the
Issuer will not fill the result in this field, and therefore the Acquirer shall not obtain CVN2 verification result in this
field. For non-UnionPay cards acquiring, this field is filled with space in the message sent by Acquirers.

Field 61.5 ARQC Authentication Result

UPI CONFIDENTIAL 137
 Part II: Online Message

3.48.7.1 Attribute
ans1, 1-byte alphabetic, numeric or special character with fixed length
3.48.7.2 Description
This subfield records the authentication result of ARQC from the card. The sequence and value information are listed
as follows:
Table 99 The Sequence and Value Information of Field 61.5

Seq. Definition Attribute Description

1 ARQC authentication result ans1 Valid values:
1- Transaction passes ARQC authentication.
2- Transaction fails ARQC authentication.
3- No ARQC authentication conducted

3.48.7.3 Usage
This field is filled by GSCS if the Issuer that supports IC card transactions requests UnionPay to conduct ARQC
authentication on its behalf. When receiving this value, the Issuer may decide whether to approve or reject the
transaction at its own discretion.

Field 61.6 Security Information Check Value

3.48.8.1 Attribute
ans..168, maximum 168-byte alphabetic, numeric, and special characters with variable length
3.48.8.2 Description
This field is used to transmit identity authentication information in card-not-present transactions and in cross-border
remittance. The sequence and value information are listed as follows:
Table 100 The Sequence and Value Information of Field 61.6

Seq. Definition Attribute Description

1 Switch center ans3 Valid value:
Identifier CUP- China UnionPay
2 Security ans..165 The format of this field is shown as follows:
authentication
<format identifier.><data>
information
<format identifier.> indicates the type of the following data,
length is 2 bytes;
<data> consists of the specific information; its format is
depended on the <format identifier> with a maximum length of
163 bytes.
Usage Usage Usage Definition
No. Identifier
1 SC UnionPay Safe Entry Mode
2 AR Issuer authentication result under
UnionPay Safe Entry Mode

UPI CONFIDENTIAL 138

 Part II: Online Message

Seq. Definition Attribute Description

3 SA Issuer direct status authentication

mode
4 CR Issuer authentication result for
CAVV under Issuer direct status
authentication mode
5 AM The Issuer’s verification mode
required by the Acquirer in the
transaction process
6 NM Cardholder’s name
7 VR Verification Code

Note 1: There is no length field between Field 61.5 and Field 61.6 because the length value of the whole Field
61 has already appeared at the very beginning of Field 61.
Note 2: In the procedure of a transaction, Members shall be able to process all the usages in Field 61.6. The
Acquirer needs to submit usages according to its actual business needs, while the Issuer may choose to decline
the transaction if certain usage is not supported. System abnormality and transaction outage shall be avoided.

3.48.8.3 Usage
Usage SC, AR, SA, and CR were used in E-commerce transactions that are certified by CUPSecure or adopt Issuer
Direct Authentication Mode. These usages are currently unused.
Usage AM of Field 61.6 is used in card-not-present transactions for transmitting Verification Element from the
Acquirer to the Issuer.
Usage NM of Field 61.6 is used in cross-border remittance for providing the Remitter’s Name and the Remittee’s
Name.
Usage VR in Field 61.6 transmits verification code (VCODE) in E-commerce transactions for SecurePlus service.
3.48.8.4 Usage SC: UnionPay Safe Entry Mode (Currently Unused)
3.48.8.5 Usage AR: Issuer Authentication Result under UnionPay Safe Entry Mode (Currently Unused)
3.48.8.6 Usage SA: Issuer Direct Status Authentication Mode (Currently Unused)
3.48.8.7 Usage CR: Issuer Authentication Result for CAVV Under Issuer Direct Status Authentication
Mode (Currently Unused)
3.48.8.8 Usage AM: Issuer Verification Mode Required by Acquirer
In order to ensure the security of card-not-present transactions, Usage AM is used for the Acquirer to indicate its
Verification Requirement and to transmit Verification Element to the Issuer, who conducts verifications on those
Verification Elements according to the specific requirement and returns verification result in response messages.
Usage AM of F61.6 consists of 2 parts:
<Verification Indicator><Verification Element Value>
<Verification Indicator> indicates the Verification Requirement of the Acquirer, for example, by setting a specific byte as
1, the Acquirer can request the Issuer to conduct verification on a corresponding Verification Element.
<Verification Element Value> stores detailed value of Verification Element.
Verification Element can be divided into mandatory verification element and auxiliary verification element according to
UPI CONFIDENTIAL 139
 Part II: Online Message
specific transaction types. For detailed rules about mandatory/auxiliary verification element for various transactions,
please refer to the UPI Operating Regulations and business guides for card-not-present transactions. It is mandatory for
the Acquirer to fill the value of a specific verification element in F61.6 Usage AM if it is used as a mandatory verification
element. It is optional for the Acquirer to fill the value of a specific verification element in F61.6 Usage AM if it is used as
an auxiliary verification element. The sequence and value information are listed as follows:
Table 101 The Sequence and Value Information of Usage AM

Position Definition Description

1~2 Usage Valid value:
identifier AM- Issuer verification mode required by Acquirer
3~18 Verification The sequence and value information of verification indicator byte-map are listed as
Indicator follows:
Sub- Description
position
and
Definition
Byte 1: The PIN data is stored in F52. It is recommended for the Acquirer to
keep consistency between the value of this byte and those of F22 &
PIN
F52. Issuer conducts PIN verification based on F22 and F52, even
verification
when this indicator is 0.
indicator
Acquirer shall fill with the following values:
0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 2: Card expiration date is stored in F14. It is recommended for the
Acquirer to keep consistency between the value of this byte and
Card
that of F14. Issuer conducts card expiration date verification based
expiration
on F14, even when this indicator is 0.
date
verification Acquirer shall fill with the following values:
indicator 0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 3: ID card number is stored in F61.1. It is mandatory for the Acquirer
to fill this byte with 1 when ID card number is a Verification
ID number
Element. Issuer conducts ID card number verification when this
verification
indicator is 1.
indicator
Acquirer shall fill with the following value:
0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 4~5: Filled with 0s.
Reserved
Byte 6: CVN2 is stored in F61.4. It is mandatory for the Acquirer to fill this
byte with 1 when CVN2 is a Verification Element. Issuer conducts

UPI CONFIDENTIAL 140

 Part II: Online Message

Position Definition Description

CVN2 CVN2 verification when this indicator is 1.

verification
Acquirer shall fill with the following value:
indicator
0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 7: Filled with 0.
Reserved
Byte 8: Name is stored in Verification Element Value of this usage. It is
mandatory for the Acquirer to fill this byte with 1 when name is a
Name
Verification Element. Issuer conducts Name verification when this
verification
indicator is 1.
indicator
Acquirer shall fill with the following value:
0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 9: Mobile phone number is stored in Verification Element Value of this
usage. It is mandatory for the Acquirer to fill this byte with 1 when
Mobile
mobile phone number is a Verification Element. Issuer conducts
phone
mobile phone number verification when this indicator is 1.
verification
indicator Acquirer shall fill with the following value:
0- Not present
1- Present
Issuer shall return the same value in this position.
Byte 10: OTP is stored in Verification Element Value of this usage.
OTP Acquirer shall fill with the following value:
verification 0- The OTP is not present.
indicator 1- The OTP is present, and shall be verified by the Issuer: The OTP
is present in Verification Element Value, and it shall be compared
by the Issuer with the OTP sent to the Cardholder.
2- The OTP is present, and shall be sent by the Issuer: The OTP is
present in Verification Element Value, and it shall be sent to the
Cardholder by the Issuer.
3- The OTP is not present, and shall be returned by the Issuer: The
Issuer shall send its generated OTP to the Cardholder, and return
the OTP to GSCS in the response message for future verification by
UPI.
Issuer shall return the following value:
1- The OTP key value is present, whereas the OTP is not present: In
the subsequent transaction, the OTP filled by the Cardholder and
the OTP key value shall be sent to the Issuer for verification.
3- Both the OTP key value and the OTP are present: In the
subsequent transaction, the OTP shall be verified by UPI.

UPI CONFIDENTIAL 141

 Part II: Online Message

Position Definition Description

Byte 11: Acquirer shall fill with the following value:

0- AV not present
AV
1- AV present
verification
Issuer shall process the transaction based on the value received
indicator
and return the same value in this position.
0- AV not present
1- AV present
2- AV present, validated by UnionPay (The validated AV is
transmitted to the Issuer)
Transmission
F60.2.8 AV AV Requirement of AV
Scenario Generated Validated Verification Indicator
(ECI) by by
AC SW IS SW

ACS Self-
ACS ACS “1” → → →
Validation
05 UnionPay AV
On-Behalf ACS UnionPay “1” “2” → →
Service

UnionPay
06 Attempt UnionPay UnionPay “1” “2” → →
Service

Authentication
07/10 - - “0” → → →
Not Performed

Downgraded
Neither
Altered Non-
ACS nor - “1” “0” → →
to 10 authenticated
UnionPay
Transaction

Note: AV is stored in Verification Element Value of this usage.

Byte Filled with 0s.
12~16:
Reserved
Note: Issuer shall verify the verification elements according to the Verification
Indicator byte-map sequence. Once the Issuer detects a verification element error, it
shall stop verifying, and return the response code “05” in F39 to reject the
transaction. If the Issuer does not support the verification of certain elements, it shall
return the response code “40” in F39 to reject the verification.
19~ Verification Can be filled with maximum 147-byte alphabetic, numeric, and special characters.
max. Element
Currently, name, mobile phone number, the OTP for CNP self-service purchase, pre-
165 Value
authorization and commission relationship related transactions, and AV used in
UP3DS will be listed in the Verification Element Value.
Because some verification elements are of variable length, to facilitate separation of
elements and ensure data integrity, a 3-byte length value shall be added in front of
each verification element value in this position, including name, mobile phone
number, OTP, AV, etc. No spaces between verification elements.
Verification elements can be present individually or as a combination. When

UPI CONFIDENTIAL 142

 Part II: Online Message

Position Definition Description

elements are combined, the value of verification element must be present in the
byte-map sequence defined in Verification Indicator.
Descriptions and notes for different verification element are listed as follows:
Verification Description & Note
Element
Name Regarding the name information transfer in special cases such as
Cardholder of the company account, normal processing is
followed, where there is no space between Chinese characters
and if English name is used, the system will not separate
deliberately but forward the actual input.
Chinese characters are the primary choice for name. The encoding
of Chinese character shall follow the standard GB18030-2000. No
space between Chinese characters in the Chinese name, but there
may be special characters like separator. Where Chinese
characters cannot be input, Chinese spelling letters (PIN YIN) can
be used instead. Family name comes before given name,
separated by space, and with initial letters of both names
capitalized. Alternatively, English name can be input with given
name followed by surname, separated by a space and the initial
letters of both names capitalized.
ID number The last 6 digits of the ID card shall be acquired by extracting 6
consecutive digits from the ID number starting with the rightmost
one. The extracted digits shall be filled from right to left in the
subfield in its original order and of its original ID number length,
0-padded on the left or/and space-padded on the right. If valid
digits extracted from ID numbers are less than 6 digits, they shall
be 0-padded on the left. For example, ID numbers like ABC1234,
12ABC34, 1234ABC shall be filled the same as 0001234, with 13
spaces on the right. ID numbers like X12345678, 1234X5678
12345678X shall be filled as 345678, with 000 padded on the left
and 11 spaces padded on the right.
Mobile Mobile phone number is a field with variable length. District code
phone shall not be included.
number
OTP The format of OTP is ans40, with the first 20 bytes used to store
the OTP key value, which is submitted by the Acquirer, and the
last 20 bytes used to store the OTP.
AV AV Stands for Authentication Value, whose format is ans28. The
value is generated by The Issuer ACS or UnionPay Attempt Service
during UP3DS authentication based on pre-defined rules. For
information about how the AV is calculated, please refer to the
UP3DS Issuer Implementation Guide.
When the indicator of the verification element stored in the usage is set as “1” or
“2”, Issuer shall return the same value in the response message as the original
value of corresponding element submitted by the Acquirer.

UPI CONFIDENTIAL 143

 Part II: Online Message

Position Definition Description

Note 1: If the auxiliary verification requirements submitted by the Acquirer do not conform to the UPI
Operating Regulations, the Issuer shall reject the transaction and return response code “40” to indicate the
transaction failure.
Note 2: If UnionPay conducts verification on behalf of the Issuer, Usage 5 will be filled by GSCS in card-not-
present transaction response messages.

3.48.8.9 Usage NM: Cardholder’s Name

Used in the transaction subject to identification verification through identifying the Cardholder’s name. This usage
can be combined with Field 61.1 to process more integrated and accurate Cardholder verification. The sequence and
value information are listed as follows:
Table 102 The Sequence and Value Information of Usage NM

Seq. Definition Attribute Description

1 Usage a2 Valid value:
identifier NM- Cardholder’s name information
2 Cardholder’s ans30 When only one name needs to be input, fill it here. The name should be
name 1 padded with trailing spaces if its length is not enough.
Note: In the cross-border remittance, the Sender’s ID card number should
be put into Field 61.1 and submitted. The Sender’s name should be put
into this field and submitted in Chinese pinyin. It is mandatory for the
Acquirer, also called as the SI (Sending Institution), to submit the Sender’s
Name in this Field in cross-border remittance verification transaction.
3 Cardholder’s ans30 When two names need to be input, fill another name here. The name
name 2 should be padded with trailing spaces if its length is not enough.
Note: In cross-border remittance, the Receiver’s name should be put into
this field and submitted in Chinese pinyin.

3.48.8.10 Usage VR: Verification Code

Usage VR transmits verification code (VCODE) for E-commerce transaction adopting SecurePlus service that is
generated by UPOP system to UPI to authenticate the transaction. The sequence and value information are listed as
follows:
Table 103 The Sequence and Value Information of Usage VR

Seq. Definition Attribute Description

1 Usage a2 Valid value:
identifier VR- Verification code information
2 VCODE ans20 VCODE is a string value generated by UPOP during authentication phase of
E-commerce transaction adopting SecurePlus Service.
Format: timestamp (YYYYMMDDHHMMSS) + 6 random digits

Reject Code
10613= Invalid characters in length field
10614= Length value exceeds 200
UPI CONFIDENTIAL 144
 Part II: Online Message

3.49 Field 62 Switching Data (Not used)

Attribute
ans..200(LLLVAR), 3-byte length value + GSCS switching data of maximum 200 bytes alphabetic, numeric, and special
characters
Description
GSCS switching data
Currently, this field is not used for Members outside of Mainland China.

UPI CONFIDENTIAL 145

 Part II: Online Message

3.50 Field 63 Financial Network Data

Attribute
ansb..512(LLLVAR), 3-byte length value + maximum 512 bytes alphabetic, numeric, and special characters and binary
numbers
Description
This field is defined as a multiple usage field to transmit detailed information about security data, including token
information, Merchant-presented QRC information, etc., in the transaction. Its usages are listed as follows:
• Usage TK: Token-related Information
• Usage MQ: Merchant-presented QRC Information (only transferred from the UMPS to the Acquirer)
For all usages, the general format is shown as follows:
Table 104 The General Format of Field 63

Field Usage Usage ID 1 Usage ID 1 Content .. Usage Usage ID n Usage ID n Content

Length ID 1 Length (TLV Element) ID n Length (TLV Element)
n3 an2 n3 ansb..507 an2 n3 ansb..507
This field can contain one usage or multiple usages based on the business requirements.
Table 105 The Usages in Field 63

Usage ID Definition Attribute

TK Token-related information ans..96
MQ Merchant-presented QRC information ans..512
Note 1: The Acquirer and the Issuer must support the reception of all usages and their subfield tags defined in the
Specifications, including unrecognized and unexpected usages and tags. The Acquirer and the Issuer can ignore the
unrecognized and unexpected usages and tags, and continue to process usages and tags in the field, without
causing system breakdown.
Note 2: The TLV format definition of this field is the same as that of Field 55 in the message. T and L are coded in
binary format and V is coded according to the format requirement of each subfield. Please refer to Section 6.44 for
details.
Note 3: If more than one usage is present in Field 63, the total length of all usages must not exceed the maximum
field length, i.e. 512 bytes.

Usage TK: Token-related information

3.50.3.1 Attribute
ans..96 , 2-byte Usage ID + 3-byte Length + maximum 91 bytes sub-TLVs
3.50.3.2 Description
Field 63 Usage TK must not be present in messages of transactions other than token-related transactions. This usage
is delivered to subscribing Issuers.
The value of the usage is TK + 3 bytes of total length of Usage TK + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 106 The Sub-TLVs of Usage TK

UPI CONFIDENTIAL 146

 Part II: Online Message

Definition Tag Format Description

Token 01 an1 This subfield will be filled based on whether the track or chip information
Information (including F23, F35, F36, F45, and F55) are verified by the GSCS.
Verification
Valid Values:
Indicator
0- Not verified (indicating it is a Token transaction, but the track or chip
information are generated by the Issuer)
1- Verified
Token 02 an..19 Token generated by the TSP
Token Expiry Date 03 an4 The expiry date of a Token that is generated by the TSP.
Format: YYMM
Token Assurance 04 an..2 The Token Assurance Level is defined by the TSP based on the risk
Level assessment.
Valid values:
0~99
Token Domain 05 n2 The Token Domain Identification indicates the application scenarios which
Identification are provided by the TR.
Valid values:
01- SE
02- HCE
03- QR Code
04- Card-on-File (COF)
05- Digital wallet
06- Chip or magnetic stripe card
TRID 06 an8..11 TRID is a unique number assigned by the TSP during TR Registration.
Reserved 07 ans..32 Currently not used.
Product 08 ansb4 The Product Identification is provided by the TR during Token Request.
Identification UnionPay system will de-tokenize the transaction and forward it to the
Issuer with this value in a Payment Token Transaction. If the TR does not
provide this information, this subfield will not be present in the Payment
Token Transaction.
The first byte of Product Identification indicates the product category and
the second to fourth bytes indicate the product sub-category:
Position Description
1 byte Filled with the product category with ans1 attribute.
Valid value:
1- Mobile payment
2~4 bytes Filled with the product sub-category with b24 attribute.
Valid value:
The 10th~12th bytes of 9F63

UPI CONFIDENTIAL 147

 Part II: Online Message

3.50.3.3 Usage
 Transmission Requirements of Usage TK in Original Request Transactions:
Table 107 Transmission Requirements of Usage TK in Original Request Transactions

Tag Definition Format Transmission Description

Requirements
AC SW IS SW
01 Token Information an1 C Present for Payment Token Transaction.
Verification Indicator
02 Token an..19 C Present for Payment Token Transaction.
03 Token Expiry Date an4 C Present for Payment Token Transaction.
04 Token Assurance Level an..2 C Present for Payment Token Transaction.
05 Token Domain n2 C Present for Payment Token Transaction.
Identification
06 TRID an8..11 C Present for Payment Token Transaction.
08 Product Identification ansb4 C6+ Present if the Product Identification is
provided by the TR during Token Request.
 Transmission Requirements of Usage TK in Subsequent Request Transactions:
Table 108 Transmission Requirements of Usage TK in Subsequent Request Transactions

Tag Definition Format Transmission Description

Requirements
AC SW IS SW
01 Token Information an1 C Present for Payment Token Transaction.
Verification Indicator
02 Token an..19 C Present for Payment Token Transaction.
03 Token Expiry Date an4 C Present for Payment Token Transaction.
04 Token Assurance Level an..2 C Present for Payment Token Transaction.
05 Token Domain n2 C Present for Payment Token Transaction.
Identification
06 TRID an8..11 C Present for Payment Token Transaction.
08 Product Identification ansb4 C6+ Present if the Product Identification is
provided by the TR during Token
Request.
Note: The tag values of TK usage in the cancellation or completion (request) message may be different from
those in the original transaction message according to the real situation.
 Transmission Requirements of Usage TK in Advice Transactions:
Table 109 Transmission Requirements of Usage TK in Advice Transactions (SWIS)

UPI CONFIDENTIAL 148

 Part II: Online Message

Tag Definition Format Transmission Description

Requirements
SW IS
01 Token Information an1 C Present for Payment Token Transaction.
Verification Indicator
02 Token an..19 C Present for Payment Token Transaction.
03 Token Expiry Date an4 C Present for Payment Token Transaction.
04 Token Assurance Level an..2 C Present for Payment Token Transaction.
05 Token Domain n2 C Present for Payment Token Transaction.
Identification
06 TRID an8..11 C Present for Payment Token Transaction.
08 Product Identification ansb4 C6+ Present if the Product Identification is
provided by the TR during Token Request.
Note: The subfield values of TK usage in reversal, refund, completion (advice), or confirmation message may be
different from those in the original transaction message according to the real situation.

Usage MQ: Merchant-presented QRC

3.50.4.1 Attribute
ans..512, 2-byte Usage ID + 3-byte Length + maximum 507 bytes sub-TLVs
3.50.4.2 Description
Field 63 Usage MQ is used to transfer the additional message from the UMPS to the Acquirer. It must not be present
in the cancellation, reversal, and refund messages.
The value of the usage is MQ + 3 bytes of total length of Usage MQ + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 110 The Sub-TLVs of Usage MQ

Definition Tag Format Description

Merchant- 01 ans..503 Present only when the Acquirer subscribes to Tag 01 and the QRC is less
presented QRC than 503 bytes in Merchant-presented QRC-based Payment.
Bill Number 02 ans..25 This number may be provided by the Merchant in the Merchant-
presented QRC, ID "01" under template "62", or may be input by the
consumer on the mobile application. For example, the Bill Number may
be present when the QRC is used for bill payment.
Mobile Number 03 ans..25 The mobile number may be provided by the Merchant in the Merchant-
presented QRC, ID "02" under template "62", or may be input by the
consumer on the mobile application. For example, the Mobile Number
to be used for multiple use cases, such as mobile top-up and bill
payment. The mobile number may be different from the consumer
mobile number.
Store Label 04 ans..25 A distinctive value associated with a store. This value may be provided

UPI CONFIDENTIAL 149

 Part II: Online Message

Definition Tag Format Description

by the Merchant in the Merchant-presented QRC, ID "03" under
template "62", or may be input by the consumer on the mobile
application. For example, the Store Label may be displayed to the
consumer on the mobile application, identifying a specific store.
Loyalty Number 05 ans..25 Typically a loyalty card number. This value may be provided by the
Merchant, if known, in the Merchant-presented QRC, ID "04" under
template "62", or may be input by the consumer on the mobile
application.
Reference Label 06 ans..25 Any value as defined by the Merchant or Acquirer in order to identify
the transaction. This value may be provided by the Merchant in the
Merchant-presented QRC, ID "05" under template "62", or may be input
by the consumer on the mobile application. For example, the Reference
Label may be used by the consumer mobile application for transaction
logging or receipt display.
Customer Label 07 ans..25 Any value identifying a specific consumer. This value may be provided
by the Merchant, if known, in the Merchant-presented QRC, ID "06"
under template "64", or may be input by the consumer on the mobile
application. For example, the Customer Label may be a subscriber ID for
subscription services, a student enrolment number, etc.
Terminal Label 08 ans..25 A distinctive value associated with a terminal in the store. This value
may be provided by the Merchant in the Merchant-presented QRC, ID
"07" under template "64", or may be input by the consumer. For
example, the Terminal Label may be displayed to the consumer on the
mobile application, identifying a specific terminal.
Purpose of 09 ans..25 Any value defining the purpose of the transaction. This value may be
Transaction provided by the Merchant in the Merchant-presented QRC, ID "08"
under template "64", or may be input by the consumer on the mobile
application. For example, the Purpose of Transaction may have the
value "International Data Package" for display on the mobile
application.
Email Address of 10 ans..100 This value should be provided by the mobile application. It will not be
the Consumer verified in the payment procedure, but provided to the
Acquirer/Merchant as additional information.
Mobile Number of 11 ans..25 This value should be provided by the mobile application. It will not be
the Consumer verified in the payment procedure, but provided to the
Acquirer/Merchant as additional information.
Address of the 12 ans..100 This value should be provided by the mobile application. It will not be
Consumer verified in the payment procedure, but provided to the
Acquirer/Merchant as additional information.
Response Code of 99 ans2 This value will only be present in the response message of transaction
Merchant- result inquiry to indicate the payment transaction outcome.
presented QRC
Payment Result

UPI CONFIDENTIAL 150

 Part II: Online Message

3.50.4.3 Usage
 The Transmission Requirements of Usage MQ in Payment Request Messages:
Table 111 The Transmission Requirements of Usage MQ in Payment Request Messages

Definition Tag Format Transmission Requirements Description

UMPS AC GSCS AC

AC IS GSCSAC UMPS

Merchant- 01 ans..502 C Present when it is a Merchant-

presented QRC presented QRC.
Bill Number 02 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Mobile Number 03 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Store Label 04 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Loyalty Number 05 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Reference Label 06 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Customer Label 07 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Terminal Label 08 ans..25 C Present only when the mobile
application sends the
information to UMPS.
Purpose of 09 ans..25 C Present only when the mobile
Transaction application sends the
information to UMPS.
Email Address of 10 ans..100 C Present only when the mobile
the Consumer application sends the
information to UMPS.
Mobile Number 11 ans..25 C Present only when the mobile
of the Consumer application sends the
information to UMPS.
Address of the 12 ans..100 C Present only when the mobile
Consumer application sends the
information to UMPS.
 The Transmission Requirements of Usage MQ in Merchant-presented QRC-based Transaction Result Inquiry

UPI CONFIDENTIAL 151

 Part II: Online Message

Messages:
Table 112 The Transmission Requirements of Usage MQ in Merchant-presented QRC-based Payment Transaction Result Inquiry
Messages

Definition Tag Format Transmission Requirements Description

UMPS ACGSCS AC

 AC ISGSCSAC UMPS

Response Code of 99 ans2 M Must be present in Merchant-

Merchant- presented QRC-based Payment
presented Payment Transaction Result Inquiry
Result Response Message

Reject Code
10633= Invalid characters in length field
10634= Length value exceeds 512
10635= Invalid characters

UPI CONFIDENTIAL 152

 Part II: Online Message

3.51 Field 70 Network Management Information Code

Attribute
n3, 3-digit numbers with fixed length

Description
It is a network management function code which is used to differentiate messages with the same message type
identifier and message format but different functions.
Usage 1: Network Management and Key Reset Message Identifier
Combined with the message type identifier of 0800/0810 and 0820/0830, this field indicates the network
management and key reset messages.
Table 113 The Network Management Information Code of Field 70 Usage 1

Message Type Network Message Type Definition

Identifier Management
Information Code
0820/0830 001 The Member signs on/UnionPay system informs the Member that
UnionPay system is enabled.
0820/0830 002 The Member signs off/UnionPay system informs the Member that
GSCS is disabled.
0800/0810 101 UnionPay resets the key.
0820/0830 101 The Member requests to reset the key.
0820/0830 201 UnionPay starts date switch.
0820/0830 202 UnionPay ends date switch.
0820/0830 301 Echo test
0820/0830 401 Stand-in authorization echo message.
0820/0830 501 Stand-in authorization transaction transmission activation.

0820/0830 502 Stand-in authorization online transmission completion/termination.

In UnionPay’s message it means transmission completion; in the
institution’s message it means termination.

Usage 2: Management Inquiry Transaction Identifier

Combined with the message type identifier of 0600/0610, this field indicates the exchange rate inquiry message or
the Merchant-presented QRC-based Payment transaction result inquiry message.
Table 114 The Network Management Information Code of Field 70 Usage 2

Message Type Network Management Message Type Definition

Identifier Information Code
0600/0610 801 UnionPay Card Exchange Rate Inquiry
0600/0610 810 Merchant-presented QRC-based Payment Transaction
Result Inquiry

UPI CONFIDENTIAL 153

 Part II: Online Message

Message Type Network Management Message Type Definition

Identifier Information Code
0600/0610 811 Reserved for Future Use on non-UnionPay standard
QRC-based payment product

Usage 3: IC Card Script Processing Result Advice Based on UICS Debit/Credit Standard
This script advice is applied to debit/credit application and electronic cash application. Combined with the message
type identifier 0620/0630, it indicates that the Acquirer needs to send the advice of script processing result when a
transaction includes the Issuer’s script.
Table 115 The Network Management Information Code of Field 70 Usage 3

Message Type Network Management Message Type Definition

Identifier Information Code
0620/0630 951 Script Processing Result Advice Based on UICS
Debit/Credit Standard

Usage 4: Stand-in Authorization Parameter Synchronization Advice Message

Table 116 The Network Management Information Code of Field 70 Usage 4

Message Type Network Management Message Type Definition

Identifier Information Code
0620/0630 902 Stand-in Authorization Parameter Synchronization
Advice Message

Reject Code
10705= Invalid code

UPI CONFIDENTIAL 154

 Part II: Online Message

3.52 Field 90 Original Data

Attribute
an42, 42-byte alphanumeric characters with fixed length

Description
This field contains original data elements used in reversal, cancellation, refund, primary credit confirmation, primary
credit transaction, etc. It includes the following subfields:
Table 117 Composition of Field 90

Position Byte 1~4 Byte 5~10 Byte 11~20 Byte 21~31 Byte 32~42
Subfield 90.1 90.2 90.3 90.4 90.5
Note for Incremental Pre-authorization/Authorization: It is mandatory for the Acquirer to fill Field 90 in the request
message of Incremental Pre-authorization/Authorization transaction. UPI system will forward Field 90 to the Issuer
directly. If the Acquirer fill Field 90 in the corresponding cancellation/refund transaction, Field 90 shall contain the
original data elements of the first pre-authorization/authorization transaction.

Field 90.1 Original Message Type

3.52.3.1 Attribute
n4, 4-digit numbers with fixed length
3.52.3.2 Description
This subfield contains the message type of the original transaction.

Field 90.2 Original System Trace Number

3.52.4.1 Attribute
n6, 6-digit numbers with fixed length
3.52.4.2 Description
This subfield contains the original system trace number, namely Field 11 of the original request message.

Field 90.3 Original System Date and Time

3.52.5.1 Attribute
n10, 10-digit numbers with fixed length
Format: MMDDhhmmss
3.52.5.2 Description
This subfield contains the system date and time of the original transaction, namely Field 7 of the original message.
Field 90.4 Original Acquirer ID
3.52.6.1 Attribute
an11, 11 alphanumeric characters with fixed length
3.52.6.2 Description
This subfield contains the Acquirer ID of the original transaction, namely Field 32 of the original request message,
without the length value. To minimize system change, Field 32 remains right justified and left padded with zeroes

UPI CONFIDENTIAL 155

 Part II: Online Message

although it is no longer a numeric field.

Field 90.5 Original Forwarding Institution ID
3.52.7.1 Attribute
an11, 11 alphanumeric characters with fixed length
3.52.7.2 Description
This subfield contains the forwarding institution ID of the original transaction, namely Field 33 of the original request
message, without the length value. To minimize system change, Field 32 remains right justified and padded with 0 to
the left although it is no longer a numeric field.

Reject Code
10905= Invalid characters

UPI CONFIDENTIAL 156

 Part II: Online Message

3.53 Field 96 Message Security Code

Attribute
64-bit binary number

Description
New single-length key defined by UnionPay and the Member

Usage
It is used in the transaction in which UnionPay system resets the key either initiatively or resets the key upon the
Member’s request. After UnionPay system generates the data key, it stores the newly produced key which is
encrypted by the Member Master Key (MMK) of the Member into this field, and sends it to the Member. When the
new key is of double or triple length or even longer length (16 bytes or 24 bytes or longer), it is stored in Field 48
(refer to Usage NK of Field 48), and this field is filled with binary 0.
The new key is generated by the HSM of UnionPay system. After the Member receives the new key sent by GSCS, the
key is decrypted by the HSM and then put into use.
The new key sent by UnionPay system is of 8-byte length.

Reject Code
N/A

UPI CONFIDENTIAL 157

 Part II: Online Message

3.54 Field 100 Receiving Institution Identification Code

Attribute
an..11(LLVAR), 2-byte length value + Receiving Institution Identification Code of maximum 11 alphanumeric
characters
Description
The code of the message receiving institution in the message
Usage
Please refer to Appendix A Code Definitions in the Technical Specifications on Bankcard Interoperability - Part VI
Annex for details.
This field appears in all transaction messages. The value is filled by UnionPay who designates the receiver of the
message. In the whole transaction process the value is unchanged.
In the transfer transaction, UnionPay system set this field as the identification code of the transfer-out side.
In the transfer-out and transfer-in transaction, this field is used to store the IIN of the receiver.

Reject Code
11003= Invalid characters in length field
11004= Length value exceeds 11

UPI CONFIDENTIAL 158

 Part II: Online Message

3.55 Field 102 Account Identification 1

Attribute
ans..28(LLVAR), 2-byte length value + the account identification number of maximum 28 bytes alphabetic, numeric,
and special characters.
Description
The payer’s Primary Account Number (PAN), namely the transfer-out account number.
Usage
For international remittance transaction, if the Acquirer (sender) remits fund from account or card instead of cash,
this field should be filled with the account or card number. For the Issuer in Chinese Mainland, only subscriber of this
field will receive it.

Reject Code
11023 = Invalid characters in length field
11024 = Length value exceeds 28
11025 = Invalid characters

UPI CONFIDENTIAL 159

 Part II: Online Message

3.56 Field 103 Account Identification 2

Attribute
ans..28(LLVAR), 2-byte length value + maximum 28 bytes alphabetic, numeric, and special characters.

Description
The payee’s Primary Account Number (PAN), namely the transfer-in account number

Usage
If the payee’s account is a bankcard account in AFT for domestic P2P transfer, this field shall be filled with the payee’s
PAN by the Acquirer and shall be received by the Issuer.

Reject Code
11033 = Invalid characters in length field
11034 = Length value exceeds 28
11035 = Invalid characters

UPI CONFIDENTIAL 160

 Part II: Online Message

3.57 Field 104 Transaction and Industry Application Information

Attribute
ansb..512(LLLVAR), 3-byte length value + maximum 512 bytes alphabetic, numeric, and special characters and binary
numbers.
Description
This field is defined as a multiple usage field to transmit detailed transaction and industry application information,
etc.
The general format of this field is:
<Field length><Usage ID1><Usage ID1 length><Usage ID1 content (TLV element)>...<Usage IDn><Usage IDn
length><Usage IDn content (TLV element)>
Note: The usage can be used separately or in a combined way based on different transaction scenarios.
The following table illustrates the format of Field 104:
Table 118 The General Format of Field 104

Field Usage Usage ID 1 Usage ID 1 Content .. Usage Usage ID n Usage ID n Content

Length ID 1 Length (TLV Element) ID n Length (TLV Element)
n3 an2 n3 ansb..507 an2 n3 ansb..507
 <Field Length>
It means the total length of the field (including <Usage ID>), occupying 3 bytes, padding 0s on the left, coded in ASCII.
 <Usage ID>
It indicates the following types of data, occupying 2 bytes, coded in ASCII. The usage identifiers in Field 104 are
described in the following table:
Table 119 The Usages in Field 104

Usage Definition Usage Identifier Attribute

Airline Industry Application Information AI ans..173
Cardholder Device Information CD ans..241
Business Indication BI ans9
Sending Information SI ans..510
Cross-border B2B Payment and Service Information BB ans..12
Wallet Information WI ans..42
Related Transaction Information RT ans49
Note: The Acquirer and the Issuer must be able to receive each usage identifier and its sub-field tag defined in
the specification, including the ones which cannot be recognized or are received unexpectedly. For
unexpected or unrecognized usage identifiers and their sub-fields, the Acquirer and the Issuer should ignore
them and continue to process other usage identifiers and their sub-field tags.
 <Usage Length>
It means the total length of the Usage ID, occupying 3 bytes, padding 0s on the left, coded in ASCII.

UPI CONFIDENTIAL 161

 Part II: Online Message

 <Usage Content>
It indicates the detailed data, the format that is dependent on the Usage ID, and the sub-fields that are composed by
one or multiple data elements in TLV format. The TLV format definition of this field is the same as that of Field 55.
Please refer to Field 55 for details.

Usage AI: Airline Industry Application Information

3.57.3.1 Attribute
ans..173, 2-byte Usage ID + 3-byte Length + maximum 168 bytes sub-TLVs
3.57.3.2 Description
This usage is to transmit auxiliary transaction information such as airline industry application information from the
Acquirer to the Issuer when the Cardholder takes an airplane or other means of transportation.
The value of the usage is AI + 3 bytes of total length of Usage AI + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 120 The Sub-TLVs of Usage AI

Definition Tag Format Description

Flight number 01 ans6 Refers to the number of the scheduled flight, i.e. the flight number from
the departure city to the destination city, which remains unchanged
throughout the entire flight. Domestic flight number is 6 bytes, such as
MU5101; international flight number is 5 bytes, such as MU583.
Aircraft- leg 1 02 ans5 Aircraft fixed serial number; the Chinese civil aviation aircraft starts with
B, followed by 4 digits, such as B6127.
The airline ticket 03 ans20 20 bytes of airline ticket number (if less than 20, padding spaces on the
number- leg 1 right).
Basic fare- leg 1 04 n12 This tag contains no decimal point; the decimal place is determined by
transaction currency. Please refer to Field 4.
The basic fare 05 an3 Indicates the currency of leg 1 fare.
currency- leg 1
The flight 06 ans8 8 bytes of flight departure date, with the format of YYYYMMDD.
departure date-
leg 1
The code of take- 07 ans3 Three characters, refer to the IATA International Airport Code, such as
off city- leg 1 Pudong Airport - PVG
The code of 08 ans3 Three characters, refer to the IATA International Airport Code, such as
landing city- leg 1 Pudong Airport - PVG
Aircraft- leg 2 09 ans5 Refers to the same tag of leg 1
The airline ticket 10 ans20 Refers to the same tag of leg 1
number- leg 2
Basic fare- leg 2 11 n12 Refers to the same tag of leg 1
The basic fare 12 an3 Indicates the currency of leg 1 fare
currency- leg 2

UPI CONFIDENTIAL 162

 Part II: Online Message

Definition Tag Format Description

The flight 13 ans8 Refers to the same tag of leg 1
departure date-
leg 2
The code of take- 14 ans3 Refers to the same tag of leg 1
off city- leg 2
The code of 15 ans3 Refers to the same tag of leg 1
landing city- leg 2
The sign-on time 16 n14 The start time of aircraft shopping system, Beijing time, with the format
of aircraft of YYYYMMDDhhmmss.
shopping system-
leg 1
The operator 17 ans6 The employee number of the crew, if less than 6 bytes, padding spaces on
number- leg 1 the right.

3.57.3.3 Usage
In the online message of purchase, pre-authorization, pre-authorization completion, MOTO, recurring, refund and
authorization transactions, the transmission requirement of Usage AI in Field 104 is defined below:
It is optional for the Acquirer to present Airline Industry Application Information through Usage AI in Field 104 during
airline E-commerce transactions.
GSCS will choose to intercept or switch Usage AI in Field 104, based on the Issuer’s business needs.
The Issuer can choose to subscribe this service or not according to its business needs.

Usage CD: Cardholder Device Information

3.57.4.1 Attribute
ans..241, 2-byte Usage ID + 3-byte Length + maximum 236 bytes sub-TLVs
3.57.4.2 Description
This usage is to submit the Cardholder’s Internet device IP information and other device information by the Acquirer.
UPI will do risk assessment and related process based on those information.
The value of the usage is CD + 3 bytes of total length of Usage CD + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 121 The Sub-TLVs of Usage CD

Definition Tag Format Description

IP version 01 n2 Valid values:
number 04- IPV4
06- IPV6
Client IP 02 ans..39 The IP address of the device used to initiate transaction by the
address Cardholder, compatible with both IPV4 and IPV6.
IPV4 sample: ***.***.***.***

UPI CONFIDENTIAL 163

 Part II: Online Message

Definition Tag Format Description

(Format: Decimal numbers separated by point, e.g.
173.016.035.002)
IPV6 sample: ****:****:****:****:****:****:****:****
(Format: Hex numbers divided by colon, e.g.
AD80:0000:0000:0000:ABAA:0000:00C2:0002)
MAC address 03 ans17 The MAC address of the device used to initiate transaction by the
Cardholder.
MAC sample: 00-23-5A-15-99-42
Format: Every two bytes are connected by “-”.
Device ID 04 ans..40 The hard disk serial number of desktop system, IMEI of Android
system, or IDFV of IOS system.
Note: When IMEI is unable to obtain in certain Android systems, the
device ID shall be filled with the device information that can be
obtained first from the priority queue: IMEI→DRM→UDID→GUID.
Device SIM card 05 ans..20 The mobile number used by the Cardholder.
number
Format: Comply with the requirement specified in E.164, e.g.
country code + mobile number: +14168362570; +86137xxxxxxxx
LBS information 06 ans..32 Latitude and longitude
Format: Latitude/ longitude
+ denotes north latitude and east longitude
- denotes south latitude and west longitude
E.g.: +37.12/-121.23 or +37/-121
Number of 07 ans..2 Applicable in Mainland China only
Device SIM card
Device type 08 ans..2 Applicable in Mainland China only
Device model 09 ans..64 Applicable in Mainland China only
number

3.57.4.3 Usage
In the online messages of purchase, pre-authorization, pre-authorization completion, recurring, MOTO, primary
credit, refund, balance inquiry, authorization, and establishment of commission relationship transactions, the
transmission requirement of Usage CD in Field 104 is defined below:
The Acquirer should present Cardholder IP and Device Information through Usage CD in Field 104 during E-commerce
transactions.
The Issuer can choose to subscribe to this service or not according to its business needs. UPI system will choose to
intercept or switch Usage CD in Field 104, based on the Issuer’s business needs.

Usage BI: Business Indication

UPI CONFIDENTIAL 164

 Part II: Online Message

3.57.5.1 Attribute
ans9, 2-byte Usage ID + 3-byte length + 4 bytes sub-TLV
3.57.5.2 Description
This usage indicates the specific business type of a PCT or AFT. It is mandatory for the Acquirer to fill Field 104 Usage
BI in PCT or AFT.
The value of the usage is BI + 3 bytes of total length of Usage BI + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 122 The Sub-TLVs of Usage BI

Definition Tag Format Description

Business 01 n2 This tag is used to identify the specific PCT/AFT business type.
Type
Valid values:
00- General payment: Default value
01- Domestic fund transfer: Domestic fund transfer with Personal account (card) via
mobile device or online banking, etc. (Applicable in Mainland China only)
02- Cash Payment: Personal cash deposit
03- Cash Rebate: Cash Rebate
04- Merchant Settlement: UPI special Merchant fund transfer
05- Fund disbursement for products of agriculture, forestation, animal husbandry,
and fishery: UPI fund disbursement business for products of agriculture,
forestation, animal husbandry, and fishery (Applicable in Mainland China only)
06- Tax Refund: Reserved for tax refund business
07- Cross-border Remittance: Cross-border remittance business
08- P2P Transfer : Domestic person-to-person transfer (only used outside of
Mainland China)
09- Prepaid Card Loading: Reserved for future use
10- Wallet Transfer: Domestic fund transfer involving a Staged Digital Wallet
Operator
11- Redemption of wealth management products : Applicable in Mainland China
only
12- Government Services: Applicable in Mainland China only
13- Reserved
14- Payout: Payout to merchandise/service providers
15~99- Reserved

3.57.5.3 Usage
This usage is applicable to primary credit (online & batch), primary credit confirmation and account funding
transactions.
It is mandatory for Acquirers to send Usage BI in Field 104 in primary credit (online & batch), primary credit
confirmation and account funding transactions.
It is mandatory for Issuers to receive Usage BI in Field 104 in primary credit (online & batch), primary credit
confirmation and account funding transactions.

Usage SI: Sending Information

UPI CONFIDENTIAL 165

 Part II: Online Message

3.57.6.1 Attribute
ans..510, 2-byte Usage ID + 3-byte length + maximum 505 bytes sub-TLVs
3.57.6.2 Description
If the local government requires Know Your Client (KYC) checking, it is mandatory for the Acquirer to fill Usage SI in
Field 104. For example, the payment system may be required to store the payer’s or the payee’s personal information,
including gender, nationality, etc., in a PCT/AFT. Whether F104 Usage SI is to be received by the Issuer or not is at the
discretion of the Issuer. GSCS can intercept or forward F104 Usage SI based on the Issuer’s business choice.
The value of the usage is SI + 3 bytes of total length of Usage SI + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 123 The Sub-TLVs of Usage SI

Definition Tag Format Description

Counterparty’s account 01 n..19 In a primary credit transaction, the payer’s account number should
number be put in this field.
In an account funding transaction, the payee’s account number
should be put in this field.
Counterparty’s name 02 ans30 In a primary credit transaction, the payer’s name should be put in
this field and ASCII encoded.
In an account funding transaction, the payee’s name should be put
in this field.
Note: Special characters and numeric are not allowed:
a) ? (Question mark) and special characters
b) All numeric
c) Only one character
Counterparty’s birthday 03 n8 Format: YYYYMMDD
Counterparty’s gender 04 ans1 Valid values:
M- Male
F- Female
O- Others
Counterparty’s 05 ans3 The country code of nationality. Please refer to Section A.5
nationality Country/Region and Currency Code in the Technical Specifications
on Bankcard Interoperability - Part VI Annex.
The country of 06 ans3 The country code of the permanent residence. Please refer to
counterparty’s Section A.5 Country/Region and Currency Code in the Technical
permanent residence Specifications on Bankcard Interoperability - Part VI Annex.
The city of 07 ans..40 These two subfields shall be coded in Standard ASCII printable
counterparty’s characters (refer to Section A.6 in the Technical Specifications on
permanent residence Bankcard Interoperability - Part VI Annex.). If Issuers from Hong
Kong and Macao choose to support the city and address value in
The address of 08 ans..80
Chinese, GB18030-2000 coding rules should be supported
counterparty’s
permanent residence
Indicator of whether 09 n1 This subfield indicates whether the payer and the payee are the

UPI CONFIDENTIAL 166

 Part II: Online Message

Definition Tag Format Description

the payer and the same person. It shall be filled by payer.
payee are the same
Valid values:
person
0- The payer and the payee are not the same person.
1- The payer and the payee are the same person.
Fund source 10 n1 In a remittance transaction, it indicates the fund source. It shall be
filled by the payer or the Acquirer.
Valid values:
0- Cash
1- Debit card
2- Credit card
3- Account funds
Additional data 11 ans..50 In a remittance or P2P transaction, the Acquirer shall fill the data
required by the out the scope of tag 01~10 but required by the local regulator.
regulator
In a remittance transaction, the Acquirer shall fill the beneficiary’s
name in this tag. Other data required by local regulator should
follow the beneficiary’s name.
Note: Special characters and numeric are not allowed:
a) ? (Question mark) and special characters
b) All numeric
c) Only one character
Note 12 ans..50 The note transmits the message that the sender passes to the
receiver. This tag shall follow these rules:
a. This tag is UTF-8 encoded.
b. For P2P transaction, this tag will be filled in the local language.
The receiver can display the note in bill for the Cardholder.
Reserved 13 ans..90 Reserved
Chinese abbreviation 14 ans..40 Applicable in Mainland China only
of the counterparty’s
name
Reserved 15 ans..32 Reserved
Reserved 16 ans..6 Reserved
Reserved 17 ans..14 Reserved
Counterparty’s ID type 18 n2 Applicable in Chinese Mainland only
Counterparty’s ID 19 ans..20 Applicable in Chinese Mainland only
number

3.57.6.3 Usage
This usage is applicable to primary credit (online & batch), primary credit confirmation and account funding
transactions.
For the Acquirer, when the local government has the regulations on PCT and AFT, the Acquirer shall submit Field 104

UPI CONFIDENTIAL 167

 Part II: Online Message
Usage SI. The transmission requirement of F104 Usage SI for the Issuer varies based on the Issuer’s business need. If
the Issuer chooses to receive F104 Usage SI, GSCS will forward the usage to the Issuer. Otherwise, GSCS does not
forward F104 Usage SI.

Usage BB: B2B Payment and Service Indicator

3.57.7.1 Attribute
ans..12, 2-byte Usage ID + 3-byte Length + maximum 7 bytes sub-TLVs
3.57.7.2 Description
This usage indicates B2B business in online transactions.
The value of the usage is BB + 3 bytes of total length of Usage BB + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 124 The Sub-TLVs of Usage BB

Definition Tag Format Description

Business 01 n2 This sub-field is used to identify the specific B2B business type.
type
Valid values:
00- Reserved
01- Merchant fund collection based on UnionPay transaction data: Chinese
import merchant fund collection business, based on UnionPay transaction data.
(Currently this business is only enabled in Mainland China.)
02- Merchant fund collection based on enterprise’s transaction data: Chinese
import merchant fund collection business, based on enterprise’s transaction
data. (Currently this business is only enabled in Mainland China.)
03- Account based payment product: B2B payment product, based on bank
account (Reserved for use)
04- Card based payment, direct payment: Merchants/acquirers call the
payment interface of the B2B platform to generate direct payment.
05- Card based payment, e-invoice payment, API mode: Merchants/Acquirers
call the e-invoice payment interface of the B2B platform to generate payment.
06- Card based payment, e-invoice payment, Portal mode: Merchants generates
e-invoice on the website of B2B platform.
07- Payout, payout to merchandise/service providers: Acquirers/Merchants call
the Payout interface of B2B Platform to initiate PCT Payout transactions to
UnionPay Cards.
08~99- Reserved
Payment 02 n1 This sub-field is used to identify the specific B2B business medium.
medium
Valid values:
0- Reserved
1- Enterprise e-banking payment (Currently only enabled in Mainland China)
2- Card-not-present payment
3~9- Reserved

3.57.7.3 Usage
This usage is applicable to purchase, pre-authorization, pre-authorization completion, authorization, primary credit,
primary credit confirmation, refund, corresponding dispute transactions and subsequent cancellation / reversal
transactions.
UPI CONFIDENTIAL 168
 Part II: Online Message
For B2B payment and service except for Payout, B2B platform will submit the usage to UPOP and UPOP will forward
the transaction to GSCS. For Payout, B2B platform will submit the usage to GSCS directly. The Acquirer does not need
to submit Usage BB. The Issuer will receive Usage BB if it has subscribed to the usage.
For detailed transmission requirements, please see section 4.5.1. However, note that in message definition tables in
section 4.5.1, AC refers to UPOP or B2B platform for Field 104 Usage BB.
Usage WI: Wallet Information
3.57.8.1 Attribute
ansb..42, 2-byte Usage ID + 3-byte length + maximum 37 bytes sub-TLVs
3.57.8.2 Description
Usage WI is used to provide information about the staged digital wallet operator, including the wallet ID and the
wallet name.
The value of the usage is WI + 3 bytes of total length of Usage WI + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 125 The Sub-TLVs of Usage WI

Definition Tag Format Description

Wallet ID 01 an8 Used to indicate the unique ID of the staged digital wallet operator.
Wallet name 02 ans25 Used to indicate the name of the staged digital wallet operator.

3.57.8.3 Usage
It is mandatory for the Acquirer to fill Field 104 Usage WI in an SDWO transaction. In the request message of an
SDWO transaction sent to the Issuer, GSCS will forward or intercept this usage based on the Issuer’s choice. Please
note that in PCT and AFT, Field 104 Usage WI Tag 02 is not present, as the wallet name is filled in F43 Card Acceptor
Name/Location. In an SDWO transaction for back-to-back purchase, both Tag 01 and Tag 02 Field 104 Usage WI shall
be filled by the Acquirer.

Usage RT: Related Transaction Information

3.57.9.1 Attribute
ans49, 2-byte Usage ID + 3-byte length + 44 bytes sub-TLV
3.57.9.2 Description
Usage RT is used to indicate the key elements of related transactions, including original message type, original system
trace number, original system date and time and original Acquirer IIN.
The value of the usage is RT + 3 bytes of total length of Usage RT + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 126 The Sub-TLVs of Usage RT

Definition Tag Format Description

Related key 01 ans42 Used to indicate the key elements of related transactions.
elements
The format of tag 01 is the same as Field 90, which contains original message
type, original system trace number, original system date and time and

UPI CONFIDENTIAL 169

 Part II: Online Message

Definition Tag Format Description

original Acquirer ID.

3.57.9.3 Usage
This usage is applicable to purchase, pre-authorization and authorization transactions.
It is mandatory for the Acquirer to fill in Field 104 Usage RT in the debt recovery of transit transactions which includes
purchase, pre-authorization and authorization transactions.
UPI system will choose to intercept or switch Usage RT in Field 104, based on the Issuer’s business needs.
The Issuer can choose to subscribe this service or not according to its business needs.

Reject Code
11043= Invalid characters in length field
11044= Length value exceeds 512
11045= Invalid characters

UPI CONFIDENTIAL 170

 Part II: Online Message

3.58 Field 113 Additional Information

Attribute
ansb..512(LLLVAR), 3-byte length value + maximum 512 bytes alphanumeric and special characters, and binary
numbers
Description
This field is defined as a multiple usage field to transmit detailed information about value-added service, such as
promotion and fee-related information, etc.
The general format of this field is the same as that of Field 104. Please refer to Section 3.58.2 for details.
Table 127 The Usages in Field 113

Usage Definition Usage Identifier Attribute

Value-added information VA ansb..190
SRC Dynamic Data SD ansb..185
Usage for UnionPay Inner Interface (Reserved) UP ansb..150
Note 1: The Acquirer and the Issuer must support the reception of all usages and their subfield tags defined in
the Specifications, including unrecognized and unexpected usages and tags. The Acquirer and the Issuer can
ignore the unrecognized and unexpected usages and tags and continue to process usages and tags in the field,
without causing system breakdown.
Note 2: If more than one usage is present in Field 113, the total length of all usages must not exceed the
maximum field length, i.e., 512 bytes.

Usage VA: Value-added Information

3.58.3.1.1 Attribute
ansb..190, 2-byte Usage ID + 3-byte length + maximum 185 bytes sub-TLVs
3.58.3.2 Description
This usage is used to transmit details about the discount, such as the coupon details in the U-plan program. It is
present in messages for U-plan payment transactions, including coupon write-off and coupon reversal between the
Acquirer and the U-plan, and Merchant-presented QRC-based Payment request between the UMPS and the Acquirer.
In the instant discount payment, UPI will send it to the Issuer in the request message based on the choice of the
Issuer. The instant discount is applicable to purchase, pre-authorization, pre-authorization completion and
authorization.
The value of the usage is VA + 3 bytes of total length of Usage VA + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. For example, if the coupon code is
1234567890123456789, Field 113 can be: VA (ASCII encoded, 2 bytes) + 021 (ASCII encoded, 3 bytes) + 01 (HEX
encoded, 1 byte) + 19 (binary encoded, 1 byte) + 1234567890123456789 (ASCII encoded, 19 bytes).
Table 128 The Sub-TLVs of Usage VA

Definition Tag Format Description

Coupon Information 01 ans..19 The coupon information.
Cost Amount (After 02 n12 The cost amount after discount. It is in the currency indicated by

UPI CONFIDENTIAL 171

 Part II: Online Message

Definition Tag Format Description

Discount) Field 49.
Amount of Discount 03 n12 The amount of discount. It is in the currency indicated by Field 49.
Note 04 ans..120 The tag is of variable length. The information can be displayed in
the Merchant receipt or the terminal screen (if it exists).
Original Amount 05 n12 The original amount. It is in the currency indicated by Field 49.
(Before Discount)

3.58.3.3 Usage
For Merchant-presented QRC-based Payment, Field 113 Usage VA tag 01, tag 03 and tag 05 will be transferred from
UMPS to the Acquirer in the request message if U-plan discount is applicable, and Field 113 VA tag 02, tag 03 and tag
05 will be transferred from GSCS to the Issuer in the request if the instant discount is applicable. The transmission
requirements of Usage VA in the Merchant-presented QRC Payment is shown in the following table.
Table 129 Transmission Requirements of Usage VA in the Merchant-presented QRC Payment Transactions

Definition Tag Format Transmission Requirements

UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
Coupon Information 01 ans..19 C
Cost Amount (After Discount) 02 n12 C
Amount of Discount 03 n12 C C
Original Amount (Before Discount) 05 n12 C C
For other payment transactions, including purchase, pre-authorization, pre-authorization completion, and
authorization, Field 113 VA tag 02, tag 03 and tag 05 will be transferred from GSCS to the Issuer in the request
message if the instant discount is applicable.
Table 130 Transmission Requirements of Usage VA in the Other Transactions

Definition Tag Format Transmission Requirements

UMPS AC GSCS IS GSCS AC
AC GSCW IS GSCS AC UMPS
Cost Amount (After Discount) 02 n12 C
Amount of Discount 03 n12 C
Original Amount (Before Discount) 05 n12 C

Usage SD: SRC Dynamic Data

3.58.4.1.1 Attribute
ansb..185, 2-byte Usage ID + 3-byte length + maximum 180 bytes sub-TLVs
3.58.4.2 Description
This usage is used to transmit details about the SRC dynamic data.
The value of the usage is SD + 3 bytes of total length of Usage SD + subTLV1+subTLV2+....+subTLVn. According to

UPI CONFIDENTIAL 172

 Part II: Online Message
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 131 The Sub-TLVs of Usage SD

Definition Tag Format Description

Transaction Cryptogram 01 ans..64 Transaction Cryptogram generated by UPI
Correlation ID 02 ans36 The ID of a specific SRC transaction
DPA ID 03 ans..64 The Merchant ID allocated by UPI when onboarding SRC system
DCF ID 04 ans8 The wallet ID allocated when onboarding SRC system

3.58.4.3 Usage
The usage is generated and returned by UnionPay SRC system when the Acquirer/Merchant applies for authorization
payload in an SRC checkout, which ensures that the subsequent authorization with the usage is related to the specific
SRC checkout. The Acquirer shall transfer the usage along with the payload returned by SRC system to GSCS for
payment (purchase, pre-authorization, and authorization) request.
Table 132 Transmission Requirements of Usage SD in SRC-related Payment Request Message

Definition Tag Format Transmission Description

Requirements
AC SW IS SW
Transaction 01 ans..64 M Present for SRC purchase, SRC pre-
Cryptogram authorization and SRC authorization.
Correlation ID 02 ans36 M Present for SRC purchase, SRC pre-
authorization and SRC authorization.
DPA ID 03 ans..64 M Present for SRC purchase, SRC pre-
authorization and SRC authorization.
DCF ID 04 ans8 M Present for SRC purchase, SRC pre-
authorization and SRC authorization.

Usage UP: Usage for UnionPay Inner Interface (Reserved)

Reject Code
11133= Invalid characters in length field
11134= Length value exceeds 512
11135= Invalid characters

UPI CONFIDENTIAL 173

 Part II: Online Message

3.59 Field 117 National and Regional Information

Attribute
ansb..256(LLLVAR), 3-byte length value + maximum 256 bytes alphabetic, numeric, and special characters, and binary
numbers.
Description
This field is defined as a multiple usage field to transmit national or regional information.
The general format of this field is the same as that of Field 104. Please refer to Section 3.58.2 for details.
Table 133 The Usages in Field 117

Usage Definition Usage Identifier Attribute

Multi Language Merchant Name and Address ML ans47
Payment Facilitator Information PF an15
Correlated Message ID Information MI ansb..56
Value-added Tax Information (Reserved) VT N/A
Note: The Acquirer and the Issuer must support the reception of all usages and their subfield tags defined in
the Specifications, including unrecognized and unexpected usages and tags. The Acquirer and the Issuer can
ignore the unrecognized and unexpected usages and tags and continue to process usages and tags in the field,
without causing system breakdown.

Usage ML: Multi Language Merchant Name and Address

3.59.3.1 Attribute
ans47, 2-byte Usage ID + 3-byte Length + 42-byte sub-TLV
3.59.3.2 Description
The value of the usage is ML + 3 bytes of total length of Usage ML + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 134 The Sub-TLVs of Usage ML

Definition Tag Format Description

Multi Language 01 ans40 The format of tag 01 is the same as Field 43, which contains Merchant
Merchant Name and name or ATM location, City’s name, and Country/Region Code. Please
Address refer to Section 3.34.2 for more details.
Note 1: This usage is UTF-8 encoded.
Note 2: For the Acquirer outside of Mainland China, this usage will be filled with Merchant name and address
in the local language, with Field 43 filled in with English.
Note 3: For the Acquirer inside Mainland China, this usage will be filled with Merchant name and address in
English characters, with Field 43 filled in with English.

3.59.3.3 Usage
This usage will only be applicable to the request messages (XX00, XX20), while response messages are not affected.

UPI CONFIDENTIAL 174

 Part II: Online Message
Acquirers can submit this usage when Field 43 is required in the request messages. If Issuers receive this usage in
other transactions, they should ignore it.
It is optional for Acquirers outside of Mainland China to submit this usage unless required by local regulations.
It is optional for Issuers outside of Mainland China to support this usage unless required by local regulations. If Issuers
want to receive this field, they have to apply for it. Otherwise, UnionPay will truncate this field to avoid failure of
Issuers’ systems to process it. When an Issuer supports this field, but is unable to parse the field, the Issuer should
ignore it and continue to process the transaction.

Usage PF: Payment Facilitator Information

3.59.4.1 Attribute
an15, 2-byte Usage ID + 3-byte Length + 10-byte sub-TLV
3.59.4.2 Description
Usage PF is used to provide information of the payment facilitator, including the PF ID.
The value of the usage is PF + 3 bytes of total length of Usage PF + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 135 The Sub-TLVs of Usage PF

Definition Tag Format Description

PF ID 01 an8 The payment facilitator ID assigned by UPI.

3.59.4.3 Usage
This usage is applicable to purchase, pre-authorization, authorization, recurring, account verification, establishment
of commission relationship, revocation of commission relationship, primary credit transaction, primary credit
confirmation transactions, and refund transactions.
For the Acquirer that registers a Payment Facilitator as a Third Party Service Provider, the PF ID shall be filled in F117
Usage PF in the request messages of transactions submitted by Merchants registered with the Payment Facilitator
within the agreed business scope (PF transactions). The Issuer is recommended to receive Usage PF for transaction
risk monitoring, data breach investigation etc., and UPI will forward or intercept this usage based on the Issuer’s
choice.

Usage MI: Correlated Message ID Information

3.59.5.1 Attribute
ansb..56, 2-byte Usage ID+3-byte length + maximum 51 bytes
3.59.5.2 Description
Usage MI provides the message ID of the transaction correlated to the current message.
The value of the usage is MI + 3 bytes of total length of Usage MI + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
The description of Usage MI sub-fields is shown in the following table:
Table 136 The Sub-TLVs of Usage MI

UPI CONFIDENTIAL 175

 Part II: Online Message

Definition Tag Format Description

Correlated 01 an..49 Message ID of the transaction correlated to the preceding QRC-based
Message ID transaction for the current message.

3.59.5.3 Usage
This usage is only applicable to QRC-based Purchase and QRC-based Authorization.
If the current message is linked to a Consumer-presented QRC transaction, Sub-Field Correlated message ID is filled
with the Message ID of the correlated Consumer-presented QRC Payload Generation request. If the current message
is linked to a Merchant-presented QRC transaction, Sub-Field Correlated message ID is filled with the Message ID of
the related Merchant-presented QRC-based Payment request.
It’s optional for Issuers outside of Mainland China to subscribe to this Usage.
Issuers may use the correlated Message ID to match the authorization message with the original QRC-based
transaction initiated by its mobile app. This Usage will not impact on an Issuer if it authorizes a QRC-based payment
transaction initiated by an app not owned by itself. In that case, the Issuer should ignore this Usage.
Table 137 Transmission Requirements of Usage MI in QRC-based Payment Transactions

Definition Tag Format Transmission Description

Requirements
AC SW IS SW

Correlated 01 an..49 C Present for QRC-based purchase/authorization

Message ID when Issuer subscribes Field 117 Usage MI.

Usage VT: Value-added Tax Information (Reserved)

Reject Code
11173= Invalid characters in length field
11174= Length value exceeds 256
11175= Invalid characters

UPI CONFIDENTIAL 176

 Part II: Online Message

3.60 Field 121 GSCS Reserved

Attribute
ans..100(LLLVAR), 3-byte length value + UnionPay reserved data of maximum 100 bytes alphabetic, numeric, and
special characters
Description
This field is used by UnionPay to store transaction data.
It is the identifier that UnionPay system distributes to the approved transaction and it is composed of the following
subfields:
Table 138 Composition of Field 121

Position Byte 1 Byte 2 Byte 3 Byte 4~43 Byte 44~81

Subfield 121.1 121.2 121.3 121.4 121.5

Field 121.1 Response/Response Reason Code

3.60.3.1 Attribute
ans1, 1-byte alphabetic, numeric, or special character
3.60.3.2 Description
It indicates how UnionPay or the Issuer processes the request message. The detailed information is as follows:
Table 139 The Sequence and Value Information of Field 121.1

Position Definition Attribute Description

Byte 1 F121.1 ans1 Valid values:
Response/Response 1- GSCS detects the time-out of the request, and the stand-in
Reason Code authorization is enabled.
2- Transaction amount is lower than the amount limit set by
the Issuer, and the stand-in authorization is enabled.
3- The Issuer’s system is blocked, and the stand-in
authorization is enabled.
4- The Issuer’s system is unable to process the transaction,
and the stand-in authorization is enabled (malfunction in the
communication line connecting to the Issuer).
5- The Issuer processes and responds.
6- The Issuer signs off.
7- UnionPay notifies the Issuer to sign off.
A- It indicates that the rejection is caused by the transfer-out
side, which identifies the reject reason combined with the
response code.
B- It indicates that the rejection is caused by the transfer-in
side, which identifies the reject reason combined with the
response code.

3.60.3.3 Usage
This field is filled by UnionPay.
When UnionPay returns the response to the Acquirer, this field is used to notify the Acquirer of the processing status

UPI CONFIDENTIAL 177

 Part II: Online Message

of the transaction request. It can contain the value of 5, 6, 7, A and B.

When UnionPay sends the information of the stand-in authorization to the Issuer, it adds this field to notify the
reason for the stand-in authorization to the Issuer. It can contain the value of 1, 2, 3 and 4.

Field 121.2 Single to Dual or Dual to Single Message Conversion Code

3.60.4.1 Attribute
ans1, 1-byte alphabetic, numeric, or special character
3.60.4.2 Description
Identifier of the single/ dual conversion. The value of this field is as follows:
Table 140 The Sequence and Value Information of Field 121.2

Position Definition Attribute Description

Byte 2 F121.2 ans1 Valid values:
Single to Dual or Dual to Single 1- UnionPay does not process it.
Message Conversion Code 2- Single-message transaction submitted by the
Acquirer is converted into dual-message by GSCS.
3- Dual-message transaction submitted by the
Acquirer is converted into single-message by GSCS.

3.60.4.3 Usage
This field is filled in by GSCS. It is added to the message that UnionPay sends to the Issuer, indicating whether single/
dual message conversion is conducted.

Field 121.3 Card Type

3.60.5.1 Attribute
ans1, 1-byte alphabetic, numeric, or special character
3.60.5.2 Description
This field indicates the type of the card involved in the transaction. The value of this field is as follows:
Table 141 The Sequence and Value Information of Field 121.3

Position Definition Attribute Description

Byte 3 F121.3 ans1 Valid values:
Type of the card and whether it is a UnionPay 9- UnionPay credit card
Card C- UnionPay debit card
A- UnionPay quasi credit card
1- Non UnionPay card, credit card
4- Non UnionPay card, debit card
2- Non UnionPay card, quasi credit
card

3.60.5.3 Usage
This field is filled in by UnionPay.

Field 121.4 GSCS Reserved

UPI CONFIDENTIAL 178

 Part II: Online Message

3.60.6.1 Attribute
ans40, 40-byte alphabetic, numeric, and special characters
3.60.6.2 Description
This subfield is filled in by UnionPay to match the original transaction.
3.60.6.3 Usage
The receiver of the message should keep the value of this field and return this field unchanged in the response
message.

Field 121.5 Fee Detail (Reserved for Use)

3.60.7.1 Attribute
ans38, 38-byte alphabetic, numeric, and special characters
3.60.7.2 Description
ISO defines this field as private data. This document applies this field in many usages, each of which has a specific
format. This sub-field is currently reserved for future use. For all usages, the following general format is used: <usage
identifier> <data>
<Usage identifier>: a 2-byte identifier that signifies the data type.
Table 142 The Usage(s) in Field 121.5

Usage Identifier Usage Definition

FD Fee Detail
<data>: The detailed data, see its format at <usage identifier>, and the length is 36 bytes in maximum.
3.60.7.3 Usage FD: Fee Detail
The cross-border fee to be charged by UPI, reserved for future use.

Reject Code
11213= Invalid characters in length field
11214= Length value exceeds 100
11215= Invalid characters

UPI CONFIDENTIAL 179

 Part II: Online Message

3.61 Field 122 Acquirer Institution Reserved

Attribute
ans..100(LLLVAR), 3-byte length value+ maximum 100 bytes alphabetic, numeric, and special characters reserved by
the Acquirer
Description
It is used by the Acquirer to reserve transaction data. It is optional for the Acquirer to fill in this field.
Table 143 Composition of Field 122

Position Byte 1~6 Byte 7~100

Subfield 122.1 122.2

Field 122.1 Merchant Discount Rate

3.61.3.1 Attribute
ans6, 6-byte letters, numbers or special characters with fixed length
3.61.3.2 Description
This subfield is filled in by the Acquirer, containing the 6 digits of the Merchant discount rate, and the value is the
actual Merchant discount rate * 10000.

Field 122.2 Acquirer Information

3.61.4.1 Attribute
ans..94, the Acquirer’s information of maximum 94 bytes letters, numbers and special characters
3.61.4.2 Description
This subfield is filled in by the Acquirer to match the original transaction. When UnionPay receives the message, it
keeps the value of this field in GSCS and returns the original value to the Acquirer in the response message.

Usage
This field is used by the Acquirer to indicate the Merchant discount rate and to match the original transaction.

Reject Code
11223= Invalid characters in length field
11224= Length value exceeds 100
11225= Invalid characters

UPI CONFIDENTIAL 180

 Part II: Online Message

3.62 Field 123 Issuer Institution Reserved

Attribute
ans..100(LLLVAR), 3-byte length value + maximum 100 bytes alphabetic, numeric, and special characters reserved by
the Issuer
Description
It is used to reserve the transaction data by the Issuer. This field is optional.
Usage
This field is filled in by the Issuer to match the original transaction. When Union Pay receives the message, it stores
the value of this field in UnionPay system and returns the original value to the Issuer in the reversal message.

Reject Code
11233= Invalid characters in length field
11234= Length value exceeds 100
11235= Invalid characters

UPI CONFIDENTIAL 181

 Part II: Online Message

3.63 Field 125 Security and Risk Assessment Information

Attribute
ansb..256(LLLVAR), 3-byte length value + maximum 256-byte alphabetic, numeric, and special characters

Description
This field is defined as a multiple usage field to transmit detailed transaction and industry application information,
etc.
The general format of this field is:
<Field length><Usage ID1><Usage ID1 length><Usage ID1 content (TLV element)>...<Usage IDn><Usage IDn
length><Usage IDn content (TLV element)>
Note: The usage can be used separately or in a combined way based on different transaction scenarios.
The following table illustrates the format of Field 104:
Table 144 The General Format of Field 125

Field Usage Usage ID 1 Usage ID 1 Content .. Usage Usage ID n Usage ID n Content

Length ID 1 Length (TLV Element) ID n Length (TLV Element)
n3 an2 n3 ansb..507 .. an2 n3 ansb..507
 <Field Length>
It means the total length of the field (including <Usage ID>), occupying 3 bytes, padding 0s on the left, coded in ASCII.
 <Usage ID>
It indicates the following types of data, occupying 2 bytes, coded in ASCII. The usage identifiers in Field 125 are
described in the following table:
Table 145 The Usages in Field 125

Usage Definition Usage Identifier Attribute

Compromised Account Indicator CA ans..60
QRC-based Payment QR ansb..120
Consumer Verification Information CV ans8
Innovative Payment IP ans..138
Low Risk Identifier LR ans..23
Authentication Transaction Identifier TF ans43
UnionPay Application Indicator (Reserved) QP ans5
Note 1: The Acquirer and the Issuer must be able to receive each usage identifier and its sub-field tag defined
in the specification, including the ones which cannot be recognized or are received unexpectedly. For
unexpected or unrecognized usage identifiers and their sub-fields, the Acquirer and the Issuer should ignore
them and continue to process other usage identifiers and their sub-field tags.
Note 2: If more than one usage is present in Field 125, the total length of all usages must not exceed the
maximum field length, i.e. 256 bytes.
 <Usage Length>

UPI CONFIDENTIAL 182

 Part II: Online Message

It means the total length of the Usage ID, occupying 3 bytes, padding 0s on the left, coded in ASCII.
 <Usage Content>
It indicates the detailed data, the format that is dependent on the Usage ID, and the sub-fields that are composed by
one or multiple data elements in TLV format. The TLV format definition of this field is the same as that of Field 55.
Please refer to Field 55 for details.
Usage CA: Compromised Account Indicator
3.63.3.1 Attribute
ans..60, 2-byte Usage ID + 3-byte Length + maximum 55 bytes sub-TLVs
3.63.3.2 Description
The value of the usage is CA + 3 bytes of total length of Usage CA + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 146 The Sub-TLVs of Usage CA

Definition Tag Format Description

Indicator of 01 a1 Valid values:
Compromised C- Confirmed compromised account
Account S- Suspected compromised account
Time Bucket of 02 n16 Indicating the time bucket of the compromised account (start date and
Compromise end date)
Format: YYYYMMDDYYYYMMDD
Type of the 03 a18 The first 8 characters indicate whether or not the 8 types of
Compromised compromised information have been compromised respectively, “Y”
Information indicates yes, and “N” indicates No:
The 1st byte: PAN;
The 2nd byte: Expiration date;
The 3rd byte: CVN2;
The 4th byte: PIN;
The 5th byte: Track data (Track 1 & Track 2);
The 6th byte: Cardholder name;
The 7th byte: Cardholder mobile phone number;
The 8th byte: Cardholder address information;
Note 1: The value of this tag should be combined with tag 01 (Indicator
of Compromised Account). If tag 01 = “C”, then “Y” indicates confirmed
compromised information, and “N” indicates no compromised
information; if tag 01 = “S”, then “Y” indicates suspected compromised
information, and ‘N’ indicates no compromised information;
Note 2: The last 10 characters are reserved for future use, and filled with
“N”.
Example: If tag 01 = “S” and tag03 = “YNNNNNNNNNNNNNNNNN”, the

UPI CONFIDENTIAL 183

 Part II: Online Message

Definition Tag Format Description

PAN is suspected to be compromised, and no other information is
compromised.
Serial Number of 04 ans12 Format: “C”+ YYYYMMDD + serial number (3 characters).
Risk Event on
For example: C20160301001
Compromised
Account

3.63.3.3 Usage
In the online message of cash withdrawal, purchase, pre-authorization, pre-authorization completion, recurring,
MOTO, primary credit, remittance, and authorization transactions, the transmission requirement is defined as below:
The Acquirer: No impact.
UPI system will choose to provide security and risk assessment information through Usage CA of Field 125, based on
the Issuer’s business needs;
Based on the Issuer’s business needs, the Issuer can choose to subscribe to this service or not.

Usage CV: Consumer Verification Information

3.63.4.1 Attribute
ans8, 2-byte Usage ID + 3-byte Length + 3-byte sub-TLV
3.63.4.2 Description
The value of the usage is CV + 3 bytes of total length of Usage CV + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition of this field is the same as that of Field 55. Please refer to Field 55 for details.
Table 147 The Sub-TLVs of Usage CV

Definition Tag Format Description

CDCVM 01 an1 Valid value:
indicator 1- The CDCVM has been performed successfully.
When the CDCVM fails or is not performed, the usage CV will not be
present.

3.63.4.3 Usage
Currently, the CDCVM indicator will only be present in the mobile contactless payment transactions. When Byte 2 Bit
3 of CVR in Tag 9F10 = 1, the UPI system will set the CDCVM Indicator to 1. In the future, the CDCVM may also be
used in mobile e-commerce transactions, etc.
 The Transmission Requirements of Usage CV in Request Messages:
Table 148 Transmission Requirements of Usage CV in Original Request Transactions

Definition Tag Format Transmission Requirements Description

AC SW IS SW
CDCVM 01 an1 C6+ Presented only when the CDCVM has
indicator been performed successfully.

UPI CONFIDENTIAL 184

 Part II: Online Message

Definition Tag Format Transmission Requirements Description

AC SW IS SW
Note: Currently, the CDCVM indicator will only be presented in purchase, pre-authorization and authorization
transactions. In subsequent transactions such as purchase cancellation, authorization cancellation,
preauthorization completion, etc., the CDCVM indicator will not be presented.
 The Transmission Requirements of Usage CV in Advice Messages
The CDCVM indicator will not be presented in any advice messages.

Usage QR: QRC-based Payment

3.63.5.1 Attribute
ansb..120, 2-byte Usage ID + 3-byte length + maximum 115 bytes sub-TLVs
3.63.5.2 Description
The value of the usage is QR + 3 bytes of total length of Usage QR + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be present in any sequence. TLV
format definition of this field is the same as that of Field 55.
Table 149 The Sub-TLVs of Usage QR

Definition Tag Format Description

QRC Use Case Indicator 01 ans3 Valid values:
100- Consumer-presented QRC, purchase transaction
210- Merchant-presented QRC, purchase transaction
211- Merchant-presented QRC, purchase transaction, debit card
only (Example: purchasing financial products)
220- Merchant-presented QRC, ATM cash withdrawal
212- Merchant-presented QRC, purchase transaction in small
businesses
231- P2P QRC-based Payment, primary credit transaction
232- P2P QRC-based Payment, account funding transaction,
Reserved
QRC Voucher Number 02 ans..20 Generated by UnionPay system. The payment index is unique
permanently. It is used to locate a transaction.
C2B Payment Code 03 ans..34 The information contained in the Consumer-presented QRC.
Wallet ID 1 04 ans..11 Assigned by UPI. It indicates the Wallet ID of the payer.
Wallet ID 2 05 ans..11 Assigned by UPI. It indicates the Wallet ID of the payee.
Point of Initiation Method 07 n2 Reserved for future use on non-UnionPay standard QRC-based
payment product.
Order Number 09 an8..40 Reserved for future use on non-UnionPay standard QRC-based
payment product.
Order Time 0A n14 Reserved for future use on non-UnionPay standard QRC-based
payment product.
Tip or Convenience 0B n2 Reserved for future use on non-UnionPay standard QRC-based
Indicator payment product.

UPI CONFIDENTIAL 185

 Part II: Online Message

Definition Tag Format Description

Value of Convenience Fee 0C n..13 Reserved for future use on non-UnionPay standard QRC-based
Fixed payment product.
Value of Convenience Fee 0D n.5 Reserved for future use on non-UnionPay standard QRC-based
Percentage payment product.

3.63.5.3 Usage
3.63.5.3.1 The Transmission Requirements of Usage QR in Original Request Messages
For QRC transactions, the original request messages include those of purchase, authorization, etc.
 For Merchant-presented QRC-based Payment:
Table 150 Transmission Requirements of Usage QR in Merchant-presented QRC-based Payment Original Request Transactions

Definition Tag Format Transmission Requirements

UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
QRC Use Case 01 ans3 C  C C 
Indicator
QRC Voucher 02 ans..20 C  C C 
Number
C2B Payment Code 03 ans..34 C  C C 
Wallet ID 1 04 ans..11 C  C C 
Wallet ID 2 05 ans..11 C  C C 
Note: In subsequent transactions such as purchase cancellation and authorization cancellation, values of the
subfield tags may be different from those in the original transaction. The Issuer must not check the
consistency. Some subfield tags may not be present in the message when they do not exist. The Member shall
ignore their absence and continue to process this transaction.
In the original request message for Merchant-presented QRC-based Payment:
 QRC Use Case Indicator (tag 01) and QRC Voucher Number (tag 02) shall be submitted by UMPS and forwarded
by the Acquirer to GSCS, and the two tags shall be sent by GSCS to the Issuer if the Issuer supports Field 125
Usage QR.
 C2B Payment Code (tag 03), Wallet ID 1 (tag 04), and Wallet ID 2 (tag 05) shall be submitted by UMPS and
forwarded by the Acquirer to GSCS if the specific tags exist, and the three tags shall be sent by GSCS to the
Issuer if the Issuer supports Field 125 Usage QR and the corresponding tags exist.
In the original response message for Merchant-presented QRC-based Payment:
 QRC Use Case Indicator (tag 01) and QRC Voucher Number (tag 02) shall be submitted by GSCS to the Acquirer,
and forwarded by the Acquirer to UMPS.
 C2B Payment Code (tag 03), Wallet ID 1 (tag 04), and Wallet ID 2 (tag 05) shall be submitted by GSCS to the
Acquirer, and forwarded by the Acquirer to UMPS if the corresponding tag exists.
 For Consumer-presented QRC-based Payment:
Table 151 Transmission Requirements of Usage QR in Consumer-presented QRC-based Payment Original Request Transactions

UPI CONFIDENTIAL 186

 Part II: Online Message

Definition Tag Format Transmission Requirements

AC SW IS SW
QRC Use Case Indicator 01 ans3 C C
QRC Voucher Number 02 ans..20 C C
C2B Payment Code 03 ans..34 C C
Wallet ID 1 04 ans..11 C C
Wallet ID 2 05 ans..11 C C
Note: In subsequent transactions such as purchase cancellation and authorization cancellation, the values of
the subfield tags may be different from those in the original transaction. The Issuer must not check the
consistency. Some subfield tags may not be present in the message when they do not exist. The Member shall
ignore their absence and continue to process this transaction.
In the original request message for Consumer-presented QRC-based Payment:
 QRC Use Case Indicator (tag 01) and QRC Voucher Number (tag 02) shall be sent by GSCS to the Issuer if the
Issuer supports Field 125 Usage QR.
 C2B Payment Code (tag 03), Wallet ID 1 (tag 04), and Wallet ID 2 (tag 05) shall be sent by GSCS to the Issuer if
the Issuer supports Field 125 Usage QR and the corresponding tags exist.
In the original response message for Consumer-presented QRC-based Payment:
 QRC Use Case Indicator (tag 01) and QRC Voucher Number (tag 02) shall be submitted by GSCS to the Acquirer.
 C2B Payment Code (tag 03), Wallet ID1 (tag 04), and Wallet ID2 (tag 05) shall be submitted by GSCS to the
Acquirer if the corresponding tag exists.
3.63.5.3.2 The Transmission Requirements of Usage QR in Subsequent Request Messages
The subsequent request messages for QRC-based Payment include those of purchase cancellation, authorization
cancellation, etc.
Table 152 Transmission Requirements of Usage QR in QRC-based Payment Subsequent Request Transactions

Definition Tag Format Transmission Requirements

AC SW IS SW
QRC Use Case Indicator 01 ans3 C C
QRC Voucher Number 02 ans..20 C C C
C2B Payment Code 03 ans..34 C C
Wallet ID 1 04 ans..11 C C
Wallet ID 2 05 ans..11 C C
Note: In subsequent transactions such as purchase cancellation and authorization cancellation, values of the
subfield tags may be different from those in the original transaction. The Issuer must not check the
consistency.
For the subsequent request message sent from the Acquirer to GSCS, QRC Voucher Number (tag 02) shall be present
if it is obtained from the Merchant in QRC-based purchase cancellation, etc.
For the subsequent request message sent from GSCS to the Issuer, tag 01 and tag 02 in Usage QR shall be present if
the Issuer supports Usage QR; tag 03, tag 04, and tag 05 in Usage QR shall be present if the Issuer supports Usage

UPI CONFIDENTIAL 187

 Part II: Online Message

QR and if the corresponding tags exist.

For the subsequent response message sent from GSCS to the Acquirer, tag 01 and tag 02 in Usage QR shall be present
in QRC-based Payment; tag 03, tag 04, and tag 05 in Usage QR shall be present if the corresponding tags exist.
3.63.5.3.3 The Transmission Requirements of Usage QR in Advice Messages
The advice messages include those of reversal, refund, etc.
Table 153 Transmission Requirements of Usage QR in QRC-based Payment Advice (ACSW)

Definition Tag Format Transmission Requirements

AC SW
QRC Voucher Number 02 ans..20 C
The Acquirer shall submit QRC Voucher Number (tag 02) in a QRC-based refund transaction. It is optional for the
Acquirer to submit it in the reversal transaction.
Table 154 Transmission Requirements of Usage QR in QRC-based Payment Advice (SWIS)

Definition Tag Format Transmission Requirements

SW IS
QRC Use Case Indicator 01 ans3 C6+
QRC Voucher Number 02 ans..20 C6+
C2B Payment Code 03 ans..34 C6+
Wallet ID 1 04 ans..11 C6+
Wallet ID 2 05 ans..11 C6+
Note: In subsequent transactions such as reversal and refund, values of the subfield tags may not be the same
as those in the original transaction.
QRC Use Case Indicator (tag 01) and QRC Voucher Number (tag 02) shall be filled by GSCS when the Issuer enables
Field 125 Usage QR for a QRC-based Payment.
C2B Payment Code (tag 03), Wallet ID1 (tag 04) and Wallet ID2 (tag 05) shall be filled by GSCS when the tag exists,
and the Issuer enables Field 125 Usage QR for a QRC-based Payment.
3.63.5.3.4 The Transmission Requirements of Usage QR in Merchant-presented QRC-based Payment Transaction
Result Inquiry Message
Table 155 Transmission Requirements of Usage QR in Merchant-presented QRC-based Payment Transaction Result Inquiry
Message

Definition Tag Format Transmission Requirements

UMPS AC
AC UMPS
QRC Voucher Number 02 ans..20 M M

Usage IP: Innovative Payment

3.63.6.1 Attribute
ansb..138, 2-byte Usage ID + 3-byte length + maximum 133 bytes sub-TLVs

UPI CONFIDENTIAL 188

 Part II: Online Message

3.63.6.2 Description
The value of the usage is IP + 3 bytes of total length of Usage IP + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be present in any sequence. TLV
format definition of this field is the same as that of Field 55.
Table 156 The Sub-TLVs of Usage IP

Definition Tag Format Description

Innovative 01 ans3 Valid values:
payment 001- Reserved
scenario 002- Reserved
indicator 003- License plate payment
004- NFC tag payment
005- Transportation transaction (including: APP innovative payment, Transit
QR Code)
006- Online QRC-based transaction
007- In-APP transaction
008- APP innovative payment, O2O
009- APP innovative payment, Online
010- Reserved for Mainland Chinese transactions
011- Reserved for Mainland Chinese transactions
012- Reserved for non-UnionPay standard QRC-based payment product
Note: This tag is a defining indicator for UnionPay innovative payment
transactions.
Specifically, for APP-innovative-payment and in-app transactions, the
sample table below illustrates the combination of key fields that features
certain scenarios/products.
F22 F60.2.8 Usage QR, F125 Usage IP, F125 Identified
(ECI) (If subscribed) (If subscribed) as
012 10 N/A APP
See 3.63.5 for innovative
valid values Tag01=005 payment,
942 N/A Transit QR
(merchant-
presented) Code

011/012 09 N/A
051/052 00 N/A
In-APP
See 3.63.5 for Tag01=007
Transaction
valid values
941/942 10
(merchant-
presented)
See 3.63.5 for APP
valid values innovative
942 N/A Tag01=008
(merchant- payment,
presented) O2O

942 N/A See 3.63.5 for Tag01=009 APP

valid values innovative

UPI CONFIDENTIAL 189

 Part II: Online Message

Definition Tag Format Description

(merchant- payment,
presented) Online

Reserved 02 ans..11 Reserved

Reserved 03 ans..11 Reserved
Innovative 04 ans..100 This tag will not be present by default.
payment
If tag 01 = “008” or “009”, this tag will be present and filled with a 1-byte
additional
digit (Data source: channel app of the APP Innovative Payment):
information
1- Front-end payment
2- Back-end payment

3.63.6.3 Usage
This usage can be present in purchase, pre-authorization, pre-authorization completion (advise & request), MO/TO,
authorization, and the subsequent cancellation, reversal and refund transactions.
UPI system will choose to provide innovative payment information through Usage IP of Field 125, based on the
Issuer’s subscription configuration.
Issuers who participate in any of UPI innovative payment businesses shall evaluate the necessity of subscribing to
Usage IP based on applicable implementation guides for innovative payment product schemes.
 The Transmission Requirements of Usage IP in Request Messages:
Table 157 Transmission Requirements of Usage IP in Request Messages

Definition Tag Format Transmission Requirements

AC SW IS SW
Innovative payment scenario indicator 01 ans3 C C
Innovative payment additional information 04 ans..100 C
 The Transmission Requirements of Usage IP in Advice Messages:
Table 158 Transmission Requirements of Usage IP in Advice Messages (ACSW)

Definition Tag Format Transmission Requirements

AC SW
Innovative payment scenario indicator 01 ans3 C

Table 159 Transmission Requirements of Usage IP in Advice Messages (SWIS)

Definition Tag Format Transmission Requirements

SW IS
Innovative payment scenario indicator 01 ans3 C
Innovative payment additional information 04 ans..100 C

Usage LR: Low Risk Identifier

UPI CONFIDENTIAL 190

 Part II: Online Message

3.63.7.1 Attribute
ans..23, 2-byte Usage ID + 3-byte Length + maximum 18 bytes sub-TLVs
3.63.7.2 Description
The value of the usage is LR + 3 bytes of total length of Usage LR + subTLV1+subTLV2+....+subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition is the same as Field 55. Please refer to Field 55 for details.
Table 160 The Sub-TLVs of Usage LR

Definition Tag Format Description

Low value exemption 01 n1 Valid values:
indicator 0- Not applicable
1- Transaction exempt from SCA as the merchant/acquirer
has determined it to be a low value payment
TRA exemption indicator 02 n1 Valid values:
0- Not applicable
1- Transaction exempt from SCA as the merchant/acquirer
has determined it to be low risk in accordance with the
criteria defined by PSD2/RTS
Trusted/Whitelisted 03 n1 Valid values:
merchant exemption 0- Not applicable
indicator 1- Transaction exempt from SCA as it originated at a
merchant trusted by the cardholder
Secure corporate payment 04 n1 Valid values:
exemption indicator 0- Not applicable
1- Transaction exempt from SCA as the merchant/acquirer
has determined it as a secure corporate payment
Delegated authentication 05 n1 Valid values:
exemption indicator 0- Not applicable
1- Transaction exempt from SCA as the merchant/acquirer
has determined it as a delegated authenticated transaction
Merchant initiated 06 n1 Valid values:
transaction indicator 0- Not applicable
1- Transaction exempt from SCA as the merchant/acquirer
has determined it as a merchant initiated transaction

3.63.7.3 Usage
Currently, this usage can be present in purchase, pre-authorization, MOTO, authorization and recurring transactions. In
subsequent transactions such as purchase cancellation, authorization cancellation, pre-authorization completion etc., this usage
will not be present.
Based on the Issuer’s business needs, the Issuer can choose to subscribe to this service or not.

 The Transmission Requirements of Usage LR in Request Messages:

Table 161 Transmission Requirements of Usage LR in Request Messages

UPI CONFIDENTIAL 191

 Part II: Online Message

Usage Usage Definition Format Transmission Requirements

AC SW IS SW
LR Low risk identifier ans..23 C C
 The Transmission Requirements of Usage LR in Advice Messages:
This usage will not be presented in any advice message.

Usage TF: Authentication Transaction Identifier

3.63.8.1 Attribute
ans43, 2-byte Usage ID + 3-byte Length + 38-byte sub-TLV
3.63.8.2 Description
This usage is submitted by Acquirer to relate an authentication DS transaction ID in UP3DS. DS transaction ID is the
universally unique transaction identifier assigned by the Directory Server to identify a single transaction. For the
detailed definition and description of DS Transaction ID, please refer to the EMV® 3-D Secure – Protocol and Core
Functions Specification.
The value of the usage is TF + 3 bytes of total length of Usage TF + subTLV1 + subTLV2 + .... + subTLVn. According to
different use cases, the usage may contain different subfield tags. Subfield tags can be presented in any sequence.
TLV format definition is the same as Field 55. Please refer to Field 55 for details.
Table 162 The Sub-TLVs of Usage TF

Definition Tag Format Description

DS 01 ans36 The value is used to relate the UP3DS authentication transaction with
transaction authorization message (such as purchase, pre-authorization, recurring,
ID authorization).
This usage is submitted by Acquirer to GSCS, which will be forwarded to
Issuer.

3.63.8.3 Usage
Currently, the DS Transaction ID will only be presented in 3-D Secure card-not-present purchase, pre-authorization,
recurring and authorization transactions and will not be present in the subsequent purchase cancellation,
authorization cancellation, pre-authorization completion transactions, etc.
 The Transmission Requirements of Usage TF in Request Messages:
Table 163 Transmission Requirements of Usage TF in Request Transactions

Definition Tag Format Transmission Description

Requirements
AC SW IS SW
DS 01 ans36 C  Presented only when the transaction is UP3DS
transaction authentication related (Applied when the value of
ID Field 60.2.8 in the Acquirer request equals to “05”,
“06”, or “07”).
 The Transmission Requirements of Usage TF in Advice Messages:
The DS Transaction ID will not be presented in any advice message.

UPI CONFIDENTIAL 192

 Part II: Online Message

Usage QP: UnionPay Application Indicator (Reserved)

UPI CONFIDENTIAL 193

 Part II: Online Message

Reject Code
11253= Invalid characters in length field
11254= Length value exceeds 100
11255= Invalid characters

3.64 Field 128 Message Authentication Code

Attribute
64-bit binary number

Description
Authentication code (MAC) used to authenticate the accurate message source

Usage
The message authentication code is the MAC data calculated with MAK and some sensitive field data following the
calculation method designated in the key management message (Field 53).
Before the transaction message is sent out by the sender, MAC should be generated by the sender. After the receiver
receives the message, it will re-calculate the MAC value to authenticate whether the message is changed during the
transmission process.
Generating and authenticating the MAC is completed by the HSM. For the detailed calculation method and usage of
the field, please refer to the Technical Specifications on Bankcard Interoperability - Part IV Data Secure Transmission
Control.

Reject Code
N/A

UPI CONFIDENTIAL 194

 Part II: Online Message

4 Explanations on Message Format

4.1 Explanation Overview
Symbol Definition
Table 164 Symbol Definition

Classification Symbol Definition

The abbreviations of AC Acquirer
sender
SW GSCS
IS Issuer
SD Message Sender
RC Message Receiver
TS Transaction Initiator
TR Transaction Receiver
OB Transfer Transaction Acceptor
CB Transfer-in Party or Transfer-out Party
The abbreviations of M Mandatory. Field that must be filled in
field transmission
C Conditional. Field that must be filled in certain condition
requirement
C+ Conditional. Field to be added in certain condition
C- Conditional. Field to be deleted in certain condition
M+ Mandatory. Field that must be added
O Optional. Field filled optionally by the Acquirer and the Issuer
 Field forwarded
Field whose value must remain the same as the value in the corresponding
field of the previous message
00 Field whose user- defined data element must be filled with 0
Field that must be deleted

Explanation on Message Format

4.1.2.1 Explanation on the Format of Request Message
Table 165 Explanation on the Format of Request Message

XXX message
Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
32 Acq_inst_id_code an..11(LLVAR) M  M 

UPI CONFIDENTIAL 195

 Part II: Online Message

XXX message
Field Data Element Data Type Transmission Requirement
AC SW IS SW
33 Fwd_inst_id_code an..11(LLVAR) M  M 
35 Track_2_data z..37(LLVAR) M 
37 Retrivl_ref_num an12 M  M 
38 Authorization Identification Response an6 M 
39 Resp_code an2 M 
41 Card_accptr_termnl_id ans8 O  C0 
43 Card_accptr_name_loc ans40 M 
44 Addtnl_resp_code ans..25(LLVAR) C 
Note 1: Field32: Acq_inst_id_code, this field must be filled by the Acquirer, and forwarded by UnionPay, and
the Issuer must return it unchanged in the response message.
Note 2: Field 33: Fwd_inst_id_code, this field is kept unchanged during the transaction and indicates the
sender of the message.
Note 3: Field 35: Track_2_data, this field only appears in the request message.
Note 4: Field 41: The Acquirer decides whether to fill in this field. Once this field appears in the original
message, it should appear in the subsequent messages.

4.1.2.2 Explanation on Format of Advice Message

Advice transaction is direct response transaction, so message format is described in two parts: one part describes
the change in message field ACSW, and the other part describes the change in message field SWIS. The way
to indicate change in each message field remains the same as that used for request message, but it should be
noted that: the first columns of the two parts of advice format (the AC column that is sent out by the Acquirer and
the SW column that is sent out by UnionPay) both indicate the relationship with the original transaction.
Table 166 Explanation on the Format of Advice Message (Sent Out by the Acquirer)

xxx advice(sent out by the Acquirer)

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0420 0430
32 Acq_inst_id_code an..11(LLVAR) M M
33 Fwd_inst_id_code an..11(LLVAR) M M
35 Track_2_data z..37(LLVAR) C1
36 Track_3_data z..104(LLLVAR) C2
37 Retrivl_ref_num an12 M M
38 Authr_id_resp an6 C4

UPI CONFIDENTIAL 196

 Part II: Online Message

xxx advice(sent out by the Acquirer)

Field Data Element Data Type Transmission Requirement
AC SW
39 Resp_code an2 M
41 Card_accptr_termnl_id ans8 M M
42 Card_accptr_id ans15 M M

Table 167 Explanation on the Format of Advice Message (Sent Out by GSCS)

xxx advice(sent out by GSCS)

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0420 0430
32 Acq_inst_id_code an..11(LLVAR) M M
33 Fwd_inst_id_code an..11(LLVAR) M M
35 Track_2_data z..37(LLVAR) C1
36 Track_3_data z..104(LLLVAR) C2
37 Retrivl_ref_num an12 M M
38 Authr_id_resp an6 C4
39 Resp_code an2 M
41 Card_accptr_termnl_id ans8 M M
42 Card_accptr_id ans15 M M

Explanation on Conditional Data Element in Message Field

If the message field meets one of the following conditions, then this field shall be present; otherwise, whether or
not the field shall be present will be determined by the sender and the receiver of the transaction.
Table 168 Explanation on Conditional Data Element in Message Field

Abbr. of Explanation
Condition
C Conditional. This Field is present in the message under certain conditions, which are explained in
Chapter 4 Message Field Descriptions.
C0 This field shall be present if the last node has sent this field. And the value of this field shall
remain the same as that at the last node.
C0+ If the original request message from the sender contains this field, this field shall be added to the
response message.
C0- If this field is sent by the last node, it shall be deleted, and not be passed to the next node.
C1 This field shall be present if the card is present and there is Track 2 data on the card. This field
shall be present in chip card transaction. If the card is a chip card, and the equivalent Track 2 data

UPI CONFIDENTIAL 197

 Part II: Online Message

Abbr. of Explanation
Condition
(tag57) exists in the card information, then fill the value of tag 57.
C2 This field shall be present if the card is present and there is track 3 data on the card.
C3 This field shall be present if Field 39 (Response Code) indicates that the transaction request is
authorized.
C4 This field shall be present if it is present in the last related transaction.
C5 This field shall be present if the receiver requests GSCS to provide it.
C6 This field shall be present if there is a business requirement.
C7 This field shall be present if it is requested by the terminal and the last bit of Field 22 is 1.
C8 This field shall be present if Field 52 (PIN_DATA) is present.
C9 This field shall be processed according to the related bankcard security specifications (e.g., Part IV
Data Secure Transmission Control of Technical Specifications on Bankcard Interoperability).
C10 This field shall be present if the transaction is related to a card account.
C11 This field shall be present when it appears in the message sent to UnionPay by other switch
centers.
C12 This field shall be present if the balance of the card is not sufficient and the Issuer partially
authorizes the transaction.
C13 Reserved
C14 This field shall be present when transaction currency (Field 49) is different from settlement
currency (Field 50).
C15 This field shall be present when transaction currency (Field 49) is different from Cardholder billing
currency (Field 51).
C16 This field shall be present when the last node sends it. And the current node may change the
value of the field according to the business requirement. When last node does not send it, a new
value may be assigned to this field based on the business requirement and/or subscribed services.
C17 This field will be absent if the original transaction is not found; this field shall be present if the
original transaction is found and contains this field.
C19 This field shall be present if the length of key is double length or triple length (16 byte or 24 byte)
or even longer.
C20 This field shall only be present when UnionPay card is acquired outside of Mainland China.
C21 This field shall be present when the Issuer applies the Technical Specifications on Bankcard
Interoperability V2.1.
C22 (1) This field shall be present in the request message sent by the Acquirer if the transaction is an
installment payment purchase transaction or installment payment authorization transaction or
installment payment refund transaction. It shall not be present in installment payment purchase
reversal, installment payment purchase cancellation, installment payment purchase cancellation
reversal, installation payment authorization reversal, installation payment authorization
cancelation, and installation payment authorization cancelation reversal messages sent by the
Acquirer. In the Issuer’s response message, this field shall be present when the installment

UPI CONFIDENTIAL 198

 Part II: Online Message

Abbr. of Explanation
Condition
payment transaction is accepted by the Issuer.
(2) This field shall be present in the request message, pre-authorization completion (advice)
message and refund (online) message sent by the Acquirer, if the transaction is RMB settlement
transaction. It shall not be present in the reversal message sent by the Acquirer. This field is
optional for the Acquirer in cancellation message.
C24 When the Acquirer (sender) remits fund from account or bankcard instead of cash, this field shall
be present to be filled with the account or bankcard number; otherwise, this field does not need
to be present.
C50 This field exists if the interface equipment sequence number cannot be implicitly ascertained by
the terminal identifier.
C51 This field must be present if the terminal can obtain card serial number.
C53 This field shall be present if the transaction is initiated by the terminal; the transaction is
authorized by the Issuer but rejected by the card.
C54 This field shall be present if the Issuer requests GSCS to verify ARQC.
C55 This field shall be present when the Issuer script exists in the response message of the original
transaction.
C56 This field shall be absent with off-line PIN entry and present with online PIN entry.
C59 This field must appear when the terminal is able to capture the card product identification
information. Otherwise, it will not appear.
C60 This field shall be present when required by CUPSecure.
C61 The field shall be present in the reversal message sent by the terminal when the original
transaction is approved by the Issuer but declined by the card.
C70 This field shall be present when Field 22 (Point of Service Entry Mode Code) indicates magnetic
stripe card and only track 1 data exists.
C71 The field shall be present when it is a fixed amount authorization.

Abbreviation of Field Name

Table 169 Abbr. of Field Name

Field Serial Number Field Name Abbreviation of Field Name

2 Primary Account Number (Pan) primary_acct_num
3 Processing Code processing_code
4 Amount, Transaction amt_trans
5 Amount, Settlement amt_settlmt
6 Amount, Cardholder Billing amt_cdhldr_bil
7 Transmission Date/Time transmsn_date_time
9 Conversion Rate, Settlement conv_rate_settlmt

UPI CONFIDENTIAL 199

 Part II: Online Message

Field Serial Number Field Name Abbreviation of Field Name

10 Conversion Rate, Cardholder Billing conv_rate_cdhldr_bil
11 System Trace Audit Number sys_trace_audit_num
12 Time, Local Transaction time_local_trans
13 Date, Local Transaction date_local_trans
14 Date, Expiration date_expr
15 Date, Settlement date_settlmt
16 Date, Conversion date_conv
18 Merchant’s Type mchnt_type
19 Merchant Country Code mchnt_cntry_code
22 Point of Service Entry Mode Code pos_entry_mode_code
23 Card Sequence Number card_seq_id
25 Point of Service Condition Code pos_cond_code
26 Point of Service Pin Capture Code pos_pin_captr_code
28 Amount, Transaction Fee amt_trans_fee
32 Acquiring Institution Identification Code acq_inst_id_code
33 Forwarding Institution Identification Code fwd_inst_id_code
35 Track 2 Data track_2_data
36 Track 3 Data track_3_data
37 Retrieval Reference Number retrivl_ref_num
38 Authorization Identification Response authr_id_resp
39 Response Code resp_code
41 Card Acceptor Terminal Identification card_accptr_termnl_id
42 Card Acceptor Identification Code card_accptr_id
43 Card Acceptor Name/Location card_accptr_name_loc
44 Additional Response Data addtnl_resp_code
45 Track 1 Data track_1_data
48 Additional Data Private addtnl_data_private
49 Currency Code, Transaction currcy_code_trans
50 Currency Code, Settlement currcy_code_settlmt
51 Currency Code, Cardholder Billing currcy_code_cdhldr_bil
52 Pin Data pin_data
53 Security Related Control Information sec_relatd_ctrl_info
54 Additional Amounts addtnl_amt

UPI CONFIDENTIAL 200

 Part II: Online Message

Field Serial Number Field Name Abbreviation of Field Name

55 Integrated Circuit Card System Related Data ICC_data
Application Cryptogram app_crypto
Cryptogram Information Data crypto_info_data
Issuer Application Data issr_app_data
Unpredictable Number unpredic_num
Application Transaction Counter app_trans_count
Terminal Verification Results termnl_veri_resl
Transaction Date trans_date
Transaction Type trans_type
Transaction Amount or Amount Authorized trans_amt
Transaction Currency Code trans_currcy_code
Application Interchange Profile app_interch_profl
Terminal Country Code termnl_cntry_code
Amount Other amt_other
Terminal Capabilities termnl_capbs
Cardholder Verification Method Results card_ver_resl
Terminal Type termnl_type
Interface Device Serial Number ifd_serial_num
Dedicated File Name DF_name
Terminal Application Version Number term_app_ver_num
Transaction Sequence Counter trans_seq_count
Issuer Authentication Data iss_auth_data
Issuer Script 1 issr_scrpt1
Issuer Script 2 issr_scrpt2
Issuer Script Results issr_scrpt_ resl
ECI Issuer Authorization Code ECIAC
Card Product Identification card_pro_id
56 Token Payment Account Reference (PAR) par
57 Issuer Additional Data - Private issr_addtnl_data
59 Detail Inquiring detail_inqrng
60 Reserved reserved
60.1 Message Reason Code msg_rsn_code
60.2 Additional Point of Service Information addtnl_pos_info

UPI CONFIDENTIAL 201

 Part II: Online Message

Field Serial Number Field Name Abbreviation of Field Name

61 Cardholder Authentication Information ch_auth_info
62 Switching Data switching_data
63 Financial Network Data finacl_net_data
70 Network Management Information Code netwk_mgmt_info_code
90 Original Data Elements orig_data_elemts
96 Message Security Code msg_security_code
100 Receiving Institution Identification Code rcvg_inst_id_code
102 Account Identification 1 acct_id1
104 Transaction and Industry Application Information trans_industry_app_inf
113 Additional Information addtnl_info
117 National and Regional Information natl_region_info,
121 National Switching Reserved national_sw_resved
122 Acquiring Institution Reserved acq_inst_resvd
123 Issuer Institution Reserved issr_inst_resvd
125 Security and Risk Assessment Information risk_asse_info
128 Message Authentication Code msg_authn_code

Basic Requirements on Message Fields of Transaction

The transaction type is identified by message type, transaction processing code (Field3), Merchant’s type (Field18),
point of service condition code (Field25) and transaction initiation channel (60.2.5). Each type of transaction has a
particular requirement for the value of these message fields. Please refer to Appendix B Table of Transaction Type
Identification of the Technical Specifications on Bankcard Interoperability - Part VI Annex for details.

4.2 Message Definition for Clearing and Settlement, and Day-end Batch Processing
Clearing and Settlement and Day-end Batch Processing include batch file processing, transaction data clearing, funds
settlement and funds transfer.
 End-of-day cutoff

End-of-day Cutoff
Cutoff message is used by GSCS to notify Members of the change of settlement date.
Table 170 Message Definition of Cutoff Message Initiated by GSCS

Cutoff message initiated by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW RC
Message Type Identifier n4 0820 0830
bitmap b128 M M

UPI CONFIDENTIAL 202

 Part II: Online Message

Cutoff message initiated by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW RC
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
15 date_settlmt n4(MMDD) M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M
100 rcvg_inst_id_code n..11(LLVAR) M M
Note 1:
Valid values of Field 70 Network Management Information Code:
201- indicates GSCS End-of-Day Cutoff starts.
202- indicates GSCS End-of-Day Cutoff Ends.
Note 2: The settlement date in the cut-off start and cut-off end message is the next settlement day. For
example, in case it is November 5th today, the settlement date in the message is November 6th.

4.3 Message Definition for Security Control Message

The following transaction messages are required for security management:
 Key reset request
 Key reset

Key Reset Request

A Member sends a key reset request advice message to GSCS, and GSCS will send an advice response message upon
receiving the advice message. At the same time, UnionPay system starts key updating module, creates a new key for
the Member, and sends the new key to the Member in the GSCS key reset request.
If UnionPay cannot send the key reset request advice response message or the key reset request message to the
Member, UnionPay will discard the message.
Table 171 Message Definition of Key Reset Request

Key reset request advice/response

Field Data Element Data Type Transmission Requirement
SD SW
Message Type Identifier n4 0820 0830
Bitmap b128 M M
7 Transmsn_date_time n10(MMDDhhmmss) M M
11 Sys_trace_audit_num n6 M M
33 Fwd_inst_id_code an..11(LLVAR) M M
39 Resp_code an2 M

UPI CONFIDENTIAL 203

 Part II: Online Message

Key reset request advice/response

Field Data Element Data Type Transmission Requirement
SD SW
53 Sec_relatd_ctrl_info n16 M M
70 Netwk_mgmt_info_code n3 M M

Key Reset
UnionPay sends the key reset request message to the Member, and the Member sends a request response message
to UnionPay upon receiving the request message. When malfunction occurs to the Member’s system and UnionPay
cannot receive the request response message, UnionPay system will resend the key reset request message. If the
sending times exceed the limit, the key reset will be processed manually.
Table 172 Message Definition of Key Reset

Key reset request/response

Field Data Element Data Type Transmission Requirement
SW RC
Message Type Identifier n4 0800 0810
Bitmap b128 M M
7 Transmsn_date_time n10(MMDDhhmmss) M M
11 Sys_trace_audit_num n6 M M
39 Resp_code an2 M
48 Addtnl_data_private ans..512(LLLVAR) C19
53 Sec_relatd_ctrl_info n16 M M
70 Netwk_mgmt_info_code n3 101 M
96 Msg_security_code b64 M
100 Rcvg_inst_id_code an..11(LLVAR) M M
128 Msg_authn_code b64 M C9

4.4 Message Definition for Management Message

Network Management Message
The management messages include sign on, sign off and echo test.
Network management transaction is the network management operational information between GSCS and
Members, that is:
 Setup and change of the network status of Members
 Echo test in the network application layer
 Members will send response after receiving network management transaction.
Network management transactions are divided in two categories: UnionPay-generated advice and Member-
generated advice.
UPI CONFIDENTIAL 204
 Part II: Online Message

Table 173 Message Definition of Network Management Message (Sent by UnionPay)

Network management (sent by UnionPay) advice/response

Field Data Element Data Type Transmission Requirement
SW RC
Message Type Identifier n4 0820 0830
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M
100 rcvg_inst_id_code an..11(LLVAR) M M

Table 174 Message Definition of Network Management Message (Sent by Member)

Network management (sent by Member) advice/response

Field Data Element Data Type Transmission Requirement
SD SW
Message Type Identifier n4 0820 0830
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
33 fwd_inst_id_code an..11(LLVAR) M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M

4.5 Message Definition for UnionPay Card International Transaction

Since currency conversion is required in international transactions, the usage of several special fields is specified as
follows:
Field 5 (settlement amount), Field 9 (settlement conversion rate), Field 16 (conversion date) and Field 50 (settlement
currency code) are related to settlement. If the transaction currency is different from the settlement currency, these
fields will appear in financial messages and stand-in authorization advice messages. Authorization and inquiry
transactions are not included in settlement, so the corresponding messages do not include these fields.
In the financial transactions involved in settlement, Field 5 (settlement amount), Field 9 (settlement conversion rate),
Field 16 (conversion date), and Field 50 (settlement currency code) are filled up by UnionPay.
Field 6 (Cardholder billing amount), Field 10 (conversion rate, Cardholder billing), and Field 51 (currency code,
Cardholder billing) specify the amount that should be held or debited from the Cardholder’s account. If the
transaction currency is different from the Cardholder billing currency, these fields will appear in authorization
transactions, financial transactions and their stand-in authorization advice messages.
In the financial transactions involved in settlement, Field 6 (Cardholder billing amount), Field 10 (conversion rate,

UPI CONFIDENTIAL 205

 Part II: Online Message

Cardholder billing), and Field 51 (currency code, cardholder billing) are filled up by GSCS.
Message Definition in Switching
4.5.1.1 Single Message
The following message types are single messages applicable to Members outside of Mainland China:
Balance inquiry, pre-authorization, MOTO pre-authorization, pre-authorization cancellation (online and manual),
MOTO pre-authorization cancellation (online and manual), pre-authorization completion (request), MOTO pre-
authorization completion (request), cash withdrawal, purchase, MOTO purchase, recurring, financial transaction
cancellation, reversal, pre-authorization completion (advice), settlement advice, refund (online)/MOTO refund
(online), exchange rate inquiry of UnionPay card, remittance (online), account verification, primary credit, primary
credit conformation, establishment of commission relationship, and revocation of commission relationship.
4.5.1.1.1 Balance Inquiry
This transaction is used to inquire about the book balance or available balance of the bankcard.
This transaction does not support reversal.
GSCS will decline this request if it cannot forward the balance inquiry request to the Issuer.
GSCS will discard this response if it cannot forward the response to the Acquirer.
The Acquirer will decline the transaction if it fails to receive the response from GSCS.
Table 175 Message Definition of Balance Inquiry

Balance inquiry request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 

UPI CONFIDENTIAL 206

 Part II: Online Message

Balance inquiry request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ans..512(LLLVAR) O 
49 currcy_code_trans an3 O  C0 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) C3 C16
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR)
usage CD ans..241 C C
117 natl_region_info ansb..256(LLLVAR)
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16

UPI CONFIDENTIAL 207

 Part II: Online Message

Balance inquiry request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.2 Pre-authorization
Pre-authorization is used by the Acquirer to obtain the transaction approval from the Issuer. The Acquirer will
estimate the purchase amount as the pre-authorization amount and send it to the Issuer. If the Issuer approves the
transaction, it will generate an authorization code and send the response to the Acquirer.
Pre-authorization only controls the available balance of the Cardholder account. The pre-authorization completion
transaction will be included in the fund settlement. An approved pre-authorization transaction is only valid in a
limited time frame.
This transaction is not included in the daily settlement and supports reversal advice.
Table 176 Message Definition of Pre-authorization

Pre-authorization request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 

UPI CONFIDENTIAL 208

 Part II: Online Message

Pre-authorization request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp a an6 C3 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) O 
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 209

 Part II: Online Message

Pre-authorization request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
usage AI ans..173 C C
usage CD ans..241 C C
usage BB ans..12 C C
usage WI ans..42 C C
usage RT ans49 C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage VA ansb..190 C
usage SD ansb..185 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage CV ans8 C
usage QR ansb..120 C C
usage IP ansb..138 C C
usage LR ansb..23 C C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9 C9 C9
Note a: In cross-border transactions, if it is a fixed amount authorization transaction, GSCS will convert it in to a
purchase transaction and switch to single message Issuers in Mainland China. In this case, Issuers in Mainland China
may not return authorization code (Field 38). Dual message Acquirers shall be able to identify and process it correctly,
if it does not subscribe to Field 38 padding.
4.5.1.1.3 MO/TO Pre-authorization
The format of this message is generally the same as the format of traditional pre-authorization transaction message
(refer to Section 4.5.1.1.2 Pre-authorization), with differences in the following fields:
 Field 25 is 18 (MO/TO transaction indicator)
For key element information, refer to B.1 single message finance, authorization request, and advice transactions in
Appendix B Transaction Types Differentiation Table.
For MO/TO pre-authorization transaction submitted in batch, the message format is the same as that of the ACSW

UPI CONFIDENTIAL 210

 Part II: Online Message

sequence of MO/TO pre-authorization transaction. It is differentiated by using value 4 for F60.3.5.

4.5.1.1.4 Incremental Pre-authorization
It’s mandatory for the Acquirer to fill Field 90 in Incremental Pre-authorization. The Field 2, 18, 32, 33, 42 and 49
shall be the same as the original pre-authorization in the request message.
Table 177 Message Definition of Incremental Pre-authorization

Incremental Pre-authorization request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp a an6 C3 
39 resp_code an2 M 

UPI CONFIDENTIAL 211

 Part II: Online Message

Incremental Pre-authorization request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) O 
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts an4 M 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C C
usage CD ans..241 C C
usage BB ans..12 C C
usage WI ans..42 C C
usage RT ans49 C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage VA ansb..190 C
usage SD ansb..185 C

UPI CONFIDENTIAL 212

 Part II: Online Message

Incremental Pre-authorization request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage CV ans8 C
usage QR ansb..120 C C
usage IP ansb..138 C C
usage LR ansb..23 C C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.5 Pre-authorization Cancellation (Online and Manual)

For a successful POS pre-authorization transaction, the pre-authorization cancellation transaction can be made
within 30 days after pre-authorization and prior to initiating pre-authorization completion to inform the Issuer to
cancel payment commitment.
The pre-authorization cancellation transaction should be a full-amount cancellation of the original pre-authorization.
This transaction is not included in settlement and supports reversal.
The Acquirer can initiate a manual cancellation of pre-authorization on the CDRS, and GSCS will send the message of
manual cancellation of pre-authorization to the Issuer, which is basically consistent with general pre-authorization
cancellation message, to inform the Issuer to cancel payment commitment.
Manual pre-authorization cancellation and pre-authorization cancellation have different values in Field 60.2.5
(transaction channel): manual pre-authorization cancellation uses the value 12 in Field 60.2.5, which means this
transaction is initiated from CDRS.
Note for Incremental Pre-authorization: To appropriately process pre-authorization cancellation, Acquirers shall
ensure that all fields are being populated correctly, including:
1) Field 4 must contain the accumulated transaction amount (sum of the first pre-authorization and all incremental
pre-authorizations).
2) Field 38 must contain the value from the first pre-authorization response message.
And the Issuer shall check whether the first pre-authorization of the cancellation is related to incremental pre-
authorizations, so as to determine the validity of Field 4.
Table 178 Message Definition of Pre-authorization Cancellation (Online and Manual)

UPI CONFIDENTIAL 213

 Part II: Online Message

Pre-authorization cancellation (online and manual) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 M  O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) O 
49 currcy_code_trans an3 M  M 

UPI CONFIDENTIAL 214

 Part II: Online Message

Pre-authorization cancellation (online and manual) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 O 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage BB ans..12 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage IP ansb..138 C C
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.6 MO/TO Pre-authorization Cancellation (Online and Manual)

The message format is the same as that of traditional pre-authorization cancellation transaction, refer to 7.5.1.1.4
Pre-authorization Cancellation (Online and Manual) with the differences in the following fields:
 The value of Field 25 is 18.
4.5.1.1.7 Pre-authorization Completion (Request)
For the approved pre-authorization transaction, the pre-authorization completion (request) is used to complete the
payment and settlement of the transaction.
This transaction is included in daily settlement and reconciliation and supports reversal advice.
Table 179 Message Definition of Pre-authorization Completion (Request)

UPI CONFIDENTIAL 215

 Part II: Online Message

Pre-authorization completion request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 M  O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 

UPI CONFIDENTIAL 216

 Part II: Online Message

Pre-authorization completion request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C C
usage CD ans..241 C C
usage BB ans..12 C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage VA ansb..190 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 217

 Part II: Online Message

Pre-authorization completion request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
usage CA ans..60 C
usage IP ansb..138 C C
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.8 MO/TO Pre-authorization Completion (Request)

For MO/TO pre-authorization completion transaction submitted in batch, the message format is the same as that of
the AC->SW sequence of MO/TO pre-authorization completion (request) transaction. It is differentiated by using
value 4 for F60.3.5.
The message format is generally the same as that of traditional pre-authorization completion (request), refer to
Section 4.5.1.1.7 Pre-authorization Completion (Request), only the value of Field 25 is 18 (MO/TO transaction
indicator).
4.5.1.1.9 Cash Withdrawal
Cash withdrawal transaction is used to request the Issuer to confirm the cash withdrawal activity and the amount.
The transaction channels can be ATM, POS, and bank counter.
This transaction is involved in settlement and reconciliation and supports reversal advice.
Table 180 Message Definition of Cash Withdrawal

Cash withdrawal request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 

UPI CONFIDENTIAL 218

 Part II: Online Message

Cash withdrawal request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
28 amt_trans_fee x+n8 C6+  O C
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 M 
53 sec_relatd_ctrl_info n16 M C16
54 addtnl_amt an..040(LLLVAR) O 
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C

UPI CONFIDENTIAL 219

 Part II: Online Message

Cash withdrawal request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.10 Purchase
The Cardholder asks for approval from the Issuer when purchasing goods or services. The purchase can be one-time
payment and installment payment (installment payment is differentiated from general Purchase by using value '64'
for Field 25).
This transaction is included in settlement and reconciliation and supports reversal advice.
Table 181 Message Definition of Purchase

Purchase request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 

UPI CONFIDENTIAL 220

 Part II: Online Message

Purchase request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+

UPI CONFIDENTIAL 221

 Part II: Online Message

Purchase request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) O 
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C C
usage CD ans..241 C C
usage BB ans..12 C C
usage WI ans..42 C C
usage RT ans49 C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage VA ansb..190 C
usage SD ansb..185 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
usage MI ansb..56 C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C

UPI CONFIDENTIAL 222

 Part II: Online Message

Purchase request/response
Field Data Element Data Type Transmission Requirement
AC SW IS SW
usage CV ans8 C
usage QR ansb..120 C C
usage IP ansb..138 C C
usage LR ansb..23 C C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.11 MO/TO Purchase

The message format is generally the same as traditional purchase transaction message format, refer to Section
4.5.1.1.10 Purchase, with differences in the following fields:
 The value of Field 25 is 08 (MO/TO transaction indicator)
For key element information, refer to single message transaction in Appendix B.1.
For MO/TO purchase transaction submitted in batch, the message format is the same as that of the ACSW
sequence of MO/TO purchase transaction. It is differentiated by using value 4 for F60.3.5.
4.5.1.1.12 Recurring
Recurring transaction is initiated by the Merchant on the Cardholder’s behalf under the circumstances that the
Cardholder is not present.
The Acquirer can initiate recurring transaction online or in batch. For the Issuer, it shall be processed online. In online
message, Field 60.2.5=20 and Field 60.3.5=4 indicate it is batch recurring transaction. Field 60.2.5 and Field 60.3.5
shall be filled according to real situation in online recurring transaction.
Online message format is:
Table 182 Message Definition of Recurring (Online)

Recurring (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 

UPI CONFIDENTIAL 223

 Part II: Online Message

Recurring (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  C0 
22 pos_entry_mode_code n3 M 
25 pos_cond_code n2 M  M 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
54 addtnl_amt an..040(LLLVAR) C25 
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 

UPI CONFIDENTIAL 224

 Part II: Online Message

Recurring (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C C
usage CD ans..241 C C
usage WI ans..42 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage LR ansb..23 C C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9 C9 C9
Message sent by the Acquirer in batch and switched to online transactions to the Issuer:
Table 183 Message Definition of Recurring (Batch)

Recurring (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0200 0210
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14+
6 amt_cdhldr_bil n12 C15+
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14+
10 conv_rate_cdhldr_bil n8 C15+

UPI CONFIDENTIAL 225

 Part II: Online Message

Recurring (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
14 date_expr n4(YYMM) O M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 C18 C0
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 O
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) O
48 addtnl_data_private ansb..512(LLLVAR) O
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14+
51 currcy_code_cdhldr_bil an3 C15+
54 addtnl_amt an..040(LLLVAR) C25
57 issr_addtnl_data ans..100(LLLVAR) C22
60 reserved ans..100(LLLVAR) Refer to Section 3.48.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C16 C16
100 rcvg_inst_id_code an..11(LLVAR) M+ M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 226

 Part II: Online Message

Recurring (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
usage ML ans47 C
usage PF an15 C
121 national_sw_resved ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) O
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage LR ansb..23 C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9

4.5.1.1.13 Financial Cancellation

Financial cancellation includes pre-authorization completion cancellation, MO/TO pre-authorization completion
cancellation, purchase cancellation, MO/TO purchase cancellation, and recurring cancellation.
Financial cancellation must be a full amount cancellation of the original financial transaction. Financial cancellation
transaction can initiate reversal advice, while it is not involved in settlement and reconciliation
Financial cancellation and its original transaction must be on the same settlement day. After the pre-authorization
completion cancellation, the original pre-authorization is still valid.
Table 184 Message Definition of Financial Cancellation

Financial cancellation request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 

UPI CONFIDENTIAL 227

 Part II: Online Message

Financial cancellation request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp a an6 C4  O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) C4+ O C4-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 M 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 

UPI CONFIDENTIAL 228

 Part II: Online Message

Financial cancellation request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage BB ans..12 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C C C
usage IP ansb..138 C C
128 msg_authn_code b64 C9 C9 C9 C9
Note a: Field 38 of the pre-authorization completion cancellation transaction message must be filled with the value
of Field 38 in the original pre-authorization transaction response.
4.5.1.1.14 Reversal
Reversal is applicable to the following transactions: cash withdrawal, pre-authorization (including MO/TO pre-
authorization), pre-authorization cancellation (including MO/TO pre-authorization cancellation), pre-authorization
completion (including MO/TO pre-authorization completion), pre-authorization completion cancellation (including
MO/TO pre-authorization completion cancellation), purchase (including MO/TO purchase and recurring), purchase
cancellation (including MO/TO purchase cancellation and recurring cancellation), establishment of commission
relationship, revocation of commission relationship, and account funding.
Field 104 Usage BB is not present in messages of account funding reversal.
Table 185 Message Definition of Reversal (Sent Out by the Acquirer)

Reversal by the Acquirer request/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0420 0430
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans a n12 M M
5 amt_settlmt n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4

UPI CONFIDENTIAL 229

 Part II: Online Message

Reversal by the Acquirer request/response

Field Data Element Data Type Transmission Requirement
AC SW
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 O C0
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
49 currcy_code_trans b an3 M M
50 currcy_code_settlmt an3 C4
55 ICC_data ansb..255(LLLVAR) C O
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage BB ans..12 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 230

 Part II: Online Message

Reversal by the Acquirer request/response

Field Data Element Data Type Transmission Requirement
AC SW
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0
122 acq_inst_resvd ans..100(LLLVAR) O C0
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C
128 msg_authn_code b64 C9 C9
Note a, b: For the messages of reversal transaction of Establish/Revoke Commission Relationship, Field 4 and Field
49 will not be present.
Table 186 Message Definition of Reversal (Sent Out by GSCS)

Reversal by GSCS request/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0420 0430
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans a n12 M M
5 amt_settlmt n12 C4
6 amt_cdhldr_bil n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4
10 conv_rate_cdhldr_bil n8 C4
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 O C0
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0

UPI CONFIDENTIAL 231

 Part II: Online Message

Reversal by GSCS request/response

Field Data Element Data Type Transmission Requirement
SW IS
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) C4
49 currcy_code_trans b an3 M M
50 currcy_code_settlmt an3 C4
51 currcy_code_cdhldr_bil an3 C4
52 pin_data b64 
55 ICC_data ansb..255(LLLVAR) C0 O
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage BB ans..12 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
121 national_sw_resved ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) O
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C
usage IP ansb..138 C

UPI CONFIDENTIAL 232

 Part II: Online Message

Reversal by GSCS request/response

Field Data Element Data Type Transmission Requirement
SW IS
128 msg_authn_code b64 C9 C9
Note a: For the messages of reversal transaction of Establish/Revoke Commission Relationship, Field 4 will not be
present.
4.5.1.1.15 Pre-authorization Completion (Advice)
For an approved pre-authorization (including MO/TO pre-authorization) transaction, the pre-authorization
completion advice can be conducted for settlement. For MO/TO pre-authorization completion (advice), the value of
field 25 is 18 to distinguish traditional pre-authorization completion (advice) transaction. The Issuer must not decline
the pre-authorization completion (advice) transaction.
If the sender of the advice does not receive the response, the advice will be stored and forwarded.
Note for Incremental Pre-authorization: To appropriately process pre-authorization completion, Acquirers shall
ensure that all fields are being populated correctly, including Field 38 must contain the value from the original pre-
authorization response message.
Table 187 Message Definition of Pre-authorization Completion (Advice) (Sent Out by the Acquirer)

Pre-authorization Completion by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14
6 amt_cdhldr_bil n12 C15
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
10 conv_rate_cdhldr_bil n8 C15
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
14 date_expr n4(YYMM) O
15 date_settlmt n4(MMDD) M
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M M

UPI CONFIDENTIAL 233

 Part II: Online Message

Pre-authorization Completion by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
35 track_2_data z..37(LLVAR) C1
36 track_3_data z..104(LLLVAR) C2
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 M M
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
45 track _1_data z..79(LLVAR) C70
48 addtnl_data_private ansb..512(LLLVAR) C22
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14
51 currcy_code_cdhldr_bil an3 C15
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
57 issr_addtnl_data ans..100(LLLVAR) O
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C
usage CD ans..241 C
usage BB ans..12 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 234

 Part II: Online Message

Pre-authorization Completion by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
usage ML ans47 C
121 national_sw_resved ans..100(LLLVAR) O
122 acq_inst_resvd ans..100(LLLVAR) O C0
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage IP ansb..138 C
128 msg_authn_code b64 C9 C9

4.5.1.1.16 Settlement Advice

When the Acquirer uses the dual message system and the Issuer uses the single message system, GSCS converts each
successfully settled transaction submitted by the Acquirer in the dual message settlement files to a settlement advice
transaction and transmits it to the Issuer.
Table 188 Message Definition of Settlement Advice

Settlement advice/response
Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14
6 amt_cdhldr_bil n12 C15
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
10 conv_rate_cdhldr_bil n8 C15
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
14 date_expr n4(YYMM) C0
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M M

UPI CONFIDENTIAL 235

 Part II: Online Message

Settlement advice/response
Field Data Element Data Type Transmission Requirement
SW IS
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 M M
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) O
48 addtnl_data_private ansb..512(LLLVAR) C0
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14
51 currcy_code_cdhldr_bil an3 C15
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
57 issr_addtnl_data ans..100(LLLVAR) O
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C
usage CD ans..241 C
usage BB ans..12 C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage VA ansb..190 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 236

 Part II: Online Message

Settlement advice/response
Field Data Element Data Type Transmission Requirement
SW IS
usage ML ans47 C
121 national_sw_resvd ans..100(LLLVAR) O C0
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage IP ansb..138 C
128 msg_authn_code b64 C9 C9

4.5.1.1.17 Refund (Online) / MO/TO Refund (Online)

For a settled international transaction, including purchase, MO/TO purchase, pre-authorization completion, MO/TO
pre-authorization completion and account funding, the refund (online) or MO/TO refund (online) transaction can be
used to return the purchase amount to the Cardholder’s account.
In the messages of account funding refund, Field 104 Usage AI and Field 104 Usage BB are not present.
In the messages of MO/TO refund (online), Field 117 Usage PF is not present.
This transaction is included in settlement and reconciliation but does not support reversal advice.
Table 189 Message Definition of Refund (Online) (Sent Out by the Acquirer)

Refund (online) by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M+
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M M

UPI CONFIDENTIAL 237

 Part II: Online Message

Refund (online) by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
35 track_2_data z..37(LLVAR) C1
36 track_3_data z..104(LLLVAR) C2
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
45 track _1_data z..79(LLVAR) C70
48 addtnl_data_private ansb..512(LLLVAR) C22
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 O
100 rcvg_inst_id_code an..11(LLVAR) M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C
usage CD ans..241 C
usage BB ans..12 C
usage WI ans..42 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 238

 Part II: Online Message

Refund (online) by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
usage ML ans47 C
usage PF an15 C
121 national_sw_resved ans..100(LLLVAR) O
122 acq_inst_resvd ans..100(LLLVAR) O C0
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C
usage IP ansb..138 C
128 msg_authn_code b64 C9 C9

Table 190 Message Definition of Refund (Online) (Sent Out by GSCS)

Refund (online) by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14
6 amt_cdhldr_bil n12 C15
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
10 conv_rate_cdhldr_bil n8 C15
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M

UPI CONFIDENTIAL 239

 Part II: Online Message

Refund (online) by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
35 track_2_data z..37(LLVAR) C0
36 track_3_data z..104(LLLVAR) C0
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C0
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
45 track _1_data z..79(LLVAR) C0
48 addtnl_data_private ansb..512(LLLVAR) C0
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14
51 currcy_code_cdhldr_bil an3 C15
52 pin_data b64 
55 ICC_data ansb..255(LLLVAR)  C
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 C0
100 rcvg_inst_id_code an..11(LLVAR) M M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage AI ans..173 C
usage CD ans..241 C
usage BB ans..12 C
usage WI ans..42 C

UPI CONFIDENTIAL 240

 Part II: Online Message

Refund (online) by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
usage PF an15 C
122 acq_inst_resvd ans..100(LLLVAR) O C0
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C
usage IP ansb..138 C
128 msg_authn_code b64 C9 C9

4.5.1.1.18 Exchange Rate Inquiry of UnionPay Card

Exchange Rate Inquiry is only performed before a UnionPay card international remittance transaction. It is used to
inquire about the currency conversion rate between transaction currency and Cardholder billing currency. For
example, if the remittance-out currency of an international remittance transaction is Hong Kong Dollar (HKD),
remittance-in currency is RMB, the Cardholder can firstly initiate Exchange Rate Inquiry transaction to get the RMB
amount as well as the currency conversion rate from HKD to RMB. Field 4 contains remittance-out amount in HKD.
Field 49 is filled with currency code of HKD. Field 6 contains remittance-in amount in RMB. Field 51 is filled with
currency code of RMB. Field 10 contains the conversion rate between HKD and RMB.
Table 191 Message Definition of Exchange Rate Inquiry of UnionPay Card

Exchange rate inquiry of UnionPay card request/response

Field Data Element Data Type Transmission Requirement
SD SW
Message Type Identifier n4 0600 0610
bitmap b128 M M
4 amt_trans n12 M M
6 amt_cdhldr_bil n12 M
7 transmsn_date_time n10(MMDDhhmmss) M M
10 conv_rate_cdhldr_bil n8 M
11 sys_trace_audit_num n6 M M
16 date_conv n4(MMDD) M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
39 resp_code an2 M
49 currcy_code_trans an3 M M

UPI CONFIDENTIAL 241

 Part II: Online Message

Exchange rate inquiry of UnionPay card request/response

Field Data Element Data Type Transmission Requirement
SD SW
51 currcy_code_cdhldr_bil an3 M M
70 netwk_mgmt_info_code n3 M M

4.5.1.1.19 Remittance (Online)

Remittance verification is associated with online remittance transaction, initiated by the Acquirer before online
remittance transaction.
Table 192 Message Definition of Remittance Verification

Remittance verification request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 

UPI CONFIDENTIAL 242

 Part II: Online Message

Remittance verification request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) O 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
57 issr_addtnl_data a ans..100(LLLVAR) C+ C16
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info b
ans..200(LLLVAR) M  C6 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
102 acct_id1 ans..28(LLVAR) C24 C16
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9 C9 C9
Note a, b: In remittance verification, Usage NM of Field 61 is used to store the sender’s name (in pinyin). It is not
case sensitive. Usage CI of Field 57 is used to store the receiver’s name (in Chinese characters) and ID number

UPI CONFIDENTIAL 243

 Part II: Online Message

Table 193 Message Definition of Remittance (Online)

Remittance (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
25 pos_cond_code n2 M  M 
28 amt_trans_fee x+n8 C6 + C0 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 

UPI CONFIDENTIAL 244

 Part II: Online Message

Remittance (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) O 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
54 addtnl_amt an..040(LLLVAR) O 
57 issr_addtnl_data ans..100(LLLVAR) C6 C16
Usage AS ans..100(LLLVAR) C6 C16
60 reserved a ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
90 orig_data_elemts n42 M 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
102 acct_id1 ans..28(LLVAR) C24 C16
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9 C9 C9
Note a: If F60.2.6=2, F6 and F51 will not be present.
4.5.1.1.20 Account Verification
Account verification is used to verify the identity of the Cardholder for the specific UnionPay bankcard. Account
verification transactions are generally used for card-no-present payment. However, account verification transactions
are not limited to card-no-present transactions. In other words, account verification transactions are not necessarily
followed by CNP transactions.
Table 194 Message Definition of Account Verification

UPI CONFIDENTIAL 245

 Part II: Online Message

Account verification request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 C6  C0 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  O 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
22 pos_entry_mode_code n3 M 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 O  C0 
42 card_accptr_id ans15 O  C0 
43 card_accptr_name_loc ans40 O 
44 addtnl_resp_code ans..25(LLVAR) O C0-
48 addtnl_data_private ansb..512(LLLVAR) M 
49 currcy_code_trans an3 M  M 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) C6 

UPI CONFIDENTIAL 246

 Part II: Online Message

Account verification request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
a
57 issr_addtnl_data ans..100(LLLVAR) C6 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info b ans..200(LLLVAR) C6  C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.21 Primary Credit

PCT is adopted as a credit order to transfer fund into a Cardholder’s bankcard account. F60.3.5 Transaction Initiation
Mode shall be filled with “3” or “4” to indicate that the PCT is an online primary credit transaction or a batch primary
credit transaction respectively. Message formats for primary credit (online) and (batch) are as follows:
Table 195 Message Definition of Primary Credit (Online)

Primary credit (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 

UPI CONFIDENTIAL 247

 Part II: Online Message

Primary credit (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
25 pos_cond_code n2 M  M 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
48 addtnl_data_private ansb..512(LLLVAR) C6 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
54 addtnl_amt an..040(LLLVAR) O C0-
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 

UPI CONFIDENTIAL 248

 Part II: Online Message

Primary credit (online) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 C6
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C C
usage BI ans9 M 
usage SI ans..483 C C
usage BB ans..12 C C
usage WI ans..42 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9 C9 C9

Table 196 Message Definition of Primary Credit (Batch)

Primary credit (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0200 0210
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C14
6 amt_cdhldr_bil n12 C15

UPI CONFIDENTIAL 249

 Part II: Online Message

Primary credit (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
10 conv_rate_cdhldr_bil n8 C15
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
14 date_expr n4(YYMM) O M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C14+
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 M C0
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) O
48 addtnl_data_private ansb..512(LLLVAR) C6
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C14+
51 currcy_code_cdhldr_bil an3 C15+
54 addtnl_amt an..040(LLLVAR) O
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
57 issr_addtnl_data ans..100(LLLVAR) C22
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C16 C16

UPI CONFIDENTIAL 250

 Part II: Online Message

Primary credit (batch) request/response

Field Data Element Data Type Transmission Requirement
SW IS
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C
usage BI ans9 M
usage WI ans..42 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
usage PF an15 C
122 acq_inst_resvd ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) O
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9

4.5.1.1.22 Primary Credit Confirmation

For online primary credit, if the Acquirer did not receive the response of primary credit request within the time limit,
or received it after timeout, or received the response code “98”, primary credit confirmation shall be triggered by
the Acquiring side.
For batch primary credit, if GSCS did not receive the response of primary credit request within the time limit, or
received it after timeout, primary credit confirmation will be triggered.
If the sender of primary credit confirmation did not receive the confirmation of primary credit transaction, the
primacy credit confirmation shall be stored and forwarded.
Table 197 Message Definition of Primary Credit Confirmation (Sent Out by the Acquirer)

Primary credit confirmation by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M

UPI CONFIDENTIAL 251

 Part II: Online Message

Primary credit confirmation by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
5 amt_settlmt n12 C4
6 amt_cdhldr_bil n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4
10 conv_rate_cdhldr_bil n8 C4
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
48 addtnl_data_private ansb..512(LLLVAR) C4
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C4
51 currcy_code_cdhldr_bil an3 C4
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.

UPI CONFIDENTIAL 252

 Part II: Online Message

Primary credit confirmation by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C
usage BI ans9 M
usage SI ans..483 C
usage BB ans..12 C
usage WI ans..42 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
usage PF an15 C
121 national_sw_resved ans..100(LLLVAR) O
122 acq_inst_resvd ans..100(LLLVAR) O C0
128 msg_authn_code b64 C9 C9

Table 198 Message Definition of Primary Credit Confirmation (Sent Out by GSCS)

Primary credit confirmation by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0220 0230
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C4
6 amt_cdhldr_bil n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4
10 conv_rate_cdhldr_bil n8 C4
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M

UPI CONFIDENTIAL 253

 Part II: Online Message

Primary credit confirmation by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 M M
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
48 addtnl_data_private ansb..512(LLLVAR) C4
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C4
51 currcy_code_cdhldr_bil an3 C4
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C16 C16
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C
usage BI ans9 M
usage SI ans..483 C
usage BB ans..12 C

UPI CONFIDENTIAL 254

 Part II: Online Message

Primary credit confirmation by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
usage WI ans..42 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
usage PF an15 C
121 national_sw_resved ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) C4
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
128 msg_authn_code b64 C9 C9

4.5.1.1.23 Establishment of Commission Relationship

The establishment of commission relationship can only be initiated online. It can be card-present or card-not-present
transaction.
Table 199 Message Definition of Establishment of Commission Relationship

Establishment of commission relationship request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  C0 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 

UPI CONFIDENTIAL 255

 Part II: Online Message

Establishment of commission relationship request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track_1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) M 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
55 ICC_data ansb..255(LLLVAR) C  O 
57 issr_addtnl_data a ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
b
61 ch_auth_info ans..200(LLLVAR) O C16 C16 C16
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.24 Revocation of Commission Relationship

It is initiated by the Acquirer online. The message format is here as follow:

UPI CONFIDENTIAL 256

 Part II: Online Message

Table 200 Message Definition of Revocation of Commission Relationship

Revocation of commission relationship request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  C0 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track_1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) M 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16

UPI CONFIDENTIAL 257

 Part II: Online Message

Revocation of commission relationship request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
55 ICC_data ansb..255(LLLVAR) C  O 
57 issr_addtnl_data a ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info b ans..200(LLLVAR) C6 C16 C16 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
usage PF an15 C C
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.1.25 Account Funding

AFT is used to debit the Issuer. The message definition of AFT is as follows.
Table 201 Message Definition of Account Funding

Account funding request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 

UPI CONFIDENTIAL 258

 Part II: Online Message

Account funding request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
28 amt_trans_fee X+n8 C6  C0 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
54 addtnl_amt an..040(LLLVAR) O 

UPI CONFIDENTIAL 259

 Part II: Online Message

Account funding request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
55 ICC_data ansb..255(LLLVAR) C  O 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) C22 C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6  C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
103 acct_id2 ans..28(LLVAR) C  C 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C C
usage BI ans9 M 
usage SI ans..483 C C
usage WI ans..42 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage CV ans8 C
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.2 Dual Message

The following message types are dual messages applicable to Members outside of Mainland China:
 Authorization/Authorization Cancellation
 Authorization Reversal/Authorization Cancellation Reversal
 Balance Inquiry
 Account Verification
Note: In dual-message mode, presentment and refund are submitted through file.

UPI CONFIDENTIAL 260

 Part II: Online Message

4.5.1.2.1 Authorization
The message format is the same as that of the single-message pre-authorization transaction, please refer to Section
4.5.1.1.2 Pre-authorization for more details. Authorization message can be used in purchase, cash withdrawal at
counter transaction, MO/TO transaction, and recurring transaction. Please refer to Appendix B Table of Transaction
Type Identification in the Technical Specifications on Bankcard Interoperability - Part VI Annex for the values of key
fields. Batch recurring file is also converted into online messages and sent to the dual-message Issuer, the message
definition is listed as follows:
Table 202 Message Definition of Recurring (Batch) (Sent to Dual-message Issuer)

Recurring (batch) sent to dual-message Issuer request/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0100 0110
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
6 amt_cdhldr_bil n12 C15+
7 transmsn_date_time n10(MMDDhhmmss) M M
10 conv_rate_cdhldr_bil n8 C15+
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
14 date_expr n4(YYMM) O M
15 date_settlmt n4(MMDD) M+ M
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 M C0
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
26 pos_pin_captr_code n2 C8
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
35 track_2_data z..37(LLVAR) C1
36 track_3_data z..104(LLLVAR) C2
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C3

UPI CONFIDENTIAL 261

 Part II: Online Message

Recurring (batch) sent to dual-message Issuer request/response

Field Data Element Data Type Transmission Requirement
SW IS
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) O
45 track_1_data z..76(LLVAR) C70
48 addtnl_data_private ansb..512(LLLVAR) C71
49 currcy_code_trans an3 M M
51 currcy_code_cdhldr_bil an3 C15+
52 pin_data b64 C7
53 sec_relatd_ctrl_info n16 C8
54 addtnl_amt an..040(LLLVAR) O
57 issr_addtnl_data ans..100(LLLVAR) C22
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C16 C16
100 rcvg_inst_id_code an..11(LLVAR) M+ M
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CD ans..241 C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C
usage PF an15 C
121 national_sw_resved ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) O
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage CA ans..60 C
usage TF ans43 C 
128 msg_authn_code b64 C9 C9
For an authorization transaction, the payment method may be by installments at the certain store Merchants. In this
instance, the processing of the transaction should be as follows:
 The value of Field 25 is 64.
 Choose Usage IP for Field 48. Since installment payment method can only be used at store Merchants, all
authorizations are fixed-amount. Usage AA of Field 48 should not be used in this case.

UPI CONFIDENTIAL 262

 Part II: Online Message
 For an installment payment transaction, Usage IP of Field 48 must be sent. If it is approved by the Issuer, Field
57 Usage IP must be present in the response message.
If the authorization transaction is sent to a single-message Issuer, it will be converted to a single message transaction:
 For a fixed-amount authorization transaction, it will be converted to purchase transaction and sent to the Issuer.
In this instance, it is mandatory for the Acquirer to fill F48 Usage AA in messages of Authorization and
Authorization Cancellation transactions. Refer to Section 3.37.3 for details. In this instance, the Issuer may not
return authorization code (Field 38), and the Acquirer outside of Mainland China should support and process
this transaction.
 For a recurring authorization transaction (Field 25 filled with 28), it will also be converted to a single message
recurring transaction and sent to the Issuer. In this instance, the Issuer may not return the authorization code
(Field 38), but the Acquirer should still support and process this transaction.
 For a manual cash withdrawal at a counter authorization transaction, it will also be converted to a single
message cash withdrawal transaction and sent to the Issuer. In this instance, the Issuer may not return the
authorization code (Field 38), but the Acquirer should still support and process this transaction.
4.5.1.2.2 Incremental Authorization
The message format is the same as that of the incremental pre-authorization defined in Section 4.5.1.1.4.
4.5.1.2.3 Authorization Cancellation (Online and Manual)
Field 60.2.5 (Transaction Channel) is filled with different values for Online and Manual Authorization Cancellation
transactions. When Field 60.2.5 is filled with 12, it means this transaction is initiated manually via CDRS.
For an international authorization cancellation transaction, if the Acquirer adopts dual message mode, the
cancellation of fixed-amount authorization must be sent through online message instead of out-going file. Field 90
should be included in authorization cancellation message sent by the Acquirer. For fixed-amount authorization, Field
41 and Field 43 must be filled with the same value as that of the original authorization message.
For an authorization cancellation of installment payment, Field 25 should be filled with 64.
For a MO/TO authorization cancellation transaction, Field 25 should be filled with 08.
For a recurring authorization cancellation transaction, Field 25 should be filled with 28.
Note for Incremental Authorization: To appropriately process authorization cancellation, Acquirers shall ensure that
all fields are being populated correctly, including:
1) Field 4 must contain the accumulated transaction amount (sum of the first authorization and all incremental
authorizations).
2) Field 38 must contain the value from the first authorization response message.
And the Issuer shall check whether the first authorization of the cancellation is related to incremental authorizations,
so as to determine the validity of Field 4.
Table 203 Message Definition of Authorization Cancellation (Online and Manual)

Pre-authorization cancellation (online and manual) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100 0110
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 

UPI CONFIDENTIAL 263

 Part II: Online Message

Pre-authorization cancellation (online and manual) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 M  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
35 track_2_data z..37(LLVAR) C1 
36 track_3_data z..104(LLLVAR) C2 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 C4  O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O C0-
45 track _1_data z..79(LLVAR) C70 
48 addtnl_data_private ansb..512(LLLVAR) C71 
49 currcy_code_trans an3 M  M 
52 pin_data b64 C7 
53 sec_relatd_ctrl_info n16 C8 C16
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s) below.

UPI CONFIDENTIAL 264

 Part II: Online Message

Pre-authorization cancellation (online and manual) request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
usage PR ans..512 C C
57 issr_addtnl_data ans..100(LLLVAR) O C
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16 
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission requirements.
90 orig_data_elemts n42 C71 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s) below.
usage WI ans..42 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage ML ans47 C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s) below.
usage QR ansb..120 C C C
usage IP ansb..138 C C
128 msg_authn_code b64 C9 C9 C9 C9

4.5.1.2.4 Authorization/Authorization Cancellation Reversal

The message format is the same as that of the pre-authorization/pre-authorization cancellation reversal in single
message.
For an authorization/authorization cancellation reversal of installment payment, Field 25 should be filled with 64.
For a MOTO authorization/authorization cancellation reversal transaction, Field 25 should be filled with 08.
For a recurring authorization/authorization cancellation reversal transaction, Field 25 should be filled with 28.
4.5.1.2.5 Balance Inquiry
Balance Inquiry in dual message mode is the same as that in single message mode except for message type identifier
and Field 25 (POS Condition Code). Message type identifier for dual message balance inquiry is 0100/0110. Field 25
for dual message balance inquiry is “00”. Please refer to Appendix B Table of Transaction Type Identification of the
Technical Specifications on Bankcard Interoperability - Part VI Annex for the value of key fields.
4.5.1.2.6 Account Verification
The format is the same as that of account verification in single message mode. Please refer to section 4.5.1.1.19 for
message format and field value.

UPI CONFIDENTIAL 265

 Part II: Online Message

4.6 Message Definition for IC Card Transaction Based on UICS Debit/Credit Standard
There are two kinds of applications in IC card debit/credit applications: one is standard debit/credit application, the
other is electronic cash application. Each application corresponds to different transaction types.

Message Definition for Standard Debit/Credit Application Transaction

4.6.1.1 Request Transactions
The following request transactions are applicable to UnionPay card international transactions:
 Balance inquiry
 Cash withdrawal
 Purchase
 Purchase cancellation
 Pre-authorization
 Pre-authorization cancellation
 Pre-authorization completion (request)
 Pre-authorization completion (request) cancellation
 Authorization
 Authorization cancellation
 Establishment of commission relationship
 Revocation of commission relationship
 Account funding
Though the basic message formats for balance inquiry, purchase, cash withdrawal, pre-authorization, establishment
of commission relationship, revocation of commission relationship transactions and account funding remain
unchanged, following statements should be taken note of:
 Add Field 23.
 IC cards based on UICS standard debit/credit support offline or online PIN verification. For offline PIN
verification, offline PIN shall not be submitted in the online message for security purposes. Therefore, in Field
52, the condition will be revised to accommodate this new feature of IC card.
 F22, F60.2.2, F60.2.3 and F60.2.7 are filled with the value in line with IC card requirement.
 Field 55 appears.
 For balance inquiry, establishment of commission relationship, and revocation of commission relationship,
subfields with tag “9F02” and “9F03” are filled with zero in the message format. If the Acquirer does not include
Field 49 in the message, then the subfield with tag valuing “5F2A” is filled in with zero; otherwise the subfield
should adopt the value of F49. In addition, Field 55 in Balance Inquiry, establishment of commission relationship,
and revocation of commission relationship messages should be optional. If the Acquirer does not submit F55,
the Issuer should not return any tag of F55.
The following tables illustrate the message format changes arising from IC card transactions, the omitted fields and
information are the same as those in magnetic stripe card transactions.
 Message Definition of IC Card Transactions without Field 55:
If the Acquirer does not submit Field 55 IC Card Data in IC card transaction messages, the message format is shown

UPI CONFIDENTIAL 266

 Part II: Online Message
in the table below. It applies to the following transactions: balance inquiry, establishment of commission relationship,
and revocation of commission relationship.
Table 204 Message Definition of IC Card Transactions without Field 55

IC card transactions without Field 55 request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100/0200 0110/0210
23 card_seq_id n3 C51  C0 
52 pin_data b64 C56  
 Message Definition of IC Card Transactions with Field 55:
If the Acquirer submits Field 55 IC Card Data in IC card transaction messages, the message format is shown in the
table below. It applies to the following transactions: balance inquiry, establishment of commission relationship,
revocation of commission relationship, purchase, cash withdrawal, pre-authorization and account funding
transaction.
Table 205 Message Definition of IC Card Transactions with Field 55

IC card transactions with Field 55 request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type n4 0100/0200 0110/0210
Identifier
23 card_seq_id n3 C51  C0 
52 pin_data b64 C56  
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
9F26 app_crypto b64 M 
9F27 crypto_info_data b8 M 
9F10 issr_app_data b..256 M 
9F37 unpredic_num b32 M 
9F36 app_trans_count b16 M  O 
95 termnl_veri_resl b40 M 
9A trans_date cn3 M 
9C trans_type cn1 M 
9F02 trans_amt cn6 M 
5F2A trans currcy code cn2 M 
82 app_interch_profl b16 M 

UPI CONFIDENTIAL 267

 Part II: Online Message

IC card transactions with Field 55 request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
9F1A termnl_cntry_code cn2 M 
9F03 amt_other cn6 M 
9F33 termnl_capbs b24 M 
9F34 card_ver_resl b24 O 
9F35 termnl_type cn1 O 
9F1E ifd_serial_num an8 C50 
84 DF_name b..128 O 
9F09 trem_app_ver_num b16 O 
9F41 trans_seq_count cn..4 O 
91 iss_auth_data b..128 O 
71 issr_scrpt1 b..1024 O 
72 issr_scrpt2 b..1024 O 
9F63 card_pro_id b128 C59 
61 ch_auth_info ans..200(LLLVAR) C54+ C16 
 Message Definition of Pre-authorization/Authorization Related Transactions:
Field 55 IC Card Data is not required for purchase cancellation, pre-authorization cancellation, pre-authorization
completion (request), pre-authorization completion (request) cancellation and authorization cancellation transactions.
The message format is different from that of the corresponding transaction using a magnetic stripe card in the following
aspects, and the definitions of other fields are the same:
 Add Field 23.
 IC card transactions based on UICS debit/credit standard support offline or online PIN verification. Offline PIN
shall not be submitted in the online message for insecurity purposes. The transmission requirement of Field 52
is C56.
 Field 22, Field 60.2.2, and Field 60.2.3 are filled with the values as required on IC card transactions.
The transmission requirement of Field 23 in IC card transactions for purchase cancellation and pre-authorization
completion (request) cancellation is different from that for pre-authorization cancellation, pre-authorization
completion (request) and authorization cancellation. Because purchase cancellation and pre-authorization
completion (request) cancellation transactions shall be initiated on the same settlement day as purchase and pre-
authorization completion (request), Field 23 shall be filled with the value matched with its original transaction. While
pre-authorization cancellation, pre-authorization completion (request) and authorization cancellation can be
initiated on different days from those of their original transactions, and Field 23 may not be matched.
Table 206 Message Definition of IC Card Purchase Cancellation and Pre-authorization Completion (Request) Cancellation

UPI CONFIDENTIAL 268

 Part II: Online Message

IC card purchase cancellation and pre-authorization completion (request) cancellation request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100/0200 0110/0210
23 card_seq_id n3 C51  C0 
52 pin_data b64 C56 

Table 207 Message Definition of IC Card Pre-authorization Cancellation, Pre-authorization Completion (Request) and
Authorization Cancellation

IC card purchase cancellation and pre-authorization completion (request) cancellation request/response

Field Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type Identifier n4 0100/0200 0110/0210
23 card_seq_id n3 C51  C0 
52 pin_data b64 C56 
 Message Definition of Dual-message Balance Inquiry and Authorization:
The message format is the same as that for balance inquiry and pre-authorization in single message.
4.6.1.2 Advice Transactions
The following advice transactions are applicable to international transactions:
 Pre-authorization completion (advice)
 Refund
 The reversal of request transaction
 Settlement advice
 Message Definition of Pre-authorization Completion (Advice):
Basically, the message format of pre-authorization completion (advice) transaction is the same as that of magnetic
stripe card. In terms of the transaction flow, the information of Field 55 is not required to be submitted by the
terminal, but the following should be noted:
 Add Field 23
 Field 22, Field 60.2.2 and Field 60.2.3 should be filled with the values in line with the requirement of IC card.
Table 208 Message Definition of IC Card Pre-authorization Completion (Advice) (Sent Out by the Acquirer)

IC card pre-authorization completion by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0220 0230
23 card_seq_id n3 C51 C0

UPI CONFIDENTIAL 269

 Part II: Online Message

Table 209 Message Definition of IC Card Pre-authorization Completion (Advice) (Sent Out by GSCS)

IC card pre-authorization completion by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0220 0230
23 card_seq_id n3 C51 C0
 Message Definition of Refund and Settlement Advice:
The IC card transaction information in Field 55 is not required to be submitted for refund and settlement advice
transactions. Therefore, the message format is basically the same as that of magnetic stripe card, but the following
points should be noted:
 Add Field 23.
 Field 22, Field 60.2.2 and Field 60.2.3 should be filled with the values in line with requirement of the IC card.
Table 210 Message Definition of IC Card Refund (Sent Out by the Acquirer)

IC card refund by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0220 0230
23 card_seq_id n3 C51 C0

Table 211 Message Definition of IC Card Refund (Sent Out by GSCS)

IC card refund by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0220 0230
23 card_seq_id n3 C51 C0

4.6.1.3 Reversal Transactions

 Message Definition of Reversal with Field 55 in the Original Transaction:
The message format is basically the same as that of magnetic stripe card, but the following points should be noted:
 Add Field 23.
 Field 22, Field 60.2.2 and Field 60.2.3 should be filled with the values in line with the requirement of IC card.
 Add Field 55.
Table 212 Message Definition of IC Card Reversal (Sent Out by the Acquirer)

UPI CONFIDENTIAL 270

 Part II: Online Message

IC card reversal by the Acquirer advice/response

Field Tag Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0420 0430
23 card_seq_id n3 C4 C0
55 ICC_data ansb..255(LLLVAR)
95 termnl_veri_resl b40 C53
9F1E ifd_serial_num an8 C4
9F10 issr_app_data b..256 C53
9F36 app_trans_count b16 C61 O
DF31 issr_scrpt_ resl b..168 C55

Table 213 Message Definition of IC Card Reversal (Sent Out by GSCS)

IC card reversal by GSCS advice/response

Field Tag Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0420 0430
23 card_seq_id n3 C51 C0
55 ICC_data ansb..255(LLLVAR)
95 termnl_veri_resl b40 C0
9F1E ifd_serial_num an8 C0
9F10 issr_app_data b..256 C0
9F36 app_trans_count b16 C0 O
DF31 issr_scrpt_ resl b..168 C0
 Message Definition of Reversal without Field 55 in the Original Transaction:
Message format of reversal transaction is basically the same as that of magnetic stripe card transactions. However,
the following should be noted:
 Add Field 23.
 Field 22, Field 60.2.2 and Field 60.2.3 should be filled with the values in line with the requirement of IC card.
Table 214 Message Definition of IC Card Reversal (Sent Out by the Acquirer)

IC card reversal by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0420 0430

UPI CONFIDENTIAL 271

 Part II: Online Message

IC card reversal by the Acquirer advice/response

Field Data Element Data Type Transmission Requirement
AC SW
23 card_seq_id n3 C51 C0

Table 215 Message Definition of IC Card Reversal (Sent Out by GSCS)

IC card reversal by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0420 0430
23 card_seq_id n3 C51 C0

Message Definition for E-cash Transaction

4.6.2.1 Designated Account Loading Transaction
This transaction must be performed on financial terminals, and PIN is optional.
Table 216 Message Definition of Designated Account Loading Transaction

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type n4 0200 0210
Identifier
Bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 

UPI CONFIDENTIAL 272

 Part II: Online Message

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 91  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
44 addtnl_resp_code ans..25(LLVAR) O 
45 track_1_data z..79(LLVAR) C70 
48 addtnl_data_private ans..512(LLLVAR) O 
49 currcy_code_trans an3 M  M 
50 currcy_code_settlmt an3 C14+ C14+
51 currcy_code_cdhldr_bil an3 C15+ C15+
52 pin_data b8 C7 
53 sec_relatd_ctrl_info n16 C8 C16
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
9F26 app_crypto b64 M 
9F27 crypto_info_data b8 M 
9F10 issr_app_data b..256 M 
9F37 unpredic_num b32 M 
9F36 app_trans_count b16 M  O 
95 termnl_veri_resl b40 M 

UPI CONFIDENTIAL 273

 Part II: Online Message

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
9A trans_date cn3 M 
9C trans_type cn1 M 
9F02 trans_amt cn6 M 
5F2A trans currcy code cn2 M 
82 app_interch_profl b16 M 
9F1A termnl_cntry_code cn2 M 
9F03 amt_other cn6 M 
9F33 termnl_capbs b24 M 
9F34 card_ver_resl b24 O 
9F35 termnl_type cn1 O 
9F1E ifd_serial_num an8 C50 
84 DF_name b..128 O 
9F09 trem_app_ver_num b16 O 
9F41 trans_seq_count cn..4 O 
91 iss_auth_data b..128 O 
71 issr_scrpt1 b..1024 O 
72 issr_scrpt2 b..1024 O 
9F74 ECIAC an6 O 
9F63 card_pro_id b128 C59 
60 Reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
details.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 mesg_authn_code b64 C9 C9 C9 C9

4.6.2.2 Cash Loading Transaction

Table 217 Message Definition of Cash Loading Transaction

UPI CONFIDENTIAL 274

 Part II: Online Message

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
Message Type n4 0200 0210
Identidier
Bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code n6 M  M 
4 amt_trans n12 M  M 
5 amt_settlmt n12 C14+ C14+
6 amt_cdhldr_bil n12 C15+ C15+
7 transmsn_date_time n10(MMDDhhmmss) M  M 
9 conv_rate_settlmt n8 C14+ C14+
10 conv_rate_cdhldr_bil n8 C15+ C15+
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
14 date_expr n4(YYMM) O  M 
15 date_settlmt n4(MMDD) M+ M 
16 date_conv n4(MMDD) C14+ C14+
18 mchnt_type n4 M  M 
19 mchnt_cntry_code n3 M  M 
22 pos_entry_mode_code n3 M 
23 card_seq_id n3 C51  C0 
25 pos_cond_code n2 91  M 
26 pos_pin_captr_code n2 C8 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
38 authr_id_resp an6 O 
39 resp_code an2 M 
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 

UPI CONFIDENTIAL 275

 Part II: Online Message

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
44 addtnl_resp_code ans..25(LLVAR) O 
45 track_1_data z..79(LLVAR) C70 
48 addtnl_data_private ans..512(LLLVAR) O 
49 currcy_code_trans an3 M  M 
50 Currcy_code_settlmt an3 C14+ C14+
51 Currcy_code_cdhldr_bil an3 C15+ C15+
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
9F26 app_crypto b64 M 
9F27 crypto_info_data b8 M 
9F10 issr_app_data b..256 M 
9F37 unpredic_num b32 M 
9F36 app_trans_count b16 M  O 
95 termnl_veri_resl b40 M 
9A trans_date cn3 M 
9C trans_type cn1 M 
9F02 trans_amt cn6 M 
5F2A trans currcy code cn2 M 
82 app_interch_profl b16 M 
9F1A termnl_cntry_code cn2 M 
9F03 amt_other cn6 M 
9F33 termnl_capbs b24 M 
9F34 card_ver_resl b24 O 
9F35 termnl_type cn1 O 
9F1E ifd_serial_num an8 C50 
84 DF_name b..128 O 
9F09 trem_app_ver_num b16 O 
9F41 trans_seq_count cn..4 O 
91 iss_auth_data b..128 O 
71 issr_scrpt1 b..1024 O 
72 issr_scrpt2 b..1024 O 

UPI CONFIDENTIAL 276

 Part II: Online Message

Designated account loading request/response

Field Tag Data Element Data Type Transmission Requirement
AC SW IS SW
9F74 ECIAC an6 O 
9F63 card_pro_id b128 C59 
60 Reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
details.
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
121 national_sw_resved ans..100(LLLVAR) O C0 
122 acq_inst_resvd ans..100(LLLVAR) O C0- C0+
123 issr_inst_resvd ans..100(LLLVAR) O C0-
128 mesg_authn_code b64 C9 C9 C9 C9

4.6.2.3 Reversal for Designated Account Loading

When the Designated Account Loading transaction is abnormal, a reversal should be initiated. The flow of the reversal
is the same as that of magnetic stripe card.
Table 218 Message Definition of Reversal for Designated Account Loading (Sent Out by the Acquirer)

Reversal for designated account loading by the Acquirer advice/response

Field Tag Data Element Data Type Transmission Requirement
AC SW
Message Type n4 0420 0430
Identifier
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M

UPI CONFIDENTIAL 277

 Part II: Online Message

Reversal for designated account loading by the Acquirer advice/response

Field Tag Data Element Data Type Transmission Requirement
AC SW
19 mchnt_cntry_code n3 O C0
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
49 currcy_code_trans an3 M M
50 currcy_code_settlmt an3 C4
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
95 termnl_veri_resl b40 C53
9F1E ifd_serial_num an8 C4
9F10 issr_app_data b..256 C53
9F36 app_trans_count b16 M O
DF31 issr_scrpt_ resl b..168 C55
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
requirements.
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M
121 national_sw_resved ans..100(LLLVAR) O
122 acq_inst_resvd ans..100(LLLVAR) O C0
128 msg_authn_code b64 C9 C9

Table 219 Message Definition of Reversal for Designated Account Loading (Sent Out by GSCS)

UPI CONFIDENTIAL 278

 Part II: Online Message

Reversal for designated account loading by GSCS advice/response

Field Tag Data Element Data Type Transmission Requirement
SW IS
Message Type n4 0420 0430
Identifier
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M M
5 amt_settlmt n12 C4
6 amt_cdhldr_bil n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C4
10 conv_rate_ cdhldr_bil n8 C4
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M M
16 date_conv n4(MMDD) C4
18 mchnt_type n4 M M
19 mchnt_cntry_code n3 O C0
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
44 addtnl_resp_code ans..25(LLVAR) C4
49 currcy_code_trans an3 M M

UPI CONFIDENTIAL 279

 Part II: Online Message

Reversal for designated account loading by GSCS advice/response

Field Tag Data Element Data Type Transmission Requirement
SW IS
50 currcy_code_settlmt an3 C4
51 currcy_code_cdhldr_bil an3 C4
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
95 termnl_veri_resl b40 C0
9F1E ifd_serial_num an8 C0
9F10 issr_app_data b..256 C0
9F36 app_trans_count b16 M O
DF31 issr_scrpt_ resl b..168 C0
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
requirements.
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M M
121 national_sw_resved ans..100(LLLVAR) O C0
123 issr_inst_resvd ans..100(LLLVAR) C4
128 msg_authn_code b64 C9 C9

4.6.2.4 Reversal for Cash Loading

Message format is the same as that of reversal for Designated Account Load.
4.6.2.5 Refund (Online)
For message format for refund and settlement advice of debit/credit application, please refer to Section 4.6.1.2.
Message Format of Script Processing Result Advice for IC Card Based on Debit/Credit
Application and E-Cash Application of UICS Debit/Credit Standard
When a transaction (for UnionPay card international transactions, it only includes balance inquiry, cash withdrawal,
purchase and pre-authorization) contains the Issuer script, the Acquirer should immediately notify the Issuer of the
script processing result of the card. The shaded message field takes the same value as that of the original transaction.
Table 220 Message Definition of IC Card Script Processing Result Based on UICS Debit/Credit Card Standard (Sent Out by the
Acquirer)

IC Card Script Processing Result Based on UICS Debit/Credit Card Standard by the Acquirer advice/response
Field Tag Data Element Data Type Transmission Requirement
AC SW
Message Type Identifier n4 0620 0630
bitmap b128 M M

UPI CONFIDENTIAL 280

 Part II: Online Message

IC Card Script Processing Result Based on UICS Debit/Credit Card Standard by the Acquirer advice/response
Field Tag Data Element Data Type Transmission Requirement
AC SW
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M
18 mchnt_type n4 M
19 mchnt_cntry_code n3 M
22 pos_entry_mode_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M
39 resp_code an2 M M
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
49 currcy_code_trans an3 C4
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
9F33 termnl_capbs b24 C4
95 termnl_veri_resl b40 M
9F37 unpredic_num b32 C4
9F1E ifd_serial_num an8 C4
9F10 issr_app_data b..256 M
9F26 app_crypto b64 M
9F36 app_trans_count b16 M O
82 app_interch_profl b16 M

UPI CONFIDENTIAL 281

 Part II: Online Message

IC Card Script Processing Result Based on UICS Debit/Credit Card Standard by the Acquirer advice/response
Field Tag Data Element Data Type Transmission Requirement
AC SW
DF31 issr_scrpt_resl b..168 M
9F1A trans_cntry_code cn2 M
9A trans_date cn3 M
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
requirements.
70 netwk_mgmt_info_code n3 M M
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M

Table 221 Message Definition of IC Card Script Processing Result Based on UICS Debit/Credit Card Standard (Sent Out by GSCS)

IC Card Script Processing Result Based on UICS Debit/Credit Card Standard by GSCS advice/response
Field Tag Data Element Data Type Transmission Requirement
SW IS
Message Type Identifier n4 0620 0630
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 C4
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
12 time_local_trans n6(hhmmss) M M
13 date_local_trans n4(MMDD) M M
15 date_settlmt n4(MMDD) M M
18 mchnt_type n4 M
19 mchnt_cntry_code n3 M
23 card_seq_id n3 C51 C0
25 pos_cond_code n2 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M M
39 resp_code an2 M M

UPI CONFIDENTIAL 282

 Part II: Online Message

IC Card Script Processing Result Based on UICS Debit/Credit Card Standard by GSCS advice/response
Field Tag Data Element Data Type Transmission Requirement
SW IS
41 card_accptr_termnl_id ans8 M M
42 card_accptr_id ans15 M M
43 card_accptr_name_loc ans40 M
49 currcy_code_trans an3 C0
55 ICC_data ansb..255(LLLVAR) Refer to transmission requirements of tag(s)
below.
9F33 termnl_capbs b24 C0
95 termnl_veri_resl b40 M
9F37 unpredic_num b32 C0
9F1E ifd_serial_num an8 C0
9F10 issr_app_data b..256 M
9F26 app_crypto b64 M
9F36 app_trans_count b16 M O
82 app_interch_profl b16 M
DF31 issr_scrpt_resl b..168 M
9F1A trans_cntry_code cn2 M
9A trans_date cn3 M
60 reserved ans..100(LLLVAR) Refer to Section 3.47.6 for transmission
requirements.
70 netwk_mgmt_info_code n3 M M
90 orig_data_elemts n42 M
100 rcvg_inst_id_code an..11(LLVAR) M M

Message Definition for Clearing, Settlement and Day-end Batch Processing for IC Card
Based on Debit/Credit Application and Electronic Cash Application of UICS
Debit/Credit Standard
It is the same as that of magnetic stripe card.

4.7 Message Definition for E-commerce Transaction Certified by GSCS CUPSecure

(Currently Not Used)
4.8 Message Definition for Risk Control Transaction (Currently Not Used)
4.9 Message Definition for Stand-in Authorization Transaction
Message Definition for Stand-in Authorization Echo

UPI CONFIDENTIAL 283

 Part II: Online Message
The stand-in authorization status Echo message is sent by GSCS in the same format as network management
transaction message. F70 is valued “401” to indicate stand-in authorization echo message.
Table 222 Message Definition of Stand-in Authorization Echo

Stand-in authorization echo advice/response

Field Data Element Data Type Transmission Requirement
SW RC
Message Type Identifier n4 0820 0830
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M
100 rcvg_inst_id_code an..11(LLVAR) M M

Message Definition for Stand-in Authorization Transaction Transmission

Activate/Suspend
Stand-in authorization transaction transmission activate/suspend message is used to activate and suspend the stand-
in authorization transaction transmission between UnionPay and Members. Members can send activate/suspend
message. UnionPay can send suspension message. The message format is the same as the message format of
network management transaction with F70 valued “501” to indicate activation and “502” to indicate suspension.
Table 223 Message Definition of Stand-in Authorization Transaction Transmission Activate/Suspend (Sent Out by GSCS)

Stand-in authorization transaction transmission activate/suspend by GSCS advice/response

Field Data Element Data Type Transmission Requirement
SW RC
Message Type Identifier n4 0820 0830
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
a
32 acq_inst_id_code an..11(LLVAR) M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M
b
100 rcvg_inst_id_code an..11(LLVAR) M M
Note a: Field 32 is filled with the Institution Identification Code of the stand-in authorized Issuer.
Note b: Field 100 is filled with the Institution Identification Code of the Member who receives stand-in
authorization transaction information log.

Table 224 Message Definition of Stand-in Authorization Transaction Transmission Activate/Suspend (Sent Out by the Member)

UPI CONFIDENTIAL 284

 Part II: Online Message

Stand-in authorization transaction transmission activate/suspend by the Member advice/response

Field Data Element Data Type Transmission
Requirement
SD SW
Message Type Identifier n4 0820 0830
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
32 acq_inst_id_code a an..11(LLVAR) M M
33 fwd_inst_id_code b an..11(LLVAR) M M
39 resp_code an2 M
70 netwk_mgmt_info_code n3 M M
Note a: Field 32 is filled with the Institution Identification Code of the stand-in authorized Issuer.
Note b: Field 33 is filled with the Institution Identification Code of the Member who sends stand-in
authorization transaction transmission activate/suspend advice and receives transaction information log.

Message Definition for Stand-in Authorization Transaction Transmission Advice

(Online)
The stand-in authorization transaction transmission advice message can be used to transfer the stand-in
authorization record from UnionPay to the stand-in authorization Member in the format listed below:
Table 225 Message Definition of Stand-in Authorization Transaction Transmission Advice (Online)

Stand-in authorization transaction transmission (online) advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Message Type n4 0220 0230
Identifier
bitmap b128 M M
2 primary_acct_num n..19(LLVAR) M M
3 processing_code n6 M M
4 amt_trans n12 M
5 amt_settlmt n12 C14
6 amt_cdhldr_bil n12 C15
7 transmsn_date_time n10(MMDDhhmmss) M M
9 conv_rate_settlmt n8 C14
10 conv_rate_cdhldr_bil n8 C15
11 sys_trace_audit_num n6 M M

UPI CONFIDENTIAL 285

 Part II: Online Message

Stand-in authorization transaction transmission (online) advice/response

Field Data Element Data Type Transmission Requirement
SW IS
12 time_local_trans n6(hhmmss) M
13 date_local_trans n4(MMDD) M
15 date_settlmt n4(MMDD) M
16 date_conv n4(MMDD) C14
18 mchnt_type n4 M
19 mchnt_cntry_code n3 C4
22 pos_entry_mode_code n3 M
25 pos_cond_code n2 M M
26 pos_pin_captr_code n2 C0
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
37 retrivl_ref_num an12 M
38 authr_id_resp an6 C4
39 resp_code an2 M
41 card_accptr_termnl_id ans8 M
42 card_accptr_id ans15 M
43 card_accptr_name_loc ans40 M
48 addtnl_data_private ans..512(LLLVAR) M
49 currcy_code_trans an3 M
50 currcy_code_settlmt an3 C14
51 currcy_code_cdhldr_bil an3 C15
55 ICC_data ansb..255(LLLVAR) C4
60 reserved a ans..100(LLLVAR) M
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage TK ansb..96 Refer to Section 3.50.3 for transmission
requirements.
90 orig_data_elemts n42 C4
100 rcvg_inst_id_code an..11(LLVAR) M M
121 national_sw_resved ans..100(LLLVAR) O C0
128 msg_authn_code b64 C9 C9

UPI CONFIDENTIAL 286

 Part II: Online Message

Stand-in authorization transaction transmission (online) advice/response

Field Data Element Data Type Transmission Requirement
SW IS
Note a: All sub-fields of Field 60 (60.1 - 60.3.10) will be sent to the Issuer.

Message Definition for Stand-in Authorization Parameter Update Advice

It is sent by the Issuer to UnionPay. One message contains one stand-in authorization parameter with F70 valued
“902”. Currently it is only used to transmit the black list card information of stand-in authorization.
Table 226 Message Definition of Stand-in Authorization Parameter Update

Stand-in authorization parameter update advice/response

Field Data Element Data Type Transmission Requirement
IS SW
Message Type Identifier n4 0620 0630
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
33 fwd_inst_id_code an..11(LLVAR) M M
39 resp_code an2 M
48 addtnl_data_private ans..512(LLLVAR) M
70 netwk_mgmt_info_code n3 M M

4.10 Message Definition for Payment Token Transaction

The message formats of payment token transactions are the same as those of PAN-based transactions.
The valid values and message transmission requirements of some payment token-related fields are shown in the
table below. The requirements of other fields not mentioned are the same as those of PAN-based transactions.

Transmission Requirements for Token-related Fields in Payment Token Original

Request Transactions
Table 227 Transmission Requirements for Token-related Fields in Payment Token Original Request Transactions

Payment token transaction original request/response

Field Definition Format Transmission Description
Requirement
AC SW IS SW
2 Primary account n..19 M C16 M C16 For Payment Token Transaction, UnionPay
number (LLVAR) System will follow the following rules to
process this field:
 In the request message, the Acquirer
will fill this field with a Token and

UPI CONFIDENTIAL 287

 Part II: Online Message

Payment token transaction original request/response

Field Definition Format Transmission Description
Requirement
AC SW IS SW
UnionPay System will replace it with
the real PAN before forwarding this
field to the Issuer.
 In the response message, the Issuer
will fill this field with the real PAN and
UnionPay System will replace it with a
Token before forwarding this field to
the Acquirer.
14 Date, expiration n4 O C6 M C6 For Payment Token Transaction, UnionPay
(YYMM) System will follow the following rules to
process this field:
 In the request message, the Acquirer
will fill this field with Token Expiry
Date and UnionPay System will
replace it with PAN Expiry Date before
forwarding this field to the Issuer. If
TR does not provide Card Expiry Date
in Token Request, UnionPay System
will remove this field from the request
message. For card-not-present
transaction, the Expiration Date
Indicator of the Usage AM in Field
61.6 must be set to “1” when this field
is present.
 In the response message, the Issuer
will fill this field with PAN Expiry Date
and UnionPay System will replace it
with the Token Expiry Date before
forwarding this field to the Acquirer.
22 Point of service n3 M  The Acquirer will fill this field according to
entry mode the Token entry mode and PIN entry mode
and UnionPay System will forward this field
to the Issuer.
Valid values for the first and second bytes:
02, 90- Magnetic stripe input
05, 07, 95, 98- Chip input
04- QRC input: Field 60.3.6 Transaction
Medium is 7 for QRC-based transaction
01- Manual input
23 Card sequence n3 C51 C6 C0 C6 For Payment Token Transaction, the
number Acquirer must fill this field with Token
Sequence Number when it can be obtained

UPI CONFIDENTIAL 288

 Part II: Online Message

Payment token transaction original request/response

Field Definition Format Transmission Description
Requirement
AC SW IS SW
by the terminal. The first 2 bytes of Field 22
are 05, 07, 95, or 98. UnionPay System will
follow the following rules to process this
field:
 In the request message, when chip
information is generated by the Issuer,
UnionPay System will directly forward
the message to the Issuer. When chip
information is generated by UnionPay,
UnionPay System will remove this
field from the request message.
 In the response message, when this
field exists in the request message to
the Issuer, the Issuer must return this
field with the same value and
UnionPay System will forward it to the
Acquirer; when this field does not
exist in the request message to the
Issuer, it must not be presented by the
Issuer. UnionPay System will replace it
with the value in the request message
sent by the Acquirer if it exists.
35 Track 2 data z..37 C1 C6 For Payment Token Transaction, the
(LLVAR) Acquirer must fill this field with Token Track
2 Data when the first 2 bytes of Field 22 are
“02”, “05”, “07”, “90”, “95”, or “98”.
 In the request message, when Token
Track 2 Data is generated by the
Issuer, UnionPay System will directly
forward the message to the Issuer;
when Token Track 2 Data is generated
by UnionPay. UnionPay System will
remove this field from the request
message.
36 Track 3 data z..104 C2 C6 If Track 3 Data exists, for Payment Token
(LLLVAR) Transaction, the Acquirer must fill this field
with Token Track 3 Data when the first 2
bytes of Field 22 are “02” or “90”.
 In the request message, when Token
Track 3 Data is generated by the
Issuer, UnionPay System will directly
forward the message to the Issuer;
when Token Track 3 Data is generated

UPI CONFIDENTIAL 289

 Part II: Online Message

Payment token transaction original request/response

Field Definition Format Transmission Description
Requirement
AC SW IS SW
by UnionPay. UnionPay System will
remove this field from the request
message.
45 Track 1 data z..79 C70 C6 If Track 1 Data exists, for Payment Token
(LLVAR) Transaction, the Acquirer must fill this field
with Token Track 1 Data when the first 2
bytes of Field 22 are “02” or “90”.
 In the request message, when Token
Track 1 Data is generated by the
Issuer, UnionPay System will directly
forward the message to the Issuer;
when Token Track 1 Data is generated
by UnionPay, UnionPay System will
remove this field from the request
message.
55 IC card system ansb..255 C C6 O  For Payment Token Transaction, the
related data a (LLLVAR) Acquirer must fill this field with Token IC
Card System Related Data when the first 2
bytes of Field 22 are “05”, “07”, “95”, or
“98”. UnionPay System will follow the
following rules to process this field:
• In the request message, when chip
information is generated by the Issuer,
UnionPay System will directly forward
the message to the Issuer; when chip
information is generated by UnionPay,
UnionPay System will remove this
field from the request message if the
Issuer does not need such
information; UnionPay system will
transmit this field to the Issuer if the
Issuer needs this information, and in
such circumstance, the Issuer cannot
process ARQC verification on this
field.
• In the response message, when chip
information is generated by the Issuer,
it is optional for the Issuer to fill this
field with the same data elements as
those of PAN-based IC card
transaction and UnionPay System will
forward it to the Acquirer; when chip
information is generated by UnionPay.

UPI CONFIDENTIAL 290

 Part II: Online Message

Payment token transaction original request/response

Field Definition Format Transmission Description
Requirement
AC SW IS SW
UnionPay System will remove this
field from the response message.
Note a: The Acquirer must fill Field 55
according to Section 4.6 Message
Definition for IC Card Transaction Based on
UICS Debit/Credit Standard.
60.2.7 IC card n1 M C6 M C16 The Acquirer, UnionPay, and the Issuer shall
authentication follow the following rules to process this
reliability field:
identifier
• In request message, the Acquirer shall
fill this field in the same manner as it
does today. UnionPay System will
replace it with value 4 if the
transaction has used Token Service
provided by UnionPay.
• In response message, the Issuer must
return this field with the same value.
UnionPay System will replace it with
value in the request message sent by
the Acquirer.
63 Financial ansb..512 Refer to Section 3.50.3 When the Token Service is provided by
network data, (LLLVAR) for transmission UnionPay and the Issuer requires the
Usage TK requirements. Token-related information, the TK usage
will be present. Otherwise, this field will be
absent.

Transmission Requirements for Token-related Fields in Payment Token Subsequent

Request Transactions
For subsequent Payment Token request transactions, the transmission requirements (whether it is mandatory,
conditional or optional, and must be filled with the same value as the original transactions) are the same as those of
PAN-based transactions. For Field 60.2.7, please refer to Section 3.48.6.2 for details. For Field 63, please refer to
Section 3.50.3 the transmission requirements of Usage TK in subsequent request transactions for details. For
Payment Token subsequent request transactions, the Acquirer will send Payment Token in Field 2 and Token Expiry
Date in Field 14, if present.

Transmission Requirements for Token-related Fields in Payment Token Advice

Transactions
 Transmission Requirements of Token-Related Fields in Advice Transactions (ACSW)
For Payment Token advice transactions, the transmission requirements (whether it is mandatory, conditional or
optional, and must be filled with the same value as the original transactions) are the same as those of PAN-based
transactions. For Field 63, please refer to Section 3.50.3 the transmission requirements of Usage TK in advice

UPI CONFIDENTIAL 291

 Part II: Online Message

transactions for details. For Payment Token advice transactions (ACSW), the Acquirer will send Payment Token in
Field 2 and Token Expiry Date in Field 14, if present.
 Transmission Requirements of Token-Related Fields in Advice Transactions (SWIS)
For Payment Token advice transactions, the transmission requirements (whether it is mandatory, conditional or
optional, and must be filled with the same value as the original transactions) are the same as PAN-based transactions.
For Field 60.2.7, please refer to 3.48.6.4 for details. For Field 63, please refer to Section 3.50.3 the transmission
requirements of Usage TK in advice transactions for details. For Payment Token advice transactions (SWIS), GSCS
will send a real PAN in Field 2 and Card Expiry Date in Field 14, if present.

4.11 Message Definition for QRC-based Payment Transaction

Message Definition for Merchant-presented QRC-based Payment Transaction
4.11.1.1 Purchase
The definition of Merchant-presented QRC-based purchase message among the Acquirer, GSCS, and the Issuer are
the same as that of bankcard transaction messages except for the following fields:
• F22= 93X/ 94X
• F60.3.6= 5
• F125 Usage QR, please refer to Section 3.64.5.3 for its transmission requirements.
The transmission requirements of message fields between UMPS and the Acquirer are described in the following
table. After receiving the message from UMPS, the Acquirer can refill the fields as per its system requirements. For
example, F11 can be refilled to ensure that the combination of F32, F33, F7, and F11 is unique in the system.
UMPS will forward Field 55 ICC data if it is a chip transaction. GSCS may process the ICC data in conditions including
but not limited to a token-based transaction where the chip information is issued by UnionPay. It may be returned
by the Issuer or GSCS depending on which party processes the ICC data.
The QRC Voucher Number in Field 125 Usage QR is used to link the QRC-based Payment among all the systems, and
it shall be consistent in all the messages.
Table 228 Message Definition of Merchant-presented QRC-based Purchase

Merchant-presented QRC-based purchase request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
Message Type Identifier n4 0200 0210
bitmap b128 M M M M M M
2 primary_acct_num n..19(LLVAR) M M  M  
3 processing_code n6 M M  M  
4 amt_trans n12 M M  M  
5 amt_settlmt n12 C14+ C14+ 
6 amt_cdhldr_bil n12 C15+ C15+ 
7 transmsn_date_time n10(MMDDhhmmss) M M  M  

UPI CONFIDENTIAL 292

 Part II: Online Message

Merchant-presented QRC-based purchase request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
9 conv_rate_settlmt n8 C14+ C14+ 
10 conv_rate_cdhldr_bil n8 C15+ C15+ 
11 sys_trace_audit_num n6 M M  M  
12 time_local_trans n6(hhmmss) M M  M  
13 date_local_trans n4(MMDD) M M  M  
14 date_expr n4(YYMM) O O  M  
15 date_settlmt n4(MMDD) M+ M  
16 date_conv n4(MMDD) C14+ C14+ 
18 mchnt_type a n4 M M  M  
19 mchnt_cntry_code b
n3 M M  M  
22 pos_entry_mode_codec n3 M M 
23 card_seq_id n3 C51   C0  
25 pos_cond_code n2 M M  M  
26 pos_pin_captr_code n2 C8 C8 
28 amt_trans_fee d x+n8 C6
32 acq_inst_id_code an..11(LLVAR) M M  M  
33 fwd_inst_id_code an..11(LLVAR) M M  M  
35 track_2_data z..37(LLVAR) C1 C1 
36 track_3_data z..104(LLLVAR) C2 C2 
37 retrivl_ref_num an12 M  M  
38 authr_id_resp an6 O  
39 resp_code an2 M  
41 card_accptr_termnl_id e
ans8 O M  M  
42 card_accptr_idf ans15 M M  M  
43 card_accptr_name_locg ans40 M M 
44 addtnl_resp_code ans..25(LLVAR) O  
45 track _1_data z..79(LLVAR) C70 C70 
48 addtnl_data_private ansb..512(LLLVAR) C22 C22 
49 currcy_code_trans an3 M M  M  
50 currcy_code_settlmt an3 C14+ C14+ 

UPI CONFIDENTIAL 293

 Part II: Online Message

Merchant-presented QRC-based purchase request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
51 currcy_code_cdhldr_bil an3 C15+ C15+ 
52 pin_data b64 C7 C7 
53 sec_relatd_ctrl_info n16 C8 C8 C16
54 addtnl_amt an..040(LLLVAR) O  
55 ICC_data ansb..255(LLLVAR) C  C C C 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage PR ans..512 C C 
57 issr_addtnl_data ans..100(LLLVAR) C22 C 
60 reserved h ans..100(LLLVAR) C Refer to Section 3.47.6 for 
transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C6 C16 C16  
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage TK ansb..96 Refer to Section 3.50.3 for 
transmission requirements.
usage MQ ansb..512 C
100 rcvg_inst_id_code an..11(LLVAR) M+ M  
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage AI ans..173 C C C
usage CD ans..241 C C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage VA ansb..190 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage ML i ans47 C C C
usage MI ansb..56 C
121 national_sw_resved ans..100(LLLVAR) O C0 C16 
122 acq_inst_resvd ans..100(LLLVAR) O O C0- C0+ 
123 issr_inst_resvd ans..100(LLLVAR) O C0- 

UPI CONFIDENTIAL 294

 Part II: Online Message

Merchant-presented QRC-based purchase request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage CA ans..60 C
usage CV ans8 C C C
usage QR ansb..120 C C C C 
usage IP ansb..138 C  C
128 msg_authn_code b64 C9 C9 C9 C9 C9 C9
Note a: F18 can be captured from the Merchant-presented QRC.
Note b: F19 can be captured from the Merchant-presented QRC, and shall be present in the numeric format.
Note c: The first and second bytes of F22 shall be filled with “94” when the chip information is not present.
Note d: F28 can be filled with the value of tip or convenience fee if applicable.
Note e, f, g: F41, F42 and F43 can be captured from the Merchant-presented QRC.
Note h: The transmission requirement of F60 in the messages between UMPS and the Acquirer is the same as
that between the Acquirer and GSCS.
Note i: The merchant local name of F117 Usage ML may be captured from the Merchant-presented QRC.

4.11.1.2 Authorization
The definition of Merchant-presented QRC-based authorization messages among the Acquirer, GSCS, and the Issuer
are the same as that of bankcard transaction messages except for the following fields:
• F22= 93/94
• F60.3.6= 5
• F125 Usage QR, please refer to Section 3.64.5.3 for its transmission requirements.
The transmission requirements of message fields between UMPS and the Acquirer are described in the following
table. After receiving the message from UMPS, the Acquirer can refill the fields as per its system requirements. For
example, F11 can be refilled to make sure that the combination of F32, F33, F7, and F11 is unique in the system.
UMPS will forward Field 55 ICC data if it is a chip transaction. It may be processed by GSCS in conditions including
but not limited to a token-based transaction where the chip information is issued by UPI. It may be returned by the
Issuer or GSCS depending on which party processes the ICC data.
The QRC Voucher Number in Field 125 Usage QR is used to link the QRC-based Payment among all the systems, and
it shall be consistent in all the messages.
Table 229 Message Definition of Merchant-presented QRC-based Authorization

UPI CONFIDENTIAL 295

 Part II: Online Message

Merchant-presented QRC-based authorization request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
Message Type Identifier n4 0100 0110
bitmap b128 M M M M M M
2 primary_acct_num n..19(LLVAR) M M  M  
3 processing_code n6 M M  M  
4 amt_trans n12 M M  M  
6 amt_cdhldr_bil n12 C15+ C15+ 
7 transmsn_date_time n10(MMDDhhmmss) M M  M  
10 conv_rate_cdhldr_bil n8 C15+ C15+ 
11 sys_trace_audit_num n6 M M  M  
12 time_local_trans n6(hhmmss) M M  M  
13 date_local_trans n4(MMDD) M M  M  
14 date_expr n4(YYMM) O O  M  
15 date_settlmt n4(MMDD) M+ M  
18 mchnt_type a
n4 M M  M  
19 mchnt_cntry_code b n3 M M  M  
22 pos_entry_mode_codec n3 M M 
23 card_seq_id n3 C51   C0  
25 pos_cond_code n2 M M  M  
26 pos_pin_captr_code n2 C8 C8 
28 amt_trans_fee d x+n8 C6
32 acq_inst_id_code an..11(LLVAR) M M  M  
33 fwd_inst_id_code an..11(LLVAR) M M  M  
35 track_2_data z..37(LLVAR) C1 C1 
36 track_3_data z..104(LLLVAR) C2 C2 
37 retrivl_ref_num an12 M  M  
38 authr_id_resp an6 C3  
39 resp_code an2 M  
41 card_accptr_termnl_ide ans8 O M  M  
42 card_accptr_idf ans15 M M  M  
43 card_accptr_name_loc g
ans40 M M 

UPI CONFIDENTIAL 296

 Part II: Online Message

Merchant-presented QRC-based authorization request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
44 addtnl_resp_code ans..25(LLVAR) O C0- 
45 track _1_data z..79(LLVAR) C70 C70 
48 addtnl_data_private h ansb..512(LLLVAR) C22 C22 
49 currcy_code_trans an3 M M  M  
51 currcy_code_cdhldr_bil an3 C15+ C15+ 
52 pin_data b64 C7 C7 
53 sec_relatd_ctrl_info n16 C8 C8 C16
54 addtnl_amt an..040(LLLVAR) O  
55 ICC_data ansb..255(LLLVAR) C  C C C 
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage PR ans..512 C C 
57 issr_addtnl_data ans..100(LLLVAR) C22 C 
60 reserved i ans..100(LLLVAR) C Refer to Section 3.47.6 for 
transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C16 C16  
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage TK ansb..96 Refer to Section 3.50.3 for 
transmission requirements.
usage MQ ansb..512 C
100 rcvg_inst_id_code an..11(LLVAR) M+ M  
104 trans_industry_app_inf ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage AI ans..173 C C C
usage CD ans..241 C C C
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage VA ansb..190 C C
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage ML j ans47 C C C

UPI CONFIDENTIAL 297

 Part II: Online Message

Merchant-presented QRC-based authorization request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
121 national_sw_resved ans..100(LLLVAR) O C0 C16 
122 acq_inst_resvd ans..100(LLLVAR) O O C0- C0+ 
123 issr_inst_resvd ans..100(LLLVAR) O C0- 
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage CA ans..60 C
usage CV ans8 C C C
usage QR ansb..120 C C C C 
usage IP ansb..138 C  C
128 msg_authn_code b64 C9 C9 C9 C9 C9 C9
Note a: F18 can be captured from the Merchant-presented QRC.
Note b: F19 can be captured from the Merchant-presented QRC, and shall be present in the numeric format.
Note c: The first and second bytes of F22 shall be filled with “94” when the chip information is not present.
Note d: F28 can be filled with the value of tip or convenience fee if applicable.
Note e: F41 may be captured from the Merchant-presented QRC.
Note f, g: F42 and F43 can be captured from the Merchant-presented QRC.
Note h: F48 Usage AA shall be filled by the Acquirer in the message to GSCS to indicate whether the
authorization transaction is fixed-amount or estimated amount.
Note i: The transmission requirement of F60 in the messages between UMPS and the Acquirer is the same as
that between the Acquirer and GSCS.
Note j: The merchant local name of F117 Usage ML may be captured from the Merchant-presented QRC.

4.11.1.3 Cash Withdrawal

The definitions of Merchant-presented QRC-based Cash Withdrawal messages among the Acquirer, GSCS, and the
Issuer are the same as those of bankcard cash withdrawal messages except for the following fields:
• F22= 94
• F60.2.5= 01
• F60.3.6= 5
• F125 Usage QR, please refer to Section 3.64.5.3 for its transmission requirements.
The transmission requirements of message fields are described in the following table. After receiving the message
from UMPS, the Acquirer can refill the fields as per its system requirements. For example, F11 can be refilled to
ensure that the combination of F32, F33, F7, and F11 is unique in the system. Field 125 Usage QR tag 02 QRC Voucher
Number shall remain consistent in all messages to link the QRC-based Payment among different systems.
Table 230 Message Definition of Merchant-presented QRC-based Cash Withdrawal

UPI CONFIDENTIAL 298

 Part II: Online Message

Merchant-presented QRC-based cash withdrawal request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
Message Type n4 0200 0210
Identifier
bitmap b128 M M M M M M
2 primary_acct_num n..19(LLVAR) M M  M  
3 processing_code n6 M M  M  
4 amt_trans n12 M M  M  
5 amt_settlmt n12 C14+ C14+ 
6 amt_cdhldr_bil n12 C15+ C15+ 
7 transmsn_date_time n10(MMDDhhmmss) M M  M  
9 conv_rate_settlmt n8 C14+ C14+ 
10 conv_rate_cdhldr_bil n8 C15+ C15+ 
11 sys_trace_audit_num n6 M M  M  
12 time_local_trans n6(hhmmss) M M  M  
13 date_local_trans n4(MMDD) M M  M  
14 date_expr n4(YYMM) O O  M  
15 date_settlmt n4(MMDD) M+ M  
16 date_conv n4(MMDD) C14+ C14+ 
18 mchnt_type n4 M M  M  
19 mchnt_cntry_code n3 M M  M  
22 pos_entry_mode_code n3 M M 
25 pos_cond_code n2 M M  M  
26 pos_pin_captr_code n2 M 
28 amt_trans_fee x+n8 C6 C6+  O C 
32 acq_inst_id_code an..11(LLVAR) M M  M  
33 fwd_inst_id_code an..11(LLVAR) M M  M  
37 retrivl_ref_num an12 M  M  
38 authr_id_resp an6 O  
39 resp_code an2 M  
41 card_accptr_termnl_id ans8 O M  M  
42 card_accptr_id ans15 M M  M  

UPI CONFIDENTIAL 299

 Part II: Online Message

Merchant-presented QRC-based cash withdrawal request/response

Field Data Element Data Type Transmission Requirement
UMPS AC GSCS IS GSCS AC
AC GSCS IS GSCS AC UMPS
43 card_accptr_name_loc ans40 M M 
44 addtnl_resp_code ans..25(LLVAR) O C0- 
49 currcy_code_trans an3 M M  M  
50 currcy_code_settlmt an3 C14+ C14+ 
51 currcy_code_cdhldr_bil an3 C15+ C15+ 
52 pin_data b64 M 
53 sec_relatd_ctrl_info n16 M C16
54 addtnl_amt an..040(LLLVAR) O  
56 par ans..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage PR ans..512 C C 
57 issr_addtnl_data ans..100(LLLVAR) O C 
60 reserved ans..100(LLLVAR) C Refer to Section 3.47.6 for 
transmission requirements.
61 ch_auth_info ans..200(LLLVAR) C6 C6 C16 C16  
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage TK ansb..96 Refer to Section 3.50.3 for 
transmission requirements.
usage MQ ansb..512 C
100 rcvg_inst_id_code an..11(LLVAR) M+ M  
117 natl_region_info ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage ML ans47 C C C
121 national_sw_resved ans..100(LLLVAR) O C0 C16 
122 acq_inst_resvd ans..100(LLLVAR) O O C0- C0+ 
123 issr_inst_resvd ans..100(LLLVAR) O C0- 
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage CA ans..60 C
usage QR ansb..120 C C C C 
128 msg_authn_code b64 C9 C9 C9 C9 C9 C9

UPI CONFIDENTIAL 300

 Part II: Online Message

4.11.1.4 Refund, Reversal, Cancellation

The message definitions of Merchant-presented QRC-based reversal and cancellation transactions are the same as
those of bankcard transactions. The message definition of Merchant-presented QRC-based refund transactions is the
same as that of bankcard transactions except for the following field:
• F125 Usage QR, refer to Section 3.64.5.3 for its transmission requirements.
4.11.1.5 Transaction Result Inquiry
When UMPS does not receive the response message from the Acquirer, UMPS will send a transaction result inquiry
message with F70 valued “810” to the Acquirer to check the payment outcome.
In the response message of transaction result inquiry, only the Response Code Of Merchant-presented Payment
Result (tag 99) in Field 63 Usage MQ is present and filled with the response code of payment transaction if the
Acquirer receives the response code “00”.
In the transaction result inquiry messages, only the QRC voucher number (tag 02) in Field 125 Usage QR is present,
while other tags must not be present.
If the Acquirer has not obtained the transaction result yet, it can respond to UMPS with the response code “98”
(timeout), and then UMPS can re-initiate the transaction result inquiry within a certain time period.
Table 231 Message Definition of Merchant-presented QRC-based Transaction Result Inquiry

Merchant-presented QRC-based transaction result inquiry request/response

Field Data Element Data Type Transmission Requirement
UMPS AC
AC UMPS
Message Type Identifier n4 0600 0610
bitmap b128 M M
7 transmsn_date_time n10(MMDDhhmmss) M M
11 sys_trace_audit_num n6 M M
32 acq_inst_id_code an..11(LLVAR) M M
33 fwd_inst_id_code an..11(LLVAR) M M
39 resp_code an2 M
57 issr_addtnl_data ans..100(LLLVAR) C
63 finacl_net_data ansb..512(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage MQ ansb..512 C
70 netwk_mgmt_info_code n3 M M
125 risk_asse_info, ansb..256(LLLVAR) Refer to transmission requirements of usage(s)
below.
usage QR ansb..120 M M

Message Definition for Customer-presented QRC-based Payment Transaction

The transmission requirements of a Consumer-presented QRC-based Payment transaction, including the purchase,

UPI CONFIDENTIAL 301

 Part II: Online Message
authorization, and its subsequent cancellation, reversal, and refund messages, are the same as those of a bankcard
POS transaction. The following fields shall be paid attention to when Consumer-presented QRC-based Payment
transaction is carried out.
• F22= 03X/ 04X
• F55
• F60.3.6= 05
• F125 Usage QR, please refer to Section 3.64.5.3 for its transmission requirements.

4.12 Message Definition for U-plan Payment Coupon Management Transaction

Coupon Write-off Transaction
A successful coupon write-off transaction is required before the processing of a U-plan purchase transaction.
In the coupon write-off message, if the coupon has been successfully written off, tag 02 Cost Amount (After Discount)
and tag 03 Amount of Discount in Field 113 Usage VA shall be returned in the response message, and tag 04 Note
can be present in the response message to be printed in the remark column.
Table 232 Message Definition of Coupon Write-off Transaction

Coupon write-off request/response

Field Data Element Data Type Transmission Requirement
AC SW U-plan SW
SW U-plan SW AC
Message Type Identifier n4 0200 0210
bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code a
n6 M  M 
4 amt_trans b n12 M  M 
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
22 pos_entry_mode_code n3 M 
25 pos_cond_code c n2 M  M 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M 

UPI CONFIDENTIAL 302

 Part II: Online Message

Coupon write-off request/response

Field Data Element Data Type Transmission Requirement
AC SW U-plan SW
SW U-plan SW AC
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M 
49 currcy_code_trans an3 M  M 
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
113 addtnl_info ansb..512(LLLVAR) Refer to transmission requirements of
usage(s) below.
usage VA ansb..190 M  M 
tag 01 ans..19 M  M 
tag 02 n12 C 
tag 03 n12 C 
tag 04 ansb..120 O 
128 msg_authn_code d b64 C9 C9 C9 C9
Note a: F3 is filled with “00x000” where “x” is a 1-byte digit representing the actual account type, please refer
to Section 3.5 Field 3 Processing Code for details.
Note b: F4 is filled with the original transaction amount.
Note c: F25 is filled with 63.
Note d: F128 should be present if MAC is supported by the Acquirer.

Coupon Reversal Transaction

In the case of a purchase transaction failure, purchase transaction timeout, or a cancelled purchase transaction for
U-plan payment, the used coupon shall be reset to the unused status by initiating the coupon reversal transaction.
Table 233 Message Definition of Coupon Reversal Transaction

Coupon reversal request/response

Field Data Element Data Type Transmission Requirement
AC SW SW U-plan
SW AC U-plan SW
Message Type Identifier n4 0420 0430 0420 0430
Bitmap b128 M M M M
2 primary_acct_num n..19(LLVAR) M  M 
3 processing_code a n6 M  M 
4 amt_trans b n12 M  M 

UPI CONFIDENTIAL 303

 Part II: Online Message

Coupon reversal request/response

Field Data Element Data Type Transmission Requirement
AC SW SW U-plan
SW AC U-plan SW
7 transmsn_date_time n10(MMDDhhmmss) M  M 
11 sys_trace_audit_num n6 M  M 
12 time_local_trans n6(hhmmss) M  M 
13 date_local_trans n4(MMDD) M  M 
15 date_settlmt n4(MMDD) M+ M 
18 mchnt_type n4 M  M 
22 pos_entry_mode_code n3 M M
25 pos_cond_code c n2 M  M 
32 acq_inst_id_code an..11(LLVAR) M  M 
33 fwd_inst_id_code an..11(LLVAR) M  M 
37 retrivl_ref_num an12 M  M 
39 resp_code an2 M M
41 card_accptr_termnl_id ans8 M  M 
42 card_accptr_id ans15 M  M 
43 card_accptr_name_loc ans40 M
49 currcy_code_trans an3 M  M 
90 orig_data_elemts n42 M M
100 rcvg_inst_id_code an..11(LLVAR) M+ M 
128 msg_authn_code d b64 C9 C9 C9 C9
Note a: F3 is filled with “00x000” where “x” is a 1-byte digit representing the actual account type, please refer
to Section 3.5 Field 3 Processing Code for details.
Note b: F4 is filled with the original transaction amount.
Note c: F25 is filled with 63.
Note d: F128 should be present if MAC is supported by the Acquirer.

4.13 Message Definition for Staged Digital Wallet Operator (SDWO) Transaction
Message Definition for SDWO Wallet Loading Transaction
4.13.1.1 Account Funding
Field 104 Usage WI is added to the message definition of account funding transaction to support wallet loading.
Field 43 shall be filled with the wallet name in wallet loading (F104 Usage BI = “10”).

UPI CONFIDENTIAL 304

 Part II: Online Message

4.13.1.2 Reversal
The message definition of reversal for SDWO transactions is the same as that of reversal for general transactions.
4.13.1.3 Refund (Online)
Field 104 Usage WI is added to the definition of the refund (online) message to support SDWO transactions. Field
104 Usage WI shall be filled by the Acquirer if the refund (online) message is used for SDWO transactions. In the
advice message of SDWO refund transactions for the Issuer, GSCS will forward or intercept this usage based on the
Issuer’s choice.

Message Definition for SDWO Balance-to-bankcard Transfer Transaction

4.13.2.1 Primary Credit
Field 104 Usage WI is added to the message definition of online primary credit transaction to support balance-to-
bankcard transfer.
Field 43 shall be filled with the wallet name in balance-to-bankcard transfer (F104 Usage BI = “10”).
4.13.2.2 Primary Credit Confirmation
Field 104 Usage WI is added to the message definition of primary credit confirmation transaction to support balance-
to-bankcard transfer.
Field 43 shall be filled with the wallet name in balance-to-bankcard transfer (F104 Usage BI = “10”).

Message Definition for SDWO Back-to-back Purchase Transaction

4.13.3.1 Purchase, Recurring, Pre-authorization
Field 104 Usage WI is added to the message definition of purchase, recurring, and pre-authorization transactions to
support back-to-back purchase for single-message Members. Field 104 Usage WI shall be filled by the Acquirer if the
transaction message is used for back-to-back purchase. In the request message of SDWO transactions sent to the
Issuer, GSCS will forward or intercept this usage based on the Issuer’s choice.
4.13.3.2 Financial Cancellation
The message definition of financial cancellation for SDWO transactions is the same as that of financial cancellation
for general transactions.
4.13.3.3 Reversal
The message definition of reversal for SDWO transactions is the same as that of reversal for general transactions.
4.13.3.4 Pre-authorization Completion, Settlement Advice
The message definition of pre-authorization completion and settlement advice for SDWO transactions is the same as
that of pre-authorization completion and settlement advice for general transactions.
4.13.3.5 Refund (Online)
Field 104 Usage WI is added to the definition of the refund (online) message to support SDWO transactions. Field
104 Usage WI shall be filled by the Acquirer if the refund (online) message is used for SDWO transactions. In the
advice message of SDWO refund transactions sent to the Issuer, GSCS will forward or intercept this usage based on
the Issuer’s choice.
4.13.3.6 Authorization, Authorization Cancellation, Authorization Cancellation Reversal
Field 104 Usage WI is added to the message definition of authorization to support back-to-back purchase for dual-
message Members. Field 104 Usage WI shall be filled by the Acquirer if the original transaction message is used for
back-to-back purchase. In the request message of SDWO transactions sent to the Issuer, GSCS will forward or

UPI CONFIDENTIAL 305

 Part II: Online Message

intercept this usage based on the Issuer’s choice.

The message definition of subsequent authorization cancellation and reversal for back-to-back purchase is the same
as that for general transactions.

UPI CONFIDENTIAL 306