Comment les statuts de paiement restent à jour
L’encaissement d’un paiement est le début de sa vie, pas la fin. Un paiement bancaire accepté aujourd’hui peut être rejeté trois jours plus tard ; un paiement par carte peut être remboursé depuis le tableau de bord Payload ; l’argent arrive sur votre compte bancaire par lots. REDA Pay apprend tout cela grâce aux webhooks (des messages que Payload envoie à votre organisation lorsqu’il se passe quelque chose) et met à jour les enregistrements sans que personne n’appuie sur un bouton. Cet article explique ce qui arrive, ce que cela modifie et que faire quand rien n’arrive.
Les dix événements
| Événement Payload | Ce qu’il signifie | Ce que fait REDA Pay |
|---|---|---|
| payment | Une transaction de paiement a été créée | Relit la transaction et met à jour la Pay Transaction |
| processed | Une transaction a été traitée | Idem |
| authorized | Un montant de carte a été autorisé | Idem |
| credit | Une transaction de versement (décaissement) a été créée | Idem |
| refund | Un remboursement a été effectué, à l’écran ou dans le tableau de bord Payload | Idem ; un remboursement effectué hors de Salesforce apparaît comme une mise à jour de transaction |
| void | Une transaction a été annulée | Idem |
| decline | Une transaction a été refusée | Idem |
| reject | Un paiement bancaire a été retourné après acceptation | Idem : la Pay Transaction passe à rejected avec une Rejected Date |
| deposit | Payload a déposé des fonds sur votre compte bancaire | Crée ou actualise une Statement Activity de type Deposit et liste les paiements qu’elle contient |
| reversal | Payload a retiré des fonds de votre compte bancaire (versements, remboursements) | Crée ou actualise une Statement Activity de type Payout |
Pour chaque événement, sauf deposit et reversal, REDA Pay fait une seule chose : il prend l’identifiant de transaction du message et relit l’intégralité de la transaction chez Payload, puis enregistre ce que Payload renvoie (statut, code de statut, statut de financement, montants, dates). Le contenu du message n’est jamais écrit directement dans un enregistrement : un statut dans Salesforce reflète donc toujours ce que détient Payload. Un message concernant une transaction que Salesforce n’a jamais vue est ignoré.
Dix événements, un par ligne. Si l’onglet en affiche moins, exécutez de nouveau Setup Webhooks.
Ce qui change sur les enregistrements
| Enregistrement | Champs qui changent | Déclenché par |
|---|---|---|
| Pay Transaction | Status, Status Code, Status Message, Funding Status, Processed Date, Rejected Date, Voided Date, montants | payment, processed, authorized, credit, refund, void, decline, reject |
| Statement Activity et ses Transaction Activities | Créées avec Statement Amount, Type, Reference Number, Logged Datetime ; lignes reliées aux Pay Transactions | deposit, reversal |
| Pay Order | Rien. Le statut de l’ordre reflète le traitement effectué à l’écran ou par la tâche ; les changements ultérieurs se trouvent sur la transaction | — |
Le traitement des webhooks s’exécute en arrière-plan, par petits lots, quelques minutes après l’événement. Les erreurs sont écrites dans un REDA Pay Log.
Exemple pratique : la vie d’un paiement bancaire
| Jour | Événement | Ce qui change dans Salesforce |
|---|---|---|
| Lun 10:00 | Un résident paie 1 251,75 $ dans le portail | Pay Order P-052010 Immediate - Processed ; T-0014610 processed, Funding Status pending |
| Lun 10:01 | Payload envoie payment et processed | REDA Pay relit T-0014610 : aucun changement visible, elle était déjà à jour |
| Mar 02:00 | Payload regroupe en lot les paiements bancaires du jour pour financement | Au prochain événement ou à la prochaine synchronisation, le Funding Status indique batched |
| Mer 09:00 | Payload envoie deposit pour le lot de mardi | La Statement Activity S-0000931:2026-11 est créée, de type Deposit, avec une ligne Transaction Activity reliée à T-0014610 ; Status Completed, Good To Reconcile |
| Jeu 15:00 | La banque du résident retourne le paiement : Payload envoie reject | T-0014610 passe à rejected, Rejected Date jeudi ; P-052010 ne change pas |
| Ven 09:00 | Payload envoie reversal pour les fonds retournés | Une Statement Activity de type Payout consigne la sortie de l’argent de votre compte |
Sans webhooks, Salesforce afficherait toujours le paiement comme traité, et le dépôt n’apparaîtrait jamais.
Ce que ne fait jamais un webhook
| Un webhook ne fait jamais ceci | Parce que |
|---|---|
| Modifier un Pay Order | Les ordres consignent votre instruction ; les résultats se trouvent sur les transactions et les relevés |
| Créer un paiement pour un ordre que Salesforce ne connaît pas | Les transactions inconnues sont ignorées ; le rapprochement peut créer délibérément celles qui manquent |
| Écrire les données du message lui-même dans un enregistrement | REDA Pay relit toujours chez Payload : un message mal formé ou périmé ne peut pas corrompre un enregistrement |
| Envoyer quoi que ce soit à vos clients | Les notifications sont internes, destinées aux propriétaires des ordres |
Comment vérifier que cela fonctionne
| Vérification | Où |
|---|---|
| Les transactions changent de statut sans synchronisation manuelle | Ouvrez un paiement bancaire récent quelques jours plus tard : Funding Status batched, puis une Statement Activity qui le cite |
| Les dépôts arrivent | Statement Activities → In Process / Pending Reconciliation se remplissent après chaque dépôt de Payload |
| Erreurs | REDA Pay Logs → Attention Needed |
| L’enregistrement existe toujours | Pay Profile → onglet Webhook Setup, dix lignes ; Webhook Setup Datetime [Payload] sur le profil |
Le recours manuel : Sync Transaction
Toute transaction peut être actualisée à la demande :
- Sur une Pay Transaction : Sync Transaction → Sync relit cette transaction.
- Sur un Pay Order : Sync Transaction → Sync demande à Payload toutes les transactions marquées avec l’ordre, met à jour celles que Salesforce possède et crée celles qui manquent.
Utilisez-le lorsqu’un statut semble périmé, lorsqu’un client dit avoir payé sans qu’aucune transaction n’apparaisse, ou pendant les premiers jours, avant que les webhooks ne soient vérifiés. Il fait exactement ce qu’aurait fait un webhook.
Erreurs à éviter
| Erreur | Ce qui se passe | Correction |
|---|---|---|
| Fonctionner sans webhooks en production | Les rejets, les remboursements effectués dans Payload et les dépôts n’arrivent jamais dans Salesforce | Configurez-les avant la mise en production |
| Remplacer la clé API sans réenregistrer | Les webhooks restent enregistrés sous l’ancienne clé et n’arrivent plus | Exécutez de nouveau Setup Webhooks |
| S’attendre à ce que le statut de l’ordre change lors d’un rejet | La transaction change ; l’ordre reste Processed | Faites vos rapports de recouvrement sur le statut des transactions |
| Modifier à la main le statut d’une transaction | Le prochain webhook ou la prochaine synchronisation l’écrase avec la vérité de Payload | Laissez les statuts à REDA Pay ; utilisez les Internal Comments pour vos notes |
Questions fréquentes
Payload envoie le message au moment de l’événement ; REDA Pay le traite en quelques minutes.
Créez un flux sur Pay Transaction qui se déclenche lorsque le Status passe à rejected ; consultez Automatiser les paiements avec des flux.
Oui, par l’événement refund : la transaction d’origine est relue et une transaction de remboursement est créée ou mise à jour sous l’ordre.