Vue d’ensemble
La découverte et le paiement sont asynchrones : l’interrogation n’est donc pas une optimisation, c’est le mécanisme même. Tout ce que vous devez savoir sur une transaction se trouve dans sonstatus, lu via Obtenir la transaction par ID.
Le paiement de factures ne vous envoie pas de notifications. L’interrogation est la façon dont les résultats vous parviennent, aussi bien pour les découvertes que pour les paiements.
La machine à états
Toutes les transitions qu’une transaction peut effectuer :SUCCESS, FAILED et REFUNDED sont finaux — une transaction ne les quitte jamais.
Réglages recommandés
Ce sont des points de départ, pas des garanties. Mesurez votre propre trafic et ajustez.
Augmentez l’intervalle au lieu d’en marteler un fixe. Un paiement qui n’est pas terminé au bout de trois secondes ne se terminera pas plus vite parce que vous avez redemandé.
Une boucle d’interrogation de qualité production
La même structure en quatre langages : un intervalle initial, une croissance jusqu’à un plafond, une échéance globale, et une branche par statut.Agir selon chaque statut
Une branche par statut, et aucun cas par défaut qui suppose un échec.Gérer UNKNOWN
UNKNOWN signifie que le résultat n’a pas été confirmé. Ce n’est ni un échec ni un succès. Il se résout de lui-même en SUCCESS ou en REFUNDED.
Ce qu’il faut faire à la place :
1
Bloquer les fonds du client
Gardez le montant réservé de votre côté et affichez un état neutre — « paiement en cours de confirmation », pas « échoué ».
2
Ralentir fortement l'interrogation
Passez à une cadence de 30 secondes, ou à une tâche en arrière-plan qui vérifie périodiquement. Interroger fréquemment n’accélère pas un examen.
3
N'agir que sur la résolution
SUCCESS — soldez et conservez le reçu. REFUNDED — libérez les fonds. Ce n’est qu’ensuite que vous informez le client.Gérer REFUNDED
REFUNDED signifie que le paiement a été débité puis restitué intégralement. Le résultat côté client est le même que pour FAILED — la facture n’est pas payée — mais votre comptabilité diffère : l’argent est parti et revenu, les deux mouvements doivent donc figurer dans votre grand livre.
error.code explique pourquoi le paiement n’a pas abouti :
Les quatre mêmes codes apparaissent sur
FAILED. Branchez sur code, jamais sur message.
Gérer les erreurs transitoires pendant l’interrogation
Une interrogation qui échoue n’est pas une transaction qui a échoué.Ne laissez jamais une interrogation échouée modifier l’état de votre commande. Seul un
status réel issu d’une lecture réussie peut le faire.Ce qu’il ne faut jamais faire
Bonnes pratiques
Une boucle, une transaction
Suivez une transaction par son identifiant. Lister les transactions à répétition pour la retrouver est plus lent et plus lourd.
Augmenter l'intervalle
Commencez à quelques secondes, montez jusqu’à une dizaine. Ralentissez à 30 secondes dès qu’une transaction est
UNKNOWN.Transmettre, ne pas abandonner
Lorsque l’interrogation au premier plan expire, mettez la transaction en file pour un rapprochement en arrière-plan.
Journaliser le requestId
Chaque interrogation en renvoie un. Conservez le dernier avec votre commande — c’est ce dont le support a besoin.
Étape suivante
Étape 5 : Reçus et rapprochement
Conservez la preuve de paiement et rapprochez votre grand livre chaque jour
Pages associées
Obtenir la transaction par ID
L’objet transaction et la matrice des champs
Stratégies d'interrogation
Conseils d’interrogation valables pour tous les produits
Payer des factures
Ce qu’il faut faire avant le paiement
Tests en sandbox
Reproduire
UNKNOWN et REFUNDED à la demande
