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#

Les environnements de test et de production sont isolés et utilisent des identifiants, des données, des connexions de fournisseurs et des états de paiement différents.

EnvironnementURL de baseUtilisation
Bac à sablehttps://api.sandbox.deuna.ioTests d’intégration et de certification
Fabricationhttps://api.deuna.ioTransactions réelles

Voir 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 la liste d'adresses autorisées lorsque votre politique de réseau le permet. Si un fournisseur de paiement ou de lutte contre la fraude exige une liste d'adresses IP, utilisez les adresses suivantes.

EnvironnementTrafic du fournisseur
Bac à sable3.22.44.237
Fabrication3.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 pour chaque opération prise en charge qui crée ou modifie l'état de paiement. Réutiliser la même clé et le même corps de requête identique, en cas de panne réseau ou de dépassement de délai, lors de la nouvelle tentative. Utiliser une nouvelle clé pour une nouvelle tentative.

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

Les réponses réussies sont conservées pendant 24 heures par défaut. Lire Requêtes idempotentes Pour les points d'extrémité pris en charge, la conservation des réponses d'erreur, les en-têtes de reprise, les conflits et la vérification du sandbox.

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. Vérifiez l'état final via les méthodes supportées en utilisant un modèle de traitement asynchrone et une recherche appropriée de commandes dans 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
client stops waiting1Client request2DEUNA orchestration3Payment provider4Pendingreconciliation5Asynchronous updateand order lookup6Final merchant state
DEUNAFournisseur ou processeurRévision ou attenteMarchand ou client