JCB QR Code Payment Implementation Guide_v1.0_201805
JCB QR Code Payment Implementation Guide_v1.0_201805
Implementation Guide
Version.1.0
May 2018
.
2018 JCB International Co., Ltd. All rights reserved.
All rights regarding this documentation are reserved by JCB Co., Ltd. (“JCB”). This
documentation contains confidential and exclusive information, patents, copyrights, trademarks,
trade secrets, know-how or other intellectual property rights, or any other rights of JCB or JCB
International Co., Ltd. (“JCBI”). You must accept and agree to all of the terms and conditions herein
before viewing, downloading or otherwise using all or any part of this documentation (written,
graphics or otherwise) appearing whether in whole or in part, regardless of form. JCBI is authorized
to conduct JCB’s business outside Japan, and the word of “JCB” in this documentation can be
construed JCB and/or JCBI in each context.
You are prohibited from copying for any third party, distributing, assigning, lending, displaying,
publishing or disclosing or modifying (including but not limited to translating), all or any part of this
documentation (written, graphics or otherwise) appearing whether in whole or in part, regardless of
form, without the prior written permission of JCB.
Certain parts of this documentation are produced by referring to documentations of EMVCo, LLC
(“EMVCo”) and this documentation may contain any information regarding patents, copyrights,
trademarks, trade secrets, know-how or other intellectual property rights, or any other rights of any
third party including EMVCo. Regardless of such reference, JCB makes no representation,
warranty or guarantee expressly nor impliedly whether all or any part of this documentation (written,
graphics or otherwise) appearing whether in whole or in part, regardless of form, does or does not
violate, infringe or otherwise use the information, patents, copyrights, trademarks, trade secrets,
know-how or other intellectual property rights, or any other rights of third parties including EMVCo.
You shall be solely responsible for determining whether your activities require license or permission
from third parties including EMVCo. JCB shall not be liable for your or any third party’s
infringement of any intellectual property rights or any other rights of any third parties including
EMVCo.
While JCB uses reasonable efforts to include accurate and up-to-date information in this
documentation, JCB makes no representation, warranty or guarantee expressly nor impliedly
regarding the accuracy or finality of this documentation (written, graphics or otherwise) appearing
whether in whole or in part, regardless of form and JCB shall not be liable for any product or service
developed or produced in compliance with this documentation. JCB shall assume no liability for
any typographical or other errors or omissions in the content of this documentation (written, graphics
or otherwise) appearing whether in whole or in part, regardless of form. This documentation may
contain links to other sites. JCB is not responsible for the content or practices of such sites.
To the extent permitted by applicable law, in no event JCB, its officers, employees, affiliates, agents,
or contractors, shall be liable to you or any third parties for any damages direct or indirect
consequential, incidental, or punitive damages arising from the use of or inability to use this
documentation, including without limitation, damages for loss of profit, business interruption, loss of
information, damages arising from third party’s claim, even if JCB has been advised of the
possibility of such damages.
QR Code is a registered trademark of DENSO WAVE. It is an ISO 18004- compliant encoding and
visualization of data.
Table of Contents
1. About This Document ............................................................................................... 7
1.1. Purpose of This Document ................................................................................. 7
1.2. Intended Readers ................................................................................................ 7
1.3. Roles and Responsibilities .................................................................................. 7
1.4. Structure of This Document ............................................................................... 8
1.5. Terminology........................................................................................................ 8
1.6. Revision of This Document ................................................................................ 9
1.7. References .......................................................................................................... 9
2. General Market Practice of QR Code Payment ....................................................... 10
2.1. Overview of QR Code Payment ....................................................................... 10
2.1.1. Business Background for QR Code Payment ............................................ 10
2.1.2. Mode and Type of QR Code Payment ....................................................... 10
2.1.2.1. Merchant Presented Mode ......................................................................11
2.1.2.2. Consumer Presented Mode .................................................................... 13
2.2. Key Benefits of QR Code Payment .................................................................. 14
2.2.1. For Issuers ................................................................................................. 14
2.2.2. For Acquirers ............................................................................................. 14
2.2.3. For Cardmembers ...................................................................................... 14
2.2.4. For Merchants ............................................................................................ 15
2.3. QR Code Payment Use Cases ........................................................................... 16
2.3.1. Face-to-Face Merchant Payment ............................................................... 16
2.3.2. Bill Payment .............................................................................................. 16
2.3.3. E-Commerce Merchant Payment............................................................... 17
3. JCB QR Code Payment Transactions – MPM ......................................................... 18
3.1. Merchant Payment Transaction ........................................................................ 18
3.1.1. Online Processing Flow ................................................................................ 18
3.1.2. Settlement Processing Flow .......................................................................... 19
3.2. System Interface Requirement.......................................................................... 20
3.3. Connectivity Requirement ................................................................................ 21
3.4. Key Items for JCB QR Code Payment Transactions ........................................ 22
3.4.1. EMV Compliant QR Code ............................................................................ 22
3.4.2. Static QR Code and Dynamic QR Code ....................................................... 22
Any matter not provided for in this document shall comply with JCBI regulations and
guidelines. Issuers and Acquirers shall also comply with local requirements if any.
1.2.Intended Readers
The intended readers of this document are Issuers and Acquirers who intend to
implement JCB QR Code Payment.
The roles and responsibilities of players involved in JCB QR Code Payment are as
follows.
(a) JCBI
(b) Issuer
• Complying with the specifications, policies, regulations and operations for JCB
QR Code Payment specified by JCBI.
• Providing a mobile application in an existing mobile banking application or as
a separate application for JCB QR Code Payment.
• Ensuring the security level of the mobile application meets JCBI, regulator, and
its own security policy and standard.
(c) Acquirer
• Complying with the specifications, policies, regulations and operations for JCB
QR Code Payment specified by JCBI.
• Ensuring that Merchants participating in JCB QR Code Payment fully meet the
merchant qualification standards specified in the JRP and fulfill KYC
requirements specified by local regulations.
• Assigning a unique Merchant PAN (refer to section 5.3) to each Merchant
following JCBI standards, to be used for QR Code generation.
• Ensuring that the participating Merchants are capable of handling JCB QR
Code Payment.
1.5.Terminology
Shall Denotes a mandatory requirement
JCBI may revise and reissue this document as necessary. Issuers and Acquirers shall
comply with the contents of the revision. For details such as the effective date of the
revision, please contact JCBI.
1.7.References
EMVCo specifications:
JCBI is joining the growing number of players in the market adopting this faster way of
facilitating payments by using a mobile device for both customer and merchant presented
QR Code payment transactions.
Section 2 introduces the general market practice and standard transaction flows for QR
Code payment. An overview of JCB QR Code Payment and Issuer and Acquirer
requirements are described in Section 3, Section 4 and Section 5.
QR Code payments reduce queue times in busy stores and restaurants. Smaller stores just
need to either scan the QR Code on a customer’s mobile phone or display a QR Code to be
scanned by customer’s mobile phone without preparing hardware terminals or an integrated
POS system. In this way, merchants from small businesses such as market stalls and pop up
shops to large scale merchants such as supermarkets, coffee chains, and luxury boutiques
are able to benefit from the convenience of this type of payment.
The QR Code can be a static (that is, constant) value for each individual merchant and
customer. Alternatively, it can be dynamic where the transaction specific dynamic data (for
example, transaction amount and billing information) is combined with the static
information.
MPM transactions give more flexibility for customers to pay without waiting in a queue.
Also, from the merchant acquiring side, it takes minimum infrastructure setup to capture
payments by receiving payment confirmation through the customer’s own mobile. Figure
2.1.2.1-1 describes the general transaction flow of MPM transaction.
# Description
1 The Cardmember opens a mobile application that has the capability to scan the
QR Code displayed at the merchant and initiates a payment transaction.
*The mobile application may be a part of existing mobile banking application offered by the
The following is the simple example of steps of the Cardmember doing an MPM
transaction.
# Description
1&2 The Merchant captures the Cardmember’s QR Code using the merchant
system and sends the information to the Acquirer in the same way as a
traditional card payment transaction.
3 The Acquirer validates the Merchant’s status and forwards the transaction to
the payment network.
4 The payment network forwards the transaction to the Issuer.
5 The Issuer checks the validity of the Cardmember account and other
credentials and when valid, debits the transaction amount from the
Cardmember account. The Issuer sends an authorization response back to
the payment network.
6&7 The payment network forwards the response back to the Acquirer. The
Acquirer forwards the response back to the Merchant.
3. The Cardmember enters the transaction amount when prompted on the display and
then performs any required CVM for Cardmember authentication.
*The Cardmember may need to enter a tip or convenience fees if prompted.
4. The Merchant (for example, the billing server) receives Merchant Notification from
the Acquirer that the transaction is approved or declined.
5. The Cardmember receives a payment confirmation from the Issuer on their mobile
application or via SMS.
1. The Cardmember purchases goods and services from a Merchant on the internet.
2. The Cardmember scans the QR Code displayed on the screen (Dynamic QR Code
customized for each transaction is recommended for e-commerce Merchant
payment).
3. The Cardmember enters the transaction amount into the mobile application when
prompted and performs any required CVM for Cardmember authentication.
*The Cardmember may need to enter a tip or convenience fees if prompted.
4. The Merchant receives notification from the Acquirer that the transaction is
approved or declined.
5. The Cardmember receives a payment confirmation from the Issuer on their mobile
application or via SMS.
6. The Merchant delivers the goods and services to the Cardmember.
This section explains the JCB QR Code Payment transaction flows for MPM transaction
from the perspective of authorization and settlement. It also gives an overview of JCB API
based MPM transactions in a single message environment.
# Description
0 The Cardmember opens the mobile application using the authentication required
by the Issuer.
1 The Cardmember scans the QR Code displayed by the Merchant, performs the
required CVM and enters the transaction amount (if required).
*Examples of CVM are PIN, one time password, fingerprint, and face recognition.
The Mobile Application sends the transaction to the Issuer for validation.
2 The Issuer validates the Cardmember’s credential and secures or debits the funds
for payment.
*The Issuer recovers a Partial Merchant PAN to the full 16-digit Merchant PAN before
forwarding the payment request to JCBI. Please refer to Section 5.3.1 for further details.
*The Issuer may convert the transaction amount to the Cardmember billing currency if
necessary before securing or debiting the funds from the account.
3&4 The Issuer forwards the transaction to JCBI (Authorization System for QR) and
JCBI forwards the transaction to the Acquirer.
5 The Acquirer validates the Merchant’s status, populates the Local Transaction
Date and Time upon validation and sends an approval response back to JCBI.
If JCBI sends a transaction response that the transaction failed (that is, rejected due to JCBI
validation or Acquirer rejection), the Issuer reverses the payment from the Cardmember’s
account and provides notification to the Cardmember that the payment failed.
Settlement processing for JCB QR Code Payment is slightly different from traditional card
payments. Licensees receive reconciliation data via Batch Interface message (variable
format).
Incoming Interchange File and Outgoing Interchange File for QR Code payment are not
generated for QR Code Payments since the transactions are processed using a single
message. JCBI provides Settlement Reports and settlement results files which contain
reconciliation data to Licensees for their settlement and reconciliation processes.
All files are exchanged between Licensees and JCBI using the existing procedure through
either Web-EDI or GXS-EDI.
# Description
10 Licensees receive Settlement Reports and reconciliation data on the day of the
cut-off.
Licensee shall set up the system interface with the Authorization System for QR in the
following manner:
• API based Interface – Licensees send and receive API messages to and from the
Authorization System for QR.
JCBI provides a set of APIs to Licensees in order to execute JCB QR Code Payment, along
with technical instruction documentation.
Licensee systems shall use the API codes provided by JCBI to send JCB QR Code Payment
transactions and receive transaction responses. Licensees shall follow JCBI message
specifications.
Licensees receive Settlement Report and settlement results files which includes
reconciliation data via Batch Interface message (variable format).
For details of the API specification, please refer to JCB Regulatory Publications – System Specifications
– Online Interface Guide for QR Code Payment.
For details of the batch interface message specification in variable format, please refer to JCB
Regulatory Publications – System Specifications – Batch Interface Guide for QR Code Payment.
Licensees shall establish system connectivity with the Authorization System for QR in the
following manner:
Use a secure Internet connection. The network bandwidth is no less than 64Kbps. If
requested by JCBI, Licensees shall upgrade bandwidth to ensure smooth online
transaction processing.
Use the API codes provided by JCBI in their host system program to format
messages.
Design an infrastructure and network communication failover plan (that is, a BCP
plan) to eliminate the risk of single point of failure at the network communication
level.
JCB QR Code Payment supports both Static QR Code and Dynamic QR Code. Acquirers
shall choose the appropriate type depending on the Merchant’s business and transaction
characteristics:
1. Static – The information in the QR Code does not change. After the QR Code has
been generated and printed, the content is fixed.
The Issuer shall design a Mobile Application that can scan QR Codes. The Issuer shall
forward the necessary data to JCBI in accordance with the JCB QR Code Payment message
specification.
The Acquirer shall generate QR Codes to be displayed at the Merchant based on EMVCo
standards and Appendix B, which include a Merchant PAN starting with the Acquirer
Identification Number (AIN) assigned by JCBI for JCB QR Code Payment.
Licensees shall perform self-tests to ensure the quality of scanning and generating QR
Codes as described in Appendix F.
JCBI may introduce a certification program to evaluate the Issuer’s Mobile Application and
Acquirer’s QR Code generation in the future.
Please refer to Appendix B and EMVCo specifications for the details of QR Code specifications.
Merchant Account Information is stored in EMV compliant QR Codes. The format and
values are unique per payment network and therefore several values may be stored in the
QR Code when the Merchant accepts cards from multiple payment networks.
Merchant Account Information with IDs 13 and 14 is reserved for JCB by EMVCo and is
the indicator for the Issuer to route the transaction to JCBI. Merchant Account Information
stored under ID “13” and “14” is either Merchant PAN or Partial Merchant PAN as
specified in Appendix B.
A Partial Merchant PAN is derived from the Merchant PAN, which is a 16-digit unique ID
that identifies a Merchant that accepts JCB QR Code Payment.
The Merchant PAN may include consecutive zeroes after the Acquirer Identification
Number (AIN). In this case, a Partial Merchant PAN should be stored in Merchant Account
Information IDs 13 and/or “ 14 to optimize manual entry.
If the Mobile Application fails to properly scan the QR Code displayed at the Merchant, the
Cardmember needs to manually enter merchant information in their Mobile Application.
The detailed layouts of Merchant PAN and Partial Merchant PAN are described in Section
5.3.
Merchant Notification is used by the Merchant to confirm the transaction results (that is,
approved or declined) and to decide whether to provide goods and services to the
Cardmember.
The Acquirer shall send Merchant Notifications via the merchant application, SMS, or
other means agreed between the Acquirer and the Merchant. Detailed requirements for
Acquirers are described in Section 5.4.
For MPM transactions, the Issuer initiates the Purchase transaction. Reversals are initiated
only by the Acquirer when required due to a failure of the transaction.
The Acquirer identifies the original Purchase transaction when initiating a Reversal. The
Acquirer shall set the OriginatorReferenceNumber in the message to indicate which
Purchase transaction is to be reversed.
For traditional card payments, the Acquirer provides the transaction amount and currency
code, and the Issuer converts the transaction amount to the Cardmember billing currency.
For MPM transactions, the Issuer receives the transaction first, so that the transaction
currency amount is converted by the Issuer.
Issuers may use the Exchange Rate Lookup API to get the converted amount from JCBI.
JCBI responds the exchange rate and the converted amount in the Cardmember billing
currency or Issuer settlement currency based on data (the original transaction amount, the
transaction currency code, and the target currency code) sent via the API.
JCBI also provides the settlement amount in the settlement currency agreed with the
Licensee during the onboarding process.
Note: Crossboarder transaction is not supported by JCBI as of February 2018. Licensees who wish to
implement crossborder transaction need to contact JCBI for further information.
Unlike the traditional card payment process, Acquirers shall not send any Outgoing
Interchange File to JCBI for MPM transactions, including Reversal and Refund.
For crossborder transactions, there will be no recalculation of the amount during the
clearing process. The settlement amount in settlement currency is calculated at the time of
the online message processing through API.
Note: Crossborder transaction is not supported by JCBI as of February 2018. Please contact your JCBI
representative for further information.
For the details of batch file specifications, please refer to JCB Regulatory Publications, System
Specifications – Batch Interface Guide for QR Code Payment.
For details of the dispute process, please refer to JCB Regulatory Publications for QR Code Payment -
Regulations Section 7.
For details of risk management requirements, please refer to JCB Regulatory Publications for QR Code
Payment- Regulations Section 3.2 and 4.5.
Licensees should refer to the JCB VI Design Manual for JCB Emblem requirements. The
digital data shall be downloaded from the following website:
http://www.jcb.co.jp/bdmanual/en/basicDesignElements/jcbEmblem/index01download01.html
For details of the JCB Emblem, please refer to JCB Regulatory Publications – Schedule D.
For the detailed and up-to-date requirements of the EMV® QR Payment Mark, please refer to the
EMVCo website (https://www.emvco.com/about/trademark-centre/).
Note: EMV® is a registered trademark or trademark of EMVCo LLC in the United States and other
countries.
Note: The QR Payment Mark, consisting of a stylized QR code, is a trademark owned by and used with
permission of EMVCo, LLC.
4. Issuer Requirements
This section describes the requirements for Issuers to implement JCB QR Code
Payment, in addition to the requirements specified in the JCB Regulatory Publications
for traditional card payment.
The Issuer shall recognize the Merchant Account Information ID 13 and 14 stored in the
QR Code as JCB QR Merchant information and shall route the transactions to JCBI
accordingly.
A Partial Merchant PAN may be stored in the QR Code as described in Section 3.4.5. If
so, the Issuer shall populate the eliminated zeros to recover the 16-digit Merchant PAN
before forwarding the transaction to JCBI.
The Issuer shall send Cardmember Notification to the Cardmember to inform them of
the transaction result via SMS, the mobile application or any other method agreed
between the Issuer and Cardmember agreed during the QR Code payment registration
process.
The Issuer should provide at least the information below to the Cardmember, in
consideration of Reversal, Chargeback, or Transaction Status Inquiry.
Approval Code
Transaction Amount
Transaction Currency Code (3-digit numeric value defined by ISO 4217)
System Trace Audit Number (value assigned by the Issuer to identify the
transaction for Reversal)
For details of Appendix QR B, please refer to Appendix E and JCB Regulatory Publications –
Operations Manual for QR Code Payment.
For details of authorization system requirements, please refer to JCB Regulatory Publications –
System Specifications – Online Interface Guide for QR Code Payment.
At the testing stage, the Issuer shall complete a QR Code Scanning Test, Sandbox Test
(self-test in the Sandbox Test environment) and API Test for QR Code Payment in the
interaction environment.
The API Test is an interactive test between the Issuer and JCBI. The Issuer shall request
its JCBI representative to arrange the test schedule.
The purpose of this test is to ensure that the mobile application properly scans QR
Codes. This is a self-test by the Issuer.
The Issuer shall perform a self-test of its mobile application to ensure that Static
and Dynamic QR Code scanning works properly. Test cases and criteria are
described in Appendix F.
The Issuer shall submit the Test Report (Appendix G) to JCBI for confirmation.
The purpose of this test is to validate that API messages are correctly generated by the
Issuer’s authorization host in accordance with JCB Regulatory Publications - System
Specifications – Online Interface Guide for QR Code Payment. This test is a self-test
performed by the Issuer in the Authorization System for QR test environment. This test
may be used for debugging purposes as well.
The successful completion of the Sandbox Test is the criteria to proceed to the API Test
in the interaction environment.
The purpose of this test is to validate that API messages are correctly generated by the
Issuer’s authorization host in accordance with the JCB Regulatory Publications -
System Specifications – Online Interface Guide for QR Code Payment.
May/2018 © 2018 JCB International All Rights Reserved Page 31
NOTE: This information, provided by JCBI, is confidential and proprietary and may not be duplicated, published or disclosed
to any third party, in whole or in part, without the express written permission of JCBI.
JCB QR Code Payment Implementation Guide
4. Issuer Requirements
As this test is an interactive test with JCBI, the Issuer shall request its JCBI
representative to arrange the test schedule.
The successful completion of the API Test is the criteria to proceed to the Migration
Test.
Upon the successful completion of the Sandbox Test, JCBI shall provide the
schedule for the API Test.
The Issuer shall connect to the Authorization System for QR test environment
and execute the online test cases with JCBI.
If the Issuer supports new functions, changes the file transfer method, or changes any
other operational procedure when implementing QR Code Payment, JCBI may request
the Issuer to perform additional tests which are not specified in this document.
The purpose of this test is to ensure that the Issuer is ready to go live and release JCB
QR Code Payment to Cardmembers.
The Migration Test shall be completed when both parties confirm that all the test
transactions specified by JCBI are successful in the production environment, which
includes online API connectivity as well as batch file exchange and data import.
Upon successful completion of the API Test, the Issuer shall agree with JCBI on
the Migration Plan and other preparation required before the first transaction.
The Issuer shall receive a Live Operation Reference (LOR) for QR Code
Payment from JCBI as the service guide for system related operations (including
system maintenance procedures and emergency procedures).
The Issuer shall submit a Monthly Report for JCB QR Code Payment to JCBI within the
first 10 business days of every month. The Monthly Report format is provided in
Appendix C.
5. Acquirer Requirements
This section describes the requirements for Acquirers to implement JCB QR Code
Payment, in addition to the requirements specified in the JCB Regulatory Publications
for traditional card payment.
The Acquirer shall provide the QR Code to the Merchant by email, a webpage for
Merchant use, via the merchant application, or by other means. The Acquirer shall
ensure that the Merchant keeps the QR Code (whether printed or displayed) in scanable
condition.
The Acquirer shall re-generate and replace the QR Code when Merchant Account
Information is changed for any reason.
The maximum size is 3.5 cm width X height when using 0.5 mm square dots.
*Acquirers should not use a QR Code with X-dimension smaller than 0.5 mm due to possible
problems in printing and scanning.
JCBI assigns a new Licensee ID and an 8-digit Acquirer Identification Number (AIN) to
the Acquirer to be used for identifying Merchants that accept JCB QR Code Payment.
Acquirers shall generate a Merchant PAN for each Merchant by concatenating its AIN
with a unique 7-digit number, followed by a Check Digit. The unique 7-digit number
should be padded with leading zeros.
Example:
Merchant PAN: 3158 0000 0000 012x
3 1 5 8 0 0 0 0 0 0 0 0 0 1 2 x
Assigned BIN to Acqurier X Unique Number for each Merchant Check Digit
(Luhn Formula)
The Acquirer should use a Partial Merchant PAN and populate into the QR Code by
eliminating the leading zeros of the unique number for each Merchant. The Partial
Merchant PAN is convenient and helps avoid errors when Cardmembers manually enter
the merchant account information in their mobile application.
3 1 5 8 0 0 0 0 1 2 x
The Merchant PAN or Partial Merchant PAN should be displayed together with the QR
Code at the Merchant for Cardmembers to enter if the mobile application fails to scan
the QR Code properly. When a Partial Merchant PAN is stored in the QR Code, it shall
be recovered by the Issuer to the 16-digit Merchant PAN.
The Acquirer shall send a Merchant Notification to the Merchant of the transaction
result via SMS, the merchant application, or any other method agreed between the
Acquirer and the Merchant.
The Acquirer shall ensure that the notification is appropriately linked to the QR Code
displayed at the Merchant, especially if there are multiple payment lanes (for example,
by assigning a Merchant PAN to each lane, or utilizing the Terminal ID as an identifier).
The Acquirer should provide at least the information below to Merchants, but not
limited to, in consideration of Reversal.
Approval Code
Transaction Amount
Transaction Currency Code (3-digit numeric value defined by ISO 4217)
Cardmember Name
System Trace Audit Number (value assigned by the Issuer to identify the
transaction for Reversal)
Submit Form A (Appendix D), Form QR B (Appendix E), and any other
required documents to JCBI.
For details of the Appendix QR B, please refer to Appendix F and JCB Regulatory Publications –
Operations Manual.
Risk management.
For details of Appendix QR B, please refer to Appendix E and JCB Regulatory Publications for QR
Code Payment – Operations Manual.
For details of authorization system requirements, please refer to JCB Regulatory Publications –
System Specifications – Online Interface Guide for QR Code Payment.
For details of settlement system requirements, please refer to JCB Regulatory Publications – System
Specifications – Batch Interface Guide for QR Code Payment.
At the testing stage, the Acquirer shall complete a QR Code Generation Test, Sandbox
Test (self-test in the Sandbox Test environment), API Test for QR Code Payment, and
File Import Test for batch files.
The API Test and File Import Test are interactive tests between the Acquirer and JCBI.
The Acquirer shall request its JCBI representative to arrange the test schedule.
The purpose of this test is to ensure that Acquirer’s QR Code generation system (for
example, the Acquirer’s internal system, webpage for merchants, and merchant
application) properly generates QR Codes in accordance with EMVCo specifications.
This is a self-test by the Acquirer.
The Acquirer shall perform the self-test for Static and Dynamic QR Code
generation in accordance with Appendix F.
Acquirer shall submit the Test Report (Appendix G) to JCBI for confirmation.
The purpose of this test is to validate that the API messages are correctly generated by
the Acquirer’s authorization host in accordance with the JCB Regulatory Publications -
System Specifications – Online Interface Guide for QR Code Payment. This test is a
self-test performed by the Acquirer in the Authorization System for QR test
environment. This test may be used for debugging purposes as well.
The successful completion of the Sandbox Test is the criteria to proceed to API Test in
the interaction environment.
JCBI provides the technical implementation details, which includes the details of
the test cases to be executed and the procedure for executing the self-test.
JCBI prepares client and server security test certificates and distributes them to
the Acquirer.
JCBI configures the IP address white listing in the Sandbox Test environment
allowing the Acquirer to perform the Sandbox Test.
The Acquirer shall make secured connection to the Sandbox Test environment
and execute the test cases as Acquirer.
The Acquirer shall use the Sandbox Test environment to simulate the Issuer and
Cardmember.
The Acquirer shall submit the test results captured during the self-test to JCBI
for validation.
The purpose of this test is to validate that the API messages are correctly generated by
the Acquirer’s authorization host in accordance with the JCB Regulatory Publications -
System Specifications – Online Interface Guide for QR Code Payment.
As this test is an interactive test with JCBI, the Acquirer shall request its JCBI
representative to arrange the test schedule.
The successful completion of the API Test is the criteria to proceed to the Migration
Test.
Upon the successful completion of the Sandbox Test, JCBI provides the
schedule for the API Test.
Acquirer shall connect to the Authorization System for QR test environment and
execute the online test cases with JCBI.
If the Acquirer supports new functions, changes the file transfer method, or changes any
other operational procedure when implementing JCB QR Code Payment, JCBI may
request the Acquirer to perform additional tests which are not specified in this
document.
The purpose of this test is to validate that the Acquirer host system is capable of
receiving batch files provided by JCBI, such as settlement summary data and
reconciliation data, which includes the Licensee ID and newly assigned AIN.
The Acquirer shall execute the batch test cases with JCBI to ensure that its host
system is capable of receiving the batch files (for example, settlement data and
reconciliation data).
The purpose of this test is to ensure that the Acquirer is ready to go live and release JCB
QR Code Payment to Merchants.
The Migration Test shall be completed when both parties confirm all the test
transactions specified by JCBI are successful in the production environment, which
includes online API connectivity as well as the batch file exchange and data import.
Upon successful completion of the API Test, Acquirer shall agree with JCBI on
the Migration Plan and other preparation requirements to be made before the
first transaction.
Acquirer shall receive a Live Operation Reference (LOR) from JCBI as the
service guide for system related operations (including system maintenance
procedures and emergency procedures).
The Acquirer shall submit a Monthly Report for JCB QR Code Payment to JCBI within
the first 10 business days of every month. The Monthly Report format is provided in
Appendix C .
A-1 Introduction
A-1. Introduction
This Appendix A gives several examples of the normal MPM transaction flows and
additional service transaction flow.
The Purchase Transaction has 5 participants. The transaction is initiated by the Issuer.
1. The Cardmember requests a purchase transaction by scanning the QR Code
using the mobile application and confirming the transaction with CVM as
required.
2. The Issuer secures available funds in the Cardmember account or debits the
account and sends the transaction to JCBI.
4. The Acquirer credits the Merchant account and sends a transaction response to
JCBI.
5. The Acquirer notifies the Merchant of the transaction result (either approved or
declined).
7. The Issuer sends Cardholder Notification to the Cardmember via the mobile
application.
The Reversal transaction has 5 participants. The transaction is initiated by the Acquirer.
1. The Merchant requests the Acquirer to initiate a reversal transaction, for reason
of a Cardmember dispute or on its own initiative. The request may be
The Timeout Reversal has 5 participants. This transaction is initiated by JCBI in when
there is no response from the Acquirer to a Purchase transaction.
2. The Issuer secures available funds in the Cardmember account or debits the
account and sends the transaction to JCBI.
4. The Acquirer does not send a transaction response to JCBI within 30 seconds.
5.1 JCBI initiates the Timeout Reversal transaction to the Acquirer. If there is no
response, JCBI retries the configured number of times.
5.2 The Acquirer notifies the Merchant of the transaction result (rejected).
5.3 The Acquirer sends the transaction response to JCBI.
6. JCBI sends the transaction response (rejected) to the Issuer.
7. The Issuer notifies the Cardmember of the transaction result (rejected).
Note: Step5.2, 5.3 and 6 may be processed at the same time or Step 6 may come first.
CVM if required.
2. The Issuer secures available funds in the Cardmember account or debits the
account, and sends the transaction to JCBI.
3. If JCBI general validation fails, JCBI rejects the transaction back to the Issuer.
4. JCBI sends the Reject Advise Transaction to the Acquirer.
5. The Acquirer sends the Merchant Notification to Merchants for the result of
transaction (rejected).
6. The Issuer sends the Cardmember Notification to Cardmember for the result of
transaction (rejected).
The Transaction Status Inquiry has 3 participants. This inquiry is initiated by the Issuer
or Acquirer in order to check the status of a transaction.
The Exchange Rate Lookup has 2 participants. The lookup is initiated by the Issuer or
Acquirer in order to obtain an exchange rate for a crossborder transaction (the
Cardmember billing currency is different from the transaction currency).
This function is not supported as of February 2018. JCBI may introduce this function in the future.
1. The Issuer or Acquirer sends the lookup to JCBI, which contains the source
currency, source amount and target currency.
2. JCBI uses the JCBI exchange rate to convert the source amount to the target
amount and sends the response to the Issuer or Acquirer
Table B-1 lists the name of the data object, the ID, the format of the value, the length, and
whether the presence of the data object at the root level of the QR Code is Mandatory (M),
Conditional (C), or Optional (O).
Ex: 13163158123456789012
Merchant Category 52 N 04 M
Code
Transaction 53 N 03 M
Currency
Tip or Convenience 55 N 02 O
Indicator
CRC 63 ans 04 M
The Monthly Report format for QR Code Payment shall be provided by your JCBI
representative. Please contact JCBI when needed.
【ISS】
(1) Balance of the Reporting Month
Cancelled Cards of the Reporting
Balance of Previous Month New Cards of the Reporting Month Balance of the Reporting Month
Product Type Month
No. of Cards No. of Accounts No. of Cards No. of Accounts No. of Cards No. of Accounts No. of Cards No. of Accounts
Credit
Debit
Prepaid
TOTAL 0 0 0 0 0 0 (a) 0 (b) 0
(2) Transaction of the Reporting Month
Number of Transactions Transaction Amount (Currency Code: )
Inter- Inter-Regional
Product Type Domestic Transaction Regional &
Domestic Transaction & Intra-
TOTAL TOTAL
On-us Local Intra- On-us Local Regional
TOTAL TOTAL
Transaction Transaction Regional Transaction Transaction Transaction
Credit 0 0 0 0
Debit 0 Cross-Border 0 0 Cross-Border 0
Prepaid 0 開始までなし 0 0 開始までなし 0
TOTAL 0 0 0 0 0 0 0 0 0 0
(3) Active Cards/Accounts in Reporting Month
No. of Cards No. of Accounts
Active Balance of Date(mm/dd/yyyy): / /
(c) (d)
the Reporting Month
Authorized
for DomesticTransaction
Signature:
for Inter-Regional & Intra-Regional Cross-Border
Transaction 開始までなし Name in Print:
Active Ratio (c)/(a) #DIV/0! (d)/(b) #DIV/0! Title:
【ACQ】
Number of merchant
Number of Transaction
Transaction Amount
Form A revised for QR Code Payment shall be introduced later. Please contact your
JCBI representative when needed.
Appendix F provides the self -test cases for the Issuer QR Code Scanning Test and the
Acquirer QR Code Generation Test.
Appendix F shall be introduced later. Please contact your JCBI representative when
needed.
Test Report for QR Code Scanning and Generating Test is described in this section. The
official Test Report format is provided by your JCBI representative