Overall view
PUSH & PAY allows issuance of payment requests driven by smart scenarios interacting with payers through “Push” notifications.
Push & Pay service is based on paymentRequest API function. The service is configurable from “Configuration” entry in CentralPay BackOffice.
It allows to :
- Define payment notification scenarios or payment reminder
- Create related email or SMS models
- Configure Smart Forms that will be integrate into payment claims
Push & Pay allows you to integrate a large number of use cases from the simplest to the most complex :
Multi-participants payments
Principles of multi-participants payments :
- Each participant receives an e-mail or SMS notification detailing the subject of the service to pay
- Amounts are set by the initiator or left free to each participant who pays the desired amount
- The dates configured on request (creation, expiry...) allow to generate notifications to each participant
Combined payments on several payment methods
Principles of combined payments :
This service allows to use several payment methods to settle a transaction, for example :
- Holiday voucher / credit card
- Cashback FidelyPay / PayPal
- CentralPay will reconcile all transactions to simplify the lettering sent to the merchant once the transaction is finalized
- A customer is never partially debited, he must necessarily finalize his process. If the customer interrupts his payment, the partial payments made are cancelled and the customer is not debited
Automation of requests, reminders and notifications
Principles of scenarios :
- The scenarios allow to automate execution of notifications (e-mail, SMS, Webhook) to payors according to defined actions.
- They generate payment claims but also intervene at key stages of a process :
- Notification of payment request
- Confirmation summary of payment in installments
- Payment failure notification and supplying of link to re-attempt payment
- Reminder in case of exceeding payment deadline
- …
Payment Request Templates
PUSH & PAY works from email or SMS models. These models must be configured before using the service.
A template is identified by its name and its UUID.
A template is configured with the following elements :
- A name
- Associated to an attached document
- A header : generally a logo
- A footer : generally an adress, a link to General Terms of Sales
- A body of document allowing interaction with the "Payment Request" content with tags integrable in the text that you will have defined.
- FIRST_NAME : data from Customer
- LAST_NAME : data from Customer
- URL : secure and tokenized payment form address
- AMOUNT : total amount to pay
- CURRENCY : currency
- DEAD_LINE : payment deadline
- LINK_EXPIRATION_DATE : payment link validity date
- DESCRIPTION : merchant description
- POS : point of sales name
- BREAKDOWN : displays amount repartition per participant in the following format :
- JohnDoe@gmail.com : 100,00 Eur
- JaneDoe@yahoo.com : 300,00 Eur
- Complete Tag list :
-
#CUSTOMER_FIRSTNAME# >> Customer Firstname
-
#CUSTOMER_LASTNAME# >> Customer Lastname
-
#FORM_PAYMENT_REQUEST_URL# >> Form URL
-
#MERCHANT_NAME# >> Merchant name
-
#MERCHANT_PAYMENT_REQUEST_ID# >> Payment request's MerchantID
-
#PAYMENT_REQUEST_CURRENCY# Payment request currency
-
#PAYMENT_REQUEST_BREAKDOWN_AMOUNT_LEFT# >> Breakdown amount to pay
-
#PAYMENT_REQUEST_BREAKDOWN_AMOUNT_PAID# >> Breakdown amount paid
-
#PAYMENT_REQUEST_BREAKDOWN_UUID#
-
#PAYMENT_REQUEST_DEADLINE# >> Payment request deadline
-
#PAYMENT_REQUEST_DESCRIPTION# >> Description
-
#PAYMENT_REQUEST_LINK_EXPIRATION_DATE# >> Link expiration date
-
#PAYMENT_REQUEST_TOTAL_AMOUNT# >> Total amount
-
#PAYMENT_REQUEST_TOTAL_AMOUNT_LEFT# Amount left to pay
-
#PAYMENT_REQUEST_TOTAL_AMOUNT_PAID# >> Amount paid
-
#PAYMENT_REQUEST_UUID# >> Payment request ID
-
#POINT_OF_SALE_NAME# >> Point of sale name
-
#MERCHANT_PAYMENT_REQUEST_ID# >> Merchant ID
-
#PAYMENT_REQUEST_BREAKDOWN_LIST# >> Breakdown details
-
#PAYMENT_LINK_BUTTON# >> Creation of a button linked to the form
-
Once a template has been created, it can be called in one of the stages of a scenario.
Payment Request Scenarios
A scenario allows to create steps defining the actions to be carried out in interaction with a "PaymentRequest".
Scenario creation
A scenario is a blank container in which steps must be inserted.
Step creation
Steps of a scenario allows to trigger a notification action on the basis of an event occurring in interaction with a "PaymentRequest".
| Reference date |
|
| Delay |
|
| Type of delay |
|
| Request status |
|
| Payment status |
|
| Breakdown status |
|
| Notification |
|
Transaction, Dispute and Installment Scenarios
The Scenario is a system that will allow you to create your own set of rules and ensuing actions and notifications for you and your customer. You can choose when, why and how the notifications are sent, and customize it.
For example you can create rules for when an expired card is used in an installmentPayment, to inform your customers they need to change their card accordingly and alert yourself of the situation. But you can also send to yourself an email when the transaction is finished and cleared.
The scenarios are a set of rules, which will bring a chosen notification as an SMS, an Email or the sent of Hooks. The different types of scenarios possible are related to “Dispute”, “Transaction” or “Installment Payment” and each type has its own possible set of rules. Scenarios are dependent of templates created in advance. Once the scenario created, the notification system is immediately set in motion.
The Templates
Three types of templates exist (SMS, Email, Hook), and must be linked to one type of scenario (“Dispute”, “Transaction” or “Installment Payment”). You cannot use an SMS template for Transaction in a Dispute scenario. In the end, a template will be linked to one or more specific rules within one or more scenario.
It's necessary to foresee what kind of templates you will need for each set of rules created.
To manage your templates :
The Email Templates
A header (generally a logo) and a footer (generally an address and a link to the Terms and Conditions) is required to create an Email template and must be created upstream. It is possible to add an attachement to the Email template.
An example of creation of a header and a footer :
And an exemple of creation of Email template :
The SMS templates
Only the name of the sender is required in this case.
The Hooks templates
In the beginning, you can create an Authentication mode that will help you to have a securised connection. If you choose so : you must enquire a name, choose a type of authentication then add your login and password. Your password and login will be stored in a securised space.
An example of creation of an authentication :
Then, at the creation of the template, you can chose an authentication mode. An URL is required, it will be there the hook will be sent. The type of Hook (Text, JSON or XML) must be chosen too.
An example of creation of a Hook template:
Generalities about the templates - Languages
At the creation of the template, you need to choose one or more languages. Dependant of the language of the receiver, the language of the template corresponding will be sent. If the language corresponding is not available, and the creator chose only one language, the template in this language will be used. If the creator chose multiple languages, the English one will be searched and sent. If the English one is not available, then the first language defined will be sent.
An example of adding multiple language :
To delete a language :
For each template a content for each language chosen is required. We recommend creating dynamic content with the use of the tags. Each tag begins with a “#” . Once you typed a “#”, the list of the available tags will be displayed. Each tag will be replaced by the personal information of the Transaction, Dispute or Installment Payment when the notification is sent.
Once the content typed you can visualize the final result with the tags replaced by example data. Please note if a problem occurs in the preview, the problem will occur in the real notification.
The tag system can be used in the three types of template (SMS, Email and Hook).
An example of creating content and preview :
The Scenarios
Once the templates created, you can write a scenario. As said before, a scenario is a set of rules. You can create one or more rules in each scenario, and you can write one or multiple scenarios with the same type.
Create a scenario
The Rules
A rule of a scenario is composed of a name, a description, a clickable case “Active” that will activate the rule. It comport also two important part “WHEN” that will define the rule itself and the “THEN” that will define the actions that will ensue the success of the situation described by the rule.
To create a rule :
The "WHEN" part :
The “WHEN” will be where the rule is set. It response to a precise Grammar. An attribute system
is also in place so when you type “#” a list of all possible attributes will be displayed. You can add conditions with adding “AND” or “OR” after the first rule is written.
All the logic operators available are :
For a chain of character :
= (equal to)
!= (different from)
in (in the following statement)
not in (not in the following statement)
Please note you need to frame the chain of character with quotation mark " ".
For numbers :
= (equal to)
!= (different from)
< (less than)
> (greater than)
<= (less or equal to)
>= (greater or equal to)
in (in the following statement)
not in (not in the following statement)
For a boolean (a true or false statement) :
= (equal to)
!= (different from)
Please note for the IN and NOT IN you need to frame the following statement with parenthesis. You can add multiple data in these parenthesis, if you separate them by comma.
You can prioritize a statement by adding parenthesis around. If you use a AND and a OR, please prioritize a part. If you use multiple AND and OR you need to prioritize each part accordingly.
Example of valid rules :
#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')
Before saving the rule, you need to test the rule with the adequate button. It will verify the rule follow the grammar used for the rules and if the rule will work once activated. You cannot save a rule without a fully working rule and a correct grammar.
An example of correct rule :
The "THEN" part :
The “THEN” w
ill be where you can choose the actions triggered by the rules. These actions can require the use of templates once the rules activated. You can only have access to templates that correspond of the type of template needed (SMS, Email, Hook) and the type of scenario you are working on (Dispute , Transaction, Installment Payment).
An example of choice of Templates :
Collective Rules
Some rules are predefined for all the actors and will be applied to you. You can verify this in your protected area in your ‘Notification’ tab. You can unsubscribe to some of these rules by using the clickable case.
