MPR - Remboursements partiels multiples

Les remboursements partiels multiples (MPR) permettent à un commerçant de soumettre plusieurs demandes de remboursement partiel, tandis que DEUNA envoie un remboursement accumulé au processeur. Il s'agit du mode de compatibilité géré par DEUNA pour les connexions qui ne peuvent pas recevoir plusieurs opérations de remboursement ou pour lesquelles le traitement des remboursements nécessite une agrégation.

Le MPR est configuré par connexion au processeur. Il est différent des remboursements multiples natifs : avec un support natif, chaque remboursement éligible peut être envoyé au processeur indépendamment ; avec le MPR, les demandes non finales restent en attente dans DEUNA jusqu'à la fin de la séquence.

Cycle de vie du MPRInterroger Athia à ce sujet#

1. Commencez à partir d'un paiement avec un montant remboursable confirmé, par exemple processed, captured, ou partial_captured.
2. Soumettez un montant de remboursement partiel.
3. DEUNA valide la demande par rapport au solde remboursable cumulé et la met en attente sans appeler le processeur.
4. Pendant que plusieurs montants de remboursement sont en attente, le paiement est partial_refunding.
5. DEUNA termine la séquence lorsque l'une des conditions suivantes se produit :
   • Le montant total demandé atteint le montant remboursable total.
   • Une demande inclut "final_refund": true.
   • La limite de remboursement enregistrée est atteinte.
6. DEUNA envoie le montant accumulé en attente au processeur en tant qu'une seule opération de remboursement.
7. Si le montant confirmé correspond au solde intégralement remboursable, le paiement devient refunded. Si le montant retourné ne correspond qu'à une partie de ce solde, le paiement devient partial_refunded.

Une demande en attente enregistre l'intention de remboursement ; elle ne prouve pas que les fonds ont été remboursés au client.

Délai de remboursement et limites de tempsInterroger Athia à ce sujet#

Le MPR a les règles suivantes pour le remboursement :

• Configurez un nombre entier de 1 à 45 jours calendaires.
• La minuterie démarre lorsque la première demande de remboursement non finale est enregistrée.
• DEUNA enregistre la date limite absolue dans refund_cutoff_at . Les remboursements partiels ultérieurs ne la prolongent ni ne la réinitialisent.
• La limite est la fin du jour calendaire cible, et non le même moment de la journée après un certain nombre de jours.
• La modification de la configuration de connexion ne remet pas à zéro une date d'échéance déjà enregistrée pour un paiement existant.
• Lorsque la limite enregistrée est atteinte, le paiement devient éligible pour que le travailleur de limite soumette le remboursement accumulé. Le traitement n'est pas garanti au moment exact de la fin de la journée, de sorte qu'il ne faut pas compter sur une période de grâce pour un autre remboursement.

Par exemple, avec une limite d'un jour, une première demande de remboursement non finale enregistrée le lundi est éligible au traitement de la limite après la fin du mardi. Elle n'est pas programmée pour le même moment le mardi.

Fermer la séquence via l'APIInterroger Athia à ce sujet#

Utilisez final_refund pour soumettre la demande actuelle et tous les montants accumulés sans attendre que la limite soit atteinte. Envoyez-la sous forme de JSON booléen :

{
  "amount": 100,
  "reason": "Item returned",
  "final_refund": true
}

Atteindre le solde intégralement remboursable ferme automatiquement la séquence ; final_refund Ce champ n'est pas requis dans ce cas.

Règles concernant le montant et la séquenceInterroger Athia à ce sujet#

• Le montant total demandé de remboursement ne peut pas dépasser le solde confirmé remboursable.
• DEUNA inclut les remboursements précédents en attente lors de la validation de chaque nouvelle demande.
• Une opération de remboursement finale ferme la séquence MPR. Les demandes de remboursement ultérieures pour cette séquence sont rejetées.
• DEUNA n'impose pas de limite de nombre de demandes pour les demandes MPR en attente. Le solde remboursable et la limite de temps sont les limites effectives de la plateforme.
• Ne calculez pas le solde restant uniquement à partir de la dernière réponse. Utilisez la dernière transaction, son historique d'opérations et les montants confirmés, en particulier lorsque les demandes peuvent se chevaucher.
• Si l'opération de capture est toujours en attente, l'éligibilité au remboursement est spécifique à la connexion. Ne remboursez pas un montant non confirmé, sauf si DEUNA a approuvé un comportement de capture et de remboursement simultané pour cette connexion.

Gestion des statuts et des erreursInterroger Athia à ce sujet#

Si le traitement est interrompu ou l'appel au processeur échoue, ne marquez pas le paiement comme remboursé localement. DEUNA peut réessayer les opérations de coupure éligibles, tandis que des échecs non résolus répétés nécessitent une revue opérationnelle. Récupérez le paiement et consommez les webhooks jusqu'à ce que l'opération atteigne un statut confirmé. Un délai d'attente seul ne constitue pas un résultat de remboursement final.

Pour le tableau de transition complet, voir Flux de travail et statuts de paiement. Pour les requêtes concurrentes, voir Capture et remboursement simultanés.

Configurer MPRInterroger Athia à ce sujet#

Travaillez avec votre représentant technique DEUNA pour configurer la connexion :

Dans l'administration, utilisez les détails de la commande et l'historique des opérations de remboursement pour surveiller les demandes en attente, le montant total remboursé, le solde restant remboursable et la coupure prévue, si disponible.

MPC et MPR peuvent être activés sur la même connexion. Leurs coupures de capture et de remboursement sont indépendantes ; la modification de l'une n'affecte pas l'autre.