China Transactions EMV

Technical Specifications on Bankcard
Interoperability
(Version 2.1)
Part I Transaction Processing
October 2011
THIS PAGE INTENTIONALLY LEFT BLANK.
Part I: Transaction Processing
Table of Contents
Using this Document .................................................................................... 1
1
Application Scope .................................................................................. 4
References .............................................................................................. 5
Terms and Definitions ............................................................................ 6
General Processing Flows of Transactions ........................................ 11

4.1
Request and Advice Transaction .......................................................................... 11
4.1.1
Request Transaction ............................................................................... 11
4.1.2
4.1.3
Advice Transactions ................................................................................ 11

Normal Processing Flow of Request Transaction............................... 12
4.1.4
Normal Processing Flow of Advice Transaction ................................. 13
4.2
Store-and-forward Mechanism of Transaction Message ............................... 15
Explanation on Transaction Switch Processing ................................. 16

5.1
Single-message Transactions Processing ........................................................ 16
5.1.1
Pre-authorization Transaction 0100/0110 ............................................. 16
5.1.2
5.1.3
MO/TO Pre-authorization Transaction 0100/0110 ................................ 16

Pre-authorization Cancellation Transaction (Online) 0100/0110 ....... 16
5.1.4
MO/TO Pre-authorization Cancellation Transaction (Online)
0100/0110 ................................................................................................................. 17
5.1.5
Financial Transaction 0200/0210 ........................................................... 17
5.1.6
Balance Inquiry 0200/0210 ...................................................................... 21
5.1.7
5.1.8
UnionPay Card Exchange Rate Inquiry 0600/0610 .............................. 21

Reversal Advice 0420/0430 ..................................................................... 22
5.1.9
5.1.10
Financial Advice Transaction 0220/0230 .............................................. 25

Manual Transaction ................................................................................. 30
5.1.11 Cross-border Single Message Transaction verified via CUPSecure 36

5.2
Dual-message Transaction Processing .............................................................. 36
5.2.1
5.2.2
Authorization Transaction ....................................................................... 36

Authorization Cancellation Transaction ................................................ 37
5.2.3
Reversal Transaction ............................................................................... 37
5.2.4
Balance Inquiry Transaction ................................................................... 37
5.3
Timeout Setting ......................................................................................................... 38
5.3.1
Timeout Setting Rules for General Transactions ................................. 38
5.4
IC Card Transaction based on CUPIC Debit/Credit Standards ..................... 38
5.4.1
Supported Transaction Types ................................................................ 38

i
5.4.2
E-cash Application-based Transaction Types ...................................... 40
Explanations on Stand-in Authorization Transaction Processing .... 42

6.1
6.2
Overview of Stand-in Authorization Transaction ............................................. 42

Processing Stand-in Authorization Transaction .............................................. 42
6.3
Obtaining Stand-in Authorization Transaction Log ......................................... 43
Transactions resulting from Processing of Clearing and Settlement 44

7.1
CUPS Cutoff Advice Transaction (0820/0830) ................................................... 44
7.2
Processing Flow of Transactions resulting from Self-Administered
Clearing/Settlement .............................................................................................................. 44
7.2.1
7.2.2
7.3
Time Sequence of CUPS Clearing and Settlement .......................................... 45
7.3.1
Processing Flow of Message Sending amid CUPS Cutoff Period .... 44

Processing of Clearing/Settlement Files .............................................. 45
Time Sequence Coordination ................................................................. 46
Explanations on Dispute Resolution ................................................... 48

8.1
Description of Dispute Resolution Transaction ............................................... 48
8.1.1
Inquiry, Inquiry Response, Retrieval Request and Retrieval Request
Fulfillment ................................................................................................................ 48
8.1.2
Retrieval Request Postponement .......................................................... 48
8.1.3
8.1.4
Credit Adjustment, Credit Adjustment Cancellation ........................... 48

Debit Adjustment, Debit Adjustment Cancellation .............................. 49
8.1.5
8.1.6
Chargeback, Chargeback Cancellation ................................................ 49

Representment, Representment Cancellation ..................................... 49
8.1.7
8.1.8
Second Chargeback, Second Chargeback Cancellation .................... 49

Good Faith, Good Faith Response ........................................................ 50
8.1.9
Special Adjustment, Special Adjustment Cancellation ...................... 50
8.1.10
Fee Collection/Funds Disbursement,Fee Collection/Funds
Disbursement Cancellation ................................................................................... 50

8.2
Dispute Processing of Domestic/Cross-border Transactions ...................... 51
8.2.1
General Flow of Dispute Submit over Network Platform ................... 51
Explanations on Processing of Management and Security Control
Related Transactions ................................................................................. 52

9.1
Network Management Advice Transaction (0820/0830) .................................. 52
9.1.1
Transaction Description .......................................................................... 52
9.1.2
Transaction Flow ...................................................................................... 52
9.2
Key Reset (0800/0810) ............................................................................................. 53
9.2.1
9.2.2
10
Transaction Description .......................................................................... 53

Transaction Flow ...................................................................................... 54
Flow of Transaction Abnormalities Processing ......................... 56

ii
10.1 Overview ...................................................................................................................... 56

10.2 Rules of Abnormalities Processing ..................................................................... 56
10.2.1
Rule 1 ......................................................................................................... 56
10.2.2
10.2.3
Rule 2 ......................................................................................................... 56
Rule 3 ......................................................................................................... 56
10.2.4 Rule 4 ......................................................................................................... 57

10.3 Message Format Error ............................................................................................. 57
10.3.1
Message Grammatical Error ................................................................... 57
10.3.2
Message Semantic Error ......................................................................... 57
10.4 Data Security Confidentiality Error ...................................................................... 58

10.4.1
PIN Error .................................................................................................... 59
10.4.2 MAC Error .................................................................................................. 60

10.5 Communications Abnormality ............................................................................... 61
10.5.1
10.5.2
Setting of Issuers Invalid Status by CUPS .......................................... 62

Individual Failure...................................................................................... 63
10.5.3 Dual Failures ............................................................................................. 74

10.6 Terminal Operation Error ........................................................................................ 76
10.6.1
10.6.2
Without Communication Failures .......................................................... 76

Communication Failures ......................................................................... 76
10.7 Transaction Abnormalities Processing ............................................................... 77

10.7.1
Remittance Transaction (online) Abnormalities Processing ............. 77
10.7.2
Designated Account Loading and cash Loading of E-Cash
Application based on CUPIC Debit/Credit standard .......................................... 89
iii
THIS PAGE INTENTIONALLY LEFT BLANK.
iv
Using this Document

Purpose
This Part I Transaction Processing is one of the six parts comprising the Technical
Specifications on Bankcard Interoperability V2.1.The document specifies the
requirements on processing procedures of various online transactions in the UnionPay
inter-bank switching network, covering processing procedures of bankcard transaction
switching, processing procedures of dispute transactions, processing procedures of
transactions on clearing and settlement, and processing procedures of transaction
abnormalities.
Audience
The audiences of this manual are the staff from UnionPay and UnionPay participants.
Time Expressed
UnionPay has operation centers in several locations including Shanghai, Beijing and
Hong Kong. For operational purpose, the time frame in this manual, unless particularly
indicated, refers to Beijing time
Coordinated Universal Time (UTC) is the basic measuring time throughout the world.
Beijing time is 8 hours ahead of UTC. Also, there is no Daylight Saving Time in China.
Unless otherwise specified, the Day in this Volume refers to the calendar day and the
Business Day refers to the working day subject to local regulations of the country where
the processing participant is located.
Replacement
The October 2011 version replaces your existing document.
Revisions
UnionPay will periodically issue revisions to this document as enhancements and
changes are implemented, or as corrections are required. Occasionally, revisions or
additions to this document will be published in an Operations Bulletin.
Please refer to the Summary of Revisions for changes reflected in this version.
Support
Please address your questions to the service teams as follows:

For questions related to this manual:
Fax: (86-21) 5036-2339
E-mail: publications_intl@unionpay.com
For questions related to transaction processing:
Fax:(86-21) 5036-2339
E-mail:support_intl@unionpay.com
Summary of Revisions
Description of Change
Where to look
Section 4.1.4.1
Added: MO/TO Refund
Section 5.1.9.3
Added: MO/TO Refund Procedures
1 Application Scope
This Specification applies to all UnionPay participants.
2 References
The terms and conditions of the following documents quoted by this Specification have
become the terms and conditions of the Specification. The modification list (excluding
corrected contents) or revised edition attached to the dated documents shall not apply to
this Specification. However, participants may study whether to apply the latest versions
of such documents. The latest versions of non-dated documents shall apply to the
Specification.
UnionPay
Operating Regulations
CUPIC
Financial Integrated Card Specification
EMV2000
Integrated Circuit Card Specification for Payment

Systems: Book 1 ~ Book 4
3 Terms and Definitions

The following terms and definitions are applied to this Specification.
CUPS (China UnionPay System)
China UnionPay system (hereinafter referred to as CUPS) is responsible for switching of
inter-bank bankcard transactions and collection, clearing and distribution of settlement
data.
CDRS
An Internet-based service platform provided by UnionPay to participants. The platform is
capable of providing functions such as dispute and report services that are connected with
switching operations. UnionPay Public Service Platform is also known as CUP Dispute
Resolution SystemCDRS.
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, arranging and submitting settlement data.
Issuer
The party where the cardholder opens an account (authorization is approved by the party).
Usually, the issuer and its headquarter center or regional center are called Issuer together.
Transfer-In
The party in which fund is transferred in the transfer transaction.
Transfer-Out
The party which conveys the fund to the other party in the transfer transaction
Pre-authorization
The payment acknowledgement or guarantee from the issuer to the agent party.
Bank Card
Credit payment tool issued to the public by, financial institutions like commercial banks,
6
and postal saving and remitting institutions, with all or part of the following functions:
consumption credit, transfer settlement, cash deposit and withdraw, etc.
Request
Message that generates a series of interactive messages.
Response Code
The code that indicates 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 corresponding results shall be cancelled.
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.
Settlement
The whole process that calculates and submits the net amount of transaction data based
on clearing result, and completes the fund transfer.
Transaction
Relevant information set that achieves the intention of original information introducer,
and usually it ends with a debit or credit transaction. The subsequent revision or
cancellation can be considered as an independent transaction set.
Single Message
A transaction mode under which the acquirer submits transaction information to the
issuerand then CUPS does settlement based on the log and the acquirer does not need to
submit presentment files.
Single Message Transaction
A transaction is transmitted only once for authorization, clearing and settlement, which is
also called comprehensive financial transaction, i.e. authorization, clearing and
settlement all take place online.
7
Dual Message
A transaction mode under which the acquirer first submits authorization request to the
issuer, and then submits settlement information to the issuer collectively in the form of
presentment file at some time afterwards.
Dual-Message Transaction
A transaction is transmitted twice. For the first time, it is only for authorization, and for
the second time, the additional information is for clearing and settlement, i.e. real-time
authorization processing and non real-time clearing and settlement processing.
Advice
Messages sent to relevant parties informs the actions that have already taken place, with
no approval required
CUPIC Standards
CUPIC is the core chip migration program of UnionPay. It is based on UnionPay IC card
specifications which are highly compliant to EMV and ISO standards. CUPIC Standards
specifically refer to Financial Integrated Circuit (IC) Cards Specification.
EMV Standards
EMV is the acronym of EUROPAY, MASTERCARD and VISA. The IC card
debit/credit application standards are jointly constituted by these three companies is
abbreviated to EMV Standards.
EMV ready
According to the current CUPIC debit/credit draft standard, it stands for support of four
major functions, namely special information transmission, security authentication,
transaction features and issuer partial script application in case of stand-in authorization.
ARQC (Authorization Request Cryptogram)
ARQC is the abbreviation of authorization request cryptogram, and it is the application
cryptogram generated by IC card for processing transactions online. During the online
card authentication procedure, issuer approves the validity of the card in current
transaction via the authentication of ARQC.
ARPC (Authorization Response Cryptogram)
ARPC is the abbreviation of authorization response cryptogram, and it is the application

cryptogram generated by the issuer and returned to the terminal in online authorization
message. It is used to verify whether online authorization response comes from the real
issuer.
CUPSecure (China UnionPay Secure)
Safety system that is established by UnionPay for bankcard transactions in Internet
E-commerce area.
UnionPay Secure Information Collection Mode
The secure authentication mode under which issuing institution verifies and completes
corresponding payment transactions while UnionPay collects secure information for
issuing institution and forwards it to issuing institution.
Issuer Secure Authentication and Authorization Mode
The secure authentication mode under which cardholder inputs identification
authenticationsecureinformationontheinterfaceprovidedbySecure Authentication
Authorization Sever (SAA) and completes corresponding payment transactions.
and
IC Card Debit/Credit Application based on CUPIC Debit/Credit Standard

It refers to the application protocols and related data set between the financial IC card
and the terminal to implement debit/credit function. It is applicable to 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 (Low-value Payment Application) based on

CUPIC Debit/Credit Standard
It refers to the application protocols and related data set based on CUPIC debit/credit
application to implement low-value payment function. It is applicable to transaction
processing between the financial IC card with low-value payment function issued by
banks and various terminals supporting the application.
MO/TO
It is the abbreviation of Mail Order/Telephone Order. In this specification it refers to the
process of cardholders of UnionPay credit card confirming the purchase of commodities
or services through telephone, mail, e-mail or other non face-to-face method. Merchants
initiate the debit request and complete the payment procedure.
9
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.
10
4 General Processing Flows of Transactions

4.1
Request and Advice Transaction

Transaction types supported by the CUPS include:
Table 1 Classification Table of Transaction Types supported by CUPS
Message Type
Transaction Type
01XX
Pre-Authorization
02XX
Financial/ Financial Advice
04XX
Reversal
05XX
Reconciliation Control
06XX
Management
08XX
Network Management
Above transactions can be classified into two types: request transaction and advice
transaction.
4.1.1 Request Transaction
The request transaction is sent from the requesting party (e.g. the acquirer) to the receiver
(e.g. the issuer), to inform the other party 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 approval or refusal of the
transaction. If the receiver is not the final receiving institution of the transaction, it is
responsible for forwarding the transaction to next institution.
The request transaction includes:
Pre-Authorization and Authorization Transaction: Pre-authorization and

Authorization Request/Response Message (0100/0110)
Financial Transaction: Financial Request/Response Message (0200/0210)

Network Management Transaction: Network Management Transaction
Request/Response Message (0800/0810).
CUPS does not support the automatically repeated sending of request message.
4.1.2 Advice Transactions
The advice transaction generally refers to a transaction in which the sender informs the
receiver of an action the sender has taken and it requests no authorization but response.
11
In the Specification the advice transaction can be sent out by acquirer, issuer and CUPS,
and the receiver of the transaction should give 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 response to the sender.
The advice transaction includes:
Financial Advice Transaction: Financial Advice/Response Message (0220/0230)
Reversal Advice Transaction: Reversal Advice/Response Message (0420/0430)
Management
(0820/0830)
advice
transaction:
Network
Management
Advice
Message
4.1.3 Normal Processing Flow of Request Transaction

The normal processing flow of request transaction includes two types: switched via
CUPS and processed directly by CUPS. The descriptions of the two types are as follows.
4.1.3.1 Normal Processing Flow Description of the Request Transaction
Switched via CUPS
Acquirer
2
CUPS
3
Issuer
1Transaction request sent to CUPS from acquirer
2Transaction request forwarded to issuer by CUPS

3Transaction response sent to CUPS from issuer
4Transaction response forwarded to acquirer by CUPS

This flow applies to Pre-authorization, MO/TO Pre-Authorization, MO/TO
Pre-Authorization
Completion(Request),
Authorization,
Authorization
Cancellation,
MO/TO
Authorization,
12
MOTO
Authorization
Cancellation,
Recurring authorization, Recurring authorization cancellation, Pre-authorization

Completion (request), Purchase, MO/TO Purchase, Recurring ,Cash Withdrawal,
Remittance Verification, Remittancetransaction,Pre-authorizationCancellation,
Pre-authorization Completion (request) Cancellation, MO/TO Authorization
Cancellation, MO/TO Authorization Completion(Request) Cancellation, Purchase
Cancellation, MO/TO Purchase Cancellation, Recurring Cancellation, Balance
Inquiry.
4.1.3.2 Normal Processing Flow Description of the Request Transaction
Processed Directly by CUPS.
1
the sender
the receiver
2
Figure 2 Normal Processing Flow of the Request Transaction Processed Directly by CUPS
1Transaction request sent to the receiver by the sender

2Response sent to the sender by the receiver
The processing flow applies to CUPS Key Reset and Network Management Transaction
with message type of 0800/0810.
4.1.4 Normal Processing Flow of Advice Transaction
The normal processing flow of advice transaction can be classified into two types:
switched via CUPS and processed directly by CUPS. The descriptions of the two types
are as follows.
13
Issuer
Acquirer
4.1.4.1 Normal Processing Flow of Advice Transaction Switched via CUPS
2
CUPS
3
4
1 Advice sent to CUPS from issuer
2 Response sent to issuer from CUPS
3 Advice sent to acquirer from CUPS

4 Response sent to CUPS from acquirer
Figure 3 Normal Processing Flow of Advice Transaction Switched via CUPS
The processing flow applies to reversal advice (initiated by acquirer, and CUPS will
forward the reversal advice to issuer after matching the original transaction records.),
Refund (online), Pre-authorization Completion (advice) Advice and IC Card Script
Processing Result Advice based on CUPIC debit/credit Standard.
4.1.4.2 Processing Flow Description of Advice Transaction Processed
Directly by CUPS
1
the
receiver
the sender
2
1Advice sent to the receiver from the sender
2Response sent to the sender from the receiver

Figure 4 Processing Flow of Advice Transaction Processed Directly by CUPS
The processing flow applies to Reversal Advice (initiated by acquirer, and CUPS will
not forward the reversal to issuer in case of unsuccessful original transaction, or the
reversal is initiated directly by CUPS), Settlement Advice and Network Management
Advice.
14
4.1.4.1 Processing Flow Description of Advice Transaction Processed

Directly by CUPS
1
the
the sender
receiver
2
Figure 4 Processing Flow of Advice Transaction Processed Directly by CUPS
1Advice sent to the receiver from the sender

2Response sent to the sender from the receiver
The processing flow applies to Reversal Advice (initiated by acquirer, and CUPS will not
forward the reversal to issuer in case of unsuccessful original transaction, or the reversal
is initiated directly by CUPS), Settlement Advice, MO/TO settlement advice and
Network Management Advice.
4.2
Store-and-forward Mechanism of Transaction Message

In transaction flows, there are two types of situations as follows:
The sender cannot send the message to the receiver;
The sender cannot receive the response from the receiver after sending the message.
In case either of two situations occurs, the sender could store the message in the
store-and-forward queue and send the message repeatedly at an intervals within certain
times prior to the cut-off of the sender system and when the receiver is in normal status.
If there is still no response received after doing so, the sending will be terminated. If
funds discrepancy occurs between the sender and the receiver, it will be solved via
dispute resolution. This method is called store-and-forward mechanism.
Store-and-forward mechanism is normally used for sending some advice messages.
15
5 Explanation on Transaction Switch Processing

5.1
Single-message Transactions Processing

5.1.1 Pre-authorization Transaction 0100/0110
Pre-authorization transaction is used by acquirer to confirm its approval of cardholders
transaction to issuer. Acquirer takes the estimated purchase amount as the
pre-authorization amount and sends it to the cardholders issuer. After approving the
transaction, issuer will put information, such as approve code etc, into the transaction
response sent to acquirer.
Pre-authorization transaction only controls the cardholders available balance. Funds
settlement will be accomplished by pre-authorization completion transaction. An
approved pre-authorization transaction is only valid within a limited time.
This transaction is a request transaction that needs to be switched via CUPS.
The transaction amount of this transaction is not involved in settlement while the
transaction volume is involved in the reconciliation.
This transaction may initiate reversal advice. For the conditions to initiate reversal and its
processing flows, please refer to Section 5.1.8 Reversal Advice.
5.1.2 MO/TO Pre-authorization Transaction 0100/0110
MO/TO Pre-authorization transaction refers to purchase orders initiated by cardholders
through telephone, fax or other agent organizations.
This transaction is a request transaction that needs to be switched via CUPS.
The transaction amount of this transaction is not involved in settlement while the
transaction volume is involved in the reconciliation.
This transaction may initiate reversal advice. For the conditions to initiate reversal and its
processing flows, please refer to Section 5.1.8 Reversal Advice.
5.1.3 Pre-authorization Cancellation Transaction (Online) 0100/0110
For a successful pre-authorization, a pre-authorization cancellation is used to inform
issuer to cancel payment commitment prior to batch clearing.
Pre-authorization cancellation must be the full amount cancellation for the original
pre-authorization.
This transaction is a request transaction switched via CUPS.
16
Transaction amount of this transaction is not involved in settlement. When the

cancellation and its original pre-authorization are in the same batch or reconciled at the
same settlement date, the transaction volume of pre-authorization will be deducted from
the total transaction volume in the reconciliation.
This transaction could initiate reversal advice.
5.1.4 MO/TOPre-authorizationCancellationTransaction(Online) 0100/0110
For a successful MO/TO Pre-authorization, a MO/TO Pre-authorization Cancellation is
used to inform issuer to cancel payment commitment prior to batch clearing.
Pre-authorization Cancellation must be the full amount cancellation for the original
pre-authorization.
This transaction is a request transaction switched via CUPS.
Transaction amount of this transaction is not involved in settlement. When the
cancellation and its original pre-authorization are in the same batch or reconciled at the
same settlement date, the transaction volume of pre-authorization will be deducted from
the total transaction volume in the reconciliation.
This transaction could initiate reversal advice.
5.1.5 Financial Transaction 0200/0210
Financial transaction is used for electronic fund transfer, and stands for that acquirer asks
issuer for permission of both cardholder transaction and fund settlement. Financial
transaction is classified into transaction request and response. After the transaction
request is approved by issuer, cardholders account will be credited or debited.
Financial transaction includes Cash Withdrawal, Remittance, Pre-authorization
Completion (request) and Purchase.
Financial transaction is a request transaction that needs to be switched via CUPS.
The transaction amount of financial transaction is involved in settlement and
reconciliation.
Financial transaction could initiate reversal advice except deposit transaction. For
conditions of generation of reversal and its processing flows, please refer to Section 5.1.8
Reversal Advice.
Remittance may not trigger any advice messages. For the conditions and procedures for
remittance abnormal processing, please refer to Section 11.7.1.
5.1.5.1 Cash Withdrawal
17
The procedure that cardholder withdraws cash at ATM, POS, bank counter or via other
terminal channel.
5.1.5.2 Pre-authorization Completion (request)
For approved pre-authorization transaction, Pre-authorization Completion (request) is
used for settlement.
5.1.5.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.
5.1.5.4 Purchase
It refers to the procedure of completing the payment circle with bankcards via POS
terminals or other channels when merchants sell commodities or provide services. It can
be one-off payment or installment payment.
5.1.5.5 MO/TO Purchase
It refers to the purchase transaction initiated by cardholders to agent organizations
through phone or fax, etc.
5.1.5.6 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. It includes Recurring, Recurring Cancellation, Recurring Reversal,
Recurring Reversal Cancellation.
5.1.5.7 Remittance
Remittance transaction is the combination of two transactions: Verification and
Remittance. In Remittance Business, Acquirer is the transfer-out party while Issuer the
transfer-in party. A processing flow of Remittance business is showed as follows:
18
3
CUPS
Issuer
Acquirer
1- Remittance Verification Request sent to CUPS from Acquirer (0100)

2-Remittance Verification Request forwarded to Issuer by CUPS (0100)
3- Approved Remittance Verification Response sent to CUPS from Issuer (0110)
4- Approved Remittance Verification Response forwarded to Acquirer by CUPS (0110)
5- Remittance Transaction Request sent to CUPS from Acquirer (0200)
6- Remittance Transaction Request forwarded to Issuer by CUPS (0200)
7-Approved Remittance Transaction Response sent to CUPS from Issuer (0210)
8- Approved Remittance Transaction Response forwarded to Acquirer by CUPS (0210)
Abnormal Processing Flows refer to Section 11.7.1
5.1.5.7.1 Remittance Verification Transaction 0100/0110
Acquirer initiates an Account Verification Transaction for transfer-in account according
to customers requirement. This transaction is a request transaction switched by CUPS.
The functions of Account Verification Transaction are shown as follows:
Verify the existence of transfer-in card
Verify whether the Transfer Transaction is supported by the transfer-in side
Check communication line to minimize the failure rate of Remittance Transaction.
Check whether the remittance amount exceeds the limit.

Acquirer can only proceed with the Remittance Transaction after receiving successful
RemittanceVerificationResponse.ARemittanceVerification Transaction can initiate
Remittance Transaction only once. If Acquirer cannot receive Account Verification
19
Response or receive the failed Account Verification Response, it cannot initiate

Remittance Transaction.
Acquirer could not initiate Remittance Transaction without Remittance Verification
Transaction.
Remittance Verification and Remittance must be initiated in the same settlement day.
Remittance Verification Transaction cannot initiate reversal and doesnt participate in
settlement.
5.1.5.7.2Remittance Transaction 0200/0210
Acquirer initiates Remittance Transaction after receiving successful Remittance
Verification Transaction. Remittance Transaction requests Issuer to verify Cardholders
Transfer and amount. Its a request transaction switched by CUPS.
Acquirer should keep the fund after it initiates the Remittance Transaction, no matter
whether it can receive Response or whether Response is successful. Funds could be used
for further processing.
If Acquirer receives approved Remittance Response, it can inform customer that
Remittance Transaction succeeded. Funds will reach the account in a real time manner.
Otherwise, it should inform customer Remittance Transaction succeeded. Funds will
reach the account in a non-real time manner.
Generally speaking, after the success of Remittance Verification, Issuers should not
reject Remittance Transaction, except for: (1) Remittance Message MAC error verified
by Issuer; (2) Remittance Message Format Error found by Issuer.
CUPS would match Remittance Transaction with Remittance Verification according to
Remittance Transactions field 90 (original data element) and reject Remittance
Transaction if the match failed.
Issuer doesnt need to match Remittance transaction with Remittance Verification.
Remittance Transaction doesnt initiate reversal. It participates in settlement.
5.1.5.8 Financial Cancellation Transaction 0200/0210
For successful financial transactions, the original financial transactions could be
cancelled under certain conditions by invoking cancellation transaction to return the
original transaction amount prior to settlement. The cancellation must be a full amount
cancellation of the original transaction.
Cancellationtransactionsoftheoriginalfinancialtransactionsinclude:
20
Pre-authorization
Completion (Request)cancellation,MO/TOPurchase
Cancellation,
Recurring
Cancellation, MO/TO Pre-authorization Completion(request) Cancellation, purchase

cancellation.
Financial cancellation transaction is a request transaction that needs to be switched via
CUPS, and the transaction flow is the request transaction processing flow switched via
CUPS.
The transaction amount of financial cancellation transaction is involved in settlement and
reconciliation.
Financial cancellation transaction could initiate reversal advice. For conditions of
generation of reversal and its processing flows, please refer to Section 5.1.8 Reversal
Advice.
5.1.6 Balance Inquiry 0200/0210
It is the procedure that cardholder inquires the account balance at ATM or other terminal
channels.
Balance inquiry is a request transaction that needs to be switched via CUPS, and the
transaction flow is the request transaction processing flow switched via CUPS.
Balance inquiry is involved in reconciliation, but shall not be taken as evidence of
balanced account. Balance inquiry does not initiate reversal.
When CUPS cannot forward the inquiry request to issuer, the request will be directly
rejected.
When CUPS cannot forward the response to acquirer, the response will be directly
discarded.
When acquirer cannot receive the response from CUPS, the transaction will be directly
rejected.
5.1.7 UnionPay Card Exchange Rate Inquiry 0600/0610
5.1.7.1 Transaction Description
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-account currency. For example, if the remitting-out currency of an
international remittance transaction is HKD while the currency of the remitting-in
account is RMB, the cardholder can initiate an exchange rate inquiry transaction first to
obtain the remitting-in amount in RMB and exchange rate for HKD against RMB. This
transaction is a request transaction directly processed by CUPS, it will not be re-initiated
if the sender doesnt receive any response, and response will be dropped if the receiver is
21
not able to send response.

5.1.7.2 Transaction Flow
Acquirer
The request of the exchange rate inquiry transaction is sent to CUPS by the Acquirer, and
the response is sent to the Acquirer by CUPS.
1
2
CUPS
1UnionPay card exchange rate inquiry (0600) sent to CUPS by the Acquirer
2Response (0610) sent to the Acquirer by CUPS

Figure 6 Flow of UnionPay Card Exchange Rate Inquiry Transaction
5.1.8 Reversal Advice 0420/0430

As for the requests with the message type 0100 and 0200, except for remittance and
inquiry request etc., reversal advice must be generated if the acquirer and CUPS could
not receive response to the transaction request within the certain time. If CUPS cannot
forward a successful transaction response to acquirer, reversal advice must be generated
as well.
When acquirer receives a reversal advice from terminal or CUPS receives a reversal
advice from acquirer, response must be given immediately. If the original transaction is
successful, it shall be initially set to Reversed Transaction and then a 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 response. But reversal advice shall not be sent across the settlement date.
Transactionsthatgenerate reversal adviceinclude:Pre-authorization,
Pre-authorization
Cancellation, manual Pre-authorizationCancellation,
Pre-authorization
Completion
(request), Pre-authorization Completion(request) Cancellation, Purchase, MO/TO
22
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/TOPre-authorizationCompletion(request),
MO/TO Pre-authorization Completion(request) Cancellation,
Reversal advice is not allowed across the settlement date.
Cash
Withdrawal,
5.1.8.1 Normal Transaction Flow
CUPS
Issuer
Acquirer
1Reversal advice (0420) sent to CUPS by acquirer
2Reversal responses (0430) sent to acquirer by CUPS
3Reversal advice (0420) sent to issuer by CUPS
4Reversal responses (0430) sent to CUPS by issuer

Figure 7 Flow of Reversal advice
5.1.8.2 Abnormal Transaction Flow

5.1.8.2.1Receiver 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.
23
1
2
Sender
Receiver
3
4
1Reversal advice sent to receiver by sender

2Reversal response sent to sender by receiver. Abnormal situation at the
receiver.
3Reversal advice re-sent to receiver by sender
4Reversal response sent to sender by receiver
Figure 8 Abnormal Flow 1 of Reversal

5.1.8.2.2 Sender of the 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.
1
Sender
Receiver
1.
Reversal advice sent to the receiver by the sender, and it cannot be sent due to
faults.
2.
Reversal advice re-sent to the receiver by the sender after recovery
24
3.
Response to the reversal advice from the receiver

Figure 9 Abnormal Flow 2 of Reversal
5.1.9 Financial Advice Transaction 0220/0230

Financial advice transaction is used for fund transfer and corresponding account
processing among acquirer, CUPS and issuer.
This transaction applies to following situations: Pre-authorization Completion (advice)
initiated by acquirer, settlement advice sent to issuer by CUPS, MO/TO settlement
advice, Refund (online) initiated by acquirer, Financial advice transaction is involved in
settlement; Pre-authorization completion (advice) initiated by acquirer, Settlement
Advice sent to issuer by CUPS, Refund (online) initiated by acquirer and MO/TO
settlement advice are involved in reconciliation.
Financial advice transaction does not initiate reversal. When the advice sender cannot
receive response, store-and-forward shall be adopted but it cannot be resent across the
settlement date.
5.1.9.1 Pre-authorization completion (advice), MO/TO Pre-Authorization
Completion (advice)
For approved pre-authorized transaction, in addition to using pre-authorization
completion (request) request to settle payment, pre-authorization completion (advice) can
be used to complete payment settlement according to relevant business rules.
Pre-authorization completion (advice) is the advice transaction switched via CUPS and
issuercannotreject thepre-authorizationcompletion(advice).The above-mentioned content
is also applicable to MO/TO Pre-Authorization Completion (advice).
5.1.9.1.1Normal Transaction Flow
4
CUPS
3
Issuer
Acquirer
1Pre-authorization completion ( advice) (0220) sent to CUPS by acquirer
2Response (0230) sent to acquirer by CUPS

3Settlement advice (0220) sent to issuer by CUPS
4Response (0230) sent to CUPS by issuer
25

Figure 10 Flow of Pre-authorization Completion (Advice)
5.1.9.1.2Abnormal Transaction Flow

If the sender cannot send pre-authorization completion (advice) transaction to the
receiver or does not get the receivers response to the transaction, it will save the advice
in the store-and-forward queue for storing and forwarding.
1
Sender
Receiver
1Pre-authorization completion (advice) sent to the receiver by the sender

cannot be sent out due to failures.
2After recovery of the sender,, pre-authorized completion ( advice) sent to
receiver by the sender.
3Response to pre-authorized completion (advice )by the receiver.
Figure 11 Abnormal Flow of the Pre-authorized Completion (Advice)
5.1.9.2 Settlement Advice, MO/TO Settlement Advice

It is the advice in which CUPS forwards dual-message request to single-message issuer
while doing single/dual message conversion, and it is the fund settlement advice for the
previously approved pre-authorization transaction. MO/TO settlement adviceisthe
settlementadviceforthepreviouslyapprovedMO/TO pre-authorization.Its
procedure is the same as regular settlement advice.
settlement
Within overtime period if issuer receives settlement advice after cutoff sent by CUPS
prior to cutoff; it shall be able to handle settlement advice transactions across settlement
dates within overtime period.
In case that acquirer adopts dual message processing mode and issuer adopts single
message processing mode, CUPS will provide conversion of transaction modes. CUPS
will convert records in dual message clearing files into settlement advices record by
record and send them to issuer. Issuer cannot reject settlement advice in online
26
transactions or if issuer needs to reject settlement advice, it could be completed via

chargeback.
Not all banks are needed to support settlement advice. If issuing bank adopting single
message transaction mode supports pre-authorization transactions, it shall support
settlement advice transaction.
5.1.9.2.1Normal Transaction Flow
Acquirer sends dual-message clearing files to CUPS, and CUPS will convert the files
into settlement advices and send them to the single-message issuer. Issuer sends response
to CUPS.
CUPS
Issuer
Acquirer
1Dual-message clearing file sent to CUPS by acquirer
2Fund settlement advice sent to issuer by CUPS
3Response sent to CUPS by issuer

Figure 12 Flow of the Settlement Advice

When failures occur at issue side and CUPS cannot send the settlement advice to issuer,
CUPS should put the advice in Store-and-forward queue for storing and forwarding.
CUPS
27
Issuer
Acquire
r
1Dual-message clearing file sent to CUPS by acquirer
2CUPS cannot send the settlement advice to issuer due to some reason
3Settlement advice re-sent by CUPS
4Response re-sent to CUPS by issuer
Figure 13 Abnormal Flow of Settlement Advice
28
5.1.9.3 Refund (Online)/ MO/TO Refund (Online)

It is the procedure that merchants refund the deducted fund to cardholders original debit
account due to commodities return or service cancellation, and it includes total and
partial refund. The procedures of MO/TO refund (online) is the same as that of normal
refund (online).
Once issuer receives refund transaction (on-line), the transaction shall be approved
unconditionally and it will be involved in reconciliation.
Within overtime period, if after CUPS cutoff, the issuer receives refund transaction
(on-line) sent by CUPS prior to cutoff, the issuer shall proceed it across settlement date
within overtime period.
The transaction is an advice transaction that needs to be switched via CUPS.
Issuer
Acquirer
1
2
CUPS
Issuer
5.1.9.3.1 Normal Transaction Flow
3
4
1Refund advice (0220) sent to CUPS by acquirer
2Response (0230) sent to acquirer by CUPS
3Advice (0220) sent to issuer by CUPS
4Response (0230) sent to CUPS by issuer

Figure 14 Flow of Refund Transaction (on-line)
5.1.9.3.2 Abnormal Transaction Flow

If the sender cannot send refund transaction (on-line) to the receiver, or it does not
receive the receivers response to the refund transaction (on-line) , the sender shall put
the refund transaction (on-line) in store-and-forward queue for storing and forwarding.
29
Receiver
Sender
1Refund advice cannot be sent to the receiver by the sender due to failures.
2After recovery of the sender, refund advice re-sent to the receiver by the
sender.
3Receivers response to refund advice.

Figure 15 Abnormal Flow of Refund Transaction (on-line)
Special Note: participants may log onto CDRS to initiate manual refund, and please refer
to Chapter 8 Explanation on Dispute Resolution for the processing flow.
5.1.10 Manual Transaction
It is the transaction in which participants log on to CDRS and finds the original
transaction through the Platform to initiate associated transaction aiming at original
transaction.
5.1.10.1
Manual Pre-authorization Cancellation Transaction 0100/0110
As for pre-authorization that is successfully switched via CUPS, acquirer may cancel it
manually on public services platform. After receiving manual cancellation request on
public services platform, CUPS will send manual pre-authorization cancellation request
message to issuer. If CUPS does not receive response after sending out the manual
pre-authorization cancellation message, a notice of transaction failed will be prompted on
the operation interface, and meanwhile CUPS will send a manual pre-authorization
cancellationreversal advice to issuer.
The transaction is involved in issuers reconciliation instead of acquirers reconciliation.
5.1.10.1.1 Normal Transaction Flow
30
Issuer
1Acquirer logs onto the CPU public services platform and initiates
pre-authorization cancellation (manual) transaction

2CPU public services platform informs CUPS of pre-authorization cancellation
(manual)
3CUPS will send pre-authorization cancellation (manual) request message to
issuer immediately after receiving it

4Issuer sends back pre-authorization cancellation (manual) response massage to
CUPS
Figure 16 Normal Flow of manual Pre-authorization Cancellation

When the sender cannot send the manual pre-authorization cancellationrequest to
receiver, or does not receive manual pre-authorization cancellation response from
Issuer
31
the
the
Acquirer
Issuer
receiver, it will initiate manual pre-authorization cancellationreversal.
CDRS
1Acquirer initiates pre-authorization cancellation (manual) transaction on the
CDRS
2PCDRSsends the pre-authorization cancellation (manual) request to CUPS
3Pre-authorization cancellation (manual) request sent to issuer by CUPS is lost

on the way due to failure, and it will cause CUPS timeout
4Pre-authorization cancellation (manual) reversal advice sent to issuer by CUPS

5Pre-authorization cancellation (manual) reversal response sent to CUPS by
issuer
Figure 17 Abnormal Flow of Manual Pre-Authorization Cancellation
5.1.10.2 Manual Refund

For settled purchase transactions, MO/TO Purchase, acquirer may initiate manual refund
on the UnionPay public services platform to return the amount consumed by the
cardholder.
Manual refund transaction processing flow and features are as follows:
Acquirer may initiate manual refund transaction after finding the original transaction
through CDRS, or refund transaction information could be manually entered, and
CUPS will directly settle the refund transaction.
Manual refund supports full amount refund, partial amount refund and multiple times
of refund.
Manual refund could be cancelled on the UnionPay public services platform before
end-ofday of current day. After cancellation, original manual refund and manual
32
refund cancellation transactions will not be in the files distributed by CUPS.
CUPS will not send any online message to participants.
Manual refund is not involved in reconciliation.
Whether acquirer adopts single message or dual message, manual refund transaction
is recorded in the general audit trailer file and is included in the statistics of the
Summary Report as well.
A
c
q
u
i
r
e
r
General transaction processing flow for manual refund is as follows:
CDRS
Acquirer
Iss
uer
Acquirer logs onto the CUP public services platform to initiate manual refund
CDRS informs CUPS of the manual refund advice
At end of day, CUPS sends transaction details and dispute files to issuer
5.1.10.3 Manual Pre-authorization Completion

As for pre-authorization successfully switched via CUPS, acquirer may settle it by
submitting manual pre-authorization completion on the public services platform.
Manual Pre-authorization completion processing flow and features are as follows:
Manual Pre-authorization completion could be cancelled manually on the public

services platform before end-of-day of current day. After cancellation, original
33
manual pre-authorization completion and manual pre-authorization completion

cancellation transactions will not be in the files distributed by CUPS.
CUPS will not send any online message to participants.
This transaction is not involved in reconciliation.
Whether
acquirer adopts
single message
or dual message,
manual
pre-authorization completion transaction is sent to participants through general

transaction detail files and is included in the statistics of Summary Report as well.
If issuer adopts dual message, then manual pre-authorization completion transaction

is recorded in dual message settlement files and is included in the statistics of the
If issuer adopts single message, then manual pre-authorization completion transaction

is recorded in the transaction detail files and is included in the statistics of the
General processing flow for manual pre-authorization completion is as follows:
Services Platform
Issuer
Acquirer
UnionPay Public
1Acquirer logs onto the UnionPay public services platform to initiate manual
pre-authorization completion
2CDRS informs CUPS of the pre-authorization completion (manual)
3After cutoff, CUPS sends general transaction detail files to issuer, including
pre-authorization completion
34

Figure 19 General Processing Flow for Manual Pre-Authorization Completion
5.1.10.4
Manual Remittance Transaction
If the remittance has been kept by Acquirer while the transaction is not settled by CUPS,
Acquirer should log onto the UnionPay dispute resolution system to find Remittance
Verification Transaction and initiate manual remittance transaction
Manual Remittance processing flow and features are as follows:
Manual Remittance Transaction can be manually cancelled in dispute resolution

system before cutoff. After cancellation, original Manual Remittance and original
Manual Remittance Transaction Cancellation would not appear in files delivered by
CUPS.
CUPS would not send any online Advice Message to Institutions.
This Transaction would not participate in the online reconciliation.
Manual Remittance Transaction is sent to Institutions by general Audit Trailer File
which is also included in Summary Report.

Manual Remittance Transaction Processing Flow is as follows:
UnionPay Dispute
Issuer
Acquirer
Resolution Platform
1Acquirer logs onto the CDRS to initiate

manual Remittance
2 UnionPay Dispute Resolution Platform informs CUPS of the manual

Remittance
3After cutoff, CUPS sends general transaction detail files to participants,

including manual Remittance
35

Figure 20 General Processing Flow for Manual Remittance
5.1.10.5
Manual MO/TO Pre-authorization Cancellation
The procedure of manual MO/TO Pre-authorization Cancellation is the same as Manual

Pre-authorization Cancellation0100/0110 specified in Section 5.1.10.1
5.1.10.6
Manual MO/TO Pre-authorization Completion
The transaction procedure of manual MO/TO Pre-authorization Completion is the same

as the Manual Pre-authorization Completion specified in Section 5.1.10.3.
5.1.11Cross-border Single Message Transaction verified via CUPSecure
Cross-border single message transactions verified via CUPSecure include 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. CUPSecure verification flow does processing within
CUPSecure system and will not affect general processing flows of transactions among
acquirers, CUPS and issuers. For example, the transaction flow of cross-border purchase
transaction verified via CUPSecure is the same as that of cross-border purchase
transaction among acquirers, CUPS and issuers.
5.2
Dual-message Transaction Processing

5.2.1 Authorization Transaction
It is the process in which acquirer initiates a request to the issuer for payment
commitment, which is switched via CUPS, and issuer returns response according to the
status of cardholders account.
When acquirer does not receive the authorization response message, acquirer could
initiate an authorization reversal message. In case CUPS cannot forward the approved
authorization response message to acquirer, it will initiate an authorization reversal
message and send it to issuer.
After the authorization request is approved, the whole transaction will be completed
through file settlement mode. The authorization code and authorization amount, of each
transaction should be indicated while submitting settlement files, and the authorization
amount will participate in issuers settlement. An approved authorization transaction is
36
valid only within limited time. If the authorization expires when issuer receives
settlement files, issuer is entitled to initiate chargeback after settlement of the transaction.
The authorization transaction only controls cardholders usable balance and does not
participate in the settlement.
The transaction is a request transaction that needs to be switched via CUPS. The
transaction flow is the same as that of request transactions switched via CUPS.
5.2.2 Authorization Cancellation Transaction
It is a process in which acquirer informs issuer to cancel payment commitment via CUPS
through POS or 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 cast upon cancellation transaction initiated by acquirer. If acquirer
does not receive cancellation response within timeout period, it shall initiate a
cancellation reversal message to inform issuer to cancel the transaction. In case CUPS
detects that the cancellation transaction is in timeout, it will also initiate a cancellation
timeout reversal to inform issuer to cancel the transaction.
Authorization cancellation does not participate in settlement.
The transaction is a request transaction that needs to be switched via CUPS. The
transaction flow is the same as that of request transactions switched via CUPS.
5.2.3 Reversal Transaction
When acquirer and CUPS cannot receive the response of request message within timeout
period, or CUPS cannot forward the response of request message to acquirer, 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.
For authorization/authorization cancellation, reversal can be initiated.
Please refer to the Single-message Transaction Processing for the transaction flow.
Transactions that would generate reversal include: Purchase Authorization (one-time
payment), Purchase Authorization (installment), Cash Withdrawal at bank counter,
MO/TO Authorization and Recurring Authorization.
5.2.4 Balance Inquiry Transaction
Except the message type (0100/0110), the processing is the same with that for
single-message transactions.
37
5.3
Timeout Setting
Acquirer center
Issuer centre
5.3.1 Timeout Setting Rules for General Transactions
Figure 21 Timeout Setting for General Transactions
Each participant in the transaction should at least comply with the following timeout
requirement:
Table 2 Timeout Setting for General Transactions
Party
Timeout Setting (second)
Acquirer center
25
CUPS
20
CUPS counts the start and the end of the timing according to its own system time.
CUPS timeout check time segment starts from sending message to issuer and ends upon
receiving response message from issuer.
Acquirer center counts the start and the end of the timing according to its own system
time.
Acquirer center timeout check time segment starts from sending message to CUPS and
ends upon receiving response message from CUPS.
5.4
IC Card Transaction based on CUPIC Debit/Credit Standards

There are two main applications for CUPIC-based IC cards, debit/credit application
which is for normal debit/credit-based transactions and E-cash application which is for
low-value payment transactions. Details are described in the following sections.
5.4.1 Supported Transaction Types
5.4.1.1 Basic Transaction Types
38
Supported request transactions include: balance inquiry, cash withdrawal, purchase,

purchasecancellation,pre-authorization/authorization,pre-authorization cancellation,
pre-authorizationcompletion(request),andpre-authorization
completion
(request)
cancellation.
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.
Supported offline transactions: offline purchase offline refund. Details of offline refund
please refer to Section 5.4.2.4.
5.4.1.2 Debit/Credit Application-based IC Card Script Processing Result
Advice
If a transaction contains the issuer script, 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.
5.4.1.3
Debit/Credit Application-based ICCard offline Purchase

Transaction
This Transaction has the same functions as normal Purchase Transaction, But this
Transaction is accepted or rejected by terminal directly. Therefore, CUPS would not
receive this kind of Transaction Message. Acquirer should generate IC Card offline
transaction outgoing files and provide to CUPS and Issuer for the purpose of settlement.
5.4.1.4 Transaction Processing Flow
Processing flow for 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 CUPS. When
the sender of the advice does not receive response, the advice shall be stored and
forwarded, but it cannot be sent across settlement date.
According to different levels at which participants have migrated to CUPIC debit/credit
standards, participants can be classified into two groups: full support (Full status) and
partial support (Early status). This specification requires both Acquirer and Issuer must
be in Full status.
39
5.4.2 E-cash Application-based Transaction Types

5.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 (on-line) Supported offline
transactions include offline purchase and offline refund
5.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 in a
designated account into the E-cash card. It is a request transaction forwarded by CUPS,
so the transaction flow is that for a request transaction forwarded by CUPS.
The transaction amount of this transaction is not involved in settlement, while the service
fee is involved in settlement.
CUPS
5
Issuer
Acquirer
The transaction flow is as follows:
1Designated account loading request sent to CUPS by acquirer
2Designated account loading request sent to issuer by CUPS
3Designated account loading response sent to CUPS by issuer

4Designated account loading response sent to acquirer by CUPS
5Script processing result advice sent to CUPS by acquirer, informing issuer of

the result of the loading transaction
6Script processing result advice response sent to acquirer by CUPS

7Script processing result advice sent to issuer by CUPS, informing issuer of the
result of the loading transaction
8Script processing result advice response sent to CUPS by issuer
Figure 22 Flow of E-cash Application-based Designated Account Loading Transaction
Designated account loading transaction may trigger reversal advice. Please refer to
Section 5.1.8 Reversal Advice for conditions to trigger reversal and its flow.
40
5.4.2.3 E-cash Application-based Cash Loading

This transaction is a transaction initiated in format 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 that for other normal
transactions.
The transaction amount and the service fee of the transaction are both involved in
CUPS
5
Issuer
Acquirer
settlement.
1Cash loading request sent to CUPS by acquirer
2Cash loading request sent to issuer by CUPS
3Cash account loading response sent to CUPS by issuer
4Cash loading response sent to acquirer by CUPS

5Script processing result advice sent to CUPS by acquirer, informing issuer of
the result of the cash loading transaction
6Script processing result advice response sent to acquirer by CUPS
7Script processing result advice sent to issuer by CUPS, informing issuer of the
result of the cash loading transaction
8Script processing result advice response sent to CUPS by issuer

Figure 23 Flow of E-cash Application-based Cash Loading Transaction
5.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 when the transaction details of acquiring
terminals had not been sent. Please refer to Section 9.6, Part III File Interface for detailed
processing procedures of IC card offline purchase.
Refund (online) is applicable to situations when the transaction details of acquiring
terminals had been sent. Please refer to Section 4.1.4.1 Advice Transaction Switched via
CUPS.
Manual refund, supplementary to Refund (online), is initiated from CDRS and participate
41
in settlement of that day.

5.4.2.5 Processing Flow of Other Transactions
The flow of the reversal for designated account loading and cash loading are the same
with that for normal transactions.
Processing flow of Script result advice is the same as that of Debit/Credit application.
Processing flow of offline purchase is the same as that of Debit/Credit offline purchase.
6 Explanations on Stand-in Authorization Transaction Processing

6.1
Overview of Stand-in Authorization Transaction

CUPS provides stand-in authorization services for credit card transactions including
purchase, cash withdrawal, pre-authorization, authorization, pre-authorization completion
(request), pre-authorization completion (advice) as well as their reversal and cancellation,
according to related UnionPay operating regulations.
6.2
Processing Stand-in Authorization Transaction

The participant can manually notify UnionPay if stand-in authorization transaction is
needed. Then CUPS processes transactions of the participant through stand-in
authorization after stand-in authorization setting is initiated. The procedures are as
follows:
CUPS
Stand-in
Authorization
Acquirer
Issuer
Stand-in Authorization
1The Acquirer sends an authorization request to CUPS
2CUPS processes applicable transactions through stand-in authorization, and

returns the result to the Acquirer.
42
Figure 24 Flow of Stand-in Authorization Transaction
6.3
Obtaining Stand-in Authorization Transaction Log

UnionPaywillsendtransactioninformationprocessedthroughstand-in authorization to the
Issuer to complete transaction details of the Issuer. For international business, stand-in
authorization transaction information is sent to the Issuer by files of stand-in
authorization transaction details. For detailed processing procedures and record format,
please refer to Part III File Interface.
43
7 Transactions resulting from Processing of Clearing and Settlement

7.1
CUPS Cutoff Advice Transaction (0820/0830)

CUPS uses cutoff message to inform participants of settlement date change. The
transaction has two types: cutoff start and cutoff end.
CUPS sends cutoff transaction to each participant, who will send response to CUPS after
receiving the transaction.
1
CUPS
Participant
The transaction flow is: CUPS sends cutoff transaction to each participant, who will send
response to CUPS after receiving the transaction.
1Cutoff advice (0820) sent to Participants by CUPS

2Response (0830) sent to CUPS by Participants
Figure 25Flow of CUPS Cutoff Advice Transaction
7.2
Processing Flow of Transactions resulting from Self-Administered

Clearing/Settlement
7.2.1 Processing Flow of Message Sending amid CUPS Cutoff Period
44
1
2
U
P
S
5
6
...
5
6
7
8
Participant
3
4
1CUPS sends cutoff start advice (0820) to Participants.
2Participants send response (0830) to CUPS

3CUPS sends cutoff end advice (0820) to Participants.
5CUPS sends reconciliation advice message (0520/0522) to Participants.
6Participants send response to CUPS (0530/0532).
7CUPS sends fund settlement advice (0620) to Participants

Note: CUPS will send various types of reconciliation advice to participants adopting
single message transaction mode; reconciliation advice and fund settlement advice
are not available to participants adopting dual message transaction mode but
relevant files are still needed. For detailed file format, please refer to file format part
in Part III File Interface of the Specification.
Figure 26 Processing Flow of Message Sending amid CUPS Cutoff Period
7.2.2 Processing of Clearing/Settlement Files

For participants using single message, CUPS will send them transaction detail files after
clearing and settlement processing.
For participants using dual message mode, CUPS will process the dual message
settlement files sent over by them during clearing and settlement, and send them the
selected and processed dual message settlement files. participants of this kind could
either send multiple settlement files in a batch or perform cancellation across batches.
For details, please refer to Part III File Interface.
7.3
Time Sequence of CUPS Clearing and Settlement

Time sequence refers to 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
45
executing other functions.

7.3.1 Time Sequence Coordination
7.3.1.1 Time Sequence Point of Clearing Batch Switch
Table 3 Time Sequence Point Control Relationship of Clearing Batch Switch
SN
Transaction Description of Crucial Function Steps

Name
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
7.3.1.2 Time Sequence Point of Dual Message Clearing Files Sending

Stop
According to relevant business rules, clearing and dispute files sent over by
participants prior to the time sequence point of dual message clearing files
sending stop shall be processed in current batch, and those sent over afterwards
will be processed in the following batch. Its control relationship is demonstrated
in the following table:
Table 4 Time Sequence Point of Dual Message Clearing Files Sending
Stop
SN
Transaction
Description of Crucial Function Steps
Name
Dual message:
Clearing files sent over by Participants prior to this point are processed in
1
Settlement
the current batch

Clearing files sent over by Participants after this point are processed in
the following batch
Dispute
Ditto
7.3.1.3 Control Steps of Cutoff Start Time Sequence Point

Its control relationship is as follows:
Table 5 Control Steps of Cut-off Start Time Sequence Point
SN
Transaction
Description of Crucial Function Steps
Names
46

1
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
2
Settlement
Single message:
Carry out settlement according to the cutoff time identified by end of
switch
Dual message:
1. Processing of submitted clearing files must be completed before cutoff
2. The conversion from dual message to single message must

be completed before cutoff
3
Dispute
1. Processing of submitted dispute files must be completed before cutoff

2. Forwarding of dispute online advice must be completed before cutoff
7.3.1.4 Control Steps of Cutoff End Time Sequence Point

Its control relationship is as follows:
Table 6 Control Steps of Cutoff End Time Sequence Point
SN
Transaction
Description of Crucial Functional Steps
Names
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 cancellation
1
Switch
transactions being processed shall follow that of the original

transactions.
2, All reversals of the previous settlement date will be rejected after
cutoff.
47
8 Explanations on Dispute Resolution

8.1
Description of Dispute Resolution Transaction

Dispute resolution transactions include: Inquiry, Inquiry Response, Retrieval Request,
Retrieval Request Fulfillment, Credit Adjustment, Debit Adjustment, Chargeback,
Representment, Second Chargeback, Good Faith, Special Adjustment, Retrieval Request
Postponement and Fee Collection/Funds Disbursement etc.
Among those transactions, Credit Adjustment, Debit Adjustment, Chargeback,
Representment, Second Chargeback, Special Adjustment and Fee collection/Funds
Disbursement participate in settlement.
8.1.1 Inquiry, Inquiry Response, Retrieval Request and Retrieval Request
Fulfillment
Acquirer or issuer could inquire relevant transactions of CUPS or counterpart participant
through inquiry/inquiry response function.
After sending out transaction inquiry request, a participant will wait for the response
from the counterpart participant within a given time and determine whether a dispute
processing needs to be carried out according to the inquiry response of counterpart. If the
inquiring party has to carry out dispute processing only after receiving the inquiry
response while no response from the counterpart participant has been received within the
given time, the inquiring party could carry out dispute processing as the counterpart
participant acknowledges the applying inquiry information options in the inquiry advice
note by default.
Issuer could decide whether to initiate chargeback or do other processing via retrieval
request function, which retrieves photocopies of original vouchers from acquirer via
CUPS.
8.1.2 Retrieval Request Postponement
It refers to the case in which the retrieval request replying party cannot fulfill the request
within given time due to a nimiety of internal processing or other reasons, the party could
initiate a retrieval request postponement prior to the expiration of fulfillment period to
ask for an expansion of fulfillment period. For restrictions on the number of days that are
expansible, please refer to relevant business rules.
8.1.3 Credit Adjustment, Credit Adjustment Cancellation
48
Credit adjustment refers to the action when acquirer offers to transfer the surplus fund to
issuer through CDRS when a surplus is found in the original transaction.. Acquirer has
the right to initiate credit adjustment once within valid time period for settled
transactions such as cash withdraw, purchase, deposit and pre-authorization completion.
The party that initiates credit adjustment may cancel credit adjustment transaction, which
has not been settled or replied/approved.
8.1.4 Debit Adjustment, Debit Adjustment Cancellation
Debit adjustment isinitiated by acquirer to put forward presentment to issuer through
CDRS when acquirer finds a deficit or credit adjustment error in the original transaction.
Acquirer has the right to initiate debit adjustment once for settled transactions such as
cash withdraw, purchase, pre-authorization completion, refund and credit adjustment.
The party that initiates debit adjustment may cancel presentment transaction, which has
not been settled or replied/approved.
8.1.5 Chargeback, Chargeback Cancellation
If issuer has disputes on settled transactions, including cash withdraw, purchase and
pre-authorization completion, or rejects debit adjustment initiated by acquirer, issuer
could initiate chargeback.
For each settled original transaction, 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 chargeback transaction, which has not
been settled or replied/approved.
8.1.6 Representment, Representment Cancellation
Representment is a second time presentment initiated by acquirer when acquirer has
disputes on the chargeback initiated by issuer.
For each settled transaction, acquirer has the right to initiate representment once.
The party that initiates representment may cancel representment transaction, which has
not been settled or replied/approved.
8.1.7 Second Chargeback, Second Chargeback Cancellation
49
Second chargeback is a second time chargeback initiated by issuer when issuer has
disputes on the representment.
The transaction is not applicable to debit card transactions and ATM transactions.
The party that initiates second chargeback may cancel the transaction, which has not
been settled or replied/approved.
8.1.8 Good Faith, Good Faith Response
Good Faith is applicable to transactions, including dispute processing period overdue,
transactions not settled, no transaction records in CUPS and dispute flow ended. Good
Faith is initiated by the party that finds the account error, the Good Faith receiver gives
response to the transaction to indicate whether it agrees with the transaction contents. If
both parties can reach an agreement, the party with a surplus could do payment via
special adjustment transaction.
Good Faith has no corresponding cancellation transaction and is not involved in
settlement.
8.1.9 Special Adjustment, Special Adjustment Cancellation
Special adjustment is applicable to transactions, including dispute processing period
overdue, transactions not settled, no transaction records in CUPS and dispute flow ended,
besides the party initiating the dispute is willing to return the fund, no need to match the
original transactions or no need to obey the dispute flow. The transaction is only used to
transfer credit funds.
The party that initiates special adjustment may cancel the transaction, which has not been
settled or replied/approved.
8.1.10 Fee Collection/Funds Disbursement,Fee Collection/Funds
Disbursement Cancellation
The transaction is used to accomplish specific fund transfer among participants or
between CUPS and participants, such as pick-up card award, dispute processing fee,
non-compliance fines and other fees that participants pay to UnionPay.
Fee Collection transaction could only be initiated by CUPS, while Fund Disbursement
transaction can be initiated by CUPS or the participant, and both Fee Collection
transactions and Fund Disbursement transactions may be cancelled prior to settlement.
50
8.2
Dispute Processing of Domestic/Cross-border Transactions

For disputes occurring in UnionPay standard card cross-border transactions, participants
could log onto CDRS to initiate disputes in the way of input on manual interface. System
would not send dispute processing advice.
8.2.1 General Flow of Dispute Submit over Network Platform
Participants could log onto CDRS to submit disputes in the way of input on manual
interface.
The general processing flow while acquirer or issuer does dispute processing through
network platform is as follows:
1Dispute processing request initiated on network platform
2Dispute processing request submitted to CUPS by network platform

3CUPS replies dispute processing result to network platform
4To inquire dispute result provided by CUPS on network platform

Figure 27 eneral Flow of Dispute Processing
51
9Explanations on Processing of Management and Security Control

Related Transactions
9.1
Network Management Advice Transaction (0820/0830)

9.1.1 Transaction Description
Network management advice transaction is the network management operation
information between CUPS and participants, that is,
to inform participants of settlement date change (cutoff start/end)
to establish and change network status of each participant
Network application layer connection test
participants key reset request
After receiving the network management advice transaction, each participant shall send
the response.
Network management advice transaction is classified into two types: transactions
initiated by CUPS and transactions initiated by participants.
Transactions initiated by CUPS include:
Cutoff Start/Cutoff End
Open and Close participants
Echo Test
Transactions initiated by participants include:

Sign On, Sign Off
Echo Test
participant key reset request (CUPS 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.
9.1.2 Transaction Flow
52
9.1.2.1 Initiated by CUPS

CUPS sends network management advice to each participant, which will send response
1
CUPS
Participant
to CUPS after receiving the advice.
1Network management advice sent to Participants by CUPS (0820)
2Response sent to CUPS by Participants (0830)
Figure 28 Flow of Network Management Transaction Initiated by CUPS
9.1.2.2 Initiated by participants

Participants send network management advice to CUPS, which will send response to
1
CUPS
2
Participant
participants after receiving the advice.
1Network management advice sent to CUPS by Participants (0820)

2Response sent to Participants by CUPS (0830)
Figure 29 Flow of Network Management Transaction Initiated by participants
9.2
Key Reset (0800/0810)

9.2.1 Transaction Description
The transaction is a messages used for key renewal and key synchronization between
53
CUPS and participants. There are two types of the transaction: key reset request initiated
by CUPS on the premise that receiving participant key reset application request and key
reset request initiated by CUPS.
9.2.2 Transaction Flow

9.2.2.1 Key Reset Application Transaction
Participants send key reset application request (0820) to CUPS, which will send response
(0830) immediately after receiving the request, and CUPS initiates 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).
CUPS will abandon the message if CUPS cannot send key reset application response or
key reset request to participants.
2
CUPS
3
Participant
1Key reset application sent to CUPS by Participants (0820)
2Response sent to Participants by CUPS (0830)

3Key reset request sent to Participants by CUPS (0800)
4Key reset response sent to CUPS by Participants (0810)

Figure 30 Flow of participant Key Reset Application
9.2.2.2 Key Reset

CUPS initiates key reset request and sends it to participants, which will send response to
CUPS after receiving the request. When participants are in failure,
CUPS will do manual processing while cannot receive the response.
54
CUPS
2
Participant
1Key reset request sent to Participants by CUPS (0800)

2Key reset response sent to CUPS by Participants (0810)
Figure 31 Flow of CUPS Key Reset
55
10Flow of Transaction Abnormalities Processing

10.1 Overview
This chapter mainly stipulates processing methods of abnormities occurring during the
application interaction among participants. The possible abnormities include:
Message format error
Data security error
Communications abnormities
Terminal operation error
10.2 Rules of Abnormalities Processing
10.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
abnormities occur. The abnormities are as follows:
while participants cannot forward financial transaction acceptance response to the
transaction sender
while receiving reversal advice from the transaction sender
while receiving no response for a request message within timeout period
while receiving a late acceptance response to the request message
10.2.2 Rule 2
When participants cannot send reversal advice correctly, they shall store and forward the
advice.
10.2.3Rule 3
participants shall match with the original transactions while receiving reversal advice. If
the match with original transaction is successful, original transaction will be cancelled
and send reversal successful response (with response code as 00),
56
which will be involved in settlement. Otherwise, a corresponding reject code will be

given according to different situations.
Issuer must properly handle the repeated reversals to avoid chaos in accounting
information.
10.2.4 Rule 4
Except for network management advice (including sign on/sign off, cutoff start and
cutoff end etc.) and reconciliation advice, CUPS or participants shall try to send the
advice to the receiver by adopting store-and-forward mechanism.
10.3 Message Format Error
This section plights the judging and processing of received messages by participants, and
herein only grammatical errors or semantic errors of data elements in the message are
defined.
10.3.1Message Grammatical Error
The grammatical error stands for the inconsistency in received messages with the
message standards in terms of data value scope or data type
If this kind of errors occurs in request message or advice message, CUPS 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 CUPS.
If this kind of errors occurs in acceptance response message of authorization or financial
transactions, CUPS shall abandon the response message and send reversal advice after
timeout period. If such errors occur in response message of advice transactions (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 A.4
Reject Code in Appendix A: Code Definitions of Part VI Annex.
10.3.2 Message Semantic Error
Message semantic error refers to the case in which the message data are invalid to the
transaction semantically (please refer to Table 8 Invalid Data Contents Error of Reversal,
57
Cancellation and Dispute Processing) though the message data grammatically complies
with message standards of bankcard information switch.
If this kind of errors occurs in general request message or advice message, CUPS will
send reject response to acquirer directly and the response codes in it are listed in the
following table:
Table 7 Invalid Data Contents Error
Position No.
Description of Data Content Error
Response Code
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 8 Invalid Data Contents Errors of Reversal, Cancellation and Dispute
Processing Transaction Request
Description of Data Contents Errors
Response Code
Transaction request cannot match the original transaction
25
Description of Data Contents Errors
Re
Transaction is inconsistent with original transaction amount
sp
64
Transaction is inconsistent with original transaction card number

Transaction is inconsistent with original transaction terminal
The original transaction is not accepted
Transaction response cannot match the reversal request
on
14
se
97
Co
12
de
Wr
ite
If this kind of errors occurs in the acceptance response message

int of authorization or
financial transactions, CUPS shall abandon the response message
and send reversal
o
advice after timeout period. If such errors occur in response
log message of advice
transactions (except for network management advice and reconciliation
advice), the
for
sender of the advice will store and forward the advice message. fut
ure
10.4 Data Security Confidentiality Error
ch
ec
This section stipulates processing of data security confidentiality kerrors that occur during
transactions among CUPS, acquirers and issuers. Those errors are as follows:
PIN format error in request messages
58
PIN verification failure in request messages (can only be detected at issuer end)
MAC calculation error in request messages
MAC calculation error in advice messages
MAC error in response to request messages
MAC error in response to advice messages
10.4.1PIN Error
10.4.1.1 PIN Format Error in Request Message
Error type
Message receiver detects format errors in PIN data blocks after decrypting the cipher text
of the PIN.
Acquirers processing
Send reject response to the terminal.

CUPS processing
Send reject response to acquirer with response code = 99
Issuers processing
Send reject response to CUPS with response code = 99

10.4.1.2 PIN Verification failure in Request Message
Error type
Issuer detects that PIN input by cardholder cannot be matched.
Issuers processing
Send reject response to CUPS. If the times of PIN verification failure do not reach the
59
limitation set by issuer, with response code = 55 (incorrect PIN), otherwise with response
code = 38 or 75 (times of PIN input exceed limitation)
10.4.2MAC Error
10.4.2.1 MAC Calculation Error in Request Message
Error type
Message receiver detects that MAC cannot be matched.
CUPS processing
Send reject response to acquirer with response code = A0

Issuers processing
Send reject response to CUPS with response code = A0

10.4.2.2 MAC Calculation Error in Advice Message
Error type
CUPS processing
Send reject response to acquirer with response code = A0

Issuers processing
Send reject response to CUPS with response code = A0

10.4.2.3 MAC Error in Response Message to Request
1.1.1.1.1.1 General Financial Transaction
Error type
60
CUPS processing
Send reject response to acquirer. If the transaction is an accepted financial transaction,

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.
Send reject response message to the terminal. If the transaction is an accepted financial
transaction, reversal message shall be initiated to CUPS with the reversal reason as 4355,
and this reversal participates in reconciliation.
10.4.2.4 MAC Error in Response Message to Advice
Error type
CUPS processing
Write into the log for future check and analysis.

10.5 Communications Abnormality
This section stipulates participants processing of communications failures during
transactions. Communication failures phenomena are as follows:
Sending request message fails
Sending response message to request fails
No response received after sending request message
Sending reversal advice message fails
Sending response message to reversal advice fails
No response received after sending reversal advice message
Receiving late response message to request message
61
The failures are arrayed in line with the sequence of each node that a complete
transaction needs to go through.
When a participant detects communications abnormities with other participants according
to afore-mentioned failure types, it adopts processing rules as follows:
it shall send echo test message (0820) at a certain interval to test if the connection has
been restored.
Unsent response message shall be abandoned.
for request message that needs to be forwarded, response with response code
91(Issuer or switch center is inoperative) will be sent to acquirer.
for advice message (022X and 042X), it shall be saved in store-and-forward queue and
sent after the connection restores.
while receiving response (0830) to echo test, which means the connection restores,
participant shall send out the messages in the store-and-forward queue in turn.
The processing approaches, from communications abnormities to its restoration, shall by
no means be repeated in the following failure treatments.
10.5.1Setting of Issuers Invalid Status by CUPS
10.5.1.1 Invalid Status
CUPS 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 CUPS up to consecutively
several times (setting could be parameterized) without signing off from CUPS.
10.5.1.2 CUPS Processing Method
Under this situation, CUPS will reject all request information sent to the issuer (Except
for information sent to CUPS by the issuer);
Meanwhile, CUPS sends echo test information to the issuer periodically (the frequency
could be set according to the specific situation, and the default is once every two
seconds).
10.5.1.3
Processing at the Restoration
When it is tested as restored, CUPS will re-send accumulated reversal messages and
62
other advice messages. When the issuer completes processing of those messages, issuers
status will be marked as under normal status and CUPS starts forwarding transactions
sent to the issuer.
Participants may apply processing to transactions under the same circumstances by
referring to CUPS processing method.
10.5.2Individual Failure
This section describes abnormalities processing flows of financial transactions, but
referred financial transactions 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 arranged order of abnormalities processing in this section is in accordance with the
order of 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 could easily cause confusion are introduced prior to the flow
description.
The difference between Sender cannot send request and Senders request is lost on the
way.
Sender cannot send request refers to the case in which the sender cannot send the request
due to communications failures, and this phenomenon can be detected by the sender,
which is marked with x in the flow chart for the following articles.
Senders 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 communications 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 reflected is that the transaction
is in timeout, which is marked with ? in the flow chart for the following articles.
Due to the fact that the ultimate situations reflected by the two cases are different, their
processing is different as details are shown as follows.
The difference among The receiver does not receive request from the sender,
The receiver cannot send response and The receivers response is lost on the
way is as follows:
Regarding the sender, processing of those three situations is the same while different
situations are reflected at the receiver 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.
63
The receiver cannot send response refers to the case in which the receiver cannot deliver
the response due to communications failures, and this phenomenon can be detected by
the receiver.
The receivers response is lost on the way refers to the case in which the response is lost
on the way due to communications failures, but this phenomenon can by no means be
detected by the receiver.
Due to the fact the ultimate situations reflected by these three cases are different, the
processing methods adopted by the receiver are different. For details, please refer to
corresponding description in following articles.
10.5.2.1 Acquirer Cannot Forward Request from Terminal
C
U
P
S
Issuer
Acquirer
Terminal
Malfunction
Acquirer cannot forward the request 2 to CUPS due to communications failures.
Reject response 3 sent to the terminal directly by acquirer.

Figure 32 Acquirer Cannot Forward Request from Terminal
10.5.2.2
CUPS Cannot Receive Request
4
5
Malfunction
64
C
U
P
S
Issuer
Acquirer
Terminal
The request 2 of acquirer is lost on the way due to communication failures. Acquirer is
in timeout due to not receiving the response from CUPS.
If the transaction is financial transaction request, acquirer sends the terminal the reject
response 3 initiated by timeout and, meanwhile, it sends CUPS the reversal 4 with
reason code 4354 and this reversal does not participate in reconciliation.
CUPS processing
CUPS sends acquirer the reject response 5 to the reversal with response code 25 and this
reversal does not participate in reconciliation.
Figure 33 CUPS Cannot Receive Request
10.5.2.3
CUPS Cannot Forward Request to Issuer
C
U
P
S
Issuer
Acquirer
Terminal
Malfunction
CUPS cannot forward acquirers request 2 to issuer due to communications failures.
CUPS processing
CUPS sends acquirer request reject response 4 with response code 91.
Figure 34 CUPS Cannot Forward Request to Issuer
10.5.2.4
Issuer Cannot Receive Request
65
Issuer
Acquirer
Terminal
C
U
P
S
5
6
Malfunction
The request 3 of CUPS is lost on the way due to communications failures. CUPS is in
timeout due to no response from issuer.
CUPS processing
CUPS sends acquirer a reject response 4. If the transaction is financial transaction

request, CUPS also needs to send issuer reversal message 5 with reason code 4361 and
this reversal does not participate in reconciliation.
Issuers processing
Issuer sends CUPS reversal reject response 6 with response code 25 and this reversal
does not participate in reconciliation.
Figure 35 Issuer Cannot Receive Request
10.5.2.5 Issuer Cannot Send Request Response to CUPS
Acquirer
Terminal
C
U
P
S
Issuers
7
8
Malfunction
Issuer cannot send CUPS request response 4 due to communications failures.
Issuers processing 1
If the transaction is financial request and accepted, this reversal participates in

reconciliation as internal reversal.
66
CUPS processing
CUPS sends acquirer request reject response 5 imitated by timeout with response code
98. If the transaction is financial transaction request, a reversal 7 also needs to be sent
to issuer with reason code 4361.
Issuers processing 2
Issuer sends CUPS reversal reject response 8 and this reversal does not participate in
reconciliation.
Figure 36 Issuer Cannot Send Request Response to CUPS
10.5.2.6 CUPS Cannot Receive Response from Issuer
6
1
Malfunction
?
7
Issuer
C
U
P
S
Acquirer
Terminal
5
8
CUPS detects timeout when it cannot receive response 4 from issuer after forwarding
request 3 to issuer.
CUPS processing
CUPS sends acquirer request reject response 5 initiated by timeout with response code
98. If the transaction is financial transaction request, reversal 7 also needs to be sent to
issuer with reason code 4361.
Issuers processing
Issuer sends CUPS reversal response 8 and whether the reversal shall participate in
reconciliation at issuer side is determined by the fact whether the original transaction
has been accepted when issuer receives the reversal. If the original transaction has
been accepted, the reversal participates in reconciliation, otherwise it does not.
CUPS detects timeout when it cannot receive response 4 from issuer after forwarding
request 3 to issuer.
CUPS processing
67
CUPS sends acquirer request reject response 5 initiated by timeout with response code 98.
If the transaction is financial transaction request, reversal 7 also needs to be sent to issuer
with reason code 4361.
Issuers processing
Issuer sends CUPS reversal response 8 and whether the reversal shall participate in
reconciliation at issuer side is determined by the fact whether the original transaction has
been accepted when issuer receives the reversal. If the original transaction has been
accepted, the reversal participates in reconciliation, otherwise it does not.
Figure 37 CUPS Cannot Receive Response from Issuer
10.5.2.7 CUPS Receives Late Acceptance Response from Issuer
Issuer
Acquirer
Terminal
C
U
P
S
4
8
Malfunction
CUPS detects timeout of issuer and sends acquirer reject response 4 while completing
following processing according to section 10.5.2.6 and receiving late acceptance
response 6 from issuer.
CUPS processing
CUPS re-sends issuer reversal advice 7 with reason code 4360 and this reversal
participates in reconciliation.
Issuers processing
Issuer sends CUPS reversal response 8 and this reversal participates in reconciliation.
Figure 38 CUPS Receives Late Acceptance Response from Issuer
68
9
10
C
U
P
S
Issuer
Acquirer
Terminal
6
7
8
Malfunction
CUPS cannot forward issuers request response 5 to acquirer.
CUPS processing 1
If the transaction is financial transaction request and accepted, reversal advice 7 will be
sent to issuer with reason code 4363.
Issuers processing
Issuer sends CUPS with reversal response 8. If the transaction is financial transaction
request and accepted, this reversal participates in reconciliation.
Acquirer sends the terminal request reject response 6 initiated by timeout. If the
transaction is financial transaction request, reversal advice 9 also needs to be sent to
CUPS with reason code 4354.
CUPS processing 2
CUPS sends acquirer reversal response 10 and this reversal does not participate in
reconciliation.
10.5.2.8 CUPS Cannot Forward Request Response to Acquirer
1
X
3
C
U
P
S
9
10
4
7
8
Malfunction
69
Issuer
Acquirer
Terminal
6
1
CUPS cannot forward issuers request response 5 to acquirer.
CUPS processing 1
If the transaction is financial transaction request and accepted, reversal advice 7 will be
sent to issuer with reason code 4363.
Issuers processing
Issuer sends CUPS with reversal response 8. If the transaction is financial transaction
request and accepted, this reversal participates in reconciliation.
CUPS with reason code 4354.
CUPS processing 2
CUPS sends acquirer reversal response 10 and this reversal does not participate in
reconciliation.
Figure 39 CUPS Cannot Forward Request Response to Acquirer
70
10.5.2.9 CUPS Receives Early Reversal from Acquirer
Issuer
Acquirer
Terminal
C
U
P
S
6
7
Malfunction
CUPS receives acquirers reversal advice 4 without receiving issuers response within
normal timeout period.
CUPS processing
CUPS sends acquirer reversal response 5 with response code 00. After receiving
transaction response 6 returned by issuer, if the transaction is financial transaction
request and accepted, reversal 7 shall be initiated with reason code 4360 and this
reversal participates in reconciliation. If the original transaction was not accepted,
CUPS will abandon the response directly.
Figure 40 CUPS Receives Early Reversal from Acquirer
10.5.2.10 Acquirer Cannot Receive Response from CUPS
1
?
5
6
C
U
P
S
Issuer
Acquirer
Terminal
Malfunction
Acquirer detects timeout if it does not receive response 3 from CUPS after sending
request 2 to CUPS.
71
CUPS with reason code 4354 and this reversal does not participate in reconciliation.
CUPS processing
After receiving reversal request 5, CUPS checks with response message of original
request, if the original transaction is accepted by issuer, CUPS sends issuer reversal
advice 7 with reason code 4354 and sends acquirer reversal response message with
response code 00. And this reversal participates in reconciliation. If the original
transaction is not accepted by issuer, CUPS sends acquirer reversal response message 6
directly with response code 12, and this reversal does not participate in reconciliation.
Issuers processing
Issuer sends CUPS reversal response 8,and this reversal participates in reconciliation at
issuer side.
Figure 41 Acquirer Cannot Receive Response from CUPS
10.5.2.11Acquirer Receives Late Acceptance Response from CUPS
C
U
P
Issuer
Acquirer
Terminal
8
10
Malfunction
Acquirer detects timeout at CUPS and sends the terminal reject response 5 while
performing sequential operations according to section 10.5.2.9, and afterwards it receives
late acceptance response 6 from CUPS.
Acquirer re-sends reversal advice 7 to CUPS with reason code 4353 and this reversal
participates in reconciliation.
72
CUPS processing
CUPS sends acquirer response 8 immediately after receiving reversal advice, and sends
issuer reversal advice 9 with reason code 4353 and this reversal participates in
reconciliation.
Issuers processing
Figure 42 Acquirer Receives Late Acceptance Response from CUPS
10.5.2.12Acquirer Cannot Send Terminal Operation Instruction
Issuer
Acquirer
Terminal
3
C
U
P
S
10
Malfunction
Acquirer cannot send the terminal operation instruction 6 due to communication

failures.
If the transaction is financial transactions request and accepted, acquirer sends CUPS
reversal advice 7 with reason code 4356 and this reversal participates in reconciliation.
CUPS processing
CUPS sends acquirer response 8 immediately after receiving reversal advice and sends
issuer reversal advice 9 with reason code is 4356 and this reversal participates in
reconciliation.
Issuers processing
73

Figure 43 Acquirer Cannot Send Terminal Operation Instruction
10.5.3Dual Failures
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 explanation on abnormality processing of special transactions
in this Chapter.
10.5.3.1 CUPS Cannot Send Acquirer Reject Response
Issuer
Acquirer
Terminal
4
C
U
P
S
Malfunction
CUPS sends acquirer transaction request reject response 3 after detecting

communications failures at issuer side, but sending of the response fails due to other
communications failures.
CUPS processing
CUPS abandons the response message without sending issuer reversal advice.
Acquirer sends terminals request reject response after detecting timeout at CUPS. If
the transaction is financial transaction request, timeout reversal 5 will be sent to CUPS
with reason code 4354. CUPS shall send acquirer reject response 6 with response code
12 immediately after receiving reversal advice, and this reversal does not participate in
reconciliation at both acquirer side and CUPS.
74

Figure 44 CUPS Cannot Send Acquirer Reject Response
10.5.3.2 CUPS Cannot Send Issuer Reversal Advice
Pheno
P
S
?
7
4
X
Issuer
C
U
Acquirer
Terminal
Figure 44 CUPS Cannot Send Issuer Reversal Advice
CUPS sends issuer reversal advice 7 after it detects communications failures (please
refer to section 10.5.2.8 CUPS Cannot Forward Request Response to Acquirer; and
section 10.5.2.7 CUPS Receives Late Acceptance Response from Issuer), but sending
of the reversal fails due to other communications failures.
CUPS processing
CUPS saves the unsent reversal advice in store-and-forward queue and re-sends it after
the connection restores.
10.5.3.3 Acquirer Cannot Send CUPS Reversal Advice
C
Issuer
Acquirer
Terminal
U
P
S
X
7
Figure 45 Acquirer Cannot Send CUPS Reversal Advice
Malfunction
Acquirer sends CUPS reversal advice 7 after detecting the previous communications
failure (please refer to section 10.5.2.12 Acquirer Cannot Send Terminal Operation
Instruction; section 10.5.2.11 Acquirer Receives Late Acceptance Response from
CUPS; and section 10.6.1 Reversal Initiated by Terminal), but sending of the reversal
by acquirer fails again due to communications failures.
75
Acquirer saves the unsent reversal advice in store-and-forward queue and re-sends it
after the connection restores.
10.6 Terminal Operation Error

This section stipulates processing by Acquirer and CUPS in case of Terminal Operation
Error; herein, Terminal Operation Error only refers to the case in which Terminal cannot
correctly execute orders sent by Mainframe.
10.6.1Without Communication Failures

Reversal Initiated by Terminal
3
C
11
Issuer
Acquirer
Terminal
12
10
Figure 46 Reversal Initiated by Terminal
Malfunction
The terminal cannot work properly and sends acquirer error status, such as ATM does
not complete the cash disbursing, POS terminal initiates reversal automatically, etc.
In reversal advice, reason code 4351 means transaction fails at terminal.

Acquirer, CUPS and Issuer participant the reconciliation of this reversal transaction.
10.6.2Communication Failures
Flow of Special Acquirer Cannot Send CUPS Reversal Initiated by Terminal

Operation Error.
76
5
9
X
C
U
P
S
3
4
Issuer
Acquirer
Terminal
Figure 47 Acquirer Cannot Send CUPS Reversal Initiated by Terminal Operation Error
Malfunction
Acquirer cannot send CUPS reversal advice 9 initiated by terminal operation error due
to communications failures (Please refer to section 10.6.1 Reversal Initiated by
Terminal).
Acquirer saves the reversal advice in store-and-forward queue and re-sends it after the
connection restores.
Table 9 Response codes used in abnormality processing
Reason Code
Explanation
4351
Reversal initiated by terminal (full amount)
4352
Reversal initiated by terminal (partial amount)
4353
Acquirer receives late response from CUPS
4354
Acquirer detects timeout
4355
Acquirer detects incorrect MAC in response message
4356
Acquirer cannot send operation instruction to terminal
4360
CUPS receives late response from issuer
4361
CUPS waits for issuers response till timeout
4362
CUPS detects incorrect MAC in response message from issuer
4363
CUPS cannot forward response messages from issuer to acquirer
10.7 Transaction Abnormalities Processing
10.7.1Remittance Transaction (online) Abnormalities Processing
This section will highlight abnormalities processing flows for several special
transactions, including deposit, transfer and load and unload of IC card based on
CUPIC e-purse/passbook standards.
77
The arranged order of abnormalities processing in this section is in accordance with

the order of 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 processings adopted by acquirer and issuer are
different, though processing by CUPS 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.
10.7.1.1 Acquirer Cannot receive Remittance Verification Response
Issuer
CUPS
Acquirer
Terminal
Figure 49 Acquirer Cannot receive Account Verification Response
Malfunction
Acquirer cannot receive Account Verification Response 5 due to communication

failures.
CUPS processing
No processing
Acquirer send time-out response 6 to terminal which means Acquirer cannot receive
response from CUPS.
Terminals processing
78
Transaction Failure, Chargeback customer and stop sequent Remittance Transaction.

But can restart Account Verification Transaction.
10.7.1.2 Acquirer receives Non-Acceptance Remittance Verification
Response
Issuer
CUPS
Acquirer
Terminal
Malfunction
Acquirer receives Non-Acceptance Account Verification Response 6.
CUPs processing
No processing
No processing
Transaction Failure, return the funds to customer and stop sequent Remittance
Transaction. But can restart Account Verification Transaction.
10.7.1.3 Terminal receives Non-Acceptance Remittance Transaction
Response
Issuer
CUPS
Acquirer
Terminal
79
Figure 51 Terminal receives Non-Acceptance Remittance Transaction Response
Malfunction
Terminal receives 'Non-Acceptance Remittance Transaction Response 12.
Transaction success, accept funds Inform customer that Remittance Success. funds
reaching account would be delayed.
Further processing
Acquirers credit Issuers account by manual remittance transaction.
10.7.1.4 Terminal cannot send Remittance Request
Issuer
CUPS
Acquirer
Terminal
Figure 52 Terminal cannot send remittance request
Malfunction
Terminal cannot send Remittance Request 7.
Not necessary to re-send Remittance Request. Transaction success, accept funds.

Inform customer that Remittance Success. funds reaching account would be delayed.
Further processing
10.7.1.5 Acquirer cannot receive Transfer Request
80
Issuer
CUPS
Acquirer
Terminal
Figure 53 Acquirer cannot receive transfer request
Malfunction
Terminal send Remittance Request 7 to Acquirer but Request lost.
Not necessary to re-send Remittance Request. Transaction success, accept funds.

Inform customer that Remittance Success. funds reaching account would be delayed.
Further processing

10.7.1.6 Acquirer cannot forward Transfer Request from Terminal
Issuer
CUPS
Acquirer
Terminal
Figure 54 Acceptance cannot forward transfer request from terminal
Malfunction
Account Verification Success. But Acquirer cannot forward Remittance Request 8

from Terminal due to communication error.
Acquirer sends Reject Response 9 to Terminal as soon as it detects the failure of

forwarding Remittance Transaction.
81
Transaction success, accept funds. Inform customer that Remittance Success. funds
reaching account would be delayed.
Further processing

10.7.1.7 CUPS cannot receive Remittance Request
Issuer
CUPS
Acquirer
Terminal
Figure 55 CUPS cannot receive remittance request
Malfunction
Account Verification Success. But CUPS cannot receive Remittance Request 8 from
Acquirer which may be lost due to communication error.
Acquirer sends Reject Response 9 to Terminal when Transaction time-outs.
Transaction success, accept funds. Inform customer that Remittance Transaction

Success. funds reaching account would be delayed.
Further processing

10.7.1.8 CUPS cannot forward Remittance Request to Issuer
Issuer
CUPS
Acquirer
Terminal
82
Figure 56 CUPS cannot forward remittance request to issuer
Malfunction
Account Verification Success. But CUPS cannot forward Remittance Request 9 to

Issuer due to communication error.
CUPs processing
CUPS sends Reject Response 10 to Acquirer as soon as it detects the failure of

forwarding Remittance Request.
Acquirer forwards Reject Response 11 to Terminal.

Success. Funds reaching account would be delayed.
Further processing
Acquirer credits Issuers account by manual Remittance Transaction.

10.7.1.9 Issuer cannot receive Remittance Request
Issuer
CUPS
Acquirer
Terminal
Malfunction
Account Verification Success. But Issuer cannot receive Remittance Request 9 from
CUPS which would be lost due to communication error.
CUPs processing
CUPS sends Reject Response 10 to Acquirer when Issuers response time-outs.
83

Further processing
10.7.1.10Issuer cannot send Remittance Request Response to CUPS
Issuer
CUPS
Acquirer
Terminal
Malfunction
Account Verification Success. But Issuer cannot send Remittance Request Response
10 to CUPS due to communication error.
CUPs processing

Further processing
Figure 58 Issuer cannot send remittance request response to CUPS

10.7.1.11CUPS cannot receive Remittance Response from Issuer
84
Issuer
CUPS
Acquirer
Terminal
Figure 59 CUPS cannot receive remittance response from issuer
Malfunction
Account Verification Success. But CUPS cannot receive Remittance Request

Response 10 from Issuer which would be lost due to communication error.
CUPs processing

Further processing
10.7.1.12CUPS receive Late Remittance Response from Issuer
Malfunction
85
Issuer
CUPS
Acquirer
Terminal
Figure 60 CUPS receive late remittance response from issuer
Account Verification Success. But CUPS receive Late Remittance Request Response
12 from Issuer after it sends Reject Response 10 to Acquirer due to communication
error.
CUPs processing
CUPS sends Reject Response 10 to Acquirer when Issuers response time-outs and
then receive Late Transfer Response from Issuer. CUPS doesnt process Response 12
and throws it out.
Transaction success, accept fund. Inform customer that Remittance Transaction

Further processing

10.7.1.13CUPS cannot forward Remittance Request Response to Acquirer
Issuer
CUPS
Acquirer
Terminal
Figure 61 CUPS cannot forward remittance request response to acquirer
10.7.1.14Acquirer cannot receive Remittance Request Response from

CUPS
Malfunction
Account Verification Success. But CUPS cannot forward Remittance Request

Response 11 to Acquirer due to communication error.
86
Acquirer sends Reject Response 12 to Terminal when response time-outs.

Success. fund reaching account would be delayed.
Further processing
If Response 11 is Acceptance Response, CUPS will settle this Transaction. There

would be no dispute and dont need further processing. If Response 11 is
Non-Acceptance Response, Acquirer should credit Issuers account by manual
Issuer
CUPS
Acquirer
Terminal
Figure 62 Acquirer cannot receive remittance request response from CUPS
Malfunction
Account Verification Success. But Acquirer cannot receive Remittance Request

Response 11 from CUPS which would be lost due to communication error.
Acquirer sends Reject Response 12 to Terminal when response time-outs.

Success. Fund reaching account would be delayed.
Further processing

10.7.1.15Acquirer receive Late Remittance Request Response from CUPS

87
Issuer
CUPS
Acquirer
Terminal
Figure 63 Acquirer receive late remittance request response from CUPS
Malfunction
Account Verification Success. But Acquirer receives Late Remittance Request

Response 12 from CUPS after it sends Time-out Response 11 to Terminal due to
communication error.
No processing. Throw Response 12 out.

Further processing

10.7.1.16Acquirer cannot send Remittance Response to Terminal
88
Issuer
CUPS
Acquirer
Terminal
Figure 64 Acquirer cannot send remittance response to terminal
Malfunction
Account Verification Success. But Acquirer cannot send Response 12 to Terminal due
to communication error.
Wait until Response time-outs. Transaction success, accept fund. Inform customer that
Remittance Transaction Success. Funds reaching account would be delayed.
Further processing
If Response 12 is Acceptance Response, there would be no dispute and dont need

further processing. If Response 12 is Non-Acceptance Response, Acquirer should
credit Issuers account by manual Remittance Transaction.
10.7.2Designated Account Loading and cash Loading of E-Cash Application
based on CUPIC Debit/Credit standard
If reversal is triggered when a designated account loading transaction initiated doesnt
work. Please refer to Section 10.5.2 Individual Failure for processing flow and
principles.
Cash loading transactions equals to deposit. Since a loading transaction must be approved
by a terminal, confirmation advice cannot be sent but reversal advice. Please refer to
Section 10.5.2 Individual Failure for processing flow and principles.
89

China Transactions EMV

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

China Transactions EMV

Uploaded by

Copyright:

Available Formats

Technical Specifications on Bankcard

Part I Transaction Processing

THIS PAGE INTENTIONALLY LEFT BLANK.

Part I: Transaction Processing

Application Scope .................................................................................. 4

Terms and Definitions ............................................................................ 6

General Processing Flows of Transactions ........................................ 11

Request and Advice Transaction .......................................................................... 11

Request Transaction ............................................................................... 11

Advice Transactions ................................................................................ 11

Explanation on Transaction Switch Processing ................................. 16

Single-message Transactions Processing ........................................................ 16

Pre-authorization Transaction 0100/0110 ............................................. 16

MO/TO Pre-authorization Transaction 0100/0110 ................................ 16

Financial Transaction 0200/0210 ........................................................... 17

Balance Inquiry 0200/0210 ...................................................................... 21

UnionPay Card Exchange Rate Inquiry 0600/0610 .............................. 21

Financial Advice Transaction 0220/0230 .............................................. 25

5.1.11 Cross-border Single Message Transaction verified via CUPSecure 36

Authorization Transaction ....................................................................... 36

Reversal Transaction ............................................................................... 37

Supported Transaction Types ................................................................ 38

Part I: Transaction Processing

E-cash Application-based Transaction Types ...................................... 40

Explanations on Stand-in Authorization Transaction Processing .... 42

Overview of Stand-in Authorization Transaction ............................................. 42

Obtaining Stand-in Authorization Transaction Log ......................................... 43

Transactions resulting from Processing of Clearing and Settlement 44

CUPS Cutoff Advice Transaction (0820/0830) ................................................... 44

Time Sequence of CUPS Clearing and Settlement .......................................... 45

Processing Flow of Message Sending amid CUPS Cutoff Period .... 44

Explanations on Dispute Resolution ................................................... 48

Description of Dispute Resolution Transaction ............................................... 48

Inquiry, Inquiry Response, Retrieval Request and Retrieval Request

Credit Adjustment, Credit Adjustment Cancellation ........................... 48

Chargeback, Chargeback Cancellation ................................................ 49

Second Chargeback, Second Chargeback Cancellation .................... 49

Special Adjustment, Special Adjustment Cancellation ...................... 50

Fee Collection/Funds Disbursement,Fee Collection/Funds

Disbursement Cancellation ................................................................................... 50

General Flow of Dispute Submit over Network Platform ................... 51

Explanations on Processing of Management and Security Control

Related Transactions ................................................................................. 52

Network Management Advice Transaction (0820/0830) .................................. 52

Transaction Description .......................................................................... 52

Transaction Description .......................................................................... 53

Flow of Transaction Abnormalities Processing ......................... 56

Part I: Transaction Processing

10.1 Overview ...................................................................................................................... 56

10.2.4 Rule 4 ......................................................................................................... 57

Message Grammatical Error ................................................................... 57

Message Semantic Error ......................................................................... 57

10.4 Data Security Confidentiality Error ...................................................................... 58

PIN Error .................................................................................................... 59

10.4.2 MAC Error .................................................................................................. 60

Setting of Issuers Invalid Status by CUPS .......................................... 62

10.5.3 Dual Failures ............................................................................................. 74

Without Communication Failures .......................................................... 76

10.7 Transaction Abnormalities Processing ............................................................... 77

Remittance Transaction (online) Abnormalities Processing ............. 77

Designated Account Loading and cash Loading of E-Cash

Application based on CUPIC Debit/Credit standard .......................................... 89

Part I: Transaction Processing