認証とAPIキー

DEUNAの認証情報は、以下の2つの質問に答えます。 どの商取引アプリケーションが呼び出しているか、および、該当する場合、 どの登録済み顧客が使用しているか。 まず、リクエストが実行される場所と、必要な権限を確認し、その後、正確な要件を エンドポイント: カタログ.

どの認証情報を利用するかを決定するこれについて Athia に質問#

以下の順序で質問してください。

1. リクエストはブラウザまたはモバイルアプリケーションで実行されますか？ 公開APIキーまたはSDKまたはエンドポイントでドキュメントされているアプリケーションコンテキストを使用します。クライアントにはプライベートキーを配置しないでください。
2. バックエンドで商取引操作を実行しますか？ プライベートAPIキーを X-Api-Key サーバー間での呼び出し（注文の作成、取得、決済、払い戻し、キャンセルなど）に使用します。
3. DEUNAは、登録済み顧客を認識する必要がありますか？ エンドポイントがサポートする場合、顧客の短い有効期限のアクセストークンを Authorization: Bearer … のみ追加します。これにより、リクエストは、プロファイルデータ、住所、保存された支払い手段、または顧客が承認したウォレットフローなどのリソースに対して、顧客固有のコンテキストを提供します。

適切な認証情報を選択してくださいこれについて Athia に質問#

公開されたAPIキー: クライアントサイド統合これについて Athia に質問#

DEUNAのコードが、ブラウザやモバイルアプリケーションなどの信頼できないクライアントで実行される場合、公開APIキーを使用します。一般的な用途としては、DEUNAのウィジェットやSDKを初期化し、クライアント側のトークン化および決済体験をサポートするための、商社と環境を特定することが挙げられます。

公開キーは、クライアント設定に含めることを意図していますが、秘密キーではなく、決済、払い戻し、キャンセルなどの商社側のバックエンド操作を実行するための権限を与えるものではありません。公開キーは、正しいサンドボックスまたは本番環境と関連付けてください。

プライベートAPIキー：サーバー間認証これについて Athia に質問#

プライベートAPIキーは、信頼できるバックエンドから商社エンドポイントを呼び出す場合に使用します。APIキーによる認証を使用する商社側の操作では、プライベートキーを以下に指定する必要があります。 X-Api-Key（例：APIキーではなく、トークンを使用） Authorization: Bearer ….

curl --request GET \
  --url https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN \
  --header "X-Api-Key: YOUR_PRIVATE_API_KEY"

const response = await fetch("https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN", {
  method: "GET",
  headers: {
    "X-Api-Key": "YOUR_PRIVATE_API_KEY"
  }
});

if (!response.ok) throw new Error(`Request failed: ${response.status}`);
const data = await response.json();

import requests

response = requests.request(
    "GET",
    "https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN",
    headers={
        "X-Api-Key": "YOUR_PRIVATE_API_KEY"
    },
)
response.raise_for_status()
data = response.json()

<?php
$curl = curl_init();

curl_setopt_array($curl, [
  CURLOPT_URL => "https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN",
  CURLOPT_CUSTOMREQUEST => "GET",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_HTTPHEADER => [
    "X-Api-Key: YOUR_PRIVATE_API_KEY"
  ]
]);

$response = curl_exec($curl);
curl_close($curl);

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class Example {
  public static void main(String[] args) throws Exception {
    HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN"))
      .header("X-Api-Key", "YOUR_PRIVATE_API_KEY")
      .method("GET", HttpRequest.BodyPublishers.noBody())
      .build();

    HttpResponse<String> response = HttpClient.newHttpClient().send(
      request, HttpResponse.BodyHandlers.ofString()
    );
    System.out.println(response.body());
  }
}

package main

import (
  "fmt"
  "io"
  "net/http"
)

func main() {
  request, err := http.NewRequest("GET", "https://api.sandbox.deuna.io/merchants/orders/ORDER_TOKEN", nil)
  if err != nil { panic(err) }
  request.Header.Set("X-Api-Key", "YOUR_PRIVATE_API_KEY")

  response, err := http.DefaultClient.Do(request)
  if err != nil { panic(err) }
  defer response.Body.Close()

  body, _ := io.ReadAll(response.Body)
  fmt.Println(string(body))
}

顧客 Bearer トークン：ログイン済みユーザーのコンテキストこれについて Athia に質問#

顧客アクセストークンは、操作がログイン済みのDEUNA顧客のコンテキストで実行され、エンドポイントがBearer認証をサポートする場合に使用します。ヘッダーの Authorization に送信してください：

Authorization: Bearer USER_ACCESS_TOKEN

ベアラートークンは、 どの顧客が 操作しているかを示します。APIキーは、 どの商社アプリケーションまたはバックエンドが 呼び出しているかを示します。したがって、特定のエンドポイントでは、顧客のベアラートークンとアプリケーションのAPIキーの両方が必要となる場合があります。

ゲストフローでベアラートークンを送信することは、ヘッダーが存在するだけでは正しくありません。商社のプライベートキーをベアラートークンとして使用したり、顧客トークンを商社のみの操作の認証として使用したりしないでください。バックエンドで顧客のコンテキストを転送する場合は、そのコンテキストをサポートするエンドポイントにのみ転送してください。

環境これについて Athia に質問#

サンドボックスと本番環境は分離されています。各環境には、独自のベースURL、APIキー、商人の設定、接続、データ、および支払い状態があります。

キーの保存とローテーションこれについて Athia に質問#

• プライベートキーは、秘密管理ツールまたは保護された実行時設定に保存してください。
• サービスおよび必要な環境へのアクセス範囲を制限してください。
• リクエストログおよびサポート添付ファイルから認証情報を削除してください。
• 古いキーを削除する前に、代替キーをデプロイして、本番環境でのトラフィックを安全に継続します。
• キーの発行とローテーションは、承認された管理者オペレーターまたはDEUNAのTAMと連携して実施してください。

認証エラーこれについて Athia に質問#

認証エラーは通常、以下のような結果を返します。 401 Unauthorized または 403 Forbidden再試行する前に、以下の点を確認してください。

1. 認証情報は、ドキュメントで指定されたヘッダーに存在します。
2. キーは、要求された環境と商社に属していること。
3. このエンドポイントは、送信した認証方法をサポートしています。
4. 顧客トークンまたはキーは有効期限切れになっていません。
5. 必要な商社、店舗、または顧客に関する情報はすべて含まれています。

永続的に認証エラーを再試行しないでください。 応答を保持してください。 request_id 利用可能な場合は、お問い合わせの際に必ず記載してください。

レート制限これについて Athia に質問#

DEUNAは、すべての統合に対して一貫したリクエスト/秒の制限を適用していません。API Gatewayは、指定された時間枠内で構成された制限を最大リクエスト数として評価します。有効な制限は、商人、環境、HTTPメソッド、およびエンドポイントによって異なる場合があります。

リクエストが設定された制限を超えた場合、ゲートウェイは 429 Too Many Requests 以下の Retry-After ヘッダーを返します。ルートレベルでのレスポンスは以下の形式になります。

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 1

{
  "error": "rate_limit_exceeded",
  "message": "maximum requests",
  "code": 429,
  "endpoint": "/merchants/orders",
  "total_requests": 101,
  "retry_after": "1s"
}

ゲートウェイ全体で制限が適用された場合、レスポンスフィールドは異なる場合があります。HTTPステータスと Retry-After ヘッダーを信頼してください。

処理 429 安全にレスポンスを処理してください

1. 少なくとも、 Retry-After.
2. 秒間、リクエストを送信するのを停止します。指数関数的なバックオフとジャイターを使用して、別のパルスとして、すぐにキューからトラフィックを解放するのではなく、再試行してください。
3. 同じ決済操作に対しては、元のアイデンティティキーと、正確なリクエストボディを再利用してください。
4. 複数のワーカーとアプリケーションインスタンスでのリクエスト制限の調整。個別のプロセスでの再試行ループが、共有の商社またはエンドポイントの制限を超過する可能性があります。
5. もし 429 トラフィックが削減された後も、レスポンスは継続します。レスポンスボディとリクエストIDを保持し、その後、DEUNAサポートまたはテクニカルアカウントマネージャー（TAM）にご連絡ください。

制限の増加をリクエスト

計画的なトラフィック増加の前に、DEUNAサポートまたはTAMに制限を確認を依頼してください。以下の情報を含めてください：

• 環境と商社ID。
• 影響を受けているHTTPメソッドとエンドポイント。
• 予想される持続的なおよびピーク時のリクエストレート、バースト期間、および計画された展開日。
• 商社システムがDEUNAに呼び出す際に使用する、アウトバウンド（エグレス）のパブリックIPアドレスまたはCIDR。

サポートリクエストには、APIキー、ベアラートークン、その他の機密情報を含めないでください。

続きこれについて Athia に質問#