Vue d'ensemble
PUSH & PAY permet l’émission de demandes de paiements ou de notifications pilotées par des scénarios intelligents interagissant avec les Payeurs, les marchants ou des mails libres par des notifications Push.
Le service Push & Pay repose sur les fonctions Payment Request, Dispute, Transaction ou InstallmentPayment de l’API. Le service est paramétrable depuis l’entrée « Configuration » du Backoffice Centralpay.
Il existe deux types de scénarios, ceux liés aux Payment Request et qui permettent d'émettre des demande de payments ou des notifications de payments, dont le processus est décrit ici et les Scénarios liées au Transaction, Dispute et InstallmentPayment.
Le Push & Pay lié aux Payment Request permet de :
- Définir des scénarios de notification de paiement ou de rappel de paiement
- Créer les modèles d’email ou de SMS correspondants
- Paramétrer les formulaires « Smart Form » associés aux demandes
Ce Push & Pay vous permet ainsi d’intégrer un grand nombre de cas d’usage des plus simples au plus complexes :
Règlement à plusieurs participants
Principes du règlement à plusieurs :
- Chaque participant reçoit une notification e-mail ou SMS détaillant l’objet du service à régler
- Les montants sont fixés par l’initiateur ou laissés libre à chaque participant qui règle le montant souhaité
- Les dates paramétrées à la demande (création, expiration…) permettent de générer des notifications vers chaque participant
Règlements combinés sur plusieurs moyens de paiement
Principes des règlements combinés :
Ce service permet d’utiliser plusieurs moyens de paiement pour régler une opération, par exemple :
- Chèque vacances / carte bancaire
- Cashback FidelyPay / PayPal
- CentralPay réconciliera l’ensemble des opérations pour simplifier le lettrage vers le commerçant une fois l’opération finalisée
- Un client n’est jamais débité partiellement, il doit nécessairement finaliser son processus. Si celui-ci interrompt son règlement, les règlements partiels réalisés sont annulés et le client non débité.
Automatisation des demandes, relances et notifications
Principes des scénarios :
- Les scénarios permettent d’automatiser l’exécution de notification (e-mail, SMS, Webhook) vers les Payeurs selon des actions définies.
- Ils génèrent des demandes de paiement mais interviennent également à des étapes clés d’un processus :
- Notification de demande de paiement
- Récapitulatif de confirmation d’un règlement en X fois
- Notification d’un échec de paiement et fourniture d’un lien pour retenter un paiement
- Relance en cas de dépassement d’un délai de paiement
- …
Les templates des Payment Request
PUSH & PAY fonctionne depuis des modèles d’e-mail ou de SMS. Ces derniers doivent donc être paramétrés avant de pouvoir utiliser le service.
Un template est identifié par son nom et son UUID.
Un template est paramétré avec les éléments suivants :
- Un nom
- Associé à une pièce jointe
- Une entête (header) : en général, un logo
- Un pied de page (footer) : en général une adresse, un lien vers des CGV
- Un corps de document permettant l’interaction avec le contenu d’une "Payment Request" avec des tags insérables dans le texte que vous aurez défini :
- FIRST_NAME : donnée issue du customer
- LAST_NAME : donnée issue du customer
- URL : adresse sécurisée et tokenisée du formulaire de Paiement
- AMOUNT : montant total à regler
- CURRENCY : devise
- DEAD_LINE : date de règlement maximum
- LINK_EXPIRATION_DATE : date de validité du lien de paiement
- DESCRIPTION : description du commerçant
- POS : nom du point de vente
- BREAKDOWN : affiche le contenu de la répartition des montants par participant sous le format suivant :
- JohnDoe@gmail.com : 100,00 Eur
- JaneDoe@yahoo.com : 300,00 Eur
- Liste complete des Tags :
-
#CUSTOMER_FIRSTNAME# >> Prénom du customer
-
#CUSTOMER_LASTNAME# >> Nom du customer
-
#FORM_PAYMENT_REQUEST_URL# >> url du formulaire
-
#MERCHANT_NAME# >> Nom du marchand
-
#MERCHANT_PAYMENT_REQUEST_ID# >> id marchand de la payment request
-
#PAYMENT_REQUEST_CURRENCY# Devise
-
#PAYMENT_REQUEST_BREAKDOWN_AMOUNT_LEFT# >> Montant restant à payer du breakdown
-
#PAYMENT_REQUEST_BREAKDOWN_AMOUNT_PAID# >> Montant payé du breakdown
-
#PAYMENT_REQUEST_BREAKDOWN_UUID#
-
#PAYMENT_REQUEST_DEADLINE# >> Date de validité du paiement
-
#PAYMENT_REQUEST_DESCRIPTION# >> Description
-
#PAYMENT_REQUEST_LINK_EXPIRATION_DATE# >> Date d’expiration du lien
-
#PAYMENT_REQUEST_TOTAL_AMOUNT# >> Montant total
-
#PAYMENT_REQUEST_TOTAL_AMOUNT_LEFT# Montant restant à payer
-
#PAYMENT_REQUEST_TOTAL_AMOUNT_PAID# >> Montant payé
-
#PAYMENT_REQUEST_UUID# >> Identifiant de la requête du paiement
-
#POINT_OF_SALE_NAME# >> Nom du point de vente
-
#MERCHANT_PAYMENT_REQUEST_ID# >> Référence du commerçant
-
#PAYMENT_REQUEST_BREAKDOWN_LIST# >> Détail des breakdowns
-
#PAYMENT_LINK_BUTTON# >> Création d’un bouton avec le lien vers le formulaire
-
Une fois un template créé, il peut être appelé dans l’une des étapes d’un scénario.
Les scénarios des Payment Request
Un scénario permet de créer les étapes définissant les actions à réaliser en interaction avec une "PaymentRequest".
Création d'un scénario
Un scénario est donc un conteneur vierge dans lequel devront s’insérer des étapes.
Création d'une étape
L’étape d’un scénario permet de déclencher une action de notification sur la base d’un événement survenu en interaction avec une "PaymentRequest".
| Date de référence |
|
| Délai |
|
| Type de délai |
|
| Statut de la demande |
|
| Statut du paiement |
|
| Statut du breakdown |
|
| Notification |
|
Scénario de Dispute, Transaction et Installment Payment
Le Scénario est un système qui va vous permettre de créer des règles ainsi que leurs actions et notifications correspondantes, pour vous et pour vos clients. Vous pouvez choisir quand, pourquoi et comment les notifications sont envoyées et les customiser.
Par exemple, vous pouvez créer des règles pour qu’en cas de carte périmée dans un installmentPayment vous soyez alerté de la situation et que votre client soit informé afin qu’il change sa carte. Vous pouvez évidemment également vous envoyer vous même un mail dès qu’une Transaction est cleared et que vous avez reçu l’argent dans votre wallet.
Les Scénarios sont des ensembles de règles qui une fois en place vont entraîner des notifications SMS, Emails ou encore des Hooks personnalisés. Il y a trois types de scénarios qui sont disponibles : “Dispute”, “Transaction” et “Installment Payment”. Ces scénarios dépendent de Templates mis en place au préalable. Une fois les scénarios mis en place, les actions et notifications sont immédiatement actives.
Les Templates
Trois types de templates existent (SMS, Mail ou Hook) et doivent être lié à un type de scénario (Dispute, Transaction ou InstallmentPayment). Il est impossible d’utiliser un template de SMS prévu pour un scénario de Dispute dans un scénario de Transaction. Vous pouvez lier les templates à une ou plusieurs règles qui vont prendre place dans un ou plusieurs scénarios.
Il est nécessaires de prévoir en avance quels types de Templates vont être utiles pour chaque scénario.
Pour manager vos templates :
Les templates de mails
Une entête (header) et un pied de page (footer) sont requis et doivent être créés en amont. L’entête comporte généralement un logo et le pied de page une adresse et un lien vers les CGV. Il est possible de mettre une piece jointe par template de mail.
Un exemple de création d’entête et de pied de page :
Un exemple de création de template d’email :
Les templates de SMS
Seulement le nom de l’expediteur est requis dans ce cas.
Les templates de Hooks
Avant de créer un template de hook, vous pouvez choisir de créer un mode d’authentification afin de sécuriser votre connexion. Ce mode d’authentification a besoin d’un nom, d’un type d’authentification que vous choisirez ainsi que vos login et mot de passe. Vos identifiants sont évidemment protégés.
Exemple de mode d’Authentification :
Vous pouvez créer le template de hook par lui même en sélectionnant un type d’authentification, en metant l’URL auquel le hook va être envoyé et enfin en choisissant le format du hook (JSON, XML ou Text).
Généralités concernant les templates - Les langues
A la création du template, concernant les SMS et les Emails, il va être demandé de choisir une ou plusieurs langues. Selon la langue du receveur, un template dans la langue correspondante sera envoyé. Si la langue n’est pas disponible mais qu’une version Anglaise existe alors la version Anglaise sera envoyé. Sinon la langue définie en premier sera envoyée.
Pour ajouter des langues :
Pour supprimer des langues :
Pour chaque template, un contenu pour chaque langue séléctionnée devra être renseigné. Nous vous recommandons d’utiliser le système de tags dynamiques. Si vous tapez un “#” une liste de tags va apparaitre. Chaque tag sera remplacé par les informations correspondantes dans la Transaction, Dispute ou Installment Payment une fois le hook, le mail ou le sms envoyé.
Vous pouvez regarder le rendu final avec le système de prévisualisation, qui permet de visualiser votre template tel qu’il apparaitra aux clients, avec les tags remplacés par des données fictives.
Il est important de noter que si un problème est constaté concernant les tags à cet instant, ce problème sera aussi présent sur le produit fini.
Le système de Tag est présent dans les trois types de templates (SMS, Mail et Hook).
Un exemple de création de contenu et de prévisualisation :
Les Scénarios
Une fois les templates créés il est possible de créer un scénario. Comme dit précédemment, un scénario est un ensemble de règles. Nous allons donc d’abord créer un scénario puis les règles le composant. Il est possible de créer une ou plusieurs règles par scénario et il est possible d’avoir un ou plusieurs scénarios du même type.
Créer un scénario
Les Règles
Une règle de scénario est composée d’un nom, d’une description, d’une case cliquable nommée “Active” qui permet de rendre la règle active, et de deux parties importantes et plus complexes: le “QUAND” et le “ALORS”.
Le “QUAND” va permettre de definir la règle elle même et le “ALORS” va permettre de choisir les actions effectuées quand la règle va s’appliquer.
Pour créer un règle :
La partie "QUAND" :
Le “QUAND” sera donc l’endroit où la règle sera definie. Le système repond à une grammaire précise. Un système d’attributs est également intégré. Si vous tapez un “#” la liste des attributs possible apparaitra. Il est possible d’ajouter des conditions avec “AND” et “OR”, une fois la première condition écrite.
Tous les opérateurs logiques disponibles sont :
Pour les chaînes de caractères :
= (égal à)
!= (différent de)
in (dans ce qui va suivre)
not in (pas dans ce qui va suivre)
Il est important de noter que chaque chaîne de caractère doit être encadrée de guillemets " ".
Pour un nombre :
= (égal à)
!= (différent de)
< (plus petit que)
> (plus grand que)
<= (plus petit ou égal à)
>= (plus grand ou égal à)
in (dans ce qui va suivre)
not in (pas dans ce qui va suivre)
Pour une boolean (une affirmation en vrai ou faux) :
= (égal à)
!= (différent de)
Il est nécessaire d’encadrer ce qui suit les IN et NOT IN de parenthèses. Il est possible de mettre plusieurs données dans ces parenthèses si elles sont séparées par des virgules.
Il est possible de donner des priorités en mettant des parenthèses autour des conditions. Si vous utilisez les conditionnels AND et OR dans la même règle, il est nécessaire de prioriser. Si vous utilisez plusieurs fois AND et OR, il est nécessaire de prioriser chaque partie.
Des exemples de règles :
#end_user_country in ('FRA', 'BE')
#authorisation_status = 'FAILURE' or (#transaction_amount > 100000 and #context = 'TRANSACTION_RISKY' )
#transaction_amount > 100000 and ( #authorisation_status = 'FAILURE' or #context = 'TRANSACTION_RISKY' )
((#transaction_amount > 100000 and #context = 'TRANSACTION_RISKY') or ( #authorisation_status = 'FAILURE' and #transaction_amount < 100000 )) and (#card_product_type = 'Consumer')
Avant de pouvoir enregistrer une régle il est nécessaire de tester sa règle avec le bouton adéquat. Cela va permettre de vérifier que votre règle est grammaticalement correcte selon notre programme et qu’elle va s’appliquer correctement. Il est impossible d’enregistrer une règle sans cela.
Un exemple de règle correcte :
La partie "ALORS" :
Enfin le “ALORS” va permettre de choisir quelle action est effectuée et quel template sera envoyé une fois la règle appliquée. Vous n’avez accès qu’aux templates qui correspondent au type de template requis (SMS, Email, Hook) et qui correspond au type de scénario choisi (Dispute , Transaction, Installment Payment).
Exemple de choix de template puis de création d’une règle :
Les règles communes
Certaines règles sont générales et appliquées à tous nos acteurs. Nous vous invitons à consulter ces règles dans votre espace protégé, dans l’onglet Notification. Il est possible de se désabonner de certaines règles, elle comporteront alors une case cliquable à côté d’elles.
