ОБНОВЛЯТЬ.
Платежный шлюз Zaopensource: github.com/Overtorment/Cashier-BTC По разным причинам существующие платежные шлюзы (например, Bitpay) могут вам не подойти.
В этой статье мы рассмотрим создание собственного биткойн-шлюза с нуля.
Предполагается, что читатель знаком с сетью Биткойн.
Если нет, то рекомендую эти статьи: «Как на самом деле работает протокол Биткойн» И «Биткойн: введение для разработчиков» Условно я бы разделил предлагаемую нами систему на 4 части:
Работа с адресами .Генерация пары открытого и закрытого ключей (как известно, хеш открытого ключа — это биткойн-адрес, а соответствующий закрытый ключ позволяет ими управлять) Получение информации из сети Bitcoin .
Статус транзакции, баланс адреса.
Создание и подписание транзакций .
Формирование корректной транзакции, подписание ключом/ключами, конвертация в hex. Полученный шестнадцатеричный код готов к трансляции в сеть.
Трансляционные транзакции .
То есть транслировать, отправлять, нажимать.
Передача шестнадцатеричной транзакции в сеть Биткойн, чтобы майнеры могли начать работу по включению транзакции в блокчейн.
Для выполнения этих операций нам потребуется подобрать набор программных решений, которые упростят нам жизнь.
Наиболее популярные и используемые решения могут выполнять все или почти все вышеперечисленные операции, но ничто не мешает нам объединить решения или даже написать собственный велосипед для определенных этапов.
Работа с адресами
В общем, с этим справится любая криптографическая библиотека, поддерживающая эллиптическую криптографию.
Подойдут и обычные биткойн-библиотеки для работы с биткойнами: pybitcointools (Виталик Бутерин) - питон
Биткор (Битпей) — Javascript
БиткойнJS - яваскрипт
БиткойнJ -Джава
другой
Получение информации из сети Bitcoin
Самый «тяжелый» пункт. Классическое решение — создать собственный эталонный полный узел Bitcoin, также известный как канонический bitcoind. Это позволит нам общаться с ним через JSON-RPC. С его помощью мы сможем как получать информацию из сети, так и отправлять транзакции.На что следует обратить внимание: После установки синхронизация узлов может занять длительное время.
Только после синхронизации узел можно будет использовать.
Это займет много места.
Я лично не знаю, какую нагрузку запросов он выдержит. Любые проблемы со сбоем/обновлением лягут на ваши плечи.
Альтернативой является реализация полного узла на Ruby+PostgreSQL. Тоши .
Неканоническая, но стремящаяся к полной реализации совместимости.
Обратите внимание, из-за дополнительных индексов база данных будет занимать 220+ гигабайт места.
Опять же необходима синхронизация с сетью.
Могут быть и другие реализации полного узла (мне неизвестные).
Другая альтернатива — использование публичного API провайдера.
Получение информации из сети и трансляция операций ляжет на его плечи.
На данный момент существуют: Chain.com блокчейн.
info/ru/api (не рекомендуется) www.blockcypher.com цепочка.
so/api
Coinalytics.co
www.blocktrail.com
coinkite.com/developers
другой
Лично я рекомендую соединить несколько решений с Fallover.
Создание и подписание транзакций
В зависимости от того, какую основную библиотеку мы выбрали, эта библиотека может или не может создавать и подписывать транзакции.Вы можете написать это сами.
См.
раздел «Работа с адресами».
Трансляционные транзакции
Результатом создания и подписания транзакций являются двоичные данные (шестнадцатеричные), готовые к отправке в сеть.Пока сеть не увидит транзакцию, считайте, что транзакции нет. Когда сеть видит транзакцию, она считается неподтвержденной.
Транзакции достаточно для передачи Биткойна на один узел, после чего через считанные секунды транзакцию увидит большая часть сети Биткойн.
Некоторые клиентские узлы из раздела «Работа с адресами» (через какие-то свои жестко запрограммированные конечные точки) или любой полный узел могут транслировать транзакции.
Вы даже можете транслировать транзакцию вручную, перейдя на специальную страницу Bitcoin API провайдера и введя транзакцию в специальную форму.
Канонически подтвержденная транзакция — это транзакция, включенная в 6 и более последовательных блоков (или 1-3. Неканонические, но более быстрые).
Транзакции с нулевой (или недостаточной) комиссией могут оставаться неподтвержденными долгое время (по моему опыту, до месяца).
Целесообразно периодически повторять такие транзакции.
Общие принципы работы платежного шлюза
Опция 1
Предположим, у нас есть уникальный счет (инвойс, заказ), предъявленный клиенту к оплате, и клиент будет платить в биткойнах.Начнем с конвертации исходной валюты счета (например, долларов США) в BTC. Это тривиальная задача и мы ее рассматривать не будем.
Дальше.
Стандартом де-факто является генерация нового уникального биткойн-адреса для каждого заказа (он же счет-фактура, он же счет-фактура, он же заказ).
Ожидается, что только наш клиент переведет средства на этот счет, только 1 раз и только строго определенную сумму (можно больше, никто не обидится, но и не меньше).
Что.
Когда средства поступают на указанный Bitcoin-адрес в необходимом количестве, заказ считается оплаченным.
Вкратце цепочка такая: заказать в системе -> сгенерировать уникальный биткойн-адрес, соответствующий заказу -> покажи это клиенту -> Ждём оплату по адресу -> ордер закрыт (отмена по истечении срока действия или получении BTC и засчет факта оплаты) Когда биткойны поступают на адрес, у вас есть возможность пополнить неподтвержденный или подтвержденный баланс.
Существует небольшая вероятность того, что транзакция будет откатана, причем это может быть как по вине плательщика (который на самом деле является злоумышленником), так и по независящим от него обстоятельствам.
Если у вас есть возможность «отобрать» предоставленный товар или услугу у клиента в случае отмены транзакции, рекомендую зачесть неподтвержденный баланс.
Это будет означать для клиента практически мгновенный процесс оплаты (в отличие, например, от часа ожидания).
А если какие-то транзакции в итоге обнаружатся отозванными, потребовать от клиента повторного платежа, угрожая забрать услугу/товар.
Не ждите, что такое мошенничество сразу же массово настигнет вас; откаты транзакций происходят очень редко, и «вручную» стимулировать такой откат (для чего, кстати, у злоумышленника нет гарантии успеха) для технически неподкованных клиентов (в отличие от чарджбэков по кредитным картам) нереально.
Еще один пример, когда может быть засчитан неподтвержденный остаток, — это если подготовка заказа клиента занимает более одного часа (например, корзина клиента находится в обработке и готовится к отправке курьерской службой).
Есть много времени, чтобы перепроверить баланс перед отправкой товара.
Для других случаев вы можете ввести определенный порог, выше которого вы должны ожидать подтвержденного баланса (например, 0,25 BTC).
Для максимальной надежности сделайте его нулевым.
После закрытия заказа вы можете оставить биткойны на этом адресе до тех пор, пока они не потребуются, либо для удобства перевести их на единый «агрегационный» кошелек торговца.
Будьте осторожны, в последнем случае вы можете скомпрометировать такой коммерческий показатель, как «оборот», т.к.
платежную операцию может отследить каждый платящий клиент. Для переводов вам необходимо будет создавать, подписывать и транслировать транзакции, используя приватные ключи адресов.
Несколько слов о сроке действия заказа.
Если ваш продукт или услуга строго привязаны к эквиваленту в фиатной валюте (например, доллару США), то типичный срок действия заказа составляет 7–15 минут из-за волатильности обменного курса.
Вариант 2
Подходит, когда вы не выставляете счета на оплату, а на счете пользователя имеется некий единый баланс, который он пополняет и с которого тратит. Здесь вам нужно будет сгенерировать биткойн-адрес для пользователя и показать его ему, попросив пополнить счет на любую сумму.В этом случае необходимо следить за адресом на предмет входящих транзакций и пополнять внутренний баланс пользователя при его наличии.
В этом случае я рекомендую считать только подтвержденные транзакции (от 3-х блоков и выше).
генерация адреса для пользователя ->
мониторинг транзакций по адресу ->
пополнение внутреннего счета при наличии входящих транзакций
Несколько слов о безопасности
В случае взлома злоумышленника будет интересовать только одно — приватные ключи от сгенерированных вами адресов, поскольку они позволяют переводить средства с этих адресов куда угодно.Я рекомендую хранить их изолированно от основной системы в каком-нибудь безопасном хранилище.
В конечном счете, они понадобятся вам только тогда, когда вы захотите использовать доходы от биткойнов (потратить их, конвертировать в наличные и т. д.).
Что дальше?
При необходимости выручка может быть автоматически переведена на биржу и продана с помощью API биржи.Для этого нам нужно будет создавать, подписывать и транслировать транзакции, используя приватные ключи адресов.
На этом все, надеюсь, будет полезно тем, у кого подобная задача.
Исправления неточностей и ошибок приветствуются в личку.
Теги: #bitcoin #Криптография #платежные системы
-
Основные Заблуждения О Scrum
19 Oct, 24 -
Немного Истории: Кто Такой Аноним
19 Oct, 24 -
«Опиум» Для Народа – Новый Им
19 Oct, 24 -
Что Заменит Телевидение?
19 Oct, 24 -
История В Картах
19 Oct, 24
