Technical Specifications on Bankcard
Interoperability
(Version 2.1)
Part I Transaction Processing
i
Table of Contents
Using this Document
... 1
1
Application Scope
... 4
2
References
... 5
3
Terms and Definitions
... 6
4
General Processing Flows of Transactions
... 11
4.1 Request and Advice Transaction ... 11
4.1.1 Request Transaction ... 11
4.1.2 Advice Transactions ... 11
4.1.3 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
5
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 MO/TO Pre-authorization Transaction 0100/0110 ... 16
5.1.3 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 UnionPay Card Exchange Rate Inquiry 0600/0610 ... 21
5.1.8 Reversal Advice 0420/0430 ... 22
5.1.9 Financial Advice Transaction 0220/0230 ... 25
5.1.10 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 Authorization Transaction ... 36
5.2.2 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.2 E-cash Application-based Transaction Types ... 40
6
Explanations on Stand-in Authorization Transaction Processing
.... 42
6.1 Overview of Stand-in Authorization Transaction ... 42
6.2 Processing Stand-in Authorization Transaction ... 42
6.3 Obtaining Stand-in Authorization Transaction Log ... 43
7
Transactions resulting from Processing of Clearing and Settlement
44
7.1 CUPS Cutoff Advice Transaction (0820/0830) ... 447.2 Processing Flow of Transactions resulting from Self-Administered Clearing/Settlement ... 44
7.2.1 Processing Flow of Message Sending amid CUPS Cutoff Period .... 44
7.2.2 Processing of Clearing/Settlement Files ... 45
7.3 Time Sequence of CUPS Clearing and Settlement ... 45
7.3.1 Time Sequence Coordination ... 46
8
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 Credit Adjustment, Credit Adjustment Cancellation ... 48
8.1.4 Debit Adjustment, Debit Adjustment Cancellation ... 49
8.1.5 Chargeback, Chargeback Cancellation ... 49
8.1.6 Representment, Representment Cancellation ... 49
8.1.7 Second Chargeback, Second Chargeback Cancellation ... 49
8.1.8 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
9
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 Transaction Description ... 53
9.2.2 Transaction Flow ... 54
iii
10.1 Overview ... 56
10.2 Rules of Abnormalities Processing ... 56
10.2.1 Rule 1 ... 56
10.2.2 Rule 2 ... 56
10.2.3 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 Setting of Issuer’s Invalid Status by CUPS ... 62
10.5.2 Individual Failure... 63
10.5.3 Dual Failures ... 74
10.6 Terminal Operation Error ... 76
10.6.1 Without Communication Failures ... 76
10.6.2 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
1
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: [email protected] For questions related to transaction processing: Fax:(86-21) 5036-2339
3
Summary of Revisions
Description of Change Where to look
Added: MO/TO Refund Section 4.1.4.1
1 Application Scope
5
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 System（CDRS）.
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
7
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 issuer，and 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.
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.
9
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 authenticationsecureinformationontheinterfaceprovidedby Secure Authentication and Authorization Sever (SAA) and completes corresponding payment transactions.
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.
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.
11
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.
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 advice transaction: Network Management Advice Message
(0820/0830)
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
A
cq
u
ir
er
CUPS
I
s
su
e
r
1
2
3
4
1—Transaction request sent to CUPS from acquirer 2—Transaction request forwarded to issuer by CUPS 3—Transaction response sent to CUPS from issuer 4—Transaction 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, MOTO Authorization Cancellation,
13
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.
the sender the receiver
1
2
Figure 2 Normal Processing Flow of the Request Transaction Processed Directly by CUPS 1—Transaction request sent to the receiver by the sender
2—Response 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.
4.1.4.1 Normal Processing Flow of Advice Transaction Switched via CUPS A c qu i re r CUPS I ss u er 1 3 4 2
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
the sender the
receiver 1
2
1—Advice sent to the receiver from the sender 2—Response 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.
15
4.1.4.1 Processing Flow Description of Advice Transaction Processed Directly by CUPS
1
the sender the
receiver 2
Figure 4 Processing Flow of Advice Transaction Processed Directly by CUPS 1—Advice sent to the receiver from the sender
2—Response 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.
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 cardholder’s transaction to issuer. Acquirer takes the estimated purchase amount as the pre-authorization amount and sends it to the cardholder’s 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 cardholder’s 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.
17
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-authorizationCancellation Transaction(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, cardholder’s 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.
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:
19
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 customer’s 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
Acq u ir er Is suer 1 2 4 5 3 6 8 7 CUPS
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 doesn’t 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 Cardholder’s Transfer and amount. It’s 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 Transaction’s field 90 (original data element) and reject Remittance Transaction if the match failed.
Issuer doesn’t need to match Remittance transaction with Remittance Verification. Remittance Transaction doesn’t 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.
21
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 doesn’t receive any response, and response will be dropped if the receiver is
not able to send response.
5.1.7.2 Transaction Flow
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.
Ac qu ir er CUPS 1 2
1—UnionPay card exchange rate inquiry (0600) sent to CUPS by the Acquirer 2—Response (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
23
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, Cash Withdrawal, Reversal advice is not allowed across the settlement date.
5.1.8.1 Normal Transaction Flow
A
cq
u
ir
er
CUPSIs
su
er
2 3 1 1—Reversal advice (0420) sent to CUPS by acquirer 2—Reversal responses (0430) sent to acquirer by CUPS 3—Reversal advice (0420) sent to issuer by CUPS 4—Reversal 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.
Sender
Receiver
1
2
3
4
1—Reversal advice sent to receiver by sender
2—Reversal response sent to sender by receiver. Abnormal situation at the receiver.
3—Reversal advice re-sent to receiver by sender 4—Reversal 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.
Sender
Receiver
1
3
2
1. Reversal advice sent to the receiver by the sender, and it cannot be sent due to faults.
25
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
1－Pre-authorization completion ( advice) (0220) sent to CUPS by acquirer 2－Response (0230) sent to acquirer by CUPS
3－Settlement advice (0220) sent to issuer by CUPS 4－Response (0230) sent to CUPS by issuer
Acq u ir er Is suer 1 4 3 4 CUPS
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 receiver’s response to the transaction, it will save the advice in the store-and-forward queue for storing and forwarding.
Sender
Receiver
1
3
2
1－Pre-authorization completion (advice) sent to the receiver by the sender cannot be sent out due to failures.
2－After recovery of the sender,, pre-authorized completion ( advice) sent to receiver by the sender.
3－Response 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
settlementadvicefor thepreviouslyapprovedMO/TO pre-authorization.Its settlement procedure is the same as regular settlement advice.
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
27
Ac
q
u
ire
r
Is
su
er
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.
A
cq
u
ir
er
CUPSIs
su
er
2 3 1 1－Dual-message clearing file sent to CUPS by acquirer 2－Fund settlement advice sent to issuer by CUPS 3－Response sent to CUPS by issuer
Figure 12 Flow of the Settlement Advice
5.1.9.2.2Abnormal Transaction Flow
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.
1
CUPS
3
1－Dual-message clearing file sent to CUPS by acquirer
2－CUPS cannot send the settlement advice to issuer due to some reason 3－Settlement advice re-sent by CUPS
4－Response re-sent to CUPS by issuer
29
Is
su
er
5.1.9.3 Refund (Online)/ MO/TO Refund (Online)
It is the procedure that merchants refund the deducted fund to cardholder’s 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.
5.1.9.3.1 Normal Transaction Flow
A cq u ir er CUPS Issu er 1 3 4 2 1－Refund advice (0220) sent to CUPS by acquirer
2－Response (0230) sent to acquirer by CUPS 3－Advice (0220) sent to issuer by CUPS 4－Response (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 receiver’s 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.
1－Refund advice cannot be sent to the receiver by the sender due to failures. 2－After recovery of the sender, refund advice re-sent to the receiver by the
sender.
3－Receiver’s 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 issuer’s reconciliation instead of acquirer’s reconciliation.
5.1.10.1.1 Normal Transaction Flow
·
¢
ËÍ
·
½
½Ó
ÊÕ
·
½
1 3 2 Sender Receiv er31
er
1—Acquirer logs onto the CPU public services platform and initiates pre-authorization cancellation (manual) transaction
2—CPU public services platform informs CUPS of pre-authorization cancellation (manual)
3—CUPS will send pre-authorization cancellation (manual) request message to issuer immediately after receiving it
4—Issuer sends back pre-authorization cancellation (manual) response massage to CUPS
Figure 16 Normal Flow of manual Pre-authorization Cancellation
5.1.10.1.2 Abnormal Transaction Flow
When the sender cannot send the manual pre-authorization cancellationrequest to the receiver, or does not receive manual pre-authorization cancellation response from the Acquirer
CDRS
receiver, it will initiate manual pre-authorization cancellationreversal.
1—Acquirer initiates pre-authorization cancellation (manual) transaction on the CDRS
2—PCDRSsends the pre-authorization cancellation (manual) request to CUPS 3—Pre-authorization cancellation (manual) request sent to issuer by CUPS is lost
on the way due to failure, and it will cause CUPS timeout
4—Pre-authorization cancellation (manual) reversal advice sent to issuer by CUPS 5—Pre-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-of–day of current day. After cancellation, original manual refund and manual
Is sue r CDRS A cqui rer
33
A c q u i r e r
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.
General transaction processing flow for manual refund is as follows:
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
Acq u ir er CDRS Iss uer
A cqu ir er Is su er
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 Summary Report as well.
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 Summary Report as well.
General processing flow for manual pre-authorization completion is as follows:
UnionPay Public Services Platform
1－Acquirer logs onto the UnionPay public services platform to initiate manual pre-authorization completion
2－CDRS informs CUPS of the pre-authorization completion (manual)
3－After cutoff, CUPS sends general transaction detail files to issuer, including pre-authorization completion
35 A cqu ir er Is su er
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 Resolution Platform
1－Acquirer logs onto the CDRS to initiate manual Remittance
2 － UnionPay Dispute Resolution Platform informs CUPS of the manual Remittance
3－After cutoff, CUPS sends general transaction detail files to participants, including manual Remittance
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 cardholder’s 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 issuer’s settlement. An approved authorization transaction is
37
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.
A cqu ir er c en ter Is sue r cen tr e 5.3 Timeout Setting
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
39
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.
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.
The transaction flow is as follows:
Ac qu ir er CUPS Is su er 5 6 2 1 4 3 7 8
1—Designated account loading request sent to CUPS by acquirer 2—Designated account loading request sent to issuer by CUPS 3—Designated account loading response sent to CUPS by issuer 4—Designated account loading response sent to acquirer by CUPS
5—Script processing result advice sent to CUPS by acquirer, informing issuer of the result of the loading transaction
6—Script processing result advice response sent to acquirer by CUPS
7—Script processing result advice sent to issuer by CUPS, informing issuer of the result of the loading transaction
8—Script 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
41
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 settlement. Ac qu ir er CUPS Is su er 5 6 2 1 4 3 7 8
1—Cash loading request sent to CUPS by acquirer 2—Cash loading request sent to issuer by CUPS
3—Cash account loading response sent to CUPS by issuer 4—Cash loading response sent to acquirer by CUPS
5—Script processing result advice sent to CUPS by acquirer, informing issuer of the result of the cash loading transaction
6—Script processing result advice response sent to acquirer by CUPS
7—Script processing result advice sent to issuer by CUPS, informing issuer of the result of the cash loading transaction
8—Script 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.
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:
Acquirer AuthorizationStand-in Issuer
CUPS
1
2
Stand-in Authorization
1—The Acquirer sends an authorization request to CUPS
2—CUPS processes applicable transactions through stand-in authorization, and returns the result to the Acquirer.
43
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.
