3.1.5. URL’s voor herkoop en uitvoering

Taler bestellingen en contracten moeten een fulfillment_url of een fulfillment_message bevatten, die door de portemonnee worden gebruikt nadat het contract is betaald. Deze tutorial legt uit hoe je deze waarden op de juiste manier instelt.

3.1.5.1. Bericht

Dit veld is simpelweg een bericht dat aan de gebruiker wordt getoond door de Taler portemonnee nadat de gebruiker de aankoop heeft afgerond. Het kan worden ingesteld op elke soort UTF-8-tekst en het moet worden gebruikt als een vriendelijk eindbericht van de verkoper aan het einde van de zakelijke transactie.

Notitie

Whe wallets leren de tekst voordat de aankoop wordt gedaan, dus gebruikers zouden het bericht van de vervulling kunnen krijgen voordat de daadwerkelijke aankoop plaatsvindt. Als gevolg hiervan zou het geen werkelijke referenties of informatie mogen bevatten die de gebruiker zou kunnen kopen met het contract.

Fulfillment berichten worden gebruikt wanneer de merchant geen fulfillment URL heeft om de gebruiker naar door te verwijzen.

3.1.5.2. vervulling_url

Contracten kunnen een fulfillment_url bevatten in plaats van een fulfillment_message. De fulfillment_url moet verwijzen naar een website (beginnend met http:// of https://) en de gebruiker zal daar naartoe worden geleid direct nadat hij de aankoop heeft afgerond en mogelijk later vanuit het aankoopdetailscherm in de transactiegeschiedenis van zijn portemonnee.

Fulfillment URL’s dienen nog een tweede doel, namelijk dat ze ook worden gebruikt voor repurchase detection. Er moet dus goed op worden gelet dat URL’s correct worden gebruikt. We leggen de twee relevante scenario’s en hun motivatie uit in de volgende twee paragrafen.

3.1.5.3. URL’s voor herkoop en uitvoering

Een mogelijk probleem voor verkopers die toegang tot digitale artikelen verkopen, is dat een klant voor een artikel op het ene apparaat heeft betaald, maar het vervolgens op een ander apparaat wil lezen, mogelijk een apparaat waarop niet eens een Taler-portemonnee is geïnstalleerd.

Natuurlijk wordt de klant dan eerst nog gevraagd om opnieuw voor het artikel te betalen. Als de klant vervolgens de taler:// link opent in de portemonnee die eerder voor het artikel heeft betaald (bijvoorbeeld door de QR-code op de desktop te scannen met de Android App), zal de portemonnee het contract claimen, detecteren dat de vervulling URL identiek is aan een waarvoor het al een betaling heeft gedaan in het verleden, en repurchase redirection initiëren: Hier zal de portemonnee contact opnemen met de verkoper en de vorige betaling herhalen, behalve deze keer met behulp van de (huidige) sessie-ID van de browser (het leert de sessie-ID van de QR-code).

De merchant backend werkt dan de sessie ID van de bestaande bestelling bij naar de huidige sessie ID van de browser. Wanneer de betaalstatus voor de “nieuwe” onbetaalde bestelling wordt gecontroleerd (of al in long-polling is), detecteert de backend dat er voor de sessie ID en fulfillment URL van de browser een bestaand betaald contract is. Het vertelt de browser dan om onmiddellijk door te verwijzen naar de URL waar het reeds betaalde artikel beschikbaar is.

Het is dus van cruciaal belang dat verkopers consequent dezelfde URL gebruiken voor hetzelfde digitale product als ze een terugkoopdetectie willen.

Notitie

Het wijzigen van de sessie-ID naar een ander apparaat vereist de betrokkenheid van de oorspronkelijke portemonnee die de betaling heeft gedaan, waardoor de mogelijkheid om de digitale aankopen op grote schaal te delen redelijk wordt beperkt.

3.1.5.4. Herhaalde aankopen toestaan

Om ervoor te zorgen dat dit mechanisme werkt zoals het bedoeld is, moeten winkeliers ervoor zorgen dat ze niet dezelfde URL gebruiken voor verschillende producten of voor fysieke producten waarvan verwacht kan worden dat klanten het artikel herhaaldelijk kopen. Op dezelfde manier is het van cruciaal belang dat verkopers consequent dezelfde URL gebruiken voor hetzelfde digitale product als ze een herhalingsaankoop willen detecteren.

Een handige manier om een unieke fulfillment URL te creëren is om de order ID in te sluiten in de fulfillment URL. Om het gebruik van de order ID in een fulfillment URL mogelijk te maken, zelfs als het order_id veld niet is ingesteld door de merchant bij het POSTEN van een nieuwe order (en dus de werkelijke order ID zal worden gekozen door de merchant backend), kunt u de placeholder tekst ${ORDER_ID} gebruiken in de fulfillment_url wanneer deze wordt gepost naar de merchant backend. De merchant backend zal dan onmiddellijk ${ORDER_ID} in de URL vervangen door de werkelijke order ID (voordat de contractvoorwaarden lokaal worden opgeslagen).