Japan Electronic-money Promotion Association

Guidelines for implementing
e-money payment terminals supporting
NFC/FeliCa - Version 1.1 March 1st, 2019Japan Electronic-money Promotion Association

Revision history
Ver

Date

Description

1.0

1 June 2016

1.1

Introduction page was added
Bibliography page was modified
1 March 2019
Contact information page was removed (Opened an inquiry form
on web site)

New creation in JapaneseJapan Electronic-money Promotion Association

1

Introduction

This document includes recommendations to avoid a number of interoperability issues
that can potentially occur between FeliCa based e-money payment terminals and NFC
mobile devices.
Additionally the document also includes some recommendations for terminals
supporting FeliCa and EMVCo.

FeliCa is a trademark of Sony Corporation. FeliCa is a contactless IC card technology developedby Sony Corporation.
EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark
elsewhere. The EMV trademark is owned by EMVCo, LLC.

Japan Electronic-money Promotion Association2

Categories
This guideline classifies issues into the following three categories:
Category A
Issues that can occur because of deviations between NFC Forum and FeliCa
specifications.
Category B
Issues that occur because of topics that are not defined in any public specification andtherefore left to implementations.
Category C
Issues that exist because of implementations that do not fully comply with the NFC Forum
and/or FeliCa specifications.
Issues that relate to terminals supporting multiple technologies and services according to
FeliCa and EMVCo specifications.

All vendors are encouraged to implement their products according to thisguideline.

Japan Electronic-money Promotion Association

3

Informative: Impact level
High
Payment failure (duplicate transactions) may happen.
The media may be damaged or destroyed.

Medium
A payment with the NFC mobile device in question is not possible.
A payment for a specific service is not possible with the NFC mobile device in question.

Low
A payment with the NFC mobile device in question is not possible. However the likelihood of
the problem to occur is not very high.
A payment with the NFC mobile device in question is not possible depending on thesurrounding situation.
A payment with the NFC mobile device in question is not possible when other terminals arelocated in close proximity.

Japan Electronic-money Promotion Association

4

Terms and definitions
terminal
a payment terminal supporting at least one FeliCa-based payment service.

media
a contactless IC card or an NFC mobile device.

NFC mobile devicea mobile device compliant to NFC Forum and FeliCa specifications.

Mode 0the state in which a FeliCa media enters after detecting an RF field

NFC-A, NFC-B, NFC-F
Different NFC technologies. NFC-F is the NFC technology used by FeliCa.

System 0
the first System on a FeliCa media

Wild-card pollinga FeliCa Polling command with System Code set to FFFFh and Request Code set to 00h

Japan Electronic-money Promotion Association

5Category A
No.

Title

FeliCa
specs

NFC
Forum
specs

A-1

NFC-F wild-card Polling

N/A

Yes

A-2

Field reset duration

N/A

Yes
5.1+ ms

A-3

End of frame detection for NFC-F

Yes

Yes

A-4

Maximum field strength

Yes

Yes

Japan Electronic-money Promotion Association

6

Category B
NFC
Forum
specs

No.

Title

FeliCaSpecs

B-1

Rules for RF collision avoidance

N/A

N/A

B-2

Mobile device switches to poll mode

N/A

N/A

B-3

Shutdown time after RF field loss

N/A

N/A

B-4

Accessing multiple FeliCa Systems #1

N/A

N/A

B-5

Accessing multiple FeliCa Systems #2

N/A

N/A

B-6

Presence check interrupts transaction

N/A

N/A

Japan Electronic-money Promotion Association

7

Category C
FeliCa
specs

NFC
Forum
specs

No.

Title

EMV®
Specs

C-1

Polling process for multiple RF technologies #1

Yes

N/A

N/A

C-2

Polling process for multiple RF technologies #2

Yes

N/A

N/A

C-3

Invalid Polling commands

-

Yes

Yes

C-4

Guard time

-

Yes

Yes

Japan Electronic-money Promotion Association8

A-1: NFC-F wild-card Polling
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
The media identified using a FeliCa Polling does not respond to any FeliCa commands.

Root cause
If the terminal uses a Wild-card Polling, the NFC mobile device sends a response indicating Peer
to Peer mode. In Peer to Peer mode, FeliCa commands are not supported, instead the device
expects the NFC-DEP protocol to be activated.

Solution
The terminal shall use the specific System Code value for the FeliCa-based service it wants toaccess when sending a FeliCa Polling.
When sending a Wild-card Polling (System Code set to FFFFh), the Request Code shall be set to
01h.

Japan Electronic-money Promotion Association9A-2: Field reset duration
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
An NFC mobile device does not respond to a FeliCa Polling after a field reset, which the terminal
performs by switching the RF field off and then on.
The field reset can be used for switching between different RF technologies (such as NFC-A,
NFC-B and NFC-F) or resetting the media state in case the media has been authentication status.

Root cause
The RF field off time during the field reset has been too short. For a field reset, the RF field has tobe switched off for a duration of at least 5.1 ms as defined in the NFC Forum specifications.

Solution
When performing a field reset, the terminal shall keep the RF field off for at least 5.1 ms.

Japan Electronic-money Promotion Association10

A-3: End of frame detection for NFC-F
ImpactHost

Payment
application

Terminal
softwareTerminal
hardware

Level
Low

Problem
The payment transaction with an NFC mobile device fails because the terminal does not receive
the response from the media properly.

Root cause
If the terminal implementation detects the end of a frame by waiting for a non-modulated carrier,noise that follows the frame might be interpreted as being part of the frame.
Early versions of the NFC Forum specifications allowed to optionally detect the end of frame
based on non-modulated carrier.

Japan Electronic-money Promotion Association11

A-3: End of frame detection for NFC-F
Difference in end of a frame detection between NFC-A, NFC-B and NFC-F
NFC-A

1
１st byteSP

2nd bytend byte

P

P E

1

0

・・・
Non-modulated
carrier after the endof frame

NFC-B
1
SOF

Data

EOF

0

0

・・・
Non- modulated
carrier after the endof frame

NFC-F(FeliCa)
Preamble

SYNC

LengthData

The position of the end offrame is calculated fromthe Length value.

CRC

The end of a frame isdetermined differently between
NFC-A, NFC-B and NFC-F.

Solution
The terminal shall determine the end of a NFC-F (FeliCa) frame by calculating the frame length
using the value of the Length byte.

Japan Electronic-money Promotion Association

12A-4: Maximum field strength
ImpactHost

Payment
application

Terminal
softwareTerminal
hardware

Level
High (potential destruction of the media)

Problem
An NFC mobile device might be destroyed when tapped on a terminal.

Root cause
In the NFC Forum specifications the maximum field strength is defined as 7.5 A/m, while the
FeliCa specification defines 11 A/m.

Solution
The terminal shall use a maximum field strength of 7.5 A/m as defined in the NFC Forumspecifications.

Japan Electronic-money Promotion Association13

B-1: Rules for RF collision avoidanceImpactHost

Payment
application

Terminal
softwareTerminal
hardware

Level
Low

ProblemSome terminals cannot operate when other terminals are located in close proximity.

Root cause
Using RF Collison Avoidance(RFCA), a terminal can check whether there is an external RF field
before switching on its own RF field. If there is an external field, the terminal keeps its RF field off.
Therefore the RF field of another terminal located nearby might prevent the operation of theterminal.

Solution
The terminal shall not keep the RF field ON all the time.
To avoid interference of RF fields, a terminal implementing RFCA shall not be placed adjacent toanother terminal (a minimum distance of approx. 200 mm between the center of the antennas issuggested).

Japan Electronic-money Promotion Association14

B-2: Mobile device switches to poll mode
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment transaction using an NFC mobile device fails when the terminal switches the RF field
off after starting the transaction.

Root cause
The NFC mobile device may switches to poll mode if it detects no external RF field for a certaintime.

Solution
In general the terminal shall not switch RF field off during a transaction.
If there is a specific need for a field reset during a transaction and a timeout error occurs
afterwards, the terminal shall retransmit the command until the NFC mobile device is ready again
to receive commands. The period for repeating retransmission is approx. 300 ms, depending on
the mobile equipment.

Japan Electronic-money Promotion Association15

B-3: Shutdown time after RF field loss
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment transaction using an NFC mobile device fails when the terminal has reset the RF fieldright before starting the transaction or during the transaction.

Root cause
Some NFC mobile devices have an IC chip that performs a shutdown process after detecting that an
external RF field has been switched off. This shutdown process takes some time during which nocommunication is possible.

Solution
In general the terminal shall not switch RF field off during a transaction.
If there is a specific need for a field reset during a transaction, and a timeout error occurs afterwards,
the terminal shall retransmit the command until the NFC mobile device is ready again to receive
commands. This is the case latest after 50.4 ms from the time the RF field has been switched off (30ms for the shutdown process + 20.4 ms for NFC-F guard time).

Japan Electronic-money Promotion Association16

B-4: Accessing multiple FeliCa Systems #1
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment process using an NFC mobile device fails if the terminal accesses different FeliCa
systems sequentially without sending a Polling with the System Code of the next system inbetween.

Root cause
An NFC mobile device is forwarding any commands to the System that has responded to the last
Polling.

Solution
Before accessing a different System during a payment process, the terminal shall send a Pollingwith the System Code of the System. The terminal shall only send commands to the System after
it has received a valid Polling response.

Japan Electronic-money Promotion Association17

B-4: Examples
Problematic sequence

Recommended solution

NFC mobile
deviceTerminal

Polling for System X

NFC mobile
deviceTerminal

Polling for System X
IDｍ=NFCID2-X

IDｍ=NFCID2-X

Polling for System Y

Request Service IDm=NFCID2-X
Response

IDｍ=NFCID2-Y

Polling for System Y

Request service IDm=NFCID2-Y
Response

Request Service IDm=NFCID2-X

Error

Japan Electronic-money Promotion Association

IDｍ=NFCID2-Y

Command is forwarded
to System Y

Request service IDm=NFCID2-Y
Response18

B-5: Accessing multiple FeliCa Systems #2
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment process that uses the Request System Code command without Polling commands fails
with an NFC mobile device.

Root cause
The Request System Code command, which is specified in the FeliCa specification, is not fully
supported on NFC mobile devices. The response may not include all System Codes available on
the device.

Solution
In case the terminal intends System Code search with the Request System Code command, theterminal shall use Polling command to check for specific System Codes in advance. The terminal
shall use the Request System Code command after receiving a corresponding valid Polling
response.

Japan Electronic-money Promotion Association19

B-6: Presence check interrupts transaction
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment process on an Android OS-based terminal fails because of the presence check that istriggered by the OS.

Root cause
If there is no communication for a specific time, Android performs a presence check by sending awild-card Polling command. If there is no response to the presence check command, which can be
the case for an authenticated System, the Android OS closes the connection as it assumes themedia has been removed. Additionally, this command can reset the media state in case the media
has been authenticated.

Solution
Android 4.4 or later allows to configure the time period after which it sends the presence checkcommand. This time shall be configured to a value that is long enough that no presence check is
performed during the transaction.

Japan Electronic-money Promotion Association20

B-6: Presence check interrupts transaction
The terminal incorrectly recognizes no media in the field.
Presence check
Terminal
Application

Middleware/
Drivers

Media

Polling command to System 0

Mode0

Mutual authentication to System 0
State transition to a mode
different than Mode0

Presence check time interval
Polling command (System Code=FFFFh)

Error
notification

Switch RF field OFF

Japan Electronic-money Promotion AssociationNo
response

Mode0

No response
becausePolling is notsupported in amode different
than Mode0.
21

B-6: Presence check interrupts transaction
The terminal resets the media state.
Presence check
Terminal
Application

Middleware/
Drivers

Media

Polling command to other than System 0
Mode0
Mutual authentication to other than System 0
State transition to a mode
different than Mode0

Presence check time interval
Polling command (System Code=FFFFh)
State is reset to Mode0(un-authenticated)
Secure command (invalid for Mode0).

Japan Electronic-money Promotion AssociationNo
response

No response
because themedia state
has been resetto Mode0.
22

C-1: Polling process for multiple RF technologies #1
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment process using NFC-F fails when an NFC mobile device supporting multiple technologies
is tapped to a terminal that implements the EMVCo polling procedure.

Root cause
The EMVCo polling and collision detection procedures are designed to make sure that only a single
device is present in the field. If multiple technologies or devices are detected, the process is aborted.
If an NFC mobile device supporting multiple technologies is tapped on such a terminal, two problems
can occur when targeting an NFC-F payment transaction:
Two technologies are detected and the process is aborted.
NFC-F is not detected by the terminal.
A more detailed description can be found on the next slide.

Japan Electronic-money Promotion Association23

C-1: Polling process for multiple RF technologies #1
Root cause (detailed description)
The EMVCo polling procedure polls for NFC-A, NFC-B and optionally for additional technologies like
NFC-F (in that order). After a technology has been detected, the polling procedure continues to poll
for all other supported technologies. The procedure performs an RF reset after polling for additional
technologies.
On the other side the NFC mobile device will respond to the first technology it supports and then
won’t respond to other technologies until an RF reset.
The technology that is detected first by the terminal depends on the point in time when the NFC
mobile device is tapped on the terminal.
Assuming that the user intends to use a FeliCa-based payment service with an NFC mobile device
that supports NFC-A, NFC-B and NFC-F:
if NFC-F is detected first, the polling procedure performs a reset and polls again for NFC-A and
NFC-B. This results in detecting two technologies because the NFC mobile device will respondto NFC-A after the reset. In this case the EMVCo collision detection procedure will abort theprocess.
if NFC-B is detected first, the polling procedure polls for NFC-F, resets the RF field and thenpolls for NFC-A. Again two technologies are detected, as the NFC mobile device responds to
NFC-A after the RF reset. The EMVCo collision detection procedure will abort the process.
if NFC-A is detected first, the other technologies are polled without an RF reset in-between.
Therefore no other technology is detected and the process is not aborted, but NFC-F is not
visible to the terminal and the NFC-F based payment transaction cannot be performed.
In all cases, the user can not use the FeliCa-based payment service.
Remark: If the terminal additionally uses the optional RF reset before polling for NFC-F, it will always detect multiple
technologies.

Japan Electronic-money Promotion Association24C-1: Implementation example
Solution
The terminal using NFC-F shall differentiate between NFC-F and EMVCo payments and only
apply the EMVCo procedures for EMVCo payments as shown below.

Implementation example for co-existence between EMVCo and FeliCa-based
services
The terminal shall be configured before the transaction on whether to perform an EMVCo or
FeliCa transaction. This configuration can be triggered by the cashier based on the payment
service the payer wants to use.
Start

Use
FeliCa-based
service?

No

Yes
FeliCa-based service
sequence (NFC-F)

Japan Electronic-money Promotion Association

EMVCo-based
service sequence(NFC-A,B)

25

C-2: Polling process for multiple RF technologies #2
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A multi-technology terminal might not detect that an NFC mobile device supports NFC-F andtherefore can not perform the FeliCa payment transaction.

Root cause
An NFC mobile device is locked in the technology it first responds to. Afterwards it will not respondto polling commands of other technologies as long as the RF Field remains ON. To change thetechnology, the terminal therefore needs to perform an RF reset.

Solution
The terminal shall only poll for a technology if it has at least one application that uses thetechnology.
When the terminal has received a response to a polling command of a technology, it shall perform
an RF reset before polling for another technology.

Japan Electronic-money Promotion Association26

C-3: Invalid Polling command
ImpactHost

Payment
application

Terminal
softwareTerminal
hardwareLevel
MediumProblem
A payment transaction fails when an NFC mobile device is tapped on a terminal that uses aninvalid Polling command.

Root cause
The terminal uses an invalid Polling command. The length of a Polling command is 6 bytes in NFC
Forum and FeliCa specifications. Some existing fare media can also accept Polling commands
with an invalid length, nevertheless such invalid Polling commands shall not be used.

Solution
The terminal shall format Polling commands as defined in the NFC Forum and FeliCa
specifications. A compliant Polling command has a length of 6 bytes.

Japan Electronic-money Promotion Association27

C-4: Guard time
ImpactHost

Payment
application

Terminal
softwareTerminal
hardware

Level
Low

Problem
A payment transaction fails when a FeliCa media is tapped on a legacy terminal that does notrespect the guard times of the media.

Root cause
After receiving a response, the terminal does not respect the defined guard time and is sending a
new command before the media is ready to receive it (the guard time is required by the media toswitch to receive mode after sending a response).

Solution
The terminal shall respect the defined guard times when transmitting or re-transmitting acommand.

Japan Electronic-money Promotion Association28

C-4: Guard time
NFC Forum and FeliCa specifications define the guard times. The guard time of
media is defined as a minimum time the terminal shall wait until it sends the next
command.
Remark: In NFC Forum specifications the corresponding definition is the ‘Frame Delay Time
ListenPoll’, however the values are different as the NFC Forum specifications include the duration
for the ‘Preamble’ of the NFC-F frame.

The guard time of media is defined in the FeliCa specification as follows:
For normal commands except for the Polling command
The terminal shall not send any commands during the guard time (approx. 501 μs), which starts at the endof the last response that was received.
Starting point

Preamble

Sync

Response

Preamble

CRC

Sync

Command

CRC
Time tGuard time of media

Guard time of media = (106 × 64 ＋ 16) / fc = approx. 501μs）
Quoted from FeliCa Card User’s Manual Excerpted Edition Ver2.01 P.20
Japan Electronic-money Promotion Association29

C-4: Guard time (Continued)
The guard time of media is defined in FeliCa specification as follows:
For Polling
The terminal shall not send any command within a maximum response time of a Polling command plus theguard time of media.
Starting point

Preamble

Sync

Command

CRC

．．．
．．．

PollingcommandPreamble

Sync

Command

CRC

Time tTimeslot
duration（＃N-1）
256 x 64 / fc

Timeslot
duration（＃N）
256 x 64 / fc

Guard timeof media

Command

Polling maximum response time = Polling response time + num of slots x timeslot duration
Polling response time = 512 x 64 / fc (approx. 2.417 ms)
Timeslot duration = 256 x 64 / fc (approx. 1.208 ms)
Guard time of media = (106 x 64 + 16) / fc (approx. 501 μs)

Quoted from FeliCa Card User’s Manual Excerpted Edition Ver2.01 P.21

Japan Electronic-money Promotion Association

30

Bibliography
Development Guidelines for NFC/FeliCa-Enabled Devices
https://www.sony.net/Products/felica/business/tech-support/index.html#FeliCa03

Best practice White paper: NFC-F Device Detection
https://www.sony.net/Products/felica/business/tech-support/index.html#NFC03

NFC Forum Specifications
https://nfc-forum.org/our-work/specifications-and-application-documents/specifications/specification-releases/

Japan Electronic-money Promotion Association31