ISO/TR 14806:2013

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 2013
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

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
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

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 ).
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.
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

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.
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

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.
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’acheter/le demander en ligne en vue de le retirer ultérieurement auprès d’un
distributeur de billets.
6 © ISO 2013 – Tous droits réservés

— Une fois que la transaction est acceptée, le paiement effectué si nécessaire, et que le client se trouve à
un terminal de chargement approprié, lequel peut être à l’entrée, le titre est chargé dans l’application
de paiement à partir du terminal.
— Le client utilise le titre détenu dans l’application de paiement aux points de validation afin d’accéder
à l’entrée ou à la sortie, en fonction de la règle de validation d’entrée ou d’entrée/sortie de l’OTP, et
présente à la demande le support avec l’application de paiement pour le contrôle des titres de transport.
5.2.3 Commentaires
Le chargement du titre d’OTP est habituellement réalisé sur un équipement de l’OTP. Il peut également
être réalisé sur un équipement bancaire. Cette transaction est hors du domaine d’application de la
présente version du Rapport technique, car il n’y a pour le moment aucune demande de normalisation
identifiée à ce sujet.
Les systèmes, données et titres de TP sont propres à l’OTP et peuvent être interopérables.
Les formats existants de données des titres d’OTP peuvent nécessiter une adaptation pour pouvoir être
utilisés malgré les capacités de stockage limitées offertes par les ZDT.
Les données de TP peuvent inclure des données de personnalisation, des contrats de transport, des
droits à réduction ou des remises propres à l’OTP.
Si l’application de paiement contient un droit à réduction ou un droit propre à l’OTP, il est utilisé par le
système de TP lorsque le client utilise l’application de paiement lors de l’achat du billet ou du contrôle
des titres de transport.
5.3 Cas d’utilisation 3: Paiement de trajets uniques à la validation
5.3.1 Objectifs
— [Obj.1] solution pour le stockage d’un titre de transport local,
— [Obj.2] remplacement du moyen de paiement du billet à l’entrée,
— [Obj. 3] méthode fluide et universelle pour permettre aux utilisateurs occasionnels d’accéder aux
réseaux de transport.
5.3.2 Parcours client
— Lorsque le prix n’est pas fixe/unique, la validation avant embarquement peut nécessiter que
le client/porteur de carte sélectionne la zone de voyage, ou que le client entre en contact avec le
conducteur qui sélectionne le titre/prix. Le voyage est limité aux trajets uniques seulement.
— Le client utilise l’application de paiement aux points de validation afin d’accéder à l’entrée ou à la
sortie, en fonction de la règle de validation d’entrée ou d’entrée/sortie du TP local, et présente à la
demande le support avec l’application de paiement pour le contrôle des titres de transport.
— Le prix du voyage peut être fixe ou calculé avant le voyage en fonction d’une tarification fondée sur
l’itinéraire, la distance, la zone ou l’horaire, ou sur la base d’une combinaison de ces cinq possibilités,
et selon les règles de tarification en vigueur.
— Pour les réseaux de transport avec règle de validation d’entrée:
— Le prix du voyage est connu ou calculé à la validation d’entrée;
— Le paiement sans contact est effectué au moment de la validation d’entrée;
— L’OTP demande le règlement après validation pour chaque trajet individuel.
— Pour les réseaux de transport avec règle de validation d’entrée/sortie:
— Le prix du voyage est connu ou calculé à la validation de sortie, la signification de la validation
de sortie étant déterminée par l’OTP dans ses règles billettiques;
— Le paiement sans contact est effectué au moment de la validation de sortie;
— L’OTP demande le règlement après validation pour chaque trajet individuel.
5.3.3 Commentaires
L’application de paiement est utilisée à la fois pour la validation et le paiement du voyage.
Pour les réseaux de transport avec règle de validation d’entrée, les propositions de titre tarifaire seront
limitées de manière significative pour les porteurs d’application de paiement, à moins qu’une sélection
du titre ne soit proposée à la validation d’entrée (par le conducteur du bus/tram ou par une interface sur
le terminal de validation).
Pour les réseaux de transport avec règle de validation d’entrée/sortie, les propositions de titre tarifaire
peuvent être plus variées, notamment avec une facturation fondée sur la distance ou l’itinéraire, mais il
convient d’éviter les ajustements tarifaires « négatifs » à la validation de sortie, car aucun remboursement
hors ligne n’est possible via une application sans contact. Selon le schéma de paiement, les cartes avec
autorisation en ligne peuvent ne pas être acceptées et, si elles le sont, nécessitent une réduction des
risques supplémentaire via un processus d’autorisation différé spécifique.
Les transactions en ligne et en temps réel doivent être évitées, à moins que l’équipement au sol ou la
capacité de communication ne soit compatible avec les exigences de temps de traitement demandées.
La plupart des transactions de paiement pour les applications de paiement sans contact EMV seront
réalisées hors ligne, à condition que le prix facturé reste inférieur à la limite de dépense hors ligne de
l’application de paiement.
La règle de non validation n’est pas pertinente pour ce cas d’utilisation et se trouve hors du domaine
d’application.
5.3.4 Management du risque
Un client peut ne pas savoir dans quelle mesure il est proche des limites de dépenses hors ligne de sa
carte lorsqu’il voyage, et peut être confronté à un rejet au point de paiement (par exemple en montant
dans un bus).
Lorsque les limites du compteur de l’application de paiement sont atteintes, il convient que l’OTP soit en
mesure d’accepter la transaction sur la base de mesures de management du risque supplémentaires (par
exemple, listes blanches, favoris) et de la soumettre à une autorisation différée. Cela peut présenter un
risque commercial potentiel pour l’OTP, étant donné que le paiement d’une transaction rejetée/forcée
n’est pas garanti par les règles actuelles des schémas de paiement et doit faire l’objet d’une négociation
OTP/acquéreur.
5.4 Cas d’utilisation 4: Paiement après une période
5.4.1 Objectifs
— [Obj.1] solution pour le stockage d’un titre de transport local;
— [Obj.2] remplacement du paiement du billet à l’entrée;
— [Obj.3] méthode fluide et universelle pour permettre aux utilisateurs occasionnels d’accéder aux
réseaux de transport.
8 © ISO 2013 – Tous droits réservés

5.4.2 Parcours client
— Le client utilise l’application de paiement aux points de validation afin d’accéder à l’entrée ou à la
sortie, en fonction de la règle de validation d’entrée ou d’entrée/sortie de l’OTP, et présente à la
demande le support avec l’application de paiement pour le contrôle des titres de transport.
— L’OTP demande le règlement du prix total des voyages après une période définie.
5.4.3 Commentaires
L’application de paiement est utilisée à la fois pour la validation et le paiement du voyage.
Ce cas d’utilisation peut s’appliquer aux réseaux de transport avec règle de validation d’entrée ou règle
de validation d’entrée/sortie.
La règle de non validation n’est pas pertinente pour ce cas d’utilisation et n’est pas considérée.
Le prix du voyage de chaque trajet peut être fixe ou calculé en fonction d’une tarification fondée sur
l’itinéraire, la distance, la zone ou l’horaire, ou sur la base d’une combinaison de ces cinq possibilités, et
selon les règles de tarification en vigueur.
Le prix effectivement facturé au client est calculé en arrière-guichet pour une période qui dépend des
règles de tarification. Des prix avantageux ou plafonnés au cours de la période peuvent être proposés. Il
est également possible de prendre en compte les titres préachetés avec la même application de paiement
ou avec des applications de paiement associées durant le calcul du prix par l’arrière-guichet. Dans ce
cas, seuls les trajets effectués en dehors du titre de voyage préacheté sont facturés sur le compte de
l’application de paiement.
Selon le schéma de paiement, les cartes avec autorisation en ligne peuvent ne pas être acceptées et, si elles le
sont, nécessitent une gestion de risques supplémentaire via un processus d’autorisation différé spécifique.
5.4.4 Management du risque
Pour une application de paiement sans contact EMV, les montants des transactions certifiées
cryptographiquement par l’application de paiement à la validation d’entrée ou de sortie seront
probablement différents du montant calculé par l’arrière-guichet et utilisé pour le règlement après la
période ou utilisé pour une autorisation différée.
Le strict plafond de dépense hors-ligne sans vérification du porteur de carte peut alors ne pas
nécessairement s’appliquer, mais d’autres limites peuvent être imposées en fonction des règles liées au
schéma/marque de paiement, qui s’appliquent par l’intermédiaire du contrat avec l’acquéreur.
Cela peut présenter un risque commercial potentiel pour l’OTP qu’il convient de couvrir via une
autorisation de paiement différée et qu’il convient qu’il fasse l’objet d’une négociation OTP/acquéreur. Il
est fortement recommandé d’utiliser des listes de refus dans les équipements de validation en entrée,
afin de gérer ce risque commercial. Cela permet de refuser le service aux applications de paiement
n’ayant pas eu d’autorisation de paiement lors d’un précédent trajet.
5.5 Cas d’utilisation 5: Authentification du client avec l’application de paiement
5.5.1 Objectifs
— [Obj.4] Utiliser l’application de paiement pour l’authentification du client dans le système
billettique transport.
5.5.2 Parcours client
— Le client
— s’enregistre une fois auprès de l’OTP en fournissant des données de son application de paiement
qui lui permettent d’être identifié de manière unique via son application de paiement et accepte
d’être facturé après utilisation, ou
— préachète un titre de transport avec son application de paiement et accepte que son application
de paiement soit inscrite sur une «liste blanche», ou
— s’enregistre pour une combinaison de titres prépayés et de dispositions de post-paiement pour
les voyages effectués en dehors de son titre préacheté.
Le client utilise l’application de paiement aux points de validation afin d’accéder à l’entrée ou à la sortie,
en fonction des règles de validation d’entrée ou d’entrée/sortie de l’OTP, et présente à la demande le
support avec l’application de paiement pour le contrôle des titres de transport.
Pour les clients s’étant enregistrés à une disposition de post-paiement:
— Le prix est calculé après validation.
— L’OTP demande le règlement après validation pour chaque trajet individuel ou le règlement du prix
total des voyages après une période définie. Le règlement est effectué en utilisant les moyens de
paiement enregistrés par l’OTP durant l’inscription du client, et pas nécessairement en utilisant les
données de l’application de paiement.
— Pour les clients qui ont enregistré des titres prépayés:
— La validité du titre de transport est contrôlée à chaque validation d’entrée et l’accès est refusé
en cas d’échec du contrôle.
5.5.3 Commentaires
Toutes les règles de validation sont permises pour ce cas d’utilisation.
Ce cas d’utilisation pour les clients recourant au post-paiement diffère du cas d’utilisation 4 par le fait
que le paiement soit effectué non pas avec le compte associé à l’application de paiement, mais d’une
manière différente (par exemple un prélèvement direct sur le compte du client), ce qui rend le type
d’instrument de paiement employé dans ce processus moins normatif. Cependant, les schémas de
paiement interdisent l’utilisation de leurs applications de paiement dans ce but.
6 Exigences pour les applications de paiement utilisées comme billets dans
les transports
Les attentes des TP décrites dans les cas d’utilisation, principalement pour le contrôle des titres de
transport et le calcul des tarifs par le système de validation d’entrée/sortie, peuvent être satisfaites plus
simplement par les systèmes billettique transport avec terminaux de validation hors-ligne à condition
que des données puissent être stockées dans l’application de paiement.
Donc, les TP tirent avantage de la possibilité de stocker des données de transport public dans les
applications de paiement.
10 © ISO 2013 – Tous droits réservés

6.1 Options de stockage des applications de paiement
Le présent paragraphe décrit trois niveaux d’exigences en fonctions des niveaux de stockage de données
pouvant être assurés par les applications de paiement.
NOTE Même si l’approche liée au journal des transactions (voir 6.3 pour une description détaillée) repose
sur des fonctions existantes définies par les normes EMVCo pour les paiements avec contact, elle nécessite des
mécanismes qui ne sont pas encore mis en œuvre dans les applications de paiement sans contact actuelles mises
en œuvre par les schémas de paiement. Sachant cela, il est peu probable de voir le journal des transactions devenir
une solution universelle, mais cela peut rester une option en tant que solution nationale.
6.2 Application de paiement sans aucune donnée de transport public
6.2.1 État de la technique
Il s’agit du contexte actuel, avec l’utilisation des applications de paiement existantes.
6.2.2 Commentaires
Dans ce contexte, il n’y a pas d’exigence supplémentaire pour l’application de paiement.
Cependant, il convient qu’elle soit configurée pour prendre en charge les transactions de valeur nulle.
Cela permet à un terminal de paiement de réaliser l’authentification hors-ligne d’une application de
paiement sans risquer un rejet d’autorisation lié au montant ou nécessiter une demande d’autorisation
en ligne (voir [Req. 16] ci-dessous).
Cette exigence s’applique également aux applications de paiement avec journal des transactions et
ZDT, car cette transaction permet à tout terminal d’inscrire des informations dans une application de
paiement au cours de la validation d’entrée, lorsque le prix est calculé à la validation de sortie.
6.3 Application de paiement avec journal des transactions de paiement
6.3.1 État de la technique
Le journal des transactions de paiement est un processus spécifié par EMVCo pour les transactions de
paiement avec contact. Sa présence dépend de la décision de l’émetteur de l’application de paiement, qui
ne peut être prise qu’au moment de l’émission de l’application de paiement.
Il convient cependant que les OTP ne s’attendent pas à ce que toutes les applications de paiement soient
munies de journaux des transactions.
Le journal des transa
...