Technical Specifications on Bankcard Interoperability

Part I Transaction Processing

Version 22.2

April 2022
THIS PAGE IS INTENTIONALLY LEFT BLANK.
 Part I: Transaction Processing

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 I: Transaction Processing

Table of Contents
ABOUT THIS DOCUMENT ...................................................................................................................................... IV
SUMMARY OF REVISIONS ..................................................................................................................................... VI
TERMS AND DEFINITIONS ....................................................................................................................................VII
1 GENERAL TRANSACTION PROCESSING............................................................................................................ 1
1.1 TRANSACTION CATEGORY .....................................................................................................................................1
1.2 GENERAL PROCESSING OF ONLINE TRANSACTION ......................................................................................................1
1.3 GENERAL PROCESSING OF OFFLINE TRANSACTION .....................................................................................................4
1.4 GENERAL PROCESSING OF MANUAL TRANSACTION ....................................................................................................4
1.5 PROCESSING OF BATCH TRANSACTION .....................................................................................................................6
1.6 PROCESSING OF DUAL-MESSAGE FINANCIAL TRANSACTION .........................................................................................6
2 TRANSACTION SWITCHING ............................................................................................................................. 8
2.1 SINGLE-MESSAGE TRANSACTION PROCESSING...........................................................................................................8
2.2 DUAL-MESSAGE TRANSACTION PROCESSING...........................................................................................................21
2.3 MANUAL TRANSACTION PROCESSING ...................................................................................................................23
2.4 PROCESSING OF IC CARD TRANSACTION BASED ON UICS DEBIT/CREDIT STANDARD ......................................................27
2.5 BATCH TRANSACTION PROCESSING .......................................................................................................................30
2.6 TIMEOUT SETTING RULES FOR GENERAL TRANSACTION ............................................................................................33
3 STAND-IN AUTHORIZATION TRANSACTION PROCESSING .............................................................................. 34
3.1 OVERVIEW OF STAND-IN AUTHORIZATION TRANSACTION ..........................................................................................34
3.2 STAND-IN AUTHORIZATION TRANSACTION PROCESSING FLOW ...................................................................................34
3.3 TRANSMISSION OF STAND-IN AUTHORIZATION TRANSACTION LOG ..............................................................................35
4 STAND-IN AUTHORIZATION PARAMETER ADVICE TRANSACTION PROCESSING ............................................. 37
4.1 OVERVIEW ......................................................................................................................................................37
4.2 STAND-IN AUTHORIZATION PARAMETER ADVICE TRANSACTION PROCESSING FLOW .......................................................37
5 PAYMENT TOKEN TRANSACTION PROCESSING ............................................................................................. 38
5.1 PAYMENT TOKEN TRANSACTION PROCESSING PRINCIPLE ..........................................................................................38
5.2 PAYMENT TOKEN TRANSACTION PROCESSING FLOW ................................................................................................38
5.3 PAYMENT TOKEN TRANSACTION TYPE ...................................................................................................................38
6 QRC-BASED PAYMENT TRANSACTION PROCESSING ...................................................................................... 41
6.1 MERCHANT-PRESENTED QRC-BASED PAYMENT TRANSACTION PROCESSING .................................................................41
6.2 CONSUMER-PRESENTED QRC-BASED PAYMENT TRANSACTION PROCESSING .................................................................43
7 U-PLAN PAYMENT COUPON MANAGEMENT TRANSACTION PROCESSING .................................................... 44
8 STAGED DIGITAL WALLET PAYMENT TRANSACTION PROCESSING ................................................................. 45
8.1 OVERVIEW OF STAGED DIGITAL WALLET PAYMENT ..................................................................................................45
UPI CONFIDENTIAL II
 Part I: Transaction Processing

8.2 PROCESSING FLOW OF STAGED DIGITAL WALLET PAYMENT .......................................................................................45

9 CLEARING AND SETTLEMENT TRANSACTION PROCESSING ........................................................................... 48
9.1 GSCS CUTOFF ADVICE TRANSACTION (0820/0830) PROCESSING .............................................................................48
9.2 SELF-ADMINISTERED CLEARING/SETTLEMENT TRANSACTION PROCESSING....................................................................48
9.3 TIME SEQUENCE OF GSCS CLEARING AND SETTLEMENT ...........................................................................................49
10 DISPUTE RESOLUTION TRANSACTION PROCESSING .................................................................................. 51
10.1 DESCRIPTION OF DISPUTE RESOLUTION TRANSACTION .............................................................................................51
10.2 DISPUTE PROCESSING OF DOMESTIC/CROSS-BORDER TRANSACTIONS .........................................................................52
11 MANAGEMENT AND SECURITY CONTROL TRANSACTION PROCESSING .................................................... 54
11.1 NETWORK MANAGEMENT ADVICE TRANSACTION (0820/0830) ...............................................................................54
11.2 KEY RESET APPLICATION (0820/0830) AND KEY RESET (0800/0810) ......................................................................55
12 ABNORMALITY TRANSACTION PROCESSING ............................................................................................. 57
12.1 OVERVIEW ......................................................................................................................................................57
12.2 RULES OF ABNORMALITY PROCESSING ..................................................................................................................57
12.3 MESSAGE FORMAT ERROR ..................................................................................................................................57
12.4 DATA SECURITY CONFIDENTIALITY ERROR ..............................................................................................................58
12.5 COMMUNICATION ABNORMALITIES ......................................................................................................................60
12.6 TERMINAL OPERATION ERROR .............................................................................................................................71
12.7 TRANSACTION ABNORMALITIES PROCESSING FLOW .................................................................................................72

UPI CONFIDENTIAL III

 Part I: Transaction Processing

About this Document

Purpose
The Technical Specifications on Bankcard Interoperability - Part I Transaction Processing is one of the six parts
comprising the Technical Specifications on Bankcard Interoperability. The document specifies the requirements on
processing procedures of various online transactions in the UPI inter-bank switching network, covering processing
procedures of bankcard transaction, dispute transactions, clearing and settlement, and transaction abnormalities.
Audience
The audience of this document are UnionPay International (UPI) staff and UPI Members who have adopted message
format version 2.1 (the message format version is indicated in the online message header).

Document Version
Version 22.2 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.

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 IV
 Part I: Transaction Processing

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 V
 Part I: Transaction Processing

Summary of Revisions
Description of Changes Location
Added a section on U-plan Payment Coupon Management 7 U-plan Payment Coupon Management
Transaction Processing. Transaction Processing

UPI CONFIDENTIAL VI
 Part I: Transaction Processing

Terms and Definitions

The following terms and definitions apply to this document.
Terms Definition
Acquirer The party who accepts the transaction (the party where the terminal is located).
The Acquirer is responsible for generating and routing the online transaction
information, as well as collecting, processing and submitting settlement data.
Advice Messages sent to relevant parties to inform them of the actions that have
already taken place, without requiring approval.
ARPC (Authorization ARPC is the abbreviation of Authorization Response Cryptogram. It is the
Response Cryptogram) application cryptogram generated by the Issuer and returned to the terminal in
an online authorization message, and is used to verify whether online
authorization response comes from the real Issuer.
Bank Card A credit payment tool issued to the public by financial institutions like
commercial banks and postal saving and remitting institutions, with all or part of
the following functions: consumption credit, transfer settlement, cash deposit
and withdraw, etc.
CDRS An Internet-based service platform provided by UPI to Members. The platform is
capable of providing functions such as dispute and report services that are
connected with switching operations.
GSCS GSCS is responsible for switching of inter-bank bankcard transactions and
collection, clearing and distribution of settlement data.
De-tokenization The process of redeeming a Payment Token for its associated PAN value based
on the Payment Token to PAN mapping, whilst performing required verification
of the Payment Token and enforcing the Token Domain Restriction Controls
associated with the Payment Token.
Dual Message A transaction mode where the Acquirer first submits an authorization request to
the Issuer, and then submits settlement information to the Issuer collectively in
the form of presentment file sometime afterwards.
Dual Message Transaction A transaction that is transmitted twice. It is transmitted firstly for authorization
only, which is processed in real time, and then for clearing and settlement, which
is not processed in real time.
EMV Standard EMV is the acronym of EUROPAY, MASTERCARD, and VISA. The IC card
debit/credit application standards that are jointly constituted by these three
companies are abbreviated to EMV Standards.
IC Card Debit/Credit It refers to the application protocols and related data set between the financial
Application based on UICS IC card and the terminal to implement debit/credit function. It is applicable to
Debit/Credit Standard transaction processing between the financial IC card with financial debit/credit
account issued by banks and various terminals supporting the application.
IC Card E-cash Application It refers to the application protocols and related data set based on UICS
(Low-value Payment debit/credit application to implement low-value payment function. It is
Application) based on UICS applicable to transaction processing between the financial IC card with low-value
Debit/Credit Standard payment function issued by banks and various terminals supporting the
application.

UPI CONFIDENTIAL VII

 Part I: Transaction Processing

Terms Definition
Identification and A validation method to validate the Cardholder and the Cardholder’s account in
Verification order to establish a credibility level for Payment Token to PAN binding.
Issuer The party where the Cardholder opens an account (i.e. the party that performs
authorization). Usually, the Issuer and its headquarter or regional center are
called Issuer together.
Issuer Identification Mode The Issuer shall verify the Cardholder’s identity information before conducting
relationship establishment transactions for card-not-present self-service
purchase, pre-authorization, and recurring.
The Issuer identification mode can be divided into Issuer autonomous
identification mode and Issuer assisting identification mode.
The Issuer autonomous identification mode requires the Issuer to send one-time
password (OTP) to the Cardholder’s cell phone (or commission UPI to send and
verify the OTP), and then the Cardholder will submit the OTP via the transaction
interface to the Issuer for verification.
The Issuer assisting identification mode requires the Cardholder to submit the
verification code via the transaction interface for verification by the Issuer.
MO/TO It is the abbreviation of Mail Order/Telephone Order. In this document, it refers
to the process where the holder of UnionPay Credit Card confirms the purchase
of commodities or services through telephone, mail, e-mail or another non-face-
to-face method. The Merchant initiates the debit request and completes the
payment procedure.
Payment Token A surrogate value for a PAN, usually a 13- to 19-digit numeric value, which must
meet basic validation rules of an account number, including the Luhn check digit.
In a transaction message, the Payment Token is submitted in lieu of the PAN and
the Token Expiry Date is submitted in lieu of PAN Expiry Date to improve
transaction security.
Pre-authorization The payment acknowledgement or guarantee from the Issuer to the agency.
Recurring A recurring transaction refers to a transaction initiated by a Merchant that is
authorized by a Cardholder in an agreement to make the payment for some
services on behalf of the Cardholder with the his/her Credit Card and submit the
transaction information (or batch file) to its Acquirer on a regular basis through
the acquiring platform, terminals or other applicable systems.
Request A message that generates a series of interactive messages.
Response Code A code that indicates the processing result returned to the sender after the
receiver receives the request or advice.
Reversal A special transaction initiated by the message sender, and used to inform the
receiver that the previous authorization or financial transaction is not completed
according to the predefined procedure and the corresponding result shall be
cancelled.
Staged Digital Wallet A transaction initiated by Staged Digital Wallet Operator, which includes wallet
Operator Transaction loading, balance-to-bankcard transfer and back-to-back purchase.
(SDWO Transaction)

UPI CONFIDENTIAL VIII

 Part I: Transaction Processing

Terms Definition
Settlement The whole process of calculating and submitting the net amount of transaction
data based on clearing result, and completing the fund transfer between
Members.
Single Message A transaction mode where the Acquirer submits transaction information to the
Issuer, and then GSCS does the settlement based on the log. The Acquirer does
not need to submit presentment files.
Single Message Transaction A transaction that is transmitted only once for authorization, clearing and
settlement, and is also called a comprehensive financial transaction, i.e.
authorization, clearing, and settlement all take place online.
Store and Forward The sender stores the message in the store and forward queue, and sends it
repeatedly at intervals within certain periods of times.
Token Assurance Level A value that allows the Token Service Provider to indicate the confidence level of
the Payment Token to PAN/Cardholder binding. It is determined by the type of
Identification and Verification (ID&V) performed and the entity that performed
it. It may also be subject to additional factors such as the Token Location. The
Token Assurance Level is set when a Payment Token is issued and may be
updated if additional ID&V is performed. The Token Assurance Level value is
defined by the Token Service Provider.
Token BIN A specific BIN or range within a BIN that has been designated only for the
purpose of issuing Payment Tokens and is flagged accordingly in BIN tables.
Token Domain The types of transactions for which a Payment Token may be used. Token
Domains may be channel-specific (e.g., NFC only), Merchant-specific, digital
wallet-specific, or a combination of any of the above.
Token Location An indication of the intended mode of storage for a Payment Token and any
related data, provided by a Token Requestor when requesting a Payment Token
from a Token Service Provider. The security of this location may influence the
Token Assurance Level that can be assigned to a Payment Token. Due diligence of
the security provided by Token Requestors is the responsibility of Token Service
Provider and assignation of a location type to Token Requestor will be at the
discretion of Token Service Provider.
Token Requestor (TR) An entity submitting Token Requests to the Token Service Provider. A Payment
Token Requestor may be a traditional participant within the payment industry or
a newly emerging participant. Potential Token Requestors include, but are not
limited to:
• Card-on-File Merchants
• Acquirers, Acquirer processors, and payment gateways on behalf of
Merchants
• Payment enablers, such as mobile device manufacturers or chip
manufacturers
• Digital wallet operators
• Card Issuers
A Token Requestor is required to register with the Token Service Provider and
follow the provider’s management standards, technical specifications, and

UPI CONFIDENTIAL IX
 Part I: Transaction Processing

Terms Definition
registration processes. After successful registration with a Token Service
Provider, the Token Requestor will be assigned a Token Requestor ID or multiple
Token Requestor IDs for different Token Domains.
Token Service Provider Token Service Providers are responsible for a number of discrete functions in
(TSP) their capacity as the authorized party for issuance of Payment Tokens. These
responsibilities include, but are not limited to:
• Ongoing operation and maintenance of the Token Vault
• Payment Token generation and issuance
• Application of security and controls
• Payment Token provisioning
• Token Requestor registration functions
Token Service Providers are responsible for building and managing their own
proprietary Token Requestor APIs, Token Vaults, Token provisioning platforms,
and Token registration. Token Service Providers must ensure that Token BINs or
Token BIN ranges are managed distinctly from traditional BINs or BIN ranges in
order to avoid any inadvertent overlap of PANs and Payment Tokens.
Transaction A set of relevant information that achieves the intention of original information
introducer, and usually it ends with a debit or credit message. The related
revision or cancellation can be considered as an independent transaction.
Transfer-in The party into which fund is transferred in a fund transfer transaction.
Transfer-out The party which transfers the fund to the other party in a fund transfer
transaction
UICS Standards UICS is the core chip migration program of UPI. It specifically refers to the
UnionPay Integrated Circuit Card Specifications which is highly compliant to EMV
and ISO standards.

UPI CONFIDENTIAL X
 Part I: Transaction Processing

1 General Transaction Processing

1.1 Transaction Category
Transactions can be divided into online transactions, manual transactions, offline transactions and batch transactions
according to different transaction processing flows. Online transactions are carried by online messages that can be
categorized into request messages and advice messages based on whether approval by the transaction recipient is
necessary for transaction completion. Authorization messages and financial transaction messages can be divided
into single messages and dual messages based on the message processing mode.
In this document, without special note, transactions refer to UnionPay card transactions by default.
As IC card has special business functions and transaction processes, special applications of IC card will be described
in a dedicated section hereinafter. Other bank cards are mainly based on magnetic stripe or other media (such as
biological characteristics or character), and share the same business functions and transaction processes; hence, no
separate statement will be given.
UPI provides stand-in authorized service for all Members. All related transaction processing procedures will be
described in a dedicated chapter of this document.
UPI provides Payment Token Service for Members. All related transaction processing procedures will be described in
a dedicated chapter of this document.

1.2 General Processing of Online Transaction

Message types supported by GSCS include:
Table 1 Classification of Message Types Supported by GSCS

Message Type Identifier Message Type Definition

01XX Authorization messages
02XX Financial transaction messages
04XX Reversal messages
05XX Reconciliation control messages
06XX Administrative messages
08XX Network management messages
The above messages can be classified into two types: request message and advice message.

1.2.1 Request and Advice Messages

1.2.1.1 Request Messages
The request message is sent from the requesting party (e.g. the Acquirer) to the receiver (e.g. the Issuer) to inform
the receiver that a transaction is in progress and response must be sent back after completion of the transaction.
After receiving the transaction request, the receiver should directly give the response of approving or refusing the
transaction. If the receiver is not the final receiving institution of the transaction, it is responsible for forwarding the
transaction to the next institution.
The request message includes:
• Authorization messages: Authorization/Pre-authorization request/request response (0100/0110)
• Financial transaction messages: Financial transaction request/request response (0200/0210)
• Administrative messages: Foreign exchange rate inquiry request/request response (0600/0610)

UPI CONFIDENTIAL 1
 Part I: Transaction Processing

• Network management messages: Network management request/request response (0800/0810)

Note: GSCS does not support automatically re-sending of request message.
1.2.1.2 Advice Messages
The advice message generally refers to a transaction message in which the sender informs the receiver of an action
the sender has taken and the sender requests no authorization but a response. The advice message described in this
document can be sent out by the Acquirer, the Issuer and GSCS, and the receiver of the transaction should give a
response accordingly. If the receiver is not the final receiving institution of the transaction, it is responsible for
forwarding the transaction to the next institution after giving a response to the sender.
The advice message includes:
• Financial transaction messages: Financial transaction advice/advice response (0220/0230)
• Reversal advice messages: Reversal advice/advice response (0420/0430)
• Administrative messages: UICS Issuer script result advice/advice response (0620/0630)
• Network management messages: Network management advice/advice response (0820/0830)
The normal processing flow of request message is divided into two types: switching via GSCS and direct processing
by GSCS. The descriptions of the two types are as follows.

1.2.2 Normal Processing Flow of Request Message

1.2.2.1 Switching via GSCS

1 2

Acquirer GSCS Issuer

4 3

Figure 1 Normal Processing Flow Description of Request Message – Switching via GSCS

1. Request sent to GSCS from the Acquirer;

2. Request forwarded to the Issuer by GSCS;
3. Request response sent to GSCS from the Issuer;
4. Request response forwarded to the Acquirer by GSCS.

UPI CONFIDENTIAL 2
 Part I: Transaction Processing

1.2.2.2 Direct Processing by GSCS

Sender Receiver

Figure 2 Normal Processing Flow of Request Message- Direct Processing by GSCS

1. Request sent to the receiver by the sender;
2. Request response sent to the sender by the receiver.

1.2.3 Exception Processing Flow of Request Message

For detailed information, please refer to Section 11 Abnormalities Transaction Processing Flow.

1.2.4 Normal Processing Flow of Advice Message

The normal processing flow of advice message is divided into two types: switching via GSCS and direct processing by
GSCS. The description of the two types are as follows.
1.2.4.1 Switching via GSCS

2
Acquirer GSCS Issuer
3

Figure 3 Normal Processing Flow of Advice Message – Switching via GSCS

1. Advice sent to GSCS from the Acquirer;

2. Advice response sent to the Acquirer from GSCS;
3. Advice sent to the Issuer from GSCS;
4. Advice response sent to GSCS from the Issuer.

UPI CONFIDENTIAL 3
 Part I: Transaction Processing

1.2.4.2 Direct Processing by GSCS

Sender Receiver

Figure 4 Normal Processing Flow of Advice Message – Direct Processing by GSCS

1. Advice sent to the receiver from the sender;
2. Advice response sent to the sender from the receiver.

1.2.5 Store-and-forward Mechanism of Message Processing

The following situations may occur in a message processing flow:
1. The sender cannot send the message to the receiver;
2. The sender cannot receive the response from the receiver after sending the message.
In either of the two situations, the sender can store the message in the store-and-forward queue, and resend the
message at a certain interval until a preset number of times is reached. During this process, if the receiver is offline,
the sender should stop sending the message, and then restore message sending after the receiver is back online.
This store-and-forward process is only valid during the same “cut-off” day; once GSCS cuts off, the process will be
terminated. If funds discrepancy occurs between the sender and the receiver, it should be solved via dispute
resolution. This method is called store-and-forward mechanism.
The store-and-forward mechanism is normally used for sending certain advice messages.

1.3 General Processing of Offline Transaction

One type of offline transaction is approved or rejected directly by the terminal, i.e. offline purchase of the IC card
electronic cash application. The Acquirer will submit the presentment file or convert the offline purchase into an
online message after the transaction is completed in order to complete the transaction record of UPI and the Issuer
and the clearing process.
Another type of offline transaction refers to the transaction completed by file transfer. There is no online message
involved.
Currently the offline transaction mentioned in this document only refers to the first type, that is, the offline purchase
of the IC card electronic cash application and related information is provided in Section 2.4.2.

1.4 General Processing of Manual Transaction

1.4.1 Normal Processing Flow of Manual Transaction
Manual transactions refer to transactions initiated manually after the Member logs onto the CDRS. Manual
transactions can be divided into manual transactions with online message and manual transactions without online
message.

UPI CONFIDENTIAL 4
 Part I: Transaction Processing

1.4.1.1 Manual Transactions with Online Message

1 CDRS

Acquirer 2 Issuer

3
GSCS
4

Figure 5 General Processing Flow of Manual Transactions with Online Message

1. The Acquirer logs onto the CDRS to initiate a manual transaction;

2. CDRS informs GSCS of the manual transaction;
3. GSCS sends an online message to the Issuer (optional; and the message can be either request or advice);
4. The Issuer returns a response message (0110).
1.4.1.2 Manual Transactions without Online Message

1 CDRS

Acquirer 2 Issuer

3 GSCS 3

Figure 6 General Processing Flow of Manual Transactions without Online Message

1. The Acquirer logs onto the CDRS to initiate a manual transaction;
2. CDRS informs GSCS of the manual transaction;
3. After the cutoff, GSCS sends transaction details in audit trailer files or to the Issuer and the Acquirer for
reconciliation.
Note: In Step 3, different types of manual transactions will go into different types of audit trailer files. Please refer to
the detailed description of manual transaction types.

1.4.2 Exception Processing Flow of Manual Transaction

The exception processing flow of manual transactions with online messages is different from those of advice
messages and request messages. If the online message is an advice message, the exception processing flow is the
same as that described in Section 1.2.5. If the online message is a request message, the exception processing flow is
the same as that described in Section 1.2.3.

UPI CONFIDENTIAL 5
 Part I: Transaction Processing

This document does not specify exception processing flow for manual transactions without online message.

1.5 Processing of Batch Transaction

A batch transaction is a transaction that is initiated by the Acquirer through batch file to GSCS and processed and
forwarded to the Issuer by GSCS.

1.5.1 Normal Processing Flow of Batch Transaction

2
Acquirer GSCS Issuer
3
4
5

Figure 7 Normal Processing Flow of Batch Transaction

1. The Acquirer submits a batch file to GSCS;

2. GSCS uploads the file, checks its validity and sends a feedback file to the Acquirer;
3. GSCS sends an online message to the Issuer;
4. The Issuer responds via online message;
Repeat step 3 and 4 until the last transaction has been processed.
5. GSCS sends a transaction response file to the Acquirer.

1.5.2 Exception processing flow of Batch Transaction

In step 1, If GSCS received duplicated batch files sent by the Acquirer, the first file is regarded as valid, and the
duplicated files will be abandoned.
In step 2, if the Acquirer received duplicated batch files sent by GSCS, the first file is regarded as valid, and the
duplicated files will be abandoned.
In step 2, if GSCS cannot send the feedback file to the Acquirer, it will store and resend it for a maximum of 3 times.
For different batch transactions, steps 3& 4 may vary for exception processing flow. Please refer to Section 2.5 for
details.
In step 5, if the Acquirer received duplicated batch files sent by GSCS, the first file is regarded as valid; and the
duplicated files will be abandoned.
In step 5, if GSCS cannot send the batch file to the Acquirer, the transaction is still deemed as valid and will be settled.
The Acquirer shall proceed according to the information recorded in the audit trailer sent by GSCS
If GSCS still cannot send part of the file record in the format of online message to the Issuer within the time limit,
transactions in this part will be regarded as unsuccessful. GSCS will notify the Acquirer in the response file.

1.6 Processing of Dual-message Financial Transaction

The online processing flow of dual-message financial transactions is the same as that of single message financial

UPI CONFIDENTIAL 6
 Part I: Transaction Processing
transactions. After online authorization, the dual-message Acquirer needs to submit dual-message presentment files
to GSCS for settlement, and then GSCS distributes corresponding settlement files to the Acquirer and the Issuer (refer
to Technical Specifications on Bankcard Interoperability - Part III File Interface).

1 2

4 3
Acquirer GSCS Issuer
5

6 6

Figure 8 Processing Flow of Dual Message Financial Transaction

1. The Acquirer submits a transaction request to GSCS;
2. GSCS switches the Acquirer’s transaction request to the Issuer;
3. The Issuer sends a response to GSCS;
4. GSCS switches the Issuers’ response to the Acquirer;
5. The Acquirer uploads presentment files to GSCS via SFTP;
6. GSCS distributes settlement files to the Issuer and the Acquirer.

UPI CONFIDENTIAL 7
 Part I: Transaction Processing

2 Transaction Switching
2.1 Single-message Transaction Processing
2.1.1 Pre-authorization Transaction 0100/0110
Pre-authorization transaction is used by the Acquirer to confirm the Issuer’s approval of the Cardholder’s transaction.
The Acquirer takes the estimated purchase amount as the pre-authorization amount and sends it to the Cardholder’s
Issuer. After approving the transaction, the Issuer will put information, such as an authorization code, etc., into the
transaction response sent to the Acquirer. Pre-authorization transaction can be initiated by the Cardholder in the
self-service manner.
Pre-authorization transaction only controls the Cardholder’s available balance or credit. Funds settlement will be
accomplished by pre-authorization completion transaction. An approved pre-authorization transaction is only valid
within a specified timeframe.
This transaction is a request transaction that needs to be switched via GSCS. Please refer to Section 1.2.2.1 for details.
The transaction is not involved in settlement.
This transaction may trigger reversal advice. For the conditions to trigger reversal and its processing flows, please
refer to Section 2.1.10 Reversal Advice 0420/0430.

2.1.2 MO/TO Pre-authorization Transaction 0100/0110

MO/TO pre-authorization transaction refers to a purchase order initiated by the Cardholder through telephone, fax
or other agencies.
This transaction is a request transaction that needs to be switched via GSCS. Please refer to Section 1.2.2.1 for details.
The transaction is not involved in settlement.
This transaction may trigger reversal advice. For the conditions to trigger reversal and its processing flows, please
refer to Section 2.1.10 Reversal Advice 0420/0430.

2.1.3 Incremental Pre-authorization Transaction 0100/0110

UPI CONFIDENTIAL 8
 Part I: Transaction Processing

2.1.3.1 Normal Transaction Flow

Acquirer GSCS Issuer

1 2
1st
Pre-
authorization
4 3

5
F90= Key Field from the 6
Incremental
1st trx F90
Pre-
authorization
Use trx 8 7
context
from the 1st 9 10
trx F90= Key Field from the F90
Incremental 1st trx
Pre-
authorization 12 11

13
One completion for all trx 15
Pre- F38 from the 1st trx
authorization
Completion 14 16

Figure 9 Normal Processing Flow of Incremental Pre-authorization

1) The Acquirer checks the validity of the account information and other credentials of the Merchant, then sends the
payment request to GSCS if the information is valid.
2) GSCS forwards the pre-authorization request to the Issuer.
3) The Issuer returns the transaction outcome to GSCS.
4) GSCS returns the Incremental pre-authorization response to the Acquirer.
5) The Acquirer sends the Incremental pre-authorization request to GSCS with the key field of the 1 st pre-
authorization transaction filled in Field 90.
6) GSCS forwards the incremental pre-authorization request to the Issuer.
7) The Issuer shall associate the incremental pre-authorization with the 1st pre-authorization transaction. After
necessary processing, the Issuer returns the transaction outcome to GSCS.
8) GSCS returns the Incremental pre-authorization response to the Acquirer.
9) The Acquirer sends another Incremental pre-authorization request to GSCS with the key fields of the 1 st pre-
authorization transaction filled in Field 90.
10) GSCS forwards the Incremental pre-authorization request to the Issuer.
11) The Issuer shall associate the incremental pre-authorization with the 1st pre-authorization transaction and the
prior incremental pre-authorizations. After necessary processing, the Issuer returns the transaction outcome to GSCS.
12) GSCS returns the Incremental pre-authorization response to the Acquirer.
13) The Acquirer sends the pre-authorization completion advice to GSCS with Field 38 from the response of the first
transaction and the final amount accumulative of all the correlated pre-authorization and incremental pre-
authorizations.

UPI CONFIDENTIAL 9
 Part I: Transaction Processing

14) GSCS returns the pre-authorization completion response to the Acquirer.

15) GSCS forwards the pre-authorization completion advice to the Issuer. Upon receipt of the pre-authorization
completion advice, the Issuer must release the pre-authorization holds created by the 1st pre-authorization and all
the incremental pre-authorizations associated with it.
16) The Issuer returns the transaction outcome to GSCS.
Note:
1) The first pre-authorization determines the final transaction characteristics. All attributes (including the Merchant
attributes) associated with the original are inherited by the incremental pre-authorizations (i.e., whether a
transaction took place in a card present or card not present environment), Acquirers shall fill in these attributes with
the same value as that of the first pre-authorization message.
2) The Acquirer shall only send the pre-authorization completion advice transaction to GSCS, rather than the pre-
authorization completion request transaction.
3) The pre-authorization completion advice transaction shall be the completion of all transactions, rather than any
one of the incremental pre-authorizations.
2.1.3.2 Exceptional Flow
1. When the Acquirer does not receive the first pre-authorization/authorization response message within certain
time (25-40s), it shall initiate a reversal message. After reversing the first pre-authorization/authorization, the
corresponding incremental pre-authorization/authorizations shall not be initiated.
2. When the Acquirer does not receive the incremental pre-authorization/authorization response message within
certain time (25-40s), it shall initiate a reversal message to reverse the current incremental pre-
authorization/authorization. After reversing the current incremental pre-authorization/authorization, the first pre-
authorization/authorization is still valid, and the Acquirer can initiate other incremental pre-
authorization/authorization if necessary.
3. Store-and-forward will be adopted in case the Acquirer of the reversal advice cannot receive any response. But
reversal advice shall not be sent on another settlement day.
Note: The reversal of the incremental pre-authorization/authorization is only applicable to the current transaction,
rather than the entire transaction cycle.
2.1.3.3 Incremental Pre-authorization Cancellation and Refund
The message flows of Incremental Pre-authorization cancellation and refund are the same as that of POS purchase
cancellation and refund for Acquirers and Issuers.
Note: The cancellation transaction is only applicable to the total transaction cycle, which includes the original pre-
authorization and all related incremental pre-authorizations. After cancellation, the total transaction cycle is closed,
the Acquirer shall not initiate other incremental pre-authorization.

2.1.4 Pre-authorization Cancellation Transaction (Online) 0100/0110

For a successful pre-authorization, a pre-authorization cancellation is used to request the Issuer to cancel the
payment commitment within 30 days after pre-authorization and prior to initiating pre-authorization completion.
Pre-authorization cancellation must be a full-amount cancellation of the original pre-authorization.
This transaction is a request transaction switched via GSCS. Please refer to Section 1.2.2.1 for details.
This transaction is not involved in settlement.
This transaction may trigger reversal advice. For the conditions to trigger reversal and its processing flows, please
refer to Section 2.1.10 Reversal Advice 0420/0430.

UPI CONFIDENTIAL 10
 Part I: Transaction Processing

2.1.5 MO/TO Pre-authorization Cancellation Transaction (Online) 0100/0110

For a successful MO/TO Pre-authorization, a MO/TO Pre-authorization Cancellation is used to request the Issuer to
cancel the payment commitment within 30 days after pre-authorization and prior to initiating pre-authorization
completion.
MO/TO Pre-authorization Cancellation must be a full-amount cancellation of the original MO/TO pre-authorization.
This transaction is a request transaction switched via GSCS. Please refer to Section 1.2.2.1 for details.
This transaction is not involved in settlement.
This transaction may trigger reversal advice. For the conditions to trigger reversal and its processing flows, please
refer to Section 2.1.10 Reversal Advice 0420/0430.

2.1.6 Financial Request Transaction 0200/0210

Financial transaction, which is used for electronic fund transfer, refers to the procedure where the Acquirer asks the
Issuer for permission of both the Cardholder’s transaction and fund settlement. A financial transaction contains a
request message and a response message. After the transaction request is approved by the Issuer, the Cardholder’s
account will be credited or debited.
Financial request transaction includes cash withdrawal, remittance, pre-authorization completion (request), MO/TO
pre-authorization completion (request), purchase, MO/TO purchase, recurring, primary credit, and account funding.
A financial request transaction needs to be switched via GSCS. Please refer to Section 1.2.2.1 for details.
Except remittance verification transactions, the other financial request transactions are involved in settlement and
reconciliation.
Except remittance verification, remittance, and primary credit transaction, financial request transactions may trigger
reversal advice. For the conditions to trigger reversal and its processing flows, please refer to Section 2.1.10 Reversal
Advice 0420/0430. Remittance must not trigger any advice messages. For the abnormalities processing flow of
remittance transactions, please refer to Section 10.7.1 for details
2.1.6.1 Cash Withdrawal
It refers to the procedure where the Cardholder withdraws cash at ATM, POS, or bank counter or another terminal.
2.1.6.2 Pre-authorization Completion (Request)
For approved pre-authorization transaction, pre-authorization completion (request) is used for settlement.
2.1.6.3 MO/TO Pre-authorization Completion (Request)
It is the procedure of using MO/TO pre-authorization completion (request) as payment settlement for the approved
MO/TO pre-authorization transaction.
2.1.6.4 Purchase
It refers to the procedure of completing payment with bankcard accounts at POS terminals or through other channels
when Merchants sell commodities or provide services. It can be one-off payment or installment payment. It also
includes the transaction initiated by the Cardholder at unattended terminals.
2.1.6.5 MO/TO Purchase
It refers to the procedure where the Cardholder orders commodities or services via phone, correspondence, email
or other non-face-to-face communication methods without being present at the Merchant, and then the
Merchant/Acquirer initiates the purchase request with the transaction details provided by the Cardholder. MO/TO
purchase is a request transaction that needs to be switched via GSCS.

UPI CONFIDENTIAL 11
 Part I: Transaction Processing

2.1.6.6 Recurring
A recurring transaction refers to a transaction initiated by a Merchant that is authorized by a Cardholder in a service
agreement to make the payment on behalf of the Cardholder and submit the transaction information (or batch file)
to its Acquirer on a regular basis through the acquiring platform, terminals or other applicable systems. It includes
recurring, recurring cancellation, recurring reversal, recurring reversal cancellation.
2.1.6.7 Remittance
A remittance transaction refers to a transaction initiated by a sender outside of Mainland China to remit funds to a
real-name UnionPay bankcard account issued by the Receiver in Mainland China. The amount sent from the sender
can be cash, fund in a bankcard or fund in a bank account.
Remittance service is the combination of two transactions: remittance verification and remittance. In both
transactions, the Acquirer is the transfer-out party whereas the Issuer the transfer-in party.

1 2

4 3
Acquirer GSCS Issuer
5 6

8 7

Figure 10 Normal Processing Flow of Remittance

1. Remittance verification request sent to GSCS from the Acquirer (0100);

2. Remittance verification request forwarded to the Issuer by GSCS (0100);
3. Approved remittance verification response sent to GSCS from the Issuer (0110);
4. Approved remittance verification response forwarded to the Acquirer by GSCS (0110);
5. Remittance transaction request sent to GSCS from the Acquirer (0200);
6. Remittance transaction request forwarded to the Issuer by GSCS (0200);
7. Approved remittance transaction response sent to GSCS from the Issuer (0210);
8. Approved remittance transaction response forwarded to the Acquirer by GSCS (0210).
Please refer to Section 10.7.1 for exception processing flows.
2.1.6.7.1 Remittance verification 0100/0110
The Acquirer initiates a remittance verification transaction for transfer-in account verification as required by the
customer. This transaction is a request transaction switched by GSCS.
The functions of remittance verification transaction are shown as follows:
1. Verify the validity of the transfer-in card.
2. Verify whether the remittance transaction is supported by the receiver.
3. Check communication line to minimize the failure rate of remittance transaction.

UPI CONFIDENTIAL 12
 Part I: Transaction Processing

4. Check whether the remittance amount exceeds the amount limit.

The Acquirer can only proceed with the remittance transaction after receiving a successful remittance verification
response. A remittance verification transaction can trigger remittance transaction only once. If the Acquirer does not
receive a remittance verification response or receives the failed remittance verification response, it cannot initiate a
remittance transaction.
Remittance verification and remittance must be initiated on the same settlement day.
Remittance verification transaction cannot trigger reversal and does not participate in settlement. If GSCS cannot
send the remittance verification request to the Issuer, the request will be rejected directly. If GSCS cannot forward
the remittance verification response to the Acquirer, the response will be abandoned. If the Acquirer cannot receive
the response sent by GSCS, the transaction will be rejected directly.
2.1.6.7.2 Remittance 0200/0210
The Acquirer initiates a remittance transaction after receiving a successful response of the remittance verification
transaction. The remittance transaction requests the Issuer to confirm the remittance service and the amount
credited to the Cardholder’s bankcard account. It is a request transaction switched by GSCS.
The Acquirer should keep the funds after it initiates the remittance transaction, no matter whether it can receive the
response or whether the response is successful. Funds can be used for further processing.
If the Acquirer receives an approved remittance response, it can inform the customer that “Remittance Transaction
succeeded”. Funds will reach the account in a real time manner. Otherwise, it should inform the customer that
“Remittance Transaction succeeded. Funds will reach the account in a non-real time manner”.
Generally, after a successful remittance verification, the Issuer should not reject the remittance transaction, except
when: (1) remittance message MAC error is verified by the Issuer; or (2) remittance message format error is found
by the Issuer.
GSCS shall match the remittance transaction with the remittance verification according to Field 90 Original Data of
the remittance transaction and reject the remittance transaction if the match fails.
The Issuer does not need to match the remittance transaction with the remittance verification. The remittance
transaction does not trigger reversal, and participates in settlement. For exception processing flow, please refer to
Section 10.7.1 for details.
2.1.6.8 Primary Credit
Primary credit transactions (PCTs) are classified into online primary credit and batch primary credit transactions. For
the transaction flow of batch primary credit, please refer to Section 2.5.2
Online primary credit is a request transaction that needs to be switched via GSCS, and the transaction flow is the
same as that of request message switched by GSCS. Please refer to Section 1.2.2.1 for details.
Abnormal online primary credit transactions may trigger primary credit confirmation. Please refer to Section 2.1.11.4
for details.
2.1.6.9 Account Funding
Account funding transaction (AFT) refers to the procedure of debiting the Issuer in payment scenarios such as P2P
transfer, etc. AFT is a type of request transaction, and please refer to Section 1.2.2.1 for details of its transaction flow.
A successful AFT does not support cancellation by a financial cancellation transaction. A refund (online) transaction
can be initiated to return partial or full amount of a settled AFT. In the event of any connection error or system
malfunction, an AFT shall be reversed by an account funding reversal (AFT reversal) advice message.
Although AFT is a type of single-message transaction, dual-message Members can also support this transaction type.
However, AFT does not support presentment by Acquirers via outgoing settlement files.

UPI CONFIDENTIAL 13
 Part I: Transaction Processing

2.1.6.10 Financial Cancellation

An original successful financial transaction can be cancelled under certain conditions by invoking a cancellation
transaction to return the original transaction amount prior to the settlement. The cancellation must be a full amount
cancellation of the original transaction.
Cancellation transactions include: pre-authorization completion (request) cancellation, MO/TO pre-authorization
completion (request) cancellation, purchase cancellation, MO/TO purchase cancellation, and recurring cancellation.
Financial cancellation transaction is a request transaction that needs to be switched via GSCS, and the transaction
flow is the request transaction processing flow switched via GSCS. Please refer to Section 1.2.2.1 for details.
The financial cancellation transaction is not involved in settlement.
Financial cancellation transaction can trigger reversal advice. For conditions to trigger reversal and its processing
flows, please refer to Section 2.1.10 Reversal Advice.

2.1.7 Balance Inquiry 0200/0210

Balance inquiry is transaction where a Cardholder inquires about the account balance at an ATM or another terminal.
It is a request transaction that needs to be switched via GSCS, and the transaction flow is the request transaction
processing flow that is switched via GSCS. Please refer to Section 4.2.2.1 for details.
The balance inquiry transaction is involved in settlement and does not trigger reversal.
When GSCS cannot forward the inquiry request to the Issuer, the request will be directly rejected.
When GSCS cannot forward the response to the Acquirer, the response will be directly discarded.
When the Acquirer cannot receive the response from GSCS, the transaction will be directly rejected.

2.1.8 UnionPay Card Exchange Rate Inquiry 0600/0610

An exchange rate inquiry transaction, which is initiated before an international remittance transaction, is to obtain
exchange rate between the transaction currency and the Cardholder billing currency. For example, if the sending
currency of an international remittance transaction is HKD while the billing currency of the receiving account is RMB,
the Cardholder can initiate an exchange rate inquiry transaction first to obtain the transfer-in amount in RMB and
exchange rate for HKD against RMB.
UnionPay card exchange rate inquiry message is 0600/0610 request transaction directly processed by GSCS. Please
refer to Section 1.2.2.2 for details. The request should not be re-sent if the sender does not receive any response,
and response will be abandoned if the receiver is not able to send the response.
This transaction is not involved in settlement.

2.1.9 Commission Relationship 0100/0110

2.1.9.1 Establishment of Commission Relationship
Establishment of commission relationship refers to the request made by the Acquirer on the Cardholder’s behalf to
ask the Issuer to validate the Cardholder’s identification and grant authority to specified card-not-present
transactions. It will not be part of the clearing and settlement procedure.
The establishment of commission relationship message is 0100/0110 request transaction and can trigger reversal
advice. For processing flow of request transaction, please refer to Section 1.2.2.1 for details. For processing flow and
trigger conditions of reversal advice, please refer to Section 2.1.10 Reversal Advice 0420/0430.
2.1.9.2 Revoke of Commission Relationship
Revoke of commission relationship is the opposite of commission relationship. It is not involved in the clearing and
settlement procedure.

UPI CONFIDENTIAL 14
 Part I: Transaction Processing
The revoke of commission relationship message is 0100/0110 request transaction and can trigger reversal advice.
For processing flow of request transaction, please refer to Section 1.2.2.1 for details. For processing flow and trigger
conditions of reversal advice, please refer to Section 2.1.10 Reversal Advice 0420/0430.

2.1.10 Account Verification 0100/0110

The Acquirer initiates account verification to verify information such as the Cardholder’s identity, account
information, etc. It is a request transaction switched by GSCS, applicable to CAT purchase, card-not-present self-
service purchase, card-not-present establishment of commission relationship, recurring, MO/TO, and primary credit
transactions. For CAT purchase, card-not-present self-service purchase, recurring, MO/TO, and primary credit
transactions, the purpose of account verification is to validate the account before the payment transaction. In some
CAT purchase, card-not-present self-service purchase, and card-not-present establishment of commission
relationship, its purpose is to verify the account validity in a certain period before binding the card.
The Issuer/UPI may conduct verification of PAN, card expiration date, PIN, CVN2, ID card number, name, mobile
phone number, one-time password (OTP), and/or other verification elements as required and indicated in the request
message.

2.1.11 Reversal Advice 0420/0430

For the requests with the message type identifier 0100 and 0200, except for remittance, primary credit transactions,
inquiry requests, etc., reversal advice must be generated if the Acquirer and GSCS cannot receive any response to
the transaction request within a specified timeframe. If GSCS cannot forward a successful transaction response to
the Acquirer, reversal advice must be generated as well.
When the Acquirer receives reversal advice from the terminal or GSCS receives reversal advice from the Acquirer, a
response must be given immediately. If the original transaction is successful, it shall be firstly set to reversed
transaction and then reversal advice will be sent to the next institution, to which the original transaction is sent.
Store-and-forward will be adopted in case the sender of the reversal advice cannot receive any response. But reversal
advice shall not be sent on another settlement day.
Transactions that generate reversal advice include: pre-authorization, pre-authorization cancellation, manual pre-
authorization cancellation, pre-authorization completion (request), pre-authorization completion (request)
cancellation, purchase, MO/TO purchase, MO/TO purchase cancellation, purchase cancellation, recurring, recurring
cancellation, MO/TO pre-authorization, MO/TO pre-authorization cancellation, manual MO/TO pre-authorization
cancellation, MO/TO pre-authorization completion (request), MO/TO pre-authorization completion(request)
cancellation, cash withdrawal, establishment of commission relationship, revoke of commission relationship (online),
and account funding transaction.
2.1.11.1 Normal Transaction Flow

2
Acquirer GSCS Issuer
3

Figure 11 Normal Flow of Reversal Advice

UPI CONFIDENTIAL 15
 Part I: Transaction Processing

1. Reversal advice (0420) sent to GSCS by the Acquirer;

2. Reversal responses (0430) sent to the Acquirer by GSCS;
3. Reversal advice (0420) sent to the Issuer by GSCS;
4. Reversal responses (0430) sent to GSCS by the Issuer.
2.1.11.2 Abnormal Transaction Flow
2.1.11.2.1 Receiver of reversal advice cannot send reversal response
When the receiver of the reversal advice cannot send the reversal response to the sender of the reversal advice, the
receiver will abandon it directly. The receiver will not send the response to the sender until it receives the reversal
advice re-sent by the sender.

2
Sender Receiver
3

Figure 12 Abnormal Flow I of Reversal

1. Reversal advice sent to the receiver by the sender;

2. Reversal response sent to the sender by the receiver. Abnormal situation at the receiver;
3. Reversal advice re-sent to the receiver by the sender;
4. Reversal response sent to the sender by the receiver.
2.1.11.2.2 Sender of reversal advice cannot send reversal advice
When the sender cannot send the reversal advice to the receiver, the sender will put the reversal advice in store-
and-forward queue for storing and forwarding.

Sender 2 Receiver

Figure 13 Abnormal Flow II of Reversal

UPI CONFIDENTIAL 16
 Part I: Transaction Processing

1. Reversal advice sent to the receiver by the sender, and it cannot reach the receiver due to connection errors;
2. Reversal advice re-sent to the receiver by the sender after recovery;
3. Response to the reversal advice from the receiver.

2.1.12 Financial Advice Transaction 0220/0230

Financial advice transaction is used for fund transfer and corresponding account processing among the Acquirer,
GSCS and the Issuer.
This transaction type includes: pre-authorization completion (advice) initiated by the Acquirer, settlement advice
sent to the Issuer by GSCS, MO/TO settlement advice, refund (online) initiated by the Acquirer (also MO/TO refund
and recurring refund). Financial advice transaction is involved in settlement. Financial advice transaction does not
trigger reversal. When the advice message sender cannot receive any response, store-and-forward shall be adopted
but the advice message cannot be resent on another settlement day.
2.1.12.1 Pre-authorization Completion (Advice) and MO/TO Pre-authorization Completion (Advice)
For an approved pre-authorized transaction, in addition to pre-authorization completion (request), pre-authorization
completion (advice) can be used to complete payment settlement. Pre-authorization completion (advice) is the
advice transaction switched via GSCS that the Issuer cannot reject. The above-mentioned content is also applicable
to MO/TO pre-authorization completion (advice).
2.1.12.1.1 Normal Transaction Flow

2
Acquirer GSCS Issuer
3

Figure 14 Normal Flow of Pre-authorization Completion (Advice)

1. Pre-authorization completion ( advice) (0220) sent to GSCS by the Acquirer;

2. Response (0230) sent to the Acquirer by GSCS;
3. Settlement advice (0220) sent to the Issuer by GSCS;
4. Response (0230) sent to GSCS by the Issuer.
2.1.12.1.2 Abnormal Transaction Flow
If the sender cannot send the pre-authorization completion (advice) transaction to the receiver or does not get the
receiver’s response to the transaction, it will save the advice in the store-and-forward queue for storing and
forwarding.

UPI CONFIDENTIAL 17
 Part I: Transaction Processing

Sender 2 Receiver

Figure 15 Abnormal Flow of Pre-authorization Completion (Advice)

1. Pre-authorization completion (advice) sent to the receiver by the sender cannot be sent out due to failure;
2. Pre-authorization completion (advice) re-sent to the receiver by the sender after recovery of the sender’s
system;
3. Response to pre-authorization completion (advice) by the receiver.
2.1.12.2 Settlement Advice, MO/TO Settlement Advice
Settlement advice is sent by GSCS when GSCS forwards the dual-message Acquirer’s request to the single-message
Issuer during the dual-message to single-message conversion, and it is the fund settlement advice for the previously
approved pre-authorization transaction.
Similarly, MO/TO settlement advice is the settlement advice for the previously approved MO/TO pre-authorization.
Its settlement procedure is the same as that of regular settlement advice.
If the settlement advice is sent before cutoff by GSCS, and received by the Issuer after cutoff, the Issuer shall be able
to handle settlement advice on another settlement day within the response time frame.
In case that the Acquirer adopts dual-message processing mode and the Issuer adopts single-message processing
mode, GSCS will provide transaction mode conversion. GSCS will convert successfully settled dual-message clearing
file into settlement advice message by records and send it to the Issuer. The Issuer cannot reject settlement advice
in online transactions. The Issuer can initiate chargeback to reject settlement advice afterwards.
It is optional for Members to support settlement advice. However, if the single-message Issuer supports pre-
authorization transaction, it shall support settlement advice transaction.
2.1.12.2.1 Normal Transaction Flow
The Acquirer sends dual-message clearing file to GSCS, then GSCS converts the file into settlement advice and send
the settlement advice to the single-message Issuer. The Issuer sends the response to GSCS.

UPI CONFIDENTIAL 18
 Part I: Transaction Processing

Acquirer GSCS Issuer

2

Figure 16 Normal Flow of Settlement Advice

1. Dual message presentment file sent to GSCS by the Acquirer;

2. Fund settlement advice sent to the Issuer by GSCS;
3. Response sent to GSCS by the Issuer.
2.1.12.2.2 Abnormal Transaction Flow
When a failure occurs on the Issuer’s side and GSCS cannot send the settlement advice to the Issuer, GSCS will put
the advice in store-and-forward queue for storing and forwarding.

2
Acquirer GSCS Issuer
3

Figure 17 Abnormal Flow of Settlement Advice

1. Dual message presentment file sent to GSCS by the Acquirer;

2. GSCS cannot send the settlement advice to the Issuer for a certain reason;
3. Settlement advice re-sent by GSCS;
4. Response re-sent to GSCS by the Issuer.
2.1.12.3 Refund (Online), MO/TO Refund (Online), Recurring Refund
It is the procedure in which the Merchant return the settled amount to the Cardholder’s original account due to
commodity return or service cancellation, and it includes total and partial refund. The procedure of MO/TO refund
(online) is the same as that of normal refund (online).
A refund (online) transaction can be initiated to return partial or full amount of a settled AFT.
For installment payment purchase, GSCS provides installment payment refund (online) transaction. The processing
flow is the same as that of refund (online) transaction.

UPI CONFIDENTIAL 19
 Part I: Transaction Processing
Once the Issuer receives a refund (online) transaction, the transaction shall be approved unconditionally and it will
be involved in reconciliation.
If the refund (online) transaction is sent by GSCS before cut-off, and received by the Issuer after cut-off, the Issuer
shall process it on another settlement day within the response time frame.
The transaction is an advice transaction that needs to be switched via GSCS.
2.1.12.3.1 Normal Transaction Flow

2
Acquirer GSCS Issuer
3

Figure 18 Normal Flow of Refund (Online)

1. Refund advice (0220) sent to GSCS by the Acquirer;

2. Response (0230) sent to the Acquirer by GSCS;
3. Advice (0220) sent to the Issuer by GSCS;
4. Response (0230) sent to GSCS by the Issuer.
2.1.12.3.2 Abnormal Transaction Flow
If the sender cannot send the refund transaction (online) to the receiver, or it does not receive the receiver’s response
to the refund transaction (online), the sender shall put the refund transaction (online) in store-and-forward queue
for storing and forwarding.

Sender 2 Receiver

Figure 19 Abnormal Flow of Refund (Online)

1. Refund advice cannot be sent to the receiver by the sender due to failure;
2. Refund advice re-sent to the receiver by the sender after recovery of the sender’s system;
3. Receiver’s response to refund advice.

UPI CONFIDENTIAL 20
 Part I: Transaction Processing
Note: Members may log onto CDRS to initiate manual refund, please refer to Chapter 8 Explanation on Dispute
Resolution for the processing flow.
2.1.12.4 Primary Credit Confirmation
For online primary credit, see Section 10.7.3 for the abnormalities processing of online primary credit.
For batch primary credit, when GSCS did not receive the response to the primary credit request, GSCS will send
primary credit confirmation advice to the Issuer. The Issuer will use credit confirmation to proceed. If both primary
credit and primary credit confirmation exist, credit confirmation shall be regarded as valid.
If GSCS cannot receive the response to credit confirmation from the Issuer, the primary credit confirmation advice
will be stored in the store-and-forward queue and proceeded accordingly. Once the Issuer receives the primary credit
confirmation advice successfully, it should be accepted unconditionally.

2.1.13 Cross-border Single-message Transaction Verified via UPOP

Cross-border single message transactions verified via UPOP include the following transactions: balance inquiry,
purchase, pre-authorization, pre-authorization completion (request), purchase cancellation, pre-authorization
cancellation, pre-authorization completion (request) cancellation, refund(on-line), purchase reversal, pre-
authorization reversal, pre-authorization completion (request) reversal, purchase cancellation reversal, pre-
authorization cancellation reversal, and pre-authorization completion (request) cancellation reversal. UPOP
verification flows are processed within UPOP system and will not affect general processing flows of transactions
among the Acquirer, GSCS and the Issuer. For example, the transaction flow of cross-border purchase transaction
verified via UPOP is the same as that of cross-border purchase transaction among the Acquirer, GSCS and the Issuer.

2.2 Dual-message Transaction Processing

2.2.1 Authorization Transaction
It is the process in which the Acquirer initiates a request to the Issuer for payment commitment, which is switched
via GSCS, and the Issuer returns a response according to the status of Cardholder’s account.
When the Acquirer does not receive the authorization response message, the Acquirer may initiate an authorization
reversal message. In case GSCS cannot forward the approved authorization response message to the Acquirer, it will
initiate an authorization reversal message and send it to the Issuer.
After the authorization request is approved, the whole transaction will be completed through presentment. The
authorization code and authorization amount of each transaction should be indicated when settlement files are
submitted, and the authorization amount will participate in the settlement between UPI and the Issuer. An approved
authorization transaction (including fixed-amount authorization and estimated-amount authorization) is only valid
for certain time specified in the UPI Operating Regulations, the Acquirer shall submit presentment files within the
specified time; otherwise the Issuer has the right to initiate chargeback.
The authorization transaction only controls the Cardholder’ usable balance and does not participate in the settlement.
The transaction is a request transaction that needs to be switched via GSCS. The transaction flow is the same as that
of request transactions switched via GSCS. Please refer to Section 1.2.2.1 for details.
2.2.2 Incremental Authorization Transaction

UPI CONFIDENTIAL 21
 Part I: Transaction Processing

2.2.2.1 Normal Processing Flow

Acquirer GSCS Issuer

1 2
1st
Authorization
4 3

5
F90= Key Field from the 1st
6
Incremental trx F90
Authorization
8 7
Use trx
context from
the 1st trx 9 10
F90= Key Field from the 1st F90
trx
Incremental
Authorization
12 11

13
One clearing record for all trx 14
Clearing F38 from the 1st trx

Figure 20 Normal Processing Flow of Incremental Authorization

1) The Acquirer checks the validity of the account information and other credentials of the Merchant, then sends the
payment request to GSCS if the information is valid.
2) GSCS forwards the authorization request to the Issuer.
3) The Issuer returns the transaction outcome to GSCS.
4) GSCS returns the Incremental authorization response to the Acquirer.
5) The Acquirer sends the Incremental authorization request to GSCS with Field 90.
6) GSCS forwards the Incremental authorization request to the Issuer.
7) The Issuer returns the transaction outcome to GSCS.
8) GSCS returns the Incremental authorization response to the Acquirer.
9) The Acquirer sends another Incremental authorization request to GSCS with Field 90.
10) GSCS forwards the Incremental authorization request to the Issuer.
11) The Issuer returns the transaction outcome to GSCS.
12) GSCS returns the Incremental authorization response to the Acquirer.
13) The Acquirer sends the presentment file of the total authorization transaction to GSCS with Field 38 from the
response of the first transaction.
14), 15) GSCS distributes the settlement files to the Acquirer and the Issuer.
Note:

UPI CONFIDENTIAL 22
 Part I: Transaction Processing
1) The first authorization determines the final transaction characteristics. All attributes associated with the original
are inherited by the incremental authorizations (i.e., whether a transaction took place in a card present or card not
present environment), the Acquirer shall fill in these attributes with the same value as that of the first authorization
message.
2) The presentment shall be the completion of all transactions, rather than any one of the incremental authorizations.
2.2.2.2 Exceptional Processing Flow
Please refer to Section 2.1.3.2.
2.2.2.3 Incremental Authorization Cancellation and Refund
Please refer to Section 2.1.3.3.

2.2.3 Authorization Cancellation Transaction

It is a process in which the Acquirer asks the Issuer to cancel payment commitment via GSCS through POS or in other
ways due to the fact that the Cardholder cancels the transaction or makes payment in other ways, or reasons of the
Merchant itself.
A time frame will be set for the cancellation transaction initiated by the Acquirer. If the Acquirer does not receive
any cancellation response within the time frame, it shall initiate a cancellation reversal message to ask the Issuer to
cancel the transaction. In case GSCS detects that the cancellation transaction is beyond the time frame, it will also
initiate a cancellation timeout reversal to ask the Issuer to cancel the transaction.
The fixed-amount authorization cancellation transaction shall be conducted at the same terminal that processed the
original authorization transaction on the same settlement day.
Authorization cancellation does not participate in settlement.
The transaction is a request transaction that needs to be switched via GSCS. The transaction flow is the same as that
of request transactions switched via GSCS. Please refer to Section 1.2.2.1 for details.

2.2.4 Reversal Transaction

For authorization/authorization cancellation, reversal can be initiated.
When the Acquirer and GSCS cannot receive the response to request message within the specified time frame, or
GSCS cannot forward the response to request message to the Acquirer, a reversal transaction should be initiated.
If the sender of the reversal cannot send the reversal message or cannot receive the response of the reversal from
the receiver, the reversal advice message will be put in the store-and-forward queue for storing and forwarding.
Please refer to the single message transaction processing for the transaction flow. Transactions that can generate
reversal include: purchase authorization (one-time payment), purchase authorization (installment payment), cash
withdrawal at bank counter, MO/TO authorization and recurring authorization and subsequent cancellation
transaction.

2.2.5 Balance Inquiry Transaction 0100/0110

Except for the message type (0100/0110), the processing is the same as that for single message transactions.

2.3 Manual Transaction Processing

It is the transaction in which a Member logs on to CDRS and finds the original transaction through the platform to
initiate a transaction associated with the original transaction.

2.3.1 Manual Pre-authorization Cancellation Transaction 0100/0110

As for pre-authorization that is successfully switched via GSCS, the Acquirer may cancel it manually on CDRS. After
receiving manual cancellation request on CDRS, GSCS will send a manual pre-authorization cancellation request

UPI CONFIDENTIAL 23
 Part I: Transaction Processing
message to the Issuer. If GSCS does not receive any response after sending out the manual pre-authorization
cancellation message, a notice of transaction failure will be prompted on the operation interface, and meanwhile
GSCS will send manual pre-authorization cancellation reversal advice to Issuer.
2.3.1.1 Normal Transaction Flow

1 CDRS

Acquirer 2 Issuer

3
GSCS
4

Figure 21 Normal Flow of Manual Pre-authorization Cancellation

1. The Acquirer logs onto the CDRS and initiates the pre-authorization cancellation (manual) transaction;
2. CDRS informs GSCS of pre-authorization cancellation (manual);
3. GSCS will send pre-authorization cancellation (manual) request message to the Issuer immediately after
receiving it;
4. The Issuer sends back the pre-authorization cancellation (manual) response message to GSCS.
2.3.1.2 Abnormal Transaction Flow
When the sender cannot send the manual pre-authorization cancellation request to the receiver, or does not receive
the manual pre-authorization cancellation response from the receiver, it will initiate manual pre-authorization
cancellation reversal.

1 CDRS

Acquirer 2 Issuer

3
GSCS 4
5

Figure 22 Abnormal Flow of Manual Pre-authorization Cancellation

1. The Acquirer initiates a pre-authorization cancellation (manual) transaction on the CDRS;

2. CDRS sends the pre-authorization cancellation (manual) request to GSCS;
3. The pre-authorization cancellation (manual) request sent to the Issuer by GSCS is lost on the way due to failure,

UPI CONFIDENTIAL 24
 Part I: Transaction Processing

and it will cause GSCS timeout;

4. Pre-authorization cancellation (manual) reversal advice sent to the Issuer by GSCS;
5. Pre-authorization cancellation (manual) reversal response sent to GSCS by the Issuer.

2.3.2 Manual Authorization Cancellation Transaction 0100/0110

The transaction procedure of manual authorization cancellation is the same as that of the manual pre-authorization
cancellation specified in Section 2.3.1.

2.3.3 Manual Refund

For settled purchase transactions, MO/TO purchase transactions, pre-authorization completion transactions, MO/TO
pre-authorization completion transactions, the Acquirer may initiate manual refund on the CDRS to return the
amount paid by the Cardholder.
GSCS will not send any online message to Members. Manual refund is involved in settlement, but not reconciliation.
Manual refund transaction processing flow and features are as follows:
The Acquirer may initiate a manual refund transaction after finding the original transaction through CDRS, or refund
transaction information can be manually entered, and GSCS will directly settle the refund transaction.
Manual refund supports full amount refund, partial amount refund and multiple times of refund.
Manual refund can be cancelled on CDRS before cutoff of the day. After cancellation, original manual refund and
manual refund cancellation transactions will not be in the files distributed by GSCS.
If the Acquirer adopts single message mode, the manual refund transaction is recorded in the general audit trailer
file and also included in the statistics of the summary report.
If the Acquirer adopts dual message mode, the manual refund transaction is recorded in the dual-message
settlement file and also included in the statistics of the summary report.

1 CDRS

Acquirer 2 Issuer

3 GSCS 3

Figure 23 Processing Flow of Manual Refund

1. The Acquirer logs onto the CDRS to initiate the manual refund;
2. CDRS informs GSCS of the manual refund advice;
3. At cutoff of the day, GSCS sends transaction details and related files to the Issuer.

2.3.4 Manual Pre-authorization Completion, Manual Authorization Presentment

For all the pre-authorization/authorization transactions which are successfully switched via GSCS, the Acquirer can
settle them by submitting manual pre-authorization completion/manual authorization presentment on CDRS. And

UPI CONFIDENTIAL 25
 Part I: Transaction Processing
manual authorization presentment is for the dual message Acquirer that can submit dual message presentment
transaction on CDRS (only for estimated amount Authorization presentment).
The transaction is involved in settlement.
Manual Pre-authorization completion processing flow and features are as follows:
1. Manual Pre-authorization completion can be cancelled manually on CDRS before cut-off of the day. After
cancellation, original manual pre-authorization completion and manual pre-authorization completion
cancellation transactions will not be recorded in the audit trailer distributed by GSCS.
2. GSCS will not send any online advice message to single message Members.
3. For the single message Acquirer, manual pre-authorization completion transaction is sent to the Acquirer
through the general transaction audit trailer and included in the statistics of summary report as well.
4. If the Issuer adopts dual message mode, then the manual pre-authorization completion transaction is recorded
in dual message settlement files and included in the statistics of summary report as well.
5. If the Issuer adopts single message mode, then the manual pre-authorization completion transaction is
recorded in the general transaction audit trailer and included in the statistics of summary report as well.
Manual authorization presentment processing flow and features are as follows:
1. Manual authorization presentment can be cancelled manually on CDRS before cut-off of the day. After
cancellation, original manual authorization presentment and manual authorization presentment cancellation
transactions will not be recorded in the settlement files and reports distributed by GSCS.
2. GSCS will not send any online advice message to single message Members.
3. For the dual message Acquirer, the manual authorization presentment transaction is sent to the Acquirer
through dual message settlement files and included in the statistics of summary report as well.
4. If the Issuer adopts dual message mode, then the manual authorization presentment transaction is recorded in
dual message settlement files and included in the statistics of summary report as well.
5. If the Issuer adopts single message mode, then the manual pre-authorization completion transaction is
recorded in the general transaction audit trailer and included in the statistics of summary report as well.
General processing flow of manual pre-authorization completion/manual authorization presentment is as follows:

1 CDRS

Acquirer 2 Issuer

3 GSCS 3

Figure 24 General Processing Flow of Manual Pre-authorization Completion/Manual Authorization Presentment

1. The Acquirer logs onto CDRS to initiate manual pre-authorization completion/manual authorization
presentment;

UPI CONFIDENTIAL 26
 Part I: Transaction Processing

2. CDRS informs GSCS of the manual pre-authorization completion/manual authorization presentment;

3. After cut-off, GSCS sends the general transaction audit trailer or dual message settlement files to the Issuer,
including manual pre-authorization completion/manual authorization presentment.

2.3.5 Manual Remittance Transactions

If the remittance has been kept by the Acquirer while the transaction is not settled by GSCS, the Acquirer should log
onto the CDRS to find the remittance verification transaction and initiate a manual remittance transaction.
The transaction is involved in settlement but not online reconciliation.
Manual remittance transaction can be manually cancelled on CDRS before cutoff. After cancellation, the original
manual remittance and original manual remittance transaction cancellation will not appear in files distributed by
GSCS.
GSCS would not send any online advice message to Institutions.
Manual remittance transaction is sent to Members through the general transaction audit trailer file which is also
included in summary report.

1 CDRS

Acquirer 2 Issuer

3 GSCS 3

Figure 25 General Processing Flow of Manual Remittance

1. The Acquirer logs onto CDRS to initiate manual remittance;

2. CDRS informs GSCS of the manual remittance;
3. After cutoff, GSCS sends general transaction audit trailer to Members, including manual remittance.
2.3.6 Manual MO/TO Pre-authorization Cancellation, Manual MO/TO Authorization
Cancellation
The procedure is the same as that of manual pre-authorization cancellation specified in Section 2.3.1.

2.3.7 Manual MO/TO Pre-authorization Completion

The procedure is the same as that of manual pre-authorization completion specified in Section 2.3.4.

2.4 Processing of IC Card Transaction Based on UICS Debit/Credit Standard

There are two main applications for UICS-based IC cards: debit/credit application which is for standard debit/credit
transactions and E-cash application which is for low-value payment transactions. Details are described in the
following sections.

2.4.1 Supported Transaction Types

UPI CONFIDENTIAL 27
 Part I: Transaction Processing

2.4.1.1 Basic Transaction Types

Supported request transactions include: balance inquiry, cash withdrawal, purchase, purchase cancellation, pre-
authorization/authorization, pre-authorization/authorization cancellation, pre-authorization completion (request),
pre-authorization completion (request) cancellation, and account funding transaction.
Supported advice transactions: pre-authorization completion (advice), refund, settlement advice, MO/TO settlement
advice, purchase reversal, cash withdrawal reversal, pre-authorization/authorization reversal, purchase cancellation
reversal, pre-authorization cancellation/authorization cancellation reversal, pre-authorization completion (request)
reversal, pre-authorization completion (request) cancellation reversal, and account funding reversal.
2.4.1.2 Debit/Credit Application-based IC Card Script Processing Result Advice
If a transaction contains the Issuer script, the Acquirer shall inform the Issuer immediately of the script result
performed by the card. International transactions shall support the advice; and both single message system and dual
message system shall also support the advice.
For a non-loading transaction, if the original transaction failed, it should be processed according to abnormal
processing flow. The script should also be performed and script result advice should be sent.
For a non-loading transaction, if the Issuer returns a script for automatic loading, the terminal should return a script
processing result advice. The script processing result will not have any influence on the result of the original non-
loading transaction.
For a loading transaction, the failed original transaction will trigger reversal. Please refer to Section 10.7.2 for details.
2.4.1.3 Transaction Processing Flow
Processing flow of request and advice transactions is similar to that of magnetic stripe card transaction.
Script processing result advice is a transaction that needs to be switched by GSCS. When the sender of the advice
does not receive any response, the advice shall be stored and forwarded, but it cannot be sent on another settlement
day.
According to different levels at which Members have migrated to UICS debit/credit standards, Members can be
classified into two groups: full support (Full status) and partial support (Early status). This document requires both
the Acquirer and the Issuer to be in Full status.

2.4.2 E-cash Application-based Transaction Types

2.4.2.1 Basic Transaction Types
Supported request transactions include designated account loading and cash loading. Supported advice transactions
include designated account loading reversal, cash loading reversal, script processing result advice and refund (online)
Supported offline transactions include offline purchase and offline refund.
2.4.2.2 E-cash Application-based Designated Account Loading
This transaction is to increase the balance of an E-cash card by transferring the fund from a designated account into
the E-cash card. It is a request transaction forwarded by GSCS, so the transaction flow is that of a request transaction
forwarded by GSCS.
The amount of this transaction is not involved in settlement, while the service fee is involved in settlement.

UPI CONFIDENTIAL 28
 Part I: Transaction Processing

1 2

4 3
Acquirer GSCS Issuer
5 7

6 8

Figure 26 Processing Flow of E-cash Application-based Designated Account Loading

1. Designated account loading request sent to GSCS by the Acquirer;

2. Designated account loading request sent to the Issuer by GSCS;
3. Designated account loading response sent to GSCS by the Issuer;
4. Designated account loading response sent to the Acquirer by GSCS;
5. Script processing result advice sent to GSCS by the Acquirer, informing the Issuer of the result of the loading
transaction;
6. Script processing result advice response sent to the Acquirer by GSCS;
7. Script processing result advice sent to the Issuer by GSCS, informing the Issuer of the result of the loading
transaction;
8. Script processing result advice response sent to GSCS by the Issuer.
Note: Designated account loading transaction may trigger reversal advice. Please refer to Section 2.1.10 Reversal
Advice 0420/0430 for conditions to trigger reversal and its flow.
2.4.2.3 E-cash Application-based Cash Loading
This transaction is a transaction initiated in the form of cash by the terminal of the Acquirer to increase the balance
of an E-cash card. It may trigger reversal advice, and the condition to trigger a reversal and its flow is the same as
those for other normal transactions. Please refer to Section 2.1.10 Reversal Advice 0420/0430 for conditions to
trigger reversal and its flow.
The transaction amount and the service fee of the transaction are both involved in settlement.

1 2

4 3
Acquirer GSCS Issuer
5 7

6 8

UPI CONFIDENTIAL 29
 Part I: Transaction Processing

Figure 27 Processing Flow of E-cash Application-based Cash Loading

1. Cash loading request sent to GSCS by the Acquirer;

2. Cash loading request sent to the Issuer by GSCS;
3. Cash account loading response sent to GSCS by the Issuer;
4. Cash loading response sent to the Acquirer by GSCS;
5. Script processing result advice sent to GSCS by the Acquirer, informing the Issuer of the result of the cash loading
transaction;
6. Script processing result advice response sent to the Acquirer by GSCS;
7. Script processing result advice sent to the Issuer by GSCS, informing the Issuer of the result of the cash loading
transaction;
8. Script processing result advice response sent to GSCS by the Issuer.
2.4.2.4 Refund
E-cash application supports three kinds of refund: refund (online), offline refund and manual refund.
Offline refund is applicable to situations where the transaction details of acquiring terminals have not been sent.
Please refer to Section 9.6 in the Technical Specifications on Bankcard Interoperability - Part III File Interface for
detailed processing procedures of IC card offline purchase.
Refund (online) is applicable to situations where the transaction details of acquiring terminals have been sent. Please
refer to Section 1.2.4.1 Switching via GSCS.
Manual refund, supplementary to refund (online), is initiated from CDRS and participates in settlement of that day.
Refund transactions are involved in settlement.
2.4.2.5 Other Transactions
The processing flow of the reversal for designated account loading and cash loading is the same as that for normal
transactions.
The processing flow of script result advice is the same as that of debit/credit application.
The processing flow of offline purchase is the same as that of debit/credit offline purchase.

2.5 Batch Transaction Processing

2.5.1 Batch Recurring
2.5.1.1 Description
It is the batch transaction of recurring. The batch file is converted into online messages. The Acquirer and GSCS
communicate via batch file, while GSCS and the Issuer communicate via online message. The conversion between
batch file and online message is completed by GSCS.
2.5.1.2 Normal Processing Flow
Batch recurring transactions are involved in settlement.
The file submitted on day T before cutoff will be converted into online message by GSCS on day T; the file submitted
on day T after cutoff will be converted into online message by GSCS on day T+1, and the response file will be sent
back on day T+1.

UPI CONFIDENTIAL 30
 Part I: Transaction Processing

2
Acquirer GSCS 3 Issuer

4
5

Figure 28 Processing Flow of Batch Recurring

1. The Acquirer sends batch recurring request file to GSCS;

2. GSCS loads file and checks its validity, then sends batch recurring feedback file back to the Acquirer;
3. GSCS sends online request messages to the Issuer;
4. The Issuer sends online response messages to GSCS;
5. GSCS sends the batch recurring response file to the Acquirer.
2.5.1.3 Exception Processing Flow
2.5.1.3.1 The procedure of submitting file by Acquirer to GSCS
In Step 1, GSCS receives duplicated batch recurring request files submitted by the Acquirer. The first one will be
regarded as valid and the rest of them will be abandoned.
2.5.1.3.2 The procedure of feedback file by GSCS to Acquirer
In Step 2, GSCS will check the validity of batch recurring request file sent by the Acquirer on the following items: the
loading status of file, the Acquirer’s transaction rights, the uniqueness of file, the validity of transaction record, the
compliance of key file information, and the compliance of the statistics in file header with that in the file record. The
recurring feedback file will notify the Acquirer of the validity of the records: the records that pass validity check will
not be present in the format of reject records and will be converted to online messages; the records that fail validity
check will be present in the format of reject records and will not be forward to the Issuer. If the entire file has error
or cannot be loaded, GSCS will send an error file record in the feedback file to the Acquirer directly and the processing
flow ends.
In Step 2, if the Acquirer receives duplicated feedback files from GSCS, the first one shall be regarded as valid and
duplicated files will be abandoned. If GSCS cannot send the feedback file to the Acquirer, it shall resume the
transmission when communication is restored.
2.5.1.3.3 The procedure of online transactions between GSCS and Issuer
The exception processing flows in Step 3 and Step 4 are the same as that of online recurring transactions. In this
procedure, GSCS may initiate recurring reversal transactions to the Issuer.
2.5.1.3.4 The procedure of response file by GSCS to Acquirer
In Step 5, if the Acquirer receives the duplicated batch recurring response files sent by GSCS, the first file is regarded
as valid and duplicated files are abandoned. If GSCS did not send the response file to the Acquirer, the transaction is
still valid and will be settled. The Acquirer shall proceed according to the information recorded in the audit trailer
sent by UPI.

UPI CONFIDENTIAL 31
 Part I: Transaction Processing
If there are still transactions that have not been converted to online message after timeout, they shall be treated as
failed transactions.

2.5.2 Batch Primary Credit

2.5.2.1 Description
It is the batch transaction of primary credit. The batch file is converted into online messages. The Acquirer and GSCS
communicate via batch file, while GSCS and the Issuer communicate via online message. The conversion between
batch file and online message is completed by GSCS.
2.5.2.2 Normal Processing Flow
Batch primary credit transactions are involved in settlement.
The file submitted on day T before cutoff will be converted into online message by GSCS on day T; the file submitted
on day T after cutoff will be converted into online message by GSCS on day T+1, and the response file will be sent
back on day T+1.

2
Acquirer GSCS 3 Issuer

4
5

Figure 29 Processing Flow of Batch Primary Credit

1. The Acquirer sends batch primary credit request file to GSCS;

2. GSCS loads file and checks its validity, then sends batch recurring feedback file back to the Acquirer;
3. GSCS sends online request messages to the Issuer;
4. The Issuer sends online response messages to GSCS;
5. GSCS sends the batch recurring response file to the Acquirer.
2.5.2.3 Exception Processing Flow
The exception processing flow of batch primary credit is the same as that of batch recurring, please refer to Section
2.5.1.3 Exception Processing Flow for details.

2.5.3 Batch MO/TO

2.5.3.1 Description
It is the batch transaction of MO/TO. The batch file is converted into online messages. The Acquirer and GSCS
communicate via batch file, while GSCS and the Issuer communicate via online message. The conversion between
batch file and online message is completed by GSCS.
2.5.3.2 Normal Processing Flow
Batch MO/TO transactions are involved in settlement.

UPI CONFIDENTIAL 32
 Part I: Transaction Processing
The file submitted on day T before cutoff will be converted into online message by GSCS on day T; the file submitted
on day T after cutoff will be converted into online message by GSCS on day T+1, and the response file will be sent
back on day T+1.

2
Acquirer GSCS 3 Issuer

4
5

Figure 30 Processing Flow of Batch MO/TO

1. The Acquirer sends batch MO/TO request file to GSCS;

2. GSCS loads file and checks its validity, then sends batch recurring feedback file back to the Acquirer;
3. GSCS sends online request messages to the Issuer;
4. The Issuer sends online response messages to GSCS;
5. GSCS sends the batch recurring response file to the Acquirer.
2.5.3.3 Exception Processing Flow
The exception processing flow of batch MO/TO is the same as that of batch recurring, please refer to Section 2.5.1.3
Exception Processing Flow for details.

2.6 Timeout Setting Rules for General Transaction

Each Member in the transaction should at least comply with the following timeout requirement:
The response time frame for the Issuer’s system is counted from the time when the Issuer receives the request
message till the time when the Issuer sends the response message. The response time shall be less than 20 seconds
according to the business rules.
Table 2 Timeout Setting for General Transactions

Party Timeout Setting X (second)

Acquirer X≥25
GSCS 20<X≤45
GSCS counts the start and the end of the timing according to its own system time.
GSCS response time frame starts from sending the message to the Issuer and ends upon receiving the response
message from the Issuer.
The Acquirer’s system counts the start and the end of the timing according to its own system time.
The Acquirer’s system response time frame starts from sending the message to GSCS and ends upon receiving the
response message from GSCS.

UPI CONFIDENTIAL 33
 Part I: Transaction Processing

3 Stand-in Authorization Transaction Processing

3.1 Overview of Stand-in Authorization Transaction
GSCS provides stand-in authorization service for purchase, pre-authorization, pre-authorization completion (request),
authorization, as well as their cancellation and reversal transactions.
The UPI stand-in authorization system supports both manual and automatic initiation/termination mode. Manual
initiation/termination mode has a higher priority than automatic initiation/termination mode:
1. Stand-in authorization initiated manually can only be terminated manually.
2. Stand-in authorization initiated automatically can be terminated manually or automatically.

3.1.1 Manual Stand-in Authorization Initiation and Termination

The Member can manually notify UPI if a stand-in authorization transaction is needed. Then GSCS processes
transactions of the Member through the stand-in authorization system after stand-in authorization setting is initiated.

3.1.2 Automatic Stand-in Authorization Initiation and Termination

GSCS can initiate or terminate stand-in authorization through monitoring the Member status. For the condition and
basic business processing of Automatic Stand-in Authorization Initiation and Termination, please refer to the
UnionPay International Stand-in Authorization Service Guide.

3.2 Stand-in Authorization Transaction Processing Flow

GSCS

Stand-in
Acquirer Issuer
Authorization

Figure 31 Processing Flow of Stand-in Authorization Transaction

1. The Acquirer sends an authorization request to GSCS;

2. GSCS processes transactions eligible for stand-in Authorization Service, and returns the result to the Acquirer.
For transactions approved via stand-in authorization, UPI will provide stand-in authorization for subsequent
transactions such as the corresponding completion, reversal and cancellation transactions.
Table 3 Processing of Subsequent Transactions of the Original Stand-in Authorization Transaction

Stand-in System status when UPI’s processing Notes

authorization for subsequent of subsequent
the original transaction occurs transactions
transaction?
Pre-authorization Completion, Pre-authorization/Authorization Cancellation
Stand-in Switch the If the Issuer has not completed the log of

UPI CONFIDENTIAL 34
 Part I: Transaction Processing

Stand-in System status when UPI’s processing Notes

authorization for subsequent of subsequent
the original transaction occurs transactions
transaction?
Yes authorization for the transaction to the the original transaction, the cancellation
original transaction Issuer transaction will fail.
was terminated
If the Issuer has completed the log of the
original transaction, the cancellation
transaction will succeed.
Stand-in Stand-in Subsequent transaction is also processed
authorization for the authorization for via stand-in authorization and will
original transaction subsequent succeed.
was not terminated transaction
No Stand-in Stand-in As there is no log of the original
authorization for the authorization for transaction in the stand-in authorization
original transaction subsequent system, the pre-authorization cancellation
was initiated transaction will fail with response code “25”; the pre-
authorization completion transaction will
succeed.
Stand-in Switch subsequent Subsequent transaction will be processed
authorization for the transaction to the by the Issuer.
original transaction Issuer
was not initiated
Other Subsequent Cancellation and Reversal
Yes Stand-in Switch subsequent If the Issuer has not completed the log of
authorization for the transaction to the the original transaction, the cancellation
original transaction Issuer transaction will fail.
was terminated
If the Issuer has completed the log of the
original transaction, the cancellation
transaction will succeed.
Stand-in Stand-in Subsequent transaction is also processed
authorization for the authorization for via stand-in authorization and will
original transaction subsequent succeed.
was not terminated transaction
No Stand-in Switch subsequent Subsequent transaction is switched via the
authorization for the transaction to the original route to the Issuer. If the route
original transaction Issuer breaks off, subsequent transaction will fail
was initiated with response code “91”.
Stand-in Switch subsequent Subsequent transaction will be processed
authorization for the transaction to the by the Issuer.
original transaction Issuer
was not initiated

3.3 Transmission of Stand-in Authorization Transaction Log

3.3.1 File Transmission Mode

UPI CONFIDENTIAL 35
 Part I: Transaction Processing
UPI will send the transaction information processed through stand-in authorization to the Issuer by files to complete
the Issuer’s transaction log. For detailed processing procedures and file record format, please refer to the Technical
Specifications on Bankcard Interoperability - Part III File Interface.

3.3.2 Online Transmission Mode

Apart from file transmission mode, Members can complete their transaction log after the completion of stand-in
authorization and before 22:00 on the second settlement day by online transmission mode.
Members can notify GSCS to initiate/terminate the online transmission mode by sending stand-in authorization
imitation/termination message. GSCS may also terminate the online transmission mode on its own initiative if the
transmission of stand-in authorization information is completed.
After online transmission starts, the stand-in authorization transactions are sent one by one following the sequence
of time when transactions were received in the stand-in authorization system. The type of the transactions
transmitted is advice transaction. Members can set up the transmission flow rate (transactions/sec). If GSCS does
not receive the response of the transaction just transmitted, that transaction will be sent repeatedly until GSCS
receives the response.

1
2
3
GSCS 4 Issuer
...

5
6

Figure 32 Stand-in Authorization Transaction Log Online Transmission Mode

1. The Issuer sends an online transmission initiation request to GSCS (0820);

2. GSCS returns the online transmission initiation response to the Issuer (0830);
3. GSCS sends the stand-in authorization advice message first in sequence to the Issuer;
4. The Issuer responds to GSCS (If GSCS does not receive the response, the transaction will be sent repeatedly
until GSCS receives the response);
Repeat 3 and 4 until…
5. The Issuer sends an online transmission termination request to GSCS (0820);
6. GSCS responds to the Issuer (0830) and stops sending any stand-in authorization advice message.

UPI CONFIDENTIAL 36
 Part I: Transaction Processing

4 Stand-in Authorization Parameter Advice Transaction Processing

4.1 Overview
The transaction is sent by the Issuer to UPI. Each advice message carries one piece of parameter synchronization
information for stand-in authorization.

4.2 Stand-in Authorization Parameter Advice Transaction Processing Flow

GSCS Issuer

Figure 33 Transaction Processing of Stand-in Authorization Parameter Advice Transaction

1. The Issuer sends the stand-in authorization parameter advice (0620) to GSCS;
2. GSCS returns the stand-in authorization parameter response (0630) to the Issuer.
If the Issuer is not able to send the stand-in authorization parameter advice transaction to GSCS, or fails to receive
any response due to timeout, or receives a rejection response, the stand-in authorization parameter advice
transaction will be stored in the storage queue.

UPI CONFIDENTIAL 37
 Part I: Transaction Processing

5 Payment Token Transaction Processing

5.1 Payment Token Transaction Processing Principle
If the Issuer applies for the UnionPay Payment Token Service, GSCS will verify the token and token-related information
in a financial transaction, and then de-tokenize it before forwarding the transaction to Issuer.

5.2 Payment Token Transaction Processing Flow

5.2.1 Normal Processing Flow
The Acquirer and the Issuer shall follow the PAN-based transaction flow to process the Payment Token transaction.
UPI TSP will de-tokenize the Payment Token before transferring the request message, advice message, or manual
message to the Issuer.
The settlement procedure for the Payment Token transaction is also the same as that for the PAN-based transaction.

5.2.2 Exception Processing Flow

When any abnormality occurs, the Acquirer and the Issuer shall follow the PAN-based transaction flow to process
the Payment Token transaction. If UPI TSP system encounters a system error or communication failure during de-
tokenization, GSCS will inform the Acquirer with response code “96” and will not forward this message to the Issuer.

5.3 Payment Token Transaction Type

Payment Token transactions flow from the terminal to the Acquirer, the Acquirer to GSCS, and GSCS to the Issuer.
The Payment Token transaction types are as follows:
Table 4 Payment Token Single Message Transaction Types

Transaction Type Transaction Name

Purchase Purchase (Lump-sum Payment)
Purchase (Installment Payment)
MO/TO Purchase
Purchase Reversal Purchase Reversal (Lump-sum Payment)
Purchase Reversal (Installment Payment)
MO/TO Purchase Reversal
Purchase Cancellation Purchase Cancellation (Lump-sum Payment)
Purchase Cancellation (Installment Payment)
MO/TO Purchase Cancellation
Purchase Cancellation Reversal Purchase Cancellation Reversal (Lump-sum Payment)
Purchase Cancellation Reversal (Installment Payment)
MO/TO Purchase Reversal
Refund Refund (Online)
MO/TO Refund (Online)
Installment Payment Refund (Online)
Manual Refund

UPI CONFIDENTIAL 38
 Part I: Transaction Processing

Transaction Type Transaction Name

Credit Voucher
Pre-authorization Pre-authorization
Pre-authorization Cancellation Pre-authorization Cancellation
Manual Pre-authorization Cancellation
Pre-authorization Reversal Pre-authorization Reversal
Pre-authorization Cancellation Reversal Pre-authorization Cancellation Reversal
Manual Pre-authorization Cancellation Reversal
Pre-authorization Completion (request)
Pre-authorization Completion (advice)
Manual Pre-authorization Completion
Pre-authorization Completion Cancellation Pre-authorization Completion Cancellation
Pre-authorization Completion Reversal Pre-authorization Completion Reversal
Pre-authorization Completion Cancellation Reversal Pre-authorization Completion Cancellation Reversal
Pre-authorization MO/TO Pre-authorization
Pre-authorization Cancellation MO/TO Pre-authorization Cancellation
Manual MO/TO Pre-authorization Cancellation
Pre-authorization Reversal MO/TO Pre-authorization Reversal
Pre-authorization Cancellation Reversal MO/TO Pre-authorization Cancellation Reversal
Manual MO/TO Pre-authorization Cancellation
Reversal
Pre-authorization Completion MO/TO Pre-authorization Completion (Request)
MO/TO Pre-authorization Completion (Advice)
Manual MO/TO Pre-authorization Completion
Pre-authorization Completion Cancellation MO/TO Pre-authorization Completion Cancellation
Pre-authorization Completion MO/TO Pre-authorization Completion
(request) reversal (Request) Reversal
Pre-authorization Completion Cancellation Reversal MO/TO Pre-authorization Completion Cancellation
Reversal
Settlement Advice Settlement Advice
MO/TO Settlement Advice
Cash Withdrawal ATM Cash Withdrawal
Manual Cash Withdrawal
Cash Withdrawal Reversal ATM Cash Withdrawal reversal
Manual Cash Withdrawal reversal

UPI CONFIDENTIAL 39
 Part I: Transaction Processing

Transaction Type Transaction Name

Balance Inquiry ATM Balance Inquiry
Balance Inquiry
Account Verification Account Verification
Primary credit Primary Credit
Primary credit Confirmation Primary Credit Confirmation
Remittance Remittance Verification
Online Remittance
Table 5 Payment Token Dual Message Transaction Types

Transaction Type Transaction Name

Authorization Purchase Authorization (Lump-sum Payment)
Manual Cash Withdrawal
Purchase Authorization (Instalment Payment)
MO/TO Authorization
Authorization Cancellation Purchase Authorization Cancellation (Lump-sum Payment)
Purchase Authorization Cancellation (Instalment Payment)
Manual Authorization Cancellation
Manual MOTO Authorization Cancellation
MO/TO Authorization Cancellation
Authorization Reversal Purchase Authorization Reversal (Lump-sum Payment)
Manual Cash Withdrawal Reversal
Purchase Authorization Reversal (Instalment payment)
MO/TO Authorization Reversal
Authorization Cancellation Reversal Purchase Authorization Cancellation Reversal (Lump-sum Payment)
Purchase Authorization Cancellation Reversal (Instalment Payment)
MO/TO Authorization Cancellation Reversal
Manual Authorization Presentment Manual Authorization Presentment
Balance Inquiry Balance Inquiry

UPI CONFIDENTIAL 40
 Part I: Transaction Processing

6 QRC-based Payment Transaction Processing

QR Code (QRC) Based Payment is a convenient, secure, and fast payment method for both Merchants and
Cardholders. Members that intend to support QRC-based Payment are strongly recommended to read the related
product scheme guide.

6.1 Merchant-presented QRC-based Payment Transaction Processing

6.1.1 Overview
Merchant-presented QRC-based Payment refers to the process where the Cardholder scans the QR Code presented
by the Merchant and a payment request is then initiated by the mobile application. Currently, it is applied in purchase,
fixed-amount authorization and subsequent cancellation, reversal, and refund transactions.

6.1.2 Normal Payment Processing Flow

If the Cardholder makes the payment for a purchase transaction or a fixed-amount authorization transaction by
scanning the QR Code presented by the Merchant, the payment application on the Cardholder’s mobile device will
initiate a QRC-based Payment request to UnionPay Mobile Payment Service (UMPS) system, and UMPS will return
the transaction result from the Issuer to the mobile application. The processing flow between UMPS and the mobile
payment application is defined in the UnionPay Mobile Payment Service Technical Specifications. The processing flow
among the UMPS, the Acquirer, GSCS and the Issuer is as follows:

UMPS Acquirer GSCS Issuer

1 Payment Request
2 Payment Request
3 Payment Request

4 Payment Response
5 Payment Response
6 Payment Response

Figure 34 Processing Flow of Merchant-presented QRC-based Payment

1. Upon receiving the payment request message from the mobile application, the UMPS forwards the payment
request to the Acquirer;
2. The Acquirer checks the validity of the account information and other credentials of the Merchant, and sends
the payment request to GSCS if the information is valid. Otherwise, the Acquirer sends a negative response to
the UMPS;
3. GSCS forwards the payment request to the Issuer;
4. The Issuer returns the transaction outcome to GSCS;
5. GSCS returns the payment response to the Acquirer;
6. The Acquirer returns the payment response to the UMPS, and the UMPS returns the transaction result to the
application.
Note: The processing flow is applicable to purchase transaction, or fixed-amount authorization transaction.
UPI CONFIDENTIAL 41
 Part I: Transaction Processing

6.1.3 Exception Payment Processing Flow

When the Acquirer does not receive the payment response message within certain time, it shall send a reversal
message to GSCS, and send a response message to UMPS with the response code “98” (timeout).
When the UMPS does not receive the response message from the Acquirer in 60 seconds, it will send a transaction
result inquiry message to the Acquirer to check the transaction outcome.

6.1.4 Normal Cash Withdrawal Processing Flow

If the Cardholder selects QRC Cash Withdrawal and enters the transaction amount on the ATM, a dynamic QR Code
is generated and displayed on the ATM screen. After scanning the QR Code, the payment application on the
Cardholder’s mobile device will display the ATM information and the transaction amount for the Cardholder to
confirm. Then, the application gateway sends a message to notify UnionPay Mobile Payment Service (UMPS) system
of the ATM cash withdrawal transaction. UMPS then sends a cash withdrawal request message to the Acquirer and
the transaction message flows among the UMPS, the Acquirer, the GSCS, and the Issuer (message flow is shown in
the chart below). After UMPS receives the response message, it will return the transaction result to the mobile
application. Please note that the message flow between UMPS and the application gateway is defined in the
UnionPay Mobile Payment Service Technical Specifications – Book 3 QRC Payment.

UMPS Acquirer GSCS Issuer

1 Cash Withdrawal
Request 2 Cash Withdrawal
Request 3 Cash Withdrawal
Request

4 Cash Withdrawal
5 Cash Withdrawal Response
6 Cash Withdrawal Response
Response

Figure 35 Processing Flow of Cash Withdrawal in the Merchant-presented QRC Mode

1. Upon receiving the message from the application gateway, UMPS sends the ATM cash withdrawal request to
the Acquirer after de-tokenization;
2. After the Acquirer completes the validity check of the Merchant-presented QRC and the ATM transaction risk
control, it instructs the ATM to display the account number and the transaction amount, and ATM then prompts
the Cardholder to enter the PIN. After the ATM collects the PIN, the Acquirer submits the Merchant-presented
ATM cash withdrawal request to GSCS;
3. GSCS forwards the transaction request to the Issuer;
4. The Issuer determines whether to approve the transaction and returns the transaction result in the response
message to GSCS;
5. GSCS returns the transaction response to the Acquirer;
6. Based on the received transaction result, the Acquirer instructs the ATM accordingly, and returns the result to
UMPS.

6.1.5 Exception Cash Withdrawal Processing Flow

UPI CONFIDENTIAL 42
 Part I: Transaction Processing
When the Acquirer does not receive the cash withdrawal response message within a certain time frame, it shall send
a reversal message to GSCS, and send a response message to UMPS with the response code “98” (timeout).
In the case of a successful Merchant-presented QRC cash withdrawal transaction, the Acquirer shall submit a reversal
transaction if any abnormal case occurs subsequently, such as the ATM cannot dispense cash, and the GSCS shall
notify UMPS of the cancelled transaction directly.
When UMPS does not receive the response message from the Acquirer within 60 seconds, it will send a transaction
result inquiry message to the Acquirer to obtain the transaction result.

6.1.6 Transaction Result Inquiry Processing Flow

UMPS Acquirer

1 Transaction Result
Inquiry Request

2 Transaction Result
Inquiry Response

Figure 36 Processing Flow of Transaction Result Inquiry

1. UMPS sends a transaction result inquiry request to the Acquirer;

2. The Acquirer responds with the QRC-based Payment transaction result.
Note: When UMPS does not receive the response message from the Acquirer within 60 seconds, UMPS can re-send
the inquiry message.

6.1.7 Transaction Cancellation/Refund Processing Flow

The message flows of QRC-based Payment cancellation and refund are the same as those of bankcard payment
cancellation and refund for Acquirers and Issuers.

6.2 Consumer-presented QRC-based Payment Transaction Processing

6.2.1 Overview
Consumer-presented QRC-based payment refers to the process where the Merchant scans the QR Code presented
by the consumer and initiates a payment request. Currently, it is applied in purchase, and subsequent cancellation,
reversal, and refund transactions.

6.2.2 Transaction Flow

The processing flow of the Consumer-presented QRC-based Payment transaction is the same as that of bankcard
transactions.

UPI CONFIDENTIAL 43
 Part I: Transaction Processing

7 U-plan Payment Coupon Management Transaction Processing

For the processing flow of U-plan payment coupon management transactions, including coupon write-off and coupon
reversal, please refer to the Technical Specifications on Bankcard Interoperability for U-plan Program, Pilot Version.

UPI CONFIDENTIAL 44
 Part I: Transaction Processing

8 Staged Digital Wallet Payment Transaction Processing

8.1 Overview of Staged Digital Wallet Payment
The staged digital wallet payment business provides the following three types of services:
1. Wallet loading - a transaction where the Staged Digital Wallet user uses a UnionPay Card to load the Staged
Digital Wallet account through the UPI network or a UPI-consented network. It is only applied to domestic
transactions outside of Mainland China. Account funding transaction (AFT) as well as AFT reversal transactions
are adopted for wallet loading.
2. Back-to-back purchase (B2BP) - a transaction that is initiated by the Staged Digital Wallet user at the contracted
Merchant of the Staged Digital Wallet Operator, and then processed by the Staged Digital Wallet Operator
through the UPI network or a UPI-consented network for purchasing goods or services with the UnionPay Card
number or Token that the user stored in the Staged Digital Wallet. B2BP can be applied to the following
transactions: purchase, recurring, pre-authorization (completion), authorization, refund and subsequent
cancellation and reversal transactions.
3. Balance-to-bankcard transfer - a transaction where the Staged Digital Wallet user transfers the wallet account
balance to an enrolled UnionPay Card through the UPI network or a UPI-consented network. It is only applied
to domestic transactions outside of Mainland China. Primary credit and primary credit confirmation
transactions are adopted for balance-to-bankcard transfer.

8.2 Processing Flow of Staged Digital Wallet Payment

8.2.1 Wallet Loading Processing Flow
Account funding transaction (AFT) is a single-message financial transaction, and is adopted as a debit order to
transfer fund from the bankcard account bound to a staged digital wallet into the wallet account.
The complete flow of a normal wallet loading procedure involving all participating parties is illustrated in the
following figure, and the interactions between the Acquirer, the Issuer, and GSCS are numbered in the figure.

Staged
Digital
1 2
Wallet Bankcard
Account
Acquirer 4 GSCS 3 Issuer Bound to
Staged the
Digital Wallet
Wallet
5 5
Operator

Figure 37 Processing Flow of Wallet Loading

1. When the staged digital wallet operator’s request to the Acquirer to transfer fund out of a UnionPay bankcard
account into the wallet is received, the Acquirer sends the AFT request to GSCS to initiate the wallet loading
procedure;
2. GSCS forwards the AFT request to the Issuer for authorization;
3. The Issuer responds to GSCS by returning the AFT response message;
4. The GSCS forwards the AFT response message to the Acquirer;

UPI CONFIDENTIAL 45
 Part I: Transaction Processing
5. After cutoff, GSCS conducts clearing and settlement by distributing audit trailers (COM/COMN) and reports to
the Acquirer and the Issuer.
AFT must not be cancelled under any condition. When any connection error or system malfunction occurs, an AFT
can be reversed by an AFT reversal advice.
Dual message Members can support wallet loading by initiating AFTs, but dual-message Acquirers must not conduct
presentment via outgoing settlement files.

8.2.2 Back-to-back Purchase Processing Flow

The complete flow of a normal single-message B2BP procedure is illustrated in the following figure. The interactions
between the Acquirer, the Issuer, and GSCS are numbered in the figure.

Signed
Merchant 1 2 Staged
Digital
Wallet
Acquirer 4 GSCS 3 Issuer
User
Staged Holding
Digital Bankcard
Wallet
5 5
Operator

Figure 38 Processing Flow of Back-to-back Purchase Payment

1. When the Acquirer receives the transaction information sent from the digital wallet operator, the Acquirer
sends the payment request message to GSCS to initiate the back-to-back purchase;
2. GSCS forwards the payment request message to the Issuer for authorization;
3. The Issuer responds to GSCS by returning the payment response message;
4. he GSCS forwards the payment response message to the Acquirer;
5. After cutoff, UPI conducts clearing and settlement by distributing audit trailers (COM/COMN), settlement files,
and reports to the Acquirer and the Issuer.
Both single-message and dual-message Members can support back-to-back purchase, and presentment by dual-
message Acquirers is supported via outgoing settlement files. Back-to-back purchase can be applied to: purchase,
recurring, pre-authorization (completion), authorization, refund and subsequent cancellation and reversal
transactions.

8.2.3 Balance-to-bankcard Transfer Processing Flow

For balance-to-bankcard transfer, primary credit transaction (PCT), a single-message financial transaction, is adopted
as a credit order to transfer fund from a staged digital wallet into the bankcard account bound to the wallet. Clearing
and settlement between the Acquirer and the Issuer are completed via GSCS, while those for the Merchant are at
the discretion of the digital wallet operator.
The complete flow of a normal balance-to-bankcard transfer procedure involving all participating parties is illustrated
in the following figure. The interactions between the Acquirer, the Issuer and GSCS are numbered in the figure.

UPI CONFIDENTIAL 46
 Part I: Transaction Processing

Staged
Digital
1 2
Wallet Bankcard
Account
Acquirer 4 GSCS 3 Issuer Bound to
Staged the
Digital Wallet
Wallet
5 5
Operator

Figure 39 Processing Flow of Balance-to-bankcard Transfer

1. When the digital wallet operator’s request to the Acquirer to transfer fund out of the wallet account into a
UnionPay bankcard account is received, the Acquirer sends the PCT request to GSCS to initiate the balance-to-
bankcard transfer procedure;
2. GSCS forwards the PCT request to the Issuer for authorization;
3. The Issuer responds to GSCS by returning the PCT response message;
4. The GSCS forwards the PCT response message to the Acquirer;
5. After cutoff, GSCS conducts clearing and settlement by distributing audit trailers (COM/COMN) and reports to
the Acquirer and the Issuer.
PCT must not be cancelled or reversed under any condition. When any connection error or system malfunction occurs,
a primary credit confirmation (PCC) is initiated for abnormalities processing. For details of PCT abnormalities
processing, please refer to Section 11.7.3. Online Primary Credit.

UPI CONFIDENTIAL 47
 Part I: Transaction Processing

9 Clearing and Settlement Transaction Processing

9.1 GSCS Cutoff Advice Transaction (0820/0830) Processing

GSCS Member

Figure 40 Processing Flow of GSCS Cutoff Advice

1. GSCS sends a cutoff advice (0820) to Members;

2. Members respond to GSCS by returning cutoff advice response (0830).
GSCS uses cutoff message to inform Members of settlement date change. The cutoff procedure usually starts at 23:00
(GMT+8). There are two transaction types: cutoff start and cutoff end.

9.2 Self-administered Clearing/Settlement Transaction Processing

9.2.1 Processing Flow of Online Messages amid GSCS Cutoff Period

2
GSCS Member
3

Figure 41 Processing Flow of Message Sending amid GSCS Cutoff Period

1. GSCS sends cutoff start advice (0820) to Members;

2. Members send cutoff start advice response (0830) to GSCS;
3. GSCS sends cutoff end advice (0820) to Members;
4. Members send cutoff end advice response (0830) to GSCS.

9.2.2 Processing of Clearing/Settlement Files

For Members using single message, GSCS will send them transaction audit trailer files after clearing and settlement.
For Members using dual message mode, GSCS will process the dual message presentment files sent over by them

UPI CONFIDENTIAL 48
 Part I: Transaction Processing
during clearing and settlement, and send them the selected and processed dual message settlement files. Members
of this kind can either send multiple settlement files in a batch or perform cancellation across batches.
For details, please refer to the Technical Specifications on Bankcard Interoperability - Part III File Interface.

9.3 Time Sequence of GSCS Clearing and Settlement

Time sequence means that an execution of a function must be on the premise of the completion of other functions,
or the completion of a function is the premise to continue executing other functions.
Table 6 Time Sequence Point Control Relationship of Clearing Batch Switch

System Description of Crucial Function Steps

Switch All transaction requests before switch are included into the previous clearing batch.
All transaction requests after the switch are included into the following clearing batch.
Clearing Carry out clearing according to batch identifiers of the transaction requests.
According to relevant business rules, clearing and dispute files sent over by Members prior to the time sequence
point of dual message clearing files sending stop shall be processed in the current batch, and those sent over
afterwards will be processed in the following batch. Its control relationship is demonstrated in the following table:
Table 7 Time Sequence Point of Dual Message Clearing Files Sending Stop

System Description of Crucial Function Steps

Settlement Dual message: Clearing files sent over by Members prior to this point are processed in the current
batch; clearing files sent over by Members after this point are processed in the following batch.
Dispute The same as settlement.
Control steps of cutoff start time sequence point are as follows:
Table 8 Control Steps of Cut-off Start Time Sequence Point

System Description of Crucial Function Steps

Switch All transaction requests before cutoff are included into settlement of the first day.
All transaction requests after cutoff are included into settlement of the second day, and
cancellation transactions of the previous settlement day will be rejected.
Settlement Single message: Carry out settlement according to the cutoff time identified by end of switch
Dual message:
Processing of submitted clearing files will be completed before cutoff.
The conversion from dual message to single message will be completed before cutoff.
Processing of submitted dispute files will be completed before cutoff.
Dispute
Forwarding of dispute online advice will be completed before cutoff.
Control steps of cutoff end time sequence is as follows:
Table 9 Control Steps of Cut-off End Time Sequence Point

System Description of Crucial Function Steps

Switch 1. All original request transactions sent over between cutoff start and cutoff end shall be included
into the settlement of the following day, and the settlement date of all response, reversal and

UPI CONFIDENTIAL 49
 Part I: Transaction Processing

System Description of Crucial Function Steps

cancellation transactions being processed shall follow that of the original transactions.
Cancellation transactions of the previous settlement day will be declined between cutoff start
and cutoff end, except the cancellation transactions that are allowed to be submitted on another
day.
2. All reversals of the previous settlement date will be rejected after cutoff.

UPI CONFIDENTIAL 50
 Part I: Transaction Processing

10 Dispute Resolution Transaction Processing

10.1 Description of Dispute Resolution Transaction
Dispute resolution transactions include: inquiry, inquiry response, retrieval request, retrieval request fulfillment,
credit adjustment, debit adjustment, chargeback, good faith, special credit adjustment, fee collection/fund
disbursement, etc.
Among those transactions, credit adjustment, debit adjustment, chargeback, special credit adjustment, and fee
collection/fund disbursement participate in settlement.
10.1.1 Inquiry Request and Inquiry Response, Retrieval Request and Retrieval Request
Fulfillment
The Acquirer or the Issuer can inquire of GSCS or a counterpart Member about relevant transactions through inquiry
function.
After sending out a transaction inquiry request, a Member should wait for the response from the counterparty within
given time and determine whether a dispute resolution process needs to be initiated according to the inquiry
response from the counterparty. If the inquiring party has to initiate a dispute resolution process only after receiving
the inquiry response while no response from the counterparty has been received within the given time, the inquiring
party may initiate the dispute resolution process, assuming that the counterparty acknowledges the applying inquiry
information options in the inquiry advice note by default.
The Issuer can use the retrieval request function to retrieve photocopies of original vouchers from the Acquirer via
GSCS, and then decide whether to initiate chargeback or do other processing.

10.1.2 Credit Adjustment and Credit Adjustment Cancellation

Credit adjustment refers to the situation where the Acquirer offers to transfer the surplus fund to the Issuer through
CDRS when a surplus is found in the original transaction. The Acquirer has the right to initiate credit adjustment once
within a valid time period for a settled transaction such as cash withdrawal, purchase and pre-authorization
completion.
The party that initiates credit adjustment may cancel the credit adjustment transaction that has not been settled,
replied to or approved.

10.1.3 Debit Adjustment and Debit Adjustment Cancellation

Debit adjustment is initiated by the Acquirer to put forward presentment to the Issuer through CDRS when the
Acquirer finds a deficit in the original transaction or credit adjustment error. The Acquirer has the right to initiate
debit adjustment once for a settled transaction such as cash withdrawal, purchase, pre-authorization completion,
refund, and credit adjustment.
The debit adjustment initiator may cancel the adjustment if it is not in effect or settled before the daily CDRS cut-off
time.

10.1.4 Chargeback and Chargeback Cancellation

If the Issuer has disputes on settled transactions, including cash withdrawal, purchase and pre-authorization
completion, or rejects debit adjustment initiated by the Acquirer, the Issuer can initiate chargeback.
For each settled original transaction, the Issuer has the right to initiate chargeback once and the chargeback amount
shall not be more than that of the original transaction.
The party that initiates chargeback may cancel the chargeback transaction that has not been settled, replied to, or
approved.

10.1.5 Good Faith and Good Faith Response

UPI CONFIDENTIAL 51
 Part I: Transaction Processing
Good Faith is applicable to such scenarios as dispute processing period overdue, transactions not settled, no
transaction records in GSCS, and dispute flow ended. Good Faith is initiated by the party that finds the account error,
and the Good Faith receiver gives response to the Good Faith request to indicate whether it agrees with the content.
If both parties can reach an agreement, the party with a surplus can make a payment via a special credit adjustment
transaction.
Good Faith has no corresponding cancellation transaction and is not involved in settlement.

10.1.6 Special Credit Adjustment and Special Credit Adjustment Cancellation

Special credit adjustment is applicable to such scenarios as dispute processing period overdue, transactions not
settled, no transaction records in GSCS, and dispute flow ended, and the party initiating the dispute is willing to
return the fund, without the need to match the original transaction or follow the dispute flow. The transaction is only
used to credit the funds.
The party that initiates special credit adjustment may cancel the special credit adjustment transaction that has not
been settled, replied to, or approved.

10.1.7 Fee Collection/Fund Disbursement and Fee Collection/Fund Disbursement

Cancellation
The transaction is used to accomplish specific fund transfer among Members or between GSCS and Members, such
as pick-up card award, dispute processing fee, non-compliance fines and other fees that Members pay to UPI.
Fee Collection transactions can only be initiated by GSCS, while Fund Disbursement transactions can be initiated by
GSCS or Member, and both Fee Collection transactions and Fund Disbursement transactions may be cancelled prior
to settlement.

10.2 Dispute Processing of Domestic/Cross-border Transactions

For disputes occurring in cross-border transactions of UnionPay Card, Members can log onto CDRS to initiate disputes
in the way of manual input on the interface. CDRS will not send dispute processing advice.

10.2.1 General Flow of Dispute Submit over CDRS

Members can log onto CDRS to submit disputes in the way of manual input on the interface.

1 CDRS 4

Initiator 2 3 Receiver

GSCS

Figure 42 General Processing Flow of Dispute Transactions

1. The initiator initiates the dispute processing request on CDRS;

2. CDRS submits dispute processing request to GSCS;
3. GSCS returns the dispute processing result to CDRS;

UPI CONFIDENTIAL 52
 Part I: Transaction Processing

4. The receiver inquires about the dispute result provided by GSCS on CDRS.

UPI CONFIDENTIAL 53
 Part I: Transaction Processing

11 Management and Security Control Transaction Processing

11.1 Network Management Advice Transaction (0820/0830)
11.1.1 Overview
Network management advice transaction is the exchange of network management operation information between
GSCS and Members, that is,
a) Informing Members of settlement date change (cutoff start/end)
b) Establishing and changing network status of each Member
c) Network application layer connection test
d) Members key reset request
After receiving the network management advice transaction, each Member shall send the response.
Network management advice transactions are classified into two types: transactions initiated by GSCS and
transactions initiated by Members.
Transactions initiated by GSCS include:
a) Cutoff Start/Cutoff End
b) Open and Close Members
c) Echo Test
Transactions initiated by Members include:
a) Sign On, Sign Off
b) Echo Test
c) Member key reset request (GSCS will initiate the key reset process after receiving the request)
If the sender does not receive the response, it will not re-send the transaction. If the receiver cannot send the
response, it will abandon the response directly.
Management and security control transactions are not involved in settlement.
Before a Member can do any transaction with GSCS, it shall send a Sign On message to notify GSCS that its system is
online; reversely, before a Member’s system becomes offline or in the maintenance mode, it shall send a Sign Off
message to notify GSCS that its system will be offline.
Echo test is used in network application layer communication testing conducted by a Member or GSCS when a
transaction communication abnormality occurs. Please refer to Section 11.5 Communication Abnormality for details.
In order to save system resources, it is not allowed to use echo test for network communication testing when
connection is fine. Idle connection inquiry message should be used instead (please refer to Section 6.3.4.5 in Part V
Communication Interface for details).

11.1.2 Transaction Flow

UPI CONFIDENTIAL 54
 Part I: Transaction Processing

GSCS Member

Figure 43 Processing Flow of Network Management Transaction Initiated by GSCS

1. Network management advice (0820) sent to the Member by GSCS;

2. Network management response (0830) sent to GSCS by the Member.

GSCS Member

Figure 44 Processing Flow of Network Management Initiated by Members

1. Network management advice (0820) sent to the GSCS by the Member;

2. Network management response (0830) sent to the Member by GSCS.

11.2 Key Reset Application (0820/0830) and Key Reset (0800/0810)

11.2.1 Overview
The transaction is a message used for key renewal and key synchronization between GSCS and Members. There are
two types of transactions: key reset request on the premise of receiving Member key reset application request, and
key reset request directly initiated by GSCS.

11.2.2 Transaction Flow

11.2.2.1 Key Reset on the Premise of Receiving Member’s Key Reset Application Request
A Member sends key reset application request (0820) to GSCS, and GSCS will send response (0830) immediately after
receiving the request and initiate key renewal module at the same time to generate new keys for the requesting
party and sending new keys to the requesting party in key reset request message (0800).
GSCS will abandon the message if GSCS cannot send key reset application response or key reset request to the
Member.

UPI CONFIDENTIAL 55
 Part I: Transaction Processing

2
GSCS Member
3

Figure 45 Processing Flow of Key Reset on the Premise of Receiving Member’s Key Reset Application Request

1. Key reset application advice (0820) sent to GSCS by the Member;

2. Key reset application response(0830) sent to the Member by GSCS;
3. Key reset request (0800) sent to the Member by GSCS;
4. Key reset response (0810) sent to GSCS by the Member.
11.2.2.2 Key Reset Directly Initiated by GSCS
GSCS initiates key reset request and sends it to the Member, and the Member will send response to GSCS after
receiving the request. When the Member’s system fails, GSCS will do manual processing if not receiving the response.

GSCS Member

Figure 46 Processing Flow of Key Reset Directly Initiated by GSCS

1. Key reset request (0800) sent to the Member by GSCS;

2. Key reset response (0810) sent to GSCS by the Member.

UPI CONFIDENTIAL 56
 Part I: Transaction Processing

12 Abnormality Transaction Processing

12.1 Overview
This chapter mainly stipulates processing methods of abnormalities occurring during the application interaction
among Members. The possible abnormalities include:
a) Message format error
b) Data security error
c) Communication abnormality
d) Terminal operation error

12.2 Rules of Abnormality Processing

12.2.1 Rule 1
For pre-authorization and financial messages (except for deposit transactions) in request messages, the original
transactions can be cancelled with reversal advice messages while abnormalities occur. The abnormalities are as
follows:
a) The Member cannot forward the financial transaction acceptance response to the transaction sender.
b) The Member receives reversal advice from the transaction sender.
c) The Member receives no response for a request message within the response time frame.
d) The Member receives a late acceptance response to the request message.
12.2.2 Rule 2
When Members cannot send reversal advice correctly, they shall store and forward the advice.

12.2.3 Rule 3
Members shall match with the original transaction when receiving reversal advice. If the original transaction is
matched and successful, the original transaction will be cancelled and a reversal successful response (with response
code as “00”) is sent. Neither the original transaction nor the reversal advice is involved in settlement. Otherwise, a
corresponding reject code will be given according to the specific situation.
The Issuer must properly handle repeated reversals to avoid chaos in accounting information.

12.2.4 Rule 4
Except for network management advice (including sign on/sign off, cutoff start and cutoff end, etc.) and reconciliation
advice, GSCS or the Member shall try to send the advice to the receiver by adopting store-and-forward mechanism.

12.3 Message Format Error

This section specifies the judgment and processing of messages received by Members, and herein only grammatical
errors and semantic errors of data elements in the messages are defined.

12.3.1 Message Grammatical Error

The grammatical error refers to the inconsistency in received messages with the message standards in terms of data
value scope or data type.
If this kind of error occurs in a request message or an advice message, GSCS will return the original request message
or advice message as it is and set a corresponding reject code in the newly added message header of the returned
message. The reject code will correspond to the first message grammatical error detected by GSCS.

UPI CONFIDENTIAL 57
 Part I: Transaction Processing
If this kind of error occurs in an acceptance response message of authorization or a financial transaction, or GSCS or
a Member receives such kind of error message, the Member or GSCS shall abandon the response message and send
reversal advice after timeout. If such an error occurs in the response message of an advice transaction (except for
network management advice and reconciliation advice), the sender of the advice will store and forward the advice
message.
For detailed error code definitions of data value scope or data type, please refer to Section A.4 Reject Code in Part
VI Annex.

12.3.2 Message Semantic Error

The semantic error refers to the case in which the message data is invalid to the transaction semantically though the
message data grammatically complies with the message standards of bankcard information switch.
If this kind of error occurs in a general request message or an advice message, GSCS will send a reject response to
the Acquirer directly and the response codes are listed in the following table:
Table 10 Invalid Data Content Error

Position No. Description of Data Content Error Response Code

4 Amount of transaction is 0. 13
The situations in which invalid data contents may possibly occur in reversal, cancellation and dispute processing
transaction requests are as follows:
Table 11 Invalid Data Content Errors of Reversal, Cancellation and Dispute Processing Transaction Request

Description of Data Content Error Response Code

Transaction request cannot match the original transaction. 25
Transaction is inconsistent with the original transaction amount. 64
Transaction is inconsistent with the original transaction card. number 14
Transaction is inconsistent with the original transaction terminal. 97
The original transaction is not accepted. 12
Transaction response cannot match the reversal request. Write into log for future check
If this kind of error occurs in the acceptance response message of authorization or a financial transaction, GSCS shall
abandon the response message and send reversal advice after timeout. If such an error occurs in a response message
of an advice transaction (except for network management advice and reconciliation advice), the sender of the advice
will store and forward the advice message.

12.4 Data Security Confidentiality Error

This section specifies the processing of data security confidentiality errors that occur during transactions among GSCS,
the Acquirer, and the Issuer. These errors are as follows:
a) PIN format error in request messages
b) PIN verification failure in request messages (can only be detected at the Issuer end)
c) MAC calculation error in request messages
d) MAC calculation error in advice messages
e) MAC error in response to request messages
f) MAC error in response to advice messages

UPI CONFIDENTIAL 58
 Part I: Transaction Processing

12.4.1 PIN Error

12.4.1.1 PIN Format Error in Request Messages
 Error type:
The message receiver detects format errors in PIN data blocks after decrypting the cipher text of the PIN.
 The Acquirer’s processing:
Send a reject response to the terminal.
 GSCS’s processing:
Send a reject response to the Acquirer with response code “99”.
 The Issuer’s processing:
Send a reject response to GSCS with response code “99”.
12.4.1.2 Pin Verification Failure in Request Messages
 Error type:
The Issuer detects that PIN input by the Cardholder cannot be matched.
 The Issuer’s processing:
Send a reject response to GSCS with response code “55” (incorrect PIN), if the times of PIN verification failure do not
reach the limitation set by the Issuer, otherwise with response code “38” or “75” (times of PIN input exceed
limitation).

12.4.2 MAC Error

12.4.2.1 MAC Calculation Error in Request Message
 Error type:
The message receiver detects that MAC cannot be matched.
 GSCS’s processing:
Send a reject response to the Acquirer with response code “A0”.
 The Issuer’s processing:
Send a reject response to GSCS with response code “A0”.
12.4.2.2 MAC Calculation Error in Advice Message
 Error type:
The message receiver detects that MAC cannot be matched.
 GSCS’s processing:
Send a reject response to the Acquirer with response code “A0”.
 The Issuer’s processing:
Send a reject response to GSCS with response code “A0”.
12.4.2.3 MAC Error in Response Message of Request Message
12.4.2.3.1 General Financial Transaction
 Error type:

UPI CONFIDENTIAL 59
 Part I: Transaction Processing

The message receiver detects that MAC cannot be matched.

 GSCS’s processing:
Send a reject response to the Acquirer. If the transaction is an accepted financial transaction, a reversal message shall
be initiated to the Issuer with the reversal reason (i.e. the reason code in field 60) as 4362, and this reversal
participates in reconciliation.
 Acquirer’s processing:
Send a reject response message to the terminal. If the transaction is an accepted financial transaction, a reversal
message shall be initiated to GSCS with the reversal reason as 4355, and this reversal participates in reconciliation.
12.4.2.3.2 Primary Credit Transaction
 Error type:
GSCS detects that the Issuer’s response message MAC error.
 GSCS’s processing:
Discard the erroneous response message, and forward the Acquirer’s primary credit confirmation message after
timeout.
 The Acquirer’s processing:
Send a response message to the Merchant that indicates a successful transaction with defect, and meanwhile send
a primary credit confirmation message.
12.4.2.4 MAC Error in Response Message of Advice Message
 Error type:
The message receiver detects that MAC cannot be matched.
 GSCS’s processing:
Write into the log for future check and analysis.

12.5 Communication Abnormalities

This section stipulates Members’ processing of communication failures during transactions. Communication failures
are as follows:
a) Sending request message fails
b) Sending response message to request fails
c) No response received after sending request message
d) Sending reversal advice message fails
e) Sending response message to reversal advice fails
f) No response received after sending reversal advice message
g) Receiving late response message to request message
The failures are arrayed in line with the sequence of each node that a complete transaction needs to go through.
When a Member detects communication abnormalities with other Members according to afore-mentioned failure
types, it adopts processing rules as follows:
1. It shall send the echo test message (0820) at a certain interval to test if the connection has been restored.
2. An unsent response message shall be abandoned.

UPI CONFIDENTIAL 60
 Part I: Transaction Processing
3. For a request message that needs to be forwarded, response with a response code “91” (Issuer or switch center
is inoperative) will be sent to the Acquirer.
4. Advice messages (022X and 042X) shall be saved in store-and-forward queue and sent after the connection
restores.
5. While receiving a response (0830) to echo test, which means the connection restores, the Member shall send
out the messages in the store-and-forward queue in turn.
The processing approaches, from communication abnormalities to their restoration, will not be repeated in the
failure treatments hereinafter.

12.5.1 Setting of the Issuer’s Invalid Status by GSCS

 Invalid Status
GSCS will mark an Issuer as under invalid status in the case that the Issuer cannot respond in time to reversal or other
advice messages sent from GSCS up to several consecutive times (setting can be parameterized) without signing off
from GSCS.
 GSCS Processing Method
Under this situation, GSCS will reject all request information sent to the Issuer (except for information sent to GSCS
by the Issuer).
Meanwhile, GSCS sends echo test information to the Issuer periodically (the frequency can be set according to the
specific situation, and the default is once every two seconds).
 Processing at the Restoration
When the echo test is successful, GSCS will re-send accumulated reversal messages and other advice messages.
When the Issuer completes processing of those messages, the Issuer’s status will be marked as under normal status
and GSCS starts forwarding transactions to the Issuer.
Members may process transactions under the same circumstances by referring to GSCS processing method.

12.5.2 Individual Failure

12.5.2.1 Overview
This section describes abnormalities processing flows of financial transactions, but the financial transactions in
question do not include deposit and transfer transactions. For abnormalities processing of deposit and transfer
transactions, please refer to the explanation on abnormalities processing of special transactions in this section.
The abnormalities processing in this section is in the same order as the transaction message processing. There is no
special description for some simple steps, and there are detailed explanations only for special and difficult steps.
Some concepts that may easily cause confusion are introduced prior to the flow description.
 The difference between “the sender cannot send request” and “the sender’s request is lost on the way”:
“The sender cannot send request” refers to the case in which the sender cannot send the request due to
communication failures, and this phenomenon can be detected by the sender, which is marked with ―x in the flow
chart hereinafter.
“The sender’s request is lost on the way” refers to the case in which the request sent by the sender is lost on the
way due to communication failures, and at the moment, the sender can by no means detect the status of the request
and all it knows is that it does not receive the response from the receiver. Hence, the ultimate result is transaction
timeout, which is marked with“?” in the flow chart hereinafter.
Due to the fact that the ultimate situations resulting from the two cases are different, their processing is different.
Details are shown as follows.

UPI CONFIDENTIAL 61
 Part I: Transaction Processing
 The differences among “the receiver does not receive request from the sender”, “the receiver cannot send
response” and “the receiver’s response is lost on the way” are as follows:
On the sender’s side, processing of those three situations is the same while different situations are reflected on the
receiver’s side.
The receiver does not receive request from the sender refers to the case in which the receiver does not receive the
original transaction request.
The receiver cannot send response refers to the case in which the receiver cannot deliver the response due to
communication failures, and this phenomenon can be detected by the receiver.
The receiver’s response is lost on the way refers to the case in which the response is lost on the way due to
communication failures, but this phenomenon can by no means be detected by the receiver.
Due to the fact that the ultimate situations resulting from these three cases are different, the processing methods
adopted by the receiver are different. For details, please refer to corresponding descriptions hereinafter.
12.5.2.2 Case 1- The Acquirer Cannot Forward Request from the Terminal

1 2

Terminal Acquirer GSCS Issuer

Figure 47 The Acquirer Cannot Forward Request from the Terminal

 Malfunction:
The Acquirer cannot forward the request 2 to GSCS due to communication failures.
 The Acquirer’s processing:
The Acquirer shall send the reject response 3 to the terminal directly.
12.5.2.3 Case 2- GSCS Cannot Receive Request

1 2

Terminal 3 Acquirer 4 GSCS Issuer

UPI CONFIDENTIAL 62
 Part I: Transaction Processing

Figure 48 GSCS Cannot Receive Request

 Malfunction:
The request 2 of the Acquirer is lost on the way due to communication failure. The Acquirer is in timeout due to not
receiving the response from GSCS.
 The Acquirer’s processing:
If the transaction is a financial transaction request, the Acquirer shall send the terminal the reject response 3 incurred
by timeout and meanwhile send GSCS the reversal 4 with reason code 4354 and this reversal does not participate in
reconciliation.
 GSCS’s processing:
GSCS sends the Acquirer the reject response 5 to the reversal with response code 25 and this reversal does not
participate in reconciliation.
12.5.2.4 Case 3- GSCS Cannot Forward Request to the Issuer

1 2 3

Terminal Acquirer GSCS Issuer

5 4

Figure 49 GSCS Cannot Forward Request to Issuer

 Malfunction:
GSCS cannot forward the request 3 to the Issuer due to communication failures.
 GSCS’ processing:
GSCS sends the Acquirer request reject response 4 with response code 91.
12.5.2.5 Case 4- The Issuer Cannot Receive Request

1 2 3

Terminal Acquirer 4 GSCS 5 Issuer

Figure 50 The Issuer Cannot Receive Request

UPI CONFIDENTIAL 63
 Part I: Transaction Processing

 Malfunction:
The request 3 of GSCS is lost on the way due to communication failures. GSCS is in timeout due to no response from
the Issuer.
 GSCS’s processing:
GSCS sends the Acquirer a reject response 4. If the transaction is a financial transaction request, GSCS also needs to
send the Issuer reversal message 5 with reason code 4361 and this reversal does not participate in reconciliation.
 The Issuer’s processing:
The Issuer sends GSCS reversal reject response 6 with response code 25 and this reversal does not participate in
reconciliation.
12.5.2.6 Case 5- The Issuer Cannot Send Request Response to GSCS

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7

Figure 51 The Issuer Cannot Send Request Response to GSCS

 Malfunction:
The Issuer cannot send GSCS request response 4 due to communication failures.
 The Issuer’s processing 1:
If the transaction is an accepted financial request, this reversal participates in reconciliation as internal reversal.
 GSCS’s processing:
GSCS sends the Acquirer request reject response 5 incurred by timeout with response code 98. If the transaction is
a financial transaction request, a reversal 7 also needs to be sent to the Issuer with reason code 4361.
 Issuer’s processing 2:
The Issuer sends GSCS reversal reject response 8 and this reversal does not participate in reconciliation.

UPI CONFIDENTIAL 64
 Part I: Transaction Processing

12.5.2.7 Case 6- GSCS Cannot Receive Response from the Issuer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7

Figure 52 GSCS Cannot Receive Response from the Issuer

 Malfunction:
GSCS detects timeout when it cannot receive response 4 from the Issuer after forwarding request 3 to the Issuer.
 GSCS’s processing:
GSCS sends the Acquirer request reject response 5 incurred by timeout with response code 98. If the transaction is
a financial transaction request, reversal 7 also needs to be sent to the Issuer with reason code 4361.
 The Issuer’s processing:
The Issuer sends GSCS reversal response 8 and whether the reversal shall participate in reconciliation on the Issuer’s
side depends on whether the original transaction has been accepted when the Issuer receives the reversal. If the
original transaction has been accepted, the reversal participates in reconciliation; otherwise it does not.
12.5.2.8 Case 7- GSCS Receives Late Acceptance Response from the Issuer

1 2 3

5 4 6
Terminal Acquirer GSCS Issuer
7

Figure 53 GSCS Receives Late Acceptance Response from the Issuer

 Malfunction:
GSCS detects timeout of the Issuer and sends the Acquirer reject response 4 while completing the following
processing according to Case 6 and receiving late acceptance response 6 from the Issuer.
 GSCS’s processing:
GSCS re-sends the Issuer reversal advice 7 with reason code 4360 and this reversal participates in reconciliation.
 The Issuer’s processing:

UPI CONFIDENTIAL 65
 Part I: Transaction Processing

The Issuer sends GSCS reversal response 8 and this reversal participates in reconciliation.
12.5.2.9 Case 8- GSCS Cannot Forward Request Response to the Acquirer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
9 7

10 8

Figure 54 GSCS Cannot Forward Request Response to the Acquirer

 Malfunction
GSCS cannot forward the Issuer’s request response 5 to the Acquirer.
 GSCS’s processing 1
If the transaction is an accepted financial transaction request, reversal advice 7 will be sent to the Issuer with reason
code 4363.
 The Issuer’s processing
The Issuer sends GSCS with reversal response 8. If the transaction is an accepted financial transaction request, this
reversal participates in reconciliation.
 The Acquirer’s processing
The Acquirer sends the terminal request reject response 6 incurred by timeout. If the transaction is a financial
transaction request, reversal advice 9 also needs to be sent to GSCS with reason code 4354.
 GSCS’s processing 2
GSCS sends the Acquirer reversal response 10 and this reversal does not participate in reconciliation.
12.5.2.10 Case 9- GSCS Receives Early Reversal from the Acquirer

1 2 3

4 6
Terminal Acquirer GSCS Issuer
5 7

Figure 55 GSCS Receives Early Reversal from the Acquirer

UPI CONFIDENTIAL 66
 Part I: Transaction Processing

 Malfunction:
GSCS receives the Acquirer’s reversal advice 4 without receiving the Issuer’s response within the response time frame.
 GSCS’s processing:
GSCS sends the Acquirer reversal response 5 with response code 00. After receiving transaction response 6 returned
by the Issuer, if the transaction is an accepted financial transaction request, reversal 7 shall be initiated with reason
code 4360 and this reversal participates in reconciliation. If the original transaction is not accepted, GSCS will
abandon the response directly.
12.5.2.11 Case 10- The Acquirer Cannot Receive Response from GSCS

1 2

3
Terminal Acquirer GSCS Issuer
4 5 7

6 8

Figure 56 The Acquirer Cannot Receive Response from GSCS

 Malfunction:
The Acquirer detects timeout if it does not receive response 3 from GSCS after sending request 2 to GSCS.
 The Acquirer’s processing:
The Acquirer sends the terminal request reject response 4 incurred by timeout. If the transaction is a financial
transaction request, reversal advice 5 also needs to be sent to GSCS with reason code 4354 and this reversal does
not participate in reconciliation.
 GSCS’s processing:
After receiving reversal request 5, GSCS checks the response message of the original request. If the original
transaction is accepted by the Issuer, GSCS sends the Issuer reversal advice 7 with reason code 4354 and sends the
Acquirer reversal response message with response code 00. And this reversal participates in reconciliation. If the
original transaction is not accepted by the Issuer, GSCS sends the Acquirer reversal response message 6 directly with
response code 12, and this reversal does not participate in reconciliation.
 The Issuer’s processing:
The Issuer sends GSCS reversal response 8, and this reversal participates in reconciliation on the Issuer’s side.

UPI CONFIDENTIAL 67
 Part I: Transaction Processing

12.5.2.12 Case 11- The Acquirer Receives Late Acceptance Response from GSCS

1 2 3

6 4
Terminal Acquirer GSCS Issuer
5 7 9

8 10

Figure 57 The Acquirer Receives Late Acceptance Response from GSCS

 Malfunction:
The Acquirer detects timeout at GSCS and sends the terminal reject response 5 while performing sequential
operations, and afterwards it receives late acceptance response 6 from GSCS.
 The Acquirer’s processing:
The Acquirer re-sends reversal advice 7 to GSCS with reason code 4353 and this reversal participates in reconciliation.
 GSCS’s processing:
GSCS sends the Acquirer response 8 immediately after receiving reversal advice, and sends the Issuer reversal advice
9 with reason code 4353 and this reversal participates in reconciliation.
 The Issuer’s processing:
The Issuer sends GSCS reversal response 10 and this reversal participates in reconciliation.
12.5.2.13 Case 12- The Acquirer Cannot Send Terminal Operation Instruction

1 2 3

5 4
Terminal Acquirer GSCS Issuer
6 7 9

8 10

Figure 58 The Acquirer Cannot Send Terminal Operation Instruction

 Malfunction:
The Acquirer cannot send the terminal operation instruction 6 due to communication failure.
 The Acquirer’s processing:
If the transaction is an accepted financial transaction request, the Acquirer sends GSCS reversal advice 7 with reason

UPI CONFIDENTIAL 68
 Part I: Transaction Processing

code 4356 and this reversal participates in reconciliation.

 GSCS’s processing:
GSCS sends the Acquirer response 8 immediately after receiving reversal advice and sends the Issuer reversal advice
9 with reason code 4356 and this reversal participates in reconciliation.
 The Issuer’s processing:
The Issuer sends GSCS reversal response 10 and this reversal participates in reconciliation.

12.5.3 Dual Failures

12.5.3.1 Overview
The financial transactions mentioned in the following failure processing do not include deposit and transfer
transactions. For the abnormalities processing of deposit and transfer transactions, please refer to Section 11.7
Transaction Abnormalities Processing.
12.5.3.2 Case 1- GSCS Cannot Send the Acquirer Reject Response

1 2

3
Terminal Acquirer GSCS Issuer
4 5

Figure 59 GSCS Cannot Send the Acquirer Reject Response

 Malfunction:
GSCS sends the Acquirer transaction request reject response 3 after detecting communication failures on the Issuer’s
side, but sending of the response fails due to other communication failures.
 GSCS’ processing:
GSCS abandons the response message without sending the Issuer reversal advice.
 The Acquirer’s processing:
The Acquirer sends terminal request reject response after detecting timeout at GSCS. If the transaction is a financial
transaction request, timeout reversal 5 will be sent to GSCS with reason code 4354. GSCS shall send the Acquirer
reject response 6 with response code 12 immediately after receiving reversal advice, and this reversal does not
participate in reconciliation on both the Acquirer’s side and GSCS.

UPI CONFIDENTIAL 69
 Part I: Transaction Processing

12.5.3.3 Case 2- GSCS Cannot Send the Issuer Reversal Advice

Terminal Acquirer GSCS 1 Issuer

Figure 60 GSCS Cannot Send the Issuer Reversal Advice

 Malfunction:
GSCS sends the Issuer reversal advice 1 after it detects communication failures (please refer to Section 11.5.2.7 GSCS
Receives Late Acceptance Response from the Issuer and Section 11.5.2.7 8 GSCS Cannot Forward Request Response
to the Acquirer), but sending of the reversal fails due to other communication failures.
 GSCS’s processing:
GSCS saves the unsent reversal advice in store-and-forward queue and re-sends it after the connection restores.
12.5.3.4 Case 3- The Acquirer Cannot Send GSCS Reversal Advice

Terminal Acquirer 1 GSCS Issuer

Figure 61 The Acquirer Cannot Send GSCS Reversal Advice

 Malfunction:
The Acquirer sends GSCS reversal advice 7 after detecting the previous communication failure (please refer to Section
11.5.2.11 The Acquirer Receives Late Acceptance Response from and Section 11.5.2.12 The Acquirer Cannot Send
Terminal Operation Instruction, and Section 11.6.1.1 Reversal Initiated by the Terminal), but sending of the reversal
by the Acquirer fails again due to communication failures.
 The Acquirer’s processing:
The Acquirer saves the unsent reversal advice in store-and-forward queue and re-sends it after the connection
restores.

12.5.4 Message Reason Codes Used in Communication Abnormalities

UPI CONFIDENTIAL 70
 Part I: Transaction Processing

Table 12 Message Reason Codes Used in Communication Abnormalities

Message Reason Code Explanation

4353 The Acquirer receives late response from GSCS.
4354 The Acquirer detects timeout.
4355 The Acquirer detects incorrect MAC in the response message.
4356 The Acquirer cannot send operation instruction to the terminal.
4360 GSCS receives late response from the Issuer.
4361 GSCS waits for the Issuer’s response till timeout.
4362 GSCS detects incorrect MAC in the response message from the Issuer.
4363 GSCS cannot forward response messages from the Issuer to the Acquirer.

12.6 Terminal Operation Error

This section stipulates processing by the Acquirer and GSCS in case of Terminal Operation Error, herein, Terminal
Operation Error only refers to the case in which the Terminal cannot correctly execute orders sent by the Mainframe.
12.6.1 No Communication Failure
12.6.1.1 Case 1- Reversal Initiated by the Terminal

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 9 11

8 10 12

Figure 62 Reversal Initiated by the Terminal

 Malfunction:
The terminal cannot work properly and sends the Acquirer error status, such as “ATM does not complete the cash
disbursement”, “POS terminal initiates reversal automatically”, etc.
 The Acquirer’s processing:
In reversal advice, reason code 4351 means transaction fails at the terminal.

12.6.2 Communication Failure

UPI CONFIDENTIAL 71
 Part I: Transaction Processing

12.6.2.1 Case 1- The Acquirer Cannot Send GSCS Reversal Incurred by Terminal Operation Error

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 9

Figure 63 The Acquirer Cannot Send GSCS Reversal Incurred by Terminal Operation Error

 Malfunction:
The Acquirer cannot send GSCS reversal advice 9 incurred by terminal operation error due to communications failures
(please refer to section 11.6.1.1 Reversal Initiated by the Terminal).
 The Acquirer’s processing:
The Acquirer saves the reversal advice in store-and-forward queue and re-sends it after the connection restores.
12.6.3 Message Reason Codes Used in Terminal Operation Error
Table 13 Message Reason Codes Used in Terminal Operation Error

Message Reason Code Explanation

4351 Reversal initiated by the terminal (full amount)
4352 Reversal initiated by the terminal (partial amount)

12.7 Transaction Abnormalities Processing Flow

This section specifies abnormalities processing flows for several special transactions.
The abnormalities processing in this section is in the same order as the transaction message processing. There is no
special description for some simple steps, and there are detailed explanations only for special and difficult steps.
Under some circumstances, the processing adopted by the Acquirer and the Issuer are different, though processing
by GSCS is the same.
For distinctions and explanations of the following situations that can be easily confused, please refer to Section 11.5.2
 “the sender cannot send request” and “request sent by the sender is lost on the way”
 “the receiver does not receive request from the sender”, “the receiver cannot send response” and “response
sent by the receiver is lost on the way”

12.7.1 Remittance (Online) Transaction Abnormalities Processing

UPI CONFIDENTIAL 72
 Part I: Transaction Processing

12.7.1.1 Case 1- The Acquirer Cannot Receive Remittance Verification Response

1 2 3

Terminal Acquirer GSCS Issuer

6 5 4

Figure 64 The Acquirer Cannot Receive Remittance Verification Response

 Malfunction:
The Acquirer cannot receive remittance verification response 5 due to communications failure.
 GSCS’s processing:
No processing.
 The Acquirer’s processing:
The Acquirer sends time-out response 6 to the terminal, which means the Acquirer cannot receive the response from
GSCS.
 The Terminal’s processing:
Transaction fails. The terminal returns the funds to the customer and does not initiate the subsequent remittance
transaction. But it can restart the remittance verification transaction.
12.7.1.2 Case 2- The Acquirer Receives “Non-acceptance” Remittance Verification Response

1 2 3

Terminal Acquirer GSCS Issuer

6 5 4

Figure 65 The Acquirer Receives “Non-acceptance” Remittance Verification Response

 Malfunction
The Acquirer receives “non-acceptance” remittance verification response 5.
 GSCS’s processing:
No processing.

UPI CONFIDENTIAL 73
 Part I: Transaction Processing

 The Acquirer’s processing:

No processing.
 The terminal’s processing:
Transaction fails. The terminal returns the funds to the customer and stops the subsequent remittance transaction.
But it can restart the remittance verification transaction.
12.7.1.3 Case 3- The Terminal Receives “Non-acceptance” Remittance Transaction Response

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 66 The Terminal Receives “Non-acceptance” Remittance Transaction Response

 Malfunction:
The terminal receives “non-acceptance” remittance transaction response 12.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds and informs the customer that “remittance succeeds, and
funds transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.4 Case 4- The Terminal Cannot Send Remittance Request

1 2 3

Terminal 6 Acquirer 5 GSCS 4 Issuer

Figure 67 The Terminal Cannot Send Remittance Request

 Malfunction:
The terminal cannot send Remittance Request 7.

UPI CONFIDENTIAL 74
 Part I: Transaction Processing

 The terminal’s processing:

It is not necessary to re-send Remittance Request. Transaction succeeds. The terminal accepts the funds. It informs
the customer that “remittance succeeds, and funds transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.5 Case 5- The Acquirer Cannot Receive Transfer Request

1 2 3

Terminal 6 Acquirer 5 GSCS 4 Issuer

Figure 68 The Acquirer Cannot Receive Transfer Request

 Malfunction:
The terminal sends remittance request 7 to the Acquirer, but the request is lost.
 The terminal’s processing:
It is not necessary to re-send remittance request. Transaction succeeds. The terminal accepts the funds. It informs
the customer that “remittance succeeds, and funds transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.6 Case 6- The Acquirer Cannot Forward Transfer Request from the Terminal

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8

Figure 69 The Acquirer Cannot Forward Transfer Request from the Terminal

 Malfunction:
Account Verification succeeds. But the Acquirer cannot forward Remittance Request 8 from the terminal due to

UPI CONFIDENTIAL 75
 Part I: Transaction Processing

communication error.
 The Acquirer’s processing:
The Acquirer sends Reject Response 9 to the terminal as soon as it detects the failure of forwarding Remittance
Transaction.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.7 Case 7- GSCS Cannot Receive Remittance Request

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8

Figure 70 GSCS Cannot Receive Remittance Request

 Malfunction:
Remittance verification succeeds. But GSCS cannot receive remittance request 8 from the Acquirer, which is lost due
to communication error.
 The Acquirer’s processing:
The Acquirer sends Reject Response 9 to the terminal when the transaction time-outs.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.

UPI CONFIDENTIAL 76
 Part I: Transaction Processing

12.7.1.8 Case 8- GSCS Cannot Forward Remittance Request to the Issuer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

11 10

Figure 71 GSCS Cannot Forward Remittance Request to the Issuer

 Malfunction:
Remittance verification succeeds. But GSCS cannot forward remittance request 9 to the Issuer due to communication
error.
 GSCS’s processing:
GSCS sends Reject Response 10 to the Acquirer as soon as it detects the failure of forwarding Remittance Request.
 The Acquirer’s processing:
The Acquirer forwards Reject Response 11 to the terminal.
 The terminal’s processing:
Transaction succeeds. It accepts the funds. It informs the customer that “remittance succeeds, and funds transfer
may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.9 Case 9- The Issuer Cannot Receive Remittance Request

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

11 10

Figure 72 The Issuer Cannot Receive Remittance Request

 Malfunction:
Account Verification succeeds. But the Issuer cannot receive Remittance Request 9 from GSCS, which is lost due to

UPI CONFIDENTIAL 77
 Part I: Transaction Processing

communication error.
 GSCS’s processing:
GSCS sends Reject Response 10 to the Acquirer when the Issuer’s response time-outs.
 The Acquirer’s processing:
The Acquirer forwards Reject Response 11 to the terminal.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.10 Case 10- The Issuer Cannot Send Remittance Request Response to GSCS

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 73 Issuer Cannot Send Remittance Request Response to GSCS

 Malfunction:
Remittance Verification succeeds. But the Issuer cannot send Remittance Request Response 10 to GSCS due to
communication error.
 GSCS’s processing:
GSCS sends Reject Response 11 to the Acquirer when the Issuer’s response time-outs.
 The Acquirer’s processing:
The Acquirer forwards Reject Response 12 to the terminal.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.

UPI CONFIDENTIAL 78
 Part I: Transaction Processing

12.7.1.11 Case 11- GSCS Cannot Receive Remittance Response from the Issuer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 74 GSCS Cannot Receive Remittance Response from the Issuer

 Malfunction:
Account Verification succeeds. But GSCS cannot receive Remittance Request Response 10 from the Issuer, which is
lost due to communication error.
 GSCS’s processing:
GSCS sends Reject Response 11 to the Acquirer when the Issuer’s response time-outs.
 The Acquirer’s processing:
The Acquirer forwards Reject Response 12 to the terminal.
 Terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.12 Case 12- GSCS Receives Late Remittance Response from the Issuer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

11 10 12

Figure 75 GSCS Receives Late Remittance Response from the Issuer

 Malfunction:
Account Verification succeeds. But GSCS receives Late Remittance Request Response 12 from the Issuer after it sends

UPI CONFIDENTIAL 79
 Part I: Transaction Processing

Reject Response 10 to the Acquirer due to communication error.

 GSCS’s processing:
GSCS sends Reject Response 10 to the Acquirer when the Issuer’s response time-outs and then receives Late Transfer
Response from the Issuer. GSCS does not process Response 12 and discards it.
 The Acquirer’s processing:
The Acquirer forwards Reject Response 11 to the terminal.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
The Acquirer credits the Issuer’s account by manual remittance transaction.
12.7.1.13 Case 13- GSCS Cannot Forward Remittance Response to the Acquirer

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 76 GSCS Cannot Forward Remittance Response to the Acquirer

 Malfunction:
Account Verification succeeds. But GSCS cannot send remittance response 11 to the Acquirer due to network issues.
 The Acquirer’s processing:
Wait for remittance response time out, and then send reject code 12 to the terminal.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
If Response 11 is Acceptance Response, GSCS will settle this transaction. There will be no dispute and further
processing is not needed. If Response 11 is Non-Acceptance Response, the Acquirer should credit the Issuer’s account
by manual remittance transaction.

UPI CONFIDENTIAL 80
 Part I: Transaction Processing

12.7.1.14 Case 14- The Acquirer Cannot Receive Remittance Response from GSCS

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 77 The Acquirer Cannot Receive Remittance Response from GSCS

 Malfunction:
Account Verification succeeds. But the Acquirer cannot receive Remittance Request Response 11 from GSCS, which
is lost due to communication error.
 The Acquirer’s processing:
The Acquirer sends Reject Response 12 to the terminal when the response time-outs.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
If Response 11 is Acceptance Response, GSCS will settle this transaction. There will be no dispute and further
processing is not needed. If Response 11 is Non-Acceptance Response, the Acquirer should credit the Issuer’s account
by manual remittance transaction.
12.7.1.15 Case 15- The Acquirer Receives Late Remittance Response from GSCS

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

11 12 10

Figure 78 The Acquirer Receives Late Remittance Response from GSCS

 Malfunction:
Account Verification succeeds. But the Acquirer receives Late Remittance Request Response 12 from GSCS after it
sends Time-out Response 11 to the terminal due to communication error.

UPI CONFIDENTIAL 81
 Part I: Transaction Processing

 The Acquirer’s processing:

No processing. Discard Response 12.
 The terminal’s processing:
Transaction succeeds. The terminal accepts the funds. It informs the customer that “remittance succeeds, and funds
transfer may be delayed”.
 Further processing:
If Response 12 is Acceptance Response, GSCS will settle this transaction. There will be no dispute and further
processing is not needed. If Response 12 is Non-Acceptance Response, the Acquirer should credit the Issuer’s account
by manual remittance transaction.
12.7.1.16 Case 16- The Acquirer Cannot Send Remittance Response to the Terminal

1 2 3

6 5 4
Terminal Acquirer GSCS Issuer
7 8 9

12 11 10

Figure 79 The Acquirer Cannot Send Remittance Response to the Terminal

 Malfunction:
Account Verification succeeds. But the Acquirer cannot send Response 12 to the terminal due to communication
error.
 The terminal’s processing:
Wait until Response time-outs. Transaction succeeds. The terminal accepts the funds. It informs the customer that
“remittance succeeds, and funds transfer may be delayed”.
 Further processing:
If Response 12 is Acceptance Response, there will be no dispute and further processing is not needed. If Response
12 is Non-Acceptance Response, the Acquirer should credit the Issuer’s account by manual remittance transaction.

12.7.2 Designated Account Loading and Cash Loading of E-cash Application based on UICS
Debit/Credit Standard
If reversal is triggered when a designated account loading transaction initiated does not work. Please refer to Section
11.5.2 Individual Failure for processing flow and principles.
A cash loading transaction equals to deposit. Since a loading transaction must be approved by a terminal, only
reversal advice instead of confirmation advice can be sent. Please refer to Section 11.5.2 Individual Failure for
processing flow and principles.
If the terminal fails to communicate with the card, it should send reversal advice.

12.7.3 Online Primary Credit

UPI CONFIDENTIAL 82
 Part I: Transaction Processing
Abnormalities processing flows of primary credit transactions (PCT) follow the rule that UPI can reject primary credit
confirmation (PCC) from the Acquirer, but the Issuer must not reject PCC from UPI.
12.7.3.1 Case 1- GSCS Cannot Receive PCT Request

Acquirer 2 GSCS Issuer

Figure 80 GSCS Cannot Receive PCT Request

 Malfunction:
Due to communications failure, PCT Request 1 from the Acquirer to GSCS is lost during transmission. Transaction
timeout occurs owing to the Acquirer’s failure to receive the response from GSCS.
 Acquirer’s processing
The Acquirer forwards the PCC 2 to GSCS.
 GSCS’s processing
GSCS sends rejection Response 3 to the Acquirer, and Response Code is 12.
12.7.3.2 Case 2- GSCS Cannot Forward PCT Request to the Issuer

1 2

Acquirer GSCS Issuer

Figure 81 GSCS Cannot Forward PCT Request to the Issuer

 Malfunction:
Due to communications failure, GSCS cannot forward the Acquirer’s PCT Request 2 to the Issuer.
 GSCS’s processing:
GSCS sends rejection Response 3 to Acquirer, and Response Code is 91. This PCT transaction will not participate in
settlement.

UPI CONFIDENTIAL 83
 Part I: Transaction Processing

12.7.3.3 Case 3- The Issuer Cannot Receive PCT Request from GSCS

1 2

Acquirer 3 GSCS 5 Issuer

4 6

Figure 82 The Issuer Cannot Receive PCT Request from GSCS

 Malfunction:
Due to communications failure, PCT Request 2 sent by GSCS is lost during transmission. The transaction timeout
occurs because GSCS and the Acquirer cannot receive the response from the Issuer.
 The Acquirer’s processing:
The Acquirer sends a PCC 3 to GSCS.
 GSCS’s processing:
Once GSCS receives PCC 3, it sends approval Response 4 to the Acquirer with Response Code A6, and then forwards
the confirmation to the Issuer.
 The Issuer’s processing:
The Issuer will return Response 6 to GSCS with Response Code A4 when it receives PCC 5, and PCC transaction will
participate in settlement. The Issuer shall post to the Cardholder’s account if the transaction information has been
successfully verified. If verification or posting fails, the Issuer shall initiate dispute processing such as credit
adjustment.
12.7.3.4 Case 4- The Issuer Cannot Send PCT Response to GSCS

1 2

3
Acquirer GSCS Issuer
4 6

5 7

Figure 83 The Issuer Cannot Send PCT Response to GSCS

 Malfunction:
Due to communications failure, the Issuer cannot send Response 3 to GSCS’s request.

UPI CONFIDENTIAL 84
 Part I: Transaction Processing

 The Acquirer’s processing:

The Acquirer sends a PCC 4 to GSCS.
 GSCS’s processing:
Once GSCS receives PCC 4, it sends approval Response 5 to the Acquirer with Response Code A6, and then forwards
the confirmation to the Issuer.
 The Issuer’s processing:
The Issuer will return Response 7 to GSCS once it receives PCC 6. If the original PCT is accepted, Response Code will
be 00. If the original PCT is rejected, Response Code will be A5. PCC transaction will participate in settlement on the
Issuer’s side. If the original PCT is rejected, the Issuer shall process the dispute by means of credit adjustment without
posting to the Cardholder’s account.
12.7.3.5 Case 5- GSCS Cannot Receive PCT Response from the Issuer

1 2

3
Acquirer GSCS Issuer
4 6

5 7

Figure 84 GSCS Cannot Receive PCT Response from the Issuer

 Malfunction:
After sending PCT Request 2 to the Issuer, GSCS cannot receive Response 3 from the Issuer. Namely, GSCS detects a
transaction timeout.
 The Acquirer’s processing:
The Acquirer sends a PCC 4 to GSCS.
 GSCS’s processing:
Once GSCS receives PCC 4, it sends approval Response 5 to the Acquirer with Response Code A6, and then forwards
the confirmation to the Issuer.
 The Issuer’s processing:
The Issuer will return Response 7 to GSCS once it receives PCC 6. If the original PCT is accepted, Response Code will
be 00. If the original PCT is rejected, Response Code will be A5. PCC transaction will participate in settlement on the
Issuer’s side. If the original PCT is rejected, the Issuer shall process the dispute by means of credit adjustment without
posting to the Cardholder’s account.

UPI CONFIDENTIAL 85
 Part I: Transaction Processing

12.7.3.6 Case 6- GSCS Receives Late PCT Response from the Issuer

1 2

Acquirer GSCS Issuer

Figure 85 GSCS Receives Late PCT Response from the Issuer

 Malfunction:
After GSCS detects a transaction timeout of the Issuer and processes the case as shown in Case 4, it then receives a
late Response 3 from the Issuer.
 GSCS’s processing:
GSCS will abandon the late Response 3 without further processing.
12.7.3.7 Case 7- GSCS Cannot Forward PCT Response to the Acquirer

1 2

4 3
Acquirer GSCS Issuer
5

Figure 86 GSCS Cannot Forward PCT Response to the Acquirer

 Malfunction:
Due to communications failure, GSCS cannot forward the Issuer’s Response 4 to the Acquirer.
 GSCS’s processing 1
GSCS will abandon this response directly. If PCT has been accepted, it will participate in settlement. If not, it will not
participate in settlement.
 The Acquirer’s processing
The Acquirer will initiate PCC 5 to GSCS.
 GSCS’ s processing 2
If the original PCT has been accepted, GSCS will send Response 6 with Response Code 00 to the Acquirer, and PCT

UPI CONFIDENTIAL 86
 Part I: Transaction Processing
will participate in settlement on both the Acquirer’s and the Issuer’s side. If the original PCT has been rejected, GSCS
will send Response 6 with Response Code of the original PCT. In this case, neither PCT nor PCC will participate in
settlement.
12.7.3.8 Case 8- The Acquirer Cannot Receive Response Forwarded by GSCS

1 2

4 3
Acquirer GSCS Issuer
5

Figure 87 The Acquirer Cannot Receive PCT Response Forwarded by GSCS

 Malfunction:
Due to communications failure, the Acquirer cannot receive Response 4 from GSCS.
 GSCS’s processing 1
GSCS will abandon this response directly. If PCT has been accepted, it will participate in settlement. If not, it will not
participate in settlement.
 The Acquirer’s processing
The Acquirer will initiate PCC 5 to GSCS.
 GSCS’ s processing 2
If the original PCT has been accepted, GSCS will send Response 6 with Response Code 00 to the Acquirer, and PCT
will participate in settlement on both the Acquirer’s and the Issuer’s side. If the original PCT has been rejected, GSCS
will send Response 6 with Response Code of the original PCT. In this case, neither PCT nor PCC will participate in
settlement.
12.7.3.9 Case 9- The Acquirer Receives Late Response from GSCS

Acquirer 1 GSCS Issuer

Figure 88 The Acquirer Receives Late PCT Response from GSCS

UPI CONFIDENTIAL 87
 Part I: Transaction Processing

 Malfunction:
After detecting a GSCS timeout and performing the subsequent processing as shown in Case 8, the Acquirer receives
a late Response 1 from GSCS.
 The Acquirer’s processing:
The Acquirer shall abandon Response 1 and process the settlement as shown in Case 8.
12.7.3.10 Case 10- MAC Verification Error in the Issuer’s Response
If the Issuer returns a successful response with MAC verification failure, GSCS will abandon this response and wait
for the Acquirer to initiate PCC. Once GSCS receives PCC, it sends approval Response to the Acquirer with Response
Code A6, and then forwards the confirmation to the Issuer. When the Issuer receives the PCC forwarded by GSCS, it
shall return to GSCS with a Response Code 00 because the original PCT is a successful transaction on the Issuer’s side.
PCC transaction will participate in settlement on the Issuer’s side.
If the Issuer returns a rejection response with MAC verification failure, GSCS will forward this response to the Acquirer
directly.
12.7.3.11 Case 11- The Issuer Returns Response Code 98
If GSCS receives Response Code 98 from the Issuer, it will abandon this response and process the case as shown in
Case 5.

UPI CONFIDENTIAL 88