496 / 691BTCPAY

BTCPay Server

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

オープンな決済ソフトウェアが請求書を作り、ビットコインと Lightning の支払いを追跡して店舗に結び付けます。運営者が導入方式とウォレットを選びます。BTCPay Server を使うだけで安全な自己管理が保証されるわけではありません。

BTCPay Server は MIT ライセンスの自由な決済処理ソフトウェアで、自分のインスタンスでも第三者のホスト経由でも運用できます。プロジェクトが提供するのはソフトウェアであり、共通の預かり口座や店舗との紛争を仲裁するサービスではありません。必要な信頼は、サーバー、ウォレット、決済サービスの実際の接続に依存します。

店舗はレジやネットショップを、請求書と選択した受取方法に接続します。BTCPay Server はオンチェーンの受取アドレスや Lightning の支払い要求を作成し、支払いを監視して請求書一覧を提供します。レジ、寄付のアプリケーションや統合用のインターフェースもあります。公開されたソースコードは検査や変更を可能にしますが、それだけで特定の導入環境の安全性を証明しません。 [BTCPay Server — Source repository]

既存のオンチェーンウォレットは拡張公開鍵で接続できます。サーバーは秘密鍵なしで受取アドレスを導出します。サーバー上に作成したホットウォレットには別のリスクモデルがあります。Lightning ノードの権限も資金操作を許す場合があります。受取、署名、管理の鍵を区別してください。self-hosted という言葉だけでは誰が資金を使えるかは決まりません。 [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]

第三者がサーバーを運用し、利用者は自分のウォレットへ直接受け取ることもできます。それでも信頼は不要になりません。悪意のある、または侵害されたサーバーが公開鍵を差し替え、将来の支払いを別の場所へ送らせる可能性があります。ウォレットで受取済みのコインと、新しく表示される支払い情報は別です。レジとは独立して入金も確認してください。同じ攻撃は侵害された自前のインスタンスにも起こり得ます。ホストは可用性やプライバシーにも影響します。 [BTCPay Server — Third-party hosting risks]

店舗は通貨、レートの取得元、有効期限、必要な承認を設定します。オンチェーン支払いの Processing は設定条件を待ち、Settled は条件の充足を示します。成功した Lightning 支払いはブロックを待つ必要がありません。不足、過払い、遅延入金、手動の状態変更も扱ってください。手動変更はネットワーク承認を作りません。価格のビットコイン換算は法定通貨への売却とは異なり、換金プラグインや事業者は固有の手数料と信頼要件を加えます。 [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]

ネットショップは注文と請求書 ID の対応を保存します。Greenfield API は店舗単位で権限を制限できます。鍵に必要以上のアクセスを与えないでください。文書に従って webhook を検証し、繰り返されたイベントで二度目の発送が起きないよう処理します。顧客がお礼ページに戻るだけでは支払いの証明になりません。障害後はローカルの記録を請求書と支払いの実際の状態に照合してください。 [BTCPay Server — eCommerce integration]

自分のノードには可用性、チャネル管理、受取側の流動性が必要です。流動性サービス、swap、カストディ型ウォレットは異なる部分を解決し、同じモデルではありません。カストディサービスでは事業者が資金を管理します。他の方式でも具体的な権限とリスクを確認する必要があります。BTCPay Server のロゴは、すべての支払いの成功や手数料ゼロを保証しません。 [BTCPay Server — Lightning options]

導入方式に応じ、店舗データ、請求書、設定、必要なウォレットデータをバックアップしてください。シードは注文データベースを置き換えません。Docker の文書はバックアップの復元を検証するよう求めています。Lightning チャネルの古い状態を誤って復元すると資金を失う可能性があります。元のノードを正常停止して行う計画的移行は災害復旧とは異なります。代替側を開始した後に同じノードの元のコピーを起動しないでください。使用中のバックエンドに合った手順が必要です。 [BTCPay Server — Backup and restore]

更新、管理者アクセスの保護、ネットワークへの公開範囲、稼働監視、検証済みバックアップを計画してください。ソフトウェアが各支払いから割合手数料を取らなくても、ホスティング、機器、ネットワーク手数料、流動性、支援には費用がかかり得ます。保存する顧客情報を減らしてください。返金や配送紛争を扱うのは店舗であり開発者ではありません。請求書の書き出しであらゆる会計義務が満たされるとは限りません。 [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]

例 · BTCPAY

レジの停止は受取済みコインの喪失ではない

仮想的な店舗で、サーバーが知るのは外部ウォレットの公開データだけです。ホスティングが停止しても、受取済みのオンチェーンコインはその鍵で管理され続けますが、レジは新しい請求書の作成や支払い通知ができないかもしれません。運営者はサービスを復旧し、受取設定を確認して注文とウォレットを照合します。この例は失われたサーバー上のホットウォレットや古い Lightning チャネル状態には当てはまりません。

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

01BTCPay Server は自動的に自己管理になりますか?

いいえ。接続するウォレット、Lightning サービス、実際の権限によります。公開鍵だけで外部ウォレットに受け取る方式と、他人のサーバー上のホットウォレットやカストディ型バックエンドは異なります。表示される支払い情報が正しいことも信頼する必要があります。

02復旧にはシードのバックアップだけで足りますか?

シードは対応するオンチェーンウォレットを復元できる場合がありますが、請求書、店舗設定、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文書 ↗
一次資料を優先 · 投資助言ではありません