Capture et remboursement simultanés

DEUNA peut sérialiser les demandes de capture ou de remboursement se chevauchant pour la même transaction sur les flux pris en charge. La sérialisation protège le calcul du solde cumulatif : après qu'une demande met à jour la transaction, la demande suivante est validée par rapport au nouveau solde.

Quelles sont les garanties de sérialisation ?Interroger Athia à ce sujet#

Pour un flux activé par la concurrence, DEUNA traite la section modifiant le solde de chaque demande séquentiellement pour la même transaction. Cela empêche deux demandes se chevauchant de valider toutes deux contre le même solde obsolète.

La sérialisation ne garantit pas que toutes les demandes se chevauchant réussissent. Après que la première demande a été appliquée, une demande ultérieure peut être rejetée car :

• Le montant dépasserait le solde restant disponible pour la capture ou le remboursement.
• Le traitement de coupure a déjà finalisé la séquence MPC ou MPR.
• Une demande antérieure a finalisé la séquence de capture ou de remboursement.
• L'état de la transaction ne permet plus l'opération.
• Le processeur ou la connexion ne prennent pas en charge l'opération partielle demandée.

Les demandes pour différentes transactions peuvent toujours être traitées indépendamment.

Instructions d'intégration pour le commerçantInterroger Athia à ce sujet#

• Utilisez les points de terminaison de capture et de remboursement existants ; il n'existe pas de point de terminaison de concurrence séparé.
• Attribuez une identité unique à chaque opération prévue. Une tentative de reprise par le client et une deuxième opération financière ne sont pas les mêmes.
• Ne calculez pas le montant suivant à partir d'un statut en cache ou d'une seule réponse. Récupérez la dernière transaction et réglez son historique d'opérations.
• Considérez partial_capturing, capturing, partial_refundinget refunding dans des états non résolus.
• Traitez les webhooks de manière idempotente et stockez les identifiants d'opération et les montants, et non seulement le statut de paiement.
• Si deux requêtes se chevauchent, traitez un rejet de solde, de limite, de dernière opération ou de statut invalide comme un résultat de validation autoritaire. Ne le relancez pas comme une nouvelle opération financière sans d'abord récupérer le paiement.

Portée et limitesInterroger Athia à ce sujet#

Ce comportement s'applique aux flux de capture et de remboursement pris en charge. Il ne fait pas que les demandes d'autorisation ou d'annulation font partie de la même séquence partielle.

Les appels au processeur peuvent toujours être asynchrones. La sérialisation protège la mise à jour du solde de DEUNA, mais elle ne peut pas transformer un délai d'attente du processeur ou une réponse en attente en un résultat final immédiat. Attendez un statut confirmé avant de procéder à la finalisation ou de communiquer avec le client.

Pour la consolidation et les limites de capture, voir MPC — Captures partielles multiples. Pour la consolidation et les limites de remboursement, voir RPM — Remboursements partiels multiples.