Authentification et clés API

Les informations d'identification DEUNA répondent à deux questions différentes : quelle application de commerçant effectue la demande, et, lorsque cela est applicable, Quel client connecté l'utilise ?. Déterminez l'emplacement de la requête et l'entité responsable, puis vérifiez précisément les exigences. catalogue des endpoints.

Déterminez quel identifiant utiliserInterroger Athia à ce sujet#

Posez ces questions dans l'ordre :

1. La requête est-elle exécutée dans un navigateur ou une application mobile ? Utilisez la clé API publique ou le contexte d'application documenté pour l'SDK ou l'endpoint. Ne placez jamais la clé privée dans ce client.
2. Votre backend effectue-t-il une opération de commerçant ? Utilisez la clé API privée dans X-Api-Key pour les appels entre serveur et serveur, tels que la création, la récupération, la capture, le remboursement ou l'annulation d'une commande.
3. DEUNA doit-il reconnaître le client connecté ? Ajoutez le jeton d'accès à court terme du client sous Authorization: Bearer … uniquement lorsque l'endpoint le prend en charge. Cela fournit à la requête un contexte spécifique au client pour les ressources telles que les données de profil, les adresses, les instruments de paiement enregistrés ou les flux de paiement autorisés par le client.

Choisissez le bon titre de créanceInterroger Athia à ce sujet#

Clé API publique : intégration côté clientInterroger Athia à ce sujet#

Utilisez la clé API publique lorsque le code DEUNA est exécuté dans un environnement non sécurisé, tel qu'un navigateur ou une application mobile. Les utilisations typiques comprennent l'initialisation d'un widget ou d'un SDK DEUNA, ainsi que l'identification du commerçant et de l'environnement pour la tokenisation et les expériences de paiement côté client prises en charge.

La clé publique est intentionnellement sécurisée pour être incluse dans la configuration du client, mais elle ne remplace pas une clé secrète et ne permet pas d'effectuer des opérations de capture, de remboursement, d'annulation ou d'autres opérations côté serveur du commerçant. Assurez-vous que la clé publique est associée à l'environnement de sandbox ou de production approprié.

Clé API privée : autorisation serveur-serveurInterroger Athia à ce sujet#

Utilisez la clé API privée lorsque votre backend sécurisé appelle un point de terminaison du commerçant. Les opérations du commerçant qui utilisent l'autorisation par clé API nécessitent la clé privée dans X-Api-Key, jamais dans 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))
}

Token d'accès client : contexte utilisateur authentifiéInterroger Athia à ce sujet#

Utilisez un token d'accès client lorsque l'opération doit être effectuée dans le contexte d'un client DEUNA authentifié et que l'endpoint prend en charge le mécanisme "Bearer". Envoyez-le dans l' Authorization en-tête :

Authorization: Bearer USER_ACCESS_TOKEN

Le jeton Bearer est utilisé pour quel client est en cours d'exécution. La clé API fournit les réponses. quelle application ou serveur backend du commerçant est en cours. Selon l'endpoint, une demande du client peut donc nécessiter à la fois une clé API et le jeton Bearer du client.

Ne transmettez pas un jeton Bearer pour un flux invité simplement parce que l'en-tête est disponible. N'utilisez pas une clé privée du commerçant comme jeton Bearer, et ne considérez pas un jeton client comme autorité pour les opérations réservées aux commerçants. Si votre backend transmet le contexte du client, transmettez-le uniquement à un endpoint qui prend explicitement en charge cette combinaison.

EnvironnementsInterroger Athia à ce sujet#

Les environnements Sandbox et Production sont isolés. Chaque environnement possède son propre URL de base, ses clés API, sa configuration du commerçant, ses connexions, ses données et son état de paiement.

Stocker et faire pivoter les clésInterroger Athia à ce sujet#

• Stockez les clés privées dans un gestionnaire de secrets ou une configuration d'exécution protégée.
• Portée de l'accès au service et à l'environnement qui ont besoin de la clé.
• Rétablir les identifiants à partir des journaux de demande et des pièces jointes de soutien.
• Déployez une clé de remplacement avant de révoquer l'ancienne clé afin que le trafic de production continue en toute sécurité.
• Coordonner l'émission et la rotation des clés avec votre administrateur autorisé ou DEUNA TAM.

Défauts d'authentificationInterroger Athia à ce sujet#

Un défaut d'autorisation revient normalement 401 Unauthorized ou 403 Forbidden. Avant de réessayer, vérifier :

1. Le titre de créance est présent dans l'en-tête documenté.
2. La clé appartient à l'environnement demandé et marchand.
3. Le paramètre supporte la méthode d'autorisation que vous avez envoyée.
4. La clé ou le jeton client n'a pas expiré ou n'a pas été révoqué.
5. Tout marchand, magasin ou client nécessaire est présent.

Ne pas réessayer une erreur d'autorisation indéfiniment. Préserver la réponse request_id si disponible et l'inclure lors de la communication avec le support.

Limites de tauxInterroger Athia à ce sujet#

DEUNA n'applique pas une valeur fixe de "requête par seconde" à chaque intégration. Le Gateway évalue les limites configurées comme un nombre maximum de requêtes dans une fenêtre de temps. La limite effective peut varier en fonction du commerçant, de l'environnement, de la méthode HTTP et de l'endpoint.

Lorsqu'une requête dépasse une limite applicable, le gateway renvoie 429 Too Many Requests avec Retry-After header. La réponse à l'échelle de la route a la forme suivante :

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"
}

Les champs de réponse peuvent différer lorsque une mesure de sécurité à l'échelle du gateway rejette la requête. Traitez le code de statut HTTP et Retry-After header comme autoritaires.

Poignée 429 Répondez de manière sécurisée

1. Arrêtez d'envoyer des requêtes pendant au moins le nombre de secondes spécifié dans Retry-After.
2. Réessayez avec un délai d'attente exponentiel et un jitter au lieu de relâcher immédiatement le trafic en attente, ce qui pourrait provoquer une nouvelle surcharge.
3. Pour la même opération de paiement, réutilisez la clé d'idempotence originale et le corps de requête identique.
4. Coordonnez la limitation de débit entre les workers et les instances d'application ; les boucles de réessayage par processus peuvent collectivement dépasser une limite partagée pour un commerçant ou un endpoint.
5. Si 429 Les réponses sont envoyées après la réduction du trafic, conservez le corps de réponse et l'ID de requête, puis contactez le support DEUNA ou votre gestionnaire de compte technique (TAM).

Demandez une augmentation de la limite

Demandez à DEUNA Support ou à votre TAM de revoir la limite avant une augmentation prévue du trafic. Incluez :

• L'environnement et l'ID du commerçant.
• Les méthodes HTTP et les endpoints affectés.
• Les taux de requête soutenus et de pointe attendus, la durée de la surcharge, et la date de déploiement prévue.
• Les adresses IP publiques ou blocs CIDR utilisés par les systèmes du commerçant pour communiquer avec DEUNA.

Ne communiquez pas les clés API, les jetons Bearer ou toute autre information sensible dans une demande de support.

ContinuerInterroger Athia à ce sujet#