Automatiser les paiements avec des flux

Tout ce que fait l’écran de paiement repose sur des enregistrements : Salesforce Flow peut donc le piloter aussi. Une automatisation peut créer un Pay Order et le faire traiter par REDA Pay en arrière-plan, payer un propriétaire lorsqu’un relevé est publié, envoyer par e-mail un lien de paiement dès sa création, ou alerter la finance lorsqu’un paiement est rejeté. Cet article liste les points d’accroche que REDA Pay offre aux flux et les règles de chacun. Aucun code n’est nécessaire ; pour Apex, consultez API Apex pour les développeurs.

Point 1 — Process Pay Order : débiter un ordre créé par une automatisation

Un Pay Order enregistré avec la case Process Pay Order cochée est traité par REDA Pay en arrière-plan, exactement comme si l’on avait appuyé sur Pay à l’écran. L’ordre doit être complet et valide :

Enregistrez l’enregistrement ; un lot démarre en quelques instants et l’ordre reçoit sa Pay Transaction et son Processed Datetime. Si l’ordre est déjà traité, l’enregistrement avec l’indicateur est refusé avec « Pay Order is already processed. » Un échec produit une transaction failed sous l’ordre, comme un paiement échoué à l’écran. Les frais sont calculés à partir des Fee Setups du compte à l’enregistrement, comme à l’écran.

Marquez un ordre par opération. Le traitement en arrière-plan est conçu pour des enregistrements uniques : marquez les ordres un par un (une interview de flux, un enregistrement), pas en masse depuis un chargement de données. Marquer de nombreux ordres en un seul enregistrement n’est pas pris en charge dans cette version.

Un modèle de flux : un flux déclenché par un enregistrement sur votre enregistrement de facturation (une facture, un débit, un relevé de propriétaire) qui, à l’échéance, utilise un élément Get Records (obtenir des enregistrements) pour trouver le Pay Customer du compte, un autre pour trouver le Default Pay Method du client, un élément Create Records (créer des enregistrements) pour créer un Pay Order avec les champs ci-dessus, et définit Process Pay Order sur vrai.

Point 2 — Default Pay Method (Disbursement) : savoir où verser

REDA Pay tient le Default Pay Method (Disbursement) du compte, du contact et de la piste à jour avec le moyen par défaut du Pay Customer chaque fois que le client est autorisé aux décaissements. Un flux de versement lit cette recherche sur le compte, vérifie qu’elle n’est pas vide et l’utilise comme Pay Method du Pay Order. Les fournisseurs la renseignent eux-mêmes via Demander ses coordonnées bancaires à un fournisseur.

Point 3 — Attribute 1–4 : transporter votre référence

Les ordres ont quatre champs texte libres Attribute, définis par les paramètres du composant de paiement ou par les paramètres d’URL rpay__att1 à rpay__att4, et par votre flux lorsqu’il crée l’ordre. Utilisez-les pour transporter le numéro de facture, le bail, le bien ou le type de débit, afin qu’un flux sur la Pay Transaction résultante sache ce qui a été payé.

Point 4 — Flux déclenchés par un enregistrement sur les enregistrements REDA Pay

Les enregistrements changent de façon prévisible ; construisez des flux dessus :

Lorsqu’un flux lit les Attribute 1–4 ou le compte, le contact et la piste liés à l’ordre, il sait à quoi correspondait le paiement.

Point 5 — L’action Update Payload Customer

Flow Builder propose une action nommée Update Payload Customer (une action Apex du package REDA Pay). Transmettez-lui un Id de Pay Customer : elle envoie à Payload le nom, l’e-mail et le téléphone actuels du client et enregistre l’identifiant client de Payload s’il manquait. Le propre flux de REDA Pay l’appelle lorsque les données d’un client changent ; appelez-la depuis votre flux après avoir mis à jour un Pay Customer par automatisation.

Les flux de REDA Pay peuvent être remplacés

Les quinze flux de REDA Pay (valeurs par défaut des nouveaux ordres, choix des frais, activation des liens, création des clients à partir d’un enregistrement parent, propagation du moyen par défaut, notifications, écrans de révocation et d’ajout de moyen) sont marqués comme remplaçables. Un administrateur peut en désactiver un et le remplacer par sa propre version, par exemple pour envoyer une autre notification. Ne le faites qu’en cas de besoin ; une mise à niveau de REDA Pay n’annule pas votre remplacement : c’est donc à vous de réconcilier les changements après chaque mise à niveau.

Exemple pratique : payer les propriétaires le 5

Un gestionnaire immobilier verse à chaque propriétaire son revenu net le 5 de chaque mois.

1. Un flux planifié s’exécute le 5 sur les enregistrements Owner Statement dont le solde est positif.
2. Pour chacun : trouver le compte du propriétaire ; s’arrêter si le Default Pay Method (Disbursement) est vide (en créant une tâche pour demander les coordonnées bancaires) ; trouver le Pay Customer du compte sur le profil.
3. Créer un Pay Order : Pay Profile, Pay Customer, Processing Account (le compte d’exploitation), Pay Method (le moyen de décaissement par défaut), Transfer Type Disbursement, Order Type Immediate, Principal Amount = solde, Attribute 1 = le numéro du relevé, Process Pay Order = vrai.
4. Un second flux sur Pay Transaction (Status processed, Type credit) marque le relevé comme payé grâce à l’Attribute 1.

Comme il s’agit de décaissements, le flux s’exécute sous un utilisateur dont REDA Pay - Enable Disbursements est coché.

Erreurs à éviter

Questions fréquentes

Pour aller plus loin

• API Apex pour les développeurs
• Envoyer un décaissement