J/Secure™2.

0 Acquirer
Implementation Guide

Ver.1.2
 J/Secure™ 2.0 Acquirer Implementation Guide

2018 JCB Co., Ltd., All rights reserved.

All rights relating to this document belong to JCB Co., Ltd. (hereinafter referred to as “JCB”).
This document contains JCB’s confidential and proprietary information, patents, copyrights,
trademark rights, trade secrets, know-how and other intellectual property or other rights. To
use any part of this document (whether formatted as text, images or in any other way) by
any method (including but not limited to browsing and downloading), you (“the reader”) must
agree to all of the items published herein.

The reader must not copy, distribute, assign, lend, post, publish, disclose or modify
(including translating) any part or all of this document to or for any third party, by any means
whatsoever, except as permitted in advance by JCB.

This document may contain third-party information, patents, copyrights, trademark rights,
trade secrets, know-how and other intellectual property or other rights. JCB does not
guarantee this document or any part thereof to be free of infringement of third-party
information, patent rights, copyrights, trademark rights, trade secrets, know-how, or any
other intellectual property or rights (either explicitly or implicitly). In using this document, it is
the reader’s responsibility to decide whether it is necessary to purchase or license such
rights from a third party. JCB shall not be held liable for infringements of a third party’s
intellectual property or other rights by the reader or any other party.

Although we strive to ensure that this document is accurate and up-to-date, JCB makes no
explicit or implicit warranty as to the accuracy or completeness of this document. Also, JCB
assumes no responsibility for any products or services developed or produced in
accordance with this document. JCB assumes no responsibility for errors or omissions in
this document.

To the extent permitted by law, JCB, its directors, employees, affiliates, business partners,
agents, and other representatives shall assume no responsibility for any direct or indirect
damages (including damages incurred by third parties) arising from the use or inability to
use this document, even if JCB has been notified of the possibility of such damages.

JCB Confidential
 J/Secure™ 2.0 Acquirer Implementation Guide

J/Secure™2.0 Acquirer Implementation Guide

Revision History
No Version Revision Date Chapter Revision Contents

1 1.0 2018/6 All First Edition

2 1.0 2018/11 All Typo errors are corrected
3 1.1 2018/11 7 Modify Chargeback Rules Revision Schedule
4 1.1 2018/11 Appendix B Updated
Table 7-1 Modified ‘After April 1 2020’ to ‘From April 1 2020’
5 1.2 2019/2
Appendix B
Added ECI value in parentheses before starting to
6 1.2 2019/2 Table 5-5
apply liability rules
7 1.2 2019/2 Appendix A Updated Acquirer Implementation Form
8
9
10

JCB Confidential
 J/Secure™ 2.0 Acquirer Implementation Guide

Table of Contents
1 Introduction ................................................................................................................... 1
1.1 Objective ..................................................................................................................1
1.2 Intended Readers ....................................................................................................1
1.3 Prerequisites of this Document.............................................................................1
1.4 Structure of this Document ...................................................................................1
1.5 Revisions of this Document ..................................................................................2
1.6 Related Documents ................................................................................................2
1.6.1 EMV 3DS Documents ...........................................................................................2
1.6.2 JCB Documents ....................................................................................................2
1.7 Definitions................................................................................................................2
2 J/Secure2.0 Overview ................................................................................................... 3
2.1 Overview ..................................................................................................................3
2.2 Objectives ................................................................................................................3
2.3 Participants and Responsibilities .........................................................................4
2.4 Structure ..................................................................................................................5
2.4.1 System Overview ..................................................................................................5
2-4-2 System Arrangement Diagram ...............................................................................6
2-5. Authentication Flow ...................................................................................................7
2-5-1 Authentication Flow (Frictionless Flow) ..................................................................7
2-5-2 Authentication Flow (Challenge Flow) ....................................................................8
3. Acquirer Implementation and Operation process ..................................................... 9
4. Consideration on Planning Phase............................................................................. 10
4.1 Decision of Implementation Method ........................................................................10
4.1.1 Implementation Options ............................................................................................10
4.1.2 3DS Server Selection ...............................................................................................10
4.1.3 Revision of Merchant Agreement .............................................................................10
5 Implementation Phase .................................................................................................11
5.1 Application to JCB ................................................................................................ 11
5.2 Initialization of 3DS Server .................................................................................. 11
5.2.1 Information required ............................................................................................ 11
5.2.2 Setting of 3DS Server Operator ID ..................................................................... 11
5.2.3 3DS Server Reference Number .......................................................................... 11
5.3 Initialization of 3DS SDK ...................................................................................... 11
5.4 Installation of Encryption Keys and Certificates...............................................12
5.4.1 Installation on the 3DS Server ............................................................................12
5.4.2 Installation to the 3DS SDK.................................................................................12
5.5 Authorization System Upgrade ...........................................................................13
5.5.1 Authorization Message Items ..............................................................................13
5.6 Merchant Implementation ....................................................................................13
5.6.1 Obtainment of Acquirer BIN and 3DS Server Operator ID .................................13
5.6.2 Registration of Information with DS ....................................................................13
5.6.3 Setting of Acquirer Merchant ID ..........................................................................13
5.6.4 Setting of 3DS Requestor ID ...............................................................................13
5.6.5 Display of JCB Logo ............................................................................................13
5.7 Transaction Processing Requirements ..................................................................... 14
5.7.1 Risk-based Authentication Results ...........................................................................14
5.7.2 Challenge Authentication Results .............................................................................15

JCB Confidential
 J/Secure™ 2.0 Acquirer Implementation Guide

5.7.3 Processing Requirements When J/Secure1.0 and 2.0 coexist ................................15

5.7.4 Authorization Processing ..........................................................................................15
5.7.4.1 Authorization Request message ............................................................................15
5.7.4.2 Exception for Authorization Request .....................................................................16
5.7.5 Sales data inclusion requirements ...........................................................................16
6 Testing .......................................................................................................................... 17
6.1 Confidence Test ....................................................................................................17
6.2 Certification Test (Online and Batch) .................................................................17
7. Operation Phase .......................................................................................................... 18
7.1 Liability Rules.............................................................................................................18
7.1.1 Overview of Liability Rules ....................................................................................18
7.1.2 Application of liability rules ....................................................................................18
7.1.3 Operational Flow ...................................................................................................18
7.1.4 Log Storage ..............................................................................................................19
7.2 Security Requirements ................................................................................................ 19
7.2.1 PCI 3DS SDK Security Requirements ..................................................................19
7.2.2 Key Security Requirements ......................................................................................19
7.2.2.1 Prerequisites ..........................................................................................................19
7.2.2.2 Fundamental Rules of Management .....................................................................19
7.2.2.3 Key Compromise ...................................................................................................20
7.2.2.4 Back-up ..................................................................................................................20
7.2.2.5 Security Requirements to a Third Party ................................................................20
7.2.3 Policy for Handling Data Collected by Acquirer ........................................................20
Appendix A Form ............................................................................................................. 21
Appendix B ECI mapping ................................................................................................ 24

JCB Confidential
 J/Secure™ 2.0 Acquirer Implementation Guide
1. Introduction

1 Introduction
This chapter describes the objectives, the intended readers, prerequisites, structure, revisions
and related materials of this document.
The term “JCB” used in this document refers to “JCB as the brand holder” unless otherwise
specified.

1.1 Objective
The purpose of this document is to convey the necessary requirements, operations and
guidelines involved when an Acquirer implements J/Secure2.0.

1.2 Intended Readers

This document is intended Acquirers of JCB International (hereinafter, Acquirer).

1.3 Prerequisites of this Document

J/Secure2.0 is JCB’s Cardholder authentication program conforming to the EMV® 3-D Secure
Protocol and Core Functions Specification ( hereinafter, EMV 3DS). J/Secure1.0 is JCB’s
Cardholder authentication program conforming to 3-D Secure1.0.2. Since J/Secure1.0 and
J/Secure2.0 are different, incompatible technical specifications, they shall be operated as
separate programs.
Official Service name for customers shall be used “J/Secure” regardless of J/Secuer1.0 or
J/Secure2.0.
The contents of this document cover the minimum necessary requirements, operations and
guidelines for J/Secure2.0 implementation by the Acquirer/Merchant.
The Acquirer is responsible for confirming that the Merchant satisfies the requirements specified
in this document.
Regarding matters other than the mandatory requirements, the Acquirer shall consider the
burden, including operational and financial burden as well as burden laid upon the Acquirer or
Merchant system, and make decisions based on its own judgment.
Also, it shall be acknowledged that all the contents of this document may not necessarily be
executed, depending on the product that the Acquirer uses.

1.4 Structure of this Document

This section presents an overview of each chapter.

Chapter 1: Introduction
This chapter describes the objectives, the intended readers, prerequisites, structure,
revisions and related materials of this document.

Chapter 2: J/Secure2.0 Overview

This chapter describes an overview of J/Secure2.0, its objectives and the
responsibilities of each party involved.

Chapter 3: Acquirer Implementation and Operation process

This chapter describes the adoption of J/Secure2.0, the process and an outline of the
tasks performed by the Acquirer before starting J/Secure2.0 service.

Chapter 4: Consideration on Planning Phase

JCB Confidential
1
 J/Secure™ 2.0 Acquirer Implementation Guide
1. Introduction

This chapter describes items that the Acquirer shall consider before implementing its
ACS.

Chapter 5: Implementation Phase

This chapter describes items that the Acquirer shall execute to implement its 3DS
Server and 3DS SDK.

Chapter 6: Testing
This chapter describes each test for J/Secure2.0 implementation.

Chapter 7: Operation Phase

This chapter describes Chargeback rules for J/Secure2.0 transactions and the
security requirements.

1.5 Revisions of this Document

JCB may revise this document as necessary. When this document is revised and distributed, the
Acquirer shall follow the contents of the revised version.

1.6 Related Documents

Documents related to this document are shown below.

1.6.1 EMV 3DS Documents

(1) EMV® 3-D Secure Protocol and Core Functions Specification (EMV 3DS)
(2) EMV® 3-D Secure SDK Specification
(3) EMV® 3-D Secure SDK Device Information
(4) EMV® 3-D Secure SDK Technical Guide
(5) Payment Card Industry 3-D Secure (PCI 3DS) - Security Requirements and
Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS,
and 3DS Server （”PCI 3DS Core”）
(6) Payment Card Industry 3-D Secure (PCI 3DS) - Security Requirements and
Assessment Procedures for EMV®3-D Secure SDK （”PCI 3DS SDK”）

1.6.2 JCB Documents

(1) J/Secure™ 2.0 ACS Functional Requirements
(2) J/Secure™ 2.0 3DS Server Functional Requirements
(3) J/Secure™ 2.0 3DS SDK Functional Requirements
(4) J/Secure™ 2.0 CA Interface Guide
(5) JCB Regulatory Publications
(6) J/Secure™ 2.0 Confidence Test Procedures（for Merchants）
(7) J/Secure™ 2.0 DS File Registration Procedures
(8) J/Secure™ 2.0 Merchant Information Maintenance Guide

1.7 Definitions
Definitions of the terms “shall”, “should”, and “may” used in this document are following.
(1) “shall” indicates that fulfilling requirements is mandatory.
(2) “should” indicates that fulfilling requirements is strongly recommended.
(3) “may” indicates that fulfilling requirements is optional.

Unless otherwise defined in this document, the definitions of terms shall conform to the EMV
3DS.

JCB Confidential
2
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2 J/Secure2.0 Overview
This chapter presents an overview of J/Secure2.0, its objectives, and the responsibilities of each
party involved.

2.1 Overview
J/Secure2.0 is JCB’s Cardholder authentication program compliant with the EMV 3DS technical
specification, which is the next generation of 3-D Secure specification. The features of
J/Secure2.0 are as follows:

➢ Frictionless Authentications
By performing risk-based authentication using information about the purchase and the
Merchant together with other details such as the device being used by the Cardholder, the
authentication of the majority of transactions is accomplished without the Cardholder having
to input information such as a password. This makes it possible to avoid situations such as
Cardholder withdrawing from transactions as a result of forgetting password.

➢ Applicable to In-App Payment

Since it can be used in applications as well as web browsers, the service is available on a
wide variety of devices.

➢ Applicable to Non-Payment Authentication

This service can be used not only for payments, but also for authentication in non-payment
fields such as registering cards in digital wallets.

2.2 Objectives
J/Secure2.0 serves four objectives, which are as follows:

➢ Fraudulent Usage Prevention for E-Commerce Transactions

By implementing Cardholder authentication for e-commerce transactions, the risk of
fraudulent usage is reduced. In transactions as specified in Section 7-1, the Issuer cannot
perform Chargeback to the Acquirer.

➢ Reduction of Chargeback Operations

It is expected that the lower overall incidence of fraudulent transactions will mean there are
fewer Chargeback, thus resulting in lower operating costs.

➢ Growth of Sales with Cards Used for E-Commerce Transactions

By implementing e-commerce transactions smoothly and securely, this service can avoid
withdrawal of Cardholder from transactions and fraudulent usage such as identity fraud,
leading to the growth of e-commerce sales.

➢ Improvement of Service for Cardholder

By providing Cardholder with a secure means of payment, it is possible for them to improve
their services.

JCB Confidential
3
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2.3 Participants and Responsibilities

Table 2-1 lists the participants in J/Secure2.0 and their main responsibilities.

Table 2-1: J/Secure Participants and Their Main Responsibilities

Participant Main responsibilities
JCB Maintenance of J/Secure2.0 scheme and operation
Construction and operation of DS
Execution of J/Secure2.0 Implementation Test for Issuers and
Acquirers
Operation of J/Secure CA
J/Secure CA Issuance of certificates
EMVCo Management and update of the EMV 3DS specifications
Certification of each system (DS, ACS, 3DS Server, 3DS SDK)
Issuer Usage and operation of ACS
Preparation/management of authentication keys, signing request
to J/Secure CA
Registration and maintenance of necessary information on DS
Cardholder authentication by risk-based authentication and
challenge authentication
Reception of J/Secure Cardholder authentication results via
Authorization Request messages, and CAVV verification
Service delivery to Cardholders, and acquisition of consent
Cardholder Usage of J/Secure2.0
Acquirer Promotion of J/Secure implementation to Merchants
Registration/maintenance of necessary information on DS
Addition of J/Secure Cardholder authentication results to
Authorization Request messages
Merchant Usage and operation of 3DS Server
Configuration of 3DS Server with necessary information
Display of J/Secure acceptance on Merchant web site/apps
Addition of J/Secure Cardholder authentication results to
Authorization Request messages
Vendor Development, delivery and maintenance of products for the
implementation of J/Secure transactions (ACS, 3DS Server, 3DS
SDK)

JCB Confidential
4
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2.4 Structure
2.4.1 System Overview
Table 2-2 shows an overview of the system necessary for implementing J/Secure2.0.

Table 2-2: System Overview

Domain Entity Description
Issuer Domain ACS Server/software that performs Cardholder
authentication, operated by Issuer or trusted
third party
Acquirer Domain 3DS Requestor Entities that initiate 3DS, such as Merchant
and digital wallets.
3DS Server Software that the 3DS Requestor needs to
support J/Secure.
3DS Client Browsers or apps that interface with
Cardholder for the purpose of communication
between 3DS Requestor, ACS and Cardholder.
3DS SDK In cases where the 3DS client is an app, 3DS
SDK is embedded in the app and
communicates with the ACS.
Interoperability DS Servers operated by JCB that are responsible
Domain for relaying communication between ACS and
3DS Server.
Commercial CA A certification authority operated by a third
party that issues selected certificates required
by J/Secure.
J/Secure CA A certification authority operated by JCB that
issues selected certificates required by
J/Secure.

JCB Confidential
5
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2-4-2 System Arrangement Diagram

Fig. 2-1 shows system arrangement diagram of J/Secure2.0.

Fig. 2-1 System Arrangement Diagram

Issuer Domain Interoperability Acquirer Domain

Domain
JCB Cardholder 3DS Requestor
(Merchant)
3DS Cliant
App 3DS SDK
3DS Server
Browser

DS

Payment
J/Secure CA
Request
ACS
Commercial CA

JCB
Issuer Host (Authorization Acquirer Host
system)

JCB Confidential
6
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2-5. Authentication Flow

2-5-1 Authentication Flow (Frictionless Flow)
The frictionless flow in J/Secure2.0 is shown in Fig. 2-2 and Table 2-3.

Fig. 2-2: Frictionless Flow

Table 2-3: Purchase Steps in Frictionless Flow

Step

(1) Cardholder follows the purchase procedure using the Merchant web site or app.

(2) The 3DS Server sends an AReq message to DS, and DS sends it to ACS.

(3) The ACS performs authentication based on the contents of the AReq message.

The ACS sends the authentication results as an ARes message to the DS, and DS sends
(4)
it to the 3DS Server.

The 3DS Requestor adds the authentication results to the authorization and sends it to
(5)
the Acquirer.

The Acquirer sends an authorization message, and the results of the authorization
(6)
processing by the Issuer are sent back to the 3DS Requestor via the Acquirer.
* Steps (5) and (6) may be omitted if the 3DS Requestor is not a merchant, or if the service
is used for non-payment purpose.

JCB Confidential
7
 J/Secure™ 2.0 Acquirer Implementation Guide
2. J/Secure2.0 Overview

2-5-2 Authentication Flow (Challenge Flow)

The J/Secure2.0 challenge flow is shown in Fig. 2-3 and Table 2-4.

Fig. 2-3: Challenge Flow

Table 2-4: Purchase Steps in Challenge Flow

Step
At the previous step (4), when the result of the ARes authentication is “Challenge
(0)
Required”, proceed to the following steps.

(1) The 3DS SDK or the web browser sends a CReq message to ACS.

For App: Information necessary for the screen display is sent as a CRes message from
(2)
the ACS to the 3DS SDK.

The 3DS SDK or the web browser displays a form where Cardholder can input
(3)
information necessary for authentication, and the Cardholder completes this form.

(4) The ACS performs authentication based on the information entered by the Cardholder.

The ACS sends the authentication results to DS as an RReq message, and the DS sends
(5)
it to the 3DS Server.

The 3DS Requestor adds the authentication results to the authorization and sends it to
(6)
the Acquirer.

The Acquirer sends an authorization message, and the results of the authorization
(7)
processing by the Issuer are sent back to the 3DS Requestor via the Acquirer.

(8) The 3DS Server sends the result received via RReq to DS as an RRes message.

* Step (8) may be performed at any time after step (5).

* After step (8), the ACS sends a Final CRes to the 3DS SDK or the browser.

JCB Confidential
8
 J/Secure™ 2.0 Acquirer Implementation Guide
3. Acquirer Implementation and Operation process

3. Acquirer Implementation and Operation process

This chapter describes the adoption of J/Secure2.0, the process and an outline of the tasks
performed by the Issuer before starting J/Secure2.0 service.

Fig: 3-1 Process Overview

Implemen
Planning Test Operation
tation

Table 3-1: Summary of Acquirer Tasks

Item Details Reference
Planning Decision of implementation method 4.1
Application to JCB 5.1
Initialization of the 3DS Server 5.2
Initialization of the 3DS SDK 5.3
Installation of the encryption key and
Implementation 5.4
certificates
Authorization system upgrade 5.5

Merchant implementation 5.6

Transaction processing requirements 5.7

Confidence Test 6.1

Test
Certification Test 6.2
Liability Rules 7.1
Operation
Security Requirements 7.2

JCB Confidential
9
 J/Secure™ 2.0 Acquirer Implementation Guide
4. Consideration on Planning Phase

4. Consideration on Planning Phase

This chapter describes items that the Acquirer’s shall consider before implementing.

4.1 Decision of Implementation Method

4.1.1 Implementation Options
Merchant adopting J/Secure2.0 shall implement 3DS server. As a general implementation
method, the following four options can be considered.

 The Acquirer develops its own 3DS server in-house and provides it to the
Merchant.
 The Acquirer purchases 3DS server from a vendor, implements it in-house, and
provides it to the Merchant as a hosting service.
 The Acquirer partners with a third party who provides 3DS server as a hosting
service and provides it to the Merchant.
 The Merchant selects 3DS server at its discretion.

4.1.2 3DS Server Selection

The 3DS Server shall be a product that has obtained EMVCo approval.
For a list of products approved by EMVCo, please follow this link:
EMVCo web site: https://www.emvco.com/

4.1.3 Revision of Merchant Agreement

When promoting J/Secure2.0 to the Merchants, the Acquirer shall consider the necessity for
revision of the existing Merchant Agreement, and their contents of revision.

JCB Confidential
10
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

5 Implementation Phase
This chapter describes items that the Acquirer shall execute at the implementation phase.

5.1 Application to JCB

After deciding to adopt J/Secure2.0, the Acquirer shall to submit the “Acquirer
Implementation Form for J/Secure2.0” to JCB to inform JCB of the implementation method
and schedule, etc. If the implementation method varies with the Merchant, the form shall be
submitted separately for each implementation method.
In principle, the Acquirer shall submit the form to the recipient listed below before service
begins.

<<Where to submit>>
JCB International Co. Ltd.
Network Services Headquarters
Fax to: +81-3-5778-8377

After the form has been submitted, JCB will provide the information listed below to the
Acquirer
・Acquirer BIN
・3DS Server Operator ID

5.2 Initialization of 3DS Server

5.2.1 Information required
At the beginning of service, the Acquirer shall set the static parameters of the 3DS Server as
specified in the J/Secure2.0 3DS Server Functional Requirements. It is also necessary to
determine the parameters listed below and register them to the 3DS Server.

・ 3DS Server URL

・ Cache Expiration Period

For the criteria of setting each parameter, refer to J/Secure2.0 3DS Server Functional
Requirements.

5.2.2 Setting of 3DS Server Operator ID

The Merchant shall set the 3DS Server Operator ID that is received from JCB on the 3DS
server so that DS can identify the 3DS Server.

5.2.3 3DS Server Reference Number

The 3DS Server shall be assigned a valid 3DS Server Reference Number by EMVCo .

5.3 Initialization of 3DS SDK

When implementing J/Secure2.0 on the 3DS Requestor App, the Acquirer shall install the
3DS SDK in the app. It is also necessary for the 3DS Requestor to verify that the 3DS SDK
has EMV 3DS Testing and Approval and that it has been assigned a valid SDK Reference
Number.
More information on the 3DS SDK is provided by the documents listed below.

JCB Confidential
11
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

・ EMV® 3-D Secure—SDK Specification

・ EMV® 3-D Secure SDK Technical Guide
・ EMV® 3-D Secure SDK—Device Information
・ J/Secure™ 2.0 3DS SDK Functional Requirements

5.4 Installation of Encryption Keys and Certificates

5.4.1 Installation on the 3DS Server
The Acquirer shall store the encryption keys and certificates that are required for 3DS
Server operation on the 3DS Server. The required keys are listed in Table 5-1 and the
certificates are listed in Table 5-2.

Table 5-1 Encryption keys to be stored on the 3DS Server

# Key Purpose
1 3DS Server client private key Protect the TLS channel for AReq/ARes messages
between the 3DS Server and DS
Protect the TLS channel for PReq/PRes messages
between the 3DS Server and DS
2 3DS Server private key Protect the TLS channel for RReq/RRes messages
between the DS and the 3DS Server

Table 5-2 Certificates to be stored on the 3DS Server

# Certificate Issuer Purpose
1 J/Secure CA root J/Secure Protect the TLS channel for AReq/ARes
certificate CA messages between the 3DS Server and DS
Protect the TLS channel for PReq/PRes
messages between the 3DS Server and DS
Protect the TLS channel for RReq/RRes
messages between the DS and the 3DS Server
2 3DS Server J/Secure Protect the TLS channel for AReq/ARes
client certificate CA messages between the 3DS Server and DS
Protect the TLS channel for PReq/PRes
messages between the 3DS Server and DS
3 3DS Server J/Secure Protect the TLS channel for RReq/RRes
server certificate CA messages between the DS and the 3DS Server

5.4.2 Installation to the 3DS SDK

The Acquirer shall store the certificates that are required for 3DS SDK operation in the 3DS
SDK.
The required certificates are listed in Table 5-3.

Table 5-3 Certificates to be stored in the 3DS SDK

# Certificate Issuer Purpose
1 J/Secure CA root certificate J/Secure Verify the signatures of ARes
CA messages between the 3DS SDK
and ACS
2 Commercial CA root certificate CM CA Encryption of CReq/CRes
messages between the 3DS SDK
and ACS
3 DS device information encryption J/Secure Encryption of AReq messages
certificate CA between the 3DS SDK and DS

JCB Confidential
12
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

5.5 Authorization System Upgrade

For Payment Authentication, the Acquirer sends the J/Secure2.0 authentication result
information specified in Table 5-4 to the Issuer in an Authorization message to show that
Cardholder authentication was performed for the transaction in J/Secure2.0.
The Acquirer shall upgrade their own host system so that it could include the Cardholder
authentication result information specified in Table 5-4 in the Authorization Request
message that is sent to JCB.

5.5.1 Authorization Message Items

Table 5-4

Item Explanation

A value that indicates whether or not the Issuer has performed

authentication.
ECI
For the ECI values for each authentication result, refer to the ECI
mapping.
Generated by ACS and the value set in the ARes or RReq is set in the
Authorization message.
CAVV
*Authorization messages that have no CAVV are regarded as the
transaction not being performed with J/Secure2.0.

5.6 Merchant Implementation

5.6.1 Obtainment of Acquirer BIN and 3DS Server Operator ID
The Acquirer shall inform the Merchant of the Acquirer’s BIN and the 3DS Server Operator ID.

5.6.2 Registration of Information with DS

The Acquirer shall register the required information according to the “J/Secure™ 2.0 DS File
Registration Procedures”.

5.6.3 Setting of Acquirer Merchant ID

The Acquirer shall inform the Merchant of the Acquirer Merchant ID.
It is also necessary to set the same Acquirer Merchant ID in the Authorization message so
that JCB can identify the Merchant.
Acquirer Merchant ID shall be generated by the Acquirer on the J/Secure™2.0 Merchant
Information Maintenance Web.

 For more information on J/Secure™2.0 Merchant Information Maintenance Web, refer to

“J/Secure™ 2.0 Merchant Information Maintenance Guide” .

5.6.4 Setting of 3DS Requestor ID

The Acquirer shall register the 3DS Requestor ID to the 3DS Server so that the DS can identify
the 3DS Requestor.
The 3DS Requestor ID will be automatically assigned when the acquirer registers the Acquirer
Merchant ID in J/Secure™2.0 Merchant Information Maintenance Web.
The format of 3DS Requestor ID is numbered with “Acquirer BIN + ‘MCT’ + Acquirer Merchant ID
(15 digits)”.

5.6.5 Display of JCB Logo

The Merchant shall display the logo on the Merchant website and Merchant app so as to make it

JCB Confidential
13
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

known that the Merchant has adopted J/Secure2.0. (J/Secure2.0 logo, etc.)
The Acquirer can obtain the J/Secure2.0 logo data from JCB at the URL shown below.
JCB VI Design Manual
http://www.jcb.co.jp/bdmanual/en/serviceMark/jsecure/download.htm

5.7 Transaction Processing Requirements

This chapter describes the processing requirements for J/Secure2.0 transactions.

5.7.1 Risk-based Authentication Results

On receiving an AReq message from the DS, the Issuer performs risk-based authentication in
ACS, sets the results in an ARes message, and responds to the DS. Table 5-5 shows the
risk-based authentication results from DS and the subsequent processing performed by the
Merchant who received them.

Table 5-5: Risk-based Authentication Results and Subsequent Processing

ARes
Risk-based Subsequent processing by Merchant
Transaction
authentication result (choose one)
Status value
Authentication
Y Perform Authorization Request with ECI = 05.
Successful
• 3DS Requestor generates CReq message and
sends it to ACS.
Challenge Required C • If the Merchant decides not to perform a
challenge, perform Authorization Request with
ECI=07.
Authentication Cease to the transaction, and Authorization
R
Rejected Request shall not be performed.
Authentication Could
Not Be Performed;
ACS: U
ACS does not support • The DS changes to Attempt, and perform
↓
the Cardholder device, Authorization Request with ECI=06(07) .
or technical problems DS: A
in ACS
ACS Attempt A Perform Authorization Request with ECI=06.
If Tx.Status is Y or A, the Acquirer shall send the CAVV on Authorization message.
*Set the value in parentheses before starting to apply liability rules for Attempt transactions.

JCB Confidential
14
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

5.7.2 Challenge Authentication Results

The Issuer that requests Challenge as a result of risk-based authentication and that receives the
Challenge request from the 3DS Requestor performs Cardholder authentication according to the
authentication method designated by the Issuer, and sets the result in an RReq message that is
sent back to the DS. Table 5-6 shows the challenge authentication results from the DS, and the
subsequent processing by the Merchant that receives these results.

Table 5-6: Challenge Authentication Results and Subsequent Processing

Value of
Challenge RReq Subsequent processing by Merchant
authentication results Transaction (choose one)
Status
Authentication
Y Perform Authorization Request with ECI = 05.
Successful
(In case of No ECI)
• Allow the Cardholder to choose another
Authentication Failed N payment method such as a different JCB card.
• Cease to the transaction, and Authorization
Request shall not be performed.
• Perform Authorization Request with ECI=07.
Authentication Could • Allow the Cardholder to choose another
Not Be Performed; U payment method such as a different JCB card.
Technical problems • Abandon the transaction, and do not perform
Authorization Request.
If Tx.Status is Y, the Acquirer shall send the CAVV on Authorization message.

5.7.3 Processing Requirements When J/Secure1.0 and 2.0 coexist

If the Issuer supports both J/Secure1.0 and J/Secure2.0, the Acquirer shall identify the version
supported by the Issuer with 3DS Requestor and send the suitable J/Secure message to the DS.

5.7.4 Authorization Processing

5.7.4.1 Authorization Request message
The Merchant shall use the ECI mapping described in Appendix B to decide whether or not
to proceed to authorization and send the additional authorization information specified in
Table 5-7 to the Issuer via the Acquirer and JCB.

JCB Confidential
15
 J/Secure™ 2.0 Acquirer Implementation Guide
5. Implementation Phase

Table 5-7 Authentication Results and Additional Information to Authorization messages

Jlink message: Bit48

Transaction
Authentication Results
Status
ECI

Authentication Successful Y 05
Authentication Failed N 07 *1
Authentication
U 07
Could Not Be Performed
DS attempt A 06(07) *2
ACS attempt A 06(07) *2
Authentication
R Authorization not possible
Rejected

*1 Shall not send Authorization when Challenge not successful (Exceeding maximum challenge),
Challenge cancel by the Cardholder,
*2 Set the values in parentheses before starting to apply liability rules for Attempt transactions.

5.7.4.2 Exception for Authorization Request

For the following cases, the Merchant is expected to send the Authorization Request message
without performing Cardholder authentication with J/Secure2.0 again.

➢ Split shipment
➢ Change in transaction amount due to addition/cancellation of purchased
items

In such a case, the Merchant and Acquirer again set the same ECI and CAVV to the
Authorization Request message, which they have used to the original Authorization Request
message. A valid CAVV shall be set. If these values are not set in the Authorization Request
message, the Issuer can request a chargeback.

5.7.5 Sales data inclusion requirements

When the Acquirer sends J/Secure 2.0 authentication results to sales data, the requirements
listed in Table 5-8 shall be included.
Relevant sales data items: PDE3009 EC Security Level Indicator
Tag Number 3009
Table 5-8
Value Description
05 Verified by 3-D Secure
Failed to be verified by 3-D Secure
06
(Reasons: Declined by issuer / Not supported by issuer)
07 Not verified by 3-D Secure

 For more information on sales data inclusion requirements, refer to the JRP Batch
Interface Guide.

JCB Confidential
16
 J/Secure™ 2.0 Acquirer Implementation Guide
6. Testing

6 Testing
This chapter describes each test for J/Secure2.0 implementation.

6.1 J/Secure2.0 Confidence Test

The purpose of Confidence Test is to verify that J/Secure2.0 is performed correctly with the
3DS Server or the 3DS SDK implemented in the Acquirer’s and Merchant’s environment and
the DS provided by JCB.
*The 3DS SDK test cannot be performed when only browser is used.
Test requirements for each scenario are shown in table 6-1

Table 6-1
Case Requirement
1) The Merchant has newly adopted a 3DS Server or 3DS SDK in their
own environment or there has been a major change in the 3DS Server Mandatory
implementation environment after service commencement.
2) A Merchant that has already implemented a 3DS Server newly
Mandatory
adopts a 3DS SDK.
3) A Merchant that is using a 3DS Server and 3DS SDK already
Optional
implemented with a hosting service, etc. uses a newly obtained 3DS
(recommended)
Server Operator ID.
4) A Merchant that is using a 3DS Server and 3DS SDK already
Optional
implemented with a hosting service, etc. uses a 3DS Server Operator
(recommended)
ID that is shared with a settlement agent.

6.2 Certification Test (Online and Batch)

The purpose of the Certification Test is to verify that the J/Secure2.0 Cardholder
authentication results are included with the Authorization Request message.
The Acquirer shall upgrade their own authorization system so that it is possible to include
the Cardholder authentication results in the Authorization Request message that is sent to
JCB as specified in section 5.5.
The Acquirer shall apply to JCB for the Certification Test before its system release.

JCB Confidential
17
 J/Secure™ 2.0 Acquirer Implementation Guide
7. Operation Phase

7. Operation Phase
This chapter describes Chargeback rules for J/Secure2.0 transactions and the security
requirements.

7.1 Liability Rules

This chapter describes the liability rules between the Issuer and Acquirer, Chargeback
operational flow, and log storage in the implementation of J/Secure2.0.

7.1.1 Overview of Liability Rules

When the Merchant requests J/Secure2.0 authentication and the Issuer performs the
authentication, Chargeback request to the transaction cannot be made according to
“Chargeback Reason #546 — Unauthorized Purchase” prescribed in “JCB Regulatory
Publications”.

7.1.2 Application of liability rules

If the Merchant requests J/Secure2.0 authentication and the Issuer performs the authentication,
chargeback request to the transaction cannot be made.
Also, if the Merchant requests J/Secure 2.0, and Issuer handles the transaction as unavailable to
authenticate due to that Issuer does not support, chargeback request to the transaction cannot
be made.
However, given the spread of J/Secure2.0 infrastructure and current market trends, the
effective date and target transactions that the Issuer may not chargeback is shown in Table 7-1.

Table 7-1: Chargeback Rules Revision Schedule

Applicable Term Target Transactions
From Implementation Transactions that meet all the following conditions;
To March 31 2020  Transactions that are authenticated by Issuer with
J/Secure2.0 until March 31 2020 （ECI=05）
 Transactions approved by Issuer
From April 1 2020 Transactions that meet all the following conditions;
 Transactions that are authenticated by Issuer or attempted by
Merchant with J/Secure2.0 on or after April 1 2020
(ECI=05 or 06)
 Transactions approved by Issuer that Acquirer sends the
necessary information in Authorization Request message

7.1.3 Operational Flow

For transactions prescribed in Section 7.1, Issuer shall not charge back in principle. However,
if the Acquirer receives a Chargeback notification for such a transaction, the Acquirer may
represent with conditions separately prescribed by JCB.

JCB Confidential
18
 J/Secure™ 2.0 Acquirer Implementation Guide
7. Operation Phase

Also, in the case where a Chargeback is received from the Issuer for a transaction without
performing Cardholder authentication prescribed in Section 5-7, the Acquirer shall be able to
present the record of Cardholder authentication and its relevance for the original transaction

 For details of chargeback operations, refer to “JRP Regulations”.

7.1.4 Log Storage

For the period that Chargeback can occur, the Acquirer should store the necessary data for
Chargeback such as the ARes, RReq log and Authorization Request messages, Authorization
Response messages, and sales data.
The storage period is recommended to be at least one year, but this should be decided after
carefully considering the laws, restrictions and guidelines etc. for each country and region from
various perspectives.

7.2 Security Requirements

This chapter describes the requirements for the PCI 3DS, the PCI SDK, and the management of
the keys prepared by the Issuer and the security required when the service is outsourced to a
third party, and the policies for handling information collected by the Acquirer.

7.2.1 PCI 3DS SDK Security Requirements

3DS SDK Developer shall comply with the PCI 3DS SDK for implementing 3DS SDK.

7.2.2 Key Security Requirements

This section describes the requirements regarding the security for keys.

7.2.2.1 Prerequisites
The Acquirer uses and manages the keys described in Section 5.4 but should not use these keys
for reasons other than the intended use described in this document.
Also, the Acquirer should consider the risks of these keys being compromised etc., and should
avoid using the same keys over a long period of time

7.2.2.2 Fundamental Rules of Management

Each type of key used in J/Secure2.0 transactions shall be managed according to its life cycle, in
accordance with the fundamental rules below. “Life cycle” refers to key generation, conveyance,
usage, storage and revocation.

➢ Split knowledge
Various supervisors distribute the keys and manage various components. A
complete key cannot be constructed with the information retained by one personnel
alone.

➢ Dual Control
Multiple personnel manage one key, rather than one personnel managing the key
alone.

JCB Confidential
19
 J/Secure™ 2.0 Acquirer Implementation Guide
7. Operation Phase

Each type of key shall be used throughout its life cycle in a physically and logically safe device,
to avoid improper use. Also, regardless of the life cycle, the key shall not be revealed outside of
this safe device in plaintext format.

7.2.2.3 Key Compromise

In the case where each encryption key managed by the Acquirer is corresponding to the
following, the Acquirer shall implement appropriate measures such as the prompt invalidation of
encryption keys and certificates etc., after evaluating the scope of risk estimated at present and
in future.

➢ In the case where each type of DES encryption key or RSA private key has been
exposed to risk, or there is such a possibility
➢ In the case where each type of DES encryption key or RSA public key pair has lost
its complete secrecy, or there is such a possibility

7.2.2.4 Back-up
In preparation for cases where the key being used is lost or damaged due to a system error for
example, the key should be backed up so that the key can be restored. Therefore it is desirable
for the system to be able to load the back-up key. The back-up key shall not be stored at a lower
security level than the key in current use.

7.2.2.5 Security Requirements to a Third Party

In the case where the Acquirer outsources the key generation, usage and other services to a
third party, the Acquirer has the responsibility of enforcing these security requirements
established in this document unto the third party.

7.2.3 Policy for Handling Data Collected by Acquirer

When performing J/Secure2.0 transactions, the Acquirer or Merchant collects and sends various
types of information from the Cardholder’s device. That information shall be handled
appropriately within the scope of the relevant laws and regulations of the country and industrial
organizations.

JCB Confidential
20
 J/Secure™ 2.0 Acquirer Implementation Guide
Appendix A Form

Appendix A Form
Acquirer Implementation Form for J/Secure 2.0

JCB Confidential
21
 J/SecureTM2.0 Acquirer Implementation Guide
Appendix A Form

Appendix A Acquirer Implementation Form for J/Secure2.0

Acquirer Implementation Form for J/Secure2.0

TO: FROM:

JCB International Co., Ltd.

Network Implementation Headquarters

Fax: +81-3-5778-8377 Fax:

Phone: +81-3-5778-7921 Phone:

Acquirer General Information

Acquirer Name
Company Address
Applicant Information
Applicant Name

Address

E-mail

Telephone

Fax

Acquirer Implementation Information

J/Secure2.0 Tick as appropriate:
Implementation ☐ Acquirer Implement J/Secure2.0 first time
☐ Acquirer change the J/Secure 2.0 3DS Server product
or 3DS SDK product
☐ Other reason (please describe below)

<J/Secure1.0 information (reference)>

Tick as appropriate:
☐ Acquirer support J/Secure2.0 only
☐ Acquirer support J/Secure both 1.0 and 2.0
If Acquirer request J/Secure1.0, please refer to Acquirer Implementation Guide
for J/Secure1.0 and submit forms accordingly.
3DS Server Tick as appropriate:
Implementation ☐ 3DS Server developed by Acquirer itself
Type ☐ 3DS Server hosted by Acquirer
☐ Acquirer use their affiliated third party/gateway
with their 3DS Server
Third party/gateway name:
☐ 3DS Server hosted by Merchants:
(Merchants name)_______________________________________

JCB Confidential
22
 J/SecureTM2.0 Acquirer Implementation Guide
Appendix A Form

3DS Server 3DS Server vendor name :

Information 3DS Server product name:
EMVCo 3DS Server Reference Number

3DS SDK 3DS SDK vendor name :

Information 3DS SDK product name:
EMVCo 3DS SDK Reference Number

Program (YYYY, MM, DD)____________________________

Activation Date When?
If exact date is requested please tick as follows
☐ Exact the above date
Information for Email Domain:
DS2.0 Registration Please indicate the e-mail domain of the person who sends the DS2.0 registration file.

*Any email for the DS 2.0 registration which domain is not indicated will be rejected.

Date: (YYYY,MM,DD) ___________________________

Authorization Signature ________________________________

Name in Print ________________________________

Title ________________________________

From JCBI to Acquirer

3DS Server Operator ID

Acquirer BIN

Password

When Acquirer submits the DS registration files to JCBI, the file (zip format) shall be protected
by this Password.
Date: (YYYY,MM,DD) ___________________________

Authorization Signature ________________________________

Name in Print ________________________________

Title ________________________________

JCB Confidential
23
 J/SecureTM2.0 Acquirer Implementation Guide
Appendix B ECI mapping

Appendix B ECI mapping

ECI mapping for J/Secure2.0 (until March 31, 2020)

This matrix represents general processing data from authentication results to authorization.
It does not provide for all scenarios that could occur which authentication is not completed and go to authorization without 3DS related data.
ECI:
Device Channel : APP, BRW
05 = Authenticated transaction
message Category : PA, NPA
06 = Attempt
RBA results Challenge results Authorization data element 07 = Not authenticated

Seq Issuer Challenge ACS ①ACS ARes ②DS ARes ③ACS RReq ④DS RReq ⑤ Authorization Liability
Authentication result Scenario example
support availability behavior Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV ECI CAVV
Not
a DS Attempt No account range A 07 *1 yes 07 - Acquirer
support
Transaction Status:
b DS Attempt RBA is performed but Challenge is not available U 07 - A 07 *1 yes 07 - Acquirer Y = Authentication Successful
N = Authentication fail or cancel
Challenge is
c ACS Attempt RBA is performed but Challenge is not available A 06 yes A 07 *1 value of ① 07 - Acquirer U = Authentication could not be
unavailable
performed due to technical issue
d RBA is successful Y 05 yes Y 05 value of ① 05 value of ARes Issuer C = Request Challenge
Authentication R = Authentication Reject
e RBA is successful Y 05 yes Y 05 value of ① 05 value of ARes Issuer
Successful A = Attempt

f Challenge authentication is successful C - - C - - Y 05 yes Y 05 value of ③ 05 value of RReq Issuer

Challenge is
available Challenge not successful(Exceeding maximum
g Normal C - - C - - N - - N - - Shall not send
challenge), Challenge cancel
Authentication not
h successful Challenge not performed by the merchant C - - C - - N 07 - N 07 - 07 - Acquirer

i Issuer reject the transaction R - - R - - Shall not send

Device is not supported by ACS or other technical

j U 07 - A 07 *1 Yes 07 - Acquirer
problems in ARes which is sent by ACS

Technical issues or Error message Error message

k Errors occurred in Creq/Cres C - - C - - 07 - Acquirer
other problems
Suppor
t Technical issues or other problems during Challenge
l C - - C - - U 07 - U 07 - 07 - Acquirer
process and authentication is not completed.

DS can not send Areq to ACS、ACS can not send ARes,

m not Connected / Error Message A 07 *1 yes 07 - Acquirer
DS receives error message instead of ARes

ARes error which is sent by ACS (The transaction can

n Any Any Any A 07 *1 yes 07 - Acquirer
be identified)
Any cases
ACS malfunction,
DS Receives error message instead of Rreq (The
o Fault network trouble, C - - C - - Error Message Error Message 07 - Acquirer
transaction can be identified)
incorrect message.
ACS can not send RReq to DS, ACS send error message
p C - - C - - not Connected / Error Message 07 - Acquirer
to DS

RReq error which is sent by ACS (The transaction can

q C - - C - - Y, N, U 05, 07 Any Error Message 07 - Acquirer
be identified)

AReq error which is sent by 3DSS to DS *2

r Error message 07 - Acquirer
3DSS cannot connect to DS due to network error.

s Normal Other errors DS can not send ARes to 3DSS *2 Any Any Any not Connected / Error Message 07 - Acquirer

t DS cannot send Rreq to 3DSS *2 C - - C - - Error Message not connected 07 - Acquirer

For NPA, use same value for transaction status and ECI and presence of CAVV is up to the issuer. Authorization is not applicable for NPA.
<NOTE>
*1 DS change ECI=06 to 07 for attempt transaction before the liability rule activation.
*2 If a message is in error or not connected or timed out, an error component send error message and ends processing. If a merchant decides to send authorization, the transaction is not eligible for the liability shift.

JCB Confidential
24
 J/SecureTM2.0 Acquirer Implementation Guide
Appendix B ECI mapping

ECI mapping for J/Secure2.0 (From April 1, 2020)

This matrix represents general processing data from authentication results to authorization.
It does not provide for all scenarios that could occur which authentication is not completed and go to authorization without 3DS related data.

Device Channel : APP, BRW

message Category : PA, NPA
RBA results Challenge results Authorization data element ECI:
05 = Authenticated transaction
Seq Issuer Challenge ACS ①ACS ARes ②DS ARes ③ACS RReq ④DS RReq ⑤ Authorization Liability
Authentication result Scenario example 06 = Attempt
support availability behavior Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV ECI CAVV *2
07 = Not authenticated
Not
a DS Attempt No account range *3 A 06 yes 06 value of ARes Issuer
support

b DS Attempt RBA is performed but Challenge is not available U 07 - A 06 yes 06 value of ARes Issuer

Challenge is
c ACS Attempt RBA is performed but Challenge is not available A 06 yes A 06 value of ① 06 value of ARes Issuer Transaction Status:
unavailable
Y = Authentication Successful
d RBA is successful Y 05 yes Y 05 value of ① 05 value of ARes Issuer N = Authentication fail or cancel
U = Authentication could not be
Authentication
e RBA is successful Y 05 yes Y 05 value of ① 05 value of ARes Issuer performed due to technical issue
Successful
C = Request Challenge
f Challenge authentication is successful C - - C - - Y 05 yes Y 05 value of ③ 05 value of RReq Issuer R = Authentication Reject
Challenge is
available A = Attempt
Challenge not successful(Exceeding maximum
g Normal C - - C - - N - - N - - Shall not send
challenge), Challenge cancel
Authentication not
h Challenge not performed by the merchant C - - C - - N 07 - N 07 - 07 - Acquirer
successful

i Issuer reject the transaction R - - R - - Shall not send

Device is not supported by ACS or other technical

j U 07 - A 06 yes 06 value of ARes Issuer
problems in ARes which is sent by ACS

k Technical issues or Errors occurred in CReq/CRes C - - C - - Error Message Error Message 07 - Acquirer
Suppor other problems
t Technical issues or other problems during Challenge
l C - - C - - U 07 - U 07 - 07 - Acquirer
process and authentication is not completed.

DS can not send AReq to ACS、ACS can not send ARes,

m not connected / Error Message A 06 yes 06 value of ARes Issuer
DS receives error message instead of ARes

ARes error which is sent by ACS (The transaction can

n Any Any Any A 06 yes 06 value of ARes Issuer
be identified)
Any cases
ACS malfunction,
DS Receives error message instead of RReq (The
o Fault network trouble, C - - C - - Error Message Error Message 07 - Acquirer
transaction can be identified)
incorrect message.

ACS can not send RReq to DS, ACS send error message
p C - - C - - not Connected / Error Message 07 - Acquirer
to DS

RReq error which is sent by ACS (The transaction can

q C - - C - - Y, N, U 05, 07 Any Error Message 07 - Acquirer
be identified)

AReq error which is sent by 3DSS, 3DSS cannot

r not Connected / Error Message 07 - Acquirer
connect to DS due to network issue. *1

s Normal Other errors DS can not send ARes to 3DSS *1 Any Any Any not connected 07 - Acquirer

t DS cannot send RReq to 3DSS *1 C - - C - - Error Message not connected 07 - Acquirer

For NPA, use same value for transaction status and ECI and presence of CAVV is up to the issuer. Authorization is not applicable for NPA.
<NOTE>
*1 If a message is in error or not connected or timed out, an error component send error message and ends processing. If a merchant decides to send authorization, the transaction is not eligible for the liability shift.
*2 The CAVV associated with a fully authenticated transaction or an attempted transaction, must be included in the authorization message.
*3 3DS Server shall send AReq message even though the issuer card range is not participated in J/Secure2.0 in order to generate the proof of an authentication attempt.

JCB Confidential
25
 J/SecureTM2.0 Acquirer Implementation Guide
Appendix B ECI mapping

ECI mapping for J/Secure2.0

Device Channel : 3RI
ECI:
3RI is only for NPA and challenge is not performed
05 = Authenticated transaction
RBA results 07 = Not authenticated
Seq Issuer ACS ①ACS ARes ②DS ARes
Authentication result Scenario example
support behavior Trx Status ECI CAVV Trx Status ECI CAVV

a Not support Authentication is not available No account range N 07 -

Transaction Status:
Y = Authentication Successful
b Authentication Successful Frictionless Y 05 - Y 05 -
N = Authentication fail or cancel
U = Authentication could not be
c Authentication rejected R - - R - - performed due to technical issue
Normal Authentication not successful
R = Authentication Reject
d RBA not successful N 07 - N 07 -

Device is not supported by ACS or other technical

e Device is not supported or other problems U 07 - U 07 -
problems at ACS
Support
DS can not send Areq to ACS、ACS can not send ARes to
f not connected / Error Message Error Message
DS
ACS malfunction, network trouble,
Fault
incorrect message.
g ARes error which is sent by ACS Any Any - Error Message

h AReq error which is sent by 3DSS *1 not connected / Error Message

Normal Other errors
i DS can not send ARes to 3DSS *1 Any Any - not connected / Error Message

<NOTE>
*1 If a message is in error or not connected or timed out, an error component send error message and ends processing.

JCB Confidential
26
 J/SecureTM2.0 Acquirer Implementation Guide

J/SecureTM2.0 Acquirer Implementation Guide

Ver.1.2

Issuer: JCB Co. Ltd.

JCB International Co., Ltd.

Copyright © 2019 JCB Co., Ltd.

Unauthorized reproduction is strictly prohibited.