3.1.5. URL-адреси для виявлення та виконання зворотного викупу#
Замовлення і контракти Taler повинні містити або URL_виконання, або повідомлення_виконання, які використовуються гаманцем після того, як контракт буде оплачено. Ця інструкція пояснює, як правильно встановити ці значення.
3.1.5.1. Повідомлення про виконання#
Це поле є просто повідомленням, яке буде показано користувачеві гаманцем Taler після того, як користувач завершить покупку. Воно може бути налаштоване на будь-який тип тексту в кодуванні UTF-8 і має використовуватися як дружнє фінальне повідомлення від продавця в кінці бізнес-транзакції.
Примітка
Гаманці запам’ятовують текст перед здійсненням покупки, щоб користувачі могли отримати повідомлення про виконання замовлення до фактичної покупки. Як наслідок, воно не повинно містити жодних реальних облікових даних або інформації, яку користувач міг би придбати за контрактом.
Повідомлення про завершення використовуються, коли продавець не має URL-адреси завершення, на яку можна перенаправити користувача.
3.1.5.2. адреса_виконання#
Контракти можуть містити URL_виконання замість повідомлення_виконання. Адреса_виконання_договору повинна вказувати на веб-сайт (починатися з http:// або https://), і користувач буде перенаправлений туди одразу після завершення покупки, а можливо, і пізніше з діалогового вікна деталей покупки в історії транзакцій гаманця.
URL-адреси виконання служать для другої мети, яка полягає в тому, що вони також використовуються для виявлення викупу. Таким чином, необхідно бути обережним, щоб правильно використовувати URL-адреси виконання. Ми пояснимо два відповідні сценарії та їхню мотивацію в наступних двох розділах.
3.1.5.3. URL-адреси для виявлення та виконання зворотного викупу#
Можлива проблема для продавців, які продають доступ до цифрових статей, полягає в тому, що клієнт може заплатити за статтю на одному пристрої, але потім захотіти прочитати її на іншому пристрої, можливо, на якому навіть не встановлений гаманець Taler.
Звичайно, на цьому етапі покупцеві спочатку все одно буде запропоновано оплатити статтю ще раз. Якщо клієнт відкриє посилання taler:// у гаманці, за допомогою якого він раніше оплачував товар (наприклад, відсканувавши QR-код на робочому столі за допомогою програми для Android), гаманець затребує контракт, виявить, що URL-адреса виконання ідентична тій, за якою він вже здійснював оплату в минулому, і ініціює перенаправлення на повторний викуп: Тут гаманець зв’яжеться з продавцем і відтворить попередній платіж, але цього разу з використанням (поточного) ідентифікатора сеансу браузера (він дізнається ідентифікатор сеансу з QR-коду).
Потім бекенд продавця оновлює ідентифікатор сесії існуючого замовлення до поточного ідентифікатора сесії браузера. Коли перевіряється статус оплати «нового» неоплаченого замовлення (або замовлення, яке вже знаходиться в довгій черзі), бекенд виявляє, що для ідентифікатора сеансу і адреси виконання браузера існує оплачений контракт. Потім він повідомляє браузеру, щоб той негайно перенаправив його на URL-адресу виконання, де вже доступна оплачена стаття.
Тому дуже важливо, щоб продавці постійно використовували одну й ту саму URL-адресу для одного й того самого цифрового продукту, де потрібне виявлення зворотного викупу.
Примітка
Зміна ідентифікатора сесії на іншому пристрої вимагає залучення оригінального гаманця, з якого було здійснено платіж, що значно обмежує можливість широкого обміну цифровими покупками.
3.1.5.4. Дозвіл на повторні покупки#
Щоб цей механізм працював належним чином, продавці повинні переконатися, що вони не використовують одну й ту саму URL-адресу для різних товарів або для фізичних товарів, якщо очікується, що клієнти купуватимуть товар неодноразово. Так само важливо, щоб продавці постійно використовували одну й ту саму URL-адресу для одного й того самого цифрового продукту, якщо потрібне виявлення зворотного викупу.
Зручним способом створити унікальну URL-адресу виконання є вбудовування ідентифікатора замовлення в URL-адресу виконання. Щоб дозволити використання ідентифікатора замовлення в URL-адресі виконання, навіть якщо поле order_id не встановлено продавцем при ОПУБЛІКУВАННІ нового замовлення (і, таким чином, фактичний ідентифікатор замовлення буде обраний бекендом продавця), ви можете використовувати текст-заповнювач ${ORDER_ID} в fulfillment_url при його відправленні в бекенд продавця. Тоді бекенд продавця негайно замінить ${ORDER_ID} в URL-адресі на фактичний ідентифікатор замовлення (перед тим, як зберегти умови контракту локально).