Quand un paiement échoue : journaux, alertes et récupération
Les paiements échouent pour des raisons ordinaires (une carte refusée, un compte bancaire vide, un numéro mal saisi) et parfois pour des raisons techniques. REDA Pay consigne chaque échec à un endroit précis et prévient une personne précise. Cet article associe chaque échec à l’endroit où il est consigné, à l’alerte qu’il déclenche et au chemin pour revenir à la normale.
Où les échecs sont consignés
| Échec | Consigné sous forme de | Qui est prévenu |
|---|---|---|
| Un paiement à l’écran est refusé ou rejeté | Une Pay Transaction au Status failed avec la raison dans Error Message, sous l’ordre ; l’ordre reste Not Processed | La personne devant l’écran, immédiatement |
| Un lien de paiement échoue lorsque le client paie | Idem, et l’ordre reste Link - Active | Le propriétaire de l’ordre : notification dans l’application « Payment Link [P-000000] failed. » |
| Une exécution planifiée échoue | Une transaction en échec sous l’ordre enfant généré | Le propriétaire de la planification : « Scheduled Payment [P-000000] failed. » ; plus un REDA Pay Log pour l’exécution |
| La connexion à Payload a été interrompue en plein paiement | Une transaction en échec avec Process Callout Exception coché ; le payeur voit le message « unexpected exception » avec un code | La tâche de récupération des paiements échoués la répare ; consultez Activer la récupération des paiements échoués |
| Une tâche d’arrière-plan a rencontré des erreurs (planifications, synchronisations, relevés, mises à jour de clients) | Un REDA Pay Log avec Attention Needed coché et les échecs joints dans un fichier CSV | Tous les utilisateurs actifs qui reçoivent les e-mails d’administration Salesforce, plus le propriétaire de la tâche, par e-mail |
| Un paiement bancaire est rejeté quelques jours plus tard | Le Status de la transaction passe à rejected avec une Rejected Date | Personne par défaut ; consultez Litiges et paiements rejetés |
| Le nom, l’e-mail ou le téléphone d’un client n’a pas pu être envoyé à Payload | Sync Error Message sur le Pay Customer | Personne ; visible sur l’enregistrement |
Lire une transaction en échec
Ouvrez le Pay Order et regardez ses Pay Transactions. Une tentative échouée comporte :
| Champ | Ce qu’il faut lire |
|---|---|
| Status | failed |
| Error Message | La raison donnée par Payload, au format « type d’erreur : description » ; par exemple une carte refusée, un routing number invalide, ou une règle client comme « Payments are not allowed at this time for this customer. » |
| Process Callout Exception | Coché lorsque la connexion a été interrompue : le résultat est inconnu jusqu’à l’exécution de la tâche de récupération |
| Created Date | Le moment de la tentative |
L’ordre lui-même n’est pas modifié et peut être payé de nouveau depuis l’enregistrement avec un autre moyen.
Une tentative échouée à côté de la nouvelle tentative réussie. L’enregistrement échoué reste pour la piste d’audit.
REDA Pay Logs
Chaque tâche d’arrière-plan qui rencontre une erreur écrit un REDA Pay Log (RPL-000000) :
| Champ | Signification |
|---|---|
| Process | Quelle tâche : ordres planifiés, synchronisation des transactions, traitement des relevés, transactions manquantes, mise à jour des clients |
| Start / End Datetime, Total Records, Success Records, Failed Records | Les chiffres de l’exécution |
| Exception | Le texte de l’erreur lorsque la tâche elle-même a échoué |
| Attention Needed | Coché tant que des échecs n’ont pas été traités |
| Resolved Date Time | Renseignez-le une fois le journal traité ; il quitte la vue Attention Needed |
| Notes & Attachments | Un fichier CSV qui liste chaque enregistrement en échec avec son erreur ; téléchargez-le pour voir quels ordres ou quelles transactions sont concernés |
Lorsqu’un journal est créé avec des échecs, REDA Pay envoie un e-mail à tous les utilisateurs actifs qui reçoivent les e-mails d’administration et au propriétaire de la tâche. L’objet est « RPL-000000 - processus - System Asynchronous Automation Exception » et le corps commence par « ATTENTION NEEDED », avec un lien vers le journal.
L’application REDA Pay a un onglet REDA Pay Logs avec les vues Attention Needed, Created Today et All ; le tableau de bord REDA Pay Admin affiche le nombre de journaux à traiter.
La vue Attention Needed est la vérification quotidienne de la personne responsable des opérations de paiement.
Récupération, selon la situation
| Situation | Faites ceci |
|---|---|
| Paiement par carte ou bancaire refusé | Encaissez de nouveau avec un autre moyen. La transaction échouée reste dans l’historique |
| Une règle client l’a bloqué (« not allowed for this customer », « pay method type is not allowed… ») | Corrigez les moyens autorisés ou le type de transfert du Pay Customer (consultez Règles par client), puis payez de nouveau |
| Payeur débité mais Salesforce affiche une tentative échouée avec Process Callout Exception | Attendez la tâche de récupération (toutes les 15 minutes), ou ouvrez l’ordre et appuyez sur Sync Transaction pour récupérer tout de suite l’enregistrement Payload. Ne retraitez pas l’ordre |
| Le statut d’une transaction semble périmé | Sync Transaction sur la transaction (ou sur l’ordre, pour toutes) la relit chez Payload |
| Une exécution planifiée a échoué | Encaissez le montant manquant par un paiement ponctuel ; la planification continue à sa prochaine date. Si le moyen n’est plus valable, remplacez-le ; consultez Configurer un paiement récurrent |
| Un journal signale de nombreux échecs d’une même tâche | Ouvrez le CSV, corrigez la cause commune (un compte inactif, un moyen supprimé, une autorisation manquante), puis renseignez le Resolved Date Time |
| Statement Activity bloquée en In Process | Utilisez Reprocess ; consultez Rapprocher les dépôts et les versements |
Sync Transaction
Sur une Pay Transaction : cliquez sur Sync Transaction, puis sur Sync. REDA Pay relit cette transaction chez Payload et met à jour le statut, le code de statut, le statut de financement et les dates. Sur un Pay Order : la même action demande à Payload toutes les transactions marquées avec l’ordre, met à jour celles que Salesforce possède et crée celles qui manquent ; c’est la version manuelle de la tâche de récupération, sans la limite d’une heure.
Messages d’erreur avec détail technique
Par défaut, REDA Pay affiche le détail technique d’une erreur (numéros de ligne et trace de pile) après le message, car le commutateur d’organisation ERROR_STACK_TRACE est livré à TRUE. Ce détail aide le support mais n’a sa place sur l’écran d’aucun client. Avant la mise en production, passez-le à FALSE ; consultez Paramètres d’organisation et messages d’erreur.
Erreurs à éviter
| Erreur | Ce qui se passe | Correction |
|---|---|---|
| Retraiter un ordre après le message « unexpected exception » | Un second débit | Synchronisez d’abord ; regardez les transactions |
| Ignorer les e-mails Attention Needed | Les exécutions planifiées échouées et les erreurs de synchronisation s’accumulent sans être vues | Confiez la vérification quotidienne à une personne |
| Supprimer les transactions échouées « pour faire le ménage » | La piste d’audit de la tentative est perdue ; les transactions qui ont des remboursements ne peuvent de toute façon pas être supprimées | Laissez-les |
| Laisser des tentatives Process Callout Exception plus d’une heure | La tâche de récupération ne les prend plus en charge | Utilisez Sync Transaction sur l’ordre |
Questions fréquentes
Non. REDA Pay n’envoie pas d’e-mail aux payeurs. Le payeur voit le résultat à l’écran ; votre propre automatisation peut lui envoyer un e-mail à partir de la transaction échouée.
Tous les utilisateurs actifs configurés pour recevoir les e-mails d’administrateur Salesforce, plus le propriétaire de la tâche qui a échoué.
Créez un flux sur REDA Pay Log (lorsque Attention Needed devient vrai) qui publie où vous le souhaitez.