3.1.5. Comprendre les 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 d’exécution

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 prennent connaissance du 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, il ne devrait contenir aucune information d’identification ni aucune information que l’utilisateur pourrait être en train 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. URLs d’exécution

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 d’exécution ont un deuxième objectif : elles sont également utilisées pour la détection des rachats. 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

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 redirection de rachat : 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 d’exécution 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 la détection des rachats n’empêche pas les clients d’acheter à nouveau le même service ou bien physique, les commerçants doivent veiller à ne pas utiliser la même URL d’exécution pour des produits différents ou pour des produits physiques que les clients sont susceptibles d’acheter à plusieurs reprises.

Une façon pratique de créer une URL d’exécution unique est d’incorporer l”identifiant de la commande dans l’URL d’exécution. Pour permettre l’utilisation de l’identifiant 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’identifiant de la commande sera choisi par le backend du marchand), vous pouvez utiliser le texte de substitution ${ORDER_ID} dans le fulfillment_url lors de son envoi au backend du marchand. Le backend du marchand remplacera alors immédiatement ${ORDER_ID} dans l’URL par l’identifiant réel de la commande (avant de persister localement les termes du contrat).