Présentation des paiements Web : achats en ligne simplifiés grâce à l'API de demande de paiement

Acheter des choses en ligne peut être un processus frustrant, en particulier sur mobile. Même si les pages sont bien conçues, de nombreuses informations sont requises : nos coordonnées, les adresses d'expédition et de facturation, l'option d'expédition et les détails de la carte. Si vous avez déjà abandonné parfois, vous êtes dans la majorité.

L'Institut Baymard a pris une moyenne sur 37 études différentes et a constaté que 69 % des paniers d'achat sont abandonnés.

Sans surprise, les chiffres sont pires sur mobile, où le petit écran et l'absence de clavier physique peuvent ralentir la saisie. Le taux d'abandon sur mobile peut atteindre 84% voire plus ! Avec l'essor et l'essor de la navigation mobile au cours des dernières années, cela signifie que le problème global s'est aggravé. Pour les sites de e-commerce, ces paniers abandonnés coûtent très cher. Business Insider a estimé que 4 000 milliards de dollars de marchandises seraient abandonnées en un an.

Heureusement, le Web se bat contre ce problème. Le groupe de travail "Web Payments" du W3C a travaillé sur "une révolution des paiements sur le Web" , en développant de nouvelles normes pour faciliter les paiements en ligne. En plus d'être le nom du groupe de travail, "Web Payments" est essentiellement un terme générique couvrant ces nouvelles normes émergentes.

L'API de demande de paiement

Le premier de ces standards, l' API Payment Request , est une avancée majeure. Cela nous donne la possibilité de demander un paiement à un utilisateur et de faire en sorte que le navigateur fournisse l'interface utilisateur pour l'accepter. Il est déjà pris en charge dans Chrome, Edge et Samsung Internet, et il est en développement dans Firefox et Safari. De nombreuses entreprises de premier plan adoptent l'API, notamment le New York Times, le Washington Post et Monzo.

Demander ces informations au navigateur offre un avantage immédiat et majeur, car ces informations sont probablement déjà stockées . Tant que nous avons entré nos coordonnées sur un autre site Web qui utilise l'API et que notre navigateur s'en souvient, le navigateur pourra pré-remplir le formulaire, ce qui nous permettra de vérifier beaucoup plus rapidement.

C'est mieux que le remplissage automatique standard ; permettre au navigateur de gérer les champs de saisie signifie qu'il peut être totalement précis - évitant tout problème de pré-remplissage des mauvaises informations dans les mauvais champs. Cela signifie également que nous avons un formulaire de paiement d'une seule page optimisé pour les mobiles, sans avoir à écrire nos propres code HTML et CSS.

Les avantages peuvent être encore plus ressentis sur mobile, mais l'API de demande de paiement ne se limite pas aux navigateurs mobiles. Il est déjà pris en charge dans les versions de bureau de Chrome, Edge et Samsung Internet pour DeX. Nous pouvons également nous attendre à ce que le support arrive plus tard dans Firefox et Safari de bureau (au moment de la rédaction, il a récemment été activé par défaut dans Safari Technology Preview 44).

Notre première demande de paiement

Commençons à explorer l'API avec un exemple de base. Nous allons demander un paiement par carte à l'utilisateur et lui permettre de payer comme ceci :

Dans la vidéo ci-dessus, vous remarquerez que l'utilisateur confirme le paiement avec son empreinte digitale. Cela ne fait pas partie de la norme de demande de paiement elle-même, mais d'une fonctionnalité de sécurité fournie par le navigateur Internet Samsung (avec le balayage de l'iris) sur les appareils pris en charge.

Si vous êtes intéressé par d'autres possibilités d'intégration de l'authentification biométrique sur le Web, vous voudrez peut-être garder un œil sur la future norme d'authentification Web.

Tout d'abord, comme d'habitude, nous devrions adopter Progressive Enhancement et vérifier que ce navigateur prend en charge l'API :

 if (window.PaymentRequest) { // We can continue with the Payment Request API } else { // Here we could fall back to a legacy checkout form }

Nous pouvons maintenant configurer la configuration de notre PaymentRequest — le type de paiement que nous accepterons et les détails à afficher concernant l'achat :

 var methodData = [{ // 'basic-card' means standard card payments - credit and debit cards supportedMethods: 'basic-card' }]; var details = { // If we are buying multiple items, each one can be included displayItems: [ { label: 'Some product that we are buying', amount: {currency: 'USD', value: '699.99'} } ], total: { label: 'Total', amount: {currency: 'USD', value: '699.99'} } }; var paymentRequest = new PaymentRequest(methodData, details);

Lorsque nous voulons afficher l'interface utilisateur de paiement (par exemple, lorsque l'utilisateur clique sur "Acheter maintenant"), nous pouvons appeler show() . Ensuite, nous traitons les données que l'utilisateur a fournies lorsque la promesse est résolue :

 // show() makes it actually display the user interface paymentRequest.show() .then(function(paymentResponse) { // User has confirmed. paymentResponse contains the data entered. // Here we would process it server-side... processPaymentDetails(paymentResponse) .then(function(paymentResponse) { // ...Then when processed successfully, this will make the dialog indicate success & then close: paymentResponse.complete('success'); // We could also update the page here appropriately }); }) .catch(function(error) { // Handle error, eg if user clicks the 'cancel' button. });

Nous avons maintenant le flux d'interface utilisateur configuré sur le front-end. Nous pouvons également le configurer davantage, pour répondre à nos besoins. Par exemple, si nous souhaitons demander des détails supplémentaires au client, nous pouvons transmettre des options supplémentaires au constructeur PaymentRequest. Par exemple, pour demander le nom, l'adresse e-mail, le numéro de téléphone et l'adresse de livraison de l'utilisateur :

 var options = { requestPayerName: true, requestPayerEmail: true, requestPayerPhone: true, requestShipping: true }; var paymentRequest = new PaymentRequest(methodData, details, options);

Nous pouvons également définir plusieurs options d'expédition et même contrôler quelles options sont présentées dynamiquement, en fonction de l'adresse du client. Vous pouvez en trouver un exemple ici sur Glitch.

Expérience utilisateur

Nous commençons à voir des statistiques impressionnantes sur les avantages que la demande de paiement peut apporter aux entreprises. Google a récemment partagé que J.Crew, une marque de mode, a découvert que 50 % de ses utilisateurs passent désormais par le flux de demande de paiement, ce qui réduit leur temps de transaction de 75 % !

C'est à vous de décider comment intégrer la demande de paiement dans votre expérience d'achat, mais une méthode courante consiste à proposer quelque chose comme une option « Paiement express » ou « Acheter maintenant », sans obliger le client à se connecter au préalable. Si vous le souhaitez, vous pouvez collecter les coordonnées de l'utilisateur à l'aide de l'interface utilisateur de demande de paiement et, une fois l'achat effectué, lui offrir la possibilité de créer un compte pour une utilisation future.

Si vous le souhaitez, vous pouvez d'abord vérifier si le client a déjà configuré un mode de paiement valide, avant de présenter l'interface utilisateur de demande de paiement. Pour ce faire, vous pouvez appeler canMakePayment :

 if (paymentRequest.canMakePayment) { paymentRequest.canMakePayment().then(function(result) { if (result) { // User has an active payment method } else { // No active payment method yet (but they could add one) } }).catch(function(error) { // Unable to determine }); }

Intégration back-end

Nous avons vu comment configurer l'interface utilisateur pour accepter les paiements, mais comment traitons-nous réellement les paiements dans le back-end ?

La plupart des sites Web ne gèrent pas les paiements eux-mêmes (ce qui nécessiterait beaucoup de soin et de conformité PCI DSS), mais utilisent une passerelle de paiement (PG) ou un fournisseur de services de paiement (PSP) tiers. Un certain nombre de passerelles de paiement ont déjà introduit un support spécifique pour l'API de demande de paiement. Ils peuvent initier la demande de paiement via leur propre script que vous incluez sur votre page, aidant à garantir que les données sont envoyées en toute sécurité et que vous n'avez pas à les gérer vous-même. Ils peuvent également proposer une solution iFrame ou de redirection. La meilleure façon de procéder est de vérifier auprès de votre passerelle de paiement comment elle recommande d'intégrer les demandes de paiement.

Intégration de l'application de paiement

Jusqu'à présent, nous avons discuté des paiements par carte. Cependant, l'API de demande de paiement prend également en charge les applications de paiement mobile telles que Samsung Pay, Pay with Google (incorporant Android Pay) et Apple Pay.

Laisser nos clients payer avec l'une de ces applications signifie qu'ils peuvent utiliser la carte qu'ils ont enregistrée dans l'application, sans avoir à saisir à nouveau les détails (même la première fois) dans le navigateur. L'utilisation de ces applications peut également être plus rapide car elles n'obligent pas le client à ressaisir son CVC (Card Verification Code, également connu sous le nom de CVV) au dos de sa carte. Enfin, ils peuvent apporter des avantages supplémentaires en matière de sécurité car ils ne transmettent pas les détails de la carte d'origine, uniquement des jetons à usage unique, nous protégeant ainsi des attaques potentielles d'interception et de rejeu.

Lorsque le client sélectionne l'application de paiement comme mode de paiement choisi, le navigateur bascule vers une feuille de paiement fournie par l'application, pour confirmer le paiement. L'application tierce acceptera alors généralement l'empreinte digitale ou le scan de l'iris du client pour confirmer le paiement si l'appareil le prend en charge.

Chaque application de paiement aura ses propres instructions particulières, mais l'idée générale est la même. Vous pouvez les identifier comme méthodes de paiement potentielles en utilisant leurs propres URL spéciales et transmettre la configuration requise dans le champ de data . Par exemple, pour prendre en charge Samsung Pay, vous devez inclure un code comme celui-ci dans votre tableau methodData :

 var methodData = [ { supportedMethods: 'https://spay.samsung.com', data: { // Samsung Pay specific data here } }, … // Other payment methods ];

De manière générale, il existe deux méthodes pour intégrer ces applications à votre passerelle de paiement : une méthode « Gateway Token » et une méthode « Network Token ». Si vous utilisez un service tiers qui le prend en charge, vous utiliserez très probablement le mode Gateway Token, où le service d'application de paiement appellera votre passerelle de paiement en votre nom. Alternativement, vous pouvez utiliser la méthode du jeton réseau où vous gérerez l'envoi du jeton à votre passerelle de paiement en toute sécurité, en utilisant leur SDK. Votre passerelle de paiement et/ou votre fournisseur d'application de paiement devraient être en mesure de fournir plus de détails.

Google a récemment annoncé l'API Google Payment qui intègre Android Pay ainsi que les cartes stockées dans les comptes Google des clients.

Apple Pay utilise actuellement sa propre solution JavaScript, Apple Pay JS. Cependant, les développeurs de Google ont créé un wrapper qui vous permet de l'utiliser via l'API de demande de paiement standard.

Et après?

Le groupe de travail sur les paiements Web ne s'arrête pas à l'API de demande de paiement. Des travaux sont également en cours sur d'autres normes, notamment l'API Payment Handler, qui permettra aux applications Web d'agir comme une application de paiement tierce. D'autres sujets en cours de discussion incluent la normalisation possible autour de la tokenisation et la possibilité pour les demandes de paiement de prendre en charge des éléments tels que les cartes-cadeaux. Si vous souhaitez suivre les développements, voici la liste de diffusion publique. J'espère qu'ensemble, nous pourrons résoudre les expériences de paiement frustrantes du passé et concrétiser la vision d'une révolution des paiements en ligne !

Autres ressources

• « Wiki des paiements Web du W3C », GitHub
• "Informations pour les développeurs de l'API de demande de paiement du W3C", GitHub voir également la FAQ
• "Web Payments 101 : Un court didacticiel de codage des demandes de paiement", Glitch
• "Plongez dans l'API de demande de paiement", développeurs Google
• "Guide de développement de l'API de demande de paiement", Microsoft Edge
• "Comment accepter Samsung Pay sur votre site Web à l'aide des paiements Web", Winston Chen, Medium