Пишемо власний платіжний шлюз Bitcoin

З різних причин існуючі платіжні шлюзи (такі як Bitpay) вас можуть не влаштовувати. У цій статті ми розглянемо створення власного Bitcoin шлюзу з нуля.

Передбачається, що читач знайомий з пристроєм мережі біткоїн. Якщо ні, то рекомендую ці статті: "Як насправді працює протокол Біткоін" і "Біткойн: введення для розробників" Умовно, нашу передбачувану систему я б розділив на 4 частини:

Загалом з цим може впоратися будь-яка криптографічна бібліотека, що підтримує еліптичну криптографію.

Ще підійдуть звичайні біткоїни бібліотеки для роботи з Bitcoin:

  • pybitcointools (Vitalik Buterin) - python
  • Bitcore (Bitpay) — javascript
  • BitcoinJS - javascript
  • BitcoinJ - java
  • інші

Отримання інформації з біткоїн мережі

Найважливіший пункт. Класичним рішенням є підняття власного еталонного повного вузла Біткоін, він же - канонічний bitcoind. Це дозволить нам спілкуватися з ним по JSON-RPC. З ним ми зможемо як отримувати інформацію з мережі, так і витрачати транзакції. На що варто звернути увагу:

  • Після встановлення синхронізація вузла може тривати тривалий час. Тільки після синхронізації вузол можна використовувати.
  • Займе чимало місця. Вже 40 гігабайт.
  • Мені особисто невідомо, яке навантаження за запитами зможе витримати.
  • Будь-які проблеми з падінням/оновленням ляжуть на ваші плечі.
Альтернатива - імплементація повного вузла на Ruby + PostgreSQL, Toshi. Неканонічна, але прагне до повної сумісності реалізація. Зверніть увагу, через додаткові індекси, база даних займе 220+ гігабайт місця. Знову ж таки, потрібна синхронізація з мережею. Можливо, є інші імплементації повного вузла.невідомі).Ще одна альтернатива- використання публічного API провайдера. На його плечі ляже отримання інформації з мережі та трансляція транзакцій.

Особисто я рекомендую підключити кілька рішень із фейловером.

Створення та підпис транзакцій

Трансляція транзакцій

Загальні принципи роботи платіжного шлюзу

Коротко, ланцюжок такий:

Якщо ви маєте можливість “відібрати” наданий товар чи послугу у клієнта у разі виявленого факту скасування транзакції, я рекомендую зараховувати непідтверджений баланс. Це означатиме майже миттєвий процес оплати для клієнта (на противагу годині очікування, наприклад). А якщо якісь транзакції виявляться відкаченими в результаті, запитати клієнта про повторний платіж, погрожуючи відібрати послугу/товар.

Не чекайте що подібний фрод вас тут же масово наздожене, відкат транзакцій це дуже велика рідкість, а "вручну" стимулювати подібний відкат (на який, до речі, у зловмисника немає жодних гарантій успіху) технічно непідкованим клієнтам нереально (на противагу чарджбекам за кредитними картками).

Ще один приклад коли можна зараховувати непідтверджений баланс — якщо на підготовку замовлення клієнта йде більше однієї години (наприклад, обробляється кошик покупця, готується до відправки кур'єрською службою). Тут купа часу перевіряти ще раз баланс перед самою відправкою товарів.

Для інших випадків можна ввести якийсь поріг, вище якого обов'язково очікувати на підтверджений баланс (наприклад 0.25 BTC). Для максимальної надійності зробити його нульовим.

Кілька слів про час життя ордера.Якщо ваш товар або послуга жорстко прив'язані до еквіваленту у фіатній валюті (наприклад, USD), то типовий термін життя ордера становить 7-15 хвилин через волатильність курсу.

Декілька слів про безпеку

Що далі?

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

Хардкорна конфа за С++. Ми запрошуємо лише профі.