495 / 736PAY·PROC

Bitcoin Payment Processor

Процесор біткоїн-платежів

Клієнт платить біткоїном, але магазин має ще визначити, яке замовлення оплачено, чи правильна сума і коли можна відправляти товар. Bitcoin Payment Processor поєднує ці кроки. Під цією назвою може бути власна програма або сервіс, виплати від якого продавець мусить чекати.

Bitcoin Payment Processor — програма або сервіс, що створює платіжні запити, відстежує надходження й пов’язує їх із замовленнями. Він допомагає виконувати продажі та зберігати записи. Він не встановлює правил мережі Bitcoin і не обов’язково зберігає кошти клієнтів: контроль ключів і порядок виплат залежать від конкретної схеми.

Уявімо покупця, який замовляє книжку онлайн. Магазин просить процесор створити invoice — платіжний запит із сумою та валютою — і зберігає його ідентифікатор поруч із номером замовлення. Покупець відкриває платіжну сторінку або сканує QR-код і платить. Збережений зв’язок дозволяє визначити, за яку покупку надійшли гроші. Без нього самого факту надходження біткоїна кудись недостатньо. Повернення на сторінку «Дякуємо за замовлення» також не доводить, що магазин отримав оплату. [1]

BTCPay Server може створювати адреси отримання з відкритих даних наявного гаманця, не отримуючи приватних ключів для витрачання. Це інша схема, ніж гарячий гаманець із ключами на сервері або доступ до коштів вузла Lightning, який обслуговує швидкі платежі. У сервісі провайдер може контролювати кошти до виплати. Тому самого напису non-custodial, тобто без передачі ключів провайдеру, замало. Перевіряйте реальні дозволи, хто може переказати гроші й чи потрібна чужа згода, щоб їх отримати. [2] [6]

Ціну книжки можуть вказати у звичайній валюті, хоча покупець надсилає біткоїн. BTCPay Server фіксує суму й курс у платіжному запиті на обмежений час. Сплив строку не перешкоджає надходженню пізнішого переказу: магазин має правильно його опрацювати. Те саме стосується недоплат і переплат. Початкова сума та курс залишаються в обліку для звіряння. Новий запит за іншого курсу може вимагати іншу кількість сатоші, найменших одиниць біткоїна, навіть якщо ціна книжки не змінилася. [3]

У BTCPay Server Processing означає, що запитану суму сплачено, але умови завершення ще не виконані, наприклад бракує підтверджень транзакції в блоках. Settled означає їх виконання; платежі Lightning зазвичай не чекають блокових підтверджень. Інші сервіси визначають власні стани. BitPay прямо попереджає, що paid не є гарантією оплати. Правило відправлення має відповідати документації обраного сервісу та способу платежу. Ручна позначка «оплачено» не замінює перевірки реального надходження. [3] [5]

Процесор повідомляє про зміни через webhook — автоматичне повідомлення між серверами. Магазин перевіряє його походження та вміст. У BTCPay HMAC-SHA256 обчислюють із початкових байтів повідомлення та спільного секрету: це код автентифікації, а не підтвердження мережі Bitcoin. BitPay не підписує сповіщення IPN; воно має лише запустити перевірку справжнього стану через API, інтерфейс взаємодії програм. Повідомлення може надійти повторно. Магазин фіксує виконання замовлення, щоб не відправити його знову. Після збою звіряє збережені стани з процесором. [4] [5]

Отримання платежу клієнта й виплата від сервісу — різні події. BitPay дозволяє вибрати підтримувану валюту розрахунку та банківський рахунок або криптовалютну адресу; зміни можуть потребувати схвалення. Продавець перевіряє також строки, ліміти, комісії та контроль коштів до виплати. За прямого надходження у власний гаманець цього проміжного кроку може не бути. Система продажів має розрізняти ці схеми, щоб «оплачено» не створювало хибного уявлення про вже доступні гроші. [6] [2]

Повернення грошей не стирає початкову транзакцію Bitcoin. Магазин спершу розглядає запит, визначає суму й валюту, перевіряє одержувача та організовує новий платіж. Посилання для запиту повернення ще не означає, що кошти надіслано. В обліку залишаються замовлення, платіжний запит, надходження, курс, комісії та повернення. Експортовані звіти допомагають бухгалтеру, але самі не виконують усіх місцевих вимог. Підтвердження мережі також не вирішує спір про доставку й не скасовує договірних або законних обов’язків щодо претензії. [7] [8] [10]

Однієї вдалої тестової покупки перед запуском недостатньо. Перевіряють недоплату, запізнілий платіж, повторні сповіщення та відновлення після збою. API-ключ — це облікові дані доступу програми: йому надають тільки необхідні дозволи для відповідного магазину. Додаткові відомості не повинні містити зайвих персональних даних. Власна експлуатація потребує хостингу, оновлень і підтримки; Lightning також потребує керування ліквідністю, тобто коштами та доступною місткістю каналів для платежів. Безплатна програма не робить експлуатацію безплатною. Доступність, захист ключів і правильне підключення магазину перевіряють окремо. [1] [9]

Приклад · PAY·PROC

Оплачена книжка й повторне повідомлення

Магазин пов’язує платіжний запит із замовленням OBJ-101. Після перевірки платежу й виконання умов відправлення він надсилає книжку та фіксує виконання. Згодом те саме сповіщення надходить знову. Система розпізнає виконане замовлення й не створює ще одну посилку. Самого відкриття сторінки подяки для відправлення було б недостатньо.

Для повної картини прочитайте також BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. На цю статтю також посилаються Оплата біткоїном в Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.

01Чи потрібно довіряти біткоїн процесору?

Не завжди. Програма може відстежувати надходження у ваш гаманець без ключів для витрачання. Гарячий гаманець на сервері, доступ до вузла Lightning або сервіс із подальшою виплатою мають інші умови. Оцінюйте реальний контроль грошей і дозволи, а не лише позначку non-custodial.

02Чи можна відправляти товар після повернення покупця в магазин?

Ні. Повернення в браузері — лише дія на сторінці. Магазину потрібен перевірений стан конкретного платежу та правило виконання замовлення для цього способу оплати. Повторні повідомлення про той самий платіж теж не повинні спричиняти повторні відправлення.

DOC · 001BTCPay Server — eCommerce integrationДокументація DOC · 002BTCPay Server — General FAQДокументація DOC · 003BTCPay Server — Invoice lifecycleДокументація DOC · 004BTCPay Server — Webhook validation exampleДокументація DOC · 005BitPay — Invoice webhooksДокументація DOC · 006BitPay — Configuring settlementsДокументація DOC · 007BTCPay Server — RefundsДокументація DOC · 008BTCPay Server — ReportingДокументація DOC · 009BTCPay Server — Lightning operationsДокументація DOC · 010BitPay — Merchant and shopper termsПервинне джерело
Переглянуто: Спочатку джерела · Не інвестиційна порада