トランザクションの検出、チェーンの確認、注文との関連付け、サービスの提供は別々のステップです。正しいチェーン、資産、受取人、金額を確認し、文書化された受入ポリシーを適用し、照合を冪等にします。トランザクション参照、スクリーンショット、ブラウザのボタンだけでは、特定の注文が支払われたことを証明できません。
チェーンイベントと注文イベントを分離する
ウォレットが送金済みと報告することは、そのウォレット自身の操作に関する証拠であり、完全な支払い判断ではありません。受信側のバックエンドは、意図されたネットワークを観測し、実際の送金を検証し、それを注文に関連付ける必要があります。その後になって初めて、注文は受入ポリシーを適用できます。インフラストラクチャの提供は、支払いの受入後の別の運用ステップです。
これらの状態遷移を、コードと顧客向けの文言の両方で明示してください。画面は、注文を支払い済みとすることなく、待機中、検出済み、確認中を表示できます。ブラウザに受入金額を指定させたり、権威あるステータスを上書きさせたりしないでください。サーバーが作成した見積もりとその指示を保存し、後からの照合を、変化するカートではなく元の注文に対して評価できるようにします。
チェーン固有の信頼ルールを使用する
ネットワークによって、トランザクションの信頼性の表現方法は異なります。Bitcoin の開発者ガイドでは、ノードがどのようにして最も多くの累積作業証明を持つチェーンを選択するか、また競合するブロックがどのように発生し得るかを説明しています。したがって、最近見られたトランザクションには、確認の深さと起こり得るチェーン変更に関するポリシーが必要です。すべての資産と商業リスクに適した単一の確認数は存在しません。
Ethereum のプルーフ・オブ・ステークに関するドキュメントはチェックポイントのファイナリティを説明し、Solana は processed、confirmed、finalized というコミットメント状態を文書化しています。これらの用語を安易に単一の普遍的なブロック数に置き換えないでください。ネットワーク固有のルール、情報源、不確実な状況での挙動を記録します。オペレーターは、無関係なチェックアウトから数値をコピーするのではなく、支払いと提供のリスクに照らして受入しきい値を決定すべきです。
実際の送金ペイロードを検証する
正しいチェーン上で受取人、資産、金額を特定します。トークン支払いでは、アドレスへのトランザクション成功だけでなく、意図されたトークンの同一性が必要です。チェーンのモデルに従って、関連する実行成功と送金の証拠を検証します。ブラウザから提供された整形済みの小数を信用せず、資産の適切な精度で整数の金額を解析します。
支払い指示は、元のルートに結び付けられたままでなければなりません。別のネットワークでの送金、同じシンボルを持つ別のトークン、無関係なトランザクション参照では、それを満たすべきではありません。検証記録には、何を確認したかを説明し、判断を見直すために必要な証拠を保存します。このガイドは、特定のサービス実装ではなく、一般的な支払い照合の原則を説明しています。
注文の関連付けを曖昧さなくする
固定の受取アドレスは、類似した金額の複数の注文を受け取る可能性があります。一致する送金の存在は、どの顧客または注文にクレジットすべきかを証明しません。実際の支払いを受け入れる前に、関連付け方法を定義し、衝突の処理を含めます。ユーザーが提供したトランザクション参照であっても、同じ送金がすでに他の場所に割り当てられていないことの検証が必要です。
同じルート上で同じ金額の2つの請求書が、重複する期間に存在するとします。ウォッチャーは1件の送金を確認します。両方を自動的に支払い済みとすることは誤りであり、十分な証拠なしに一方を選ぶことも安全ではありません。オペレーターのポリシーが有効な関連付けを確立できるまで、送金を未割り当てまたはレビュー中に保ちます。曖昧な一致は、対処すべき状態であり、確実性を捏造する理由ではありません。
遅延および変化する証拠を許容する状態を定義する
支払いプロセスには、少数の明確な状態があり、チェーンの証拠を注文を受け入れる判断から分離することが有益です。この例示的な表は、特定のサービスのステータス名を説明するものではなく、考えられる段階を説明しています。各遷移には検証済みの理由があるべきであり、支払いの受入はインフラストラクチャの提供とは別のままであるべきです。
遅延、一部、超過の送金、見積もりの期限切れ、一時的に利用できないチェーンデータを含めます。期限切れは、実際の送金を消滅させません。遅延した支払いは、自動的な受入または拒否ではなく、レビューを必要とする場合があります。以前に観測されたチェーンイベントが変化した場合は、すべてのウォッチャー通知を不可逆的な真実として扱うのではなく、文書化されたポリシーの下で状態を再評価します。
| 例示的な状態 | 意味 | 次の判断 |
|---|---|---|
| 待機中 | 検証済みの適格な送金なし | 有効な請求書の観測を継続 |
| 検出済み | 関連する送金を観測 | チェーンの信頼性と関連付けを確認 |
| 確認中 | 受入ルールがまだ満たされていない | ポリシーが判断を許可するまで観測 |
| レビュー | 遅延、一部、または曖昧な証拠 | オペレーターのポリシーの下で解決 |
| 受入済み | 検証および照合済みの支払い | 別の提供ワークフローへ進む |
再試行を安全かつ観察可能にする
ウォッチャーと照合ジョブは、接続の中断やプロセスの再起動後に再試行します。チェーンと適切なトランザクションまたは送金識別子など、安定した送金IDを使用して、重複クレジットを防ぎます。進捗と判断を永続化し、同じイベントを再度処理しても、2つ目のサービスをプロビジョニングしたり、受け入れ済みの見積もりを変更したりしないようにします。
不明な結果と失敗した操作を区別します。下流のリクエストがタイムアウトした場合は、再送信する前にその権威ある結果を確認します。受け入れ済みおよび不確実なアクションの永続的な記録を保持します。注文トークンと内部証拠へのアクセスを制限しつつ、係争中の支払いを調査するのに十分な情報を保持します。ここでの信頼性とは、チェックアウトの滑らかなアニメーションではなく、再現可能な判断を意味します。
保留中の注文にまだ何が必要かを知る
送金が観測されていない、必要なチェーンの信頼性に達していない、または請求書との関連付けにレビューが必要なため、注文が保留のままになる場合があります。請求書と公開トランザクション参照を保存し、記載された受入ルールを確認し、注文の意図された支援プロセスを利用します。ステータス更新の遅延は、それ自体では、別の支払いを送る理由にはなりません。
実際の注文の指示と検証済みステータスに従ってください。支払い確認は、照合済みの送金の受入を示すべきであり、サービスの提供には別のステータスがあります。非公開のアクセストークンやウォレットのシークレットを支援のリクエストに含めないでください。
実践チェックリスト。
- サーバーが作成した不変の見積もりを永続化する。
- チェーン、受取人、資産、整数の金額を検証する。
- チェーン固有の受入ルールを文書化する。
- 固定アドレスの衝突を推測せずに処理する。
- 重複クレジットと安全でない再試行送信を防ぐ。
- 遅延、一部、誤ったルート、変化した証拠のケースをテストする。
重要な詳細。
トランザクションハッシュだけで支払いを確認できますか？+
いいえ。意図されたチェーン上で送金、そのペイロード、信頼性を検証し、それが注文に属し、まだクレジットされていないことを確認します。
すべてのネットワークで同じ確認しきい値を使用できますか？+
いいえ。ネットワークによって信頼性とファイナリティのモデルが異なります。オペレーターは、各ルートに適した受入ポリシーを定義し、テストする必要があります。
支払い確認済みとは、サーバーがプロビジョニング済みという意味ですか？+
いいえ。支払いの受入と提供は別々のワークフローイベントです。プロビジョニングのステータスは、独自の権威あるプロセスから伝えます。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Bitcoin 開発者ガイド：ブロックチェーンの挙動 developer.bitcoin.org
- Ethereum：プルーフ・オブ・ステークとファイナリティ ethereum.org
- Solana：RPC 状態コミットメント solana.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。