3.1.5. Détection des rachats et URL d’exécution

Les commandes et les contrats de Taler doivent contenir un fulfillment_url ou un fulfillment_message, qui sont utilisés par le portefeuille après que le contrat ait été payé. Ce tutoriel explique comment définir correctement ces valeurs.

3.1.5.1. Message de satisfaction

Ce champ est simplement un message qui sera affiché à l’utilisateur par le portefeuille Taler après que l’utilisateur a effectué l’achat. Il peut être défini comme n’importe quel type de texte UTF-8 et est censé être utilisé comme un message final amical de la part du commerçant à la fin de la transaction commerciale.

Note

Les portefeuilles de blé apprennent le texte avant que l’achat ne soit effectué, de sorte que les utilisateurs pourraient obtenir le message d’exécution avant l’achat proprement dit. Par conséquent, ce message ne devrait pas contenir les données d’identification ou les informations que l’utilisateur est susceptible d’acheter avec le contrat.

Les messages d’exécution sont utilisés lorsque le marchand n’a pas d’URL d’exécution vers laquelle rediriger l’utilisateur.

3.1.5.2. fulfillment_url

Les contrats peuvent contenir un fulfillment_url au lieu d’un fulfillment_message. Le fulfillment_url doit faire référence à un site web (commençant par http:// ou https://) et l’utilisateur y sera redirigé immédiatement après avoir effectué l’achat et éventuellement plus tard à partir de la boîte de dialogue des détails de l’achat dans l’historique des transactions de son porte-monnaie.

Les URL de traitement ont un deuxième objectif : ils sont également utilisés pour la détection des achats. Il faut donc veiller à utiliser correctement les URL d’exécution. Nous expliquons les deux scénarios pertinents et leur motivation dans les deux sections suivantes.

3.1.5.3. Détection des rachats et URL d’exécution

Un problème possible pour les commerçants qui vendent l’accès à des articles numériques est qu’un client peut avoir payé pour un article sur un appareil, mais peut ensuite vouloir le lire sur un autre appareil, peut-être un appareil qui n’a même pas de porte-monnaie Taler installé.

Naturellement, à ce stade, le client sera encore invité à payer à nouveau pour l’article. Si le client ouvre ensuite le lien taler:// dans le portefeuille qui a précédemment payé l’article (par exemple en scannant le code QR sur le bureau avec l’application Android), le portefeuille réclamera le contrat, détectera que l’URL d’exécution est identique à une URL pour laquelle il a déjà effectué un paiement dans le passé, et lancera une réorientation d’achat : Le portefeuille contacte alors le commerçant et rejoue le paiement précédent, mais cette fois en utilisant l’identifiant de session (actuel) du navigateur (il apprend l’identifiant de session à partir du code QR).

Le backend du commerçant met alors à jour l’ID de session de la commande existante en fonction de l’ID de session actuel du navigateur. Lorsque le statut de paiement de la « nouvelle » commande non payée est vérifié (ou déjà en interrogation longue), le backend détecte que pour les session ID et fulfillment URL du navigateur, il existe un contrat payé existant. Il demande alors au navigateur de rediriger immédiatement vers l’URL d’exécution où l’article déjà payé est disponible.

Il est donc essentiel que les commerçants utilisent toujours la même URL de traitement pour le même produit numérique lorsque la détection des rachats est souhaitée.

Note

Le changement de l’identifiant de session vers un autre appareil nécessite l’intervention du portefeuille d’origine qui a effectué le paiement, ce qui limite raisonnablement la possibilité de partager largement les achats numériques.

3.1.5.4. Permettre des achats répétés

Pour que ce mécanisme fonctionne comme prévu, les marchands doivent veiller à ne pas utiliser le même URL de traitement pour différents produits ou pour des produits physiques pour lesquels les clients sont susceptibles d’acheter l’article à plusieurs reprises. De même, il est essentiel que les commerçants utilisent systématiquement la même URL de traitement pour le même produit numérique lorsque la détection des achats répétés est souhaitée.

Une façon pratique de créer une URL de traitement unique est d’incorporer l”identifiant de la commande dans l’URL de traitement. Pour permettre l’utilisation de l’ID de la commande dans une URL d’exécution même si le champ order_id n’est pas défini par le marchand lors du POST d’une nouvelle commande (et donc l’ID de la commande sera choisi par le backend du marchand), vous pouvez utiliser le texte placeholder ${ORDER_ID} dans le fulfillment_url lors de l’envoi au backend du marchand. Le backend du marchand remplacera alors immédiatement ${ORDER_ID}` dans l’URL par l’ID réel de la commande (avant de persister les termes du contrat localement).