Итак, мы делаем отдельную библиотеку бэкенда (она — друг магазина, прослойка между фронтендом и демоном) на JS. Для удобства отладки делаем модельку в двух вариантах: как JS-библиотеку и как URL на nodeJS, который можно вызывать, например, из бэкенда PHP. Итак, у нас имеется библиотека kalatori_frontend.js тупо с одной функцией function KALATORI(query, order) Вариант: она же, завернутая в http://localhost:12345 для обращения. В функцию передаются два параметра:
query — это, собственно, тот запрос, что прислал фронтенд. Он передается в библиотеку без изменений.
Если интересны подробности, вообще-то запрос фронтенда целиком соответствует API Kalatori — за исключением дополнительного параметра endpoint. Дело в том, что API Kalatori использует эклектику и параллельные сущности — часть параметров передаются как POST, часть почему-то как GET. Поэтому параметр endpoint нужен чтобы пакет данных был един. Но этим, повторю, занимается сам фронтенд, об этом думать не надо. Также отмечу, что фронтенд способен работать с демоном напрямую безо всяких прослоек — это возможно в случае donate, когда сумма добровольна и обман невозможен. Но это тоже не имеет сейчас значения.
Параметр callback можно добавить в запрос фронтенда здесь, а можно в параметре order.
order необязательный параметр с данными этого заказа из базы магазина, где присутствуют все или некоторые параметры. Те, что присутствуют, будут использованы.
order_id: «kalatori_frontend_123»Идентификатор заказа, который будет передан демону как orderId. Не может содержать слэшей и прочих запрещенных в URL символов, поскольку в API это будет часть url. В идеале это номер заказа, а лучше еще имя вашего конкретного магазина, пример: DennyShop_123 Если параметр не указан, в качестве orderId будет передан номер заказа order из запроса query (с добавленным именем kalatori_frontend для удобства отладки).
[!] Внимание! Мы не будем проверять, что «DennyShop_123» похоже какими-то цифрами на order:123, если вы передали идентификатор, именно он и полетит к демону.
total: 123.45
Сумма к оплате. Если этот параметр указан, мы передадим демону именно его, а не ту сумму, что прислал фронтенд в query. Сравнений тоже делать не будем.
currency: «USD»
Валюта, которую установил магазин для заказа. Точнее — имя семейства. Потому что валюта магазина может называться DOT или TUGRIC или USD, но в последнем случае это может оказаться именем целого семейства, начинающегося на USD: USDC, USDT, USD-XZ, и тогда окончательный выбор делает пользователь уже на уровне плагина, магазину без разницы, какой разновидностью доллара ему платят. Демону передается именно конкретный код валюты, что прислал фронтенд, от этого зависит, с какими серверами демон будет работать. Но имеет смысл проверить соответствие первых букв, чтобы покупатель не обманул систему, получив сумму в DOT, а оплатив эту сумму более дешевой валютой USDC. Поэтому, если у магазина currencу=USD, то мы проводим проверку, что код выбранной плагином валюты тоже начинается на «USD».
currencies: «USDC USDT DOT»
Совсем необязательный параметр. Это список валют, которые разрешены для использования в настройках магазина, перечисленные через пробел. Зачем? Например, цена у магазина в USD, демон умеет USDC, USDT, USD-XZ, а у владельца магазина есть аккаунт только в USDС, и он не желает принимать иные. На уровне фронтенда иных вариантов и не отобразится, но вдруг злоумышленник сделает подмену? Мне лень сейчас думать, возможна ли тут какая-то уязвимость и сможет ли злодей как-то получить деньги на свой же счет в USD-XZ, поэтому мы на всякий случай просто ограничиваем возможность использовать валюты, запрещенные в магазине.
callback: «https://my_great_store.me/callback?id=123&hash=d1438b69fa53e6d9a3ce321e3096b9ac28652a70"
URL, по которому демон стукнет магазину в случае успешного платежа. Это любой произвольный URL, но мы рекомендуем, чтобы в нем содержался id заказа и секретный хэш, гарантирующий, что этот URL сформирован вашим магазином. Например, hash=sha1('my order 123');
Если callback не указан, то демон работает без каллбэка — бэкенд повторяет фоновые запросы (некоторое разумное время) до тех пор, пока демон (и, соответственно, функция KALATORI) не вернет payment_status: 'paid', и этот paid на выходе будет пойман и обработан движком вашего магазина.
Все страницы по теме «kalatori»: 2024-06-17: KALATORI: Хуепутало: логика валютных курсов |