ISO/TR 14806:2013
(Main)Intelligent transport systems — Public transport requirements for the use of payment applications for fare media
Intelligent transport systems — Public transport requirements for the use of payment applications for fare media
Systèmes intelligents de transport — Exigences pour les transports publics relatives à l'utilisation d'applications de paiement pour les moyens de perception du prix du voyage
L'ISO/TR 14806:2013 définit les exigences du secteur des transports publics vis‑à‑vis des émetteurs d'applications de paiement afin qu'ils puissent spécifier leurs applications de façon qu'elles soient utilisables comme un outil permettant d'accéder aux réseaux de transport, au moyen de systèmes billettique transport dont l'architecture est orientée soit sur le support, soit sur l'arrière-guichet, pour les utilisateurs non locaux et occasionnels comme pour les utilisateurs réguliers. L'ISO/TR 14806:2013 définit les prérequis exigés, qu'ils soient d'ordre technique ou non.
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/TR
REPORT 14806
First edition
2013-07-15
Intelligent transport systems — Public
transport requirements for the use of
payment applications for fare media
Systèmes intelligents de transport — Exigences pour les transports
publics relatives à l’utilisation d’applications de paiement pour les
moyens de perception du prix du voyage
Reference number
ISO/TR 14806:2013(E)
©
ISO 2013
---------------------- Page: 1 ----------------------
ISO/TR 14806:2013(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TR 14806:2013(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Terms and definitions . 1
3 Symbols and abbreviated terms . 3
3.1 CNP . 4
3.2 HHT . 4
3.3 PAN . 4
3.4 PT . 4
3.5 PTO . 4
3.6 TDA . 4
3.7 TR . 4
3.8 ZVT . 4
4 Objectives and general requirements for the PTO . 5
5 Use cases . 5
5.1 Use case 1: Product purchase for loading on customer media . 6
5.2 Use case 2: Access with PTO product data in payment application . 6
5.3 Use case 3: Pay single journeys on validation . 7
5.4 Use case 4: Pay after a period . 8
5.5 Use case 5: Entitlement with payment application . 9
6 Requirements for payment applications used in transport ticketing .10
6.1 Payment application storage options .10
6.2 Payment application without any public transport data .10
6.3 Payment application with payment transaction logs .10
6.4 Payment applications with transit data areas (TDAs) .12
6.5 Supported transaction types .14
7 Matching between use cases, validation access rules and payment application types .16
7.1 Revenue protection and inspection .18
8 Security of payment applications.18
9 Condition for use in a multi-application context .19
9.1 Using payment application in a multi-application media .19
9.2 PTO Participation in the life cycle management of payment applications .19
9.3 Payment application selection.19
10 Test and certification of payment applications .20
10.1 Ease of integration into front end equipment .20
10.2 RF protocol testing .20
10.3 (SE) payment application certification .20
10.4 Terminal payment application certification .21
10.5 Transaction time .22
11 Customer data privacy .22
Annex A (informative) Business rules checklist for using payment applications .23
Annex B (informative) Options for providing interoperability between PTOs B.1: Background .28
Bibliography .30
© ISO 2013 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TR 14806:2013(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
iv © ISO 2013 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TR 14806:2013(E)
Introduction
For several years, payment institutions have started to roll out worldwide contactless payment cards.
These cards support a contactless interface in addition to a contact interface or magstripe.
Where made available by Payment Application Issuers, these cards might be used by the Public transport
industry for accessing the transport networks for specific use cases and customer groups. To facilitate
payment application usage, the Public transport industry will benefit from data storage within the
payment application, but this data storage capability is not a compulsory prerequisite as some Public
transport Operators (PTOs) will start accepting payment application without such data storage facilities.
This Technical Report describes the current state of the art in a fast changing subject domain. It should not
be used as the primary basis for system procurements. It describes PTO requirements for the ways that
payment cards, or more specifically, payment applications (see Notice below), can be used by the PTOs
to serve specific customer needs. The PTO requirements expressed in this Technical Report aim at being
applicable to all payment application scheme/brand specifications for, and only for, the listed use cases
in this Technical Report. For the use cases primarily based on the contactless interface, this Technical
Report describes the functions needed by the Public transport industry and provides requirements from
PTOs to the payment industry. Note that not all PTO requirements are currently available and some
will require further discussion between the payment industry and PTOs, possibly leading to further
developments in the availability and use of payment application functions. This Technical Report will be
updated according to ISO procedures to reflect the evolution of PTO requirements and the corresponding
level of functionality afforded by the payment industry. It assumes that any available data storage space
will allow the storage of limited information only but may not be able to host fare products as they are
defined today for ticketing applications (e.g. it might not be sensible to store a season ticket in a record
that might be overwritten).
This Technical Report has been designed to provide ticketing and payment system designers who wish
to accept payment applications with a clear definition of what usage options are available from these
payment applications. It describes the functional interface to the payment application, with the aim of
facilitating the design and procurement of fare collection systems.
Annexes A and B also provide:
— a checklist of commercial issues that need to be addressed by Public transport (PT), usually under
a contract with a bank providing merchant acquiring services;
— options for providing interoperability between fare payment schemes that use bank issued payment
applications, including proposals for any concomitant changes to those payment applications and
payment application scheme rules.
NOTICE: The term “Payment application” used in this Technical Report refers to both an
application resident either in a conventional payment card or an application loaded into a multi-
[3]
application customer media (as described in ISO/TR 24014-3 ).
© ISO 2013 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/TR 14806:2013(E)
Intelligent transport systems — Public transport
requirements for the use of payment applications for fare
media
1 Scope
This Technical Report defines the requirements from public transport for payment application owners
to specify their application to make payment application media accepted as a tool to access the public
transport networks by means of either media centric or back-office centric fare management systems,
for non-local and non-frequent users as well as regular users.
This Technical Report defines both technical and non-technical requirements needed.
Four main items have been identified:
— Discrepancies between the existing payment application scheme rules and PTOs expectations.
— Definition of a short lifecycle storage area (scratchpad) which may support Check-In/Check-Out
access and inspection processes.
— Definition of a long life cycle storage area (product area) to store a transport and other products
within the payment application.
— Condition for use in a multi-application context, when different payment and transport applications
are implemented in the same medium.
This Technical Report describes the requirements for:
— Level of Security and associated trust model;
— Conditions for the use of the specific storage area and the overwriting of products or data.
This Technical Report does not describe commercial issues which have to be defined for an implementation
and may differ from place to place, e.g.:
— From Media Owner to Customer;
— From Media Owner to Application Owners;
— From Payment Application owner to customer;
— From Payment Application Owner to Public transport;
— From Public transport to Customer.
The first cases addressed by this Technical Report are EMV contactless applications and those variants
(not strictly EMV) with application storage. All other payment applications (e.g. contactless magstripe
emulation) will be addressed potentially in a future version of this Technical Report.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply:
© ISO 2013 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TR 14806:2013(E)
2.1
acquirer (or acquiring bank)
payment institution having a contract with the merchant for handling the remittance and settlement of
transit fares charged to customers using the transport network
Note 1 to entry: Merchant in this Technical Report is Public Transport Operator (PTO).
Note 2 to entry: The acquirer may accept payments using payment applications from one or more payment
application issuers, and/or for one or more payment application schemes/brands.
2.2
cardholder
holder of the payment application
Note 1 to entry: The cardholder has a contract with the issuer of its payment application. The media hosting the
payment application may not necessarily be a “card“.
2.3
certification
certification applicable to payment application, payment media and payment terminals, as required by
the banking industry stakeholders, e.g. EMVCo, payment schemes
2.4
card-not-present transaction
CNP transaction
payment transaction where neither the card nor its holder are present at the point of sale
EXAMPLE Orders by telephone, fax or the Internet.
2.5
EMV Contactless Application
payment schemed defined applications relying on EMV technology
Note 1 to entry: As opposed to a payment scheme application relying on magstripe emulation.
Note 2 to entry: This is the type of payment application.
2.6
issuer
payment application issuer
payment institution having a contract with the cardholder and issuing the payment application on a
contactless media
Note 1 to entry: The issuer issues payment applications such as credit or debit cards and guarantees payment for
properly authorized transactions using the payment application.
2.7
merchant
entity having the necessary terminal equipment for handling payment transaction at validation points
Note 1 to entry: In this Technial Report, merchants are Public Transport Operators (PTOs).
2.8
payment application
application resident either in a conventional payment card or an application loaded into a multi-
application customer media
[3]
Note 1 to entry: As described in ISO/TR 24014-3.
2 © ISO 2013 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TR 14806:2013(E)
2.9
payment interoperability
acceptance of payment application at the merchant point of sales whatever the payment application
issuer is and whatever the merchant acquirer is
Note 1 to entry: Payment interoperability is ensured by rules and certification process enforced at each payment
application scheme level and by EMVCo.
2.10
payment application scheme
payment brands that establish industry operating regulations for acquirers and issuers to facilitate
coordination with merchants and cardholders
Note 1 to entry: Payment application schemes can have international scope (VISA, MasterCard, JCB Intl) or a
domestic one (ZKA, GIE Carte Bancaire).
2.11
public transport
general statement about the transit industry
2.12
public transport operator
local specific implementation, independently of any difference between the roles of authorities, operators
or retailers in fare management systems as defined in ISO 24014-1
2.13
transit data storage
standard logical data storage within the payment application available for transit ticketing operations,
even if this storage is open to other merchants
Note 1 to entry: Transit data storage can take two implementation forms that determine their life cycle: included
in the payment transaction log; separate, and available for non-payment needs.
Note 2 to entry: In the context of this Technical Report, the word transit data area (TDA) designates such a
dedicated storage.
2.14
ticketing interoperability
technical interoperability provided by the usage of the same format for writing transit data in the
payment application
Note 1 to entry: In the context of this Technical Report, ticketing interoperability is considered an optional requirement.
2.15
validation
transaction made with payment transaction equipment for confirming the validity of a payment
transaction product or for enabling access to the transport network by realizing a payment transaction
2.16
zero value (payment) transaction
offline transaction at the reader for a null amount
EXAMPLE Null amount, e.g. £0.00 or 0€ or 0USD.
Note 1 to entry: This transaction may not be possible on all cards now.
3 Symbols and abbreviated terms
For the purposes of this Technical Report, the following symbols and abbreviations apply:
© ISO 2013 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TR 14806:2013(E)
3.1 CNP
Card-not-present
3.2 HHT
Hand-held Terminal (used for revenue inspection)
3.3 PAN
Primary Account Number
3.4 PT
Public Transport
3.5 PTO
Public Transport Operator
3.6 TDA
Transit Data Area
3.7 TR
Technical Report
3.8 ZVT
Zero Value Transaction
4 © ISO 2013 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TR 14806:2013(E)
4 Objectives and general requirements for the PTO
PTOs motivations for using the payment applications as a fare media can serve different objectives:
— [Obj.1] To offer a solution for local transit product storage:
— Using payment application as a fare media can, in some cases, remove the need (and cost) for
PTO to distribute ticketing application and/or customer media.
— [Obj.2] To replace cash as a fare payment at the gate
— Using payment application as a fare media can replace cash payment at the gate or at bus/tram
entry by electronic payment.
— [Obj.3] To provide a seamless and universal way of providing access to the transport network for
infrequent users
— Using payment application as a fare media can offer PTOs a complement to their existing
ticketing application covering the needs of frequent customers, which by nature don’t hold their
ticketing application,
— [Obj.4] To enable a third party application used for customer authentication in the fare
management system
— Using payment application as a fare media can allow customer authentication via their payment
application in post payment fare management system and avoid the issuance of transport media
for registered customers.
The corresponding use cases are described in (Clause 5):
The Public transport requirements that make them possible address the following elements:
— Requirements for payment applications used in transport ticketing (Clause 6)
— Application security in payment applications (Clause 8)
— Customer media requirements (Clause 9)
— Test and certification of payment applications (Clause 10)
— Customer data privacy (Clause 11)
These PT requirements are also completed by explanations about how payment applications can be
used and what fare policy can be implemented according to the use cases and validation access rules
applicable in a transport network (Clause 7).
Beyond the scope of this Technical Report, a first level of analysis is also given for guidance in annexes about:
— business rules checklist for using payment applications (Annex A);
— options for providing national and international ticketing interoperability (Annex B).
NOTE Where interoperability is achieved by means of the basic contactless payment application without
transit data storage, there is no need for any ticketing data to be interoperable.
5 Use cases
Payment applications can be used in a number of ways for transport ticketing, as determined by the PTO
and subject to suitable agreement in the merchant acquiring contracts.
The generic ways are defined in the following use cases which can eventually be complemented by
national interoperable fare management applications.
© ISO 2013 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/TR 14806:2013(E)
In the description of the use cases, three possible validation access rules to the transport networks
are considered:
— non validation rule:
— customers should have an entitlement to travel, but are not required to validate at any stage of
the journey although they may be subject to revenue protection control.
— entry validation rule:
— customers are required to validate only on entry.
— entry/exit validation rule:
— customers should validate both on entry and exit, and possibly at intermediate validation points.
These different validation access rules will structure the way payment applications can be used in
transport networks as described in the following use cases and further analysed in Clause 7.
5.1 Use case 1: Product purchase for loading on customer media
5.1.1 Objective
This use case is the conventional one where a customer selects a product from a retailer and uses a
payment application to pay for the product. The payment application can be used in contact mode,
contactless mode or in cardholder not present mode. The payment options vary according to mode.
5.1.2 Customer path
— The customer selects a product.
— The customer pays with a payment application.
— The PTO product is not loaded to the payment application.
— The PTO product is loaded onto the PTO media and application.
— The customer travels and validates using the PTO’s entry or entry/exit ticketing system.
5.1.3 Comments
This use case is conventional and well defined and is therefore out of the scope of this Technical Report
although included here for completeness.
5.2 Use case 2: Access with PTO product data in payment application
5.2.1 Objective
— [Obj.1] payment application as a solution for local transit product storage.
5.2.2 Customer path
— The customer should first purchase or request a product from his/her PTO at a suitable ticket
machine or should purchase or request online for later collection at a ticket machine.
— Once the transaction is accepted, payment made if required, and the customer is at a suitable
loading terminal, which can be the entry gate, the product is loaded from the terminal into the
payment application.
6 © ISO 2013 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TR 14806:2013(E)
— The customer uses the product held in the payment application at points of validation to gain entry
and exit, according to the PTO’s entry or entry/exit validation rule and presents the medium with
the payment application when requested for revenue inspection.
5.2.3 Comments
The PTO product loading is commonly carried out on PTO equipment. It may also be carried out on
bank equipment. This operation is out of the scope of this version of the Technical Report as there is no
identified demand yet for standardising it.
PT systems, data and products are PTO-specific and may be interoperable.
Existing PTO product data format may need to be adapted to cope with the limited storage capacity
provided by the TDA.
PT data can include PTO-specific personalisation data, travel ticket, discount entitlement or concession.
If the payment application holds a PTO-specific discount entitlement or entitlement, it will be used by PT
system when the customer uses the payment application during ticket purchase or revenue inspection.
5.3 Use case 3: Pay single journeys on validation
5.3.1 Objectives
— [Obj.1] solution for local transit product storage,
— [Obj.2] replacement of fare payment at the gate,
— [Obj.3] seamless and universal way of providing access to the transport network for infrequent users.
5.3.2 Customer path
— Where the fare is not fixed/flat, validation prior to boarding may require the customer/cardholder
to select zone of travel or customer engages with driver who selects product/fare. Travel is limited
to single journeys only.
— The customer uses the payment application at points of validation to gain access and exit, according
to the local PT entry or entry/exit validation rule and presents the medium with the payment
application when requested for revenue inspection.
— The travel price may be flat or be calculated prior to travel depending on the route or distance or
zonal or time-based pricing, or be a mixture of the five and depending on the tariff rules.
— For transport networks with entry validation rule:
— The travel price is known or calculated on entry validation,
— Contactless payment is made at the moment of entry validation,
— The PT Operator requests settlement after validation for each individual journey.
— For transport networks with entry/exit validation rule:
— The travel price is known or calculated at exit validation, the meaning of exit validation being
determined by the PTO in its ticketing rules,
— Contactless payment is made at the moment of exit validation,
— The PT Operator requests settlement after validation for each individual journey.
© ISO 2013 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/TR 14806:2013(E)
5.3.3 Comments
The payment application is used for both travel validation and payment.
For transport network with entry validation rule, fare products proposal will be significantly limited
for payment application holders unless a product selection is proposed at the entry validation (by the
driver on bus/tram or by an interface on validation terminal).
For transport network with entry/exit validation rule, fare products proposal can be more comprehensive
including distance or route based charging, but “negative” price adjustment on exit validation should
be avoided as no offline refunds are possible via a contactless transaction. Depending on the payment
application scheme, online authorization cards may not be accepted and where accepted will require
extra risk mitigation via a specific deferred authorization processes.
Online real-time tra
...
RAPPORT ISO/TR
TECHNIQUE 14806
Première édition
2013-07-15
Systèmes intelligents de transport —
Exigences pour les transports publics
relatives à l’utilisation d’applications
de paiement pour les moyens de
perception du prix du voyage
Intelligent transport systems — Public transport requirements for the
use of payment applications for fare media
Numéro de référence
ISO/TR 14806:2013(F)
©
ISO 2013
---------------------- Page: 1 ----------------------
ISO/TR 14806:2013(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2013
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2013 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/TR 14806:2013(F)
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Termes et définitions . 1
3 Symboles et abréviations . 3
3.1 CNP . 4
3.2 PDC . 4
3.3 PAN . 4
3.4 TP . 4
3.5 OTP . 4
3.6 ZDT . 4
3.7 TR . 4
3.8 TVN. 4
4 Objectifs et exigences généraux pour les OTP . 4
5 Cas d’utilisation . 5
5.1 Cas d’utilisation 1: Achat d’un titre pour chargement sur support client. 6
5.2 Cas d’utilisation 2: Accès avec les données du titre de transport dans l’application
de paiement . 6
5.3 Cas d’utilisation 3: Paiement de trajets uniques à la validation . 7
5.4 Cas d’utilisation 4: Paiement après une période . 8
5.5 Cas d’utilisation 5: Authentification du client avec l’application de paiement . 9
6 Exigences pour les applications de paiement utilisées comme billets dans les transports 10
6.1 Options de stockage des applications de paiement .11
6.2 Application de paiement sans aucune donnée de transport public .11
6.3 Application de paiement avec journal des transactions de paiement .11
6.4 Applications de paiement avec zones des données de transport (ZDT) .13
6.5 Types de transactions pris en charge .15
7 Correspondance entre cas d’utilisation, règles de validation d’accès et types d’application
de paiement .17
7.1 Protection et contrôle des titres de transport .20
8 Sécurité des applications de paiement .21
9 Conditions pour l’utilisation dans un contexte multi-applicatif .21
9.1 Utiliser une application de paiement dans un support multi-applicatif .21
9.2 Participation de l’OTP dans la gestion du cycle de vie des applications de paiement .21
9.3 Sélection de l’application de paiement .21
10 Essai et certification des applications de paiement .22
10.1 Facilité d’intégration dans les équipements frontaux .22
10.2 Essai du protocole RF .22
10.3 Certification d’application de paiement (SE) .23
10.4 Certification de terminal d’application de paiement .23
10.5 Durée des transactions .24
11 Protection des données relatives à la vie privée du client .25
Annexe A (informative) Liste de contrôle des règles commerciales pour l’utilisation d’applications
de paiement .26
Annexe B (informative) Options afin de fournir l’interopérabilité entre les OTP .32
Bibliographie .34
© ISO 2013 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/TR 14806:2013(F)
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (CEI) en ce qui concerne
la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/CEI, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/CEI, Partie 2, www.iso.
org/directives.
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant les
références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de l’élaboration
du document sont indiqués dans l’Introduction et/ou sur la liste ISO des déclarations de brevets reçues,
www.iso.org/patents.
Les éventuelles appellations commerciales utilisées dans le présent document sont données pour
information à l’intention des utilisateurs et ne constituent pas une approbation ou une recommandation.
Le comité chargé de l’élaboration du présent document est l’ISO/TC 204, Systèmes intelligents de transport.
iv © ISO 2013 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO/TR 14806:2013(F)
Introduction
Depuis plusieurs années, les établissements de paiement ont entrepris le déploiement à l’échelle mondiale
de cartes de paiement sans contact. Ces cartes prennent en charge une interface sans contact en plus
d’une interface à contact ou à bande magnétique.
Une fois mises à disposition par les émetteurs d’application de paiement, ces cartes pourraient être
utilisées par le secteur des transports publics afin de permettre l’accès aux réseaux de transport pour
des cas d’utilisation et des groupes de clients spécifiques. Afin de faciliter l’utilisation d’applications
de paiement, le secteur des transports publics pourra tirer avantage du stockage de données dans ces
applications. Toutefois, cette capacité à stocker des données n’est pas une condition sine qua non, étant
donné que certains opérateurs de transports publics commenceront à accepter des applications de
paiement dépourvues de telles fonctionnalités de stockage de données.
Le présent Rapport technique (TR) décrit l’état actuel des techniques dans un domaine qui évolue
rapidement. Il convient de ne pas l’utiliser en tant que seule base pour l’acquisition de systèmes. Il
décrit les exigences des opérateurs de transports publics (OTP), relatifs à la manière dont les cartes de
paiement ou, plus exactement, les applications de paiement [voir Nota Bene ci-dessous] peuvent être
utilisées par ces OTP pour répondre à des besoins clients spécifiques. Les exigences transport des OTP
figurant dans le présent TR visent à s’appliquer aux spécifications de tout schéma/marque de paiement
pour les cas d’utilisation qui sont énumérés dans ce TR (et uniquement ceux-ci). En ce qui concerne les
cas d’utilisation fondés sur les interfaces sans contact, ce TR décrit les fonctions dont a besoin le secteur
des transports publics et fournit des exigences transport émis par les OTP à l’adresse de l’industrie du
paiement. Il est à noter que les exigences transport des OTP ne sont pas tous disponibles actuellement
et certains d’entre eux nécessiteront d’être débattus de manière plus approfondie par l’industrie du
paiement et les OTP, ce qui pourra mener à de nouveaux développements concernant la disponibilité
et l’utilisation de fonctions liées à des applications de paiement. Ce TR sera mis à jour conformément
aux procédures de l’ISO afin de refléter l’évolution des exigences transport des OTP et le niveau de
fonctionnalité correspondant permis par l’industrie du paiement. Il part du principe que tout espace
de stockage de données disponible permettra uniquement le stockage d’informations limitées et sera
susceptible de ne pas pouvoir supporter les titres tarifaires tels qu’ils existent aujourd’hui pour des
applications billettiques (par exemple il ne serait pas judicieux de stocker un abonnement dans un
enregistrement qui pourrait être écrasé).
Le présent Rapport technique a été conçu pour fournir une définition claire des options d’utilisation
disponibles à partir des applications de paiement, à l’intention des concepteurs de systèmes billettique et
de paiement qui souhaitent autoriser ces applications. Il décrit l’interface fonctionnelle liée à l’application
de paiement, dans le but de faciliter la conception et l’acquisition de systèmes billettique transport.
Les Annexes A et B fournissent également:
— une liste de contrôle des questions commerciales qui doivent être abordées par les transports
publics (TP), habituellement dans le cadre d’un contrat passé avec une banque offrant des services
d’acquisition aux commerçants;
— des options afin de permettre l’interopérabilité entre les schémas billettiques recourant à des
applications de paiement émises par des banques, notamment des propositions relatives à toute
modification concomitante de ces applications de paiement et des règles du schéma de paiement associé.
NOTA BENE: Le terme «Application de paiement» employé dans le présent document peut se référer
soit à une application intégrée à une carte de paiement conventionnelle, soit à une application
[3]
chargée dans un support client multi-applicatif (tel que décrit dans l’ISO/TR 24014-3 ).
© ISO 2013 – Tous droits réservés v
---------------------- Page: 5 ----------------------
RAPPORT TECHNIQUE ISO/TR 14806:2013(F)
Systèmes intelligents de transport — Exigences pour les
transports publics relatives à l’utilisation d’applications de
paiement pour les moyens de perception du prix du voyage
1 Domaine d’application
Le présent Rapport technique définit les exigences du secteur des transports publics vis-à-vis des
émetteurs d’applications de paiement afin qu’ils puissent spécifier leurs applications de façon qu’elles
soient utilisables comme un outil permettant d’accéder aux réseaux de transport, au moyen de systèmes
billettique transport dont l’architecture est orientée soit sur le support, soit sur l’arrière-guichet, pour
les utilisateurs non locaux et occasionnels comme pour les utilisateurs réguliers.
Le présent Rapport technique définit les exigences requises, qu’elles soient d’ordre technique ou non.
Quatre éléments principaux ont été identifiés:
— Divergences entre les règles des schémas de paiement existants et les attentes des OTP.
— Définition d’une zone de stockage à court cycle de vie (mémoire bloc-notes) permettant de supporter
un accès avec validation en entrée/sortie et les processus de contrôle.
— Définition d’une zone de stockage à long cycle de vie (zone de titres) pour stocker des titres de
transport et d’autres titres dans l’application de paiement.
— Conditions pour une utilisation dans un contexte multi-applicatif, lorsque différentes applications
de paiement et de transport sont mises en œuvre dans le même support.
Le présent Rapport technique décrit les exigences liées
— au niveau de sécurité et au modèle de confiance associé,
— aux conditions pour l’utilisation de la zone de stockage spécifique et l’écrasement des titres ou des
données,
Le présent Rapport technique ne décrit pas les questions commerciales, qui sont à définir pour une mise
en œuvre et peuvent être différentes d’un endroit à l’autre, par exemple:
— Du propriétaire du support au client;
— Du propriétaire du support aux propriétaires d’application;
— Du propriétaire d’application de paiement aux clients;
— Du propriétaire d’application de paiement aux transports publics;
— Des transports publics au client.
Les premiers cas traités par le présent Rapport technique seront les applications sans contact EMV et leurs
dérivés (non strictement conforme à EMV) avec stockage d’application. Toutes les autres applications de
paiement (par exemple, émulation de bande magnétique sans contact) seront potentiellement traitées
dans une version ultérieure du présent Rapport technique.
2 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
© ISO 2013 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO/TR 14806:2013(F)
2.1
acquéreur
banque acquéreur
institution de paiement ayant un contrat avec le commerçant pour prendre en charge le paiement et le
règlement des titres de transport facturés aux clients qui utilisent le réseau de transport
Note 1 à l’article: l’opérateur de transports publics, dans le présent TR)
Note 2 à l’article: L’acquéreur peut accepter les paiements effectués au moyen d’applications de paiement provenant
d’un ou plusieurs émetteurs d’application de paiement, et/ou pour un ou plusieurs mécanismes/marques
d’applications de paiement.
2.2
porteur de carte
porteur de l’application de paiement
Note 1 à l’article: Le porteur de carte a un contrat avec l’émetteur de son application de paiement. Le support
hébergeant l’application de paiement n’est pas nécessairement une «carte».
2.3
certification
certification qui s’applique à l’application de paiement, au moyens de paiement et aux terminaux de paiement,
comme exigé par les parties prenantes de l’industrie bancaire, par exemple EMVCo, schémas de paiement
2.4
transaction «carte non présente»
transaction CNP
transaction de paiement où ni la carte ni le porteur de carte ne sont présents au point de vente
Note 1 à l’article: Commandes par téléphone, fax ou Internet.
2.5
application sans contact EMV
mécanisme défini d’applications de paiement reposant sur la technologie EMV
Note 1 à l’article: Par opposition au mécanisme d’applications de paiement reposant sur l’émulation de bande
magnétique.
Note 2 à l’article: Il s’agit du type d’application de paiement.
2.6
émetteur
émetteur de l’application de paiement
institution de paiement ayant un contrat avec le porteur de carte et émettant l’application de paiement
sur un support sans contact
Note 1 à l’article: L’émetteur émet des applications de paiement telles que des cartes de crédit ou de débit et
garantit le paiement des transactions dûment autorisées, effectuées à l’aide de l’application de paiement.
2.7
commerçant
Eentité disposant de l’équipement terminal nécessaire pour prendre en charge les transactions de
paiement à des points de contrôle
Note 1 à l’article: Les commerçants sont les opérateurs de transports publics dans le présent TR.
2.8
application de paiement
application intégrée à une carte de paiement conventionnelle ou application chargée dans un support
multi-applicatif du client
[3]
Note 1 à l’article: Tel que décrit dans l’ISO/TR 24014-3.
2 © ISO 2013 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO/TR 14806:2013(F)
2.9
interopérabilité du paiement
acceptation de l’application de paiement au point de vente du commerçant, quel que soit l’émetteur de
cette application de paiement et quel que soit l’acquéreur du commerçant
Note 1 à l’article: L’interopérabilité du paiement est garantie par des règles et des processus de certification
appliqués au niveau du chaque schéma de paiement et par EMVCo.
2.10
schéma de paiement
marques de paiement qui établissent des règles d’exploitation sectorielles pour les acquéreurs et
émetteurs, afin de faciliter la coordination avec les commerçants et les porteurs de cartes
Note 1 à l’article: Les schémas de paiement peuvent avoir une portée internationale (VISA, MasterCard, JCB Intl)
ou nationale (ZKA, GIE Carte Bancaire).
2.11
transports publics
énoncé général concernant le secteur des transports en commun
2.12
opérateur de transports publics
exécutant à l’échelle locale, indépendamment de toute différence entre le rôle des autorités, des opérateurs
ou des détaillants dans les systèmes billettique transport tels que définis dans l’ISO/CEI 24014-1
2.13
stockage des données de transport
système de stockage de données logiques standard se trouvant dans l’application de paiement,
disponible pour les transactions billettiques liées au transport, même si le stockage est ouvert aux
autres commerçants
Note 1 à l’article: Le stockage des données de transport peut s’appliquer de deux manières qui déterminent son
cycle de vie: il peut être inclus dans le journal des transactions de paiement, il peut être à part, et disponible pour
servir des besoins autres que le paiement.
Note 2 à l’article: Dans le contexte du présent Rapport technique, le terme zone des données de transport (ZDT)
désigne un tel type de stockage dédié.
2.14
interopérabilité billettique
interopérabilité technique fournie par l’utilisation du même format pour inscrire les données de
transport dans l’application de paiement
Note 1 à l’article: Dans le cadre du présent Rapport technique, l’interopérabilité billettique est considérée comme
une exigence facultative.
2.15
validation
transaction effectuée avec l’équipement des TP afin de confirmer la validité d’un titre de TP ou pour
permettre l’accès au réseau de transport par le biais d’une transaction de paiement
2.16
transaction (de paiement) de valeur nulle
transaction hors ligne sur le lecteur, pour un montant nul
EXEMPLE Montant nul comme 0,00 £, 0 €, 0 USD.
Note 1 à l’article: Cette transaction peut ne pas être possible sur toutes les cartes actuellement.
3 Symboles et abréviations
Pour les besoins du présent document, les symboles et abréviations suivants s’appliquent.
© ISO 2013 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO/TR 14806:2013(F)
3.1 CNP
La carte ou son porteur ne sont pas présents au point de vente.
3.2 PDC
Portable de contrôle (terminal utilisé pour le contrôle des titres de transport).
3.3 PAN
Numéro de compte principal
3.4 TP
Transports publics
3.5 OTP
Opérateur de transports publics
3.6 ZDT
Zone des données de transport
3.7 TR
Rapport technique
3.8 TVN
Transaction de valeur nulle
4 Objectifs et exigences généraux pour les OTP
Les motivations poussant les OTP à utiliser les applications de paiement en tant que support billettique
peuvent servir différents objectifs:
— [Obj.1] Offrir une solution pour le stockage d’un titre de transport local:
— Utiliser une application de paiement en tant que support billettique peut, dans certains cas,
supprimer la nécessité (et le coût associé) qui incombe à l’OTP de distribuer une application
billettique et/ou un support client.
— [Obj. 2] Remplacer l’argent liquide comme moyen de paiement du billet à l’entrée
— Utiliser une application de paiement en tant que support billettique peut remplacer le paiement
en liquide à l’entrée ou aux portes d’un bus/tram par un paiement électronique.
— [Obj. 3] Offrir une méthode fluide et universelle pour permettre aux utilisateurs occasionnels
d’accéder aux réseaux de transport
— Utiliser une application de paiement en tant que support billettique peut offrir aux OTP
un complément, leurs applications billettiques existantes couvrant les besoins des clients
4 © ISO 2013 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO/TR 14806:2013(F)
réguliers, mais, par nature, ne couvrant pas ceux des clients qui ne détiennent pas leur propre
application billettique.
— [Obj. 4] Autoriser une application tierce dans le système billettique transport pour
l’authentification du client
— Utiliser une application de paiement en tant que support billettique peut permettre
l’authentification du client via son application de paiement, dans le système billettique transport
et éviter l’émission d’un support billettique pour les clients enregistrés.
Les cas d’utilisation correspondants sont décrits à l’Article 6:
Les exigences des transports publics qui les rendent possibles traitent les éléments suivants:
— Exigences pour les applications de paiement utilisées comme billets dans les transports (Article 7)
— Sécurité d’application pour les applications de paiement (Article 8)
— Exigences pour le support client (Article 9)
— Test et certification des applications de paiement (Article 10)
— Protection des données relatives à la vie privée du client (Article 11)
Ces exigences transport sont également complétées par des explications concernant la façon dont les
applications de paiement peuvent être utilisées et quelle politique tarifaire peut être appliquée en
fonction des cas d’utilisation et des règles de validation d’accès applicables dans un réseau de transport
(Article 7).
Au-delà du domaine d’application du présent Rapport technique, un premier niveau d’analyse est
également fourni dans les annexes, à titre d’information, concernant:
— la liste de contrôle des règles commerciales pour l’utilisation d’applications de paiement (Annexe A);
— des options visant à permettre l’interopérabilité billettique nationale et internationale (Annexe B).
NOTE Lorsque l’interopérabilité est obtenue au moyen de l’application de paiement sans contact basique,
dépourvue de stockage des données de transport, il n’est pas nécessaire que les données billettiques soient
interopérables.
5 Cas d’utilisation
Les applications de paiement peuvent être utilisées de diverses manières pour la billettique liée au
transport, comme déterminé par l’opérateur de transports publics, et faire l’objet d’accords appropriés
dans les contrats d’acquisition du commerçant.
Les manières génériques sont définies dans les cas d’utilisation suivants, qui peuvent finalement être
complétés par des applications billettique transport nationales interopérables.
© ISO 2013 – Tous droits réservés 5
---------------------- Page: 10 ----------------------
ISO/TR 14806:2013(F)
Dans la description des cas d’utilisation, trois règles possibles de validation d’accès au réseau de
transport sont prises en considération:
— règle de non validation:
— les clients doivent posséder un titre de transport, mais ne sont pas tenus de le valider à une quelconque
étape de leur trajet, bien qu’ils puissent faire l’objet d’un contrôle de leur titre de transport.
— règle de validation d’entrée:
— les clients sont tenus de valider à l’entrée seulement.
— règle de validation d’entrée/sortie:
— les clients doivent valider à la fois à l’entrée et à la sortie, et éventuellement à des points de
validations intermédiaires.
Ces différentes règles de validation d’accès structurent la manière dont les applications de paiement
peuvent être utilisées dans les réseaux de transport, tel que cela est décrit dans les cas d’utilisation
suivants et analysé ensuite dans l’Article 7.
5.1 Cas d’utilisation 1: Achat d’un titre pour chargement sur support client
5.1.1 Objectif
Ce cas d’utilisation est le cas conventionnel, lorsqu’un client sélectionne un titre chez un détaillant et
utilise une application de paiement pour régler le titre. L’application de paiement peut être utilisée en
mode avec contact, sans contact ou en mode porteur non présent. Les options de paiement varient en
fonction du mode.
5.1.2 Parcours client
— Le client sélectionne un titre.
— Le client règle avec une application de paiement.
— Le titre d’OTP n’est pas chargé dans l’application de paiement.
— Le titre d’OTP est chargé dans le support et l’application de l’OTP.
— Le client voyage et valide en utilisant le système billettique d’entrée ou d’entrée/sortie de l’OTP.
5.1.3 Commentaires
Ce cas d’utilisation est conventionnel et bien défini, il est donc hors du domaine d’application du présent
Rapport technique, bien qu’il ait été inclus par souci d’exhaustivité.
5.2 Cas d’utilisation 2: Accès avec les données du titre de transport dans
l’application de paiement
5.2.1 Objectif
— [Obj.1] utiliser l’application de paiement comme solution pour le stockage d’un titre de transport local.
5.2.2 Parcours client
— Le client doit d’abord acheter ou demander un titre de son OTP auprès d’un distributeur de billets
approprié, ou doit l’ach
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.