先に業務注文を保存
一意のclient_order_idを作り、数量、期間、受取アドレスをデータベースへ保存します。一意制約で並行処理による重複を防ぎます。本記事は接続例であり、顧客実績ではありません。
正確な見積もりを保存
GET /prices/quote には実際の数量と期間を使います。応答には price_sun、currency、priced_at が含まれ、price_sun は現在の参考価格を表す整数 SUN 文字列です。POST /orders は受理時に再計算して注文価格を固定するため、見積もりIDは送信しません。
送信するバイト列に署名
鍵はサーバーだけに保管します。JSONを一度シリアライズし、仕様に従い実際の送信内容へ署名します。ログから鍵と認証ヘッダーを除きます。
冪等性キーも保存
POST /orders には client_order_id と 8〜128 文字の可視 ASCII Idempotency-Key が必要です。送信前にキーと正確な本文を保存します。不確定な再試行では両方を維持し、timestamp、nonce、署名だけ更新します。加盟店 API は QUOTE_EXPIRED を返しません。Webhook は公開 Skill、アドレス有効化は照会で追跡します。
不確定な応答を照会
POST /ordersがタイムアウトしたら、GET /orders?client_order_id={client_order_id}で確認します。既存注文を追跡し、再試行が適切な場合も同じ番号と条件を維持します。冪等性の競合は調査対象です。
受理と完了を区別
プラットフォームの注文IDと状態を保存し、終端結果と提供の証拠からローカル状態を更新します。HTTP成功だけで委託済みにせず、失敗や確認待ちを残します。
通知の検証と重複排除
仕様に従いWebhook署名を検証し、イベントIDで重複処理を防ぎます。確実に保存または処理してから応答します。状態が食い違う場合は注文照会で照合します。
再試行と異常テスト
タイムアウト、上限付き指数バックオフ、有限の再試行回数を設定し、秘密を含まない履歴を記録します。残高不足、期限切れ、重複、受理後タイムアウト、不正署名を検証してください。実際の通信形式は公開仕様に従います。