Smart Form

Simple à intégrer, Smart Form est un formulaire de paiement intelligent accessible par l’API via le service paymentRequest. Hébergé dans la zone PCI-DSS de CentralPay, il intègre les fonctionnalités de paiement les plus essentielles.

En utilisant Smart Form, vous évitez la partie la plus contraignante des exigences PCI-DSS. En effet, toutes les données sensibles sont directement traitées dans l'environnement PCI-DSS de CentralPay. Par conséquent, les données cartes bancaires ne transitent jamais par votre serveur.

Smart Form est rattaché aux services :

paymentRequest qui initialise des demandes de paiement via l’API
"Push & Pay" qui assure l’automatisation et l’émission des notifications de demande de paiement

Avec Smart Form, les parties les plus complexes des traitements sont gérées par CentralPay :

La génération et l’hébergement du formulaire de paiement
les vérifications des informations utilisateur,
la gestion des différents moyens de paiement,
la sécurisation des données de carte,
les notifications de relances ou de demandes de paiement,
les différents modes et types de paiement.

Le service est accessible :

Via l’API CentralPay en intégration avec un SI tiers :
- Par redirection HTTPS vers un site internet
- Par des notifications e-mail/SMS
- Par l’affichage ou l’impression d’un QR code
• Via la console web ou l’application mobile CentralPay
- Par des notifications e-mail/SMS
- Par des notifications e-mail/SMS

Exemple de formulaire de paiement "Smart Form"

Moyens de paiement disponibles

CARTES BANCAIRES

Visa, Mastercard, Amex, Bancontact…

CARTES BANCAIRES

Paiement en X fois pour échelonner les règlements de vos clients.

Visa, Mastercard, CB

Paiements SEPA

SCT - SEPA Credit Transfer (Virement SEPA)

SDD - SEPA Direct Debit (Prélèvement SEPA Core)

Planning de mise en ligne - Moyens de paiement
Moyen de paiement	Etat	Type
AliPay	Not live	Wallet
American Express	Live	Card
ANCV	Not live	Voucher
Apple Pay / Google Pay	Not live	Wallet
Bancontact	Not live	Card
Carte Bancaire	Live	Card
Diners	Live	Card
Discover	Live	Card
GiroPay	Not live	Direct Debit
Ideal	Not live	Direct Debit
JCB	Not live	Card
Maestro	Live	Card
MasterCard	Live	Card
PayPal	Not live	Wallet
Postfinance	Not live	Card
Visa	Live	Card
Visa Electron	Live	Card

Choix des moyens de paiement :

Le paramétrage du point de vente permet de définir les moyens de paiement qui seront accessibles au client.
En fonction des interactions souhaitables entre les règlements combinés, certains moyens ne sont pas nécessairement accessibles.

Associé au service Push & Pay, un Smart Form peut intégrer des modes de paiement évolués :

Règlement à plusieurs participants
Règlements combinés sur plusieurs moyens de paiement
Automatisation des demandes, relances et notifications

Payment request

paymentRequest permet de définir les conditions et les modalités de règlement d’un montant à encaisser. L’instruction peut-être initiée pour être soit transmise en direct depuis une redirection HTTPS depuis un site Internet vers le formulaire de paiement, soit depuis le service PUSH & PAY par notification e-mail/SMS ou par affichage d’un QR Code.

Avec le service PUSH & PAY, il est ainsi possible de créer des workflows complexes permettant l’interaction poussée avec les consommateurs ou des plateformes tierces. Vous devez donc paramétrer les modèles e-mail/SMS et les scénarios avant d’utiliser cet objet.

Lire la suite de Payment request

Fonctionnement d’une demande de paiement

Une demande de paiement permet de réserver un montant à régler selon des modalités définies dans sa requête.

Montant Fixe :
- Le règlement est fixé à un seul montant (totalAmount).
- Le Payeur ne pourra pas modifier le montant.
Montant Fixe avec règlement échelonné avec installment :
- Permet de découper le montant initial en plusieurs règlements (Installment) selon une fréquence définie.
Abonnement avec l'object subscription :
- Par le biais de la demande de paiement, le payeur souscrit à un abonnement que vous définissez.
Montant Partiel :
- Le montant du règlement est libre. Le Payeur pourra payer en plusieurs fois en fixant lui-même le montant ou réadresser la demande de paiement à des tiers.
Règlement à plusieurs à base de montants fixes :
- Le montant total se subdivise en plusieurs sous-montants qui sont affectés à chaque participant
- Chaque participant recevra ensuite une notification par e-mail ou SMS lui permettant de se rendre sur la page de paiement afin de régler le montant qui lui a été alloué.

Le paramétrage revient à renseigner les données suivantes en fonction du contexte :

		Je paie
		Seul		À plusieurs
		Destinataire	Montant	Destinataire	Montant
Montant	Partiel	@1 -->	N/A	@1 --> @2 --> @3 -->	N/A N/A N/A
Montant	Fixe	@1 -->	1 000 €	@1 --> @2 --> @3 -->	500 € 300 € 200 €

Une demande de paiement réussie adresse en réponse :

L’adresse du formulaire de paiement et les caractéristiques associées sous forme de :
- QR CODE
- URL
UUID de la requête

La liste des moyens de paiement disponibles est paramétrable sur le point de vente défini par :

Carte Bancaire
Carte bancaire en X fois
Chèque Vacances
Virement
Wallet
FidelyPay

Lire la suite de Fonctionnement d’une demande de paiement

Initialisation des demandes

Les demandes de paiement sont initialisables depuis :

L’API
La console CentralPay
L’application mobile CentralPay

Lire la suite de Initialisation des demandes

Les types de demandes de paiement

Il existe 3 types de demandes de paiement depuis le Back office :

1/ Les demandes instantanées :

Elles sont caractérisées dans l’interface par un symbole d’éclair et peuvent être créées comme ce qui suit :

Elles comprennent la possibilité de réaliser des transactions, des cautions, des abonnements, des paiements en X fois, en CB ou en SDD et des virements. Il est également possible de créer des customers en enregistrant les données de vos clients, ou de rechercher des customers déjà existant.

Des paramètrages supplémentaires seront disponibles pour configurer les paiements en X fois et les abonnements :

2/ Les demandes programmées :

Elles sont caractérisées dans l’interface par un symbole d’horloge et peuvent être créées comme ce qui suit :

Elles comprennent les même options que les instantanées comme la possibilité de réaliser des transactions, des cautions, des abonnements, des paiements en X fois, en CB ou en SDD et des virements. Il est également possible de créer des customers en enregistrant les données de vos clients, ou de rechercher des customers déjà existant.

La différence avec les demandes de paiement instantané reside dans la possibilité d’utiliser un profil spécial, ainsi que certaines options :

Une date limite de paiement est ajoutable, date à partir de laquelle votre client ne pourra plus payer.
Une date limite d’expiration, qui est la date à partir de laquelle le formulaire de paiement expire.
L’ajout d’un scénario qui va vous permettre de configurer des notifications précises sur cette demande de paiement.
L’ajout d’un email de réception de confirmation de paiement.
Une langue pour la demande de paiement.
Une règle d’affichage qui permet de choisir un template d’affichage et un formulaire SMART FORM customisé si besoin.
L'envoi d'une Pièce jointe dans le mail de confirmation de paiement.

3/ Importation de demande de paiement de masse :

La fonctionnalité est disponible depuis via le bouton import sur la page de listing des demandes de paiements (Backoffice 10.7.0) :

Attention pour avoir accès à cette fonctionnalité, il faut être connecté en Marchand et avoir l’ACL ‘cpay_core_payment_request’ en CREATE.

Au clic sur le bouton importer, une popin apparait :

A partir de celle-ci, il est possible de directement uploader un fichier CSV ou JSON, ou bien de télécharger un modèle (les données sont fictives et données à titre d’exemple).

L’option « forcer l’importation » permet de soumettre l’import malgré des erreurs de syntaxe.

Listing des champs du fichier à importer :

Libellé	Description	Commentaires
profile_uuid*	UUID du profil de demande de paiement	Doit exister et appartenir au marchand Obligatoire
merchant_payment_request_id	Référence marchand	Entre 0 et 100 caractères
description	Description	Entre 0 et 255 caractères
total_amount*	Montant de la demande de paiement	Doit être > 0 Obligatoire
last_name	Nom	Entre 0 et 35 caractères
first_name	Prénom	Entre 0 et 35 caractères
*Email si phone vide**	Email	Obligatoire si Phone vide Entre 0 et 255 caractères Si l’email est présent dans la base Customer (et create_customer à N), les données du Customer seront reprises. Si l'email (et éventuellement nom et prénom) est associé à plusieurs Customer, c’est le dernier crée qui sera repris.
Phone * si email vide	Téléphone	Obligatoire si Email vide Entre 0 et 255 caractères Format International : ^\\+[0-9]{1,15}$ Ex : +33612345678 * Si email est fourni et est présent dans la base Customer (et create_customer à N), les données du Customer seront reprises. * Si un email est fourni (et éventuellement nom et prénom) et est associé à plusieurs Customer, c’est le dernier crée qui sera repris.
create_customer*	Création d'un customer	Valeur possible : "Y" (oui) ou "N" (non) Obligatoire
link_expiration_date	Date limite de paiement	Si rempli, surcharge celle du profil de demande de paiement. Format : YYYY-MM-DD Doit être > à NOW
deadline	Date d'expiration du lien	Si rempli, surcharge celle du profil de demande de paiement Format : YYYY-MM-DD Doit être > à NOW
receipt_email	Email de réception confirmation de paiement	Si rempli, surcharge celle du profil de demande de paiement. Si non rempli, la valeur du champ email sera reprise
language	Langue utilisée dans la demande	Si rempli, surcharge celle du profil de demande de paiement. Par défaut : Anglais.

Attention, il est nécessaire de mettre tous les champs dans le fichier, sans ordre précis.

Si le fichier contient des erreurs par rapport aux contraintes listées ci-dessus, un message d’erreur sera affiché en haut de la popin afin que le marchand corrige son fichier :

Si le fichier passe les vérifications, le marchand sera redirigé sur la page de listing des demandes de paiement avec un message :

C’est ensuite le batch qui va créer les demandes de paiement et envoyer un mail récapitulatif à l’adresse mail du profil qui a créé l’import.

Lire la suite de Les types de demandes de paiement

Statuts de demandes de paiements

Un certain nombre de statuts liés à la demande de paiement sont disponibles afin de faciliter le suivis de celle-ci. Les statuts s’influencent entre eux et sont changés suite à certaines actions manuelles ou automatiques sur notre plateforme.

Il faut distinguer les statuts de la demande de paiement elle-même et ceux du moyen de paiement mis en place pour y répondre.

Nous pouvons distinguer 4 paramètres de statuts différents sur une demande de paiement :

Les statuts de la demande
Les statuts du paiement
Les statuts du Breakdown
Les statuts du débit

Les statuts de la demande peuvent être accompagné d’une raison pour certains.

Statuts de la demande :

Concerne les statuts de la demande paiement par elle même.

Active

La demande de paiement est ouverte

Fermée

Les opérations ont été correctements réalisées par l'utilisateur et le client, aucune actions disponible désormais

Annulée

Une erreur a été commise par l'utilisateur, ou le paiement n'a pas été réalisé à temps par le client

Concernant l’action de fermeture d’une demande de paiement, une raison est demandé en plus de la fermeture.

L’annulation de la demande de paiement n’entraine pas un remboursement ou l’annulation sur le moyen de paiement utilisé.

Statuts du paiement :

Concerne les statuts du paiement par lui même. Les moyens de paiement mis en place dependent du choix effectué lors de la création de la demande de paiement, mais tous possèdent les mêmes statuts.

Payé

La demande de paiement à été honorée, entraine un statut de la demande Fermée

Partiel

La demande de paiement à été partiellement honorée, le statut de la demande est toujours Active

Non Payé

La demande de paiement n’est pas honorée. Ce statut est présent au début, tant que la demande de paiement n’est pas honorée mais est également présent à l’annulation de la demande de paiement

Statuts du Breakdown :

Le Breakdown contient les données d'un client : les status des paiements individuels.

Dans le cadre d’une transaction avec un client unique, la payment request, le breakdown et le paiement ont le même statut.

Dans le cadre d’une transaction avec plusieurs clients alors il peut y avoir une disparité au niveau des statuts du breakdown.

Payé

Le client a honoré la demande de paiement

Partiel

Le client a honoré partiellement la demande de paiement, le statut de la demande est toujours Active et le statut du paiement est Partiel

Non Payé

Le client n’a pas honoré la demande de paiement. Ce statut est présent au début, tant que la demande de paiement n’est pas honorée mais est également présent à l’annulation de la demande de paiement

Selon le nombre de client, les statuts peuvent se combiner et donner des cas où plusieurs statuts cohabitent.

Statuts du debit :

Le statut du débit décrit l’état du débit, une fois la demande de paiement honorée.

Uncaptured

Il est possible de faire des transactions ou les paiements ne seront pas sécurisé immédiatement. Ce statut apparait dans ce cas uiquement.

Captured

Le paiement est sécurisé et sera bientôt débité

Cleared

Le paiement est débité

Pending

Aucune action de capture ou de pré-capture sur le paiement n'ont été effectuées, paiement non sécurisé.

Lire la suite de Statuts de demandes de paiements

Profil de Demande de Paiement

Les profils sont liés au service Push & Pay et aux demandes de paiements. Les profils reprennent les paramètres des demandes de paiements et la possibilité de choisir un scénario. Ils vont constituer des templates de comportements déjà pré-fait qui seront appliqués automatiquement aux demandes de paiement dans lesquelles le profil sera selectionné. Ils peuvent ensuite être utilisés dans les demandes de paiement programmées et les demandes de paiement de masse.

Dans la partie configuration générale, il est possible de choisir un nom, un point de vente, une devise liée au point de vente et une langue, qui va influencer la langue dans laquelle les informations seront affichées pour vos clients.

Dans la partie moyens de paiement, il est possible de choisir la nature de la demande de paiement (Transaction, Caution, Paiement en X fois, abonnement ou virement).

Enfin dans les options, il est possible de choisir une limite de paiement (après laquelle votre client ne sera plus en possibilité de payer), une limite d’expiration du lien (après laquelle votre client ne sera plus en possibilité de payer par le formulaire spécifiquement), la possibilité de choisir un scénario qui va envoyer des notifications aux moments clefs de la demande de paiement, un email de réception de confirmation de paiement, des règles d’affichage, la possibilité d’ajouter des pièces jointes et enfin la possibilité de créer automatiquement des customers dès que le profil est utilisé.

Lire la suite de Profil de Demande de Paiement

Règles d'affichage - Paramètrage de Formulaire et redirection du smart form

Les paramètrages de formulaire sont des templates de SMART FORM, customisés selon vos besoins. Ils sont appellés “Régles d’affichages” dans la création des demandes de paiement. Ces templates sont présents dans les demandes de paiement programmées, par un choix ou via le profil choisis. Ils sont également présent dans les demandes de paiement de masses via le profil choisis.

Les champs disponibles pour les templates sont : le nom du template, la possibilité d’en faire le template par défault, la possibilité d’afficher le champ CVV ainsi que la possibilité de forcer le fait de créer un customer. Sont également disponibles les champs comprenant l’URL de redirection ainsi que le delais avant la redirection.

Enfin, il est possible d’ajouter des champs supplémentaires aux formulaires générés automatiquement, les champs cochés seront ajoutés aux champs déjà présent sur le SMART FORM classique. Les champs ajoutés peuvent différés si le template est utilisé pour les virements ou pour une demande de paiement avec une carte.

Le liste des champs supplémentaire est la suivante :

Adresse 1
Adresse 2
Adresse 3
Adresse 4
Ville
Pays
Email
Prénom
Téléphone
Code Postal

Lire la suite de Règles d'affichage - Paramètrage de Formulaire et redirection du smart form

Cas d'usage

Demande de paiement unitaire

Il s’agit d’une demande de paiement à une transaction comprenant un montant et une devise. Elle reste associée à un scénario permettant de gérer les cas définis par l’utilisateur.

Règlement simple d’un montant unique :

Montant
Devise
Langue

Exemple cURL :

curl -v https://test-api.centralpay.net/v2/rest/paymentRequest \
-u 'doctest:4I9HJRTd' \
-F paymentMethod[]='TRANSACTION' \
-F currency='EUR' \
-F totalAmount=100000 \
-F partial=false \
-F breakdown[]='{"amount":100000, "email":"johnDoe@hotmail.com"}' \
-F transfer[]='{"destinationWalletId":"10cfe034-ba9a-457e-b13d-fc68a5bfd171", "amount":100000, "email":"johnDoe@hotmail.com"}'

Réponse JSON :

{ 
 "paymentRequestId": "cd80f9c9-d121-44a6-a6a9-3f775a5acff8",
 "creationDate": "2020-08-13T15:34:02.004118+02:00",
 "pointOfSaleId": "cfc0b3c7-e666-4c52-b77a-96f234b873fe",
 "deadline": null,
 "linkExpirationDate": null,
 "endingDate": null,
 "scenarioId": null,
 "paymentFormTemplateId": null,
 "merchantPaymentRequestId": null,
 "description": null,
 "currency": "EUR",
 "totalAmount": 100000,
 "paymentRequestStatus": "ACTIVE",
 "paymentStatus": "UNPAID",
 "createCustomer": false,
 "paymentMethods": [ "TRANSACTION" ],
 "transaction": { 
  "paymentRequestTransactionId": "2f813571-dc15-4149-a39c-0a671d301bb2",
  "contractId": "71602dd0-2790-4743-877b-e72530d7576d",
  "receiptEmail": null,
  "source": "EC" 
 },
 "installment": null,
 "subscription": null,
 "breakdowns": [
  { 
   "paymentRequestBreakdownId": "4dc27147-4d46-4b68-ba2f-49f6f3a8871b",
   "customerId": null,
   "lastEnteringDate": null,
   "lastPaymentAttempt": null,
   "amount": 100000,
   "initiator": true,
   "endpoint": "https://test-form.centralpay.net/25cd87d7-2dd8-4f08-8b78-2f84f5496ffd",
   "email": "johnDoe@hotmail.com",
   "phone": null,
   "firstName": null,
   "lastName": null,
   "entered": false,
   "paymentAttempted": false,
   "paid": null,
   "view": 0,
   "status": "UNPAID",
   "payments": [] 
  } 
 ],
 "transfers": [ 
  { 
   "destinationWalletId": "10cfe034-ba9a-457e-b13d-fc68a5bfd171",
   "escrowDate": null,
   "amount": 100000,
   "fee": 0,
   "merchantTransferId": null 
  } 
 ],
 "wireTransfer": null,
 "transferGroup": null,
 "attachments": [],
 "language": "eng",
 "redirectUrl": null,
 "closeComment": null,
 "additionalData": {} 
}

Lire la suite de Cas d'usage

Intégration du Smart form

Nous allons vous présenter les différentes étapes présentent lors d'une intégration standard de notre Smart Form.

Dans un premier temps, il faut initier une payment request avec les informations de payment que vous souhaitez et que vous avez récuperrer auprès du client. L'initialisation se fait généralement via un curl php. Vous pouvez retrouver un cURL PHP sur notre site example.
Pour des raison de lisibilité des informations envoyées notre exemple se fera en cURL natif.

Exemple cURL natif :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/paymentRequest' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--form 'paymentMethod[]="TRANSACTION"' \
--form 'currency="EUR"' \
--form 'totalAmount="100000"' \
--form 'partial="false"' \
--form 'breakdown[]="{amout:100000, email:johnDoe@hotmail.com}"' \
--form 'transfer[]="{destinationWalletId:10cfe034-ba9a-457e-b13d-fc68a5bfd171, amount:100000, email:johnDoe@hotmail.com}"'

Une fois cette Payment request correctement initée, nous renvoyons une réponse en JSON. Les informations pour afficher le smart form sont présentes dans cette réponse, aussi vous devez la récuperer et la traiter afin de pouvoir récuperer le ou les endpoint(s). Il y a plusieurs endpoints si vous initiez une payment request avec plusieurs payeur, et donc plusieurs breakdowns.

Réponse du curl exemple :

{
    "paymentRequestId": "4cd3c57c-a71e-4e5d-832c-46e0b30d85c6",
    "creationDate": "2021-06-10T12:34:44.386219+02:00",
    "pointOfSaleId": "cfc0b3c7-e666-4c52-b77a-96f234b873fe",
    "deadline": null,
    "linkExpirationDate": null,
    "endingDate": null,
    "scenarioId": null,
    "scenarioStartingDate": null,
    "paymentFormTemplateId": null,
    "merchantPaymentRequestId": null,
    "description": null,
    "currency": "EUR",
    "totalAmount": 100000,
    "paymentRequestStatus": "ACTIVE",
    "paymentStatus": "UNPAID",
    "createCustomer": false,
    "paymentMethods": [
        "TRANSACTION"
    ],
    "transaction": {
        "paymentRequestTransactionId": "a094ba26-d5e3-41e1-a9d4-4d88bc6f838e",
        "contractId": "71602dd0-2790-4743-877b-e72530d7576d",
        "receiptEmail": null,
        "source": "EC",
        "capture": true,
        "customAcceptanceData": {}
    },
    "installment": null,
    "subscription": null,
    "breakdowns": [
        {
            "paymentRequestBreakdownId": "d3d48c4d-50d8-46d1-ba54-720b673dcc27",
            "customerId": null,
            "lastEnteringDate": null,
            "lastPaymentAttempt": null,
            "amount": null,
            "initiator": true,
            "endpoint": "https://test-form.centralpay.net/b670bb15-c243-450c-aa2b-ea6b077231e2",
            "email": "johnDoe@hotmail.com",
            "phone": null,
            "firstName": null,
            "lastName": null,
            "entered": false,
            "paymentAttempted": false,
            "paid": false,
            "view": 0,
            "payments": []
        }
    ],
    "transfers": [
        {
            "destinationWalletId": "10cfe034-ba9a-457e-b13d-fc68a5bfd171",
            "escrowDate": null,
            "amount": 100000,
            "fee": 0,
            "merchantTransferId": null
        }
    ],
    "wireTransfer": null,
    "transferGroup": null,
    "attachments": [],
    "language": "eng",
    "redirectUrl": null,
    "closeComment": null,
    "additionalData": {}
}

Exemple de endpoint :

"endpoint": "https://test-form.centralpay.net/b670bb15-c243-450c-aa2b-ea6b077231e2"

La dernière étape consiste à afficher le smart form à votre client. Vous pouvez ou vrir le smart form dans un autre page, ou l'intégrer diréctement à votre page via un iframe.

Exemple de iframe :

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<iframe src="https://test-form.centralpay.net/b670bb15-c243-450c-aa2b-ea6b077231e2/transaction" id="iframeForm" width="1000" height="1000"></iframe>
</body>
</html>

Lire la suite de Intégration du Smart form