-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
1/30
Implementation Guide for Technical
Enhancements
April 2011
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
2/30
THIS PAGE INTENTIONALLY LEFT BLANK.
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
3/30
Table of ontents
Using this Document ......................................................................................................................... 1
Purpose....................................................................................................................................... 1
Audience & Application Scope .................................................................................................. 1
Time Expressed .......................................................................................................................... 1
Support ....................................................................................................................................... 1
1 New Programs and Functions ...................................................................................................... 3
1.1
MO/TO .............................................................................................................................. 3
1.1.1
Description ............................................................................................................. 3
1.1.2
Compliance ............................................................................................................ 3
1.1.3 Transaction types and processes ............................................................................ 3
1.1.4 The use of key fields .............................................................................................. 4
1.1.5
Clearing and settlement process ............................................................................. 7
1.1.6
Key issues in the transition period ......................................................................... 7
1.2
RECURRING ................................................................................................................... 7
1.2.1 Transaction description .......................................................................................... 7
1.2.2 Compliance .......................................................................................................... 7
1.2.3
Transaction types and processes ............................................................................ 8
1.2.4
Usage of key fields ................................................................................................. 8
1.2.5
Clearing and settlement process ............................................................................. 9
1 2 6 Key issues in transition period 9
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
4/30
2. 7 Introduction to the processing of presentment files by CUPS ............................... 15
3
Enhancements for Fields ............................................................................................................ 20
3.1
Instruction for filling F22, F60.2.2 and F60.2.3 .............................................................. 20
3.1.1
Enhancement Description .................................................................................... 20
3.1.3 Issues to be noticed by the acquirers .................................................................... 21
3.1.4 Issues to be noticed by the issuers........................................................................ 21
3.2 Processing of F61 ............................................................................................................ 21
3.2.1
Enhancement Description .................................................................................... 21
3.2.2
Processing instruction .......................................................................................... 22
3.2.3
Compliance .......................................................................................................... 23
3.2.4 Supporting transaction types and processes ......................................................... 23
3.2.5
Instruction for settlement process ........................................................................ 23
3.2.6
Issues to be noticed by the acquirers .................................................................... 23
3.2.7
Issues to be noticed by the issuers........................................................................ 23
3.3 Instructions for filling out F42 ........................................................................................ 23
3.3.1
Background .......................................................................................................... 23
3.3.2
Compliance .......................................................................................................... 24
3.4
Instructions for using F54 ............................................................................................... 24
3.4.1
Enhancement Description .................................................................................... 24
3.4.2
Compliance .......................................................................................................... 24
3.4.3 Issues to be noticed by the issuers........................................................................ 24
4
Summary of Enhancements ....................................................................................................... 24
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
5/30
Using this Document
Purpose
This Guide is formulated as complementary manual of Technical Specifications V2.0
(April 2011) to help participants better understanding the revisions and amendment
made in the new edition so as to facilitate the system upgrade and transformation.
Audience & Application Scope
The audiences of this Guide are the stuff from UnionPay and UnionPay participants.
The Guide applies to all 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.
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
6/30
THIS PAGE INTENTIONALLY LEFT BLANK.
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
7/30
1 New Programs and Functions
1.1 MO/TO
1.1.1 Description
MO/TO is a non-magnetic-based and non-password-based transaction initiated
through telephone or fax, etc., supporting transaction types such as MO/TO purchase,
MO/TO pre-authorization and MO/TO authorization. Only credit cards are authorized
to initiate cross-border MO/TO transactions. Under the condition of dual message
being converted to single message, MO/TO authorization will not distinguish whether
it‟s an estimated or a fixed amount, and all of authorization transactions will be
converted to MO/TO pre-authorization transactions. Message format of MO/TO
transaction differs from common transactions only in the value of field 25.
1.1.2 Compliance
1.1.2.2 For Acquirers
It is optional for acquirers. Acquirers having the demand to expand MO/TO
merchants and transactions may choose to update system to support MO/TO
t ti
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
8/30
3. Purchase type: MO/TO purchase, MO/TO purchase reversal, MO/TO purchase
cancellation, MO/TO purchase cancellation reversal,
4. MO/TO refund: refund (online), manual refund.
1.1.3.2 Transaction process
Process of normal transactions, exceptional transactions and error transactions is the
same as traditional authorization, pre-authorization, and purchase type.
1.1.4 The use of key fields
1.1.4.1 Field 25
For MO/TO, value 08 in field 25 is used to identify MO/TO authorization, MO/TO
purchase from traditional authorization and purchase transactions, value 18 is used toidentify MO/TO pre-authorization from traditional pre-authorization transactions. The
acquirer should fill in the request message in accordance with the definition of the
field.
1.1.4.2 Field 60.2.5
V l 19 i dd d i Fi ld 60 2 5 t i di t MO/TO t ti i iti t d b f
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
9/30
Transaction Name Message type Transaction
Processing
Code F3
Point of
Service
Conditi
on code
(F25)
Terminal
TypeF60.
2.5
MO/TO Authorization
reversal
0420/0430 00x000
08
UnionPay
(manual
transactio
n)
MO/TO Authorization
cancellation reversal
0420/0430 20x000
MO/TO
Pre-authorization
0100/0110 03x000
MO/TO
Pre-authorization
cancellation
0100/0110 20x000
MO/TO
Pre-authorization
completion (request)
0200/0210 00x000
MO/TO
Pre-authorization
completion cancellation
0200/0210 20x000
MO/TO
Pre-authorization
0220/0230 00x000
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
10/30
Transaction Name Message type Transaction
Processing
Code F3
Point of
Service
Conditi
on code
(F25)
Terminal
TypeF60.
2.5
completion
Manual MO/TO
pre-authorizationcancellation reversal
0420/0430 20x000
1.1.4.4 Definition of message format
Transaction Name Section Number in Part II: On-line Message
MO/TO purchase 7.5.1.1.10MO/TO purchase cancellation 7.5.1.1.12
MO/TO Purchase reversal 7.5.1.1.13
MO/TO Purchase cancellation reversal
MO/TO Authorization 7.5.1.2.1
MO/TO Authorization cancellation 7.5.1.2.1
MO/TO Authorization reversal 7.5.1.2.1
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
11/30
cancellation reversal
1.1.5 Clearing and settlement process
The clearing and settlement process of MO/TO authorization, MO/TO
pre-authorization and MO/TO purchase is the same as the process of the common
authorization, pre-authorization and purchase settlement process.
1.1.6 Key issues in the transition period
There is no transition period for new transactions. As a new transaction type, MO/TO
could only be successful when both the acquirer and the issuer support the
transaction.
1.2 RECURRING
1.2.1 Transaction description
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
b h lf f th dh ld ith th hi /h dit d d b it th t ti
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
12/30
1.2.3 Transaction types and processes
1.2.3.1 Transaction Type
Recurring supports the following transaction types:
1. Authorization type: recurring authorization, recurring authorization cancellation,
recurring authorization cancellation, recurring authorization cancellation reversal
2. Purchase type: recurring, recurring reversal, recurring cancellation, recurringcancellation reversal
1.2.3.2 Transaction process
Its ordinary transaction, exceptional transaction and dispute transaction are the same
with common authorization and purchase transactions.
1.2.4 Usage of key fields
1.2.4.1 Field 25
In recurring business, value 28 in field 25 is used to distinguish other authorization
type transactions and traditional purchase transactions. The acquirer should fill out
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
13/30
1.2.4.3 Definition of Message Format
Transaction Types Section in Part II Online Message
Recurring 7.5.1.1.11
Recurring cancellation 7.5.1.1.12
Recurring reversal 7.5.1.1.12
Recurring cancellation reversal
Recurring authorization 7.5.1.2.1
Recurring authorization cancellation 7.5.1.2.2Recurring authorization reversal 7.5.1.2.3
Recurring authorization cancellation
reversal
1.2.5 Clearing and settlement process
The clearing and settlement of recurring authorization and recurring transaction in
single message is the same as that of authorization and purchase transaction
respectively.
1.2.6 Key issues in transition period
Th i t iti i d f t ti A t ti t
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
14/30
1.3.2 Compliance
1.3.2.1 For Acquirers
It is optional for acquirers.
1.3.2.2 For Issuers
It is optional for issuers.
1.3.3
Transaction types and processes
1.3.3.1 Transaction Type
Refund (online) transaction is a new transaction for IC card based on CUPIC debit
and credit application.
1.3.3.2 Transaction process
The process of refund (online) transaction of E-cash is the same as the current process
of refund (online) of IC card based on CUPIC credit and debit application and offline
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
15/30
1.3.7 Key issues in transition period
There is no transition period for new transactions. As a new transaction type,
recurring could only be successful when both the acquirer and the issuer support the
transaction.
1.4 Cross-border remittance
1.4.1 Description
Currently two kinds of remittance are supported:
- Remittance in non-RMB currency from outside China Mainland to accounts in
mainland China, being settled in RMB
- Remittance in one non-RMB currency from one country outside of China Mainland
to the other non-RMB accounts in the other country outside of China Mainland,
settled in non-RMB.
Prior to the cross-border remittance transaction, remittance verification must be
initiated. In addition, with the change of requirements for remittance verification,
remittance verification message is changed accordingly, based on the following
reasons:
1. In remittance verification, the acquirer should forward the identity information
(name, ID number) of the remitter and purpose of the remittance, which will not be
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
16/30
1.4.3 Transaction types and processes
1.4.3.1 Transaction Type
Remittance verification;
Remittance.
1.4.3.2
Transaction process
It is the same as the previous remittance transaction.
1.4.4 Explanation on online message
1.4.4.1 Value of key fields
The value of key field of the message is the same as that of the previous remittance
verification transaction and remittance transaction:
1.As the purpose of remittance needs to be forwarded in the remittance verification,
RE usage, a fixed-length of 3 digits being used to indicate the remittance purpose, is
added in field 48
2.Transfer-out party‟s name and ID number will be forwarded through field 61,
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
17/30
2 Enhancements on Settlement Files
2.1. (FCP) Format of fee collection and payment file
2.1.1 Enhancement Description
In order to successfully settle the funds in disputed transactions between institutions,
fee collection and payment transaction have been added. There‟s no online message
for this transaction. Settlement procedures will be completed by entering manually
into CDRS., the settlement result will be reflected in the new file record of fee
collection and payment (FCP).
Fee collection transaction can only be initiated by UnionPay, while fee payment
transactions may be initiated either by both UnionPay and participants.
File of fee collection and payment (IFDYYMMDD?? FCP) is added. For specificdefinition, please refer to Technical Specifications: Part III: File Interface
4.1.1.3 .
2.1.2 Compliance
It is mandatory for all acquirers and issuers.
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
18/30
2. 3 Format of General Audit Trailer File
2. 3.1 Enhancement Description
1. Since the country information of the merchant, i.e., value of field 19, should be
reflected in relevant files of cross-border transactions, a field of merchant country
code should be added in the reserved field of general audit trailer file(COM/COMB).
2. Filling blank instead of „ N‟ in the digit for stand-in authorization indicator in thegeneral audit trailer file stands for non stand-in authorization transactions.
2. 3.2 Compliance
The first enhancement is mandatory for all acquirers.
The second enhancement is mandatory for all acquirers.
2. 4 Dispute Audit Trailer File
2.4.1 Enhancement Description
In the dispute audit trailer file, it also needs to reflect the country information of the
merchant, i.e., value of field 19. So, a field of merchant country code is added in the
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
19/30
institutions by CUPS where the institutions should receive instead of forwarding the
message, which include settlement value, settlement currency, settlement exchange
rate, debit amount of the cardholder, currency of the cardholder‟s account, exchange
rate of charging the cardholder, service fee, currency of service fee, exchange rate of
service fee;
5. Supplementary description is given to the filling of some fields in section 0; for
settlement transactions, filling in the following fields of transaction transmission time
and system tracking number is changed to filling in the value of the corresponding
field of the original authorization transactions. For refund transactions, the field will
be re-generated by the acquirer; for different circumstances, further detailed
descriptions are given to the requirement for filling in the authorization response
identification code of the field, the authorization date, the original transaction
information, the single and dual message ID (including IC card offline purchase, IC
card offline refund, and general refund).
2. 5.2
Compliance
It is mandatory for all the dual message institutions. However, because a meaningful
field is added in the reserved field, the structure of the whole file is not changed. And
the institutions having not implemented the transformation won't be affected.
2. 6 File rejection code
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
20/30
rejection file are all in line with Technical Specification V2.0, while the reconciliation
report is in the format of report file. Below is the introduction to the processing of
presentment files by CUPS.
2. 7.1 Explanation on key fields in presentment files
There are four key fields in Block 0 of the presentment file: institution identification
number, system trace number, transaction time and authorization date and these four
key fields shall be unique in the same presentment file.
From the current situation, major transactions are TC100 (presentment) and TC101
(refund).
For TC100 transaction, the key fields are institution identification number, system
trace number and transaction time. The combination of these three fields shall beunique to locate the original online authorization transaction. These three fields must
be identical to those in the original online authorization transaction.
For TC101 file, the institution identification number shall be the same as that of the
original transaction. But the system trace number and the transaction time of TC101
transactions shall be those of the refund transactions instead of those of TC100
i id d li f h bi i f h b i d h k
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
21/30
2.7.2 The processing of presentment files by CUPS
For the presentment files forwarded by acquirers, except the header and the end of the
file, each line represents one transaction, which contains at least segment 0 and
segment 1, while in IC card related transactions also contains segment 2. When
processing the presentment files, CUPS will read transaction records one by one from
beginning to the end. Each read transaction record will be processed according to the
following steps until the end of the file:
Read a transaction from the presentment file
Search for the original transaction through key fields
Validity Verification
Insert into the dual message log
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
22/30
2. 7.4 Description of rejection code
In the previous version of specification, the rejection code for presentment transaction
is specified as that of the online transaction. In accordance with the specification, the
rejection code of rejection file IFCYYMMDD51R is the on-line rejection code. But
because the procession of exceptional online transaction is different from that of the
presentment transaction, the rejection code of the online transaction is unable to
describe the exceptional circumstances occurred in processing presentment transactions.
Therefore, the new version of specification has defined a new file rejection code and
the equivalent online rejection code.
2. 7.5 Validity Verification
The system will verify the legitimacy of each transaction to determine whether to
accept the transaction or not. Legitimacy verification mainly includes:Format verification:
Currently it will only check the file header, the file tail and each field length. If the
file is found invalid, it will reject the whole file, and will not process any transaction
in the file.
The number of transactions recorded at the end of the file should be the same as the
actual number of transactions. Otherwise, it will reject the whole file, and will not
i i d i h fil
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
23/30
If the card media of the presentment transaction is not the same as the original
transaction, then the transaction will be rejected;
If the original transaction is a fixed amount authorization, but the amount of the
presentment transaction does not equal with the original transaction, then the
transaction will be rejected;
If the original transaction is a non-fixed amount authorization, but the amount of the
presentment transaction is greater than the maximum limit of a presentment, then the
transaction will be rejected;
If the original transaction is a non-fixed amount authorization, but the authorization
code of the presentment transaction is not the same as the original transaction, then
the transaction will be rejected.
Transaction type restrictions:
The current system supports TC100, TC101 and TC102 transactions, and other
transactions will be rejected.
Credit adjustment without presentment is related with a chargeback without
presentment:If credit allocation or chargeback without presentment has been done to the original
authorization transaction, then the presentment transaction will be rejected.
Duplicate transactions:
If a presentment was done for the transaction earlier, and no repeated presentment is
allowed, then the transaction will be rejected;
If refund (TC101) is done for transactions without presentment, then the refund
i ill b j d
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
24/30
3 Enhancements for Fields
3.1 Instruction for filling F22, F60.2.2 and F60.2.3
3.1.1 Enhancement Description
F22: Currently the first two digits of field 22 indicate the method for reading cards,
however, the classification criteria is different, e.g., some are classified as per reading
by magnetic stripe card or IC card, and others are classified as per reading by contact
or contactless method. The different classification criteria will result in chaos in
filling out the value of this field by the acquirers, so in the latest amendment the
classification criteria are unified. The basic idea is to have a clear description without
modifying the value. For details, please refer to Part II: On-line Message. PF60.2.2:
Values of these sub-fields are also classified by different criteria. The value of 2 and 5
describe the readable card media, but not indicating whether it has a contactless
interface or not; while the value of 6 defines that it has a contactless interface, without
defining the readable card media. As a result, it should be classified by unified criteria
with a unified description just as F22, the basic idea of which is to have a clear
description as well without modifying the value. For details, please refer to Part II:
On-line Message. From the description of the amended value, there‟s a relationship of
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
25/30
CUPS will determine the transaction media, based on the combined value of the first
two digits of service point in input code (F22), terminal reading capability (F60.2.2),
and IC card condition code (F60.2.3) of the message, and will store the result in
F60.3.6 to help the issuers to identify the transaction media. For details, please refer
to Part II: On-line Message 5.2.2 Transformation Type( optional/mandatory)
3.1.2 Compliance
It is optional for acquirers; if the acquirer wishes to carry out IC card business, it
should be able to correctly forward the combined value of these three fields based on
the transaction scenarios.
It is optional for issuers; if the issuer wishes to carry out IC card business, it should be
able to identify relevant values of these three fields, and correctly identify the
transaction media.
3.1.3
Issues to be noticed by the acquirers
If the transaction media is FallBack card, the accepting terminal should be able to
correctly forward field 60.2.3, as the existence of large amount of the value 1 or 2 in
this field represents different degree of suspected merchant fraud.
3.1.4 Issues to be noticed by the issuers
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
26/30
3.2.1.2 Name verification requirement
F61 is used to store ID verification information of various types of cardholders, such
as the defined ID card information. With the development of various business types,
single identity verification cannot meet the requirements. As bankcard frauds and
similar cases are changing and increasing, the increasingly complicated market
environment has resulted in the need of verifying the cardholder‟s name. In
particularly, in non-card transactions of trans-territory remittances and deposits,
verification of the non card transaction, i.e., verification of the cardholder‟s name,
who is either a recipient or a transfer-out party, has become more important and
urgent. The premise of name verification is that the name should be forwarded to the
issuer by means of the on-line message. To do this, this field has been selected to
store the names to be verified. And NM usage is added in the sub-field F61.6. For
specific definition, please refer to
3.2.2 Processing instruction
3.2.2.1 Processing of verification mode
The current specification defines 8 types of contents that need special attention of the
issuers in verification, including: password authentication, card validity verification,
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
27/30
3.2.2.2 Method of filling in names
For the forwarded names, as there may need to fill out two names (e.g. in the transfer
transaction, there are a transferor cardholder and a transferee cardholder), NM usage
has defined two name fields, Name field 1 and Name field 2 respectively. To facilitate
a unified processing, for transactions only having one name, all the names will appear
in name field 1, such as deposit transactions and cash withdrawal transactions.
Although the cash flow is in the opposite direction, only one account name will need
to be verified, so all of them will use name field 1. When the transaction needs to
verify two names, the cardholder name which is of higher security requirements will
be stored in name field 1, the other cardholder name will be stored in name field 2.
3.2.3 Compliance
It is optional for both acquirers and issuers.
3.2.4 Supporting transaction types and processes
Prior to the remittance business, a remittance verification transaction must be
forwarded, which must be successful before the remittance business can be
implemented. As a result, the remittance verification transaction only needs to send
F61, and there is no need to forward the remittance transaction once again. As such, in
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
28/30
fill out this field. At present, this field is freely filled out by the institutions. In order
to regulate the filling of the message field, if the acquirer has no special requirements
in the field, then all of them will be filled out with the default value 0.
3.3.2 Compliance
It is mandatory for acquirers and The issuer should be able to correctly identify all 0
values.
3.4 Instructions for using F54
3.4.1 Enhancement Description
With the increasing account types nowadays, the way of describing account balance is
different among different account types. For example, debit card calls it available
balance; while the credit card has both consumption limit and cash advance limit. In
addition, different types of transactions with different terminal types also have
different amount limits. Therefore, in the current specification, the simple definition
of carrying balance and available balance is less applicable. Based on the above
reasons, the specification has re-combed and described the carrying balance and the
available balance of the current day from the perspectives of different account types
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
29/30
1
The following table summarizes all the enhancements and the effective date of each enhancement.
S.N Type Ehancement Compliance for
acquirer
Compliance
for issuer
Effective
Date
Where
to look
Availabe
Online Test
Time
Remarks
1. New Programs
and Functions
MO/TO Optional Optional 15 Apr, 2011 1.1 31 Dec, 2010 The effective date of
optional programs are
only for those participant
that choose to implement
the programms.
2. Recurring Optional Optional 15 Apr, 2011 1.2 31 Dec, 2010
3. online refund and offline
refund for E-cash
Optional Optional 21 Oct, 2011 1.3 30 Apr, 2011
4. Cross-border remittance Optional Optional 15 Apr,2011 1.4 31 Dec, 2010
5. Enhancements
on settlement
files
Add record format for fee
collection and payment
(FCP) files
Mandatory Mandatory 2.1 30 Jun, 2011 Only apply to acquirers
6. TC 804:Processing of
merchant group files of
stand-in authorization
institutions
--- Optional 21 Oct, 2011 2.2 15 Apr, 2011
7. General Audit Trailer File
(F19)
Mandatory Mandatory 21 Oct, 2011 2.3 15 Apr, 2011
8. Dispute Audit Trailer File
(F19)
Mandatory Mandatory 21 Oct, 2011 2.4 15 Apr, 2011
9. Settlement file for dual
message
Mandatory Mandatory 21 Oct, 2011 2.5 15 Apr, 2011
10. Add File rejection code Mandatory Mandatory 21 Oct, 2011 2.6 15 Apr, 2011
11. Enhancements Optimization of field 22, Mandatory Mandatory 21 Oct 2011 3.1 15 Apr, 2011
-
8/19/2019 Implementation Guide for Technical Enhancement_April 2011
30/30
2
S.N Type Ehancement Compliance for
acquirer
Compliance
for issuer
Effective
Date
Where
to look
Availabe
Online Test
Time
Remarks
for fields field 60.2.2 and field 60.2.3
12. Optimization of field 61 Optional Optional 21 Oct,2011 3.2 15 Apr, 2011
13. Processing of field 42 Mandatory __ 21 Oct,2011 3.3 15 Apr, 2011
14. Processing of field 54 Mandatory Mandatory 21 Oct,2011 3.4 15Apr, 2011