Le groupe de travail Web Payments du W3C a publié le 15 septembre les API Web Payments HTTP 1.0 et Web Payments HTTP Messages 1.0. Tous les retours et contributions pour ces brouillons de travail sont les bienvenus.
L'objectif du groupe de travail Web Payments est de standardiser les déroulements de haut niveau, les API et les structures de messages des payments web. Les bénéfices d'une telle standardisation sont décrits ainsi :
- Améliorer l'expérience du paiement en ligne, en particulier pour les utilisateurs mobiles. Les standards devraient faciliter l'automatisation pour améliorer l'expérience utilisateur.
- Rationaliser le flux de paiement, ce qui devrait réduire la proportion de transactions abandonnées avant la validation du paiement ("abandon de panier").
- Une meilleure adoption des améliorations des moyens de paiement (mises à jour de sécurité par exemple) ou les nouveaux moyens de paiement.
- Amélioration de la valeur des paiements digitaux par des formats de requêtes et réponses lisibles par des machines.
La lecture devrait démarrer par l'API de Web Payments, puis celle de l'API Web Payments Messages. Les API proposées sont de type CRUD web. Les messages proposés sont représentés sous forme de modèles de données qui peuvent être exprimés dans n'importe quel langage. Pour la démonstration, les formats des messages d'exemple sont en JSON.
L'actuel flux de paiement web, décrit ci-dessous, propose un paiement en mode pull, mais la spécification propose aussi un mode push. La base comporte 3 phases : paiement et enregistrement, initialisation de la requête de paiement, puis génération de la réponse au paiement.
L'intermédiaire de paiement est un nouveau concept, qui n'existe traditionnellement pas. Comme son nom l'indique, il gère les flux de messages entre l'acheteur, le vendeur et l'application de paiement. C'est ce composant qui dirige la réponse au paiement en fonction de s'il s'agit d'un pull ou d'un push. Il décide également quelle application de paiement de l'acheteur peut être utilisée en fonction des méthodes choisies par l'utilisateur.
Il y a clairement encore des obstacles intéressants à dépasser, parmi lesquels :
- Le code HTTP 420 qui est pour l'instant
undefined. - Des codes d'erreurs HTTP pertinents. Au delà des nombreuses possibilités liées aux moyens de paiement existants comme ACH, les cartes de crédit ou les crypti-monnaires, il faudra aussi envisager de supporter les futurs moyens de paiements.
- La matrice de menaces. De nouvelles opérations sensibles font leur apparition :
- Le client HTTP de l'acheteur s'authentifie lui-même pour enregistrer une application de paiement auprès du service du site concerné.
- Les actions autorisées de l'intermédiaire de paiement.