Technical Specifications on Bankcard. Interoperability. (Version 2.1) Part I Transaction Processing

Transcription

1 Technical Specifications on Bankcard Interoperability (Version 2.1) Part I Transaction Processing October 2011

2 THIS PAGE INTENTIONALLY LEFT BLANK.

3 Table of Contents Using this Document Application Scope References Terms and Definitions General Processing Flows of Transactions Request and Advice Transaction Request Transaction Advice Transactions Normal Processing Flow of Request Transaction Normal Processing Flow of Advice Transaction Store-and-forward Mechanism of Transaction Message Explanation on Transaction Switch Processing Single-message Transactions Processing Pre-authorization Transaction 0100/ MO/TO Pre-authorization Transaction 0100/ Pre-authorization Cancellation Transaction (Online) 0100/ MO/TO Pre-authorization Cancellation Transaction (Online) 0100/ Financial Transaction 0200/ Balance Inquiry 0200/ UnionPay Card Exchange Rate Inquiry 0600/ Reversal Advice 0420/ Financial Advice Transaction 0220/ Manual Transaction Cross-border Single Message Transaction verified via CUPSecure Dual-message Transaction Processing Authorization Transaction Authorization Cancellation Transaction Reversal Transaction Balance Inquiry Transaction Timeout Setting Timeout Setting Rules for General Transactions IC Card Transaction based on CUPIC Debit/Credit Standards Supported Transaction Types i

4 5.4.2 E-cash Application-based Transaction Types Explanations on Stand-in Authorization Transaction Processing Overview of Stand-in Authorization Transaction Processing Stand-in Authorization Transaction Obtaining Stand-in Authorization Transaction Log Transactions resulting from Processing of Clearing and Settlement CUPS Cutoff Advice Transaction (0820/0830) Processing Flow of Transactions resulting from Self-Administered Clearing/Settlement Processing Flow of Message Sending amid CUPS Cutoff Period Processing of Clearing/Settlement Files Time Sequence of CUPS Clearing and Settlement Time Sequence Coordination Explanations on Dispute Resolution Description of Dispute Resolution Transaction Inquiry, Inquiry Response, Retrieval Request and Retrieval Request Fulfillment Retrieval Request Postponement Credit Adjustment, Credit Adjustment Cancellation Debit Adjustment, Debit Adjustment Cancellation Chargeback, Chargeback Cancellation Representment, Representment Cancellation Second Chargeback, Second Chargeback Cancellation Good Faith, Good Faith Response Special Adjustment, Special Adjustment Cancellation Fee Collection/Funds Disbursement,Fee Collection/Funds Disbursement Cancellation Dispute Processing of Domestic/Cross-border Transactions General Flow of Dispute Submit over Network Platform Explanations on Processing of Management and Security Control Related Transactions Network Management Advice Transaction (0820/0830) Transaction Description Transaction Flow Key Reset (0800/0810) Transaction Description Transaction Flow Flow of Transaction Abnormalities Processing ii

5 10.1 Overview Rules of Abnormalities Processing Rule Rule Rule Rule Message Format Error Message Grammatical Error Message Semantic Error Data Security Confidentiality Error PIN Error MAC Error Communications Abnormality Setting of Issuer s Invalid Status by CUPS Individual Failure Dual Failures Terminal Operation Error Without Communication Failures Communication Failures Transaction Abnormalities Processing Remittance Transaction (online) Abnormalities Processing Designated Account Loading and cash Loading of E-Cash Application based on CUPIC Debit/Credit standard iii

6 THIS PAGE INTENTIONALLY LEFT BLANK. iv

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

8 Please address your questions to the service teams as follows: For questions related to this manual: Fax: (86-21) For questions related to transaction processing: Fax:(86-21)

9 Summary of Revisions Added: MO/TO Refund Description of Change Where to look Section Added: MO/TO Refund Procedures Section

10 1 Application Scope This Specification applies to all UnionPay participants. 4

11 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 5

12 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 Credit payment tool issued to the public by, financial institutions like commercial banks, 6

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

14 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) 8

15 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, or other non face-to-face method. Merchants initiate the debit request and complete the payment procedure. 9

16 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

17 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 01XX 02XX 04XX 05XX 06XX 08XX Transaction Type Pre-Authorization Financial/ Financial Advice Reversal Reconciliation Control Management Network Management Above transactions can be classified into two types: request transaction and advice transaction 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 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

18 Acquirer Issuer Part I: Transaction Processing 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) 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 Normal Processing Flow Description of the Request Transaction Switched via CUPS 1 4 CUPS 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, 12

19 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 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 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/ 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

20 Acquirer Issuer Part I: Transaction Processing Normal Processing Flow of Advice Transaction Switched via CUPS 1 2 CUPS 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 Processing Flow Description of Advice Transaction Processed Directly by CUPS 1 the sender the receiver 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. 14

21 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. Store-and-forward mechanism is normally used for sending some advice messages. 15

22 5 Explanation on Transaction Switch Processing 5.1 Single-message Transactions Processing 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 Reversal Advice 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 Reversal Advice 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

23 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 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 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 Reversal Advice. Remittance may not trigger any advice messages. For the conditions and procedures for remittance abnormal processing, please refer to Section Cash Withdrawal 17

24 The procedure that cardholder withdraws cash at ATM, POS, bank counter or via other terminal channel Pre-authorization Completion (request) For approved pre-authorization transaction, Pre-authorization Completion (request) is used for settlement 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 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 MO/TO Purchase It refers to the purchase transaction initiated by cardholders to agent organizations through phone or fax, etc 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 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

25 Acquirer Issuer Part I: Transaction Processing CUPS 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 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 19

26 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 Remittance 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 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: Pre-authorization 20

27 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 Reversal Advice 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 UnionPay Card Exchange Rate Inquiry 0600/ 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 21

28 Acquirer Part I: Transaction Processing not able to send response 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. 1 2 CUPS 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 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

29 Acquirer Issuer Part I: Transaction Processing 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 Normal Transaction Flow 1 CUPS 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 Abnormal Transaction Flow Receiver of Reversal Advice Cannot Send Reversal Response When the receiver of the reversal advice cannot send the reversal response to the sender of the reversal advice, the receiver will abandon it directly. The receiver will not send the response to the sender until it receives the reversal advice re-sent by the sender. 23

30 1 2 Sender Receiver 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 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 2 Receiver 3 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

31 Acquirer Issuer Part I: Transaction Processing 3. Response to the reversal advice from the receiver Figure 9 Abnormal Flow 2 of Reversal 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 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) Normal Transaction Flow 1 4 CUPS 3 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 25 4

32 Figure 10 Flow of Pre-authorization Completion (Advice) Abnormal 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. 1 Sender 2 Receiver 3 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) 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 26

33 Acquire r Issuer Acquirer Issuer Part I: Transaction Processing 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 Normal 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. 1 CUPS 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 Abnormal 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 27

34 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 Figure 13 Abnormal Flow of Settlement Advice 28

35 Acquirer Issuer Issuer Part I: Transaction Processing 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 Normal Transaction Flow 1 2 CUPS 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) 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. 29

36 Receiver Sender Part I: Transaction Processing ËÍ ½ ½Ó ÊÕ ½ 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 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 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 Normal Transaction Flow 30

37 Issuer Part I: Transaction Processing Issuer 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 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 31

38 Acquirer Issuer Part I: Transaction Processing receiver, it will initiate manual pre-authorization cancellationreversal. CDRS 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 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 32

39 Acquirer A c q u i r e r Part I: Transaction Processing 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: CDRS 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 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

40 Issuer Acquirer Part I: Transaction Processing 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 34

41 Issuer Acquirer Part I: Transaction Processing Figure 19 General Processing Flow for Manual Pre-Authorization Completion 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 35

42 Figure 20 General Processing Flow for Manual Remittance 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 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 Cross-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 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 36

43 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 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 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 Balance Inquiry Transaction Except the message type (0100/0110), the processing is the same with that for single-message transactions. 37

44 Acquirer center Issuer centre Part I: Transaction Processing 5.3 Timeout Setting 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 Supported Transaction Types Basic Transaction Types 38

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

46 Acquirer Issuer Part I: Transaction Processing E-cash Application-based Transaction Types 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 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: CUPS 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 Section Reversal Advice for conditions to trigger reversal and its flow. 40

47 Acquirer Issuer Part I: Transaction Processing 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 CUPS 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 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 Advice Transaction Switched via CUPS. Manual refund, supplementary to Refund (online), is initiated from CDRS and participate 41

48 in settlement of that day 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 1 Acquirer Stand-in Authorization Issuer 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. 42

49 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

50 Participant Part I: Transaction Processing 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. The transaction flow is: CUPS sends cutoff transaction to each participant, who will send response to CUPS after receiving the transaction. 1 CUPS 2 1 Cutoff advice (0820) sent to Participants by CUPS 2 Response (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 Processing Flow of Message Sending amid CUPS Cutoff Period 44

51 Participant Part I: Transaction Processing C U P S CUPS sends cutoff start advice (0820) to Participants. 2 Participants send response (0830) to CUPS 3 CUPS sends cutoff end advice (0820) to Participants. 4 Participants send response (0830) to CUPS 5 CUPS sends reconciliation advice message (0520/0522) to Participants. 6 Participants send response to CUPS (0530/0532). 7 CUPS sends fund settlement advice (0620) to Participants 8 Participants send response (0630) to CUPS 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 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

52 executing other functions Time Sequence Coordination Time Sequence Point of Clearing Batch Switch Table 3 Time Sequence Point Control Relationship of Clearing Batch Switch SN Transaction Name Description of Crucial Function Steps 1 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 2 Clearing Carry out clearing according to batch identifiers of the transaction requests 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 Name 1 Settlement 2 Dispute Ditto Dual message: Description of Crucial Function Steps Clearing files sent over by Participants prior to this point are processed in the current batch Clearing files sent over by Participants after this point are processed in the following batch 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 Names Description of Crucial Function Steps 46

53 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 Control Steps of Cutoff End Time Sequence Point Its control relationship is as follows: Table 6 Control Steps of Cutoff End Time Sequence Point Transaction SN Names Description of Crucial Functional Steps 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

54 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 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 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 Credit Adjustment, Credit Adjustment Cancellation 48

55 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 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 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 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 Second Chargeback, Second Chargeback Cancellation 49

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

57 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 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: Dispute processing request initiated on network platform 2-Dispute processing request submitted to CUPS by network platform 3-CUPS replies dispute processing result to network platform 4-To inquire dispute result provided by CUPS on network platform Figure 27 eneral Flow of Dispute Processing 51

58 9Explanations on Processing of Management and Security Control Related Transactions 9.1 Network Management Advice Transaction (0820/0830) 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 Transaction Flow 52

59 Participant Participant Part I: Transaction Processing Initiated by CUPS CUPS sends network management advice to each participant, which will send response to CUPS after receiving the advice. 1 CUPS 2 1 Network management advice sent to Participants by CUPS (0820) 2 Response sent to CUPS by Participants (0830) Figure 28 Flow of Network Management Transaction Initiated by CUPS Initiated by participants Participants send network management advice to CUPS, which will send response to participants after receiving the advice. 1 CUPS 2 1 Network management advice sent to CUPS by Participants (0820) 2 Response sent to Participants by CUPS (0830) Figure 29 Flow of Network Management Transaction Initiated by participants 9.2 Key Reset (0800/0810) Transaction Description The transaction is a messages used for key renewal and key synchronization between 53

60 Participant Part I: Transaction Processing 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 Transaction Flow 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. 1 2 CUPS Key reset application sent to CUPS by Participants (0820) 2 Response sent to Participants by CUPS (0830) 3 Key reset request sent to Participants by CUPS (0800) 4 Key reset response sent to CUPS by Participants (0810) Figure 30 Flow of participant Key Reset Application 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

61 Participant Part I: Transaction Processing 1 CUPS 2 1 Key reset request sent to Participants by CUPS (0800) 2 Key reset response sent to CUPS by Participants (0810) Figure 31 Flow of CUPS Key Reset 55

62 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 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 Rule 2 When participants cannot send reversal advice correctly, they shall store and forward the advice Rule 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

63 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 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 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 Message 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 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

64 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 4 Amount of transaction is 0 13 The situations in which invalid data contents may possibly occur in reversal, cancellation and dispute processing transaction requests are as follows: Table 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 64 sp on Transaction is inconsistent with original transaction card number 14 se Transaction is inconsistent with original transaction terminal 97 Co The original transaction is not accepted 12 de Transaction response cannot match the reversal request 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 o and send reversal advice after timeout period. If such errors occur in response log message of advice transactions (except for network management advice and reconciliation for advice), the 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 k errors that occur during transactions among CUPS, acquirers and issuers. Those errors are as follows: PIN format error in request messages 58

65 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 PIN Error 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. Acquirer s processing Send reject response to the terminal. CUPS processing Send reject response to acquirer with response code = 99 Issuer s processing Send reject response to CUPS with response code = PIN Verification failure in Request Message Error type Issuer detects that PIN input by cardholder cannot be matched. Issuer s processing Send reject response to CUPS. If the times of PIN verification failure do not reach the 59

66 limitation set by issuer, with response code = 55 (incorrect PIN), otherwise with response code = 38 or 75 (times of PIN input exceed limitation) MAC Error 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 Issuer s processing Send reject response to CUPS with response code = A MAC Calculation Error in Advice Message Error type Message receiver detects that MAC cannot be matched. CUPS processing Send reject response to acquirer with response code = A0 Issuer s processing Send reject response to CUPS with response code = A MAC Error in Response Message to Request General Financial Transaction Error type Message receiver detects that MAC cannot be matched. 60

67 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. Acquirer s processing 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 MAC Error in Response Message to Advice Error type Message receiver detects that MAC cannot be matched. CUPS processing Write into the log for future check and analysis 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

68 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 Setting of Issuer s Invalid Status by CUPS 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 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) Processing at the Restoration When it is tested as restored, CUPS will re-send accumulated reversal messages and 62

69 other advice messages. When the issuer completes processing of those messages, issuer s 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 Individual 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 Sender s 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. Sender s request is lost on the way refers to the case in which the request sent by the sender is lost on the way due to 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 receiver s 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

70 Issuer Acquirer Terminal Issuer Acquirer Terminal Part I: Transaction Processing 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 receiver s 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 Acquirer Cannot Forward Request from Terminal x C U P S Malfunction Acquirer cannot forward the request 2 to CUPS due to communications failures. Acquirer s processing Reject response 3 sent to the terminal directly by acquirer. Figure 32 Acquirer Cannot Forward Request from Terminal CUPS Cannot Receive Request ? C U P S 5 Malfunction 64

71 Issuer Acquirer Terminal Part I: Transaction Processing 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. Acquirer s processing 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 CUPS Cannot Forward Request to Issuer C U P S 3 x Malfunction CUPS cannot forward acquirer s 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 Issuer Cannot Receive Request 65

72 Terminal Issuer Acquirer Terminal Acquirer Issuers Part I: Transaction Processing 1 2 3? C U 4 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. Issuer s 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 Issuer Cannot Send Request Response to CUPS 终 端 1 6 受 理 方 5 2 C U P S x 发 卡 方 8 Malfunction Issuer cannot send CUPS request response 4 due to communications failures. Issuer s processing 1 If the transaction is financial request and accepted, this reversal participates in reconciliation as internal reversal. 66

73 Issuer Acquirer Terminal Part I: Transaction Processing 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 Issuer s 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 CUPS Cannot Receive Response from Issuer C U P S? Malfunction 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 Issuer s 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

74 Issuer Acquirer Terminal Part I: Transaction 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 Issuer s 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 CUPS Receives Late Acceptance Response from Issuer C U 6 P S 7 8 Malfunction CUPS detects timeout of issuer and sends acquirer reject response 4 while completing following processing according to section 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. Issuer s processing Issuer sends CUPS reversal response 8 and this reversal participates in reconciliation. Figure 38 CUPS Receives Late Acceptance Response from Issuer 68

75 Issuer Acquirer Terminal Issuer Acquirer Terminal Part I: Transaction Processing X 9 5 C U P S Malfunction CUPS cannot forward issuer s 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 Issuer s processing Issuer sends CUPS with reversal response 8. If the transaction is financial transaction request and accepted, this reversal participates in reconciliation. Acquirer s processing 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 CUPS processing 2 CUPS sends acquirer reversal response 10 and this reversal does not participate in reconciliation CUPS Cannot Forward Request Response to Acquirer X 9 5 C U P S Malfunction 69

76 CUPS cannot forward issuer s 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 Issuer s processing Issuer sends CUPS with reversal response 8. If the transaction is financial transaction request and accepted, this reversal participates in reconciliation. Acquirer s processing 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 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

77 Issuer Acquirer Terminal Issuer Acquirer Terminal Part I: Transaction Processing CUPS Receives Early Reversal from Acquirer C U P S Malfunction CUPS receives acquirer s reversal advice 4 without receiving issuer s 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 Acquirer Cannot Receive Response from CUPS C? U P 3 5 S Malfunction Acquirer detects timeout if it does not receive response 3 from CUPS after sending request 2 to CUPS. Acquirer s processing 71

78 Issuer Acquirer Terminal Part I: Transaction Processing Acquirer sends the terminal request reject response 4 initiated by timeout. If the transaction is financial transaction request, reversal advice 5 also needs to be sent to 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. Issuer s processing Issuer sends CUPS reversal response 8,and this reversal participates in reconciliation at issuer side. Figure 41 Acquirer Cannot Receive Response from CUPS Acquirer Receives Late Acceptance Response from CUPS Malfunction C U 5 6 P 7 S Acquirer detects timeout at CUPS and sends the terminal reject response 5 while performing sequential operations according to section , and afterwards it receives late acceptance response 6 from CUPS. Acquirer s processing Acquirer re-sends reversal advice 7 to CUPS with reason code 4353 and this reversal participates in reconciliation. 72

79 Issuer Acquirer Terminal Part I: Transaction Processing 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. Issuer s processing Issuer sends CUPS reversal response 10 and this reversal participates in reconciliation. Figure 42 Acquirer Receives Late Acceptance Response from CUPS Acquirer Cannot Send Terminal Operation Instruction 1 2 C 3 5 U X P S Malfunction Acquirer cannot send the terminal operation instruction 6 due to communication failures. Acquirer s processing 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. Issuer s processing Issuer sends CUPS reversal response 10 and this reversal participates in reconciliation. 73

80 Issuer Acquirer Terminal Part I: Transaction Processing Figure 43 Acquirer Cannot Send Terminal Operation Instruction Dual 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 CUPS Cannot Send Acquirer Reject Response X 5 3 C U P S 6 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 s processing 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 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

81 Issuer Acquirer Terminal Issuer Acquirer Terminal Part I: Transaction Processing Figure 44 CUPS Cannot Send Acquirer Reject Response CUPS Cannot Send Issuer Reversal Advice 1 2 C 3 Pheno 6 5 U P S 7? 4 X Figure 44 CUPS Cannot Send Issuer Reversal Advice CUPS sends issuer reversal advice 7 after it detects communications failures (please refer to section CUPS Cannot Forward Request Response to Acquirer; and section 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 Acquirer Cannot Send CUPS Reversal Advice C U P X S 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 Acquirer Cannot Send Terminal Operation Instruction; section Acquirer Receives Late Acceptance Response from CUPS; and section Reversal Initiated by Terminal), but sending of the reversal by acquirer fails again due to communications failures. Acquirer s processing 75

82 Issuer Acquirer Terminal Issuer Acquirer Terminal Part I: Transaction Processing Acquirer saves the unsent reversal advice in store-and-forward queue and re-sends it after the connection restores 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 Without Communication Failures Reversal Initiated by Terminal C U P S Malfunction Figure 46 Reversal Initiated by Terminal 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. Acquirer s processing In reversal advice, reason code 4351 means transaction fails at terminal. Acquirer, CUPS and Issuer participant the reconciliation of this reversal transaction Communication Failures Flow of Special Acquirer Cannot Send CUPS Reversal Initiated by Terminal Operation Error X C U P S 3 4

83 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 Reversal Initiated by Terminal). Acquirer s processing 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 issuer s 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 Remittance 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

84 Issuer CUPS Acquirer Terminal Part I: Transaction Processing 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 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 Acquirer Cannot receive Remittance Verification Response 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 s processing Acquirer send time-out response 6 to terminal which means Acquirer cannot receive response from CUPS. Terminal s processing 78

85 Issuer CUPS Acquirer Terminal Issuer CUPS Acquirer Terminal Part I: Transaction Processing Transaction Failure, Chargeback customer and stop sequent Remittance Transaction. But can restart Account Verification Transaction Acquirer receives Non-Acceptance Remittance Verification Response Malfunction Acquirer receives Non-Acceptance Account Verification Response 6. CUP s processing No processing Acquirer s processing No processing Terminal s processing Transaction Failure, return the funds to customer and stop sequent Remittance Transaction. But can restart Account Verification Transaction Terminal receives Non-Acceptance Remittance Transaction Response 79

86 Issuer CUPS Acquirer Terminal Part I: Transaction Processing Figure 51 Terminal receives Non-Acceptance Remittance Transaction Response Malfunction Terminal receives 'Non-Acceptance Remittance Transaction Response 12. Terminal s processing Transaction success, accept funds Inform customer that Remittance Success. funds reaching account would be delayed. Further processing Acquirers credit Issuer s account by manual remittance transaction Terminal cannot send Remittance Request Figure 52 Terminal cannot send remittance request Malfunction Terminal cannot send Remittance Request 7. Terminal s processing Not necessary to re-send Remittance Request. Transaction success, accept funds. Inform customer that Remittance Success. funds reaching account would be delayed. Further processing Acquirers credit Issuer s account by manual remittance transaction Acquirer cannot receive Transfer Request 80

87 Issuer CUPS Acquirer Terminal Issuer CUPS Acquirer Terminal Part I: Transaction Processing Figure 53 Acquirer cannot receive transfer request Malfunction Terminal send Remittance Request 7 to Acquirer but Request lost. Terminal s processing Not necessary to re-send Remittance Request. Transaction success, accept funds. Inform customer that Remittance Success. funds reaching account would be delayed. Further processing Acquirers credit Issuer s account by manual remittance transaction Acquirer cannot forward Transfer Request from 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 s processing Acquirer sends Reject Response 9 to Terminal as soon as it detects the failure of forwarding Remittance Transaction. Terminal s processing 81

88 Issuer Issuer CUPS CUPS Acquirer Acquirer Terminal Terminal Part I: Transaction Processing Transaction success, accept funds. Inform customer that Remittance Success. funds reaching account would be delayed. Further processing Acquirers credit Issuer s account by manual remittance transaction CUPS cannot receive Remittance Request 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 s processing Acquirer sends Reject Response 9 to Terminal when Transaction time-outs. Terminal s processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. funds reaching account would be delayed. Further processing Acquirers credit Issuer s account by manual remittance transaction CUPS cannot forward Remittance Request to Issuer 82

89 Issuer CUPS Acquirer Terminal Part I: Transaction Processing 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. CUP s processing CUPS sends Reject Response 10 to Acquirer as soon as it detects the failure of forwarding Remittance Request. Acquirer s processing Acquirer forwards Reject Response 11 to Terminal. Terminal s processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing Acquirer credits Issuer s account by manual Remittance Transaction Issuer cannot receive Remittance Request Malfunction Account Verification Success. But Issuer cannot receive Remittance Request 9 from CUPS which would be lost due to communication error. CUP s processing CUPS sends Reject Response 10 to Acquirer when Issuer s response time-outs. Acquirer s processing Acquirer forwards Reject Response 11 to Terminal. Terminal s processing 83

90 Issuer CUPS Acquirer Terminal Part I: Transaction Processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing Acquirer credits Issuer s account by manual Remittance Transaction Issuer cannot send Remittance Request Response to CUPS Malfunction Account Verification Success. But Issuer cannot send Remittance Request Response 10 to CUPS due to communication error. CUP s processing CUPS sends Reject Response 11 to Acquirer when Issuer s response time-outs. Acquirer s processing Acquirer forwards Reject Response 12 to Terminal. Terminal s processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing Acquirer credits Issuer s account by manual Remittance Transaction. Figure 58 Issuer cannot send remittance request response to CUPS CUPS cannot receive Remittance Response from Issuer 84

91 Issuer CUPS Acquirer Terminal Issuer CUPS Acquirer Terminal Part I: Transaction Processing 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. CUP s processing CUPS sends Reject Response 11 to Acquirer when Issuer s response time-outs. Acquirer s processing Acquirer forwards Reject Response 12 to Terminal. Terminal s processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing Acquirer credits Issuer s account by manual Remittance Transaction CUPS receive Late Remittance Response from Issuer Figure 60 CUPS receive late remittance response from issuer Malfunction 85

92 Issuer CUPS Acquirer Terminal Part I: Transaction Processing 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. CUP s processing CUPS sends Reject Response 10 to Acquirer when Issuer s response time-outs and then receive Late Transfer Response from Issuer. CUPS doesn t process Response 12 and throws it out. Acquirer s processing Acquirer forwards Reject Response 11 to Terminal. Terminal s processing Transaction success, accept fund. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing Acquirer credits Issuer s account by manual Remittance Transaction CUPS cannot forward Remittance Request Response to Acquirer Figure 61 CUPS cannot forward remittance request response to acquirer Acquirer 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. Acquirer s processing 86

93 Issuer CUPS Acquirer Terminal Part I: Transaction Processing Acquirer sends Reject Response 12 to Terminal when response time-outs. Terminal s processing Transaction success, accept fund. Inform customer that Remittance Transaction 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 don t need further processing. If Response 11 is Non-Acceptance Response, Acquirer should credit Issuer s account by manual Remittance Transaction. 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 s processing Acquirer sends Reject Response 12 to Terminal when response time-outs. Terminal s processing Transaction success, accept fund. Inform customer that Remittance Transaction 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 don t need further processing. If Response 11 is Non-Acceptance Response, Acquirer should credit Issuer s account by manual Remittance Transaction Acquirer receive Late Remittance Request Response from CUPS 87

94 Issuer CUPS Acquirer Terminal Issuer CUPS Acquirer Terminal Part I: Transaction Processing 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. Acquirer s processing No processing. Throw Response 12 out. Terminal s processing Transaction success, accept funds. Inform customer that Remittance Transaction Success. Funds reaching account would be delayed. Further processing If Response 12 is Acceptance Response, CUPS will settle this Transaction. There would be no dispute and don t need further processing. If Response 12 is Non-Acceptance Response, Acquirer should credit Issuer s account by manual Remittance Transaction Acquirer cannot send Remittance Response to Terminal Figure 64 Acquirer cannot send remittance response to terminal 88

95 Malfunction Account Verification Success. But Acquirer cannot send Response 12 to Terminal due to communication error. Terminal s processing 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 don t need further processing. If Response 12 is Non-Acceptance Response, Acquirer should credit Issuer s account by manual Remittance Transaction Designated 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 doesn t work. Please refer to Section 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 Individual Failure for processing flow and principles. 89