Aller au contenu principal
Tous les systèmes sont opérationnelsNouveautésv1
Se connecter

API directe

Créez une expérience de paiement appartenant au commerçant avec les API du serveur DEUNA.

Dernière mise à jour : October 12, 2026
Sur cette page
Méthode d’intégration

Maîtrisez l’interface et coordonnez les paiements depuis votre backend.

Créez le parcours client dans votre application et utilisez les API DEUNA pour les opérations de paiement, utilisateur, carte et orchestration.

Interface
Frontend et backend gérés par le marchand
Mode de déploiement
API serveur à serveur avec prise en charge côté client si nécessaire
Idéal pour
Équipes exigeant un contrôle maximal du produit
Comparer les méthodesOuvrir la référence

Utilisez l'API Direct lorsque votre équipe gère l'interface de paiement et appelle DEUNA à partir d'un backend de marchand de confiance. Votre client collecte ou tokenise l'instrument de paiement, votre backend crée le paiement, et les deux parties gèrent toute action du client nécessaire avant l'état de paiement final.

Suivez le chemin d'intégration.#

1. Configurer l'accèsSélectionnez la clé publique, la clé privée et, éventuellement, le jeton Bearer du client.2. Préparer l'environnementDéfinissez les URL de base, Postman, l'accès réseau, les tentatives, les limites de débit et les délais d'attente du client.3. Collecter les détails de paiementTokenisez les données de carte ou collectez les champs requis pour la méthode de paiement sélectionnée.4. Créer le paiementImplémentez la requête Purchase V2, les réponses, les en-têtes et le contrat d'idempotence.5. Gérer chaque étatImplémentez les actions du client, le traitement en attente, le succès, le rejet, la capture, l'annulation et le remboursement.6. Reconcilier les mises à jourRecevez des notifications de statut asynchrones et confirmez l'état autoritaire de la commande.

1. Configurer le marchand et l'environnement#

Avant de soumettre la requête de paiement :

  1. Complétez configuration du compte et obtenez les identifiants pour l'environnement de test.
  2. Lire Authentification et clés API afin de séparer les identifiants publics du client, les identifiants privés du backend et, éventuellement, l'identité du client.
  3. Configurez au moins une connexion de paiement et une stratégie de routage. Utilisez Capacités des fournisseurs pour confirmer le support du pays, de la méthode, de la devise et de l'opération, puis examinez Stratégies de paiement.
  4. Appliquez les exigences d'environnement et de réseau partagées en Principes essentiels de l’intégration API.
  5. Utiliser les environnements de test Collection Postman lorsque vous souhaitez examiner les requêtes de test avant de mettre en œuvre un client.

Le sandbox et l'environnement de production utilisent des URL de base, des identifiants, des connexions de fournisseurs et des données de paiement différents. Ne mélangez pas les ressources entre les environnements.

2. Collectez les informations de paiement en toute sécurité#

Le commerçant possède l'interface API Direct, mais la gestion des données de carte reste soumise à son périmètre PCI.

  • Si le client doit éviter de manipuler les données de carte brutes côté marchand, utilisez la méthode supportée Flux de tokenisation de carte et envoyez le jeton de méthode de paiement résultant au backend.
  • Si le fournisseur de lutte contre la fraude configuré nécessite des données de navigateur ou d'appareil, implémentez Flux API direct pour la capture de l'empreinte digitale de l'appareil.
  • Pour les portefeuilles et les méthodes de paiement alternatives, commencez avec Capacités des fournisseurs, puis suivez le guide de connexion associé pour les exigences nécessaires. payment_source, specific_fields, redirection, QR, code promo ou comportement de rappel.
  • Si un jeton de commande existant est disponible, le backend peut récupérer ses paramètres configurés. Méthodes de paiement avant de le traiter.

3. Créer et traiter le paiement#

Les nouvelles intégrations doivent commencer par POST /v2/merchants/orders/purchase. Elle prend en charge deux modèles de requête valides :

ModèleQuand l'utiliserDocumentation
Commande en ligne · RecommandéCréer la commande et traiter son paiement via une seule requête Purchase V2.Contrat de requête de paiement et Fournir des exemples concrets
Jeton de commande existant · FacultatifCréer la commande uniquement lorsque l'autre canal ou expérience en nécessite order_token avant le paiement.Créer une commande, puis Traiter la commande existante

Utilisez la Démarrage rapide du paiement dans l'environnement de test Pour le flux backend le plus simple et fonctionnel. catalogue des endpoints est la source d'information officielle des opérations publiées et des appelants pris en charge.

Pour chaque demande de modification de paiement prise en charge, générez une référence stable. X-Idempotency-Key dans l'environnement backend. Utiliser la même clé et le même corps de requête identique lors d'une tentative de nouvelle demande en cas d'échec. Suivre la Guide pour les requêtes idempotentes, y compris sa période de conservation et sa gestion des conflits.

4. Gérer la réponse et l'action du client#

Une requête HTTP 2xx La réponse indique que la requête API a été acceptée ou traitée. Elle ne prouve pas par elle-même que des fonds ont été transférés. order.payment.data.status et toute action suivante renvoyée.

Sélectionnez le cycle de vie correspondant à la méthode choisie :

Workflow pour les cartesGérer les achats, l'autorisation, l'évaluation des risques, la capture, l'annulation, les remboursements et les états finaux de la carte.3D sécuriséPrésenter un appel Direct API pris en charge et évaluer l'état de paiement résultant.Déroulement de la procédure de l ' APMGérer les redirections, les codes QR, les codes promotionnels, la confirmation bancaire, l'annulation et l'expiration.

Ne pas utiliser l'URL de retour du navigateur, le callback SDK ou la redirection du fournisseur comme preuve de paiement. Maintenir la transaction en attente, en cours de traitement, en cours d'examen ou en attente de l'action du client.

5. Confirmer les résultats asynchrones#

Configurer Webhooks de statut de commande et de paiement Pour le commerçant et l'environnement. Vérifiez la signature, acceptez les livraisons répétées de manière idempotente, et validez la demande avant d'exécuter une logique métier lente.

Lorsqu'une réponse synchrone est perdue ou qu'une notification est retardée, récupérez la commande originale avec GET /merchants/orders/{order_token}. Vérifier l'état du paiement récupéré avant de procéder à l'exécution ou avant de lancer une nouvelle tentative.

Pour les délais d'attente du réseau, suivez Gestion des délais d'attente des clientsUn délai d'attente du client ne signifie pas que le paiement a échoué.

6. Implémenter des opérations post-paiement#

Afficher uniquement les opérations prises en charge par la connexion sélectionnée et l'état de paiement actuel:

CapturerCapturer l'intégralité ou une partie d'une autorisation valide.VideEffectuer une autorisation valide avant de finaliser la transaction.RemboursementEffectuer un remboursement complet ou partiel pour un paiement déjà effectué.

Pour un comportement avancé, veuillez consulter Plusieurs captures partielles, Remboursements partiels multipleset Retours asynchrones.

Liste de contrôle pour la mise en production#

  • Les clés privées sont stockées uniquement dans la configuration backend sécurisée et sont masquées dans les journaux.
  • Les identifiants de test et de production, les URL de base, les connexions et les données sont isolés.
  • Chaque action du client nécessaire et réalisable est implémentée. État du paiement et requise
  • Le backend conserve les identifiants de commande, les corps de requête et les clés d'idempotence pour faciliter la récupération.
  • Les signatures de webhook, les livraisons dupliquées, les livraisons retardées et les mises à jour hors séquence sont testées.
  • Le comportement en cas de dépassement du délai d'attente du client est conforme aux accords établis. Gestion du délai d'attente et modèle de réconciliation.
  • 429 et gestion des erreurs de la plateforme Recommandations concernant les limites de débit et le Référence d'erreur.
  • Les contrôles de capture, d'annulation et de remboursement ne sont affichés que si la connexion et l'état le permettent.
  • Les scénarios de succès, de refus, 3DS, en attente, timeout, de nouvelle tentative et d'échec du fournisseur sont certifiés avant le déploiement.