B2BinPay — криптовалютная платежная система с множеством связанных бэкэндов приложений, аналитики, нод, очередей, но лишь одной UI-страницей, которую видит конечный пользователь. К ней предъявляются высокие требования относительно удобства в использовании. Несмотря на кажущуюся простоту страницы, команде разработчиков было бы интересно поделиться тем, как она устроена изнутри.
Для понимания бизнес-процессов потребуется погрузиться в предметную область. Для читателей, которые ещё не знают, что такое криптовалюта, блокчейн и адрес, мы составили короткие и понятные определения под катом.
Цикл проведения платежа происходит следующим образом: на сайте магазина покупатель выбирает товар и валюту оплаты. Система перенаправляет пользователя на страницу платежа. На ней содержится следующая информация: валюта, адрес, информационные комментарии. Пользователь отправляет необходимую сумму по указанному адресу и ожидает достаточного количества подтверждений сети, чтобы признать платеж успешным. Во время ожидания покупатель может следить за статусом платежа, не уходя со страницы на сайт-эксплорер. Как только платеж принят, пользователь переправляется на страницу успешной оплаты на сайт продавца.
Процесс платежа делится на несколько этапов. Каждый из них не требует действий пользователя, кроме непосредственного перевода денег. Стандартный успешный сценарий:
Соответственно, страница платежа может находиться в двух состояниях: просмотр реквизитов и ожидание подтверждения. При просмотре реквизитов ввести адрес можно двумя способами: отсканировать QR-код или скопировать адрес в текстовом виде. Кроме основной информации добавим мини-инструкцию в текстовом виде, которая расскажет, как оплатить, где скачать приложение-кошелек и как купить валюту. Помимо этих полей есть еще одно, наличие которого зависит от выбранной валюты. Иногда для корректного сопоставления транзакции, платежного поручения и покупателя требуется знать не только адрес, но и дополнительную информацию. Например, у валюты Ripple при отправке необходимо указать destination tag (комментарий к транзакции).
Для тех, кто копирует адрес в текстовом виде, а не сканирует QR-код, добавлена кнопка копирования. Также на странице должен присутствовать логотип монеты, так как многие люди идентифицируют валюту визуально, по форме и цветовой гамме логотипа, а не по буквенному обозначению.
Смена состояния происходит в тот момент, когда обнаружена входящая транзакция на платежный адрес. В этот момент реквизиты исчезают, так как больше не требуются; пользователь переходит в режим ожидания, а страница нуждается в постоянном потоке информации о статусе транзакции. Теперь на странице можно найти: время ожидания до завершения транзакции, текущее количество подтверждений, короткий комментарий, поясняющий дальнейшие действия.
Страница должна быть легкой для восприятия, интуитивно понятной и в то же время достаточно информативной. Для опытных покупателей необходимо делать акценты на адресе и сумме.
Из перечисленных требований получился макет будущей страницы.
Первый вариант реализации бэкэнда — обойтись совсем без него! При генерации страницы оплаты заранее известно, на какой адрес будут отправлены деньги. Получать новые транзакции по этому адресу можно из эксплорера средствами JS. Таким образом, задача сводится к тому, чтобы написать коннекторы к эксплорерам и периодически опрашивать нужный. Статичная схема классов могла бы выглядеть следующим образом:
Плюсы: нет нагрузки на наши мощности, легко реализовать, потенциальные угрозы безопасности отсутствуют.
Минусы: ненадежность источников и несвоевременное поступление новой информации, трудности при доставке обновлений кодовой базы конечным клиентам (неконтролируемое кэширование). Решающий минус — многие валюты не имеют стабильных эксплореров с развитым API.
Второй вариант (рабочий) — собственный микросервис, который получает информацию непосредственно от пулла нод, фильтрует и распределяет по платежным страницам. Использование Server Side Events на клиенте снизит уровень избыточности и сэкономит трафик. SSE вписываются в вариант использования, так как страница пассивна в своем поведении — она лишь принимает новую информацию.
Минусы: много затрат на реализацию, дополнительная нагрузка на оборудование.
Плюсы: высокий уровень надежности и независимость от сторонних сервисов; контекст заказа, а не транзакции.
Принципиальная схема:
Когда в браузере покупателя открывается платежная страница, на асинхронный бэкэнд микросервиса отправляется запрос на создание SSE-соединения. В запросе указывается адрес, который нужно отслеживать, сумма платежа, время жизни и другие незначительные параметры. На бэкэнде это хранится в in-memory noSQL хранилище. Каждый раз, когда на любой из блокчейн-нод появляется новый блок, приложение получает и извлекает из него полезную информацию по адресам и транзакциям, хранящимся в БД. Если очередной блок полезен, то обновления отправляются клиентам. Соединения закрываются по инициативе сервера в момент, когда получено достаточно подтверждений или истекло TTL.
Таким образом, бэкэнд производит ресурсоемкие операции и гоняет трафик только в момент поступления новой информации на ноду, а периодическое «опрашивание» на предмет новой информации отсутствует. Благодаря асинхронности получаем высокую скорость работы с тысячами одновременных подключений.
Зная, что для монет с PoW задержка при получении новой информации в пределах секунды незначительна, минимальное горизонтальное масштабирования такой системы даст большой прирост пропускной способности. В особенно активные дни, такие как «черная пятница», нагрузка возрастает. На случай, если система не справляется или технически неисправна, то на клиенте предусмотрено fallback-состояние, в котором страница остаётся в режиме просмотра реквизитов навсегда. Для PoS-монет этап с мониторингом количества подтверждений можно пропустить, так как скорость транзакции часто составляет от 2 до 5 секунд.
Третий вариант реализации бэкэнда — гибридный, когда в зависимости от скорости транзакции блокчейна и информации о текущей доступности сторонних сервисов, используются либо SSE, либо HTTP взаимодействие с эксплорерами. Является самым эффективным и трудозатратным одновременно.
Подходящая для задачи фронтэнд-технология — vue.js с декларативной отрисовкой и возможностью создать несколько состояний компонента. Это легковесная библиотека с изящной структурой и реактивным изменением DOM. Источник данных — SSE-соединение, которое открывается при инициализации компонента.
Мы развиваем продукт и делаем его качественным и надежным, чтобы сделать блокчейн-платежи удобными, массовыми и доступными. Мы любим не только деньги, но и самые передовые технологии, сложные задачи и элегантные решения.
В разработке платежной системы B2BinPay нами регулярно решаются задачи, которые, не смотря на их кажущуюся простоту, требуют нестандартного подхода или свежего взгляда. Будем благодарны за отзывы, комментарии и предложения. Если вы хотите привнести новые и смелые идеи в платежный сервис, которым пользуются по всему миру, – смотрите актуальные вакансии.
Для понимания бизнес-процессов потребуется погрузиться в предметную область. Для читателей, которые ещё не знают, что такое криптовалюта, блокчейн и адрес, мы составили короткие и понятные определения под катом.
Для понимания терминов, приведем аналогии с фиатным миром платежей:
Блокчейн — децентрализованная (в идеальном случае) база данных, хранящая в себе информацию об адресах, транзакциях, балансах. Она состоит из блоков, в каждом из них содержится ограниченное количество информации. Блоки генерируются благодаря майнерам путем энергозатратных расчетов (PoW) или доказательством доли (PoS). Каждый следующий блок содержит в себе список новых транзакций и ссылку на предыдущий. У каждой криптовалюты собственный блокчейн.
Мерчант — то же, что и владелец магазина, арендующий платежную систему для приёма платежей у конечных пользователей.
Кошелек — то же, что и счет в традиционном финансовом мире.
Транзакция — запись в блокчейне о том, что с одного кошелька отправлены средства на другой. Баланс кошелька формируется из суммы транзакций.
Адрес — то же, что и реквизиты счета. Разница в том, что большинство блокчейнов позволяют генерировать бесконечное количество адресов для одного кошелька.
Подтвержденная транзакция — такая транзакция, после которой было сгенерировано безопасное количество блоков. Один блок равен одному подтверждению. Если транзакция не получила 4-8 подтверждений, то она не считается завершенной.
Платежная система — ПО, обеспечивающее прием и обработку платежей в криптовалюте. Связывает и агрегирует заказы, платежи, транзакции, возвраты, пополнения, выводы и прочую информацию. Также информирует систему мерчанта об изменениях в контексте заказов и оплат, а не блокчейнов и транзакций.
Эксплорер — сервис или сайт-обозреватель данных, поступающих в блокчейн. Используя такой сервис, можно в удобном виде получить информацию об адресах, транзакциях и блоках.
Нода — компьютер, на котором хранится копия всей базы данных (блокчейна).
Мерчант — то же, что и владелец магазина, арендующий платежную систему для приёма платежей у конечных пользователей.
Кошелек — то же, что и счет в традиционном финансовом мире.
Транзакция — запись в блокчейне о том, что с одного кошелька отправлены средства на другой. Баланс кошелька формируется из суммы транзакций.
Адрес — то же, что и реквизиты счета. Разница в том, что большинство блокчейнов позволяют генерировать бесконечное количество адресов для одного кошелька.
Подтвержденная транзакция — такая транзакция, после которой было сгенерировано безопасное количество блоков. Один блок равен одному подтверждению. Если транзакция не получила 4-8 подтверждений, то она не считается завершенной.
Платежная система — ПО, обеспечивающее прием и обработку платежей в криптовалюте. Связывает и агрегирует заказы, платежи, транзакции, возвраты, пополнения, выводы и прочую информацию. Также информирует систему мерчанта об изменениях в контексте заказов и оплат, а не блокчейнов и транзакций.
Эксплорер — сервис или сайт-обозреватель данных, поступающих в блокчейн. Используя такой сервис, можно в удобном виде получить информацию об адресах, транзакциях и блоках.
Нода — компьютер, на котором хранится копия всей базы данных (блокчейна).
Общая схема работы и требования к содержимому страницы оплаты
Цикл проведения платежа происходит следующим образом: на сайте магазина покупатель выбирает товар и валюту оплаты. Система перенаправляет пользователя на страницу платежа. На ней содержится следующая информация: валюта, адрес, информационные комментарии. Пользователь отправляет необходимую сумму по указанному адресу и ожидает достаточного количества подтверждений сети, чтобы признать платеж успешным. Во время ожидания покупатель может следить за статусом платежа, не уходя со страницы на сайт-эксплорер. Как только платеж принят, пользователь переправляется на страницу успешной оплаты на сайт продавца.
Процесс платежа делится на несколько этапов. Каждый из них не требует действий пользователя, кроме непосредственного перевода денег. Стандартный успешный сценарий:
- На сайте продавца пользователь выбирает способ оплаты B2BinPay и валюту
- ИС продавца отправляет запрос на создание нового платежного поручения, получая в ответе ссылку на страницу оплаты
- Происходит редирект пользователя на страницу оплаты, где содержится информация: валюта, сумма, адрес и дополнительные поля при необходимости
- Пользователь оплачивает покупку
- Система обнаруживает, что по адресу поступила новая транзакция и страница переходит в состояние отслеживания
- Производится мониторинг статуса транзакции и обновление информации на странице до тех пор, пока не будет достигнуто безопасное количество подтверждений
- Пользователь перенаправляется на страницу успешной оплаты на сайт продавца
Соответственно, страница платежа может находиться в двух состояниях: просмотр реквизитов и ожидание подтверждения. При просмотре реквизитов ввести адрес можно двумя способами: отсканировать QR-код или скопировать адрес в текстовом виде. Кроме основной информации добавим мини-инструкцию в текстовом виде, которая расскажет, как оплатить, где скачать приложение-кошелек и как купить валюту. Помимо этих полей есть еще одно, наличие которого зависит от выбранной валюты. Иногда для корректного сопоставления транзакции, платежного поручения и покупателя требуется знать не только адрес, но и дополнительную информацию. Например, у валюты Ripple при отправке необходимо указать destination tag (комментарий к транзакции).
Для тех, кто копирует адрес в текстовом виде, а не сканирует QR-код, добавлена кнопка копирования. Также на странице должен присутствовать логотип монеты, так как многие люди идентифицируют валюту визуально, по форме и цветовой гамме логотипа, а не по буквенному обозначению.
Смена состояния происходит в тот момент, когда обнаружена входящая транзакция на платежный адрес. В этот момент реквизиты исчезают, так как больше не требуются; пользователь переходит в режим ожидания, а страница нуждается в постоянном потоке информации о статусе транзакции. Теперь на странице можно найти: время ожидания до завершения транзакции, текущее количество подтверждений, короткий комментарий, поясняющий дальнейшие действия.
Страница должна быть легкой для восприятия, интуитивно понятной и в то же время достаточно информативной. Для опытных покупателей необходимо делать акценты на адресе и сумме.
Из перечисленных требований получился макет будущей страницы.
Бэкэнд
Первый вариант реализации бэкэнда — обойтись совсем без него! При генерации страницы оплаты заранее известно, на какой адрес будут отправлены деньги. Получать новые транзакции по этому адресу можно из эксплорера средствами JS. Таким образом, задача сводится к тому, чтобы написать коннекторы к эксплорерам и периодически опрашивать нужный. Статичная схема классов могла бы выглядеть следующим образом:
Плюсы: нет нагрузки на наши мощности, легко реализовать, потенциальные угрозы безопасности отсутствуют.
Минусы: ненадежность источников и несвоевременное поступление новой информации, трудности при доставке обновлений кодовой базы конечным клиентам (неконтролируемое кэширование). Решающий минус — многие валюты не имеют стабильных эксплореров с развитым API.
Второй вариант (рабочий) — собственный микросервис, который получает информацию непосредственно от пулла нод, фильтрует и распределяет по платежным страницам. Использование Server Side Events на клиенте снизит уровень избыточности и сэкономит трафик. SSE вписываются в вариант использования, так как страница пассивна в своем поведении — она лишь принимает новую информацию.
Минусы: много затрат на реализацию, дополнительная нагрузка на оборудование.
Плюсы: высокий уровень надежности и независимость от сторонних сервисов; контекст заказа, а не транзакции.
Принципиальная схема:
Когда в браузере покупателя открывается платежная страница, на асинхронный бэкэнд микросервиса отправляется запрос на создание SSE-соединения. В запросе указывается адрес, который нужно отслеживать, сумма платежа, время жизни и другие незначительные параметры. На бэкэнде это хранится в in-memory noSQL хранилище. Каждый раз, когда на любой из блокчейн-нод появляется новый блок, приложение получает и извлекает из него полезную информацию по адресам и транзакциям, хранящимся в БД. Если очередной блок полезен, то обновления отправляются клиентам. Соединения закрываются по инициативе сервера в момент, когда получено достаточно подтверждений или истекло TTL.
Таким образом, бэкэнд производит ресурсоемкие операции и гоняет трафик только в момент поступления новой информации на ноду, а периодическое «опрашивание» на предмет новой информации отсутствует. Благодаря асинхронности получаем высокую скорость работы с тысячами одновременных подключений.
Зная, что для монет с PoW задержка при получении новой информации в пределах секунды незначительна, минимальное горизонтальное масштабирования такой системы даст большой прирост пропускной способности. В особенно активные дни, такие как «черная пятница», нагрузка возрастает. На случай, если система не справляется или технически неисправна, то на клиенте предусмотрено fallback-состояние, в котором страница остаётся в режиме просмотра реквизитов навсегда. Для PoS-монет этап с мониторингом количества подтверждений можно пропустить, так как скорость транзакции часто составляет от 2 до 5 секунд.
Третий вариант реализации бэкэнда — гибридный, когда в зависимости от скорости транзакции блокчейна и информации о текущей доступности сторонних сервисов, используются либо SSE, либо HTTP взаимодействие с эксплорерами. Является самым эффективным и трудозатратным одновременно.
Подходящая для задачи фронтэнд-технология — vue.js с декларативной отрисовкой и возможностью создать несколько состояний компонента. Это легковесная библиотека с изящной структурой и реактивным изменением DOM. Источник данных — SSE-соединение, которое открывается при инициализации компонента.
Дизайн
Мы развиваем продукт и делаем его качественным и надежным, чтобы сделать блокчейн-платежи удобными, массовыми и доступными. Мы любим не только деньги, но и самые передовые технологии, сложные задачи и элегантные решения.
В разработке платежной системы B2BinPay нами регулярно решаются задачи, которые, не смотря на их кажущуюся простоту, требуют нестандартного подхода или свежего взгляда. Будем благодарны за отзывы, комментарии и предложения. Если вы хотите привнести новые и смелые идеи в платежный сервис, которым пользуются по всему миру, – смотрите актуальные вакансии.
