Как создать встроенный планировщик выплат по подписке в криптокошельке

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

Что вообще такое планировщик выплат по подписке

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

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

Три подхода к реализации

1. Через смарт-контракт (on-chain)

Вы деплоите смарт-контракт, который содержит логику подписки. Держатель контракта (подписчик) даёт разрешение на трату средств, а контракт сам списывает токены по расписанию.

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

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

Пример архитектуры: контракт подписчика хранит адрес получателя, сумму, интервал и дату следующего платежа. Keeper-бот (или сервис вроде Chainlink Automation) вызывает функцию executePayment(), контракт проверяет, прошёл ли нужный интервал, и переводит токены.

2. Через бэкенд-сервис (off-chain планировщик)

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

Плюсы: гибкость, легко менять параметры, можно добавить уведомления, не нужно платить за газ на каждую подписку с контракта.

Минусы: приватный ключ хранится на сервере — это единая точка отказа. Если сервер взломают, злоумышленник получит доступ ко всем средствам. Нужно следить за аптаймом сервера.

3. Через десктопное или мобильное приложение кошелька

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

Плюсы: приватный ключ не покидает устройство, не нужен внешний сервер, пользовательский опыт похож на привычные банковские автоплатежи.

Минусы: устройство должно быть онлайн в момент платежа (для мобильных — обычно не проблема, для десктопных — уже сложнее), нужно аккуратно реализовать фоновый процесс.

Сравнение подходов

Параметр	Смарт-контракт	Бэкенд-сервис	Встроенный в кошелёк
Контроль над ключами	Полный (ваш ключ или разрешение контракта)	Ключ на сервере — риск	Полный (ключ на устройстве)
Гибкость настроек	Низкая (нужен деплой новой версии)	Высокая	Высокая
Зависимость от третьей стороны	Минимальная (только keeper)	Высокая (ваш сервер)	Минимальная
Стоимость для пользователя	Газ за каждый платёж + деплой	Затраты на хостинг сервера	Бесплатно (встроено)
Сложность реализации	Высокая	Средняя	Средняя-высокая
Надёжность	Зависит от keeper-сети	Зависит от аптайма сервера	Зависит от устройства пользователя

Как реализовать встроенный планировщик в кошельке: пошагово

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

1. Определите модель данных для подписки. Каждая подписка должна хранить: адрес получателя, сумму, адрес токена (или нативная монета), интервал в секундах/блоках, дату следующего платежа, статус (активна/приостановлена/отменена), лимит платежей (если есть).
2. Создайте UI для управления подписками. Пользователь должен видеть список активных подписок, уметь ставить на паузу, менять сумму, отменять. Интерфейс должен показывать историю исполненных платежей и дату следующего.
3. Реализуйте локальное хранилище расписаний. Используйте базу данных устройства (SQLite, Realm, и т.п.) для хранения подписок. Шифруйте чувствительные данные — хотя бы адрес получателя и сумму, если для вас важна приватность.
4. Настройте фоновый процесс. На iOS — Background Tasks (BGTaskScheduler), на Android — WorkManager. Задача проверяет, есть ли подписки с истёкшим сроком, и инициирует транзакцию. Важно: ОС может убить фоновый процесс, поэтому нужен fallback — проверка при следующем запуске приложения.
5. Подписывайте транзакцию на устройстве. Когда пришло время платежа, приложение формирует транзакцию (адрес отправителя, получатель, сумма, данные для transfer/transferFrom), подписывает приватным ключом и отправляет в сеть через RPC-ноду или API провайдера.
6. Обрабатывайте ошибки. Недостаточно газа — уведомите пользователя. Транзакция зафейлилась — попробуйте повторить с увеличенным gas price. Подписка просрочена — решите, пропускать ли платёж или наверстывать.
7. Добавьте уведомления. Push-уведомление перед списанием (за день/час), после успешного платежа, при ошибке. Это то, что отличает нормальный продукт от сырого прототипа.

Что выбрать в зависимости от ситуации

Если вы делаете продукт для обычных пользователей — встроенный планировщик в кошелёк. Люди привыкли к автоплатежам в банках и ожидают того же от крипты. Не нужно объяснять про газ, keeper-сети и смарт-контракты.

Если вы делаете продукт для продвинутых пользователей/DeFi — смарт-контракт с возможностью управления подписками через интерфейс. Это даёт прозрачность и некастодiability, но требует больше разработки.

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

Частые ошибки

• Не учитывают разницу во времени блоков. В сетях с нестабильным временем блоков (Ethereum в периоды загруженности, сайдчейны) ориентироваться на точное время ненадёжно. Лучше использовать номер блока как ориентир или допускать окно в несколько минут.
• Хранят приватный ключ в открытом виде на сервере. Это грубейшая ошибка. Если уж храните на сервере — используйте HSM, KMS или хотя бы шифрование с ключом, который не хранится рядом.
• Не обрабатывают реборны и форки. Транзакция может быть откачена при реборне. Планировщик должен проверять финальность и не считать платёж исполненным до достаточного количества подтверждений.
• Забывают про газовые лимиты. Если сумма подписки сопоставима с комиссией за транзакцию, пользователь теряет деньги. Нужно либо предупреждать, либо накапливать платежи и отправлять пакетом.
• Нет возможности отмены. Пользователь должен иметь возможность отменить подписку в любой момент. Если отмена требует отправки отдельной ончейн-транзакции (для контрактного подхода) — это нужно честно показать в UI.
• Не ведут историю платежей. Без истории пользователь не понимает, что произошло с его деньгами. Это базовое требование к любому финансовому продукту.

Практические рекомендации

Начните с простого расписания. Не пытайтесь сразу поддерживать cron-выражения. Еженедельные и ежемесячные платежи покрывают 90% сценариев.

Используйте отдельный адрес для подписок. Это позволяет изолировать средства, выделенные на автоплатежи, от основных накоплений. Если планировщик сломается или утечёт — потеря будет ограничена.

Дайте пользователю контроль над газом. Позвольте выбрать приоритет транзакции или установить максимальную комиссию. Никто не хочет платить 15 за перевод20.

Логируйте всё. Каждое исполнение подписки, каждая ошибка, каждый запрос на отмену — должно логироваться. Это нужно и для отладки, и для поддержки пользователей.

Тестируйте на тестовых сетях. Обязательно. Особенно — сценарии с реборнами, падением цены газа, временным отсутствием интернета на устройстве.

Предусмотрите graceful degradation. Если фоновый процесс не сработал (ОС убила задачу, устройство было выключено), приложение должно догнать пропущенные платежи при следующем запуске — либо честно сообщить, что платёж пропущен.

Итог

Встроенный планировщик выплат по подписке — это не космическая ракета, но и не тривиальная задача. Главное решение — где хранить логику расписания и ключи. Для большинства криптокошельков оптимальный путь — локальный планировщик на устройстве пользователя с фоновыми задачами, шифрованным хранилищем и понятным UI для управления подписками.

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

Ключевой критерий хорошего планировщика — пользователь должен понимать, что происходит с его деньгами, и иметь возможность это контролировать в любой момент.

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