Payora — крипто-платёжный шлюз под ключ

01Обзор проекта

Payora — это платёжный шлюз для приёма криптовалюты, который бизнес разворачивает у себя и полностью контролирует. В отличие от привычных платёжных провайдеров, Payora не становится посредником между покупателем и продавцом: средства идут напрямую на адреса мерчанта, а сервер шлюза не хранит приватных ключей и не распоряжается деньгами. Отсюда два ключевых свойства, вынесенных в само описание продукта, — self-hosted (разворачивается на инфраструктуре владельца) и non-custodial (ваши ключи — ваши средства).

Идея проекта родилась из простого наблюдения: почти каждый онлайн-сервис, которому нужно принимать крипту, заново изобретает один и тот же платёжный модуль. Кто-то прикручивает сторонний процессинг и платит комиссию и за транзакции, и за вывод; кто-то пишет приём «на коленке», без вебхуков, без сверки сумм и без нормальной обработки недоплат. Payora собирает эту повторяющуюся работу в один продукт: единый API, готовый платёжный экран (hosted-checkout) и подписанные вебхуки, которые сообщают магазину о факте оплаты.

Мы спроектировали и собрали продукт целиком — от инфраструктуры и архитектуры до посадочной страницы, кабинета и документации. Ниже разбираем, какую задачу решает Payora, как он устроен внутри и какие инженерные решения позволили сделать приём криптовалюты предсказуемым и безопасным.

Отдельно стоит сказать про контекст. Payora задумывался не как разовый виджет оплаты, а как общий платёжный слой для целого набора проектов: подключаешь один раз — и принимаешь крипту в любом из своих сервисов, заводя их как отдельных мерчантов. Такой подход экономит десятки часов на каждом новом продукте и убирает зоопарк несовместимых платёжных модулей, который обычно расползается по сайтам со временем. Чем больше у владельца проектов, тем выше отдача от единого шлюза: одна точка обновления, одна модель безопасности, одна логика статусов на всех.

02Контекст и задача

Принять криптоплатёж «технически» несложно — сложно сделать это надёжно и повторяемо. Когда мы разбирали задачу, на поверхность всплыл целый набор болей, с которыми сталкивается каждый, кто принимает крипту самостоятельно:

• Кастодиальный риск. Сторонние процессинги держат средства у себя: это и комиссии, и лимиты, и риск заморозки или ухода сервиса вместе с деньгами.
• Дублирование кода. На каждом новом сайте платёжный модуль пишется заново — генерация адресов, отслеживание поступлений, сверка суммы, статусы счёта.
• Ненадёжные уведомления. Магазин должен узнать об оплате мгновенно и доверять источнику. Самописные «пинги» легко подделать, а опрос блокчейна вручную — это нагрузка и задержки.
• Сопоставление платежа со счётом. Если все платят на один адрес, понять, кто и за что заплатил, превращается в головную боль.
• Недоплаты и переплаты. Курс плавает, пользователь округляет сумму, сеть берёт комиссию — нужна логика частичной оплаты и допустимого отклонения.

Задача формулировалась так: построить шлюз, который снимает всю эту рутину с разработчика магазина, но при этом не отнимает контроль над деньгами. Мерчант должен подключить приём криптовалюты за вечер, а не за спринт, и при этом точно знать, что средства приходят ему напрямую.

Отдельный пласт задачи — это доверие на стороне покупателя. Платёжный экран должен выглядеть так, чтобы человек не побоялся отправить средства: понятная сумма, видимый адрес, QR-код и таймер до истечения счёта. Любая неопрятность здесь напрямую бьёт по доходимости оплаты, поэтому checkout мы рассматривали не как «технический экран», а как полноценную часть воронки продаж.

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

03Цели проекта

Из задачи выросли конкретные продуктовые и инженерные цели, которые мы держали в голове на всех этапах:

• Простая интеграция. Подключение к сайту — это один запрос на создание счёта и один обработчик вебхука. Не SDK на тысячу строк, а понятный REST.
• Non-custodial по умолчанию. Приватные ключи не покидают сторону владельца. Сервер шлюза работает в режиме «только чтение» там, где это касается приёма средств.
• Готовый платёжный экран. Чтобы мерчанту не нужно было рисовать UI оплаты — Payora отдаёт hosted-checkout со счётом, адресом, QR и таймером.
• Доверенные уведомления. Каждый вебхук подписан, магазин проверяет подпись и не может быть обманут поддельным «оплачено».
• Предсказуемость. Чёткие статусы счёта, понятная логика недоплат и истечения срока, идемпотентность.
• Самостоятельный хостинг. Развёртывание на своём сервере с отдельными поддоменами под API, оплату и админку.

Эти цели сознательно сформулированы как ограничения, а не как «хотелки». Каждое из них отсекало неподходящие архитектурные варианты ещё на этапе проектирования. Например, требование non-custodial сразу убрало из рассмотрения любые схемы, где сервер держит ключи; требование простой интеграции отказалось от тяжёлых SDK в пользу прозрачного HTTP; а требование предсказуемости задало строгую модель статусов вместо «магического» поведения. В итоге продукт получился узким и заточенным — он делает одно, но делает это надёжно.

04Что мы сделали

Payora собирает приём криптовалюты в три понятных составляющих, которые закрывают весь жизненный цикл платежа:

Поверх этого ядра — посадочная страница с понятным позиционированием, кабинет мерчанта для создания проектов и просмотра счетов, и документация, по которой разработчик подключается без созвонов. Всё это развёрнуто как единый продукт на собственной инфраструктуре.

Важно, что эти три составляющие не разрозненны, а образуют замкнутый контур: API создаёт счёт, checkout показывает его покупателю, вебхук возвращает результат магазину. Каждый элемент знает ровно столько, сколько ему нужно, и не лезет в чужую зону ответственности. Именно эта собранность отличает шлюз от набора скриптов: интегратору не приходится самому склеивать куски, он работает с готовым потоком «счёт → оплата → уведомление».

05Архитектура решения

Payora разнесён по нескольким поддоменам — так роли и нагрузки физически отделены друг от друга, а доступы проще ограничивать:

• payora.money — посадочная страница: позиционирование, документация для разработчика, точки входа в кабинет.
• api.payora.money — программный интерфейс: сюда магазины обращаются за созданием и статусом счетов.
• pay.payora.money — hosted-checkout: страница оплаты, которую видит покупатель.
• admin.payora.money — административная панель и кабинет мерчанта: проекты, ключи, история счетов, настройки вебхуков.

Такое деление — не косметика. Оно позволяет давать платёжному экрану и API разные политики кэширования и безопасности, изолировать админку, и при необходимости масштабировать или выносить части независимо. Под капотом — серверный стек на PHP 8.3, развёрнутый в управляемой панелью среде, за Cloudflare (DNS, TLS, защита периметра).

Логически система состоит из четырёх блоков: приёма запросов (API и валидация), учёта счетов (состояние, статусы, суммы и сроки), наблюдения за блокчейном (детект поступлений на адреса счёта) и оповещения (формирование и отправка подписанных вебхуков). Каждый блок отвечает за свой кусок жизненного цикла платежа и общается с остальными через чёткие границы.

Разделение по поддоменам даёт ещё и эксплуатационное преимущество: публично доступная посадочная и checkout живут отдельно от админки, доступ к которой можно дополнительно ограничивать. Если в будущем какой-то из блоков станет узким местом — например, наблюдение за блокчейном при росте числа счетов, — его можно усилить или вынести, не трогая остальные части. Архитектура с самого начала проектировалась под расширение, а не под разовый запуск.

06Как проходит платёж

С точки зрения интегратора весь поток укладывается в несколько шагов, и большая часть из них происходит без участия магазина:

• 1. Создание счёта. Магазин делает запрос к API: сумма, валюта, идентификатор заказа, адрес для вебхука. В ответ — счёт с уникальными реквизитами и ссылкой на hosted-checkout.
• 2. Оплата. Покупатель попадает на платёжный экран Payora: видит сумму, адрес, QR-код и таймер. Платит из любого кошелька.
• 3. Детект поступления. Шлюз отслеживает адрес счёта и фиксирует входящий перевод, сверяя сумму с ожидаемой и учитывая допустимое отклонение.
• 4. Подтверждение. После нужного числа подтверждений счёт переходит в статус «оплачен».
• 5. Подписанный вебхук. Payora отправляет магазину серверное уведомление со статусом и подписью; магазин проверяет подпись и выполняет своё действие — выдаёт товар, пополняет баланс, открывает доступ.

Важная деталь — идемпотентность и доверие. Магазин никогда не должен полагаться на редирект пользователя «спасибо за оплату»: единственный источник правды о деньгах — это подписанный вебхук от Payora. Поэтому фактическое начисление всегда привязано к проверенному уведомлению, а не к действию в браузере.

Почему это так принципиально? Редирект легко подделать или просто не дождаться: пользователь может закрыть вкладку сразу после отправки средств, потерять сеть или открыть «страницу спасибо» вручную, ничего не заплатив. Если магазин начисляет товар по редиректу, он открыт для злоупотреблений и потерь. Вебхук же приходит сервер-серверно, подписан секретом и отражает реальное состояние счёта — поэтому именно он, и только он, служит командой «выдать». Этот принцип мы выносим в документацию как обязательный, а не рекомендательный.

07Ключевые возможности

Разберём то, что делает Payora не «приёмом крипты», а именно платёжным шлюзом продакшн-уровня.

Единый REST API

Вся интеграция строится вокруг небольшого набора методов: создать счёт, узнать его статус, получить реквизиты. Ответы предсказуемы, ошибки — машиночитаемы. Разработчику не нужно держать в голове особенности конкретной сети — он работает с понятием «счёт», а сетевые детали Payora берёт на себя.

Hosted-checkout

Готовая страница оплаты снимает с магазина целый пласт работы. На ней покупатель видит сумму, адрес, QR-код для кошелька и таймер до истечения счёта. Это и удобнее для пользователя, и безопаснее: реквизиты формирует и показывает сам шлюз, магазин не участвует в отображении адреса.

Подписанные вебхуки

Каждое уведомление о смене статуса счёта подписано секретом мерчанта. Магазин на своей стороне проверяет подпись и только после этого доверяет содержимому. Так подделать «оплачено» нельзя, даже зная адрес обработчика.

Логика сумм и сроков

Курс плавает, пользователи округляют, сети берут комиссию — поэтому шлюз умеет работать с допустимым отклонением суммы, фиксировать частичные оплаты и корректно закрывать счета по истечении срока. Это снимает с магазина самую неприятную ручную работу.

Статусы и жизненный цикл счёта

Счёт в Payora проходит через понятный набор состояний — от «создан» и «ожидает оплату» до «оплачен», «недоплата» или «истёк». Магазину не нужно гадать, что происходит: статус всегда однозначен, а переходы между состояниями детерминированы. Это упрощает и автоматизацию на стороне магазина, и разбор спорных ситуаций в поддержке — по любому счёту видно, на каком он шаге и почему именно в нём оказался.

Идемпотентность и надёжная доставка

Сеть ненадёжна, обработчики падают, ответы теряются — поэтому уведомления устроены так, чтобы повторная доставка не ломала логику магазина. Один и тот же факт оплаты можно безопасно обработать несколько раз и не начислить лишнего. Для денег это принципиально: лучше получить уведомление дважды и корректно его погасить, чем потерять единственное и оставить клиента без товара.

08Безопасность и non-custodial

Главный принцип Payora — не становиться кастодианом. Деньги покупателя идут на адреса, которыми распоряжается сам бизнес, а сервер шлюза в части приёма работает в режиме «только наблюдение»: он умеет вычислять адреса для счетов и отслеживать поступления, но не хранит приватных ключей, которыми можно было бы эти средства потратить.

Это меняет модель угроз в выгодную сторону. Даже в худшем сценарии компрометации сервера у атакующего нет доступа к деньгам — нечего «увести». Подпись вебхуков защищает магазины от поддельных уведомлений, разделение поддоменов ограничивает поверхность атаки, а контур закрыт Cloudflare. Для бизнеса это означает простое: контроль над средствами остаётся у него, а не у внешнего сервиса.

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

09TON и USDT: уникальные адреса

Payora принимает TON и USDT в сети TON — быстрые и дешёвые по комиссии активы, удобные для онлайн-оплат. Но сама по себе поддержка валюты — это лишь половина дела. Вторая, более тонкая половина — как сопоставить конкретный платёж с конкретным счётом.

Мы пошли по пути уникального адреса на каждый счёт: для нового счёта детерминированно выводится отдельный адрес зачисления. Когда на него приходит перевод, шлюз точно знает, к какому заказу он относится — без меморандумов, комментариев к платежу и ручного сопоставления, которые так легко теряются. Деривация адресов реализована так, что серверу для приёма не нужны приватные ключи: он вычисляет адреса и наблюдает за ними, оставаясь read-only.

Детерминированная деривация — это ещё и про восстановимость. Адрес каждого счёта можно вычислить заново из исходных параметров, а значит система не зависит от хрупкого хранилища «адрес ↔ заказ»: связь восстанавливается из самой логики деривации. Для приёма USDT-on-TON и нативного TON это особенно удобно — обе валюты живут в одной сети, что упрощает наблюдение и снижает комиссии относительно более «тяжёлых» цепочек.

10Недоплаты, переплаты и сроки

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

Сложнее обстоит с явными недоплатами и переплатами. Если пришло заметно меньше — счёт получает соответствующий статус, и магазин сам решает, что делать: ждать доплату, вернуть средства или закрыть частично. Если пришло больше — этот факт тоже фиксируется и доводится до магазина, а не «проглатывается» молча. Логика построена так, чтобы ни один реальный перевод не пропал из виду и по каждому было понятное решение.

Отдельная история — сроки. У счёта есть окно жизни, в течение которого его можно оплатить; на checkout это окно видно как таймер. По истечении срока счёт переходит в статус «истёк», и это важно по двум причинам: во-первых, курс к моменту оплаты не «уплывает» далеко от зафиксированного; во-вторых, магазин получает чёткий сигнал, что заказ можно отменять или пересоздавать. Все эти переходы — недоплата, переплата, истечение — отражаются в статусах и в подписанных вебхуках, так что у интегратора всегда есть машиночитаемая картина происходящего.

11Кабинет мерчанта и админка

Чтобы продукт был самостоятельным, мало одного API — нужен интерфейс, где мерчант управляет своими проектами. В административной части (admin.payora.money) бизнес заводит проекты, получает ключи и секрет для подписи вебхуков, настраивает адрес обработчика и валюты, и видит историю счетов с их статусами.

Это закрывает повседневные сценарии без обращения к разработчику шлюза: создать новый проект под новый сайт, перевыпустить ключ, проверить, дошёл ли конкретный платёж, разобрать спорный счёт. По сути, кабинет — это «пульт» над всем тем, что API делает программно.

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

12Интеграции: проверено в бою

Payora не существует в вакууме — он создавался как общий платёжный слой для целой экосистемы проектов. Один из первых реальных интеграторов — фриланс-маркетплейс 24freelance: пополнение баланса пользователя проводится через Payora. Магазин создаёт счёт, пользователь оплачивает на hosted-checkout, а после подтверждения Payora присылает подписанный вебхук, по которому баланс начисляется автоматически.

Эта интеграция — хорошая проверка архитектуры на практике: она показала, что подключить новый проект к шлюзу можно быстро и что выбранная модель (счёт → checkout → подписанный вебхук → начисление) ложится на реальный продукт без костылей. Каждый подключённый сервис заводится как отдельный проект-мерчант со своими ключами, что изолирует их друг от друга.

Главная ценность первой интеграции — она прошла именно по тому пути, который заложен в продукте: никаких обходных решений и «временных» хаков. Пополнение баланса — отличный полигон, потому что здесь критична надёжность начисления: ошибка означала бы либо потерянные деньги пользователя, либо неоправданно выданный баланс. Тот факт, что весь поток отработал на привязке к подписанному вебхуку, подтвердил ключевую гипотезу: один раз развёрнутый шлюз действительно становится общим платёжным слоем, к которому новые проекты подключаются как мерчанты, а не переписываются каждый раз с нуля.

13Технологический стек и инфраструктура

Под Payora мы собрали отдельную, изолированную среду — со своим системным пользователем, поддоменами и политиками. Это и аккуратнее с точки зрения безопасности, и проще в сопровождении.

• Бэкенд — PHP 8.3: API, учёт счетов, формирование и отправка вебхуков, логика статусов.
• Блокчейн-слой — работа с TON и USDT-on-TON: вычисление адресов счетов и наблюдение за поступлениями в read-only режиме.
• Инфраструктура — отдельный изолированный аккаунт с поддоменами api/pay/admin, за Cloudflare (DNS, TLS, защита) и с валидными сертификатами Let's Encrypt.
• Безопасность — разделение ролей по поддоменам, секреты для подписи на стороне мерчанта, отсутствие приватных ключей приёма на сервере.

Выбор PHP 8.3 здесь прагматичен: зрелая, быстрая платформа, на которой удобно держать и API, и серверный рендеринг checkout, и админку в одном предсказуемом окружении. Cloudflare закрывает периметр и берёт на себя TLS-терминацию и базовую защиту, а Let's Encrypt обеспечивает валидные сертификаты на всех поддоменах. Вся среда задумана как self-hosted: владелец разворачивает её на своей инфраструктуре и сохраняет полный контроль — что прямо вытекает из non-custodial природы продукта.

14Дизайн и UX

Финтех-продукт продаёт доверие, поэтому интерфейсы Payora мы делали спокойными и техничными, без визуального шума. Посадочная страница объясняет ценность за несколько секунд: что это, кому, чем отличается (self-hosted, non-custodial) и как начать. Документация и точки входа в кабинет — на расстоянии одного клика.

Отдельное внимание — платёжному экрану. Это момент, где пользователь расстаётся с деньгами, и любая неясность стоит конверсии. Поэтому на hosted-checkout всё сведено к главному: сумма, адрес, QR-код, таймер и понятный статус. Чем меньше на этом экране лишнего, тем выше доходимость оплаты до конца.

UX checkout мы рассматривали как часть инженерной задачи, а не как «оформление». Каждый элемент на экране оплаты решает конкретную проблему доверия: видимый адрес и QR убирают страх «куда платить», таймер снимает неопределённость «сколько у меня времени», а живой статус счёта отвечает на главный вопрос покупателя — «дошли ли мои деньги». В сумме это снижает количество брошенных оплат и обращений в поддержку, что для платёжного продукта так же важно, как и техническая надёжность под капотом.

15Как мы работали

Проект вели последовательными этапами с демонстрацией результата на каждом шаге:

• Исследование. Разобрали сценарии приёма крипты, болевые точки, требования к безопасности и модель «счёт → оплата → уведомление».
• Архитектура. Спроектировали разнесение по поддоменам, формат API, схему статусов счёта и механизм подписи вебхуков.
• Разработка ядра. Собрали API, учёт счетов, деривацию адресов и наблюдение за поступлениями, hosted-checkout и отправку вебхуков.
• Интеграция и обкатка. Подключили первый реальный проект (пополнение баланса 24freelance) и проверили весь поток на практике.
• Запуск и инфраструктура. Развернули среду за Cloudflare с поддоменами и сертификатами, оформили посадочную и документацию.

Такой порядок не случаен: сначала мы фиксировали контракт — формат API, схему статусов и подпись вебхуков, — и только потом строили вокруг него реализацию. Это позволило вести разработку ядра и интеграции почти параллельно: пока собиралась серверная логика, контракт уже был достаточно стабильным, чтобы готовить первого интегратора. Демонстрации на каждом этапе давали возможность раньше увидеть нестыковки и поправить их до того, как они «застынут» в коде.

16Результат

Получился не «скрипт приёма крипты», а самостоятельный платёжный шлюз, который можно развернуть у себя и подключать к любому количеству проектов.

• Приём криптоплатежей подключается за вечер — один запрос на счёт и один обработчик вебхука.
• Бизнес сохраняет полный контроль над средствами: non-custodial и self-hosted.
• Подписанные вебхуки и уникальные адреса убирают целые классы ошибок: подделку уведомлений и потерянные платежи.
• Архитектура проверена реальной интеграцией и готова масштабироваться на новые проекты.

Но главный результат — не в отдельных цифрах, а в смене модели. Раньше каждый новый сайт владельца означал новый платёжный модуль с нуля; теперь это просто ещё один проект-мерчант в общем шлюзе. Платёжная логика перестала быть разовой задачей и стала переиспользуемым активом, который окупается тем сильнее, чем больше проектов к нему подключается.

17Выводы

Payora — пример того, как инженерная аккуратность превращает «модную тему» в рабочий инструмент. Самое ценное здесь не в том, что продукт «принимает крипту», а в том, как он это делает: без кастодиального риска, с доверенными уведомлениями и предсказуемой логикой счетов. Именно эти неброские, но критичные детали отличают платёжный шлюз продакшн-уровня от очередного самописного приёма.

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

И ещё один вывод, скорее методологический. Лучшие финтех-решения почти всегда про то, чего на экране не видно: про модель угроз, про идемпотентность, про то, что считать единственным источником правды о деньгах. Эти решения принимаются один раз, в начале, и потом годами оберегают продукт от целых классов проблем. Именно так мы и подходим к работе — сперва правильные границы и контракты, а уже потом всё остальное.