【J-Secure2.0】J-Secure™2.0 Acquirer Implementation Guide - 2.2.0

J/Secure™2.
0 Acquirer
Implementation Guide
Ver.2.2.0
J/Secure™ 2.0 Acquirer Implementation Guide
2019 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

Revision History
No Version Revision Date Chapter Revision Contents
1 1.0 2018/6 All First Edition

2 1.1 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
5 1.2 2019/2
Appendix B 2020’
Added ECI value in parentheses before
6 1.2 2019/2 Table 5-5
starting to apply liability rules
7 1.2 2019/2 Appendix A Updated Acquirer Implementation Form
Updated for EMV 3DS Core Spec and match
8 2.2.0 2019/10 All up the version number with the latest EMV
3DS Core Spec
9
10
JCB Confidential
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................................................................................................................3
2 J/Secure2.0 Overview ................................................................................................... 4
2.1 Overview ..................................................................................................................4
2.2 Objectives ................................................................................................................4
2.3 Participants and Responsibilities .........................................................................5
2.4 Structure ..................................................................................................................6
2.4.1 System Overview ..................................................................................................6
2-4-2 System Arrangement Diagram ...............................................................................7
2-5. Authentication Flow ...................................................................................................8
2-5-1 Authentication Flow (Frictionless Flow) ..................................................................8
2-5-2 Authentication Flow (Challenge Flow) ....................................................................9
3. Acquirer Implementation and Operation process ................................................... 12
4. Consideration on Planning Phase............................................................................. 13
4.1 Decision of Implementation Method ........................................................................13
4.1.1 Implementation Options ............................................................................................13
4.1.2 3DS Server Selection ...............................................................................................13
4.1.3 Revision of Merchant Agreement .............................................................................13
5 Implementation Phase ................................................................................................ 14
5.1 Application to JCB ................................................................................................14
5.2 Initialization of 3DS Server ..................................................................................14
5.2.1 Information required ............................................................................................14
5.2.2 Setting of 3DS Server Operator ID .....................................................................14
5.2.3 3DS Server Reference Number ..........................................................................14
5.3 Initialization of 3DS SDK ......................................................................................14
5.4 Installation of Encryption Keys and Certificates...............................................15
5.4.1 Installation on the 3DS Server ............................................................................15
5.4.2 Installation to the 3DS SDK.................................................................................15
5.5 Authorization System Upgrade ...........................................................................16
5.5.1 Authorization Message Items ..............................................................................16
5.6 Merchant Implementation ....................................................................................16
5.6.1 Obtainment of Acquirer BIN and 3DS Server Operator ID .................................16
5.6.2 Registration of Information with DS ....................................................................16
5.6.3 Setting of Acquirer Merchant ID ..........................................................................16
5.6.4 Setting of 3DS Requestor ID ...............................................................................16
5.6.5 Display of JCB Logo ............................................................................................17
5.7 Transaction Processing Requirements ..................................................................... 17
5.7.1 Risk-based Authentication Results ...........................................................................17
5.7.2 Challenge Authentication Results .............................................................................18
JCB Confidential
5.7.3 Processing Requirements When J/Secure1.0 and 2.0 coexist ................................18

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

The EMV 3-D Secure protocol versions that are supported by J/Secure 2.0 are below.
Table 1-1: J/Secure 2.0 Protocol Version Numbers

EMV 3-D Secure Protocol Version Number status Effective date
2.1.0 Active May 2018
2.2.0 Active Oct 2019
The contents applicable to Protocol Version Number 2.2.0 and above are written as [applicable
to v2.2.0 and above] in this document.
1.7 Related Documents

Documents related to this document are shown below.
1.7.1 EMV 3DS Documents
(1) EMV® 3-D Secure Protocol and Core Functions Specification v2.1.0
(2) EMV® 3-D Secure Protocol and Core Functions Specification v2.2.0 (hereinafter EMV 3DS
Core Spec)
(3) EMV® 3-D Secure SDK Specification v2.1.0
(4) EMV® 3-D Secure SDK Specification v2.2.0 (hereinafter EMV 3DS SDK Spec)
(5) EMV® 3-D Secure SDK Device Information
(6) EMV® 3-D Secure SDK Technical Guide v2.1.0
(7) PCI 3DS Security Requirements and Assessment Procedures for EMV 3-D Secure Core
Components: ACS, DS, and 3DS Server v1.0 (hereinafter PCI 3DS Core)
(8) PCI 3DS Security Requirements and Assessment Procedures for EMV 3-D Secure SDK
(hereinafter PCI 3DS SDK)
(9) PCI 3DS Data Matrix For use with PCI 3DS Core Security Standard v1.0 (hereinafter PCI
3DS Data Matrix)
1.7.2 JCB Documents

(1) J/Secure™ 2.0 ACS Functional Requirements
(2) J/Secure™ 2.0 3DS Server Functional Requirements
JCB Confidential
2
1. Introduction
(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.8 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
3
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.
➢ Applicable to Authentication without cardholders (3RI Payment for Payment Authentication)

[applicable to v2.2.0 and above]
In case of authentication where cardholder is not present such as recurring transactions, the
second or subsequent payments of split payments, re-authorization for pre-order
transactions, authentication results can be obtained each time and used for each
Authorization transaction.
2.2 Objectives
J/Secure2.0 serves four objectives, which are as follows:
➢ Fraudulent Usage Prevention for card-not-present Transactions (E-Commerce, Recurring

Transactions, mail order and telephone order, etc.)
By implementing Cardholder authentication for card-not-present 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 card-not-present Transactions

By implementing card-not-present 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 card-not-present sales.
JCB Confidential
4
➢ Improvement of Service for Cardholder

By providing Cardholder with a secure means of payment, it is possible for them to improve
their services.
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
5
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
6
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
7
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
(4)
sends 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
8
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
(5)
sends 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
9
2-5-3 Authentication Flow (3RI)

The J/Secure2.0 3RI flow is shown in Fig. 2-4 and Table 2-5.
Fig. 2-4: 3RI
3DS Requestor
3DS Server
DS（Brand）
④Authorization
⑤Authorization
ACS ISS Host ACQ Host
②Authentication
Issuer Acquirer
Table 2-5: Purchase Steps in 3RI

Step
(1 3DS Server receives from 3DS Requestor information including a flag that shows the
) transactions is 3RI, its usage, date and time of the previous authentication,
authentication results and authentication data, and include it in an AReq that will be
sent to ACS via DS.
(2 ACS validates the card and if possible performs risk-based authentication, and
) generates ECI and CAVV.
(3 The ACS sends the authentication results as an ARes message to the DS, and the
) DS sends it to the 3DS Server.
(4 The 3DS Requestor adds the authentication results to the authorization and sends it
) to the Acquirer.
(5 The Acquirer sends an authorization message, and the results of the authorization
) processing by the Issuer are sent back to the 3DS Requestor via the Acquirer.
*In the case where additional authentication is required at (2), Issuer can utilize
Decoupled Authentication to authenticate the cardholder. After the authentication, ACS
sends the authentication results as an RReq message to 3DS Server via DS.
[applicable to v2.2.0 and above]
JCB Confidential
10
2-6. Extended Function

The following features were introduced in EMV® 3-D Secure Protocol and Core Functions
Specification v2.2.0 as extended functions of the previous spec. [applicable to v2.2.0 and above]
- 3RI Payment
In the case where a merchant stores the card information, the merchant can initiate the
authentication request. Since the cardholder is not present, frictionless authentication is
performed based on the previous authentication results and the information stored by the
merchant.
 Use Cases: Split shipments, pre-order, recurring transactions(subscription), free trial,
auto top up, payments confirmed after the purchased amount is fixed (e.g. payment in
ridesharing apps), etc.
- Whitelisting
Issuer manages the list of whitelisted merchants for each cardholder.
- Acquirer Transaction Risk Analysis (TRA)

Instead of Issuer authenticating the cardholder, the merchant performs the risk analysis of
the transaction. It is optional for the Issuer to authenticate the cardholder.
- Decoupled Authentication
When ACS authenticates the cardholder with the method other than Challenge
authentication, the transaction is pended at the merchant while ACS returns the
authentication results before the pending period expires.
 Use Cases: Mail order, telephone order
JCB Confidential
11
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
12
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
13
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
14
・ 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
JCB Confidential
15
3 DS device information encryption J/Secure Encryption of AReq messages
certificate CA between the 3DS SDK and DS
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.
A Value generated by ACS or DS as the result of an authenticated transaction or an

authentication attempted transaction and sent in the ARes or RReq. The value shall
CAVV
be set in the Authorization message.*Authorization messages that have no CAVV are
regarded as the transaction for which J/Secure2.0 is not performed.
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)”.
JCB Confidential
16
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
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.html
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)*.
DS: A
or technical problems in
ACS
Perform Authorization Request with ECI=06
ACS Attempt A
(07)*.
Decouple Required Wait for RReq message from ACS during the
[applicable to v2.2.0 D authentication holding time determined by
and above] Merchant.
Authentication
Not Requested
(Data share only) I Perform Authorization Request with ECI = 07
[applicable to v2.2.0
and above]
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.
 In an ARes, the Issuers are expected to send Transaction Status other than N (authentication
failure).
JCB Confidential
17
 When a transaction is determined to have a high risk of fraud based on risk-based
decisioning, it is recommended for the Issuer to perform Challenge authentication or
Decoupled Authentication challenge. In the case where the Issuer has no channel with
the cardholder and neither of Challenge authentication and Decoupled Authentication
challenge is available, ACS can return Attempt as ARes or if the Issuer hopes to reject
the transaction because of the high risk of fraud, ACS can set R (reject) in the ARes.
When R is set in the ARes, Authorization will not be performed.
 The Issuer sets ECI = 07 and CAVV value generated by ACS when the Issuer returns
Transaction Status = I in the ARes.
 For NPA (Message Category = Non-Payment), ACS does not need to generate ECI and
CAVV because 3DS Requestor or Merchant is not allowed to utilise the Authentication
Result for NPA in the subsequent payment authorization.
If ACS sends ECI and CAVV in the ARes or RRes for NPA, DS deletes those values and
sends the message to 3DS Server.
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.
JCB Confidential
18
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
19
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
Authentication Not Requested
I 07
(Data share only)
*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 Authenticated by 3-D Secure
Failed to be Authenticated by 3-D Secure
06
(Reasons: Not supported by Issuer or Cardholder)
07 Not Authenticated by 3-D Secure
 For more information on sales data inclusion requirements, refer to the JRP Batch
Interface Guide.
JCB Confidential
20
5.7.6 Result of Non-Payment Authentication
The Acquirer should not divert the result of Non-Payment (NPA) Authentication to the
Authorization transaction of Payment (PA) or 3RI.
5.7.7 Protocol version

When ACS does not support the protocol version which is specified in the AReq sent by the
Merchant, the expected behavior in each component is as follows:
- For PA
DS returns Attempt in the ARes to the 3DS Server.
* For the Issuer who need to adapt to PSD2 requirements, Merchants are expected to send
Authentication request based on the protocol version which is available to the Issuer.
-For NPA
Merchants are expected to send Authentication request based on the protocol version
which is available to the Issuer.
If the Issuer does not support the protocol version set in the AReq by the Merchant, or if the
Issuer does not support J/Secure2.0, the DS does not return Attempt but returns
Transaction Status = U.
JCB Confidential
21
6.Testing
6 Testing
This chapter describes each test for J/Secure2.0 implementation.
6.1 J/Secure2.0 Confidence Test

6-1-1 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 has newly adopted a 3DS Server or 3DS SDK
hosting service provided by a third party/gateway who has not yet Mandatory
received 3DS Server Operator ID from JCB.
4) 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.
5) 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-1-2 Version Update Requirement

Along with the protocol version update of EMV 3DS Core Spec, JCB will update DS system
if necessary.
If an Acquirer updates their 3DS Server protocol version in accordance with JCB DS update,
Confidence Test with the updated 3DS Server is required.
Note: A 3-D Secure version numbers is in the following format: Major.Minor.Patch, and the
criteria for the update is based on the Minor (e.g. update from 2.1.0 to 2.2.0).
Contact information for Confidence Test is below:
JCB Co., Ltd.

Information Brand Infrastructure and Technologies
J/Secure support
Telephone Number +81-3-5778-8369
Office hours are 10:00 to 17:00 (Japan Standard Time:
Business hours GMT+9:00) from Monday to Friday except Japan National
Holidays.
JCB Confidential
22
6.Testing
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
23
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.
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
JCB Confidential
24
7. Operation Phase
 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 Core, the PCI 3DS 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.
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.
JCB Confidential
25
7. Operation Phase
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 TLS encryption key has been exposed to risk, or there is such a possibility
 In the case where TLS encryption key 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
26
Appendix A Form
Appendix A Form
Acquirer Implementation Form for J/Secure 2.0
JCB Confidential
27
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.
Support Protocol ☐ version 2.1.0
Version ☐ version 2.2.0
JCB Confidential
28
Appendix A Form
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)_______________________________________
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
Activation
Date
(YYYY, MM, DD)____________________________
If exact date is requested please tick as follows
When? ☐ 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
JCB Confidential
29
Appendix A Form
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
30
Appendix B ECI mapping
JCB Confidential
31
ECI mapping for J/Secure2.0

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.
Until March 31, 2020, the value in blanket of ECI and the entity in blanket of Liability will be applied.
Device Channel : APP, BRW, 3RI

message Category : PA, NPA
RBA results Challenge or Decoupled results Authorization data element
Mess ①ACS ARes ②DS ARes ③ACS RReq ④DS RReq ⑤ Authorization
Issuer's Challenge/
ACS age
Seq version Decoupled Authentication result Scenario example Liability
behaviour Cate Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV Trx Status ECI CAVV ECI CAVV *2
support availability
gory
06 06 Issuer
a - 1 PA: DS Attempt PA A yes value of ARes
Not No account range *3, the protocol version is (07) (07) (Acquirer)
support NPA: Authentication is not supported *7
a - 2 NPA U - -
not performed
06 06 Issuer
b - 1 PA: DS Attempt PA U 07 - A yes value of ARes
Challenge or (07) (07) (Acquirer)
Decoupled
RBA is performed but Challenge and 06 value of 06 Issuer
b - 2 authenticati PA: ACS Attempt PA A 06 yes A value of ARes
Decoupled authentication are not available (07) ① (07) (Acquirer)
on is
unavailable NPA: Authentication is
b - 3 NPA U - - U - -
not performed
value of
c - 1 PA Y 05 yes Y 05 05 value of ARes Issuer
①
RBA is successful and authenticated
c - 2 NPA Y - - Y - -
d - 1 PA C *4 - - C - - Y 05 yes Y 05 value of ③ 05 value of RReq Issuer

Authentication
Challenge authentication is successful
Successful
d - 2 NPA C *4 - - C - - Y - - Y - -
e - 1 PA D *5 - - D - - Y 05 yes Y 05 value of ③ 05 value of RReq Issuer

Decoupled Authentication is successful
Challenge or
e - 2 Decoupled NPA D *5 - - D - - Y - - Y - -
authenticati
f - 1 on is PA C *4 - - C - - N - - N - - Shall not send
available Challenge not successful(Exceeding
maximum challenge), Challenge cancel
f - 2 Normal NPA C *4 - - C - - N - - N - -
g - 1 PA D *5 - - D - - N - - N - - Shall not send

Decoupled Authentication failed
g - 2 NPA D *5 - - D - - N - - N - -
Authentication not
successful
h - 1 PA C *4 - - C - - N 07 - N 07 - 07 - Acquirer
Challenge not performed by the merchant
(merchant does not send CReq)
h - 2 NPA C *4 - - C - - N - - N - -
i - 1 PA R - - R - - Shall not send

Issuer reject the transaction
i - 2 NPA R - - R - -
06 06 Issuer
j - 1 Device is not supported by ACS or other PA U 07 - A yes value of ARes
(07) (07) (Acquirer)
technical problems in ARes which is sent by
j - 2 Support ACS NPA U - - U - -
Technical issues or
other problems
k - 1 Technical issues or other problems during PA C *4 - - C - - U 07 - U 07 - 07 - Acquirer
Challenge process and authentication is not
k - 2 completed. NPA C *4 - - C - - U - - U - -
06 06 Issuer
l - 1 DS can not send AReq to ACS、ACS can not PA not connected / Error Message A yes value of ARes
(07) (07) (Acquirer)
send ARes, DS receives error message
l - 2 instead of ARes NPA not connected / Error Message Error Message
06 06 Issuer
m - 1 PA Any Any Any A yes value of ARes
ARes error which is sent by ACS (The (07) (07) (Acquirer)
transaction can be identified)
m - 2 NPA Any - - Error Message
Any cases
o - 1 PA C, D - - C, D - - not Connected / Error Message 07 - Acquirer
ACS can not send RReq to DS, ACS send
error message to DS
o - 2 NPA C, D - - C, D - - not Connected / Error Message
p - 1 PA C, D - - C, D - - Y, N, U 05, 07 Any Error Message 07 - Acquirer

RReq error which is sent by ACS (The
transaction can be identified)
p - 2 NPA C, D - - C, D - - Y, N, U - - Error Message
q - 1 AReq error which is sent by 3DSS, 3DSS PA not Connected / Error Message 07 - Acquirer
cannot connect to DS due to network issue.
q - 2 *1 NPA not Connected / Error Message
r - 1 PA Any Any Any not connected 07 - Acquirer

Normal Other errors DS can not send ARes to 3DSS *1
r - 2 NPA Any - - not connected
s - 1 PA C, D - - C, D - - Error Message not connected 07 - Acquirer

DS cannot send RReq to 3DSS *1
s - 2 NPA C, D - - C, D - - Error Message not connected
value of
t - 1 PA I *6 07 Yes I 07 07 value of ARes Acquirer
An authentication exemption is accepted, ①
Any cases Normal
data share only
t - 2 NPA I *6 - - I *6 - -
Information Share
u - 1 An authentication exemption or data share PA U 07 - 07 - Acquirer
Not only is requested but Issuer is not
support participated in J/Secure or does not support
u - 2 protocol version 2.2.0 NPA U - -
For NPA, ECI and CAVV shall not be generated. If ECI and CAVV is generated by ACS, DS will delete these values and does not send them to 3DS Server. The result of NPA shall not be used for Authorization.
As a best practice, Transaction Status = N is not desirable to respond in ARes because transaction may not be proceeded for authorization. If transaction is not authenticated by RBA, ACS should request further authentication such as Challenge (C) or Decoupled (D).
If Challenge or Decoupled authentication is not available, ACS may respond Attempt (A).
<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.
*4 This indicator (C) is not valid if Device Channel = 03(3RI) within the AReq message.
*5 This indicator (D) can be sent only if the 3DS Requestor Decoupled Request Indicator = Y within the AReq message. This transaction status is available for protocol version 2.2.0 and above.
*6 This indicator (I) can be sent only if the 3DS Requestor Challenge Indicator = 05, 06, or 07 within the AReq message. This transaction status is available for protocol version 2.2.0 and above.
*7 If the 3DS Requestor Challenge Indicator indicates 05, 06 or 07 within the AReq message, u-1 is applicable.
ECI: Transaction Status:

05 = Authenticated transaction Y = Authentication Successful
06 = Attempt
N = Authentication fail or cancel
07 = Not authenticated
U = Authentication could not be performed due to technical issue
C = Request Challenge
R = Authentication Reject
A = Attempt
D = Request Decoupled Authentication
I = Information Only
JCB Confidential
32
Ver.2.2.0
Issuer: JCB Co. Ltd.

JCB International Co., Ltd.
Copyright © 2019 JCB Co., Ltd.

Unauthorized reproduction is strictly prohibited.

【J-Secure2.0】J-Secure™2.0 Acquirer Implementation Guide - 2.2.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

【J-Secure2.0】J-Secure™2.0 Acquirer Implementation Guide - 2.2.0

Uploaded by

Copyright:

Available Formats

J/Secure™2.

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

J/Secure™2.0 Acquirer Implementation Guide

1 1.0 2018/6 All First Edition

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

1.2 Intended Readers

1.3 Prerequisites of this Document

1.4 Structure of this Document

Chapter 2: J/Secure2.0 Overview

Chapter 3: Acquirer Implementation and Operation process

Chapter 4: Consideration on Planning Phase

Chapter 5: Implementation Phase

Chapter 7: Operation Phase

1.5 Revisions of this Document

1.6 Protocol Version Number

Table 1-1: J/Secure 2.0 Protocol Version Numbers

1.7 Related Documents

1.7.1 EMV 3DS Documents

1.7.2 JCB Documents

(3) J/Secure™ 2.0 3DS SDK Functional Requirements

➢ Applicable to In-App Payment

➢ Applicable to Non-Payment Authentication

➢ Applicable to Authentication without cardholders (3RI Payment for Payment Authentication)

➢ Fraudulent Usage Prevention for card-not-present Transactions (E-Commerce, Recurring

➢ Reduction of Chargeback Operations

➢ Growth of Sales with Cards Used for card-not-present Transactions

➢ Improvement of Service for Cardholder

2.3 Participants and Responsibilities

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

Table 2-2: System Overview

2-4-2 System Arrangement Diagram

Fig. 2-1 System Arrangement Diagram

Issuer Domain Interoperability Acquirer Domain

2-5. Authentication Flow

Fig. 2-2: Frictionless Flow

Table 2-3: Purchase Steps in Frictionless Flow

2-5-2 Authentication Flow (Challenge Flow)

Fig. 2-3: Challenge Flow

Table 2-4: Purchase Steps in Challenge Flow

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

2-5-3 Authentication Flow (3RI)

Fig. 2-4: 3RI

Table 2-5: Purchase Steps in 3RI

2-6. Extended Function

- Acquirer Transaction Risk Analysis (TRA)

3. Acquirer Implementation and Operation process

Fig: 3-1 Process Overview

Table 3-1: Summary of Acquirer Tasks

Merchant implementation 5.6

Transaction processing requirements 5.7

Confidence Test 6.1

4. Consideration on Planning Phase

4.1 Decision of Implementation Method

4.1.2 3DS Server Selection

4.1.3 Revision of Merchant Agreement

5.1 Application to JCB

5.2 Initialization of 3DS Server

・ 3DS Server URL

5.2.2 Setting of 3DS Server Operator ID

5.2.3 3DS Server Reference Number

5.3 Initialization of 3DS SDK

・ EMV® 3-D Secure—SDK Specification

5.4 Installation of Encryption Keys and Certificates