Обнаружение повторных покупок и URL-адреса для их совершения

3.1.5. Обнаружение повторных покупок и URL-адреса для их совершения#

Ордера и контракты Taler должны содержать либо fulfillment_url, либо fulfillment_message, которые используются кошельком после оплаты контракта. В этом руководстве объясняется, как правильно установить эти значения.

3.1.5.1. Сообщение о выполнении#

Это поле - просто сообщение, которое будет показано пользователю кошельком Taler после того, как он завершит покупку. Оно может быть задано в любом виде текста UTF-8 и должно использоваться в качестве дружественного финального сообщения от продавца в конце транзакции.

Примечание

Кошельки узнают текст до совершения покупки, поэтому пользователи могут получить сообщение о выполнении контракта до фактической покупки. В результате оно не должно содержать никаких реальных учетных данных или информации, которую пользователь мог бы приобрести с помощью контракта.

Сообщения о выполнении используются, когда у продавца нет URL-адреса для перенаправления пользователя.

3.1.5.2. fulfillment_url#

Контракты могут содержать fulfillment_url вместо fulfillment_message. Ссылка на веб-сайт (начинающийся с http:// или https://), на который пользователь будет перенаправлен сразу после совершения покупки и, возможно, позже из диалога деталей покупки в истории транзакций кошелька.

URL-адреса выполнения служат второй цели - они также используются для обнаружения повторных покупок. Таким образом, необходимо позаботиться о правильном использовании URL-адресов выполнения заказа. Мы объясним два соответствующих сценария и их мотивацию в следующих двух разделах.

3.1.5.3. Обнаружение повторных покупок и URL-адреса для их совершения#

Возможная проблема для продавцов, продающих доступ к цифровым статьям, заключается в том, что покупатель может оплатить статью на одном устройстве, но затем захотеть прочитать ее на другом, возможно, на том, на котором даже не установлен кошелек Taler.

Естественно, в этот момент покупателю сначала все равно будет предложено оплатить статью еще раз. Если клиент откроет ссылку taler:// в кошельке, с которого ранее была произведена оплата статьи (например, отсканировав QR-код на рабочем столе с помощью приложения для Android), кошелек заявит о контракте, обнаружит, что URL-адрес выполнения идентичен тому, за который он уже производил оплату в прошлом, и инициирует перенаправление покупки: Здесь кошелек свяжется с продавцом и повторит предыдущий платеж, только на этот раз используя (текущий) идентификатор сессии браузера (он узнает идентификатор сессии из QR-кода).

Затем бэкэнд продавца обновляет идентификатор сессии существующего заказа до текущего идентификатора сессии браузера. Когда проверяется статус оплаты «нового» неоплаченного заказа (или уже в процессе длительного опроса), бэкэнд обнаруживает, что для идентификатора сессии и * URL-адреса выполнения* браузера существует уже оплаченный контракт. Затем он указывает браузеру немедленно перенаправить его на URL выполнения, где доступна уже оплаченная статья.

Поэтому очень важно, чтобы продавцы постоянно использовали один и тот же URL-адрес для одного и того же цифрового продукта, если требуется выявление повторных покупок.

Примечание

Для смены идентификатора сессии на другом устройстве требуется участие первоначального кошелька, с которого был совершен платеж, что разумно ограничивает возможность широкого обмена цифровыми покупками.

3.1.5.4. Разрешение повторных покупок#

Чтобы этот механизм работал так, как задумано, продавцы должны следить за тем, чтобы не использовать один и тот же URL-адрес выполнения для разных товаров или для физических товаров, где покупатели, как ожидается, будут приобретать товар неоднократно. Аналогичным образом, очень важно, чтобы продавцы постоянно использовали один и тот же URL-адрес для одного и того же цифрового продукта, если требуется выявление повторных покупок.

Удобным способом создания уникального URL-адреса выполнения заказа является вставка идентификатора заказа в URL-адрес выполнения заказа. Чтобы включить использование ID заказа в URL-адресе выполнения заказа, даже если поле order_id не задано продавцом при ПОСТе нового заказа (и, таким образом, фактический ID заказа будет выбран бэкендом продавца), вы можете использовать текст-плейсхолдер ${ORDER_ID} в fulfillment_url при постинге его в бэкенд продавца. Тогда бэкэнд продавца сразу же заменит ${ORDER_ID} в URL на реальный ID заказа (перед сохранением условий контракта локально).