UnionPay Card E-Commerce Implementation Guide for Issuer

UnionPay Card E-Commerce

Implementation Guide for Issuer

(Jan 2018)
 UnionPay Card E-Commerce Implementation Guide for Issuer

THIS PAGE INTENTIONALLY LEFT BLANK.

 UnionPay Card E-Commerce Implementation Guide for Issuer

Table of Contents
1 Document Description...................................................................................................................... 1
1.1 Purpose .................................................................................................................................. 1
1.2 Terms and Acronym Definitions ......................................................................................... 1
2 Descriptions of Transaction Authentication Element Combinations ........................................... 2
2.1 Description of Transaction authentication Element Combinations .................................. 2
2.1.1 Authentication Mode................................................................................................. 2
2.1.2 Non-Authentication Mode ........................................................................................ 3
2.2 Mode of Dynamic verification data ..................................................................................... 3
3 Service Flow ...................................................................................................................................... 5
3.1 Transaction Flow ....................................................................................................................... 5
3.1.1 Authentication Mode................................................................................................. 5
3.1.2 Non-Authentication Mode ........................................................................................ 8
3.2 System interactive flows ....................................................................................................... 9
3.2.1 Authentication Mode................................................................................................. 9
3.2.2 Non-Authentication Mode .................................................................................... 11
4 Online Transaction Processing Request ..................................................................................... 13
4.1 Description of Transaction Types .................................................................................... 13
4.1.1 Account Verification Transaction ........................................................................ 13
4.1.2 Balance Inquiry Transaction ................................................................................ 13
4.2 Key points for E-Commerce Transaction Message ........................................................ 13
4.2.1 Online Message Description ................................................................................. 13
4.2.2 Transaction Element Values ................................................................................. 16
4.2.3 Requirements to transfer Authentication Elements ............................................ 18
4.3 Account verification ......................................................................................................... 19
4.3.1 Type Description ................................................................................................... 19
4.3.2 Key Points .............................................................................................................. 19
4.4 Balance Inquiry ................................................................................................................ 20
4.5 Verifying dynamic verification data ................................................................................ 21
4.5.1 Verifying mobile phone number ........................................................................... 21
4.5.2 Verifying dynamic verification code .................................................................... 21
5 Settlement ..................................................................................................................................... 23
5.1 Document List ................................................................................................................... 23
5.2 Explanations on Settlement File Access Mode ................................................................ 23
5.2.1 SFTP Mode ............................................................................................................ 23
5.2.2 Flow transmission Mode ....................................................................................... 23
5.2.3 PGP+Email Transmission ..................................................................................... 24
5.3 Settlement Characteristics of E-Commerce Transactions ............................................. 24

i
 UnionPay Card E-Commerce Implementation Guide for Issuer

6 Participating Procedures ............................................................................................................. 25

6.1 Application Procedures for E-Commerce Service. ......................................................... 25
6.2 Checklist for E-Commerce Service ................................................................................. 26
6.3 Testing Procedures ........................................................................................................... 26
6.3.1 Key information ..................................................................................................... 26
6.3.2 Procedures for testing ........................................................................................... 27
7 Annex ............................................................................................................................................ 28
Annex 1 IFDYYMMDD01ICOM: General single message transaction settlement detail of
organizations as issuers ........................................................................................................... 28
Annex 2 IFDYYMMDD01IERR: Dispute Trailer ................................................................ 31
Annex 3 IFCYYMMDD99C: General Dual-message settlement detail of organizations as
issuers ....................................................................................................................................... 33
Annex 4 IFCYYMMDD99S: Transaction statistics file of organizations as issuers
....................................................................................................................................................34
Annex 5 IFRYYMMDD01C603DZ-<Transaction Currency>-<Settlement Currency>: UPI
Institution Net Settlement Summary ..................................................................................... 35
Annex 6 IFRYYMMDD01C605DZ: Institution Dispute Resolution Detail ........................ 37
Annex 7 FD<YYMMDD>01IFEEDTL: UPI Institution Fee Settlement File ..................... 38
Annex 8 IFR<YYMMDD>01C602DZ-<”Transaction Currency”>-<”Settlement
Currency”>: UPI Institution Settlement (UIS) Report ........................................................ 40

ii
 UnionPay Card E-Commerce Implementation Guide for Issuer

1 Document Description

1.1 Purpose
With the background of the "UPI Operating Regulations", this document provides guidance to
UnionPay card Issuers looking to implement the UnionPay E-Commerce service. Specifically, the
document provides:
Assistance to card Issuers in understanding the UnionPay E-Commerce system,
Understanding of the technical integration required between the UnionPay E-Commerce
(GSCS) system and the Issuer’s systems, and
The framework for achieving the best outcome from each participating vendor.
An introduction to the establishment of UnionPay E-Commerce service rules.
1.2 Terms and Acronym Definitions
This section defines the business terms that appear in this document.

Acronym/Term Explanation

UPOP UnionPay Online Payment system

GSCS UnionPay Global Service Connection System

E-Commerce service refers to the cardholder accessing the

E-Commerce service internet through a transaction terminal, initiating, and
completing a payment transaction.

Authentication Mode refers to the transaction processing

Authentication Mode mode of the card Issuer responsible for verifying the card-
holder's identity and the card information.

Non-authentication Mode refers to the transaction pro-

Non-Authentication
cessing mode of the card Issuer responsible for verifying
Mode
the card information.

SMS Short Messaging Service

Refers to the dataset (characters and symbols) sent to the

Dynamic Verification cardholder’s mobile phone during the E-Commerce service
Code used to verify transactions and the identity of the transac-
tion initiator.

1
 UnionPay Card E-Commerce Implementation Guide for Issuer

2 Descriptions of Transaction Authentication Element Combinations

2.1 Description of Transaction authentication Element Combinations

2.1.1 Authentication Mode
1. PIN-Based Debit / PIN-Based Prepaid Cards
In Authentication Mode, there are two combinations of required authentication elements.
Combination One: Issuer verifies card number and dynamic verification data
Mandatory elements (issuers need to verify): card number, dynamic verification data;
Other elements: expiration date, CVN2
Note:
• If acquirer doesn’t submit correctly or completely the mandatory elements, issuer
should refuse the transaction.
• If acquirer only send mandatory elements and issuers should verify accordingly
and issuers should not refuse the transaction due to lack of other elements.
• If issuers choose other elements means issuers are capable to verify and it depends
on acquirers whether send or not.
1. If acquirer send other elements as expiration date and CVN2, then issuer should
verify both;
2. If acquirer send other elements as expiration date, then issuer should verify the
expiration date and should not refuse the transaction due to the lack of CVN2;
3. If acquirer send other elements as CVN2, then issuer should verify the CVN2 and
should not refuse the transaction due to the lack of expiration date;
4. If acquirer only send mandatory elements and issuers should verify accordingly
and issuers should not refuse the transaction due to lack of other elements.

② Combination Two: Issuer verifies card number and PIN

Mandatory elements (issuers need to verify): card number, PIN;
Optional elements: expiration date, CVN2;
Note:
• If Issuers require the card number and PIN for transaction verification, then
regulatory authorities in that jurisdiction must also allow the UPOP to collect the
customer PIN that is used for cash withdrawals.
• If the regulatory authority does not allow this activity then the Issuer can either
establish a special E-Commerce PIN that is different to the cash withdrawal PIN;
• If acquirer doesn’t submit correctly or completely the mandatory elements, issuer
should refuse the transaction.
• If acquirer only send mandatory elements and issuers should verify accordingly
and issuers should not refuse the transaction due to lack of other elements.
 If issuers choose other elements means issuers are capable to verify and it depends

2
 UnionPay Card E-Commerce Implementation Guide for Issuer
on acquirers who send or not;
1. If acquirer send other elements as expiration date and CVN2, then issuer should
verify both;
2. If acquirer send other elements as expiration date, then issuer should verify the
expiration date and should not refuse the transaction due to the lack of CVN2;
3. If acquirer send other elements as CVN2, then issuer should verify the CVN2 and
should not refuse the transaction due to the lack of expiration date;

2. Credit Cards
For credit card transactions in Authentication Mode, Issuers may choose one of the
following combinations of authentication elements to verify a transaction.
Combination: Verification of the card number, CVN2, expiration date, and dynamic
verification data;

Note: In Authentication Mode, the card issuer can choose UnionPay Send SMS mode on
behalf of the Issuer or Issuer Send SMS mode. UnionPay International needs to be advised of
the preferred solution by the Issuer in their E-Commerce application:

3
 UnionPay Card E-Commerce Implementation Guide for Issuer

If UnionPay is requested to send dynamic verification data on behalf of the Issuer, and
the verification process is via SMS, then the Issuer must verify the mobile number sent by
UnionPay International against the mobile number on record for the card holder.
If the Issuer selects to send dynamic verification data directly, then the card Issuer must
verify the authenticity of dynamic verification data and verify whether the dynamic verification
data the cardholder input is accurate.
Issuers should follow the same rules of Authentication Modes throughout all BINs owned.

2.1.2 Non-Authentication Mode

The required transaction elements are specified in the following table for credit and debit
cards. The Issuer should verify the required elements, and may verify the optional elements.
1. Debit / Prepaid Card
Mandatory elements: Card number
Other elements: Expiration date, CVN2, cardholder name

Note:
 If acquirer doesn’t submit correctly or completely the mandatory elements, issuer
should refuse the transaction.
• If acquirer only send mandatory elements and issuers should verify accordingly
and issuers should not refuse the transaction due to lack of other elements.

If issuers choose other elements means issuers are capable to verify and it depends on
acquirers who send or not;
1. If acquirer send other elements as expiration date and CVN2, then issuer should
verify both;
2. If acquirer send other elements as expiration date, then issuer should verify the
expiration date and should not refuse the transaction due to the lack of CVN2;
3. If acquirer send other elements as CVN2, then issuer should verify the CVN2 and
should not refuse the transaction due to the lack of expiration date;
Cardholder name follow the above mentioned expiration date and CVN2 rules.

2. Credit Card
Mandatory elements: Card number, Expiration date
Other elements: CVN2, cardholder name

Note:
 If acquirer doesn’t submit correctly or completely the mandatory elements, issuer
should refuse the transaction.
• If acquirer only send mandatory elements and issuers should verify accordingly
and issuers should not refuse the transaction due to lack of other elements.
• If issuers choose other elements means issuers are capable to verify and it depends

4
 UnionPay Card E-Commerce Implementation Guide for Issuer
on acquirers who send or not;
1. If acquirer send other elements as CVN2 and cardholder name, then issuer should
verify both;
2. If acquirer send other elements as CVN2, then issuer should verify the CVN2 and
should not refuse the transaction due to the lack of cardholder name;
3. If acquirer send other elements as cardholder name, then issuer should verify the
cardholder name and should not refuse the transaction due to the lack of CVN2;

a) Mode of Dynamic verification data

For Authentication Mode, two methods are provided for the transmission of dynamic
verification data;
1. UnionPay Send SMS Mode: The Issuer authorizes UnionPay to send dynamic
verification data on its behalf. In this mode the dynamic verification data means the mobile
phone number. Using this service the Issuer needs to support verification of the mobile
phone number to match the card number when receive Balance Inquiry, Purchase, Pre-
Authorization, and Authorization transactions which using F61.6 to store the mobile phone
number.
2. Issuer Send SMS Mode: The Issuer sends dynamic verification data itself. In this
mode the dynamic verification data means the dynamic verification code (SMS OTP). In this
case the Issuer must do two steps system upgrade:
Step 1: Upgrade from 2.0 messaging version to 2.1 version which may related to all
transaction types such as POS/ATM. The issuer should evaluate the influence carefully.
Step 2: Support E-Commerce transactions including the transmission and verification of
dynamic verification data described in Chapter 3 and Chapter 4.
When an Issuer chooses to send the dynamic verification code, it will ensure that the va-
lidity of the dynamic verification code is correctly linked with corresponding transaction and
set the session time out period. During the course of transaction authentication, the Issuer
shall verify the dynamic verification code and its session time limit. For the detail require-
ment, please see Section 4 – ‘Online Transaction Processing Request’, with the relevant sec-
tion 4.5 "Verifying Dynamic verification data".

Note: In Authentication Mode, whether dynamic verification data is sent by the card Is-
suer or by UnionPay on behalf of the Issuer, the process needs to be fully tested during the
Issuer E-Commerce online integration testing.

5
 UnionPay Card E-Commerce Implementation Guide for Issuer

2 Service Flow

a) Transaction Flow
i. Authentication Mode
3.1.1.1 UnionPay Send SMS Mode on behalf of Issuer

6
 UnionPay Card E-Commerce Implementation Guide for Issuer

1: An order is successfully submitted and a UnionPay card is selected for payment.

2: The card holder enters the UnionPay card number on the UPOP payment interface.
3: The UPOP dynamically displays the authentication elements based on the Issuer’s authen-
tication requirements profile (for details on authentication element combinations please see
the description in 4.2 regarding authentication elements). In Authentication Mode, the Issuer
can choose to whether send the dynamic verification code or not.
4:If the Issuer not requires verify dynamic verification data, then the payment page will dis-
play the payment elements based on Issuer’s associated authentication elements. The card
holder enters the relevant payment information and the transaction message is then sent to
the card Issuer’s system for authorization to complete the transaction process.
5:If the Issuer requires verify dynamic verification data, then the following transaction flow
applies.
6: If the card used in UPOP at the first time, UPOP sends the card number and mobile num-
ber authenticated transaction request to the card Issuer for authentication. If not, then skip to
flow 81.①
7: The Issuer uses the card number to verify the card holder's mobile number information
and confirms it is correct. The maximum e attempts are no more than twice, otherwise the
card will be denied by UPOP system within six hours.
8: The UPOP sends the dynamic verification data (SMS code) to the card holder's mobile
number.
9: The card holder enters the dynamic verification data (SMS code) on the UPOP payment
page.
10: After the UPOP authenticates the dynamic data as correct, the payment elements are
passed to the Issuer for authorization.
11: The card Issuer approves or declines the transaction and the result is sent to the Acquirer
and then to the merchant.
2

3.1.1.2 Issuer Send SMS Mode ②

1 ①
If the card was used in UPOP before, mobile number will reserve in UPOP system and cardholder no need to enter
mobile number again. The last two digits of the mobile number will display on the UPOP webpage to indicate card-
holder. Cardholder can re-enter mobile number when it changed in Issuer and UPOP will send the new mobile num- ber
to verify via Issuer.
2②
Issuer sends SMS mode only applicable for card issuer that has upgraded to 2.1 message and support account veri-
fication transaction.

7
 UnionPay Card E-Commerce Implementation Guide for Issuer

1: Order is successfully
submitted

2: Enter UnionPay card number

3: Is dynamic authentication data mode

required?

Yes
No

5: Input authentication data, click

"Send SMS" 4: No SMS

6. Send Account verification transaction

7: Issuer return the last 4 digit of

mobile phone number, then Notify the
generates and sends SMS cardholder:
The SMS has been
sent to your mobile
8:Enter dynamic authentication phone ****1234.
code

9: Confirm payment

10: Display payment result

1: An order is successfully submitted, and a UnionPay card is selected for payment.

2: The card holder enters their UnionPay card number on the UPOP payment interface.
3: The UPOP dynamically displays the required authentication elements based on the Issuer’s
authentication elements profile (for details on authentication element combinations please see
description in 4.2 regarding authentication elements).

8
 UnionPay Card E-Commerce Implementation Guide for Issuer

4: If the Issuer requires verify dynamic verification data, then the following steps are required.
5: Cardholder enters the relevant authentication information and presses the “Send SMS”
button.
6: The UPOP sends the account related request to the card Issuer via account verification
transaction.
7: At the same time the Issuer generates and sends the dynamic authentication code to card
holder’s mobile number on file and returns the card holder’s last 4 digits of mobile number
back to the UPOP. UPOP will notify the card holder the SMS has been sent to your mobile
phone ****1234.
8: The card holder enters the dynamic verification data on the UPOP payment page.
9: The SMS dynamic authentication code and payment transaction is sent to the Issuer for
authorization.
10: The card Issuer approves or declines the transaction and the result is sent to the Acquirer
and then to the merchant.

3.1.2 Non-Authentication Mode

1: Order is successfully
submitted

2: Enter UnionPay card

number and payment info

3: Confirm payment

4: UPOP transfers payment info

5: Card issuer makes

authorization

6: Display payment result

1: An order is successfully submitted and a UnionPay card is selected for payment.

2: The card holder enters their UnionPay card number on the merchant or UnionPay payment
page.
3: The card holder clicks to confirm payment.
4: The Acquirer or the merchant sends the payment information to the UPOP and the transac-
tion is sent to the Issuer for authorization.

9
 UnionPay Card E-Commerce Implementation Guide for Issuer
5: The Issuer processes the transaction.
6: The Issuer returns the transaction result to the merchant or Acquirer.

3.2 System interactive flows

3.2.1 Authentication Mode
3.2.1.1 UnionPay Send SMS Mode on behalf of card issuer

Merchant Acquirer UPOP GSCS Issuer SMS Center

Cardholder
1.Request
2.Transfer Request

3.Request

4.UPOP webpage

5.Info.
6.Verification Request 7.Response
Result
8.Send SMS Request
9.Send SMS Send
SMS
with code

10.Enter SMS code 11.Send SMS code

12.Response Result Verify
SMS
code

13.Send Purchase Request

14.Response Result
15.successful page
16. 17.Response
Result

10
 UnionPay Card E-Commerce Implementation Guide for Issuer

1: The card holder makes a purchase at the merchant website, and then selects their Union-
Pay card for payment.
2: The merchant sends the transaction information to the Acquirer.
3: The Acquirer directs the transaction request to the UPOP system.
4: The UPOP displays the payment page to the card holder.
5: The card holder enters their card number, mobile number and other payment information,
and then clicks the button to send the dynamic verification code.
6: If card is used in UPOP at the first time, the UPOP sends the balance inquiry transaction
(including card number and mobile number) to Issuer via GSCS platform. If not, skip to flow
8.
7: The Issuer uses the card number to verify the card holder's mobile number information.
The maximum attempts are no more than twice, otherwise the card will be denied by UPOP
system within six hours.
8: If the card holder’s mobile number is correctly matched, the UPOP notifies the SMS pro-
cessing system to send an SMS.
9: An SMS containing verification data is sent to the card holder's mobile.
10: The card holder receives the SMS with the six digit verification code and then enters the
dynamic verification code on the UPOP page.
11: The UPOP sends the dynamic verification code to the SMS gateway for verification.
12: The verification result is returned to the UPOP system.
13: The card holder clicks to confirm payment, then the UPOP system sends the payment in-
formation to issuer via GSCS.
14: The Issuer returns the authorization result.
15: The payment page displays to the card holder the result of their transaction.
16: The UPOP returns the transaction result to the Acquirer.
17: The Acquirer sends the transaction result to the merchant.

3.2.1.2 Issuer Send SMS Mode ③

Merchant Acquirer UPOP GSCS Issuer Issuer SMS Center

Cardholder
1.Send Request
2.Transfer Request

3.Transfer Request

4.Redirect to UPOP webpage

5. Input Payment Information, click to send SMS

6.Account Verification
7.Response last 4 digits of mobile number
8.end SMS Request
9.Send SMS
Send SMS

10.Enter SMS code

11.Send Purchase Request

12.Response Result
13.Redirect to successful page

3 ③
Issuer sends SMS mode only applicable for card issuer that has upgraded to 2.1 message and support account veri-
fication transaction.
11
 UnionPay Card E-Commerce Implementation Guide for Issuer
14.Response Result 15.Response
Result

1: The card holder makes a purchase at the merchant website, and then uses their UnionPay
card for payment.
2: The merchant sends the order information to the Acquirer.
3: The Acquirer redirects the transaction request to the UPOP system.
4: The UPOP displays the payment page to the card holder.
5: The card holder enters the card number and other payment information, and then clicks the
button to send dynamic verification code.
6: The UPOP sends the account verification transaction to trigger Issuer send SMS.
7: The Issuer processes the account verification transaction, and then returns the last 4 digits
of mobile phone number.
8: At the same time the Issuer generates SMS based on the SMS module described in 3.2.3.
9: The Issuer sends the SMS to the card holder's mobile number.
10: The card holder receives the SMS with the 6 digits dynamic authentication code and en-
ters it on the UPOP page.
11: The card holder clicks to confirm payment, and the UPOP system sends the payment
information including the dynamic verification data to issuer via GSCS.
12: The Issuer returns the transaction result.
13: The payment success page is displayed to the card holder.
14: The UPOP returns the transaction result to the Acquirer.
15: The Acquirer returns the transaction result to the merchant.

12
 UnionPay Card E-Commerce Implementation Guide for Issuer

3.2.2 Non-Authentication Mode

1: The card holder makes a purchase at the merchant website, and then uses their UnionPay
card for payment.
2: The merchant sends the order information and payment information to the Acquirer.
3: The Acquirer redirects the transaction request to the UPOP system.
4: The UPOP sends the payment information to the Issuer via GSCS.
5: The Issuer processes the authorization request and returns the result to the GSCS, which
returns the authorization result to the UPOP.
6: The UPOP returns the transaction result to the Acquirer.
7: The Acquirer returns the transaction result to the merchant.

13
 UnionPay Card E-Commerce Implementation Guide for Issuer

4 Online Transaction Processing Request

4.1 Description of Transaction Types

The E-Commerce transaction service includes a number of transaction types. Including
but not limited to purchase/authorization, pre-authorization, refund, account verification and
balance inquiry transaction as follows:

Single message Dual message

2.0 Version Purchase/Purchase Cancellation Authorization/Authorization Can-

cellation
Pre-Authorization/Pre-Authorization
Cancellation Balance Inquiry
Pre-Authorization Comple-
tion/Pre-Authorization Completion Can-
cellation
Balance Inquiry

2.1 Version Self-Service Purchase/Purchase Cancella- Authorization/Authorization Can-

tion cellation
Self-Service Balance Inquiry
Pre-Authorization/Pre-Authorization
Account Verification
Cancellation
Self-Service Pre-Authorization Comple-
tion/Pre-Authorization Completion Can-
cellation
Balance Inquiry
Account Verification
4

4.1.1 Account Verification Transaction ④

For the processing of E-Commerce transactions in Authentication Mode, issuers that
choose Issuer Send SMS mode must make system modifications to handle account verifica-
tion transactions. In these circumstances, Account Verification transaction prior to payment
is meant to trigger the sending of the dynamic verification data and request the last 4 digits of
the mobile phone number.
Account Verification is detailed in Section 4.3 “Account Verification” and “Technical
Specifications on Bankcard Interoperability”, Part II Online Message guidelines.
Issuers that utilize UnionPay Send SMS mode do not need system change for account
verification transactions.
5

4.1.2 Balance Inquiry Transaction ⑤

Issuers must support for Balance Inquiry transaction. The Balance Inquiry transaction
will require a complete card number, and a mobile number for matching verification. For de-
tails see Section 4 “Balance Inquiry” relating to balance inquiry transactions.

4.2 Key points for E-Commerce Transaction Message

4.2.1 Online Message Description

4 ④
Account verification transaction only applicable for card issuer that has upgraded to 2.1 messages.
5 ⑤
Balance inquiry transaction applicable for sending dynamic authentication data mode.
14
 UnionPay Card E-Commerce Implementation Guide for Issuer

For Authentication mode, prior to the transaction occurring, the domestic or international
Acquirer initiates an account verification transaction to trigger the Issuer (or UnionPay as
agent) to send the dynamic verification code.
4.2.1.1 F60.2.5 Terminal Type
Messages between the Acquirer, UnionPay, and the Issuer utilize the F60.2.5 to indicate E-
Commerce transactions. The value of F60.2.5 is “07” for on E-Commerce transaction.
4.2.1.2 F60.2.8 Electronic Commerce Identification (ECI) Symbol
Messages between the Acquirer, UnionPay, and the Issuer utilize the F60.2.8 ECI symbol
to store transaction mode data (this symbol only indicates the mode which acquirers attempt,
so whether the dynamic verification data is included depends on Issuers choice of Authenti-
cation Mode).
New defined values for F60.2.8 ECI label:

09 Authentication Mode

10* Non-Authentication Mode

* Currently some acquirers haven’t finished the modification and their Non-Authentication Mode ECI
may be ’00’ as default. In this situation we treat ‘00’ as ‘10’.

Note: ECI is related to E-Commerce liability shift.

Only if the Acquirer initiates an Authentication Mode transaction, the ECI value of the
transaction will be set to 09. Else if the Acquirer initiates a Non-Authentication Mode
transaction, the ECI value of the transaction will be set to 10.
The Issuer has different Chargeback right by using Reason Code 4515 according to the
value of ECI. When ECI value is 09, the Issuer has no right to initiate a chargeback using
Reason Code 4515.
Especially, if the Issuer who only supports Non-Authentication Mode while the Acquirer
initiates an Authentication Mode transaction, the transaction will be downgraded to a
Non-Authentication Mode transaction, but ECI value will still be kept as 09.

Note: October 14, 2015, Reason Code 4810 has expired and UPI OR incorporated
Chargeback Reason Code 4810 into 4515 according to UPI OR (Version June, 2015).

4.2.1.3 F61.6 AM Usage

When an Acquirer has a special requirement for the security of the transaction, they can
require the Issuer to conduct additional transaction element verification through the F61.6
AM field.
F61.6AM is also used to transmit the dynamic verification data. The 10th position in the
bitmap represents whether to verify dynamic verification data, storing the dynamic verifica-
tion data in the self-defined data with data type ANS40. The first 20 bytes are used to store
6

the key ⑥ for dynamic verification data, while the following 20 bytes are for storing the dy-
namic verification code.
The verification elements that the Acquirer selects to send as part of the transaction au-
thorization process are defined in the following table:

6 ⑥
The format for the key is "14 digits YYYYMMDDHHMMSS + 6 random digits".
15
 UnionPay Card E-Commerce Implementation Guide for Issuer

Name Description Usage description

Verification 16 bytes (bitmap), every byte represent one verification Element, For each byte,
Indicator beginning from the left most byte, each byte represents the below 1) The Acquirer shall fill with
verification Element in turn: the following value.
byte1–PIN verification indicator (PIN data is stored in field 52). It 0: no present
is recommended for Acquirer to keep consistency between the 1: present
value of this byte and the value of F22 & F52. Issuer conducts PIN 2) Issuer shall return this
verification based on the value of F22 and F52, even when the usage in response with the
indicator being set as ‘0’) same value.
byte2–card expire date verification indicator (Card Expire Date is Note
stored in field 14). It is recommended for Acquirer to keep a. The name, mobile phone
consistency between the value of this byte and the presence of F14. number, dynamic verification
Issuer conducts Card Expire Date Verification based on the code used in card-no-present
presence of F14, even when the indicator being set as ‘0’) transactions will be listed in
byte3–identification card Number verification indicator (ID Card the following “Verification
Number is stored in field 61.1). It is mandatory for Acquirer to set Element Value” part.
this byte as “1” when ID Card Number is used as Verification b. Issuer will verify the
Element; Issuer conducts ID Card Number Verification (F61.1) verification elements
based on the indicator being set as '1') according to the bitmap
byte4–Reserved, filled with all 0. sequence. Once error occurs,
byte5–Reserved. Filled with all 0. Issuer will stop the
byte6–CVN2 verification indicator (CVN2 Value is stored in field verification processing, and
61.4). It is mandatory for Acquirer to set this byte as “1” when will respond “05” in F39 to
CVN2 is used as Verification Element; Issuer conducts CVN2 reject transaction. If the
verification (F61.4) based on the indicator being set as '1') verification of some element
byte7–Reserved. Filled with all 0. is not supported by the issuer,
byte8–name verification indicator (Name is stored in this usage). It issuer shall return “40” in F39
is mandatory for Acquirer to set this byte as “1” when Name is to reject.
used as Verification Element; Issuer conducts Name Verification c. ID number verification
(“Verification Element Value” part of this Usage – “Name”) based shall require the last six digits
on the indicator being set as '1') of ID number. The six digits
byte9-mobile phone number verification indicator (mobile phone are the last 6 digits of ID card.
number is stored in this usage). It is mandatory for Acquirer to set If there is not enough valid
this byte as “1” when mobile phone number is used as Verification digit, it shall be padded with 0
Element; Issuer conducts mobile phone number verification on the left and with space on
(“Verification Element Value” part of this Usage – “Mobile phone the right, e.g., for ID number
number”) based on the indicator being set as '1') ABC1234, 12ABC34,
byte10-Dynamic verification code verification indicator (Dynamic 1234ABC will be represented
verification code is stored in this usage). It is mandatory for as 0001234, padded with 13
Acquirer to set this byte as “1” when Dynamic verification code is spaces on the right. For ID
used as Verification Element. Issuer conducts Dynamic verification numberX12345678,
code verification (“Verification Element Value” part of this Usage 1234X5678 12345678X will
– “dynamic verification code”) based on the indicator being set as be presented as 345678,
'1') padding “000” on the left and
byte11–16:reserved for use, filled with all 0 11 spaces on the right.
Verification ans…147.Reserved. Currently name, mobile phone number, 1. In response message,
Element dynamic verification code can be stored. Issuer shall return the value
Value 1. Chinese characters are the primary choice for name. The the same with the original
encoding of Chinese character is GB18030-2000. There is no space value submitted by Acquirer.
between each Chinese character in the Chinese name, but there may 2. The Verification
be special characters like separator. Where Chinese characters Element Value will appear in
cannot be input, Chinese spelling letters (PIN YIN) can be used the sequence defined in the
instead. Family name comes first and then given name, separated above bitmap. Considering
by space, and capitalized with initial letter of both surname and that some information are of
given name, Alternatively, English name can be input with given variable length, a digit number
name coming first and then surname, separated by a space and with fixed length (3 bytes)
capitalizing the initial letter of both surname and given name. will be added prior to each
Regarding the name information transfer under special cases such verification element value for
as cardholder of the company account, the processing follows the indicating the length of each
normal processing, where there is no space between Chinese element value. There is no
characters and if English name is used, the system will not space between verification
separate deliberately but forward the actual input. elements.
2. Mobile phone number is a field with variable length. 3. These elements can
District code shall not be included. appear individually or
3. The dynamic verification code is defined as ANS40, with combined. While combined,
16
 UnionPay Card E-Commerce Implementation Guide for Issuer
Name Description Usage description
the first 20 bytes are used to store the key value related with the sequence shall be the same
dynamic verification, which is submitted by the acquirers, and the with the above bitmap
last 20 bytes are used to store the dynamic verification code.
Note 1: if the auxiliary verification element submitted by acquirer does not meet the operational standard,
issuer can reject the transaction according to operating regulations. And return response code “40” to indicate
transaction failure.
Note 2: If UnionPay is acting as the agent to conduct stand-in verification, this Usage will be filled by
UnionPay in Card-Not-Present Transaction.

Detailed definition please refer to Technical Specifications on Bankcard Interoperability - Part II

Online Message - Field 60 Self-Defined Field.

4.2.1.4 F48 AS Usage

(1) PM Tag:
The PM tag has been recently added to F48 AS usage to indicate secondary merchant in-
formation.
The Secondary merchant code and name/location information used in E-Commerce trans-
actions are sent by the Acquirer.
Position Meaning Length
No.
1 Secondary merchant code Ans15, label for secondary merchant code

2 Secondary merchant Ans40, label for secondary name and location. Usage of
name and location this field should meet requirements of the "Service Guide-
lines"
(2) Other Tags:
Account Verification transaction will utilize F48 AS Usage AO Tag and ON Tag.
For de- tails guide please refer to Section 4.3 Account Verification.

4.2.1.5 Response Code

For high-risk merchants the Issuer can set its own risk controls in determining
whether to accept the transactions. Transactions that are rejected on this basis will have
a response code “03”.
If the authentication information submitted by acquirer does not meet the rules, issuer
can reject the transaction according to rules. And return response code “40” to deny
transaction.
If the card does not have a mobile number reserved in Issuer bank, Issuer should
response code “P1”.
If the card mismatches the mobile phone, Issuer should response code “05”.
For other circumstances, please refer to Technical Specifications on Bankcard
Interoper- ability - Part VI Annex.

4.2.2 Transaction Element Values

4.2.2.1 Key Values for 2.0 message format.

Mes- Transaction ID

17
 UnionPay Card E-Commerce Implementation Guide for Issuer
N Service sage Transaction F2 F60.2 F22 F60.2.8 * F61.
o. Type Type Type F0 F3 .5 6
5
0200/ 00x0
1 Purchase 00
0210 00

Purchase 0200/ 20x0

2 00
Cancellation 0210 00
011:PIN
Purchase included
0420/ 20x0 in Card
3 Cancellation 00
0430 00 not Pre-
Reversal
sent
Pre-authoriza 0100/ 03x0 transac-
4 06
tion 0110 00 tion; 09:Authentication
AM
E-Comme Mode
Single 07 Us-
rce Pre-auth 0100/ 20x0 012:PIN
5 06 10:Non-Authentic age
Cancellation 0110 00 excluded ation Mode
in Card
not Pre-
Pre-auth
0420/ 20x0 sent
6 Cancellation 06
0430 00 transac-
Reversal
tion;
Pre-auth 0200/ 00x0
7 06
Completion 0210 00
Pre-auth
0200/ 20x0
8 Completion 06
0210 00
Cancellation
0220/ 20x0
9 Refund 00
0230 00
Authoriza- 0100/ 00x0
10 00
tion 0110 00
Authoriza- 0420/ 00x0
11 00
tion Reversal 0430 00
Authoriza-
Dou- 0100/ 20x0
12 tion Cancel- 00
ble 0110 00
lation
Authoriza-
tion Cancel- 0420/ 20x0
13 lation Re- 0430 00
00
versal
Balance 0200/ 30x0
14 Single 00
Account Inquiry 0210 00
Service Dou- Balance 0100/01 30x0
15 00
ble Inquiry 10 00

* Currently some acquirers haven’t finished the modification and their Non-Authentication Mode
ECI may be ’00’ as default. In this situation we treat ‘00’ as ‘10’.

4.2.2.2 Key Values for 2.1 message format.

Mess Trans- Transaction ID

N Service F60. F60. F61
age action F F22 F60.2.8 *
o. Type F0 F3 F60.3.5 2.5 .6
Type Type 25 2.9
Pur- 0200/ 00x0 Self-Se
1 00
chase 0210 00 rvice
Pur-
0200/ 20x0 Self-Se
2 chase 00
0210 00 rvice
Cancel
Pur-
chase 0420/ 20x0 As
3 00
Cancel 0430 00 Orig
Reversal

18
 UnionPay Card E-Commerce Implementation Guide for Issuer
0100/ 03x0 As 011:PI 0:
4 Pre-auth 06
0110 00 Orig N in- De-
cluded
Pre-auth in Card fault
0100/ 20x0 As
5 Cancel- 06 not
Sin- 0110 00 Orig 1:
lation Present
gle 09:Authenticat Inter-
trans-
Pre-auth AM
0420/ 20x0 As action; ion Mode ter-
6 Cancel 06 07
E-Com 0430 00 Orig 10:Non-Authe Usa
Reversal net ge
merce 012:PI ntication
Pre-auth N ex-
0200/ 00x0 As Mode 2:
Comple- 06 cluded
0210 00 Orig
tion in Card Text
Pre-auth not Mess
Comple- Present
0200/ 20x0 As age
7 tion 06 trans-
0210 00 Orig
Cancel- action; 3:
lation Voic
0220/ 20x0 Self-Se e
8 Refund 00
0230 00 rvice
Author- 0100/ 00x0 Self-Se
9 00
ization 0110 00 rvice
1 Auth 0420/ 00x0 As
Dou- 00
0 Reversal 0430 00 Orig
ble
Auth
1 0100/ 20x0 As
Cancel- 00
1 0110 00 Orig
lation
Auth
1 Cancel- 0420/ 20x0
00
As
2 lation 0430 00 Orig
Reversal
Account
1 0100/ 33x0 Self-Se
Sin- Verifi- 00
3 0110 00 rvice
gle cation
1 Balance 0200/ 30x0 Self-Se
00
4 Account Inquiry 0210 00 rvice
Service Account
1 0100/ 33x0 Self-Se
Verifi- 00
5 Dou- 0110 00 rvice
cation
ble
1 Balance 0100/ 30X Self-Se
00
6 Inquiry 0110 000 rvice

* Currently some acquirers haven’t finished the modification and their Non-Authentication Mode
ECI may be ’00’ as default. In this situation we treat ‘00’ as ‘10’.

4.2.3 Requirements to transfer Authentication Elements

4.2.3.1 Authentication Mode
1. Debit / Prepaid Card
Verification El-
AC->SW SW->IS IS->SW SW->AC
ement
Transfer
Card no. Required Return As Is Return As Is
As Is
Required when card issu-
Dynamic verifi- Transfer
er sends dynamic verifi- Return As Is Return As Is
cation code As Is
cation code1
Transfer
PIN Optional2 Return As Is Return As Is
As Is
Transfer
Expiration date Optional3 Return As Is Return As Is
As Is
Transfer
CVN2 Optional4 Return As Is Return As Is
As Is

19
 UnionPay Card E-Commerce Implementation Guide for Issuer
Required when UnionPay
sends dynamic verifica- Transfer
Mobile Phone No Return As Is Return As Is
tion code on behalf of As Is
card issuer
Note 1: Where card Issuer sends the dynamic verification code. In F61.6AM usage "transaction
verification method" data, if the value of "byte10-dynamic verification code" is 1, then this type
transaction sends dynamic verification code, and the card issuer verifies the dynamic code.
Note 2: Card Issuer can choose to verify the dynamic verification code in lieu of a PIN. For
details see section 3.1 on authentication elements.
Note 3: Whether the expiration date would be verified is determined by card Issuer when joining
network. If the card Issuer chooses to verify expiration date, then "byte2-card expiration date
verification" of the "transaction verification method" data will have value 1, indicating that in
this type of purchase transaction validity period must be sent, and card Issuer must verify.
Note 4: Whether the CVN2 would be verified is determined by card Issuer when joining network.
If the card Issuer chooses to verify CVN2, then "byte6- CVN2 verification" of the "transaction
verification method" data will have value 1, indicating that in this type of purchase transaction
validity period must be sent, and card Issuer must verify.

2. Credit Card
Verification
AC->SW SW->IS IS->SW SW->AC
Element
Card no. Required Transfer As Is Return As Is Return As Is
Dynamic verifi- Required when
Transfer As Is Return As Is Return As Is
cation code card issuer sends
dynamic verifica-
tion code
CVN2 Required
Transfer As Is Return As Is Return As Is
Expiration date Required
Transfer As Is Return As Is Return As Is
Required when
UnionPay sends
Mobile Phone No dynamic verifica-
Transfer As Is Return As Is Return As Is
tion code on behalf
of card issuer
4.2.3.2 Non-Authentication Mode
1. Debit / Prepaid Card
Verification Ele-
AC->SW SW->IS IS->SW SW->AC
ment
Card no. Required Transfer As Is Return As Is Return As Is
1
Expiration date Optional Transfer As Is Return As Is Return As Is
2
CVN2 Optional Transfer As Is Return As Is Return As Is
2
Name Optional Transfer As Is Return As Is Return As Is
Note 1: If the Debit / Prepaid card has Expiration Date, the issuers can choose to verify it and acquir-
ers should send it. If the Debit / Prepaid card has no Expiration Date, the issuers should not choose
this element to verify.
Note 2: If acquirers send transactions with CVN2 or cardholder name, issuer should verify them cor-
rectly; If acquirers send transactions without CVN2 or cardholder name, issuer should not decline due
to the absence of CVN2 or cardholder name.

2. Credit Card
Verification Ele-
AC->SW SW->IS IS->SW SW->AC
ment
Card no. Required Transfer As Is Return As Is Return As Is
Expiration date Required Transfer As Is Return As Is Return As Is
1
CVN2 Optional Transfer As Is Return As Is Return As Is
1
Name Optional Transfer As Is Return As Is Return As Is
Note 1: If acquirers send transactions with CVN2 or cardholder name, issuer should verify them cor-
rectly; If acquirers send transactions without CVN2 or cardholder name, issuer should not decline due
to the absence of CVN2 or cardholder name.

20
 UnionPay Card E-Commerce Implementation Guide for Issuer
7

4.3 Account verification ⑦

4.3.1 Type Description
Prior to a purchase transaction being processed, the Acquirer (or UnionPay) initiates the
account verification transaction to trigger the Issuer to send the dynamic verification code.
If the Issuer is sending the dynamic verification code, the UnionPay system transfers the
account verification transaction to the Issuer, and on receipt the Issuer then sends the dynam-
ic verification code and returns the last 4 digits of the mobile phone number of the card
stored in the issuer.
If UnionPay is acting as the agent in sending the dynamic verification code, then Union-
Pay will send the dynamic verification code and verify it in subsequent transaction. In this
case the Issuer will not receive any account verification transactions.
4.3.2 Key Points

Sending account verification without a purchase transaction can be used to trigger the
sending of dynamic verification code and returns the last 4 digits of the mobile phone num-
ber of the card stored in the issuer.

4.3.2.1 F48 AS usage – AO Tag

In the account verification message F48, AS usage, the use of the AO tag provides an ad-
ditional value for Code 18 -“E-Commerce dynamic verification data trigger". The card Issuer
recognizes the relevant tag for the account verification transaction and triggers the sending of
the dynamic verification code to the card holder. Meanwhile, return the last 4 digits of the
mobile phone number.
Code Related service name Usage Notes
18 Card-not-present For Card State Inquiry and payment. Issuer sends
self-service dynamic the dynamic verification code to the cardholder
verification trigger, when recognizes the Account verification transac-
for Card State Inquiry tion is for triggering dynamic verification code for
and payment. E-Commerce Transaction, meanwhile, returns the
last 4 digits of the mobile phone number of the
cardholder if the card state is normal, through F57
AS Usage - SE Tag.
4.3.2.2 F48 AS usage – ON Tag
In the F48 AS usage, the new ON tag is used to transmit an order number. This is used by
the Acquirer to pass the transaction order number from the merchant to the card Issuer with
the account verification transaction. For account verification transactions used to trigger dy-
namic verification data, the AS usage ON tag can only be used to send order number data.
Position Meaning Length
No.
1 Order no Ans40, used to label transaction order number from the
merchant

4.3.2.3 F57 AS Usage SE Tag

The tag SE of Usage AS in Field 57 is used for Issuer to return card status and Mobile
phone number (last 4 digits) of card holder to Acquirer.
Position No. Meaning Length

7 ⑦
Account verification transaction type only applicable for card issuers that have upgraded to 2.1 message.
21
 UnionPay Card E-Commerce Implementation Guide for Issuer
1 Card status an3, label for card state.
Three spaces: Default
OFF: Card is frozen or suspended by the issuer.
2 Mobile ans20, store the masked and last 4 digits of mobile
Phone No. phone number of cardholder, left-aligned, right-fill
spaces.
For example, the mobile phone number is 12345678,
****5678 should be returned.

4.4 Balance Inquiry

For Issuers that use UnionPay to issue the dynamic verification code SMS on their behalf,
a balance inquiry transaction is necessary to complete the card number and mobile number
verification process. Using a balance inquiry transaction the mobile number for the card ac-
count is sent to the Issuer, and then checked against the card holder's mobile number on file
with the Issuer.
Technically E-Commerce Balance Inquiry is a sort of POS Balance Inquiry. The mes-
sages have some differences from POS Balance Inquiry. Currently in E-Commerce Balance
Inquiry message F60.2.5 is 07 and mobile phone number stored in F61.6 AM Usage.
Mobile phone number is a subfield with variable length without district/country code in
F61.6 AM Usage.

Note: If the card does not have a mobile number on file in the issuer a P1 error code is
returned.

4.5 Verifying dynamic verification data ⑧

Section 4 – ‘Online Transaction Processing Request’ stipulates that the message field us-
es F61.6AM to transmit dynamic verification data, using the 9th and 10th position in the bit-
map to represent whether to verify dynamic verification data.
4.5.1 Verifying mobile phone number
Issuers need to support verification of the mobile phone number when receive Balance
Inquiry, Purchase, Pre-Authorization, and Authorization transactions. F61.6 AM Usage is
used to transfer mobile number to issuers. Mobile phone number is a subfield with variable
length without district/country code stored in the self-defined data in F61.6 AM Usage. The
first 3 bytes are for the length of the mobile phone number and the following bytes are the
mobile phone number. For example, “00812345678”.
4.5.2 Verifying dynamic verification code
4.5.2.1 Dynamic verification code format
The dynamic verification code is stored in the self-defined data with data type ANS40.
The first 20 bytes are used to store the dynamic verification associated key, while the fol-
lowing 20 bytes are for storing the dynamic verification information.
To achieve this, the UPOP and the Issuer agree to process as follows:
For the key: UPOP sends "14 digits YYYYMMDDHHMMSS + 6 random digits" to the
Issuer.
For the dynamic verification data: The Issuer must use the same format as UPOP, being a
6 digit number.
Dynamic verification data and associated keys are left-aligned, right-fill spaces.

8 ⑧
When an Issuer chooses to send the dynamic verification code by itself, it should refer to this section.
22
 UnionPay Card E-Commerce Implementation Guide for Issuer

Note: During payment, UPOP sends the key for "account verification" transaction first,
triggering the Issuer to send the dynamic verification data. During the transaction both the
key and dynamic verification data are sent to the Issuer to verify.

4.5.2.2 Formats for dynamic verification data ⑨

In order to deliver a consistent and reliable payment service to card holders, Issuers that
elect to send dynamic verification data themselves will need to follow this process:
1. SMS module
"Purchase transaction and pre-authorized transaction" module:
The UnionPay online payment verification code is: {0}, amount {1}{4}, merchant :{2},
order number{3}.
** PLEASE NOTE – THIS MUST BE KEPTCONFIDENTIAL! **

The specific data elements are:

{0}: SMS verification code, 6 digit number;
{1}: transaction amount,
{2}: merchant name, 8 Chinese characters;
{3}: order number, last 8 digit characters of merchant order number; and,
{4}: transaction currency unit, 3 digit English acronym, for example: RMB, USD.
Note: The length of a single SMS transaction should be kept under 70 characters.
2. Time interval between transmissions of dynamic verification data
The cycle time between dynamic verification data requests is 60 seconds. This means that
after the card holder clicks "Sending SMS ", 60 seconds must pass before the card holder can
click to receive a new SMS verification code.
3. Valid time for dynamic verification data
The SMS verification code is valid for 100 seconds, during which time the same SMS
verification code can be verified multiple times by the card holder.
4. Number of times dynamic verification data can be sent
If the card holder clicks "Receive SMS verification code" 5 times in one hour, the SMS
verification code service is disabled for 1 hour.
If the card holder enters an invalid "SMS verification code" 3 times within 1 hour, then
the sending of a new dynamic verification code is disabled for 1 hour.

9 ⑨
When an Issuer chooses to send the dynamic verification code by itself, it should refer to this section.
23
 UnionPay Card E-Commerce Implementation Guide for Issuer

5 Settlement

5.1 Document List

Num-
Document name Description
ber

General single message transaction

1 IFDYYMMDD01ICOM settlement detail of organizations as
issuers

Dispute settlement detail of organiza-

2 IFDYYMMDD01IERR
tions as issuers

General Dual-message settlement detail

3 IFCYYMMDD99C
of organizations as issuers

Transaction statistics file of organiza-

4 IFCYYMMDD99S
tions as issuers

IFRYYMMDD01C603DZ-
<Transaction Curren- cy>- Old UPI Institution Net Settlement
5
<Settlement Curren- cy> Summary

6 IFRYYMMDD01C605DZ Institution Dispute Resolution Detail

UPI Institution Fee Settlement File,

FD<YYMMDD>01IFEED
7 which provides detailed and more ac-
TL
curate fee settlement file to members.

IFR<YYMMDD>01C602D
Z-<”Transaction Curren- UPI Institution Settlement (UIS) Re-
8
cy”>-<”Settlement Cur- port.
rency”>

5.2 Explanations on Settlement File Access Mode

5.2.1 SFTP Mode
UnionPay archives the settlement documentation and reports by Issuer code. On the same
day as settlement occurs, UnionPay loads the settlement documentation and reports to the
SFTP server, and those documents are then available to be downloaded individually by Issu-
ers.
5.2.2 Flow transmission Mode
Issuers that use the current transfer mode download specified in the "UnionPay Bank
Card Interoperability Technology Guidelines V2.0 part 3 File Interface" File Interface
Guidelines can use either passive or active download of settlement documentation and re-
ports.
Passive download: After UnionPay has completed the daily settlement; the day's settle-
ment document and report are sent to the bank prior to 8:00am Beijing time.
Active download: After UnionPay has completed the daily settlement; banks can down-
load the settlement documentation and reports from UnionPay after 8:00am Beijing time.
The Settlement document and report can be downloaded individually, or UnionPay can
compress the day's documents into a single zip file which can then be downloaded by the
bank. The compressed document naming convention is ‘yyyymmdd.zip’ (with yyyymmdd

24
 UnionPay Card E-Commerce Implementation Guide for Issuer

being the transaction date). If the compressed file method is chosen, UnionPay must be noti-
fied in advance to prepare the files accordingly.
5.2.3 PGP+Email Transmission
It is not recommended to use email for transmission of settlement documents.
5.3 Settlement Characteristics of E-Commerce Transactions
Typically E-Commerce settlement and POS/ATM transactions are processed concurrent-
ly. Card Issuers can differentiate E-Commerce transactions from other transaction records
and dispute transaction records based on F60.2.5 (channel 07).
Issuers can use the following points to differentiate E-Commerce transactions and
POS/ATM transactions in the settlement document.
 For single message transaction details document (IFDYYMMDDICOM or
IFCYYMMDD99C):
Field 22: 011(PIN-enabled CNP transaction), 012(no PIN CNP transaction).
 For dual message transaction details document (IFCYYMMDD99C):
E-commerce transaction initiation channel is 07.
 For single data transaction details document (IFDYYMMDDICOM):
reserved field CCCRM□□□□□□□MMDDHHMMSS□XXYYZSS, in E-commerce
transaction XX is 0,YY is 09 (card issuer authentication mode) or 10 (card issuer Non-
authentication mode)

25
 UnionPay Card E-Commerce Implementation Guide for Issuer

6 Participating Procedures

6.1 Application Procedures for E-Commerce Service.

Application procedures for E-Commerce issuing business
Issuer UPI

Consult UPI local representative about Provide business document and

E-Commerce business; membership application forms

Apply for UPI issuing membership Carry out membership assessment on

membership application

Carry out technical and business

Provide technical and business support
assessment on business application

Fill in and submit E-Commerce

Confirm forms and make an assessment
issuing program application form

Conduct system modification

1. Confirm forms and provide support

Submit testing application form 2. Provide testing report

Confirm forms and prepare System

Fill in system launch application form
launch

Stage 1:
Institution: consults a UPI representative about E-Commerce product information.
UPI: provide the E-Commerce issuing business documents, UPI issuing membership ap-
plication forms to institution.
Stage 2:
Institution: fills in and submits the UPI membership application forms.
UPI: during the stage 2, UPI operation team makes an assessment based on these submit-
ted documents.
Stage 3:
Institution: if institution gets the authorization from UPI, institution performs the busi-
ness and technical assessment based on the provided E-Commerce business documents.
UPI: UPI product team provides the business and technical support.
Stage 4:
Institution: fills in and submits the E-Commerce issuing program application form.
UPI: during the stage 4, UPI product team makes an assessment based on the submitted
document.

26
 UnionPay Card E-Commerce Implementation Guide for Issuer
Stage 5:

27
 UnionPay Card E-Commerce Implementation Guide for Issuer

Institution: conducts system modification according to document UnionPay Card E-

Commerce Implementation Guide for Issuer.
Stage 6:
Institution: submits testing application form and testing cards.
UPI: confirm the application form, configure the testing environment and then provide
the testing plan. Afterwards, UPI provides the testing report to confirm the test is completed.
Stage 7:
Institution: fill in the launching application form and submit it to the UPI.
UPI: Confirm the system in production environment has been configured.
6.2 Checklist for E-Commerce Service
Status Files
Stage 1 E-Commerce Product Guide

□ UPI Membership application forms(101,105,106 form)

Stage 2
Authorization result

Stage 3 UnionPay Card E-Commerce Implementation Guide for Issuer

□ UnionPay Card E-Commerce Issuing Program Application

Stage 4 Form

□ T115_UnionPay Members and Partners Online Testing Re-

Stage 6 quest Form
T25_Certification result

Stage 7 □ 003_System Information Form

Condition- □ UnionPay E-Commerce Service Maintenance Form

al Stage

Note:
Issuer should receive all these documents and application forms during each stage.
The highlighted documents must be careful written and respond by Issuer.
In the stage 8, the UnionPay E-Commerce service maintenance form is just used for the
production function modification.
6.3 Testing Procedures
6.3.1 Key information
There is only one stage for E-Commerce program test: Online testing
Generally the issuers need to apply for testing 5-10 days before the plan date. Then Un-
ionPay will assign the person and the starting date to the issuers according to the resources.
Testing time is regulated to the regular working day in China.
Testing cycle depends on different issuer testing condition. The regular value is 5 – 15
working days.
After completing the testing, UPI would provide a testing report.

28
 UnionPay Card E-Commerce Implementation Guide for Issuer

Issuer must confirm the consistence between the testing system and launching system.
6.3.2 Procedures for testing

Acquirer UnionPay

Make a testing a plan and provide

Submit the application form
the required testing information

Perform testing

Study the report and prepare

Provide a testing report
system launch

Step 1:
Issuer: submit the testing application form and testing cards.
UPI: prepare a testing plan.
Step 2:
UPI: perform the test according the material provided by Issuer.
Issuer: support UPI during the whole testing process
Step 3:
UPI: provide an official testing report to Acquirer.
Issuer: Study the testing report, confirm the whole testing objectives are achieved and
then prepare the system launch application form.

29
 UnionPay Card E-Commerce Implementation Guide for Issuer

7 Annex

Annex 1 IFDYYMMDD01ICOM: General single message transaction settlement detail of

organizations as issuers
Fields are separated by blank space; records are separated by new lines. Includes card is-
suer transactions of all card BINs and all transaction currency types.

Sample Reference:

General single message transaction settlement detail of organizations as issuers (Sample

data are structured packets, with boxes representing spaces)

No. Description Field Type Sample

No. Length

1 Acquirer’s IIN 32 ans11 47990344□□□□

2 Sender’s IIN 33 ans11 00010344□□□□

3 System Trace 11 n6 040031□

No.

4 Transaction 7 n10 1127135705□

Transmission
time

5 PAN 2 n19 9559980111111111111□(Note: Card number)

6 Transaction 4 n12 000000001111□(Note: Amount is RMB 11.11)

Volume

7 Message Type n4 0200□ (Note: 0200 is purchase or pre-authorization

completion transaction; 0220 is refund transaction)

8 Transaction 3 n6 010000□
Type Code

9 Merchant Type 18 n4 6011□

10 Terminal Code 41 ans8 12840001□

11 Acquirer’s iden- 42 ans15 001584053111254□(Note: Merchant Code)

tification code

12 Name and Ad- 43 ans40 CHNHKWZQSHASHA COSMETIC

dress of Accep- SHOP□□□□□□□□□□□□□(Note: Merchant Name)
tor

13 Retrieval Num- 37 an12 470203040030□

ber

14 Point of Service 25 n2 02□

Condition Code

15 Authorization 38 an6 □□□□□□□

30
 UnionPay Card E-Commerce Implementation Guide for Issuer

Response code

16 Receiver’s IIN 100 ans11 01030000□□□□

17 System trace 90.2 n6 000000□

number of the
original txn

18 Transaction 39 an2 00□

Response Code

19 Transaction 49 an3 344□

Currency

20 Point of Service 22 n3 011□ (Note: 011 PIN-enabled CNP transaction,

Entry Mode 012 no PIN CNP transaction)

21 Settlement Cur- 50 n3 344□

rency

22 Settlement 5 n12 000000001111 （Note: the transaction volume is

Volume 11.11 Yuan）

23 Settlement Ex- 9 n8 00000001（Note: the decimal number is represented

change Rate by the first number from the left. The 2nd to the 8th
number is the value of the exchange rate, which is
assumed as 1）

24 Settlement Date 15 n4 1012□

25 Conversion Date 16 n4 1012□

26 Currency of card 51 an3 156□

holder account

27 Debit amount of 6 n12 000000002222□ (Note: Amount is RMB 22.22，use

Card holder actual card issuer debit as reference)
account

28 Debit exchange 10 n8 10000020□ (Note: this sample exchange rate is

rate of Card 2.0)
holder account

29 Receivable Ser- n12 000000000400（Note: Members Related shall re-

vice Fee ceive 4 HKD as service fee）

30 Payable Service n12 000000000400（Note: Members Related shall pay 4

Fee HKD as service fee）

31 Interchange fee X+n11 D00000000000 （ Note: The interchange fee that

Members shall pay to UPI or vice versa, currently
not implemented）

32 Currency of an3 156□ (Note: currently not charged)

transaction fee

33 Exchange rate of n8 00000000□ (Note: currently not charged)

transaction fee

34 Transaction fee X+n11 D00000000000□

31
 UnionPay Card E-Commerce Implementation Guide for Issuer

of card holder

35 Transaction Fee an3 344□

Currency For E-commerce transactions, this field equals set-
tlement currency；

36 Transaction Fee n8 30001000□

Exchange Rate For transaction fees that are collected by percent-
age(like POS transactions), , Currency conversion is
not necessary because the currency of transaction
fee is the same as that of settlement currency. This
field should be set to the fixed value ‘30001000’.
For fixed amount transaction fee(e.g ATM trans-
actions), transaction fee should be converted to the
settlement currency from the currency of inter-
change fee. The field should be the exchange rate
from currency of interchange fee to settlement cur-
rency, e.g. exchange rate for USD/RMB is 8.011,
the value of the field should be 30008011.

37 Reserved ans30 Refer to below note A.

Note A: The format of field “Reserved” is aaabcftgggiimmddhhmmssexxyyzss followed by enter-shift

sign:
1. “aaa” stands for card sequence number of Field 23; if field 23 is not submitted by the acquirer,
CUPS will automatically filled it with default value 000. Issuers shall be able to proceed correctly.
E-commerce transaction is □□□；
2. “b” stands for terminal read capability of Field 60.2.2; E-commerce transaction is □；
3. “c” stands for IC card’s condition code of Field 60.2.3, E-commerce transaction is □；
4. “f” stands for card level of Field 60.3.9
5. “t” is the identifier of stand-in authorization transaction: “Y” indicates it is a stand-in authorization
transaction; Blank space indicates it is a non-stand-in authorization transaction. It is only valid for the
Issuer and can be filled by a space by the Acquirer;
6. “ggg” stands for the country code, i.e, value of Field 19;
7. “ii” stands for fee standard, it is for issuers to calculate and check service fee
8. mmddhhmmss” stands for original transaction time, if there is no original transaction,it is filled
with 10 blanks.
9. “e” is transaction initiation method, the same as definition of F 60.3.5
10. “xx” stands for transaction channel; E-commerce transaction is 07
11. “yy” stands for E-commerce transaction ECI，09(Authentication mode) ,10 (Non-authentication
mode),00(CNP transaction) or 03(eBank Transaction)；
12. “z” is the identifier for domestically accepted or internationally accepted: “F” indicates it is an inter-
nationally accepted transaction; and “M” indicates it is a domestically accepted transaction. It is only valid
for the Issuer and can filled by a space by the Acquirer.
13. “ss” stands for installment payment terms. For example, “06” stands for six terms, and space stands
for non-installment payment transaction.
Note: For advice transaction, CUPS will uniformly fill with “00” and conduct settlement no matter
whether it is a reject response or no response. Members shall conduct settlement according to the data
provided by CUPS.
Fee Standard
Description Corresponding Region Code
Code
General cases, no special
00
region
Hong Kong and Macau Region Code (Refer to HK
Hong Kong and Macau
01 and Macau Region parameter configuration for de-
Region
tails)
Singapore Code (Refer to Singapore parameter con-
02 Singapore
figuration for details)
.. Reserved for future use Reserved for future use
ZZ Reserved for future use Reserved for future use

32
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 2 IFDYYMMDD01IERR: Dispute Trailer

Sample Reference:
Includes Issuer dispute transactions of all card BIN and all currency types, specific for-
mat as follows:

Card issuer error flow format

No. Description Field Type/Length

1 Acquirer’s IIN 32 ans11

2 Sender’s IIN 33 ans11

3 System Trace No. 11 n6

4 Transaction Transmission time 7 n10

5 PAN 2 n19

6 Transaction Volume 4 n12

7 Message Type n4

8 Transaction Type Code 3 n6

9 Merchant Type 18 n4

10 Terminal Code 41 Ans8

11 Acquirer’s identification code 42 Ans15

12 Name and Address of Acceptor 43 Ans40

13 Retrieval Number 37 an12

14 Point of Service Condition Code 25 n2

15 Authorization Response code 38 an6

16 Receiver’s IIN 100 n11

17 System trace number of the original transaction 90.2 n6

18 Transaction Response Code 39 an2

19 Transaction Currency 49 an3

20 Point of Service Entry Mode 22 n3

21 Settlement Currency 50 n3

22 Settlement Volume 5 n12

23 Settlement Exchange Rate 9 n8

33
 UnionPay Card E-Commerce Implementation Guide for Issuer

24 Settlement Date 15 n4

25 Conversion Date 16 n4

26 Currency of card holder account 51 an3

27 Debit amount of Card holder account 6 n12

28 Debit exchange rate of Card holder account 10 n8

29 Receivable Service Fee n12

30 Payable Service Fee n12

31 Interchange fee X+n11

32 Transaction fee of card holder 28 X+n11

33 Original transaction date time 90.3 n10

34 Original transaction processing code 3 n6

35 Reserved for use Ans30

Note: The format of field (Reserved for use) for the Acquirer is AAABCGGGFHII□□□□□□□
□□□□DEEEESS followed by enter-shift sign; The format of field (Reserved for use) for the Issuer is
ZAAABCGGGFHII□□□□□□□□□□DEEEESS followed by enter-shift sign.
In the above format,
（1） “Z” is for the identifier of the transaction being domestically acquired or internationally
acquired, “F” means the transaction is cross-border acquired, and “M” means the transaction is
domestically acquired
（2） “AAA” stands for card sequence number of Field 23; if the acquirer did not submit
Field 23, CUPS will fill F23 with 000 in settlement. Issuer shall be able to proceed properly.
（3） “B” stands for terminal read capability of Field 60.2.2;
（4） ) “C” stands for IC card’s condition code of Field 60.2.3;
（5） “GGG “stands for Country code of the merchant, it is the value of Field 19;
（6） “F” stands for transaction initiation method, value of Field 60.3.5
（7） “H” stands for card level, value of F60.3.9
（8） “II” stands for fee standard for issuers to calculate or check.;
（9） “D” is the identifier of dispute resolution initiator, indicating who initiates the dispute
resolution transaction. The definitions are as follows:
Space-Not defined;
1-nitiated by UPI
2-nitiated by the Member
（10） “EEEE” stands for dispute resolution reason code;
“SS” stands for installment payment terms. For example, “06” means six terms, “12” means twelve
terms and a space means it is a none-installment payment transaction.

34
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 3 IFCYYMMDD99C: General Dual-message settlement detail of organiza- tions

as issuers
This document is used for providing transaction details to Issuers that use a dual message
settlement model.
File header record, file body record and file tailer record should be separated by en- ter-
shift symbol ‘0x0D0A.
File header record
For the specific format please see the "UnionPay Bank Card Interoperability Technology
Guidelines V2.0" document, part 3 - ‘File Interface Guideline TC000’.
File body
For the Specific format please see "Technical Specifications on Bankcard Interoperabil-
ity V2.1" part III File Interface Guideline TC100, 101. TC100 is for settlement transaction,
TC101 is for refund transaction.
File tailer record
For the specific format please see "Technical Specifications on Bankcard Interoperability
V2.1" document, part III File Interface TC001.

Sample Reference:

35
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 4 IFCYYMMDD99S: Transaction statistics file of organizations as issuers

This document is used for providing net amount and category totals to Issuers that use a
dual message settlement model.
File header record, file body record and file tailer record should be separated by en- ter-
shift symbol ‘0x0D0A.
File header record
For the specific format please see the "UnionPay Bank Card Interoperability Technology
Guidelines V2.0" document, part 3 - ‘File Interface Guideline TC000’.
File body
For the Specific format please see "Technical Specifications on Bankcard Interoperability
V2.1”, part III File Interface Guideline TC900, 901.
File tailer record
For the specific format please see "Technical Specifications on Bankcard Interoperability
V2.1" document, part III File Interface Guideline TC001.

Sample Reference:

36
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 5 IFRYYMMDD01C603DZ-<Transaction Currency>-<Settlement Currency>: UPI

Institution Net Settlement Summary
Report usage: summary of transactions that have been completed by the bank.
Output Cycle: Daily
Categorization By: Issuer Code, Transaction Currency, Settlement Currency E-
Commerce transaction display "POS" column

Reference Sample:
Sample:

37
UnionPay Card E-Commerce Implementation Guide for Issuer

38
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 6 IFRYYMMDD01C605DZ: Institution Dispute Resolution Detail

Output Cycle: Daily
Categorization By: Issuer Code, Original Currency Code

Reference Sample:
Sample:

39
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 7 FD<YYMMDD>01IFEEDTL: UPI Institution Fee Settlement File

Note: UnionPay International (UPI) Institution Fee Settlement File provides detailed and
more accurate fee settlement file to members. For the purpose of reconciliation and calcula-
tion, the computational accuracy is changed from the minimum accuracy of the currency to
1/10000 of the minimum accuracy of the currency.
Output Cycle: Daily
Categorization By: Issuer Code, Original Currency Code
File Format:
Ind. Description Field Length Value
NO.
1 Acquiring Institution 32 ans11
Identification Number
2 Forwarding Institution 33 ans11
Identification Number
3 System Trace Audit 11 n6
Number
4 Transmission Date/Time 7 n10
5 Primary Account Num- 2 n19
ber (PAN)
6 Card Acceptor Identifi- 42 ans15
cation Code
7 Authorization Identifi- 38 an6
cation Response
8 Reversal Identification n1 0: None Reversal
1: Reversal
9 Transaction Type Iden- n1 0: Online Transaction
tification 1: Batch File Transaction
2: Dispute
10 Receiving Institution 100 ans11
Identification Number
11 Issuing Institution Iden- ans11
tification Number
12 Currency Code, Settle- 50 n3
ment
13 Total Fee ID an4 TFEE
14 Total Fee Debit/Credit a1 C: Credit; D: Debit.
Identification

15 Total Fee Amount n16 Round Number. Padded with 0 on the

front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
16 Total Reimbursement an4 TRMB
Fee ID
17 Total Reimbursement a1 C: Credit; D: Debit.
Fee Debit/Credit Identi-
fication
18 Total Reimbursement n16 Round Number. Padded with 0 on the
Fee Amount front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
19 Total Service Fee ID an4 TSVC
20 Total Service Fee Deb- a1 C: Credit; D: Debit.
it/Credit Identification
21 Total Service Fee n16 Round Number. Padded with 0 on the
Amount front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
22 Reserved Field ans50 Reserved Field

40
 UnionPay Card E-Commerce Implementation Guide for Issuer

23 Number of Detailed Fee n3 This record contains the number of the

Field detailed fee field, which is determined by
the actual fees involved in certain transac-
tion. The number of fee field might vary
according to transaction type.
Detailed Fee 1 Deb- a1 C: Credit; D: Debit.
it/Credit Identification
Detailed Fee 1 Amount n16 Round Number. Padded with 0 on the
front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
Detailed Fee 2 ID an4 Please refer to file instruction 3.

Detailed Fee 2 Deb- a1 C: Credit; D: Debit.

it/Credit Identification
Detailed Fee 2 Amount n16 Round Number. Padded with 0 on the
front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
......

Detailed Fee n ID an4 Please refer to file instruction 3.

Detailed Fee n Deb- a1 C: Credit; D: Debit.
it/Credit Identification
Detailed Fee n Amount n16 Round Number. Padded with 0 on the
front. The computational accuracy is
1/10000 of the minimum computational
accuracy of the currency.
File Instruction:
The settlement file is consisted of several records. Each record corresponds to a certain transaction with
(0x0D，0x0A) as the record separator; The transaction with fee calculation, such as: purchase, cash with-
draw, balance inquiry, online payment, remittance, refund, MOTO, recurring, dispute, etc., is delivered into
this file; Cancellation, reversal, etc., is not delivered to this file unless special requirements from institutions.
The structure of the record is:
Primary transaction attribute
Settlement currency
Total fee field
Total reimbursement fee field
Number of detailed fee
Detailed fee 1 field
Detailed fee 2 field
……
Detailed fee n field;
The structure of each fee field is:
Fee ID
Fee Credit/Debit identification
Fee amount;
The number of detailed fee depends on the actual number of fee that the transaction involved. Therefore, the
length for each record is not fixed.
3. The fee ID is the indicator of the fee types and is designated by UPI.
Total Fee, total reimbursement fee and total service fee ID are:
Total Fee: TFEE
Total reimbursement fee: TIRF
Total service fee: TSVC
Detailed reimbursement fee ID is numbered as R001, R002, R003 ……;
Detailed service fee ID is numbered as S001, S002, S003 ……;
Default reimbursement fee and default service fee are part of detailed fee, default reimbursement fee ID is
R001, Default service fee ID is S001.
4. Transaction records are not sorted in file.

41
 UnionPay Card E-Commerce Implementation Guide for Issuer

Annex 8 IFR<YYMMDD>01C602DZ-<”Transaction Currency”>-<”Settlement Cur-

rency”>: UPI Institution Settlement (UIS) Report.
Note:
For E-Commerce transaction, authorization service fee and authentication service fee will
be combined into the column service fee in the UIS report.
E-Commerce transaction display " E Commerce " Column.
Report Header
The report header includes the following information:
IIN(Institution identification number).
Institution Name.
Transaction Settlement Date.
Settlement Date.
Transaction Currency.
Settlement Currency.
Daily Sub-reports
UIS reports includes three daily sub-reports:
C602-DZ-001 UPI Institution Settlement Summary Report (Daily Report) C602-DZ-
002 UPI Institution Settlement Fee Report (Daily Report)
C602-DZ-003 UPI Institution Settlement Dispute Fee Report (Daily Report)
These reports include all fees that are that are settled in a given settlement service. Fees
are reported by the following categories:
Business mode
Business transaction type
Report ID Report Title Report Description
C602-DZ-001 UPI Institution Settlement Provides summarized totals of
Summary Report (Daily Re- the settlement amount,
port) reimbursement fee,
service fee,
total fee
and net settlement amount. Debit
amount, credit amount and total
amount is given.
C602-DZ-002 UPI Institution Settlement Fee Provide count,
Report (Daily Report) transaction amount,
settlement amount,
reimbursement fees,
service fees
and net settlement amount
information summarized by
business transaction type.
C602-DZ-003 UPI Institution Settlement Provide count,
Dispute Fee Report (Daily Re- transaction amount,
port) settlement amount,
reimbursement fees,

42
 UnionPay Card E-Commerce Implementation Guide for Issuer

service fees
and net settlement amount
information summarized by dis-
pute transaction type.

Reference Sample:

Examples:
The following report samples are examples of UIS report for a single institution with a
certain currency association. In the example, the numbered fields on the report correspond to
the numbered field on the UIS report.
Header:

C602-DZ-001

C602-DZ-002

C602-DZ-003

43
UnionPay Card E-Commerce Implementation Guide for Issuer

44