L'API Payment Request est désormais implémentée dans tous les navigateurs Web les plus utilisés
L'API Payment Request est désormais implémentée dans tous les navigateurs Web les plus utilisés,
pour faciliter les paiements en ligne indépendamment de la plateforme
L'achat de produits en ligne est une expérience pratique, mais souvent frustrante, en particulier sur les appareils mobiles. Bien que le trafic mobile continue d'augmenter, les achats effectués sur mobile représentent seulement environ un tiers de tous les achats en ligne. Quelles sont les raisons qui peuvent l’expliquer ?
Les formulaires d'achat en ligne sont parfois chronophages, difficiles à utiliser, lents à charger et à rafraîchir, et nécessitent plusieurs étapes pour être validés. C'est parce que deux composants principaux des paiements en ligne, notamment la sécurité et la commodité fonctionnent souvent à fins multiples.
La plupart des problèmes qui conduisent à l'abandon d’un achat en cours peuvent être directement attribués aux formulaires d'achat. Chaque application ou site a son propre processus de saisie et de validation des données, et les utilisateurs trouvent souvent qu'ils doivent entrer les mêmes informations au point d'achat de chaque application. En outre, les développeurs d'applications ont du mal à créer des flux d'achats qui supportent de multiples méthodes de paiement unique, même les petites différences dans les exigences de la méthode de paiement peuvent compliquer le processus d'achèvement et de soumission du formulaire.
Tout système qui améliore ou résout un ou plusieurs de ces problèmes est un changement bienvenu. Bien entendu, il existe des solutions partielles à ce problème comme Autofill, une extension dont la fonctionnalité principale est d’effectuer le remplissage automatique des champs de formulaire quand la page est chargée sans aucune interaction de l'utilisateur.
Cependant, il existe une solution plus complète : l’API Payment Request (demande de paiement).
L'API Payment Request a été proposé comme standard au W3C, l’organisme chargé de promouvoir la compatibilité des technologies WWW. Son objectif est d’éliminer les formulaires de caisse. Il a été présenté comme une solution qui améliore considérablement le flux de travail des utilisateurs pendant le processus d'achat, offrant une expérience utilisateur plus cohérente et permettant aux marchands Web de tirer facilement parti de différentes méthodes de paiement.
L'API Payment Request est conçue pour être agnostique du fournisseur, ce qui signifie qu'elle ne nécessite pas l'utilisation d'un système de paiement particulier. Ce n'est pas une nouvelle méthode de paiement ni l'intégration directe avec les processeurs de paiement. Il s’agit plutôt d’un moyen d'acheminer les informations de paiement et de livraison de l'utilisateur aux commerçants, avec les objectifs suivants :
- laisser le navigateur agir comme intermédiaire entre les commerçants, les utilisateurs et les méthodes de paiement ;
- standardiser le flux de communication de paiement autant que possible ;
- supporter parfaitement les différentes méthodes de paiement sécurisées ;
- fonctionner sur n'importe quels navigateur, appareil ou plateforme mobile.
L'API Payment Request est une norme ouverte et croisée par navigateur qui remplace les flux de caisse traditionnels en permettant aux marchands de demander et d'accepter tout paiement dans un seul appel d'API. L'API permet à la page Web d'échanger des informations avec le user agent pendant que l'utilisateur fournit une entrée, avant d'approuver ou de refuser une demande de paiement.
De plus, avec le navigateur agissant en tant qu'intermédiaire, toutes les informations nécessaires à un paiement rapide peuvent être stockées dans le navigateur, afin que les utilisateurs puissent simplement confirmer et payer, le tout en un seul clic.
Ce mois-ci, le statut de l'implémentation de dette API dans Webkit est passé de « Under Consideration » à « In Development ». Ian Jacobs de la W3C a expliqué que « Cela signifie que l'API est implémentée dans Chrome, Edge, Firefox et Webkit, ainsi que Samsung Internet Browser et Facebook. »
« Le timing ne pourrait pas être mieux. Aujourd'hui, le Groupe de travail sur les paiements Web a fait des avancées à la fois sur l'API Payment Request, mais aussi sur les identificateurs Payment Method qui sont passés au statut de Candidate Recommendation. Cette étape dans la piste de recommandation du W3C signifie que la spécification est stable et que nous nous concentrerons maintenant sur l'interopérabilité du navigateur, principalement en développant une suite de tests complète. »
Source : W3C
Et vous ?
:fleche: Que pensez-vous de cette API ?
Copie article où est la source ?
BOnjour,
Je me trompe peut être mais l'article semble une simple traduction de celui là
Sur le fond rien de choquant du moment que la source est citée
https://developers.google.com/web/fu...yment-request/
Un chercheur en sécurité relève des faiblesses de l'API Payment Request
Un chercheur en sécurité relève des faiblesses de l'API Payment Request,
implémentée dans les navigateurs pour faciliter les paiements en ligne
Comme c'est souvent le cas, une fonctionnalité créée pour plus de commodité peut être détournée de son but initial. Pour permettre aux utilisateurs de ne pas avoir à entrer les numéros de leur carte de crédit (notamment les 16 caractères, en plus des quatre pour la date et des trois ou quatre chiffres du numéro de vérification de carte CCV), l'API Payment Request permet aux sites Web d'extraire des numéros stockés dans les navigateurs.
Cependant, selon Lukasz Olejnik, chercheur en sécurité et en matière de protection de la vie privée, même sans une évaluation complète de la vie privée, il est facile de voir des vecteurs sérieux qui pourraient être utilisés pour détourner la fonctionnalité de son but initial.
« Il y a de fortes chances que les jours de sites de commerce électronique ayant des systèmes de paiement personnalisés, souvent inutiles, soient comptés. L'API Payment Request améliore non seulement la commodité, mais aussi la sécurité des paiements en ligne. Les sites Web auront plus facilement accès aux options de paiement. Les utilisateurs du Web pourront plus facilement éviter les phishings, les escroqueries et d'autres expériences désagréables », a-t-il reconnu.
L'API Web Payment fonctionne comme suit :
- le processus de paiement est lancé par le site ;
- le navigateur prend le contrôle, l'utilisateur peut fournir une méthode de paiement comme une carte de crédit, puis un numéro CVV, et c'est tout.
Tout en utilisant des messages d'affichage standard, intuitifs et compatibles avec le navigateur. L'API Payment Request est maintenant prise en charge par Chrome et Edge, et le sera bientôt dans Firefox et WebKit.
Les utilisateurs ont la possibilité d'ajouter une carte de crédit à un navigateur, il est donc simple de payer en utilisant une carte de crédit précédemment incluse. Pour faciliter à la fois la vie des développeurs Web, mais aussi celle des utilisateurs, la spécification comprend une méthode de vérification si l'utilisateur dispose d'une méthode de paiement enregistré. Cette méthode s'appelle canMakePayment et est l’objet central auquel s’est intéressé le chercheur.
« Pour protéger contre les abus, canMakePayment peut être exécuté par une origine (c.-à-d. un site Web) avec une méthode de paiement ciblé spécifique de temps en temps. Donc, un site Web peut vérifier si un navigateur a une carte Visa incluse – mais la vérification (immédiatement après) si la carte MasterCard est également prise en charge devrait être impossible. Ce mécanisme protège l'énumération des méthodes de paiement incluses dans un navigateur. Par exemple, c'est ainsi qu'il est implémenté dans Chrome. L'origine spécifique (c'est-à-dire le site Web) peut faire un tel test toutes les 30 minutes seulement, via un mécanisme de quota. Si un site Web tente de faire le test plus fréquemment, Chrome ne le permettra pas. Le mécanisme de quota rend les attaques d'énumération / empreintes numériques plus difficiles étant donné qu’elles vont nécessiter plus de temps.
« Cependant, un site Web pourrait simplement utiliser un tas d'iframes avec des scripts fonctionnant efficacement dans des origines différentes, ce qui signifie que le quota de 30 minutes est fonctionnellement non pertinent. De tels iframes (en utilisant le paramètre de “allowpaymentrequest” de l'empreinte numérique) effectueraient alors des tests supplémentaires sans quota. Par exemple, un iframe pourrait tester "visa", un autre "mastercard", etc. À la fin, les iframes communiquent les résultats du test au frame parent. En fin de compte, ce processus permettrait d'énumérer toutes les méthodes de paiement prises en charge par l'utilisateur. »
Pour étayer ses dires, il a mis sur pied une page Web qui permet de tester les méthodes de paiement enregistrées sur le navigateur Chrome. Il a expliqué qu’enregistrer au préalable une carte Visa est essentiel. Il a proposé d’utiliser la sienne avec les numéros 4916 6293 0528 7782 (CVV 933).
« Je l'ai testé sur Chrome, la version Desktop et la version Android. Dans cette démo, seules deux cartes sont testées : Visa et MasterCard. Ce n'est pas tout », a-t-il déclaré.
Le chercheur note également que l’API Payment Request, tel qu’elle est livrée dans Chrome, permet la détection lorsqu'un utilisateur est en mode Incognito. « C’est aussi simple que de tester deux méthodes de paiement différentes par le même site. Si je fais une demande canMakePayment pour "visa", puis à nouveau pour "mastercard" (les deux demandes depuis le même site web), le second appel va entraîner une exception quand il ne sera pas en Incognito :
NotAllowedError: Not allowed to check whether can make payment”.
En revanche, en mode Incognito (dans cet exemple, je n’ai inclus qu’une Visa), nous avons :
mastercard card enabled? true
visa card enabled? true. »
En clair, l’API ne fonctionne pas bien avec le mode Incognito.
Il a déjà prévenu l’équipe Chrome.
:fleche: détection du mode Incognito sur Chrome
:fleche: PoC fingerprinting
Source : blog Olejnik
