プロトコル標準

API は一連の HTTP API 標準に従っており、 べき等性を確保することで、より堅牢な 統合されています

Google がホストする URL

Google がホストする各メソッドのドキュメントには、ベース URL が記載されており、 メソッド名とメジャー バージョン番号が含まれます。完全な URL が作成されます。 呼び出し元の決済インテグレータのアカウント ID を あります。たとえば、Google がホストする echo メソッドに関するドキュメントをご覧ください。 には、URL を指定します。

https://vgw.googleapis.com/secure-serving/gsp/v1/echo

発信者の決済インテグレータのアカウント ID が INTEGRATOR_1 の場合は、次を追加します。 これを URL の末尾に追加します。

https://vgw.googleapis.com/secure-serving/gsp/v1/echo/INTEGRATOR_1

注: エンドポイントのドキュメント ページは、使用する特定のメソッドの ケースに最も正確な URL が表示されます。

パートナーがホストする URL

パートナーがホストする各 API メソッドのドキュメントには、ベース URL が記載されています。 メソッド名とメジャー バージョン番号が含まれます。「 決済インテグレータのアカウント ID（PIAID） 確認できます。

サンドボックス環境と本番環境

Google は Standard Payments API をサンドボックスでホストしています（開発用と 必要があります。Google サンドボックス環境でのリクエスト 実世界において金銭的な法的責任を生じさせることはありません。サンドボックスと 完全に分離され、鍵やストレージ データが共有されることはなく、 トランザクション情報を取得します

Google では、お客様のサンドボックスがいつでも利用可能であることを前提としています。 サンドボックスを使用して、変更と新機能を最初にテストします。

Google のサンドボックスのベースパス

https://vgw.sandbox.google.com/secure-serving/gsp/

注: 統合がすでにリリースされていて、 使用し、https://billpaynotification.sandbox.googleapis.com できます。新しい統合では「vgw.sandbox.google.com」が呼び出されます。できます。

Google の本番環境のベースパス

https://vgw.googleapis.com/secure-serving/gsp/

注: 統合がすでにリリースされていて、 https://billpaynotification.googleapis.com ホストで起動する場合は、引き続きその操作を続けることができます。 新しい統合では「vgw.googleapis.com」ができます。

このガイドでは、本番環境のエンドポイントを使用します。

コンテンツ タイプとエンコード

PGP 暗号化を使用するメッセージ ペイロードでは、 application/octet-stream; charset=utf-8。PGP リクエスト本文は で定義されるように、base64url エンコードを使用して送信される rfc4648 §5。 JWE 暗号化を使用するメッセージ ペイロードでは、コンテンツ タイプを使用する必要があります。 application/jose; charset=utf-8。[Compact Serialization] オプション 最後のリクエスト本文のエンコードを処理します。

HTTP ステータス コード

Standard Payments API は HTTP 200 ステータス コードを返すように設計されています サーバーで処理できるすべてのリクエストに対して 優先度を指定しますこれには、 ビジネスの観点から見ると、リクエストの成功と拒否が 説明します。処理できないリクエストが HTTP 200 ステータス コード（Google と 共有します代わりに、API レスポンスでは適切な HTTP ステータスを使用する必要があります。 オプションの ErrorResponse オブジェクトと置き換えます。

HTTP エラーと理由
400	BAD REQUEST クライアントが無効な引数を指定しました。 また、システムがエラーになったという理由でオペレーションが拒否された場合にも返されます。 オペレーションの実行に必要な状態になっていません。 これは、システム状態に達するまでリクエストの再試行が成功しない場合に使用します 明示的に修正されました。たとえば、以下の理由で払い戻しリクエストが失敗した場合。 存在しないキャプチャを参照しているため、再試行は成功しません キャプチャがインテグレータのシステムに存在する まで継続されます 注: BAD_REQUEST（400）は使用しないでください。 適切なアプリケーション エラーが発生している状況で使用します。対象 正しくない通貨があれば ACCOUNT_DOES_NOT_SUPPORT_CURRENCY とコード 200 を そのフィールドまたは列挙型が標準のレスポンスに含まれます。
401	UNAUTHORIZED リクエストに有効な認証情報がありません。 あります。たとえば、無効なシグネチャや不明なシグネチャは、 401 が返されます。
403	FORBIDDEN / PERMISSION DENIED 呼び出し元には、指定された操作を実行する権限がありません。
404	NOT FOUND 支払いやユーザーなど、リクエストされたエンティティが見つかりませんでした。
409	CONFLICT / ABORTED オペレーションが中止されました。通常は、次のような同時実行の問題が原因です。 シーケンサー チェックの失敗、トランザクションの中止など
412	PRECONDITION FAILED このコードは、べき等性のキーが Pod 内で 再利用できます。
429	RESOURCE EXHAUSTED / TOO MANY REQUESTS 一部のシステム リソースを使い果たしました。
499	CANCELLED オペレーションがキャンセルされました（通常は呼び出し元によってキャンセルされました）。
500	INTERNAL ERROR 内部エラー。つまり、基盤となるシステムで一部の不変条件が予期される 破損しています。
501	UNIMPLEMENTED このサービスではオペレーションが実装、サポート、または有効化されていません。
503	UNAVAILABLE サービスは現在使用できません。これは一時的な問題である可能性が高い 再試行で修正できます。
504	GATEWAY TIMEOUT / DEADLINE EXCEEDED オペレーションが完了する前に期限が切れました。オペレーションが システムの状態が変更された場合、 正常に完了したことがわかります。たとえば、成功したレスポンスが 期限までに十分な時間、サーバーからの 期限が切れます。

リクエストのべき等性

リクエストのべき等性は、Standard Payments で使用される中心的な戦略 Google とパートナーの間のシステム インタラクションが確実に フォールトトレラントですべき等リクエストとは、べき等性を含むリクエストのことです。 複数回送信される可能性がありますが、1 つのリクエストと同じ効果があります。 この戦略では、システム間の結果整合性を促進することで、 安全に再試行できるようにして、 状態を表します。

Google の API はべき等性を利用して、次のことを行います。

• すべてのアクションを簡単に追跡および追跡できるようにして、 監査可能であることです。
• 競合状態を回避するために、複数の同一リクエストが 最終状態が異なることはありません。
• リクエストを個別に理解できるようにすることで状態を最小化し、 パフォーマンスとスループットを向上させるために、 データの保持に使用されます。
• リクエストが再試行かどうかを示す追加のフィールドが不要に

で確認できます。

注: エラー結果をキャッシュに保存したり、べき等を返したりしないでください。そして、 エラーの自動再試行では、指数バックオフ戦略を使用する必要があります。

例

例 1: レスポンスを受信する前に接続が失われた

シナリオ:

1. Google がインテグレータにリクエストを送信します。
2. インテグレータ サーバーがこのリクエストを受信し、正常に処理します。
3. Google のサーバーは、ステップ 2 のレスポンスを受け取る前に電源を失います。
4. Google のサーバーの電源が復旧し、同じリクエストが送信される すべての同じパラメータ（リクエスト ID とリクエストの詳細は同じだが、 requestTimestamp）をインテグレータのサーバーに送信します。

結果:

この場合、インテグレータ サーバーは、次の URL で指定された同じ応答を使用して応答する必要があります。 ステップ 2: responseTimestamp を除くすべてのパラメータが同じであるため。 副作用はステップ 2 で 1 回だけ発生します。ステップ 4 に副作用はありません。

例 2: メンテナンス中のサーバーにリクエストが送信された

シナリオ:

1. インテグレータ サーバーのデータベースは、メンテナンスのため停止しています。
2. Google がインテグレータにリクエストを送信します。
3. インテグレータは UNAVAILABLE ステータス コードを正しく返します。
4. Google のサーバーがレスポンスを受信し、再試行をスケジュールします。
5. インテグレータ サーバーのデータベースがオンラインに戻った。
6. Google がステップ 2 のリクエストを再送信します（リクエスト ID とリクエストの詳細が同じ場合）。 requestTimestamp を更新しました）。両方のリクエストのリクエスト ID が 一致しているはずです
7. インテグレータ サーバーがリクエストを受信し、OK ステータス コードを返す 完全なレスポンスが返されます

結果:

この場合、インテグレーター サーバーはステップ 7 のリクエストを処理する必要があり、 HTTP 503（UNAVAILABLE）を返す。代わりに、インテグレーター サーバーはすべての作業を リクエストを処理し、適切なメッセージを OK で返します。なお、 UNAVAILABLE。Google は次のようなリクエストを繰り返し行う場合があります。 ステップ 2:リクエストごとにステップ 3 のようなメッセージが表示されます。 そして最終的に、ステップ 6 とステップ 7 に入ります。

例 3: 復元エラーのため、再試行されたメッセージが最初のメッセージと一致しない

シナリオ:

1. Google がインテグレータにリクエストを送信します。
2. インテグレータ サーバーがこのリクエストを受信し、正常に処理します。
3. Google のサーバーは、ステップ 2 のレスポンスを受け取る前に電源を失います。
4. Google のサーバーの電源が復旧し、同じリクエストを送信しようとします。 一部のパラメータは異なります

結果:

この場合、インテグレータ サーバーは HTTP 412 で応答する必要があります。 （PRECONDITION FAILED）エラーコードが検出されたことを Google に示す 表示されます。