Как мы тестировали платежи, а в итоге сделали свой ngrok

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

Процесс выгляди так:

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

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

Тут может быть стразу несколько сложностей. Во первых сейчас мы живём в 2023-м году, а значит ipv6 ещё не заменил ipv4 и дефицит публичных IP адресов остаётся актуальной проблемой. От сюда проблема - публичного адреса нет и провайдер не может его дать, так как сам во всю использует CGNAT. Но даже если есть публичный IP тогда вам нужен маршрутизатор в настройках которого вы сможете настроить проброс порта на свою локальную машину. Если же вы решили пойти поработать в кафе, то это становится не возможно в принципе.

Плюсы

Минусы:

Разработкой в облаке уже никого не удивишь, есть такие решения как Telepresence, Garden, DevSpace, okteto. Типичный процесс работы с подобными системами выглядит следующим образом – я создаю какой-то файл-манифест, в котором описываю свой проект и способ его развертывания, запускаю какую-то команду up, стенд поднимается, мне предоставляется публичная ссылка, по условной команде dev мой сервис, запущенный в облаке, переключается в режим разработки – открываются нужные порты в облачную среду, запускается синхронизация файлов, теперь я могу зайти внутрь этого виртуального окружения и запускать/отлаживать свое приложение.

Плюсы:

Минусы:

Еще один вариант – открывать туннель в свою локальную сеть, чтобы все запросы на публичный адрес попадали напрямую в мой сервис. Тут тоже разнообразие сервисов и, наверное, самый известный – это ngrok, есть еще inlets, tunnelin, localxpose.

Работают эти все решения по одному принципу – некоторый консольный клиент при запуске подключается к какому-то публичному хосту и открывает сессию, которой присваивает публичный адрес, запрос пользователя к этому адресу сначала идет на этот публичный хост, а потом через открытую с консольным клиентом сессию попадает в уже пользовательский сервис.

Плюсы:

Минусы:

Можно арендовать свой небольшой сервер у любого провайдера и пробрость порт по SSH. Технические детали описывать не буду, статей на эту тему много, например тут.

Плюсы:

Минусы:

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

Работать с сервисом несложно – после первичной настройки запускаем команду tuna http 8080 и получаем ссылку на наш сервис, которую и используем в конфигурации платежной системы тестового магазина:

Чтобы получить статичный домен нужно передать соответствующий флаг, поэтому запускать нужно так – tuna http 8080 --subdomain=my-service-lev, команда стала чуть больше, но все еще понятна, однако каждый раз вспоминать порт сервиса и привязанный к оплате домен неудобно, поэтому дополнительно локально мы используем такой инструмент как direnv.

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

При каждом запуске мы даем понять сервису, что он работает в локальном окружении, поэтому часть функционала расширена или просто отключена. Последней строкой мы даем понять direnv, что нужно прочитать пользовательские персонализированные настройки из файла .env – этот файл ни в коем случае не должен попасть в репозиторий, у каждого разработчика этот файл свой (проверьте содержимое .gitignore, что файл .env там указан), как правило в этом файле перечислены тестовые пароли, ключи, почтовые ящики.

Ну, а теперь соединяем все вместе, содержимое файла .envrc:

В добавленной строке мы даем понять tuna на каком порту работает наш сервис – это настройка универсальна для всех, поэтому храним в общем файле. А так выглядит содержимое моего файла .env:

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

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

Есть у tuna и дополнительный полезный функционал, о нем расскажу ниже.

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

Часто надо поделиться каким-то файлом и приходится загружать его в Google Drive или Telegram. Встроенный файловый сервер позволяет легко расшарить любой каталог на вашем компьютере, скопировать ссылку и дать её другу. Работает всё также просто, нужно просто добавить 1 флаг и указать путь к желаемому каталогу, в ответ вы получаете ссылку, перейдя по которой можно увидеть содержимое вашего каталога и скачать любой файл:

Когда вы хотите получить техническую поддержку от друга или какой либо компании, но не можете предоставить подключение по SSH или ленитесь настраивать, то в tuna достаточно написать:

Будет запущен встроенный SSH-server, а в терминале вы увидите короткую инструкцию для подключения:

Отправляете это вашему другу/тех. поддержке и когда он подключится, это вы тоже увидите.

Также можно настраивать аутентификацию, задать разрешённые подсети, добавлять заголовки, включать CORS, пробрасывать TCP порт, указать в назначении сторонний IP, в общем, функционал получился достаточно богатый, да и запланировано еще много интересного.

А ещё у нас есть хосты (через который строится туннель) в России, а это значит, что трафик не будет делать огромный крюк через дата центры в Европе или Америке.

Сервис можно оплатить рублями через сервис Юкасса, а цена более чем приятная.

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

Подробнее можете посмотреть всё на сайте https://tuna.am/#pricing, надеюсь вам понравится работать с tuna и спасибо, что дочитали до конца 🙂

Если у вас возникли вопросы, можете задать их нам по почте info@tuna.am

P.S.: Ещё ранее мы писали о нашем сервере для видеонабдюдения Yucca. Оригинал стати у нас в блоге.