Sign in
はじめに/Webhook 通知

Webhook 通知

HMAC 署名付き Webhook で支払いと出金のステータス更新をリアルタイムに受信します。

2328.io は支払いステータスが変化するたびに、url_callback に Webhook を送信します。これは支払い成功の通知を受け取る推奨方法です。

リクエスト形式

  • Method: POST
  • Content-Type: application/json
  • Signature: リクエストボディの sign フィールド

ペイロード

Webhook ボディは /v1/payment/info のレスポンス形式に従い、tx_explorer_url と署名検証用の sign フィールドが追加されます。

支払い成功

JSON
{
  "uuid": "db17d490-15b6-47b9-9015-91d1d8b119f2",
  "order_id": "ORDER-12345",
  "amount": "180.00000000",
  "currency": "RUB",
  "url": "https://go.2328.io/db17d490-15b6-47b9-9015-91d1d8b119f2",
  "expires_at": "2026-05-09T16:56:58+03:00",
  "created_at": "2026-05-09T15:56:58+03:00",
  "payer_currency": "TON",
  "payer_amount": "0.95256917",
  "network": "TON",
  "address": "UQA0RevhkCQx-EltyNgPPeG8dqtnCz7ZslOzMdNQlLxVaNBb",
  "payment_status": "paid",
  "txid": "41c2a327323480af8e705d05deb09c238a41779928832abef4bb77c862357b11",
  "tx_explorer_url": "https://tonviewer.com/transaction/41c2a327323480af8e705d05deb09c238a41779928832abef4bb77c862357b11",
  "payment_amount": "0.95256917",
  "merchant_amount": "0.949711462490000000",
  "amount_usd": "2.41324380",
  "exchange_rate": "0.01340691",
  "sign": "6f8c15b6e53b506d5bfa38ed3fb3b50697af73434262153c02e412541372f04d"
}

キャンセル/失敗した支払い

支払いが終端状態 paid でない場合、txidpayment_amountmerchant_amountnull になります:

JSON
{
  "uuid": "48edaf2d-2c49-4638-8f86-88636f661c1f",
  "order_id": "ORDER-12345",
  "amount": "2800.00000000",
  "currency": "RUB",
  "url": "https://go.2328.io/48edaf2d-2c49-4638-8f86-88636f661c1f",
  "expires_at": "2026-05-09T06:19:04+03:00",
  "created_at": "2026-05-09T05:19:04+03:00",
  "payer_currency": "ETH",
  "payer_amount": "0.01620968",
  "network": "ETH-ERC20",
  "address": "0x37c20d6d96d130Bc5B33D832e43b8e16aACe0c59",
  "payment_status": "cancel",
  "txid": null,
  "tx_explorer_url": null,
  "payment_amount": null,
  "merchant_amount": null,
  "amount_usd": "37.53934800",
  "exchange_rate": "0.01340691",
  "sign": "40ce68ad9691ad54e684329d75ab5adaf5b01409a2d18d3e0110b8c1be605342"
}

フィールドリファレンス

FieldTypeDescription
uuidstring支払い UUID
order_idstring注文 ID
amountdecimal (8 dp)currency での法定通貨金額
currencystringマーチャントが要求した法定通貨
urlstringホスト型チェックアウト URL
expires_atstring (ISO 8601)決済セッションの有効期限
created_atstring (ISO 8601)決済セッション作成日時
payer_currencystring支払者が支払う暗号資産
payer_amountdecimal (8 dp)期待される暗号資産の金額
networkstringブロックチェーンネットワーク
addressstring入金アドレス
payment_statusstringpendingcheckpaidunderpaid_checkunderpaidoverpaidcancelaml_lock のいずれか(References を参照)
txidstring | nullブロックチェーントランザクションハッシュ。確定支払い後にのみ存在
tx_explorer_urlstring | nullブロックチェーンエクスプローラーのトランザクション URL。txid がない場合、または内部 P2P 送金の場合は null
payment_amountdecimal | null実際に支払われた金額。支払い後にのみ存在
merchant_amountdecimal (18 dp) | null手数料控除後にマーチャントへクレジットされる金額
amount_usddecimal (8 dp)作成時点の USD 換算金額
exchange_ratedecimal使用された 暗号資産 / 法定通貨 の為替レート
signstring (hex)ペイロードの HMAC-SHA256 署名

署名の検証

Webhook 署名を検証するには:

  1. ペイロードから sign フィールドを取り出す
  2. オブジェクトから sign フィールドを削除する
  3. 残りのフィールドを JSON エンコードする
  4. JSON を Base64 エンコードする
  5. API_KEY を使って Base64 文字列の HMAC-SHA256 を計算する
  6. 計算した署名と sign 値を定数時間比較で照合する
PHP
<?php
function verifyWebhookSign(array $data, string $apiKey): bool {
    $receivedSign = $data['sign'] ?? '';
    unset($data['sign']);

    $json = json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
    $base64 = base64_encode($json);
    $calculated = hash_hmac('sha256', $base64, $apiKey);

    return hash_equals($calculated, $receivedSign);
}

$apiKey = 'YOUR_API_KEY';
$payload = json_decode(file_get_contents('php://input'), true);

if (!verifyWebhookSign($payload, $apiKey)) {
    http_response_code(401);
    exit;
}

switch ($payload['payment_status']) {
    case 'paid':
    case 'overpaid':
        // Credit the order — check idempotency by order_id first
        break;
    case 'underpaid_check':
    case 'underpaid':
    case 'cancel':
        break;
}

http_response_code(200);

ユーザーに資金をクレジットする前に、必ず署名を検証してください。 署名のない、または不正な署名の Webhook はなりすましリクエストである可能性があります。

出金 Webhook

出金の status が変化すると、システムは出金作成時に渡された url_callback URL に POST Webhook を送信します。url_callback が指定されていない場合、その出金には Webhook は送信されません。

出金 Webhook は通常の API キーではなく Payout API key で検証する必要があります。署名アルゴリズムは支払い Webhook と同一です(sign を取り除き、JSON エンコード、base64、HMAC-SHA256)が、キーのみが異なります。

ペイロード

JSON
{
  "uuid": "019dff1f-0dbd-7277-8d45-271e7775388f",
  "order_id": "4dfdcc84402b1185b71cbe399321533e",
  "status": "completed",
  "currency": "TRX",
  "network": "TRX-TRC20",
  "amount": "3.00",
  "merchant_amount": "3.00",
  "network_amount": "3.00",
  "amount_usd": "1.04",
  "to_address": "THauRv5tcucQRohXg8NiyGTk16DX1XQG5x",
  "memo": null,
  "txid": "9242e533703704ef3eaba840f70b4a26333e72c943377ee375fea17badb53def",
  "tx_explorer_url": "https://tronscan.org/#/transaction/9242e533703704ef3eaba840f70b4a26333e72c943377ee375fea17badb53def",
  "block_number": null,
  "error_type": null,
  "created_at": "2026-05-07T00:08:38+03:00",
  "updated_at": "2026-05-07T00:08:54+03:00",
  "from_currency": "USDT",
  "debited_amount": "1.050735",
  "debited_currency": "USDT",
  "sign": "925ad7bf3d6841864101f7cc2c7e30652e70a06cdb04dbe07a0129480000ce4a"
}

フィールドリファレンス

FieldTypeDescription
uuidstring出金 UUID
order_idstring提供した冪等性/参照 ID(指定した場合)
statusstringpendingcompletedfailedcancelledReferences を参照)
currencystring出金通貨
networkstringブロックチェーンネットワーク
amountdecimal出金額(currency 単位)
merchant_amountdecimalマーチャント残高から課金された金額
network_amountdecimal実際にオンチェーンで送信された金額
amount_usddecimal出金時点の USD 換算金額
to_addressstring受取人のブロックチェーンアドレス
memostring | null使用された場合のメモ/宛先タグ
txidstring | nullブロックチェーントランザクションハッシュ。completed で設定
tx_explorer_urlstring | nullブロックチェーンエクスプローラーのトランザクション URL。txid がない場合、または内部 P2P 送金の場合は null
block_numberinteger | nullオンチェーントランザクションのブロック高
error_typestring | nullstatus = failed のときの理由(例:aml_riskReferences を参照)
created_atstring (ISO 8601)出金作成日時
updated_atstring (ISO 8601)最終ステータス変更日時
from_currencystring自動換算が使われた場合に出金が引き落とされたソース残高(例:BTC 出金に対する USDT
debited_amountdecimalfrom_currency 残高から引き落とされた金額
debited_currencystring引き落とし通貨
signstring (hex)ペイロードの HMAC-SHA256 署名(Payout API key で署名)

ベストプラクティス

  • 冪等性 — 支払いがすでに処理済みかを常に確認する(order_id または uuid で)。Webhook は複数回到着することがあります。
  • 高速なレスポンス — 可能な限り早く HTTP 200 を返してください。重い処理はバックグラウンドキューにオフロードします。
  • 再送信 — システムが HTTP 200 を受け取らない場合、Webhook は 2 分後に再送信されます。最大 5 回まで再試行します。
  • 非同期処理 — レスポンスをブロックしないよう Webhook イベントは非同期に処理してください。
  • セキュリティ — ペイロードを信頼する前に必ず sign 署名を検証してください。

Webhook は順序通りに到着しないことがあります。受信した最初の Webhook が最終状態だと仮定しないでください — 確実性が必要な場合は、必ず /v1/payment/info(または /v1/payout/status/{uuid})で再取得してください。

配送および処理契約

Webhookエンドポイント内で次の順序を使用してください:

  1. シークレットや完全な署名をログに記録せずにリクエストボディを読み取ります。
  2. それが支払い/静的ウォレットイベントか、支払イベントかを識別し、正しいAPIキーを選択します。
  3. sign を削除し、文書化されたJSONバイトを再現し、HMAC-SHA256を計算し、定数時間で比較します。
  4. 必要な識別子、10進文字列、およびステータス値を検証します。
  5. インボックス/冪等性レコードを原子的に挿入します。もし既に存在する場合、副作用を繰り返さずにHTTP 200を返します。
  6. 注文/台帳の変更をコミットし、重要でないメール、分析、または通知をキューに追加します。
  7. HTTP 200 を迅速に返します。

冪等性トランザクションを保持している間は、遅いサードパーティサービスを呼び出さないでください。コミット後、返却前にタイムアウトが発生すると再試行が起こる可能性があります。重複はコミット済みの受信ボックスキーを確認し、無操作になる必要があります。

イベント主要な識別子メモ
支払いセッションuuid + ステータス/バージョンの証拠同じ請求書でも複数の正当なステータス変更を発生させることができます。
部分支払いのチャージ請求書 uuid + txid1つの請求書に複数の振込が含まれることがあります。
静的ウォレット入金ネットワーク + txidorder_id はそのウォレットへのすべての入金で再利用されます。
支払い支払い uuid + ステータスWebhookの再試行ロジックから2回目の支払いを作成しないでください。

スキーマにイベントIDがない場合は、検証済みペイロードハッシュを追加の監査証拠として保存してください。ただし、上記のビジネス識別子をタイムスタンプに置き換えないでください。

注文と照合

配信は少なくとも一度行われ、ステータスメッセージが競合する可能性があります。「最後のリクエストが勝つ」ではなく、単調なビジネスルールを実装してください:

  • 古いイベントが遅れて到着した場合でも、履行済みの注文をcheckに戻さないでください;
  • 以前のクレジットを繰り返すことなく、underpaid_checkが追加のtxidを受け取れるようにしてください;
  • paidoverpaidをそれぞれ異なる金額を保持したまま成功した決済状態として扱ってください;
  • 権威あるAPIが後で別の状態を報告しない限り、underpaidを最終的な部分支払いの結果として維持してください;
  • aml_lockをレビューにルーティングし、一般的な再試行ワーカーに履行させないでください;
  • 遷移が不可能な場合、コンテキストが不足している場合、または金銭的にあいまいな場合には、支払い/支払い情報を照会してください。

Webhook 配信が正常に見えても、スケジュールされた照合を実行してください。ローカル端末の状態と入金額を /v1/payment/info/v1/static-wallet/transactions、または /v1/payout/status/{uuid} と比較し、台帳履歴を静かに上書きするのではなく、差異があれば警告を出してください。

Webhook エンドポイントのセキュリティ

  • HTTPS を必須とし、コールバックを公開可能に保ってください。支払い作成時には、プライベート/ループバックのコールバックターゲットは拒否されます。
  • 小さなリクエストボディの制限と JSON コンテンツタイプを強制してください。
  • 高コストな処理の前にレート制限を行いますが、正当なバーストや再試行の余地は十分に残してください。
  • ウェブフックをソースIPだけで認証してはいけません。ネットワークの許可リストは多層防御の一部であり、HMACの検証は必須です。
  • sign、APIキー、ポリシーで必要とされる場合の住所、アプリケーションログから個人メタデータをマスクしてください。
  • 制御されたローテーション期間中は、現在のキーと明示的にスケジュールされた置換キーの両方を利用可能にしておき、どのキーがイベントに署名したかを推測してはいけません。
  • 署名が無効の場合は汎用的なエラーボディを返し、エンドポイントがキーまたはアカウントの情報源とならないようにします。