Bitcoin и Lightning на сайте: итоговый платёжный маршрут
Оглавление курса «Bitcoin и Lightning: платежи на сайте» · Урок 30 из 30.
В этом курсе мы построили две линии оплаты учебной библиотеки: обычное поступление Bitcoin и расчёт через Lightning. Теперь соберём их в один проектный договор. Результатом будет последовательный маршрут курса 17 от создания заказа до права доступа, с явными источниками, состояниями восстановления и границами учебного кода.
Все главы подготовлены локально как черновики. Кошельки, узлы, счета, платежи, тесты и серверные программы не запускались. Поэтому итог не утверждает готовность коммерческого платёжного сервиса. Он даёт самостоятельную программу реализации и ожидаемых проверок, которую можно позднее выполнить в отдельной изолированной лаборатории после соответствующего решения.
Заказ находится в приложении
Обе ветки начинаются с серверного заказа на курс 17. Цена зафиксирована: 30 000 сатоши, или 30 000 000 миллисатоши в общей внутренней форме. У заказа есть получатель права, валюта, выбранный метод и версия предметной политики. Клиентское поле amount не заменяет эту запись.
Платёжный инструмент связан с заказом через instrumentId. Для обычной ветки сервер сохраняет назначение адреса и наблюдение подходящих выходов; для Lightning — payment hash и профиль invoice. Равная сумма не является достаточной связью. Несколько читателей могут одновременно купить один курс, поэтому совпадение цены не объясняет получателя доступа.
Создание инструмента и чтение его результата — разные действия. Подготовка может иметь неизвестный результат и требует своего восстановления. Повтор статуса не должен автоматически выпускать новый адрес или invoice. Пока судьба прежней попытки не ясна, приложение сохраняет её идентификаторы и не прячет неопределённость за новой кнопкой оплаты.
Две политики подтверждения
Учебная onchain-v1 требует двух подтверждений для подходящего поступления. Это правило нашей лаборатории, а не универсальная гарантия финальности и не рекомендация для любой стоимости заказа. Наблюдение содержит источник, срез цепочки и связь денежных выходов с назначением.
Учебная lightning-v1 требует достоверного SETTLED нужного invoice и суммы не меньше цены. OPEN и ACCEPTED не выдают доступ. Для этой ветки не вводим фиктивные два Bitcoin-подтверждения. Переплата записывается отдельно, а позднее наблюдение обрабатывается согласно политике заказа и достоверному времени источника.
Обе ветки сохраняют неизвестный результат. Недоступный RPC не означает, что обычная транзакция отсутствует. Недоступный узел Lightning не означает, что invoice отменён. Последнее достоверное состояние остаётся с указанием свежести, а новый ответ обновляет только ту область, которую действительно наблюдает.
Паспорт приложения
Запишем собственную конфигурационную форму. Она содержит договоры и не включает рабочие credentials. Реальные профили и endpoints добавляются при отдельной реализации, где выбираются совместимые версии и изолированная среда.
PAYMENT_PROJECT = {
'course_id': 17,
'expected_sats': 30_000,
'expected_msat': 30_000_000,
'network': 'regtest',
'backend_reference': 'Python 3.12 standard library',
'bitcoin_core_reference': '31.0',
'onchain_policy': {
'id': 'onchain-v1',
'confirmations_required': 2,
},
'lightning_policy': {
'id': 'lightning-v1',
'required_invoice_state': 'SETTLED',
'source_profile': None,
'node_version': None,
'adapter_implementation': None,
},
'execution': 'not_run',
}Bitcoin Core 31.0 здесь является закреплённым справочным профилем первой линии, а не заявлением о запущенном экземпляре. Lightning-узел и SDK намеренно не выдуманы: статьи 19–30 описывают архитектуру через первичные BOLT/LND и собственные Python-модели. Пустой source_profile не следует заменять произвольным публичным сервисом ради включения кнопки.
Современная обработка Bitcoin URI также требует своей совместимой спецификации. Исторический BIP 21 заменён BIP 321; будущая интеграция выбирает поддержку кошельков явно. Пример не предлагает объединить два способа в один QR без отдельного договора инструментов и проверки двойного поступления.
Хранилище решений
В базе находятся заказы, инструменты, наблюдения, принятые решения, права и outbox. Денежное свидетельство и выдача права сохраняются атомарно. Повтор события возвращает уже существующую предметную связь. Внешнее письмо имеет собственную доставку, поэтому его отказ не отменяет оплаченный доступ.
Если заказ имеет несколько инструментов, право всё равно создаётся один раз по договору заказа. Второе поступление не исчезает: оно фиксируется как отдельный денежный факт и направляется в выбранную политику разбора. Нельзя обещать автоматический возврат, пока не спроектирован и не разрешён соответствующий процесс.
Идемпотентность должна обеспечиваться фактическим хранилищем. Слово once в учебном интерфейсе не заменяет уникальных ограничений и транзакции. Несколько работников могут получить одно уведомление, но один заказ не превращается в несколько прав только из-за параллельных callbacks.
Восстановление и источники
Для on-chain линии сохраняем назначения и контрольные точки, для Lightning — связь invoice и независимые индексы наблюдения. Поток ускоряет обновление, сверка восстанавливает пропущенные факты. Неизвестная область остаётся видимой, а курсор не продвигается через необработанные данные ради видимости свежего сервиса.
Резервирование узла не совпадает с копией приложения. Восстановление Lightning по предусмотренному механизму имеет свои границы; старый channel.db нельзя использовать как обычный безвредный снимок активного канала. Документация закреплённой версии и операторский договор определяют путь возврата. Сайт затем отдельно сверяет назначения и права.
Доступ и публичная библиотека
Статус заказа защищается серверной сессией либо ограниченным разрешением. Backend-секреты узла не попадают в браузер, source control и статическую сборку. Чтение статуса не закрывает каналы, не создаёт возвраты и не выдаёт новые invoice. Каждая административная операция имеет отдельные полномочия.
Старые публичные уроки ProfessorWeb остаются обычными доступными страницами. Учебный платёжный пример относится к отдельному предметному праву и не закрывает весь каталог. Если продукт действительно защищает ресурс, это обеспечивает серверная выдача, а не скрытие кнопки в HTML. Такой договор сохраняет расширяемость сайта и его существующие URL.
Ожидаемая приёмка
Читатель создаёт заказ, видит точную цену и выбранный инструмент, затем получает ясный статус. Обычная ветка ждёт своей политики подтверждений. Lightning ждёт settlement. Повтор уведомления не создаёт второе право. Потеря ответа вызывает наблюдение исходной задачи. Отказ email не удаляет доступ, а смена профиля не переименовывает старые инструменты задним числом.
Разработчик получает модели, источники и перечень ещё не реализованных адаптеров. При будущем запуске каждое ожидаемое свойство проверяется на выбранном профиле и получает фактический результат. До этого метаданные честно сохраняют example_execution: not_run. Мы закончили последовательный учебный маршрут двух платёжных способов, не скрывая границы доверия и восстановления.