Bitcoin Payment Processor

顧客がネットショップで本を注文するとします。店はプロセッサーに invoice、つまり金額と通貨を指定した支払い要求を作ってもらい、その識別子を注文番号とともに保存します。顧客は支払いページを開くか QR コードを読み取って支払います。保存した対応関係から、店はどの購入に対する入金かを判断できます。これがなければ、どこかにビットコインが届いたという情報だけでは不十分です。「ご注文ありがとうございます」のページに戻ることも、店が支払いを受け取った証拠にはなりません。 [1]

BTCPay Server は既存ウォレットの公開データから受取アドレスを生成でき、支出に必要な秘密鍵を受け取る必要はありません。これは鍵をサーバーに置くホットウォレットや、高速な支払いを扱う Lightning ノードの資金にアクセスする構成とは異なります。サービスでは事業者が払い出しまで資金を管理する場合もあります。したがって、鍵を事業者に預けないという non-custodial の表示だけでは判断できません。実際の権限、誰が送金できるか、資金を受け取るのに他者の承認が必要かを確認します。 [2] [6]

本の価格は通常の通貨で表示され、顧客はビットコインで払うかもしれません。BTCPay Server は支払い要求の金額と換算レートを一定時間固定します。期限切れは後からの送金を止める仕組みではないため、店には適切な処理が必要です。不足や過払いにも対応します。元の金額とレートは照合用に残します。本の価格が変わらなくても、別のレートで新しい要求を作ると、ビットコインの最小単位である satoshi の必要数は変わり得ます。 [3]

BTCPay Server の Processing は要求額が支払われたものの、ブロック内での取引承認など完了条件がまだ満たされていない状態です。Settled は条件が満たされた状態で、Lightning 支払いは通常ブロック承認を待ちません。他社サービスは独自に状態を定義します。BitPay は paid が支払い保証ではないと明示しています。発送の基準は選んだサービスの文書と支払い方法に合わせる必要があります。注文を手動で支払い済みにしても、実際の入金確認の代わりにはなりません。 [3] [5]

プロセッサーは webhook、つまりサーバー間の自動メッセージで状態の変化を知らせます。店は送信元と内容を検証します。BTCPay では元のメッセージのバイト列と共有シークレットから HMAC-SHA256 を計算します。これは認証コードであり、Bitcoin ネットワークの承認ではありません。BitPay は IPN 通知に署名しないため、それをきっかけに API で実際の状態を問い合わせます。API はプログラム同士の通信窓口です。通知は再び届く場合があるので、店は処理済みの注文を記録し、二重発送を防ぎます。障害後は保存した状態をプロセッサーと照合します。 [4] [5]

顧客の支払いを受けることと、サービスから払い出しを受けることは別の出来事です。BitPay では対応する精算通貨と銀行口座または暗号資産アドレスを設定でき、変更に承認が必要な場合があります。店は時期、限度額、手数料、払い出し前の資金管理者も確認します。自分のウォレットへ直接受け取る場合、この中間段階がないこともあります。販売システムは両者を区別し、「支払い済み」が資金をすでに使えるという誤解につながらないようにします。 [6] [2]

返金しても元の Bitcoin 取引は消えません。店は顧客の申請を処理し、金額と通貨を決め、受取人を確認して新たな支払いを行います。返金を請求するリンクだけでは、資金が送られたことにはなりません。注文、支払い要求、入金、レート、手数料、返金の記録を残します。書き出したレポートは会計を助けますが、地域のあらゆる義務をそれだけで満たすわけではありません。ネットワーク承認も配送の争いを決着させたり、苦情対応に関する契約上・法律上の義務をなくしたりはしません。 [7] [8] [10]

公開前に一度買い物が成功しただけでは不十分です。不足払い、遅延払い、重複通知、障害からの復旧も試します。API キーはプログラムのアクセス資格情報なので、対象店舗に必要な権限だけを付与します。付随情報に不要な顧客データを含めません。自前運用にはホスティング、更新、サポートが必要です。Lightning では、支払いに使う資金とチャネル内の空き容量という流動性の管理も加わります。無料ソフトウェアでも運用は無料とは限りません。可用性、鍵の保護、店舗との正しい連携は別々に確認します。 [1] [9]