Les limites de la DSP2

La limitation du périmètre aux seuls comptes de paiement

La DSP2, en tant que directive sur les services de paiement régit les opérations en ligne des acteurs de ces services uniquement sur les périmètres concernés qui sont les comptes intervenant dans les opérations de paiements.

Dans les faits cependant, les acteurs, et en particulier les agrégateurs, réalisent aujourd’hui des opérations sur l’ensemble des comptes des utilisateurs, notamment leurs comptes d’épargne. Un des enjeux de ces agrégateurs étant de fournir des services à valeur ajoutée touchant à l’ensemble de l’activité de l’utilisateur sur ses comptes : comptes courants, comptes d’épargnes, chèque, cartes, crédits, plan en actions, …

En réglementant uniquement sur l’accès aux comptes de paiement, la commission européenne et l’ABE mettent en lumière le fonctionnement des agrégateurs (rejeu des secrets de connexion utilisateurs) sans fournir une solution à l’ensemble des problématiques des échanges entre ces acteurs non bancaires (agrégateurs) et les banques.

Dans l’intérêt du développement des agrégateurs, des solutions devront donc être actées pour élargir cette législation. Par ailleurs, les travaux engagés par les banques dans le cadre de la DSP2 les ayant amenées à construire l’architecture nécessaire à l’exposition de services sur internet, une évolution de ces services à plus des comptes et à plus de services utilisateurs est probablement à venir.

Incompatibilité avec les standards existants

Contrairement à l’initiative OpenBanking UK, basé sur le standard reconnu du groupe de travail Financial API, au sein de la fondation OpenID, les nouveaux services offerts par les banques dans le cadre de la DSP2 se fondent sur des exigences réglementaires plutôt que sur des standards de sécurité établis.

Consentement utilisateur

Le consentement utilisateur est un bon exemple de cet éloignement entre le standard, ici OpenID Connect, et la réglementation.

La directive implique que le consentement de l’utilisateur à l’utilisation d’un ou plusieurs comptes pour un agrégateur :

• Doit être recueilli par le TPP (donc l’application qui va consommer les API) ;
• Doit être appliqué et vérifié par l’ASPSP (hébergeant les API).

Ceci est réalisé à rebours du standard OpenID Connect (implémenté dans le cadre de OpenBanking UK), dans lequel le consentement doit être recueilli par le service hébergeant les données et les API.

Cinématique authorization code

Mise en œuvre pour l’usage des AISP, la cinématique authorization code requiert une redirection de l’utilisateur de l’AISP vers le service d’authentification et de consentement de l’ASPSP, puis en retour une nouvelle redirection vers l’application de l’AISP.

Cette redirection peut être considérée comme un obstacle à l’utilisation des services comme le mentionne en exemple l’article 32 des RTS. En conséquence elle peut s’avérer illégale et des travaux sont en cours pour trouver des alternatives conformes ou non aux standards OAuth2.

L’acceptation de l’usage de cette cinématique pour les besoins de la DSP2 relève alors de chaque autorité nationale, ce qui a pour effet de limiter l’uniformisation européenne de ces interfaces. Actuellement, en France, l’ACPR a validé l’usage de cette redirection.

Figure 3: Les acteurs de la DSP2 en scène

Conclusion

Dans un environnement numérique en constante mutation, la DSP2 prend le parti de favoriser le développement des acteurs intermédiaires de services de paiement, pour mieux standardiser les échanges et apporter une meilleure ergonomie de navigation des utilisateurs et une meilleure sécurité des transactions.

Elle comporte des apports importants sur des sujets de sécurité, qui imposent des évolutions des SI bancaires : l’ouverture des services sur internet et le changement des moyens d’authentification sont en particulier un sujet compliqué pour les banques historiques.

Cet article Sécurité des opérations financières en ligne en 2020 : Quelles limitations à l’efficacité de la DSP2 ? (2/2) est apparu en premier sur RiskInsight.

Parallèlement, les chiffres de la fraude n’ont cessé de progresser, pour dépasser en 2014 les 500 millions d’euros détournés sur le plan national. Dans la plupart des cas, cette fraude est due à l’utilisation de numéros de carte volés.

Pour endiguer cette tendance, les principaux organismes émetteurs de cartes bancaires (dont Visa et MasterCard) ont décidé de fonder en 2005 le Payment Card Industry Security Standard Council, dont le porte-étendard demeure sans nul doute PCI DSS (Payment Card Industry Data Security Standard).

PCI DSS et la nébuleuse des responsabilités

Le standard PCI DSS s’applique à « toute entreprise qui stocke, traite ou transmet des données carte ». Cette définition englobe donc aussi bien les banques que les commerçants, ou encore les prestataires de service de paiement (PSP), qui ont de ce fait des comptes à rendre devant les réseaux émetteurs de cartes. Pour être conformes à PCI DSS, ces acteurs doivent ainsi respecter les 280 exigences de sécurité qui composent le standard, réparties autour de 12 thèmes de nature technique ou organisationnelle.

Il convient par ailleurs de noter qu’en France, le standard PCI DSS n’est pas une obligation légale, mais est imposé contractuellement par les principaux acteurs du marché : Visa et MasterCard. Une société non conforme à PCI DSS s’expose ainsi à des pénalités financières, qu’elles soient imposées directement par les réseaux, ou par un partenaire de la chaine de paiement, comme ce fût par exemple le cas pour le Groupe Aldo en 2010.

Toutefois, les acteurs concernés n’ont pas tous les mêmes responsabilités vis-à-vis de la norme. Si la conformité des commerçants doit être justifiée chaque année auprès de Visa et MasterCard, ce n’est pas le cas de la banque, qui n’est pas tenue de réaliser un reporting régulier sur sa propre situation. Elle est en revanche responsable de celle de ses commerçants, autrement dit sa clientèle professionnelle. En effet, la déclaration des commerçants demeure du ressort de la banque, qui s’expose en cas de non-conformité ou de compromission chez l’un de ses clients à des pénalités financières.

Des commerçants aux profils variés…

Tous les commerçants ne présentent pas le même profil vis-à-vis du standard, et ne font donc pas face aux mêmes obligations. PCI DSS distingue quatre catégories, dont la plus élevée regroupe les marchands effectuant plus de six millions de transactions annuelles sur un réseau. Ces sociétés doivent impérativement obtenir une certification PCI DSS, délivrée à l’issue d’un audit au cours duquel l’intégralité des points de contrôle est vérifiée. Les autres commerçants n’ont pas d’obligation de certification. Leur conformité est justifiée par le biais d’un processus déclaratif, matérialisé par un questionnaire d’auto-évaluation (Self Assessment Questionnaire, SAQ). Ce questionnaire, complété chaque année, permet d’attester que l’ensemble des points de contrôle de la norme est respecté par le commerçant.

Les commerçants ne sont toutefois pas contraints de supporter eux-mêmes l’intégralité des exigences adressées par la norme. Un e-marchand ne comptant que quelques salariés ne disposera vraisemblablement pas de service informatique spécifique, ne développera probablement pas lui-même son site internet, et hébergera encore moins les fonctionnalités de paiement sur son système d’information. Les commerçants dans cette situation ont ainsi la possibilité de reporter une partie des responsabilités liées au standard vers un prestataire proposant une solution de paiement certifiée PCI DSS. Le commerçant choisissant cette solution ne deviendra pas automatiquement conforme à PCI DSS, mais portera considérablement moins de risques sur son périmètre. À titre de comparaison, le SAQ correspondant à cette situation n’adresse que deux des douze thèmes (sécurité physique et gestion des prestataires) du standard, pour un total de 17 exigences à couvrir.

…dont la banque hérite d’une responsabilité complexe

La banque est responsable de la déclaration de l’ensemble de ses commerçants auprès des réseaux. Si les marchands les plus conséquents sont susceptibles d’être d’autant plus réceptifs voire demandeurs de cette démarche PCI DSS, ce n’est pas nécessairement le cas des commerçants peu exposés, en règle générale également peu sensibles aux questions de sécurité. Aborder le standard sous l’inconditionnel angle réglementaire serait alors voué à l’échec. Le client risquerait en effet de se tourner vers une autre banque, ne lui imposant pas ces contraintes dont il ne perçoit pas la nécessité.

Il appartient alors à la banque d’accompagner son commerçant, en lui faisant dans un premier temps comprendre les enjeux portés par la sécurisation des données. Pourquoi protéger les données carte ? Quels risques encourus en cas de compromission ? Comment corréler sécurité et développement du business ? Toutes ces questions peuvent être abordées sans même évoquer PCI DSS. L’objectif est que le marchand intègre la protection des données comme vecteur de sécurisation de son business, lui permettant de continuer à travailler en acceptant les moyens de paiement Visa et MasterCard, et de développer la confiance de sa clientèle.

En tant que premier relais de l’établissement bancaire auprès du client, le chargé d’affaires peut être l’interlocuteur privilégié pour aborder ces questions. Il est alors du ressort de la banque de définir sa cible en termes de sensibilisation, et de former ses conseillers au discours sécurité qui doit être intégré au sein de la démarche commerciale globale.

En synthèse, la banque se retrouve donc dans une position complexe d’intermédiaire entre les réseaux carte et ses propres clients. Pour satisfaire les deux parties, il est alors nécessaire de gérer les risques associés à leurs intérêts divergents. Risque réglementaire d’une part, lié au non-respect des exigences imposées par Visa et MasterCard. Risque économique d’autre part, dû à une fuite d’une partie de sa clientèle.

Définition d’une stratégie de déclaration, le véritable enjeu pour la banque

La multiplicité des profils au sein d’un portefeuille clients proscrit l’adoption d’une réponse unique. Pour satisfaire l’ensemble des acteurs impliqués, une stratégie portant sur la déclaration de chaque client doit ainsi être mise en œuvre.

Imposer le remplissage systématique d’un SAQ en vue d’une déclaration ne convaincra pas les plus petits commerçants, moins exposés et moins enclins à consacrer les ressources nécessaires à une mise en conformité PCI DSS. À l’inverse, laisser une marge de manœuvre totale à ses clients exposera la banque aux pénalités imposées par Visa et MasterCard en cas de compromission.

La stratégie adoptée doit donc se construire sur la base des profils commerçants, pouvant être modélisés suivant deux paramètres :

• Exposition au risque : le commerçant est d’autant plus exposé qu’il réalise un grand nombre de transactions carte à l’année, et qu’il est au contact de ces données (par exemple en les stockant sur son système d’information, ou en portant certaines fonctions de paiement en interne).
• Maîtrise des exigences PCI DSS : le commerçant a un niveau de maîtrise d’autant plus important qu’il est en mesure d’allouer les ressources nécessaires à la démarche de mise en conformité, et qu’il manifeste sa volonté de conformer aux règles du standard.

En définitive, la meilleure réponse que puisse apporter une banque à la question PCI DSS repose sur une approche pragmatique. Connaître son portefeuille clients et identifier les risques portés par chacun d’entre eux doit permettre de répartir au mieux les moyens à consacrer à leur mise en conformité. Cet engagement de moyens sera par ailleurs perçu de façon positive par les réseaux carte, moins susceptibles de se retourner vers la banque si une compromission commerçant venait malgré tout à se produire.

Cet article PCI DSS : Quelle stratégie pour la banque vis-à-vis de ses commerçants ? est apparu en premier sur RiskInsight.

La Directive de Services des Paiements : une première initiative

L’adoption par le Parlement Européen en 2007 de la Directive de Services des Paiements (DSP) et sa transposition sur le plan national en 2009 avait pour objectifs majeurs d’harmoniser les services de paiements de l’Union Européenne et de stimuler la concurrence. Mise à part le fait qu’à partir de cette adoption, il est possible d’effectuer et recevoir des paiements d’Allemagne, d’Espagne, du Royaume-Uni… aussi aisément qu’en France ; un nouveau statut d’Établissement de Paiement (EP) a été créé. Il permet à de nouveaux acteurs autres que les banques et les établissements de crédit de fournir des services de paiement. En France, les EP sont agréés par l’Autorité de Contrôle Prudentiel et de Résolution (ACPR).

L’héritage de cette première version concernait 3 types de Fintech : celles proposant des opérations de paiements associés à un compte (ex : Slimpay qui permet de générer des mandats de prélèvements électroniques), les transferts de fonds et les émissions d’instruments de paiement (ex : portefeuille électronique). Les plateformes de financement (crowdfunding) qui ne fournissent pas de services de paiement n’entrent pas dans le champ d’application de la DSP1. Elles sont par ailleurs réglementées par l’ordonnance du 30 mai 2014 en tant que service de financement. Celles qui perçoivent des fonds bénéficient jusqu’à présent d’une dérogation, du fait que le montant total de leurs opérations de paiement soit inférieur à 3 000 000 € sur un mois (article 26 de la DSP1).

De nouveaux types d’acteurs, un nouveau cadre réglementaire

Le développement des Fintech a fait apparaître de nouveaux services de paiements depuis la DSP1 : les services d’information sur les comptes (ex : agrégateur de données Bankin’) et les services d’initiation de paiement (ex : Sofort), autrement appelés les tiers de paiement (Third Party Providers ou TPP). Ces nouveaux acteurs, se connectant aux banques des utilisateurs via leur login/mot de passe bancaire, ne sont pas pris en compte par la DSP1 et engendrent de nouveaux risques (données n’étant plus sous la protection du secret bancaire, problématique liée aux responsabilités en cas de fraude, etc.).

La DSP2 (adoptée par le Parlement Européen le 8 octobre 2015 et qui devrait être transposée dans le droit national fin 2017) stimule toujours la concurrence tout en fournissant un nouveau cadre réglementaire adéquat entre les TPP et les banques. Concernant la DSP1, les contrôles sont effectués par l’ACPR, la CNIL et la DGCCRF et les sanctions peuvent aller jusqu’au retrait d’agrément de l’Établissement de Paiement (EP). La nouvelle version de la Directive laisse aux États membres la charge de définir le régime de sanctions à appliquer en cas de son non-respect, sanctions qui ne sont donc pour l’instant pas connues.

Extrait de l’article 103 de la Directive : « Les États membres déterminent le régime de sanctions applicables en cas d’infraction aux dispositions de droit national visant à transposer la présente directive et prennent toutes les mesures nécessaires pour en assurer l’application. Ces sanctions sont effectives, proportionnées et dissuasives ».

Une obligation pour les banques qui ouvre de nouvelles opportunités : la coopétition

La DSP2 impose aux banques de transmettre de façon sécurisée les données seulement nécessaires à l’activité des TPP et de rembourser le payeur en cas d’incident de paiement dans un délai de 1 jour (excepté si la responsabilité du TPP est engagée dans un incident de paiement, auquel cas, il doit lui-même rembourser immédiatement la banque). Pour autant, la directive ne précise pas les exigences techniques de sécurité auxquelles devront se soumettre les banques et les TPP. Le contenu des guidelines de l’Autorité Bancaire Européenne (prévus pour fin 2016) sera déterminant : les normes techniques devront prendre en considération l’éventail des risques inhérents aux nouveaux services de paiement.

Cette obligation peut être vue comme une opportunité pour les banques de développer des Open API. L’Open API est une interface de programmation qui permet à des tiers d’accéder à des ressources internes. Cet accès n’est pas forcément autorisé en lecture et en écriture à l’intégralité des données. La plupart du temps, il est limité et nécessite l’accord de l’utilisateur.

Les banques peuvent utiliser et promouvoir ces mécanismes afin de renforcer leur compétitivité, leur image de marque et proposer de nouveaux services plus rapidement en offrant la possibilité aux développeurs externes de créer de nouvelles applications à partir de l’Open API et en les rémunérant en échange. Ce mouvement est essentiel pour que les banques gardent la main sur l’innovation et les nouveaux services pour continuer à se différencier. Certaines banques ont déjà initié une démarche proactive et innovante en mettant en place un Open API soit ouvert au public (CA Store, Fidor Bank) soit restreint à des partenaires (Bradesco, Garanti).

Cet article La DSP2 : une directive sur les services de paiements qui prône la concurrence est apparu en premier sur RiskInsight.

Une multiplicité des moyens de paiement

Le panorama des nouveaux moyens de paiement ne cesse d’évoluer au fil des années. Cette évolution sous-entend aussi une diversité des technologies utilisées par chaque solution.

Le e-commerce : Les transactions en ligne via un ordinateur se résume généralement à recopier les données d’une carte bancaire sur un site marchand. Il est toutefois possible d’utiliser un portefeuille électronique, comme le propose par exemple PayPal.

Le m-commerce : On distingue différents modes de paiements sur mobile :

• Le paiement à distance, via internet sur une application dédiée ou sur un navigateur, ou encore par SMS en utilisant la technologie USSD (Unstructured Supplementary Service Data). Ce protocole de communication permet entre autre de consulter son suivi conso et de payer sa facture en tapant #123# depuis son mobile. Ce dernier est aujourd’hui surtout présent dans les régions du monde où la population est peu bancarisée ;
• Le transfert d’argent de mobile à mobile, est un service proposé par de plus en plus de portefeuilles électroniques, à l’instar de Google Wallet ou des portefeuilles Bitcoin;
• Le paiement de proximité, ou paiement sans contact, permettant de payer chez le marchand avec son smartphone. Cette solution est dominée par deux technologies. La première est le Near Field Comunication (NFC), comme le proposent Apple Pay et Google Wallet. La seconde est le Quick Response Code (QR Code), une technologie notamment utilisée par les portefeuilles Bitcoin ou DigiCash.

Il ne s’agit pas ici d’une liste exhaustive des nouveaux moyens de paiement, puisque d’autres solutions permettent de payer autrement, à l’image du NFC Reader proposé par Square. Cependant, il faut garder en tête que ces nouvelles solutions tendent à se généraliser. Reste à identifier les impacts au niveau de la sécurité.

Quels enjeux en matière de sécurité ?

Ces nouveaux moyens de paiement sont tributaires des supports qui les proposent. Autrement dit, de nouveaux risques apparaissent, puisque le smartphone devient en partie responsable de la sécurité du paiement. Certes, ces solutions proposent des systèmes de sécurisation de la transaction via par exemple le chiffrement ou la tokenisation (mécanisme visant à remplacer le numéro de la carte bancaire par un autre numéro unique et inutilisable dans d’autres contextes). Mais un smartphone n’est autre qu’un outil personnel pour l’utilisateur, donc potentiellement personnalisable ou attaquable. Or, une authentification désactivée, ou un smartphone « jailbreaké » (dont les fonctions de sécurité ont été déverrouillées) sont autant de problèmes de sécurité dont l’utilisateur est responsable ou peut être la victime en cas de failles de sécurité utilisées des pirates.

La solution de paiement doit donc proposer des mesures de sécurité pour palier à ces éventualités. Trois exemples concrets permettent de mieux comprendre les enjeux de la sécurité des nouveaux moyens de paiement.

Apple Pay, Google Wallet et les portefeuilles Bitcoin, trois solutions, trois philosophies différentes

Les solutions proposées par les deux géants américains Apple et Google, sont des portefeuilles électroniques. À noter que ce terme est un abus de langage car il signifie initialement l’utilisation d’un compte crédité. Ils permettent de payer via des applications qui les supportent, et ils permettent aussi de payer chez le marchand directement avec son smartphone par communication NFC. Google Wallet existe depuis septembre 2011 aux États-Unis alors qu’Apple Pay est lui disponible depuis octobre 2014 outre-Atlantique et depuis le 14 juillet 2015 en Grande Bretagne. On compte néanmoins plus de 700 000 terminaux de paiement acceptant chacune des deux solutions.

Apple Pay (à gauche) et Google Wallet (à droite)

L’une des distinctions majeures entre ces deux solutions réside dans le stockage des données à caractère personnel. Tandis qu’Apple certifie ne récupérer aucune donnée qui pourrait être reliée à l’utilisateur, Google, lui, se propose de récupérer et stocker toutes ces données dans le Cloud. La raison de ces choix technologiques provient du fait qu’Apple est propriétaire de sa technologie de bout en bout, il fabrique ses propres smartphones. De l’autre côté, Google ne fabrique pas les mobiles qui proposent sa solution de paiement. Ainsi, il se propose de stocker toutes les données sur le cloud afin de les sécuriser. Une confiance que l’on retrouve aussi au travers d’une solution en marge du système bancaire : le Bitcoin.

Les portefeuilles Bitcoin permettent de faire ses achats en monnaie « virtuelle » depuis son mobile. Il est en effet aujourd’hui possible de payer avec ses bitcoins chez certains marchands, et ce, même en France. Le Picotin par exemple, restaurant dans le 12^ème arrondissement de Paris, propose à ses clients de payer son addition par bitcoin.

© Sebastian Seibt | Le Picotin accepte les paiements en monnaie dématérialisée

De plus, certains portefeuilles électroniques comme igot (disponible en Australie) s’occupent de transférer au marchand l’équivalent de la quantité de bitcoin en monnaie locale.

Ce moyen de paiement virtuel présente de nombreux avantages, en particulier du point de vue de l’anonymisation même s’il reste peu répandu et sujet à des variations de valeurs extrêmement fortes.

Ces solutions sont donc une nouvelle expérience de paiement. Une expérience qui se voit portée par deux arguments : ergonomie et sécurité. Apple Pay, Google Wallet, et les portefeuilles Bitcoins peuvent-ils incarner l’avenir des paiements sécurisés ? C’est dans l’optique de répondre à cette question, qu’il sera nécessaire de décrypter la sécurité de ces trois nouveaux moyens de paiement. Cela fera l’objet de prochains articles de blog à ce sujet.

Cet article Démocratisation des nouveaux moyens de paiements : la sécurité au cœur des enjeux est apparu en premier sur RiskInsight.

Parmi ces services, nous retrouvons notamment le Mpaiement. Faire ses achats sur internet à n’importe quel moment et de n’importe où (transport, salle d’attente…) a enthousiasmé les utilisateurs. Cependant, les débuts ont été laborieux : saisir les 16 caractères de sa carte bancaire sur un clavier tactile de taille réduite génère forcément des erreurs et peut décourager plus d’un client. L’achat sur smartphone ne peut être qu’efficace que s’il est simple et rapide !

Protéger sa carte bancaire à travers les portefeuilles virtuels

Les portefeuilles virtuels proposés par les commerçants ont apporté une solution : les données de carte bancaire sont enregistrées chez le commerçant et par le biais d’un login et d’un mot de passe, l’utilisateur s’identifie pour réaliser son paiement en « un clic », tout simplement. La sécurité des données est assurée par les mesures mises en œuvre dans le cas d’une certification PCI DSS du commerçant ou d’une externalisation du service auprès d’un fournisseur de service de paiement (Payment Service Provider), lui-même certifié PCI DSS. (cf. un article précédent).

S’identifier pour réaliser un paiement n’est cependant pas une solution totalement innovante. Paypal, le leader mondial du portefeuille virtuel pour les sites web a naturellement décliné son offre pour les smartphones.  Ce service remporte un net succès et attise les convoitises, comme l’on peut le voir en ce moment avec  l’arrivée de nouvelles solutions sur le marché français telles que Kwixo, Buyster ou Lemonway qui utilisent notamment le numéro de téléphone du client comme identifiant.

Au-delà des mesures techniques de sécurité pour l’hébergement des données, ces solutions proposent, pour certaines d’entre elles, une sécurisation intéressante des mots de passe du client (longueur minimale, caractères spéciaux, questions secrètes pour le renouvellement) mais malheureusement elles font également le sujet d’attaque par Phishing et l’utilisateur non averti peut alors se retrouver malgré lui piégé en livrant lui-même ses identifiants au fraudeur….

La course aux moyens de paiement de demain est lancée !

De nouveaux moyens de paiement vont changer nos habitudes de demain comme les smartphones ont pu le faire ces dernières années.

Solution déjà lancée outre-atlantique dans les Starbucks New-Yorkais, le code barre 2D (ou QR code) est une nouveauté pour le paiement mobile. Initialement envisagé pour obtenir de l’information en le flashant, le QR code, a été détourné aujourd’hui pour proposer une « facture électronique » que le client va flasher avec son smartphone, et régler via une application de portefeuille virtuel, protégé par un code PIN.

Autre challenger qui se fait dorénavant attendre… le NFC. Le Near Field Communication est un protocole sécurisé d’échange de données entre une borne et une puce, intégré par exemple dans un smartphone ou une carte bancaire. Le NFC permet de centraliser divers services en un seul support, tels que le titre de transport ou la carte fidélité. Il peut également offrir la possibilité de payer « sans contact », une solution simple et transparente pour les utilisateurs. En expérimentation depuis 2010 dans la ville de Nice, ce test grandeur nature n’a pas rencontré le succès escompté. Pour 200 000 cartes avec module NFC livrées, seules 2 800 transactions sans contact ont été effectuées la première année au sein des 1 500 commerces de proximité de la ville (source ZDNet.fr).

Cependant, Google est l’un des acteurs qui y croit fort, notamment avec sa solution Wallet, basée sur la technologie NCF. Uniquement disponible aujourd’hui aux États-Unis, Google compte bien utiliser sa force pour prendre une place importante sur ce marché avant que son concurrent Apple ne propose également sa solution.

L’un des principaux freins au développement de ce nouveau moyen de paiement reste, notamment, le nombre très limité de terminaux mobiles intégrant directement une puce NFC. Mais avec le récent dépôt de brevet d’Apple sur le NFC, on peut s’imaginer que le message a été compris par les grands fabricants de smartphones…

Cet article Un téléphone ça sert à payer ! est apparu en premier sur RiskInsight.