クライアントが誤ったリンクを送ってきた場合のAPI注文のキャンセル

まず、注文がサプライヤーに送信されたかどうかを確認する

誤ったリンクは、必ずしもプロモーションがすでに開始されていることを意味するわけではありません。社内データベースでは注文が作成されていても、まだAPIで送信されていない場合があります。その場合、キャンセルはご自身の処理ロジック次第です。注文をキャンセル済みとしてマークし、自動支払いを停止し、送信を開始しなければ十分です。

注文ID、作成日時、リンク、サービスの種類、APIリクエストのログを確認してください。サプライヤーへのリクエストが送信されていない場合は、古い注文の上に新しい注文を作成しないでください。まず元の申請のキャンセルを記録してください。そうしないと、クライアントが異なるリンクで二重に起動される可能性があります。

サプライヤー側の注文ステータスを確認する

APIリクエストがすでに送信されている場合は、サプライヤーに最新のステータスを問い合わせてください。ステータス名は異なりますが、通常はいくつかのグループに分けられます。待機中、処理中、一部実行、完了、キャンセルです。判断には、ご自身のパネル上のステータスではなく、サービスを起動する側の回答が重要です。

• 待機中：注文がまだキャンセル可能な場合があります。
• 処理中：停止が可能な場合もありますが、一部のボリュームがすでに開始されている可能性があります。
• 一部実行：サプライヤーがそのような操作をサポートしている場合、残りのみをキャンセルできます。
• 完了：キャンセルによるリンクの修正はもうできません。

内部ステータスのみで確認する欠点は、更新が遅れる可能性があることです。最新のAPIレスポンスとその受信時刻を基準にしてください。

サービスの開始前に注文をキャンセルする

キューの注文については、サプライヤーのドキュメントにキャンセルメソッドが規定されている場合はそれを使用してください。ご自身の内部番号ではなく、注文作成時に取得したIDを渡してください（異なる値の場合）。完全なレスポンスを保存してください。操作コード、ステータス、エラーテキスト、リクエスト時刻です。

APIがキャンセルを確認するまで、注文がキャンセルされたと見なさないでください。 リクエストの受理とサービスの実際の停止は異なるイベントである場合があります。一部の連携では、まず受理の確認が届き、最終ステータスは後で変わる場合があります。

この方法の欠点は、サプライヤーが注文を処理から外すのに間に合わない場合があることです。その場合、キャンセルは拒否を返すか、未実行部分にのみ適用されます。

確認なしに既存の注文のリンクを変更しない

多くのAPIでは、リンクは注文作成時に固定されます。同じIDで新しいリンクを渡そうとすると、無視されるか、エラーとして処理されるか、予測できない状態が発生する可能性があります。リクエストを再送信すれば自動的にアドレスが置き換わると期待しないでください。

ドキュメントがリンクの編集を明示的にサポートしている場合は、まずサービスがまだ実行を開始していないことを確認してください。次に、古い値、新しい値、APIレスポンスを保存してください。これはクライアントやサプライヤーとの争議の際に役立ちます。

編集の欠点は、メソッドが利用可能であっても、更新前に一部のアクションが古いページに送信されている可能性があることです。修正されたリンクは、すでに得られた結果を移行するものではありません。

一部実行の場合の対処

誤ったリンクでプロモーションがすでに開始されている場合は、残りのキャンセルをリクエストしてください。サプライヤーへの連絡には、注文ID、誤ったリンク、正しいリンク、現在のステータス、エラー発見時刻を記載してください。連絡内容の詳細を何度も変更しないでください。履歴の確認が複雑になります。

残りのキャンセルが確認されたら、すでに実行されたボリュームを記録してください。返金は、サプライヤーの規則で規定されている場合、通常は未実行部分にのみ適用されます。実行済みのボリュームは、技術的にあるチャンネル、動画、プロフィールから別のものに移行することはできません。

一部キャンセルの欠点は明らかです。クライアントはすでに誤ったページで結果を受け取っている可能性があり、この部分の予算は必ずしも返金されません。

注文が完了している場合は、別の申請で修正を行う

完了した注文は通常、API経由でキャンセルできません。そのような状況では、記録を削除したり、履歴のリンクを変更したりしないでください。元のデータは照合に必要です。サービスが遅延して表示されているだけでなく、実際に誤ったアドレスで提供されたかどうかを確認してください。

その後、2つの道があります。サプライヤーの規則に従って補償を話し合うか、クライアントと合意した上で正しいリンクで新しい注文を作成するかです。新しい注文には、別のID、金額、作成理由の明確な注記が必要です。

新規起動の欠点は、追加の予算が必要であり、完了したサービスに対する補償が利用できない場合があることです。

再起動の前にクライアントに状況を伝える

リンクがクライアントのものであり、エラーがクライアント側から来た場合、ご自身の判断で代替を起動しないでください。元のリンク、注文ステータス、キャンセルの可能性、各選択肢の結果をクライアントに送信してください。サービスの一部がすでに実行されている場合は特に重要です。

• 注文が送信されていない場合は、正しいリンクを要求し、古い申請のキャンセルを確認してください。
• 注文がキューの場合は、キャンセルを送信したがサプライヤーの回答待ちであることを伝えてください。
• 一部実行がある場合は、残りのみを停止できることを伝えてください。
• 注文が完了している場合は、新しい起動または別の解決方法を合意してください。

合意に時間がかかる欠点は、その間にキューの注文が処理に移る可能性があることです。そのため、可能であればまず技術的なキャンセルリクエストを送信し、その後で今後の対応を確認してください。

操作のログと証拠を保存する

紛争のある注文ごとに、クライアントからの元のリンク、受信日、内部番号、サプライヤー側のID、APIリクエストとレスポンスを保存してください。クライアントがチャットでリンクを送信した場合、注文カード内で元のものを保存せずに編集済みのバージョンに置き換えないでください。

誰がいつエラーに気づいたかを別途記録してください。これは、誤って送信されたデータと、マネージャーのミス、注文フォーム、自動入力のエラーを区別するのに役立ちます。サプライヤーへの再問い合わせの際は、矛盾が生じないように1つのデータチェーンを使用してください。

手動でログを管理する欠点は、時間がかかることです。しかし、履歴がなければ、キャンセルステータスを確認し、なぜ資金を全額返金できないのかをクライアントに説明するのが難しくなります。

連携におけるエラー処理を確認する

このような事例の後、システムがAPIにリンクをどのように渡すかを確認してください。エラーはクライアントだけが原因で発生するわけではありません。フォームがパラメータを切り捨てたり、キャッシュから古い値を代入したり、投稿へのリンクの代わりにプロフィールへのリンクを受け入れたり、余分な文字を含むリンクを通過させたりする場合があります。

注文作成前に形式チェックを追加してください。プラットフォーム、サービスの種類、期待されるオブジェクトとの一致です。動画サービスの場合、システムはチャンネルへのリンクと動画へのリンクを区別する必要があり、ソーシャルメディアの場合はプロフィールと個別の投稿を区別する必要があります。チェックはリンクの正確性を保証するものではありませんが、明らかなエラーの一部を排除します。

注文の送信は、短いデータチェックによって作成から分離することをお勧めします。 追加ステップの欠点は、注文がすぐに作業に入らないことですが、誤ったアドレスに気づく時間ができます。

チーム向けに明確なキャンセルシナリオを設定する

統一された手順を記述してください。自動送信を停止し、サプライヤーのステータスを確認し、キャンセルを送信し、レスポンスを保存し、クライアントに通知し、その後でのみ再起動を合意します。このようなシナリオは形式上のものではなく、異なる従業員が相互に排他的なアクションを実行しないようにするために必要です。

権限の制限とアクションログなしでキャンセルへのアクセスを許可しないでください。複数のマネージャーが同時に1つの注文を扱っている場合、1人がキャンセルをリクエストし、別の人が回答を受け取る前に代替を作成する可能性があります。これは余分なコストと計算の混乱を招きます。

厳格なシナリオの欠点は、緊急時の柔軟性が低いことです。しかし、API注文では、個々のアクションの速度よりも、どのリンクが実際に作業に入ったかの管理が重要です。