Разработка платежного шлюза на Lightning Network под ключ

Разрабатываем платёжные шлюзы на Lightning Network для приёма микроплатежей в Bitcoin. Это принципиально другая модель расчётов: off-chain каналы с on-chain settlement. Перед тем как строить шлюз, нужно понять, что Lightning — это сеть ликвидности, и управление этой ликвидностью — основная операцион

Направления блокчейн-разработки

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1450
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1004
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1270
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1011

Разрабатываем платёжные шлюзы на Lightning Network для приёма микроплатежей в Bitcoin. Это принципиально другая модель расчётов: off-chain каналы с on-chain settlement. Перед тем как строить шлюз, нужно понять, что Lightning — это сеть ликвидности, и управление этой ликвидностью — основная операционная задача, которой нет в аналогах на базе L1. Неправильный менеджмент каналов приводит к потере до 30% платежей из-за фейлов по пути. Мы, команда блокчейн-инженеров с 5+ годами опыта и 30+ проектами за плечами, строим production-ready решения под ключ: оценим ликвидность, настроим автоматическую ребалансировку и интегрируем с вашим backend.

Получите консультацию на старте — мы поможем избежать типичных ошибок.

Архитектура Lightning: что нужно знать инженеру

Платёж по Lightning Network проходит не напрямую от sender к receiver, а по пути через промежуточные узлы. Узел А → Узел Б → Узел В → Узел Г: каждый промежуточный узел пересылает HTLCs (Hash Time-Locked Contract). Если на каком-то хопе не хватает ликвидности в нужном направлении — платёж фейлится и нужно пробовать другой path.

Для шлюза это означает: inbound ликвидность — критический ресурс. Чтобы принимать Lightning платежи, ваш узел должен иметь inbound capacity от хорошо подключённых узлов сети.

Выбор node implementation

LND vs CLN vs Eclair: мы рекомендуем LND для веб-шлюзов — его API в 2 раза богаче, документации на 40% больше. LND (Go) имеет стабильный gRPC/REST API и лучшую экосистему инструментов.

Параметр LND CLN Eclair
API gRPC+REST JSON-RPC REST (Phoenix)
Документация Отличная Хорошая Средняя
Инструменты Loop, Pool plugins Встроенный wallet

Какие инструменты нужны для разработки платежного шлюза на Lightning Network?

Для быстрого старта потребуется: Bitcoin full node (синхронизация ~600GB NVMe), LND поверх bitcoind, минимальный капитал 0.1–0.5 BTC для открытия каналов, и сервер с постоянным storage. Мы используем Go для core-логики и Python для скриптов ребалансировки.

Настройка LND ноды

Установка и конфигурация:

lnd --bitcoin.active --bitcoin.mainnet --bitcoin.node=bitcoind \ --bitcoind.rpchost=localhost --bitcoind.rpcuser=rpcuser --bitcoind.rpcpass=rpcpassword \ --bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 --bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 \ --rpclisten=0.0.0.0:10009 --tlsextraip=YOUR_SERVER_IP --alias="YourGateway" --color=#FF6B35 

Для API взаимодействия — lnd-grpc клиент. Сертификат и macaroon (credential файл) обязательны для каждого запроса.

Создание инвойса и ожидание оплаты

package lightning import ( "context" "encoding/hex" lnrpc "github.com/lightningnetwork/lnd/lnrpc" "google.golang.org/grpc" ) type LNDClient struct { conn *grpc.ClientConn client lnrpc.LightningClient } func (c *LNDClient) CreateInvoice(ctx context.Context, amountSats int64, memo string, expirySeconds int64) (*Invoice, error) { req := &lnrpc.Invoice{Value: amountSats, Memo: memo, Expiry: expirySeconds} resp, err := c.client.AddInvoice(ctx, req) if err != nil { return nil, err } return &Invoice{ PaymentRequest: resp.PaymentRequest, PaymentHash: hex.EncodeToString(resp.RHash), ExpiresAt: time.Now().Add(time.Duration(expirySeconds) * time.Second), }, nil } func (c *LNDClient) WatchInvoices(ctx context.Context, handler func(*lnrpc.Invoice)) error { stream, err := c.client.SubscribeInvoices(ctx, &lnrpc.InvoiceSubscription{}) if err != nil { return err } for { invoice, err := stream.Recv() if err != nil { return err } if invoice.State == lnrpc.Invoice_SETTLED { handler(invoice) } } } 

Как управлять ликвидностью в Lightning Network?

Главная операционная задача для production шлюза. Канал имеет capacity (общий размер) и balance (распределение между сторонами). При приёме платежей balance смещается в вашу сторону — inbound capacity расходуется. При отправке — наоборот.

Loop: submarine swaps

Lightning Loop (Lightning Labs) позволяет перебалансировать канал через submarine swap — атомарный обмен между on-chain BTC и off-chain Lightning sat без закрытия канала:

  • Loop Out: переводим Lightning sat → on-chain BTC. Восстанавливает inbound capacity.
  • Loop In: переводим on-chain BTC → Lightning sat. Восстанавливает outbound capacity.
# Восстановить 500k sat inbound capacity через Loop Out loop out --amt 500000 --channel YOUR_CHANNEL_ID 

Стоимость: 0.1–0.3% + on-chain fee (примерно $1-2 при текущих комиссиях). Для шлюза с постоянным inflow — автоматический Loop Out при достижении порога (outbound balance > 80% capacity). Это экономит до 2% от суммы платежа — для шлюза с оборотом 10 BTC/мес это около $500 в месяц.

Pool: аренда ликвидности

Lightning Pool — маркетплейс для аренды inbound ликвидности. Продавцы открывают каналы к вашему узлу за комиссию. Срок аренды: 2016 блоков (~2 недели). Альтернатива самостоятельному менеджменту каналов для старта.

Автоматическая ребалансировка

async def auto_rebalance(lnd_client: LNDClient): channels = await lnd_client.list_channels() for channel in channels: balance_ratio = channel.local_balance / channel.capacity if balance_ratio > 0.85: amount = int((balance_ratio - 0.5) * channel.capacity) await loop_out(amount, channel.chan_id) elif balance_ratio < 0.15: amount = int((0.5 - balance_ratio) * channel.capacity) await rebalance_circular(amount, channel.chan_id, lnd_client) 

Почему BOLT-12 лучше BOLT-11 для recurring payments?

BOLT-11 — одноразовый инвойс. BOLT-12 Offers — многоразовый переиспользуемый payment код. Клиент запрашивает актуальный инвойс у получателя через onion-сообщение, получает BOLT-11 (или BOLT-12 invoice), платит. Работает для подписок, tips, recurring payments. LND поддерживает BOLT-12 начиная с версии 0.17.

Безопасность

Watchtower: если ваш узел offline, бывший контрагент может попытаться транслировать старое состояние канала (breach attempt). Watchtower-сервис мониторит блокчейн и публикует penalty транзакцию. LND имеет встроенный watchtower client и server.

# Подключение к публичному watchtower lncli wtclient add [email protected]:9911 

Channel backup: SCBs (Static Channel Backups) позволяют восстановить средства из каналов при потере node state. Автоматически создаются LND, нужно хранить в безопасном месте.

Macaroon ограничения: для API доступа приложения выпускаем ограниченные macaroon — только права на создание инвойсов без права инициировать платежи:

lncli bakemacaroon invoices:write invoices:read 

Интеграция с backend

Метод Endpoint Описание
POST /api/invoices создать инвойс
GET /api/invoices/:hash статус инвойса
WS /api/invoices/stream real-time события оплаты

Webhook при оплате — та же схема что для on-chain платёжного шлюза (HMAC-SHA256 подпись). Fiat конвертация: при создании инвойса принимаем fiat сумму, конвертируем в satoshi по текущему курсу (Kraken/Coinbase API), фиксируем курс на время жизни инвойса.

Что входит в разработку

  • Документация по интеграции REST API и webhook
  • Доступ к дашборду управления ликвидностью
  • Обучение команды (2 часа)
  • Поддержка в течение 2 недель после запуска
  • Исходный код и конфигурация

Инфраструктура

  • Dedicated server или VPS (не контейнер без persistent storage)
  • Bitcoin full node (потребляет ~600GB NVMe)
  • LND поверх bitcoind
  • Minimum initial capital для открытия каналов: 0.1–0.5 BTC для малого шлюза

Разработка базового Lightning платёжного шлюза с созданием инвойсов, мониторингом оплат и автоматическим Loop Out — 6–8 недель. С полным ликвидити-менеджментом, BOLT-12 поддержкой и admin дашбордом — 3–4 месяца. Свяжитесь с нами, чтобы оценить ваш проект.