レート制限

このページで扱うトピック

Opn Payments はすべての加盟店に、最高度の可用性、安定性、システムのセキュリティを提供することを主な目標とし、トラフィックの急増と減少を常にモニターしています。 この取り組みの一環として、Omiseは2つの主要な方法を利用して受信リクエスト数を制御しています。レート制限リクエストタイプの優先順位付けです。

IP およびアカウントベースのレート制限 Omise は IP とアカウントに基づいてリクエストのレートを制限します。 短時間のバーストとスパイクを一時的に許容しますが、一定の期間が経過すると、システムの容量に応じて制限がベースラインまで下がります。

注:弊社のVault上でのトークン作成は、メインAPIと比較してレート制限が大幅に低くなっています。

リクエストタイプの優先順位付け すべてのリクエストは、以下の優先順位で処理されます。

  1. ライブモードでのPOST/PUT APIコール(チャージ作成、課金キャプチャ、返金作成など
  2. ライブモードでのGET APIコール(例:トランザクションの一覧表示、単一の課金取得)
  3. テストモードでのすべてのAPIコール

エラー

API から HTTP 429 の Too Many Requests レスポンスを受信している場合、これはリクエストの送信数が多すぎて、Opn Payments のレート制限に達していることを示しています。

このポリシーが加盟店側の統合に悪影響を及ぼす場合は、[連絡する]から(mailto:support@opn.ooo) までご連絡ください。

負荷テスト

上記の優先順位付けに基づいて、テストモードのAPIリクエストは、ライブモードと比較して著しく異なるパフォーマン ス特性を持つことになります。 さらに、テストモードのリクエストは、パフォーマンスを大きく変化させるアップストリームの決済ゲートウェイと相互作用する必要はありません。 これらの理由から、例えば大きなセールスイベントの前などに、API の「負荷テスト」や「ベンチマーク」を行うことはお勧めしません。 API へのリクエストを模擬できるような方法で統合を構築することを強くお勧めします。 必要に応じて、ライブ API リクエストで観測された遅延をシミュレートすることを検討してください。

レート制限を回避するためのヒント

  • ポーリングを避け、代わりに webhooks を使用してください。
  • 同時に多くのリクエストを行わないようにし、時間をかけて分散してください。例: 1 秒間に 100 リクエストを送るのではなく、 1 秒間に 20 リクエストを5 秒間で行う、という形で 100 リクエストを送ることができるかを検討してください。
  • Omise APIへのリクエストを送信するために10以上の並列ワーカーを使用しないようにしてください。
  • リクエスト量の多い大規模なイベントが予想される場合は、連絡するから連絡をお願いします。
Omiseは、お客様のウェブサイト全般における利便性を向上するためにクッキーを利用し、お客様のアクセス、閲覧履歴に関する情報を収集します。 当社のウェブサイトを閲覧し続けることにより、お客様は当社のプライバシーポリシーに同意することとします。 詳細はこちら