05.05.2025
Криптоплатежи или банковские переводы: что выбрать бизнесу?
Читать статью
Пользователь входит в приложение по email — и сразу видит адрес, баланс и кнопку отправки. Устанавливать расширение не пришлось, seed phrase никто не показывал. Значит ли это, что кошелёк принадлежит пользователю и только он распоряжается деньгами? Не обязательно.
«Встроенный» описывает интерфейс: кошелёк находится внутри сайта или приложения. Но контроль зависит от другой части системы — от того, кто может авторизовать подписание транзакции, как устроено восстановление и можно ли перенести доступ к активам.
Поэтому встроенный кошелёк стоит оценивать не как одну функцию, а как набор отдельных решений: вход, создание аккаунта, ключи, подписание, восстановление, экспорт, комиссии и связь с бизнес-логикой продукта.
Встроенный криптокошелёк — это кошелёк внутри приложения, маркетплейса, игры, финтех-сервиса или другой цифровой платформы. Пользователь не переключается в отдельное расширение, чтобы посмотреть баланс или подтвердить операцию: основные действия происходят в интерфейсе самого продукта.
В документации также встречаются выражения in-app wallet и Wallet-as-a-Service, или WaaS. Первое подчёркивает пользовательский сценарий. Второе чаще описывает инфраструктуру для разработчиков: SDK и API, через которые приложение создаёт адреса, запрашивает подпись, читает баланс и получает статус транзакции.
Ни одно из этих названий само по себе не означает «некастодиальный». Кошелёк может быть под контролем пользователя, под контролем платформы или работать по схеме, где для операции нужны несколько участников и заданные правила.
На экране всё выглядит единым продуктом, но под интерфейсом работает несколько слоёв:
Приложение может полностью управлять внешним видом кошелька, но не иметь права единолично подписывать транзакцию. Возможна и обратная модель: пользователь видит баланс в своём профиле, а операции авторизует сервер платформы.
Именно поэтому вопрос «у нас встроенный кошелёк или нет?» почти ничего не говорит о рисках. Гораздо полезнее спросить: кто и при каких условиях способен вывести активы?
Технические реализации различаются, но базовый путь обычно состоит из одних и тех же этапов.
Сначала сервис проверяет, кто запрашивает доступ. Это может быть код из email, вход через социальный аккаунт, PIN-код, биометрия или ключ доступа (passkey).
Такой вход ещё не равен подписи в блокчейне. Он может только открывать сессию, запускать запрос на подпись или давать одну часть данных, необходимых распределённой системе.
Новому пользователю система создаёт блокчейн-аккаунт и связывает его с профилем. При следующем входе нужно вернуть доступ к тому же адресу.
На демонстрации это выглядит просто. В рабочем продукте появляются сложные случаи: новый телефон, другой браузер, утраченный email, заблокированный социальный аккаунт, смена поставщика кошелька. Команда должна заранее знать, какой фактор возвращает доступ, а какой только подтверждает вход.
Приложение формирует перевод, оплату, вызов контракта или разрешение на расходование токенов. До подтверждения человеку важно показать:
Если вместо этих данных интерфейс показывает только кнопку «Подтвердить», удобство на входе превращается в риск в момент подписания.
Авторизация отвечает на вопрос, кто имеет право одобрить действие. Подпись создаёт криптографическое подтверждение для блокчейна. В разных моделях это делает пользователь, сервер приложения, несколько участников или смарт-аккаунт с программируемыми правилами.
Актуальная документация Circle о подписании, например, отдельно описывает инициирование, авторизацию, формирование подписи и отправку в сеть. Такое разделение полезно при анализе любой архитектуры, а не только одного продукта.
После подписания транзакция попадает в сеть. Это ещё не означает, что операция стала окончательной. Она может оставаться в ожидании, завершиться ошибкой, быть заменена или откатиться при выполнении смарт-контракта.
Для оплаты особенно опасно путать красивую галочку в кошельке с финальным статусом заказа. Сервер должен дождаться заранее определённого состояния и сопоставить транзакцию с нужным счётом.
Различие между моделями видно не в дизайне экрана, а в полномочиях на подпись.
В этой схеме без подтверждения пользователя транзакция не должна быть подписана. Человек может входить привычным способом, но решение о переводе остаётся за ним.
Это похоже на самостоятельное хранение, однако одного ярлыка недостаточно. Нужно выяснить, участвует ли поставщик в подписании, кто меняет факторы восстановления, доступен ли экспорт и что произойдёт при потере всех устройств.
Фраза «пользователь контролирует кошелёк» должна описывать реальные полномочия. Наличие личного кабинета и имени владельца ещё ничего не доказывает.
В управляемой платформой схеме сервер может создавать и подписывать операции через свои учётные данные и политики. Такой подход применяют для автоматических выплат, сбора депозитов, сервисных аккаунтов и внутренних операций.
За удобством стоит большая ответственность. Платформе нужны разделение ролей, лимиты, журналы действий, защита серверных секретов, процедура восстановления и план на случай компрометации. Отдельно проверяются юридические и комплаенс-требования конкретной модели.
Слово «встроенный» не делает такой кошелёк некастодиальным. Оно говорит лишь о том, где пользователь видит функцию.
Некоторые решения распределяют подпись между несколькими участниками или пропускают операцию через набор правил. Система может требовать подтверждение пользователя и участие инфраструктуры, ограничивать сумму, разрешать только определённые адреса или блокировать необычную частоту переводов.
Это снижает часть рисков, но создаёт зависимости. Нужно перечислить всех, без кого нельзя подписать транзакцию, восстановить доступ, изменить политику или перенести аккаунт.
В описаниях встроенных кошельков часто встречаются многосторонние вычисления (MPC), ключи доступа и абстракция аккаунта. Эти технологии относятся к разным уровням.
MPC-схема позволяет нескольким сторонам совместно сформировать подпись, не собирая полный приватный ключ в одном месте. Но реальная защита зависит от порога, мест хранения долей, операторов узлов, правил входа и восстановления.
Ключ доступа — это криптографическая учётная запись, обычно защищённая устройством или менеджером учётных данных. Он может заменить пароль в знакомом пользовательском сценарии. При этом команде всё равно нужно решить, что происходит при потере устройства, синхронизации через облако и восстановлении аккаунта.
Смарт-аккаунт — блокчейн-аккаунт на смарт-контракте. Он может объединять действия, разрешать оплату комиссии другой стороной, применять лимиты, менять подписантов и подключать модули восстановления. Подробнее этот слой разобран в статье про абстракцию аккаунта и смарт-кошельки.
Встроенный кошелёк может использовать одну из этих технологий, несколько сразу или обычный аккаунт с приватным ключом. Поэтому слово «seedless» или обещание входа по email не заменяет описание архитектуры.
Создать кошелёк за несколько секунд несложно. Сохранить предсказуемый доступ при сбое — гораздо труднее.
До запуска стоит разыграть реальные сценарии:
Экспорт приватного ключа может дать путь в другой кошелёк, но одновременно создаёт момент раскрытия критически важного секрета. Кроме того, экспорт бывает доступен не на всех платформах и не для всех способов создания аккаунта. Например, Privy отдельно описывает условия экспорта для клиентских и серверных кошельков.
Переносимость не всегда требует показа приватного ключа. В смарт-аккаунте можно сменить владельца или подписанта. В другой архитектуре миграция проходит через процедуру восстановления. В любом случае обещание «доступ всегда можно вернуть» должно превращаться в конкретную, проверяемую последовательность действий.
Внешний кошелёк — отдельное приложение или расширение, которое пользователь подключает к сервису. Платформа запрашивает действие, а подпись происходит в кошельке. Так работает и подключение через WalletConnect.
Встроенный вариант удобен новичку: не нужно заранее выбирать кошелёк, переключаться между приложениями и разбираться, почему окно подписи выглядит иначе. Команда контролирует весь путь и может объяснять операции в контексте своего продукта.
Внешний кошелёк удобен опытному пользователю: у него уже есть адрес и активы, а один и тот же инструмент работает с разными сервисами. При этом платформа хуже контролирует интерфейс подтверждения и должна поддерживать больше сочетаний кошельков, устройств и сетей.
Часто разумно оставить оба пути. Новичок получает встроенный кошелёк, а опытный пользователь подключает свой. Тогда заранее определяют правила объединения профилей, отображения нескольких балансов, отключения адреса и восстановления доступа без появления дубликатов.
Встроенный кошелёк сокращает путь до оплаты: пользователь уже авторизован, нужная сеть известна, а окно подтверждения открывается внутри продукта. Это полезно в играх, маркетплейсах, сервисах для авторов и финтех-приложениях.
Но кошелёк и платёжная система решают разные задачи.
Кошелёк хранит активы и подписывает действие. Для полноценной оплаты бизнесу дополнительно нужны:
Эти задачи не исчезают после подписи в одно касание. Практическая сторона разобрана в чек-листе API для криптоплатежей и материале о том, как снизить число неуспешных платежей.
CryptumPay — криптовалютная платёжная система для бизнеса с интеграцией через API и HTML-виджет. Её можно рассматривать, когда приложению нужно связать криптоинвойс и статус транзакции с заказом, балансом, доступом или другим бизнес-событием. Называть CryptumPay встроенным кошельком без отдельного подтверждения такой функции не следует.
Безопасность лучше обсуждать через конкретные угрозы, а не через обещание «bank-grade». Поставщику и собственной команде стоит задать вопросы:
Привычный вход не защищает от фишинга и вредоносных разрешений. Более того, интерфейс знакомого приложения может создать ложное ощущение безопасности. Пользователь должен понимать, какие права получает контракт и как проверить и отозвать разрешения токенов.
Если система разрешает экспорт приватного ключа, нужен понятный инструктаж: любой, кто получит ключ, сможет распоряжаться аккаунтом. Основные правила остаются теми же, что и для seed phrase и private key, даже если при первом входе человек их не видел.
Начинать лучше не со списка технологий, а с действий пользователя и бизнеса.
Для каждого типа операции зафиксируйте, кто её одобряет: пользователь, сервер, несколько сотрудников или программируемая политика. Не смешивайте потребительский баланс, автоматический сервисный кошелёк и казначейство компании.
Проверьте потерю телефона, email и социального аккаунта, компрометацию сессии, сбой поставщика и перенос к другому решению. Отдельно задайте полномочия службы поддержки.
Уточните, создаётся обычный аккаунт с ключом или смарт-аккаунт. Проверьте рабочие сети, токены, вызовы контрактов, комиссии и одинаковость адресов. Поддержка тестовой сети не доказывает поддержку основной.
Узнайте, можно ли экспортировать приватный ключ, сменить владельца смарт-аккаунта, добавить подписанта или перейти к другому поставщику. Ограничения должны быть понятны пользователю до пополнения.
Показывайте действие, адрес, сеть, актив, сумму, комиссию и запрашиваемые разрешения. Если в одну транзакцию объединены несколько операций, они тоже должны быть видны.
Нужны лимиты, журналы, уведомления, защита webhook, идемпотентность запросов, обработка повторов и сценарий инцидента. Тестируйте не только успешную операцию, но и долгий pending, отклонение и ошибку после подписи.
Решите, должен ли пользователь постоянно хранить средства, иногда платить, получать выплаты или только закрывать конкретный инвойс. Ради простой оплаты не всегда нужен полноценный встроенный кошелёк. И наоборот, платёжный виджет не заменяет долгосрочный пользовательский аккаунт.
В мобильном приложении добавляются deep links, возврат из другого окна, состояние сессии и системные экраны подтверждения. Эти вопросы подробнее разобраны в гайде о криптоплатежах в мобильных приложениях.
Встроенный криптокошелёк способен сделать блокчейн незаметной частью привычного приложения. Но удобный вход не должен скрывать систему контроля.
Ключевые вопросы остаются практическими: кто авторизует перевод, как формируется подпись, что видит пользователь, как вернуть доступ, можно ли перенести аккаунт и какой статус получает операция после отправки в сеть.
Если человеку нужен постоянный баланс и регулярные действия внутри продукта, встроенный кошелёк может стать подходящей основой. Если бизнесу важнее принять оплату и обновить заказ, достаточно платёжной интеграции — например, CryptumPay. Иногда продукту нужны оба слоя, но их полномочия, сбои и восстановление должны проверяться независимо.
Create an account and connect the checkout yourself, or talk to sales and we will plan the integration with you.
Напишите нам в Telegram, и мы спланируем интеграцию
