以下のガイドは、私の周りの同僚が実際に踏み込んだ落とし穴に踏み込んだ、または学んだすべての人です。金融および電子商取引の支払いやその他の関連業界に参入しようとしている人、および通関業界に参入したばかりの人に、いくつかの啓蒙と支援を提供したいと思います。 ！
1.金融システムはbigdecimalを使用して金額を処理し、小数点以下の桁数を指定します
財務関連の経験がある方は、金額を処理するときに、精度が失われるためdoubleまたはfloatを使用しないようにしてください。これにより、計算エラーが発生する可能性があります。bigdecimalを使用する必要がありますが、あまりにも多すぎるため、ピットに足を踏み入れることを妨げるものではありません。ヤンは単純すぎる！
実際、bigdecimalを不適切に使用すると、依然として精度が失われます（オンライン検索の例を挙げないでください！）。ここでは、その処理方法について説明します。「小数点以下の桁数を指定してください！」、これ以上踏まないでください。
2.インターフェースの金額フィールドの金額単位を繰り返し確認します
頭脳を使いたくない人が常にいます（笑）、彼らはインターフェース（支払いインターフェースなど）を取得した後、それについて考えさえしなかったため、その金額をインターフェースの金額フィールドに渡しました。彼らは人民元の通過を求めていることを知らない、とあなたは与えました。ポイントです！！！あなたはインターフェースに500ポイントを入れ、そして三者は500元を支払いましたユーザーは考えました（とても幸せです...）
ですから、金額のインターフェイスが表示された場合は、金額の単位（返金額を含む）を確認する必要があることを警告します。
3.トランザクションインターフェースのステータスについては、どのフィールドコードのトランザクションステータスを繰り返し確認する必要があります。
たとえば、次の3者インターフェースの戻りメッセージ
{ "成功"：true、 "結果"：{ "ステータス"： "0"、 "amt"： "100.00" ..... } }
status = 0はビジネスの失敗を意味します
インターフェースを接続する人が、コードサービスが成功する状況を確認しない場合、成功= trueを成功と見なし、上記のメッセージをサービスの失敗として返します。これにより、最終的には資本損失につながる可能性があります。
上記のリターンは、インターフェースプロバイダーに確認した後、成功フィールドはビジネスステータスではなく、このリクエストの通信ステータスのみを表します。このリクエストが製品購入の控除リクエストである場合、考えてみてください。お金は控除されていません。ユーザーにとって、製品は出荷された可能性があります！！！
4.取引金額を返すインターフェースについては、取引が部分的に成功するかどうかを確認してください
一部のビジネスシナリオでは、アプリケーションの金額が確認された金額と一致しない場合があります（部分的に成功する可能性があります）。現時点では、3（2）パーティのインターフェースを呼び出しても、インターフェースから返される金額に注意を払わず、インターフェースを直接使用してトランザクションのステータスを成功させます。その後の処理を決定するために、キャピタルロスが発生するのは簡単です。
トランザクションインターフェースが部分的に成功しないことが確認されたが、インターフェースが金額フィールドを返す場合、ビジネスロジックがビジネスステータスが成功であることを確認した後、アプリケーション金額を再度確認し、確認された金額と一致しているかどうかを確認して、トランザクションが完全に成功することを確認します。
5.トランザクションインターフェイスはべき等でなければなりません。
これは非常に重要です！！！、べき等がわからない場合は、 Baidu（No Google）にアクセスしてください。トランザクションがべき等ではなく、並行シナリオでの支払い（引き出し）である場合、それはN回呼び出され、結果はユーザーにN回支払われ、ユーザーは考えます（とても幸せです...）
今後、他の人のapiを調整する場合でも、他の人にapiを提供する場合でも、「こんにちはそれが良い」ように、インターフェイスがべき等であることを確認してください。。。
6.非同期コールバックインターフェイスはべき等でなければなりません。
これも非常に重要です！！！、「トランザクションが一度だけコールバックされるか、失敗したトランザクションがコールバックされない」とは決して信じないでください。トランザクションには複数のコールバック要求があるからです！
1）。べき等2）呼び出し側が失敗するとコールバックしないと言った場合、失敗コールバックのロジックを追加する必要があります3）呼び出し側が成功しないとコールバックしないと言う場合、成功コールバックのロジックを追加する必要があります
参照：サードパーティの支払いインターフェースの非同期源泉徴収インターフェースの正しい開発方法（オンラインの穴埋めの概要）
7.異常な注文の補償メカニズム（クエリ補充注文）
インターフェースの呼び出しプロセス中に、例外や呼び出しのタイムアウトなどの問題が発生するのは通常のことですが、状況によっては、注文の照会や補充などの補償処理を行う場合があります。
補充注文をクエリすると、トランザクション中に注文に異常が発生し、トランザクション結果が不明な中間状態が生成されます。このとき、3つのパーティ（2つのパーティ）が提供するクエリインターフェースを使用して、元の注文の結果を再確認し、その結果に基づいて何かを行うことができます。補充注文などの補償業務。ここで重要なポイントの1つは、サードパーティのクエリインターフェースにクエリの時間制限があるかどうかを確認することです。一部のサードパーティのインターフェースは、トランザクションの直後にクエリを実行できません。操作の前に数分待つ必要がある場合があります（同期の問題の可能性があります）。事前にクエリを実行すると、インターフェースは注文が存在しないという応答を返し、その後の処理でエラーが発生します！
8.三者間、二者間インターフェースを要求したり、トランザクションとのインターフェースに複雑で時間のかかるロジックをネストしたりすることは禁止されています
場合によっては、トランザクションメソッドの更新やその他の操作で、3者から返された結果を使用して更新を行う前に、3者に要求する必要があります。これは発生します。3者インターフェイスのパフォーマンスに問題がある場合、トランザクション全体を長時間送信できず、データベース接続が解放されません。リクエストの量が多い場合、データベースアセットが不十分で、システムのダウンタイムが発生する可能性があります。
9.継続的に更新します。。。。