496 / 736BTCPAY

BTCPay Server

支払いを受け取るための自前の基盤

小さなオンラインショップでビットコインを受け取り、どの注文が支払済みかを把握したいとします。BTCPay Server は顧客向けの支払いページを作り、店側の入金確認を助けます。支出に使う鍵を渡さずに、自分のウォレットと連携させることもできます。ただし、実際の仕組みは設定とサーバー管理者によって変わります。

BTCPay Server は、MIT ライセンスで公開されているビットコイン決済用の自由なソフトウェアです。自分のサーバーで動かすことも、他者の環境を利用することもできます。支払い要求を作成し、入金を照合して記録を助けます。プロジェクト自体は資金を預ける口座でも、商品の紛争を裁く仲介者でもありません。

オンライン書店を考えてみましょう。顧客がビットコインを選ぶと、BTCPay Server は invoice、つまり一定額の支払い要求を作ります。支払いページには、店舗の設定に応じてアドレスや Lightning の支払い要求が表示されます。ソフトウェアは入金を監視し、連携先のショップへ状態の変化を通知します。店員が一件ずつ支払いを注文に結び付ける必要が減ります。店頭レジや寄付の受付にも利用できます。公開されたソースコードは検査や改変が可能ですが、それだけで個々の設置環境の安全性が証明されるわけではありません。 [1]

既存のウォレットなら、受取アドレスを導く情報である拡張公開鍵をサーバーへ渡す方法があります。送金を認可する秘密鍵は、ハードウェアウォレットなどサーバーの外に置いたままにできます。ホットウォレットでは事情が異なり、秘密情報がインターネット接続端末に保存されます。高速決済を扱う Lightning ノードへのアクセスも、支出を可能にする場合があります。サーバーを運営することと資金を管理することは、別々に確認すべき問題です。self-hosted、すなわち自前運用という名称だけでは判断できません。 [2] [3]

他者のサーバーを使えば、設置や保守の負担を減らせます。しかし自分のウォレットへ直接受け取る場合も、サーバー管理者に依存します。改変や侵入を受けたサーバーが、自分の代わりに攻撃者のアドレスを表示する可能性があるからです。公開鍵を入手しただけでは過去の入金を支出できませんが、改ざんされたレジは今後の支払いを別の宛先へ誘導できます。独立したウォレットでも入金を確認しましょう。自前サーバーが侵害された場合も同じ危険があり、外部ホストは可用性や支払いのプライバシーにも影響します。 [4]

本の価格はチェコ・コルナで表示し、顧客はビットコインで払うことができます。Invoice は一定時間、レートと支払額を固定します。Processing は全額が支払われたものの、ブロック承認などの決済条件がまだ満たされていない状態です。Settled は条件が満たされた状態で、Lightning 決済は通常ブロックを待ちません。不足、過払い、期限後の入金も店舗で扱う必要があります。状態を手動で変えてもネットワークの承認は生まれません。また、画面上の価格換算だけで銀行口座にコルナが振り込まれるわけではなく、プラグインや事業者による両替には別の条件と費用があります。 [5] [6] [3]

プログラム同士は、通信の窓口である Greenfield API で連携します。ショップは invoice の識別子を注文と一緒に保存します。状態変更は webhook というサーバーからの自動メッセージで知らされ、その真正性を文書に従って確認します。API のアクセスキーには、対象店舗に必要な権限だけを与えます。同じ通知が再び届いても、二冊目を発送してはいけません。顧客が購入お礼ページに戻ったことも支払いの証拠にはなりません。障害後には、手元の記録を invoice の状態や実際の入金と照合します。 [7]

Lightning Network は支払いチャネルを使い、一件ごとの決済を別々にブロックへ記録せずに支払える仕組みです。自分のノードには可用性とインバウンド流動性、つまり資金を自分の側へ受け入れられるチャネルの余地が必要で、継続的な管理を伴います。流動性の支援、支払いネットワーク間の交換、事業者が顧客資金を管理するカストディサービスなどを使う選択肢もあります。ただし権限、手数料、リスクは異なります。支払いページの BTCPay Server という名前だけでは店舗の選択は分からず、すべての支払いの成功も保証されません。 [8]

ウォレットの復元情報は、店舗全体のバックアップではありません。鍵に加え、請求記録、設定、構成に応じた他のデータも必要です。Lightning では、古いチャネル状態でノードを起動することが特に危険で、誤った復元は資金を損なうおそれがあります。計画的なサーバー移行と、障害後の復旧は別の手順です。移行中に元のノードの状態を変え続けたり、復元したコピーと同時に動かしたりしてはいけません。使用する実装の手順に従ってください。Lightning の復元テストはネットワークや相手ノードから隔離し、稼働中のチャネルに影響を与えないようにします。 Docker はアプリケーションの構成要素を別々のコンテナで動かす環境であり、そのガイドはこの設置方式を対象としています。 [9]

利点は、自分の決済基盤について判断できることです。一方で、更新、管理者アクセス、インターネットに公開するサービス、復元できるバックアップには担当者が必要です。ソフトウェアは決済ごとの割合手数料を取りませんが、ホスティング、機器、ネットワーク手数料、Lightning の支援には費用がかかることがあります。不要な顧客の個人情報は保存しないようにします。本の紛失や返品があれば、苦情や返金を扱うのは販売者であり、BTCPay Server の開発者が売買を裁くわけではありません。請求記録は帳簿を助けますが、すべての会計上の義務に代わるものではありません。 [10] [3] [7]

例 · BTCPAY

レジは止まってもウォレットは残る

外部ウォレットの公開情報だけを使う店舗で、サーバーが応答しなくなったとします。その鍵で管理している受取済みのビットコインが消えるわけではありません。ただし顧客が新しい支払いページを開けず、店側も注文の最新状態を確認できないことがあります。復旧後、受取設定を確認し、請求記録とウォレットを照合します。この例は、サーバー上のホットウォレットとともに秘密鍵を失った場合や、古いデータから Lightning チャネルを復元する場合には、そのまま当てはまりません。

理解を深めるには、この項目とあわせて次もお読みください Bitcoin Payment Processor, Bitcoin Point of Sale, セルフカストディ, Lightning Network, Merchant Adoption, Bitcoin. 次の項目からも参照されています Bitcoin Coffee, Transaction Labeling, Bitcoin Payment Processor, Bitcoin Point of Sale.

01BTCPay Server を使えば必ず自己管理になりますか?

いいえ。接続したウォレットの鍵を誰が管理し、サーバーや Lightning サービスがどの権限を持つかを確認します。外部ウォレットの公開情報だけでは支出できませんが、ホットウォレットやカストディサービスは別の構成になり得ます。秘密鍵がなくても、侵害されたレジは誤ったアドレスを表示できます。

02ウォレットのバックアップ単語だけですべて戻せますか?

対応する Bitcoin ウォレットは復元できる場合がありますが、請求一覧や店舗設定、Lightning チャネル状態まで自動で戻るわけではありません。それぞれにバックアップと手順が必要です。安全に試験し、古い Lightning のテスト用コピーを現用ノードのようにネットワークと通信させてはいけません。

DOC · 001BTCPay Server — Source repository一次資料 DOC · 002BTCPay Server — Wallet setup文書 DOC · 003BTCPay Server — General FAQ文書 DOC · 004BTCPay Server — Third-party hosting risks文書 DOC · 005BTCPay Server — Invoice lifecycle文書 DOC · 006BTCPay Server — Store rates and policies文書 DOC · 007BTCPay Server — eCommerce integration文書 DOC · 008BTCPay Server — Lightning options文書 DOC · 009BTCPay Server — Backup and restore文書 DOC · 010BTCPay Server — Maintenance文書
改訂日: 一次資料を優先 · 投資助言ではありません