Aller au contenu principal
Sur cette page

Configurez ces éléments communs avant d’intégrer une ressource de l’API DEUNA. Les mêmes règles d’environnement, de réseau, de nouvelle tentative et de délai s’appliquent aux commandes, paiements, utilisateurs, liens de paiement et abonnements.

Environnements#

Le sandbox et la production sont isolés et utilisent des identifiants, des données et des endpoints de webhook distincts.

EnvironnementURL de baseUtilisation
Environnement de testhttps://api.sandbox.deuna.ioTests d’intégration et de certification
Productionhttps://api.deuna.ioTransactions réelles

Consultez Authentification et environnements pour les types d’identifiants, leur rotation et les exemples de requêtes.

Collection Postman#

Utilisez la collection Postman DEUNA pour explorer les requêtes avant de développer un client.

Ouvrir la collection DEUNA dans Postman

  1. Connectez-vous à Postman et créez un fork de la collection dans votre espace de travail.
  2. Sélectionnez l’environnement sandbox ou production.
  3. Renseignez merchant_id, public_api_keyet private_api_key avec les valeurs de cet environnement.
  4. Commencez par une opération du catalogue des endpoints.

Adresses IP#

Privilégiez une liste de domaines autorisés lorsque votre politique réseau le permet. Si votre récepteur de webhooks ou un fournisseur de paiement ou de fraude impose une liste d’IP autorisées, utilisez les adresses ci-dessous.

EnvironnementWebhooks entrants et trafic sortant vers les fournisseurs
Environnement de test3.22.44.237
Production3.131.108.151 · 3.132.78.68 · 3.19.18.42 · 18.220.134.28

Codes de réponse#

Une opération réussie renvoie une réponse 2xx . Une réponse 4xx signifie que l’authentification, les autorisations, les données ou l’état de la ressource doivent changer. Une réponse 5xx correspond à un échec temporaire de DEUNA ou du fournisseur et ne doit être retentée que si l’opération peut être répétée en toute sécurité.

Utilisez la référence des réponses et codes d’erreur pour identifier la cause, la politique de nouvelle tentative et l’action corrective.

Requêtes idempotentes#

Envoyez une valeur X-Idempotency-Key stable pour chaque opération distincte qui crée ou modifie l’état d’un paiement. Réutilisez la même clé et un corps identique après une erreur réseau ou un délai d’attente client. Utilisez une nouvelle clé pour une nouvelle tentative métier.

En-têtes d’une requête idempotenteHTTP
X-Api-Key: YOUR_PRIVATE_API_KEY
X-Store-Code: STORE_CODE
X-Idempotency-Key: order_1042-attempt_1
Content-Type: application/json

Consultez Créer un paiement pour le contrat propre à l’achat et un exemple de nouvelle tentative.

Délais d’attente client#

Un délai d’attente client signifie que l’appelant a cessé d’attendre ; il ne prouve pas l’échec du paiement. Le traitement peut continuer avec les contrôles de fraude, le routage et le fournisseur après la déconnexion.

Lorsqu’une requête de paiement expire :

  1. Bloquez le fulfillment et marquez la tentative comme en attente de rapprochement dans votre système.
  2. Conservez l’ID de commande, le corps et la clé d’idempotence d’origine.
  3. Ne retentez que si l’opération est éligible, avec la même clé et un corps identique.
  4. Rapprochez l’état final à partir d’un webhook vérifié ou d’une recherche de commande appropriée dans le catalogue des endpoints.
  5. Présentez le résultat rapproché à l’acheteur et terminez toute annulation ou tout remboursement requis avant le fulfillment.
Diagramme de flux
1-. "client stops waiting".-> D["Pendingreconciliation"]2DEUNA orchestration3Payment provider4Verified webhook or orderlookup5Final merchant state6D
Exception ou arrêtDEUNAFournisseur ou processeurMarchand ou client