Workflow pour les paiements par carte
Suivez les états d'achat, d'autorisation, de 3DS, de revue, de capture, de blocage et de remboursement de carte sans mélanger l'authentification avec le succès du paiement.
Sur cette page
Les paiements par carte utilisent soit un achat en une étape, soit un modèle d'autorisation et de capture en deux étapes. Consultez la valeur actuelle dans payment.data.status; si le paiement se trouve dans une réponse de commande, consultez order.payment.data.status.
Utilisez cette page pour le chemin spécifique à la carte. Pour chaque définition d'état et transition directe autorisée, consultez Workflow et statuts de paiement.
Achat et autorisation#
La connexion du processeur configurée détermine si DEUNA effectue un achat ou une autorisation. Un défi 3DS peut précéder l'une ou l'autre opération.
| État | Signification | Action du commerçant |
|---|---|---|
pending | Le paiement par carte existe, mais le routage, l'authentification ou le traitement n'ont peut-être pas commencé. | Suivre next_action lorsqu'elles sont présentes et maintiennent la réalisation bloquée. |
pending_3ds | L'authentification de l'émetteur est incomplète. | Complétez le défi, puis évaluez le nouveau statut du paiement. |
processing | Une demande d'achat est en cours. | Attendre processed ou un autre résultat autoritaire. |
authorizing | Une autorisation en deux étapes est en cours. | Attendre authorized ou un autre résultat autoritaire. |
processed | Un achat est terminé et les fonds ont été collectés. | Appliquez la politique de réalisation ; le paiement peut toujours être remboursé. |
authorized | Les fonds ont été réservés, mais pas collectés. | Capturez ou annulez dans les limites de la connexion du processeur. |
3DS et OTP
Seule une réussite d'authentification permet de poursuivre le flux de paiement par carte. Cela ne prouve pas qu'un achat ou une autorisation a réussi. Après le défi, attendez processed, authorized, ou un autre état de paiement déclaré.
Certains adaptateurs de processeur utilisent pending_otp interne. Le traitement actuel des paiements normalise les résultats pour le public pending et fournit les métadonnées nécessaires pour la prochaine action. Si un ancien rapport ou filtre de recherche contient pending_otp, le traiter comme attendant l'action du client — pas comme le succès de paiement.
Revue et retours#
manual_review met en attente la réalisation jusqu'à ce qu'une décision de risque produise un nouveau statut de paiement. Une revue approuvée peut continuer à processed ou captured; une revue rejetée peut produire denied. Voir Déroulement et situation des fraudes pour les champs et décisions de fraude distincts.
denied décrit la tentative infructueuse, mais la machine d'état des paiements peut router ou réessayer le même paiement vers pending, pending_3ds, processing, ou authorizing. Ne réalisez pas une tentative rejetée et ne modélisez pas denied comme un statut de paiement terminal.
Capturez une autorisation#
Capture convertit les fonds réservés en fonds collectés. Le processeur, le montant autorisé restant, les limites de temps et la configuration du commerçant déterminent quelles opérations de capture sont admissibles.
La machine d'état peut également recevoir captured ou partial_captured directement sans exposer l'état "en cours" correspondant. Les notifications sont des instantanés autoritaires, et non une séquence garantie d'événements.
Pour les modes de capture partielle, la concurrence prise en charge, les limites de temps et final_captureVoir MPC — Captures partielles multiples.
Annuler une autorisation#
Annulation libère les fonds réservés. Cela est différent d'un remboursement, qui renvoie les fonds qui ont déjà été collectés.
Le succès API Void retourne HTTP 204 No Content. Lorsque le processeur se termine de manière asynchrone, utilisez l'état de paiement ultérieur comme résultat.
Remboursez les fonds collectés#
Un achat réussi, une capture complète ou une capture partielle peut être remboursé lorsque la connexion et le montant restant remboursable le permettent.
Un remboursement échoué peut restaurer processed, captured, ou partial_captured. Conservez le paiement réussi et la tentative de remboursement échouée séparément. Consultez RPM — Remboursements partiels multiples pour les modes natifs et DEUNA agrégés, les limites de temps, la concurrence et le comportement du sol restant.
Liste de contrôle d'intégration#
- Mettez en attente la réalisation pour
pending,pending_3ds,processing,authorizingetmanual_review. - Considérez l'authentification et l'acceptation des requêtes comme des preuves intermédiaires, et non comme une confirmation financière.
- Stockez les montants confirmés et les identifiants d'opération à chaque mise à jour de statut.
- Récupérez le paiement principal après un délai ou une réponse tardive du prestataire.
- Utilisez la référence de transition validée lors de la gestion des tentatives ou des chemins de réconciliation qui ne sont pas visibles dans le flux normal.