Sample User Guide

CentralPay propose des solutions de paiement modulaires permettant l’unification des flux d’encaissement pour compte propre et l’automatisation des reversements pour le compte de tiers. La typologie de services et d’opérations proposées par CentralPay varie en fonction des besoins et de l’activité de ses marchands et partenaires.

CentralPay est une société indépendante, entièrement propriétaire de sa technologie et de ses agréments. Garantissant la meilleure autonomie possible dans ses choix de partenariats et de son évolution.

CentralPay est autorisé à entrer en relation d’affaires avec les entreprises enregistrées dans l’Espace Économique Européen.

ACPR (Banque de France)	Établissement de Monnaie Électronique : CentralPay est un Établissement de Monnaie Électronique régulé par la Banque de France à travers son autorité de contrôle prudentiel et de résolution, l’ACPR (CIB 17138).
	DSP2 : CentralPay est conforme à la 2ème Directive sur les Services de Paiements qui impose notamment des exigences en matière d’authentification forte et de protection des données.
	PCI-DSS : CentralPay obtient annuellement la certification la plus élevée possible en matière de sécurisation des données bancaires et prévention de la fraude ; la norme PCI DSS de niveau 1.
	EBA CLEARING & EPC : En qualité de membre de l’European Payment Council et sa connexion à l’EBA CLEARING, CentralPay intègre les schémas européens des règlements SEPA afin d’émettre et de recevoir des virements et des prélèvements depuis ses propres IBAN et IBAN virtuels.
	SWIFT : Connecté au réseau SWIFT, messagerie la plus acceptée à l’échelle mondiale, CentralPay est en mesure d’échanger des flux financiers internationaux avec la plupart des banques et des institutions financières participantes.
	Visa, Mastercard, Cartes bancaires, American Express : CentralPay est accrédité auprès des grands réseaux de cartes, afin d’optimiser les parcours et la conversion des paiements de tous ses utilisateurs.

CentralPay exploite ses services depuis deux Datacenter Français. Les équipements et services exploités sur ces deux sites sont entièrement redondés.

Un hébergement hautement résiliant :

• Deux Datacenter de conception TIER III basés à Tours
• Environnement actif/actif entre les deux sites
• Des engagements contractuels (SLA) de 99.9%
• Des normes reconnues : ISO27001, PCI-DSS, Code of Conduct

Une infrastructure garante de la sécurité de vos données :

• Cœur de réseau allant jusqu’à 10 Gb/s
• Réseau électrique entièrement redondé | Densité électrique allant de 600 mA à 32 A
• Système de contrôle d’accès avec double authentification (badge & code personnel)
• Vidéo-surveillance et alarme reliée 24h/7j à notre télésurveillance
• Système d’extinction d’incendie par aérosol FirePro

CentralPay garantit une disponibilité annuelle de ses services (SLA & PCA) selon les barèmes suivants :

Les API de CentralPay reposent sur une architecture en micro services apportant un maximum de flexibilité. Notre approche modulaire permet de faire constamment évoluer nos solutions afin d’apporter toujours plus de services et de fonctionnalités.

Ces évolutions sont réalisées après des analyses d’impact poussées afin de ne pas provoquer de changement dans les intégrations de nos utilisateurs. Dans de très rares cas, celles-ci peuvent appeler des modifications mineures ou plus importantes lorsque des changements de régulations surviennent, comme ce fut le cas pour l’évolution vers la version 2.0 du 3DS par exemple.

En cas d’évolution de la plateforme ou de modifications des attentes concernant la consommation de ses APIs, CentralPay s’engage à vous prévenir dans un délai correspondant à l’ampleur des actions à mener :

• Modifications mineures nécessitant aucune action du marchand ou partenaire :
  remise d’information simple
• Modifications mineures avec action nécessaire par le marchand ou partenaire :
  2 mois minimum de délai de prévenance + accompagnement à la réalisation
• Modifications majeures avec action nécessaire par le marchand ou partenaire :
  6 mois minimum de délai de prévenance + accompagnement à la réalisation

À noter que les modifications nécessitant une action de nos marchands ou partenaires sont qualifiées d’exceptionnelles à inexistantes et que toutes les précautions sont prises pour éviter tout impact sur leur activité.

La réserve représente les sommes qui sont maintenues sur votre compte CentralPay afin de permettre de couvrir les R-transactions (rejets, refus, retours, remboursements, contestations, impayés) liés à des opérations de paiement. Ses paramètres sont définis en fonction du profil de risque financier de votre compte, et sont actualisés en fonction de l’analyse de vos R-transactions sur une période suffisante. Les transactions récurrentes par prélèvement SEPA et par carte bancaire sont particulièrement sujets au risque de R-transactions.

CentralPay possède 3 types de garanties de protection qui peuvent s’appliquer aux marchands, en fonction de la nature de leur contrat :

1/ Le collatéral

Il représente la somme fixe versée en début de relation, servant à couvrir le risque de crédit dans le cas où le marchand ne pourrait pas satisfaire ses obligations de remboursement envers ses clients.

Le détail du Collatéral est visible depuis le Portail utilisateur : Administration Reversements Somme des cautions

2/ Le pied de compte

En l’absence de Collatéral, une somme fixe peut être prélevée directement sur les opérations afin de garantir le remboursement des clients en cas de besoin. Le wallet doit donc dépasser la valeur du pied de compte pour autoriser les reversements (payout).

Le détail du pied de compte est visible depuis le Portail utilisateur : Administration Reversements Seuil fixe

3/ La réserve glissante

Selon le secteur d’activité et les processus de règlement du compte, une réserve glissante (« rolling réserve » en anglais) peut être automatiquement ouverte. Il s’agit d’une garantie de protection supplémentaire qui permet de maintenir un certain pourcentage du volume d’encaissement marchand sur le compte CentralPay afin de permettre l’initiation de remboursements automatiques en cas de contestation de transaction, de fraude ou encore afin de couvrir d’éventuels frais opérationnels. Cette somme appartient à la trésorerie du marchand, elle est gardée un nombre défini de jours avant d’être libérée (généralement entre 90 à 180 jours).

Par exemple, le seuil variable de la réserve glissante est de 5% du volume d’encaissement sur 90 jours. Le calcul quotidien du montant de réserve est le suivant : montant des transactions encaissées lors des 90 derniers jours * 5%

Le détail du pied de compte est visible depuis le Portail utilisateur : Administration Reversements Seuil variable

Ouvert pour une entité (personne physique ou morale), il est le support de :
– Sa contractualisation : grille tarifaire, CGU…
– Son administration : authentification, profils utilisateurs…
– Sa configuration : scenario de notification, points de vente, règles d’acceptations
– Sa conformité : KYC/KYB, accréditations…

Le compte CentralPay contient un ou plusieurs comptes de paiement ou de monnaie électronique.

1/ Les types de compte CentralPay et droits associés

Il existe plusieurs types de compte CentralPay disposants de droits spécifiques à chacun :

• Participant (anciennement Basic) : destiné aux sous-marchands et participants. Il dispose d’un compte de paiement ou de monnaie électronique, à travers duquel il peut uniquement recevoir des transferts en provenance du partenaire l’ayant inscrit. Il peut piloter ses reversements depuis son Portail utilisateur mais n’a aucun accès à l’API CentralPay.
• Marchand (anciennement Standard) : destiné aux marchands. Il dispose d’un ou plusieurs comptes de paiement, à travers desquels il peut réaliser des opérations de paiement et piloter ses reversements. Il peut également disposer d’un compte de commission sur lequel CentralPay prélèvera ses frais, afin de segmenter ce type d’opérations du reste des transactions.
• Partenaire MOBSP (disponible prochainement) : destiné aux partenaires MOBSP. Il dispose d’un compte de commission pour recevoir les frais associés à ses services, et potentiellement d’un compte de paiement pour opérer ses propres encaissements. Il peut réaliser des opérations de paiement au travers d’un compte de collecte dont CentralPay est le titulaire et à accès aux services partenaires MOBSP (demande d’inscription de sous-marchands, transferts via transaction…).
• Partenaire DME (disponible prochainement) : destiné aux partenaires distributeurs de Monnaie Électronique. Il dispose d’un compte de commission pour recevoir les frais associés à ses services. Il peut réaliser des opérations de paiement au travers d’un compte de collecte dont CentralPay est le titulaire et à accès aux services partenaires DME (demande d’inscription de sous-marchands / participants, transferts via transaction, transferts en Monnaie Électronique…)
• Partenaire Agent (anciennement Agent) : destiné aux partenaires Agents Prestataires de Services de Paiement. Il dispose d’un compte de commission pour recevoir les frais associés à ses services, et potentiellement d’un compte de paiement pour opérer ses propres encaissements. Il peut réaliser des opérations de paiement au travers d’un compte de collecte dont il est le titulaire et à accès aux services partenaires Agent (demande d’inscription de sous-marchands, transferts via transaction, transferts indépendants…).

NB : Un compte peut-être « Marchand » et « Participant » à la fois, dans le cas d’une activité propre en complément de sa participation à une plateforme.

2/ Paramétrage des emails de contacts du compte

Afin d’adresser nos demandes ou de transférer les informations importantes aux bonnes personnes au sein de votre entité, il est important de renseigner les emails de contact du compte :

• Email contact : email du responsable général du compte
• Email administratif : email du responsable administratif du compte
• Email technique : email du responsable technique du compte
• Email financier : email du responsable financier du compte

NB : par défaut, les emails sont renseignés avec celui du titulaire du compte.

• Accès Portail utilisateur de RCT – Paramétrage des coordonnées
• Accès Portail utilisateur de PROD – Paramétrage des coordonnées

1/ Introduction

Les profils clients (ou « Customer ») unifient et sécurisent toutes vos données client pour en faciliter la gestion. Ils interagissent avec les autres services de CentralPay et permettent notamment de :

• centraliser leur historique de paiements (tous canaux de vente et moyens de paiement confondus)
• digitaliser et stocker de manière sécurisée leurs supports de paiement (cartes, mandats SEPA, IBAN virtuels)
• suivre facilement leurs paiements récurrents (abonnements, paiements fractionnés) ou règlements en attente (demandes de paiement).

Dans certains cas, ils peuvent également être associés à un compte de monnaie électronique permettant au client de recevoir et d’utiliser des fonds au sein du réseau du partenaire distributeur de cette monnaie électronique.

Un Customer est obligatoirement identifié soit par son email, soit par son numéro de téléphone.

Il est également possible de déclarer d’autres informations le concernant comme son nom, son prénom, sa langue, sa référence personnalisée, son moyen de paiement par défaut…

2/ Utilisation

La création d’un Customer est obligatoire pour la réalisation :

• d’abonnements ou de paiements fractionnés par carte
• de paiements en 1 clic par carte
• de paiements par prélèvement SEPA
• de paiements par virement SEPA avec IBAN Virtuel dédié à celui-ci
• de création d’un compte de monnaie électronique anonyme

3/ Interfaces

Vous pouvez consulter l’ensemble des Customers de votre compte depuis votre Portail utilisateur > Compte > Customers :

• Accès Customers – Portail utilisateur de RCT
• Accès Customers – Portail utilisateur de PROD

Vos Customers disposent également d’un portail client leur permettant d’administrer les paiements réalisés avec votre entreprise.

4/ Création d’un Customer

Il existe deux méthodes pour créer un Customer :

• Créer un Customer depuis le service API dédié, permettant ensuite de créer une Card, de gérer un IBAN Virtuel pour ce Customer, d’initier une transaction, une demande de paiement…
• Créer un Customer via une demande de paiement

CentralPay assure l’unicité des Customers : si vous initiez une demande de paiement avec création d’un Customer alors que son email ou son numéro de téléphone est déjà connu dans votre compte, CentralPay ne créera pas de nouveau Customer et associera la transaction au profil existant.

1/ Introduction

Les points de vente (« Point of Sales » ou « POS ») sont la représentation de vos différents sites web, boutiques, ou équipes de vente. Ils permettent de segmenter les opérations de votre compte CentralPay à des fins :

• Techniques : vous pouvez réaliser des paramétrages différents par point de vente (notifications clients, notifications internes, nom expéditeur des emails de confirmation, logo affiché dans la page de paiement …)
• Administratives : vous pouvez limiter les droits de consultation ou de modification de vos profils utilisateurs à certains points de ventes
• Comptables : vous pouvez filtrer les opérations par point de vente dans votre Portail utilisateur ou dans vos exports de données

Lors de la création de votre compte CentralPay, un premier Point de Vente est créé automatiquement. Vous pouvez ensuite vous rendre sur votre Portail utilisateur pour paramétrer ce dernier, ou en créer de nouveaux :

• Accès Points de ventes – Portail utilisateur de RCT
• Accès Points de ventes – Portail utilisateur de PROD

2/ Paramétrages

Les Points de Vente comprennent un certain nombre de paramétrages obligatoires :

• Paramètres généraux
  • Nom : nom du point de vente (visible par vos clients)
  • URL du site : s’il s’agit d’un site e-commerce, renseignez l’URL de ce dernier. Sinon, renseigner l’URL de votre site vitrine.
  • Pays du point de vente
• Configuration
  • Type technique : sélectionnez « Vente à distance »
  • Utilisateurs API : sélectionnez les utilisateurs API ayant un droit d’accès à ce Point de Vente
  • Contrats : sélectionnez le contrat VAD carte qui a été paramétré pour votre compte (en règle générale, vous n’aurez qu’un seul contrat à disposition)
  • Contrat par défaut : sélectionnez le contrat VAD carte qui sera utilisé par défaut (en règle générale, vous n’aurez qu’un seul contrat à disposition)
  • Viban prioritaire : si vous souhaitez que les IBAN Virtuels affichés dans les demandes de paiement soient ceux des Customers, alors sélectionnez « Client ». Si vous préférez afficher des IBAN Virtuels dédiés à chaque demande de paiement, alors sélectionnez « SCT ». Si besoin d’informations complémentaires, consultez notre rubrique sur les IBAN Virtuel.

D’autres paramétrages ne sont pas obligatoires, mais sont importants pour votre parcours de vente :

• Paramètres généraux
  • Logo : chargez le logo de votre entreprise ou celui dédié à votre point de vente. Il apparaitra dans la page de paiement générée par les demandes de paiement.
  • ID point de vente du marchand : renseignez une référence personnalisée vous permettant d’identifier plus simplement le point de vente dans vos systèmes d’information.
• Emails de confirmation
  • Coche « Activer l’email de confirmation de paiement » : En cochant cette case, vous activez l’envoi d’un email à vos clients lorsqu’ils réalisent un paiement par carte. Il s’agit d’un email standardisé non modifiable contenant un récapitulatif du paiement (raison sociale de votre compte, nom de votre point de vente, date du paiement, identifiant de la transaction CentralPay, référence marchand de la transaction, description marchand de la transaction, code d’autorisation du paiement, marque de la carte, 6 premiers et 4 derniers chiffres de la carte, montant de la transaction, état de la transaction). La langue et le pied de page de l’email peuvent être paramétrés depuis le Portail utilisateur > Configuration > Email confirmation paiement.
  • Email de l’expéditeur : si vous avez coché la case « Activer l’email de confirmation de paiement », vous pouvez personnaliser l’adresse expéditeur en utilisant l’une de vos adresses email (par exemple : no-reply@mondomaine.com). Attention, veillez à nous demander de vous communiquer nos clés SPF et DKIM afin que vous puissiez autoriser CentralPay à envoyer des emails depuis votre domaine.
  • Nom de l’expéditeur : si vous avez coché la case « Activer l’email de confirmation de paiement », vous pouvez personnaliser le nom de l’expéditeur (par exemple : MonEntreprise).
  • Coche « Recevoir une copie de la confirmation de paiement » : En cochant cette case, vous activez l’envoi d’une copie de l’email adressé à vos clients lorsqu’ils réalisent un paiement par carte. Cela peut vous permettre d’être informé facilement par email lorsqu’un client réalise un paiement.
  • Email du destinataire : si vous avez coché la case « Recevoir une copie de la confirmation de paiement », vous devez renseigner l’adresse email du destinataire de cette copie.

Enfin, d’autres paramètres secondaires sont disponibles :

• OTP
  • Email de l’expéditeur OTP email : Email affiché en tant qu’expéditeur des emails de One Time Password (connexion à l’espace Administration du Portail Utilisateur…)
  • Nom de l’expéditeur OTP email : Nom affiché en tant qu’expéditeur des emails de One Time Password (connexion à l’espace Administration du Portail Utilisateur…)
  • Numéro de téléphone ou nom de l’expéditeur OTP SMS : Nom ou numéro de téléphone affiché en tant qu’expéditeur des SMS de One Time Password (validation de mandat SEPA…)
• Paramètres de communication

Ces paramètres sont appliqués aux mails ou SMS transmettant le lien vers le formulaire de paiement d’une demande de paiement (paymentRequest).

Ils s’appliquent uniquement lorsque aucun scenario n’a été configuré sur la demande paiement.

• Expéditeur SMS : Nom du correspondant affiché sur le SMS
• Expéditeur Email : Email du correspondant affiché sur l’email
• Nom de l’expéditeur Email : Nom du correspondant affiché sur l’email
• Adresse de réponse Email : Email utilisé pour les réponses des emails envoyés (applicable prochainement)
• Pied de page de l’email : Pied de page des emails (applicable prochainement)

1/ Introduction

Les comptes de paiement sont utilisés pour réaliser des opérations de paiement (collecte de paiements en devises ISO, reversement des fonds vers un compte bancaire…). Ils permettent de stocker des fonds dans une devise ISO (EUR, USD, CHF, GBP…) et possèdent un IBAN/BIC qui lui est propre. Un compte de paiement est, sauf exception, associé à un compte bancaire ayant le même titulaire, permettant à CentralPay de réaliser des reversements automatiques par virement SEPA.

Si vous disposez de plusieurs comptes bancaires sur lesquels vos fonds doivent être reversés, vous pouvez demander à votre contact CentralPay de créer le même nombre de comptes de paiement dans votre compte CentralPay. Ainsi, chaque compte de paiement sera lié à un compte bancaire différent et adressera des reversements SEPA en conséquence.
Il est également possible de créer plusieurs comptes de paiement à des fins de segmentation des fonds (avec un compte dédié aux opérations de commission ou de frais par exemple).

Vous pouvez consulter le détail de vos comptes de paiements depuis ces accès :

• Comptes de paiement – Portail utilisateur de RCT
• Comptes de paiement – Portail utilisateur de PROD

2/ Utilisations

Les comptes de paiement sont systématiquement utilisés pour les opérations de paiement de notre plateforme, à l’exception des opérations de monnaie électronique.

3/ Création de comptes de paiement

Si vous êtes marchand CentralPay, vous pouvez adresser une demande par email aux équipes CentralPay pour la création de plusieurs comptes de paiement à votre nom. Cela afin de segmenter vos opérations ou d’ouvrir un compte dans une devise différente.

Si vous êtes Partenaire MOBSP ou AGENT de CentralPay, vous pouvez créer des comptes pour vos sous-marchands en utilisant le service de création de comptes de paiement.

1/ Introduction

Uniquement réservé aux Partenaires DME et à leurs utilisateurs.

Les comptes de ME (Monnaie Électronique) sont utilisés pour stocker et échanger des fonds dans une devise CUSTOM (devise dédiée à un partenaire DME). Un partenaire DME peut demander la création de comptes de ME pour les participants de son réseau puis réaliser des transferts de fonds en ME entre ces comptes.

Le titulaire d’un compte de ME ne peut recevoir des paiements et utiliser sa monnaie électronique que par l’intermédiaire du partenaire DME. Il peut cependant demander le remboursement de sa monnaie électronique à tout moment et recevra ses fonds en devise ISO : soit sur son compte bancaire par virement SEPA, soit sur sa carte bancaire, selon les paramétrages de son compte.

Vous pouvez consulter le détail de vos comptes de ME depuis ces accès :

• Comptes de ME – Portail utilisateur de RCT
• Comptes de ME – Portail utilisateur de PROD

2/ Utilisations

Les comptes de ME sont principalement utilisés pour permettre à des personnes physiques de recevoir et d’échanger facilement des fonds dans les contextes suivants :

• Marketplaces C2C de produits ou de services
• Stockage et utilisation de valeurs cadeaux au sein d’un réseau de commerçants indépendants

3/ Spécificités

Le CMF (Code Monétaire et Financier) présente des conditions spécifiques pour la monnaie électronique. Ainsi, il existe deux types de comptes de ME chez CentralPay :

• Compte de ME anonyme : ce compte peut être ouvert sans vérification d’identité du titulaire, à condition qu’il soit adressé à une personne physique et soit limité à 150 € de solde ou d’encaissement sur 30 jours. Ce type de compte est particulièrement utile dans le cadre d’une utilisation ponctuelle du compte par son titulaire, ou tout simplement pour simplifier l’entrée en relation avec le partenaire DME.
• Compte de ME vérifié : un compte anonyme peut être ensuite vérifié par les équipes conformité de CentralPay (procédure KYC) pour augmenter les limites qui lui étaient imposées, il devient ainsi « vérifié ».

4/ Création de comptes de ME

Si vous êtes Partenaire DME de CentralPay, vous pouvez demander la création de comptes de ME pour vos participants.

1/ Introduction

Les notifications peuvent être adressées en fonction des évènements liés à certains objets API :

• Demande de paiement (PaymentRequest)
• Contestation carte (dispute)
• Paiement X fois (installment)
• Transaction carte (transaction)
• Reversement (payout)
• Remboursement carte (refund)
• Abonnement (subscription)
• Crédit carte (credit)
• Transaction SDD (sddTransaction)
• Transaction SDD inversée (sddTransactionReversal)
• Mandat (mandate)

2/ Types de scénarios de notification

Notifiez vos clients et alertez vos collaborateurs automatiquement lorsque certains évènements ont lieu sur votre compte CentralPay : encaissement d’un virement, contestation client, échec de règlement…
Vous maitrisez le contenu de chaque notification depuis des templates personnalisés et définissez un mode d’envoi par email, par sms ou par Json. Vous automatisez ainsi le pointage de vos encaissements, les notifications clients, ou encore la mise à jour de votre système d’information.

3/ Paramétrage des modèles de notification

3.1/ Paramétrage des modèles (templates)

• Accès paramétrage templates emails :
  • Portail utilisateur de recette
  • Portail utilisateur de production
• Accès paramétrage templates SMS :
  • Portail utilisateur de recette
  • Portail utilisateur de production
• Accès paramétrage templates hooks :
  • Portail utilisateur de recette
  • Portail utilisateur de production

Pour commencer le paramétrage de vos notifications, vous devez créer vos modèles de communication (email, sms ou hook) en renseignant les éléments demandés. Par exemple l’objet du mail, le nom et email de l’émetteur, le corps du texte…

Vous pouvez intégrer des éléments dynamiques (tags) dans le corps du texte en tapant le caractère « # », qui fera apparaitre la liste des tags disponible pour le type de scénario de notification sélectionné.

Attention, si vous utilisez les notifications emails, veillez à nous demander de vous communiquer nos clés SPF et DKIM afin que vous puissiez autoriser CentralPay à envoyer des emails depuis votre domaine.

Concernant les SMS, veillez à calculer le nombre de caractères : vous serez facturés d’un SMS par 160 caractères (espaces inclus).

3.2/ Paramétrage du header et footer pour templates emails

• Paramétrage en-tête d’email (header)
  • Portail utilisateur de recette
  • Portail utilisateur de production
• Paramétrage pied de page d’email (footer)
  • Portail utilisateur de recette
  • Portail utilisateur de production

En cas de création d’un template email, un « header » et un « footer » devront être créés. Vous pouvez par exemple intégrer votre logo en Header, et vos conditions de contact ou mentions légales en Footer.

4/ Paramétrage des scénarios de notification

• Accès Scénarios de notification – Portail utilisateur de RCT
• Accès Scénarios de notification – Portail utilisateur de PROD

Pour spécifier à la plateforme les conditions d’envoi et destinataires de vos notifications, vous devez créer un scénario intégrant une ou plusieurs règles d’envoi.

Après avoir choisi le type de scénario souhaité, vous pouvez créer une règle d’envoi. Cette règle est scindée en deux parties : le “QUAND” va permettre de définir l’évènement déclencheur de la notification tandis que le “ALORS” va permettre de choisir les actions qui seront effectuées lorsque l’évènement se produira.

4.1/ Dans la partie « QUAND » :

• Tapez « # » pour visualiser l’ensemble des attributs disponible pour votre scénario
• Utilisez des opérateurs logiques pour constituer votre règle :
  • Pour les chaînes de caractères (doivent être entourés de guillemets «  ») :
    • = (égal)
    • != (différent de)
    • in (dans ce qui va suivre)
    • not in (pas dans ce qui va suivre)
  • Pour les nombres (attention les montants doivent être renseignés en centimes) :
    • = (égal)
    • != (différent de)
    • < (plus petit que)
    • <= (plus petit ou égal à)
    • in (dans ce qui va suivre)
    • not in (pas dans ce qui va suivre)
  • Pour les boolean (affirmations en vrai ou faux) :
    • = (égal à)
    • != (différent de)
• Vous pouvez utiliser des conditions pour compléter votre règle :
  • AND (pour ajouter une autre condition d’activation)
  • OR (pour ajouter une autre possibilité d’activition)

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 ou plusieurs fois OR, il sera également nécessaire de prioriser chaque partie.

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 obligatoire de d’abord tester sa règle avec le bouton « tester ». Cela va permettre de vérifier que votre règle est grammaticalement correcte. Attention, cela ne garantit pas que votre règle correspond à ce que vous souhaitiez faire.

4.2/ Dans la partie « ALORS » :

Le “ALORS” va permettre de choisir le destinataire et le template utilisé pour la notification. 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 (transaction carte, demande de paiement, remboursement …).

1/ Organisation des services anti-fraude

Les services anti-fraude sont segmentés en 4 outils :

• 1/ Liste blanche (whitelist)
  Le but de la « whitelist » est de rendre sélective l’application d’une règle d’acceptation.
  La règle définie devient inopérante pour des clients identifiés, VIP ou reconnus de confiance qui sont intégrés à une « whitelist ».
  Les « whitelists » portent sur les données spécifiques d’un client, comme le numéro de sa Carte Bancaire ou son adresse IP.
  Cette fonctionnalité permet d’être moins restrictif sur des populations d’utilisateurs.
• 2/ Liste noire (blacklist) :
  Le service de « blacklist » permet de refuser les paiements.
  Tout comme pour les « whitelists », les « blacklists » portent sur les données propres au porteur de carte (Carte, IP, Tel, email).
• 3/ Règles d’acceptation des transactions :
  Cet outil permet de construire les règles spécifiques définissant les conditions d’acceptation d’un paiement.
• 4/ Scoring anti-fraude
  Le service de scoring permet de détecter les transactions potentiellement frauduleuses en se basant sur l’analyse croisée de plusieurs données liées aux paiements.

Les phases de traitement des transactions sont toujours exécutées dans cet ordre.

Dans le cas où les données d’entrée remplissent toutes les conditions des « whitelist » définies, le service de « blacklist » ne sera pas exécutée et la transaction sera opérée normalement.
Dans le cas où les données d’entrée remplissent une des conditions des « blacklist » définies et ne figurent pas dans le service de « whitelist », la transaction sera refusée et le service « règle d’acceptation » ne sera pas exécutée.
Chaque service est exécuté de façon descendante vis-à-vis de la hiérarchie des acteurs CentralPay, ce qui signifie qu’une plateforme peut appliquer les paramètres de ses services anti-fraude à ses marchands, mais que l’inverse n’est pas possible.

2/ Outil de scoring de fraude

CentralPay s’appuie sur un service de détection de fraude reposant sur des algorithmes de machine learning.

Ce moteur prédictif est constitué depuis un large échantillon de données fourni par CentralPay au format JSON et issues des données TRANSACTION / REFUND / DISPUTE.
Ce service s’appuie sur une classification comportementale liée au secteur d’activité du marchand.

Le moteur retourne une action et un score.

L’action invite le service de paiement à accepter ou refuser la transaction.

Le score classifie le niveau de risque en fournissant un pourcentage de probabilité de fraude. Ce score est ensuite interprété dans le moteur de règle.

Le score permet au marchand et à l’algorithme d’interagir ensemble pour s’améliorer.

Les scores sont classifiés ainsi :

• De 0 à 19 = risque faible
  Transaction acceptée
  Pas d’action
• De 20 à 59 = risque moyen
  Transaction acceptée
  Action : envoi événement avec détail du score pour revue manuelle et apprentissage
• +60 = risque élevé
  Transaction refusée
  Action : envoi événement avec détail du score pour revue manuelle et apprentissage

Ce service d’analyse d’exposition à la fraude analyse le contexte d’exposition au risque de fraude de chaque transaction. Ce service retourne un score qui permet de traiter automatiquement la réponse attendue dans le moteur de règle.

Le score repose sur l’analyse croisée des données suivantes :

• Indice de risque IP
• Détection de Proxy
• Détection réseau TOR
• Vérification de l’adresse IP
• Confidence factors
• Email checks
• Address & phone checks
• Adresse d’expédition à haut risque
• Géolocalisation des adresses IP
• Identification des équipements utilisés
• Adresse e-mail
• Type de navigateur
• Discordances de pays
• Distance de l’adresse d’expédition
• Distance de l’adresse de facturation
• Domaine e-mail
• Heure
• Montant de la commande
• Pays
• Numéro de téléphone
• Titulaire IP
• Titulaire de l’e-mail
• Vérification adresse CB

3/ Listes blanches et listes noires

3.1/ Liste blanche (Whitelist)

Le but de la « whitelist » est de rendre sélective l’application d’une règle d’acceptation. Cette règle devient inopérante pour des clients identifiés, VIP ou reconnus de confiance qui sont intégrés à une « whitelist ».

Le service anti-fraude passe ainsi à l’étape suivante.

Les « whitelists » portent sur les données spécifiques d’un client, comme le numéro de sa Carte Bancaire ou son adresse IP. Cette fonctionnalité permet d’être moins restrictif sur une population d’utilisateurs.

3.2/ Liste noire (Blacklist)

L’étape de la « blacklist » permet de refuser les paiements.

Tout comme pour les « whitelists », les « blacklists » portent sur les données propres au porteur de carte :

• Pays
• Régions géographiques
• Numéros de carte
• Numéros de téléphone
• E-mail
• Adresses IP
• IBAN

4/ Règles d’acceptation des transactions

Le moteur de règles d’acceptation est une brique applicative puissante et modulaire qui permet d’adapter le comportement lié au traitement à réaliser sur chaque transaction comme :

• accepter
• refuser
• alerter
• …

Ce service permet ainsi de définir des actions à réaliser sur chaque transaction depuis une large liste d’attributs disponibles : score de fraude, localisation du porteur, montant des ventes cumulées sur 7 ou 30 jours, client VIP whitelist, paramètre spécifique adressé par le marchand…

Une règle d’acceptation est une condition logique. Elle permet : d’autoriser, de restreindre, et/ou d’interdire des transactions.
Une règle se compose de 4 éléments : l’action, les attributs, les opérateurs, les valeurs.

La syntaxe d’une règle est la suivante :
« Action » « if » « Attribut » « Opérateur de comparaison » « Valeur de comparaison »

Exemple :

REFUSE if card_country != 'FRA'

La règle présentée dans cet exemple permet de refuser automatiquement les paiements lorsque le pays de la carte n’est pas la France.
La syntaxe de la grammaire choisie par la plateforme pour son moteur d’acceptation est très semblable à la syntaxe SQL (utilisée pour dialoguer avec les bases de données).

4.1/ Les actions disponibles

• ALLOW
  Autorise le paiement.
• REFUSE
  Refuse le paiement.
• ALERT
  Adresse une notification « webhook » de la transaction associée.

4.2/ Les attributs disponibles

En tapant « # », les attributs disponibles sont affichés.

Dans une règle, un attribut est toujours suivi d’un Opérateur de comparaison.

4.3/ Les opérateurs de comparaison disponibles

• = (égal)
• != (différent de)
• < (plus petit que)
• <= (plus petit ou égal à)
• in (dans ce qui va suivre)
• not in (pas dans ce qui va suivre)

Les opérateurs de comparaison = , != , > , < , >= et <= doivent être suivis d’une valeur.

Les opérateurs IN et NOT IN sont suivis d’une liste de valeurs de comparaison.
Une liste de valeurs est entourée par des parenthèses et les valeurs à l’intérieur de la liste sont séparées par des virgules.

Exemple :

REFUSE if #currency NOT IN ('EUR', 'USD', 'GBP', 'CHF')

L’exemple présenté ci-dessus permet de refuser tous les paiements dont la devise n’est pas l’Euro, le Dollar US, la Livre Sterling ou le Franc Suisse.

Cette syntaxe évite d’écrire plusieurs règles ou plusieurs conditions dans la même règle.

4.4/ Les valeurs disponibles :

En fonction du type de valeur, la syntaxe permettant de définir la valeur ne sera pas la même :

• Entiers (valeur numérique sans décimale) : syntaxe classique (ex : 100)
• Doubles (valeur numérique avec décimales) : la valeur est définie avec un point comme séparateur de décimale (ex : 12.32)
• Chaîne de caractères : la valeur est définie entre ‘quotes’ simples (ex : ‘FRA’)
• Booléens : la valeur est true ou false (ex : false)

ATTENTION : les valeurs de « montants » doivent être renseignées en centimes (ex : pour 10 € on renseignera une valeur de 1000).

4.5/ Les opérateurs logiques :

Les opérateurs disponibles sont AND et OR. Ils permettent de définir comment le moteur de règle va interpréter la succession de ces règles. Le « AND » permet une inclusion tandis que le « OR » une exclusion.

Exemple :

REFUSE if #amount < 1000 and #card_country != 'FRA'

L’exemple présenté ci-dessus permet de refuser les paiements dont le montant est inférieur à 10 € ET dont la carte n’est pas française. Si l’une ou l’autre des conditions définies n’est pas remplie, l’action ne sera pas exécutée.

1/ Introduction

Les reversements bancaires (ou « Payout ») sont des virements sortant de votre compte de paiement CentralPay vers le compte bancaire qui y est associé.

Ils peuvent être réalisés manuellement depuis le Portail utilisateur ou l’API Payment. Ils peuvent également être automatisés depuis le Portail utilisateur.

Depuis le Portail utilisateur, seuls les profils utilisateurs titulaires du compte (dit « Legal ») peuvent paramétrer et réaliser les reversements.

2/ Les deux modes de reversement

2.1/ Reversement automatique

Le titulaire du compte peut définir la périodicité : quotidien, hebdomadaire (choix du jour de la semaine, ex : chaque mardi) ou mensuel (choix du jour dans le mois, ex : le cinq du mois).
Le service PAYOUT automatique exécutera automatiquement à 01h00 du jour donné un virement des fonds disponibles sur votre compte de paiement.

Exemple d’un reversement hebdomadaire programmé le mardi :
CentralPay exécutera la demande de création du virement (PAYOUT) le mardi matin avec les fonds disponibles (AVAILABLE) sur le compte de paiement jusqu’au mardi 01h00.

2.2/ Reversement manuel (via BO ou API)

Vous avez la possibilité d’exécuter des payouts manuellement depuis le Portail utilisateur ou l’API CentralPay. Vous pouvez déterminer le montant à reverser (avec en maximum le montant disponible sur votre compte).

Attention, le PAYOUT ne sera exécuté immédiatement que s’il est effectué avant 05h00 le matin. À défaut, il sera exécuté le lendemain à 05h00 du matin également.

3/ Délais de disponibilité des fonds

Les reversements comprennent uniquement les fonds disponibles (ou « AVAILABLE ») de vos comptes de paiement. Les fonds issus d’une transaction par carte bancaire sont par exemple disponibles à J+2 : une transaction carte réalisée le lundi, apparaîtra en « Pending » le lundi, sera « Available » le mardi soir, le payout automatique sera effectué le mercredi matin à 00h05 et la réception du virement SEPA sur votre compte bancaire le jeudi.

NB : Le paramètre EscrowDate peut influer sur la date de disponibilité des fonds d’une transaction (concerne uniquement les partenaires AGENT).

4/ Création d’un reversement manuel

4.1/ Payout manuel par Portail utilisateur

Depuis le Portail Utilisateur > Administration > Mon compte> Reversements : cliquez sur « Transferts externes », sélectionnez le compte d’émission, le montant du reversement ainsi que l’IBAN destinataire, puis cliquez sur « confirmer le transfert ».

4.2/ Payout manuel par API

Consultez la rubrique développeurs du service Payout.

5/ Reversement en euros ou devises via le réseau SWIFT

Les virements bancaires internationaux sont gérés via le réseau SWIFT (contrairement au réseau SEPA pour les virements européens). Ces virements peuvent être émis depuis un très grand nombre de pays en EUROS ou dans d’autres devises.

Si vous disposez d’un compte en devises ou n’étant pas accessible via le réseau SEPA, vous pouvez réaliser vos virements via le réseau SWIFT. Contactez CentralPay pour en savoir plus.

Les virements bancaires du réseau SWIFT présentent des frais très largement supérieurs aux virements SEPA. Vous pouvez demander à CentralPay de paramétrer vos reversements automatiques afin qu'ils soient déclenchés à partir d'un certain seuil de fonds disponibles.

6/ Retours, statuts et webhooks

6.1/ Statuts

6.2/ Webhooks

1/ Introduction

Vous pouvez réaliser plusieurs exports de votre compte aux formats CSV, EXCEL, ou JSON depuis votre Portail utilisateur. Pour cela, paramétrez votre recherche avec les filtres disponibles sur la page de l’export souhaité, cliquez sur « Rechercher » puis « Exporter ». En quelques secondes, vous recevrez le fichier par email et pourrez le télécharger à tout moment depuis votre Portail utilisateur > Compte > Exports.

2/ Export comptable des opérations du compte

• Accès opérations – Portail utilisateur de RCT
• Accès opérations – Portail utilisateur de PROD

Cet export reprend l’ensemble des mouvements financiers débiteurs et créditeurs qui ont été réalisés sur votre compte : autorisations cartes, transactions cartes, transactions SDD, transactions SCT, transfers, payout, frais CentralPay…
Vous disposerez du détail de chaque opération afin que vous puissiez le rapprocher facilement à vos factures ou vos dossiers.

L’export contient les données suivantes :

3/ Télécharger le rapport financier mensuel

Chaque début de mois, en plus de la facture, un rapport financier est généré, puis mis à disposition dans l’espace sécurisé de votre compte (Administration > compte > documents > Rapports financiers). Il présente les montants totaux de crédit, de débit, de frais et de réserve de votre compte :

• Accès documents – Portail utilisateur de RCT
• Accès documents – Portail utilisateur de PROD

Pour bien comprendre votre rapport financier : A) Le total des montants acquis / reçus sur votre compte au cours de la période B) Le montant net reçu sur votre compte, déduction faite de l’ensemble des frais selon le calcul « B = A – I » C) Le montant de la réserve détenue en garantie au jour de clôture de la période D) Le montant des fonds disponibles au jour de clôture de la période E) La valeur totale des fonds disponibles et en garantie enregistrée dans les livres de CentralPay au jour de clôture de la période selon la formule « E = C + D » F) La valeur totale des fonds retirés / transférés à la banque du marchand pendant la période G) Le total des frais de service et commissions facturées sur les transactions définies dans la grille tarifaire H) Total des frais d’opérations techniques : frais d’autorisation cartes, de contestation, de payout… I) Total des frais techniques et commissions ou « I = G + H »

1/ Introduction

Vous pouvez réaliser plusieurs exports de votre compte aux formats CSV, EXCEL, ou JSON depuis votre Portail utilisateur. Pour cela, paramétrez votre recherche avec les filtres disponibles sur la page de l’export souhaité, cliquez sur « Rechercher » puis « Exporter ». En quelques secondes, vous recevrez le fichier par email et pourrez le télécharger à tout moment depuis votre Portail utilisateur > Compte > Exports.

2/ Export des transactions cartes

• Accès Transactions – Portail utilisateur de RCT
• Accès Transactions – Portail utilisateur de PROD

Cet export vous permet d’obtenir le détail des transactions cartes que vous avez réalisées au cours d’une période donnée.
Cet export simplifie la lecture de vos transactions carte en agrégeant les opérations d’autorisations et de débit, et présente des données complémentaires spécifiques aux transactions cartes.

L’export contient les données suivantes :

3/ Export des remboursements cartes

• Accès Remboursements cartes – Portail utilisateur de RCT
• Accès Remboursements cartes – Portail utilisateur de PROD

Cet export vous permet d’obtenir le détail des remboursements cartes que vous avez réalisées au cours d’une période donnée.

4/ Export des contestations de transactions cartes

• Accès Contestations cartes – Portail utilisateur de RCT
• Accès Contestations cartes – Portail utilisateur de PROD

Cet export vous permet d’obtenir le détail des contestations de transactions cartes (disputes/chargebacks) que vous avez reçues au cours d’une période donnée.

5/ Export des abonnements (cartes et SDD)

• Accès Abonnements – Portail utilisateur de RCT
• Accès Abonnements – Portail utilisateur de PROD

Cet export vous permet d’obtenir le détail des abonnements cartes et SDD que vous avez réalisés au cours d’une période donnée.

1/ Introduction

Les webhooks permettent d’adresser des notifications HTTP sur les URL de votre choix en fonction des évènements (ou « Events ») qui surviennent sur votre compte CentralPay. Ces évènements correspondent à la création, au changement de donnée ou au changement de statut d’un objet des API CentralPay.

Le service permet ainsi d’avertir en temps réel votre système d’information, dès qu’une opération est réalisée sur votre compte CentralPay. Par exemple, une transaction réussie ou échouée, la création d’une nouvelle souscription (abonnement), un nouveau client (Customer), la réception d’un impayé… 

Les webhooks sont classés en deux catégories :

• liés aux Points de Vente « POS »
• liés aux « Comptes »

Le serveur distant doit confirmer la bonne réception de la requête en retournant un code 2XX. Dans le cas contraire, une nouvelle requête sera adressée toutes les 5 min pendant 2h.

Pour s’assurer de la bonne réception des hooks, nous vous conseillons d’utiliser le service Webhook Site. Entrez l’URL donnée par le site et l’adresse mail, et effectuez vos tests. Une fois que vous êtes satisfait des réponses hooks, vous pouvez remplacer l’adresse mail et l’URL par les vôtres et effectuez un nouveau test.

2/ Liste des Webhooks

Vous pouvez consulter la liste des webhooks depuis la rubrique Développeurs > Webhook notifications.

The Json « CardToken » object

The « CardToken » object represents a debit/credit card token.

Merchants usually want to be able to charge payment cards, IBAN or other without having to store sensitive data on their servers.
Token.js makes this easy in the browser, but you can use the same technique in other environments with our token API.

Tokens can be created with your publishable API key, which can safely be embedded in downloadable applications like iPhone and Android apps. You can then use a token anywhere in our API when a credit/debit card, bank account or any personal ID number is accepted.

You need to add a header "Origin" with an URL previously added in your Back Office as an Authorized Custom form Host.
For your tests, you can use the origin : https://example.centralpay.net.

You can store multiple Cards per Customer in order to charge the customer later on (subscription, etc.).

It can also be used to store multiple debit or credit cards on a recipient in order to transfer to these cards later.

Note: If the card is already registered for this merchant, the API will return the previous cardId registered (not a new one).

A dispute is opened when a customer questions a transaction with their bank or credit/debit card provider.

When the transaction is tagged as a dispute, you can respond to the dispute with evidence that shows the charge is legitimate. If the transaction cannot be proven legitimate, the dispute will become a chargeback.

L’API utilise un protocole HTTP pour transporter et renvoyer toutes les réponses formatées en JSON.
Les API CentralPay sont des API REST permettant de faciliter l’intégration de nos services de paiement.

CentralPay mets à disposition de ses utilisateurs deux API :

• L’API « Core Payment » : pour toutes les fonctions liées aux opérations de paiement
• L’API « Onboarding » : pour toutes les fonctions liées à la création de comptes de paiement et de monnaie électronique (accessibles aux partenaires uniquement)

1/ Fonctions

Toutes les fonctions utilisent les types « MIME » : « application/x-www-form-urlencoded » et « multipart/form-data ».

Les fonctions utilisent les méthodes suivantes :

• Méthode HTTP POST pour la création ou la mise à jour d’un objet
• Méthode HTTP GET pour la recherche d’objets
• Méthode HTTP DELETE pour supprimer des objets

2/ Authentification

L’API de CentralPay utilise l’authentification de base HTTP pour l’authentification. Toutes les demandes adressées à notre API doivent être authentifiées (intégrant le nom d’utilisateur et le mot de passe fournis par la plateforme) et doivent être effectuées via HTTPS.

Vous pouvez récupérer vos identifiants API depuis votre Portail utilisateur : Administration Mon compte Technique
Cliquez ensuite sur Identifiant API Modifier Générer Copiez le mot de passe API Mettre à jour

NB : Certains services comme le cardToken requièrent la déclaration de votre MerchantPublicKey, également disponibles depuis les liens présentés ci-dessus.

MerchantPublicKey

La MerchantPublicKey permet de s’authentifier sur le service API cardToken qui ne nécessite pas d’autre type d’authentification et permet d’identifier un marchand.
Cette clé est trouvable dans l’onglet Technique des détails de votre compte sur notre portail utilisateur :

3/ HTTP Request

Toujours utiliser HTTP-Header pour les formats de sérialisation (user_agent, …)

Le Content-Type (application/x-www-form-urlencoded ou multipart/form-data) doit être renseigné pour toutes les requêtes dans l’en-tête.

L’utilisation du champ « Idempotence-Key » dans l’en-tête HTTP permet d’identifier la requête qui a été envoyée.

Si la même valeur « Idempotence-Key » est envoyée à nouveau, la demande sera considérée comme déjà traitée et ne sera pas relancée.

Ce contrôle permet au commerçant d’éviter d’envoyer des entrées en double.

Cette clé doit être construite avec un hachage « sha1 » des paramètres de la demande (SANS date) concaténés comme ceci :

Idempotence-Key = sha1(card[number] + card[cvc] + card[expirationMonth] + card[expirationYear] + card[check] + merchantPublicKey)

NB : La clé "Idempotence-Key" est valable 24 heures.

4/ HTTP Response

Dans chaque réponse HTTP, le champ « Request-Id » est inscrit dans l’en-tête HTTP.

NB : Si vous avez une demande spécifique à envoyer via l'API REST de CentralPay, veuillez contacter le support ou votre référent CentralPay.

Le Portail utilisateur est une interface web connectée aux APIs de CentralPay. Il permet de consulter l’activité et d’administrer votre compte CentralPay. Les comptes ayant des droits « Partenaires » peuvent également consulter l’activité des comptes de leurs sous-marchands.

• Accès Portail utilisateur de recette (RCT)
• Accès Portail utilisateur de production (PROD)

1/ Fonctionnalités

Le Portail utilisateur permet notamment :

• De consulter les opérations comptables du compte
• De consulter les paiements par carte (« transaction »)
• De consulter les paiements par virement SEPA (« sctTransaction »)
• De consulter les paiements par prélèvement SEPA (« sddTransaction »)
• De créer et de consulter les demandes de paiement (« paymentRequest »)
• De créer et de paramétrer les profils clients (« customer »)
• De créer et de paramétrer les points de vente (« pointOfSale »)
• De paramétrer les notifications Smart Push (templates, scénarios …)
• D’initier et de gérer les paramètres de reversement (« payout »)
• De générer des exports et de télécharger les rapports financiers mensuels
• Pour les comptes « Partenaires » uniquement :
  • De créer et de consulter les demandes d’onboarding (« merchant-enrollment »)
  • De consulter les opérations et de paramétrer les comptes de leurs sous-marchands

NB : Les comptes ayant des droits "Participant" (sous-marchands/participants de partenaires) peuvent uniquement consulter les opérations dont ils sont bénéficiaires ("transfer") et gérer leurs paramètres de reversement ("payout").

2/ Les profils utilisateurs du Portail

Ils représentent des personnes physiques pouvant accéder à un ou plusieurs comptes CentralPay ainsi qu’à tout ou partie des services du Portail utilisateur.

2.1/ Gestion des profils utilisateurs « Legal » et « Natural »

• Accès Portail utilisateur de RCT – Gestion des profils utilisateurs BO
• Accès Portail utilisateur de PROD – Gestion des profils utilisateurs BO

Lors de la création du compte CentralPay, le responsable ayant réalisé l’onboarding (dirigeant ou personne physique disposant d’une délégation de pouvoir) se voit attribuer un profil utilisateur dit « Legal ». Il dispose ainsi de tous les droits administrateur du compte, mais également de droits légaux permettant de paramétrer les éléments les plus sensibles du compte :

• Paramètres du compte de paiement :
  • Changement d’IBAN de sortie (payout)
  • Changement des conditions de reversements sur compte bancaire
  • Mise à jour des documents de société
• Paramètres des utilisateurs :
  • Création de nouveaux utilisateurs « Legal »
  • [à compléter]

Une fois le compte créé, vous avez la possibilité de créer autant de profils utilisateurs que nécessaire en renseignant leur nom, leur prénom, leur email et leur rôle utilisateur (définissant les droits qu’ils auront sur le compte). Les profils ainsi créés sont nommés « Natural ».

NB : Si vous disposez de plusieurs comptes CentralPay et que vos équipes doivent avoir accès à ces différents comptes, créez leur profil utilisateur depuis l’un d’entre eux, puis demander à CentralPay d’affecter leur profil à vos autres comptes. Ils bénéficieront ainsi d’un unique centralisé pour tous ces comptes.

2.2/ Gestion des rôles et droits des profils utilisateurs « Natural »

• Accès Portail utilisateur de RCT – Gestion des rôles utilisateurs BO
• Accès Portail utilisateur de PROD – Gestion des rôles utilisateurs BO

Les droits des profils utilisateurs « Natural » sont régis par leur rôle utilisateur. Le rôle comprend une liste de droits (lecture seule, création, modification, suppression) paramétrables par service (transaction, demandes de paiement, règles d’acceptation…). Ces droits peuvent être différents en fonction des services sélectionnés.

Les utilisateurs disposant des droits nécessaires peuvent créer des rôles pour chaque équipe de leur entreprise, cependant des rôles préétablis sont disponibles nativement :

• Standard Admin : Accès complet à toutes les fonctionnalités du Portail utilisateur (excepté les fonctionnalités admin). Attention, ce rôle comprend des accès à des services sensibles comme les règles d’acceptation, les whitelists, les blacklists, les créations d’utilisateurs Portail utilisateur, les créations de rôles utilisateurs du Portail, la création et la gestion d’utilisateurs API …
• Standard read only : [à compléter]
• [à compléter]

Contactez le service client CentralPay si vous avez besoin d’aide pour la création de rôles personnalisés.

Quelques précisions importantes concernant les rôles :

• Les rôles sont cumulables, un utilisateur peut ainsi se voir assigner plusieurs rôles
• Les droits des rôles sont héritables, ainsi un utilisateur ayant le droit de créer d’autres profils utilisateurs ne pourra affecter qu’un rôle similaire ou inférieur au sien.

2.3/ Gestion des catégories de point de vente

• Accès Portail utilisateur de RCT – Gestion des catégories de point de vente
• Accès Portail utilisateur de PROD – Gestion des catégories de point de vente

Si vous avez le besoin de limiter l’accès d’utilisateurs à certains points de ventes, vous pouvez créer des catégories, les affecter à vos points de ventes puis les affecter à vos profils utilisateurs.

Exemple : un utilisateur ayant des droits de création de demandes de paiement ne pourra le faire que sur les points de ventes de sa catégorie. Il ne pourra également visualiser que les demandes de paiement émises via les points de vente de sa catégorie.

Contactez le service client CentralPay si vous avez besoin d’aide pour la création de catégories de point de vente personnalisées.

3/ Liste des types d’opérations visibles sur le Portail utilisateur

Le portail client CentralPay est l’interface des profils clients (Customer). Il permet à vos clients de :

• consulter leur historique de paiement,
• d’administrer leurs opérations en cours (mise à jour de leur moyen de paiement par défaut, résiliation d’abonnement…)
• mais aussi d’interagir avec vous en cas de question concernant une opération (formulaire de contact).

Ce portail est principalement utilisé pour l’administration des paiements récurrents par les clients. Les équipes conformité de CentralPay peuvent requérir que l’URL de ce portail soit intégrée dans le pied de page ou les conditions générales de votre site marchand.

Pour s’y connecter, vos clients ont deux options :

• Via la page d’accueil du portail Client, en renseignant les informations d’un de leurs paiements opéré avec votre compte CentralPay :
  • Accès portail client de RCT : https://test-customer.centralpay.net/home
  • Accès portail client de PROD : https://customer.centralpay.net/home
• En direct via le lien communiqué dans les emails automatique de création d’abonnement / de paiement fractionné, ou en intégrant le CustomerID visible dans votre Portail utilisateur > Compte > Customer > Détail > CustomerId :
  • Accès portail client de RCT : https://test-customer.centralpay.net/customer/?uuid=[CustomerId]
  • Accès portail client de RCT : https://customer.centralpay.net/customer/?uuid=[CustomerId]

Le portail d’inscription de CentralPay permet la création d’un Compte CentralPay et d’un compte de paiement : de la création du profil utilisateur, jusqu’à la contractualisation, en passant par la collecte du KYC/KYB. Il interagit avec l’API Onboarding de CentralPay.

Pour les comptes « Partenaires », il permet donc de créer des sous-marchands facilement depuis un portail hébergé par CentralPay, et d’ainsi éviter une intégration complète de l’API Onboarding.

Pour adresser un lien d’onboarding à l’un de vos futurs sous-marchands, vous pouvez utiliser le service de création de compte de paiement.

• Accès au portail d’inscription de RCT
• Accès au portail d’inscription de PROD

1/ Les deux modes d’intégration de Smart Collection

La solution Smart Collection permet d’encaisser des paiements depuis divers moyens de paiement.

Vous pouvez au choix :

• créer et intégrer vos propres parcours de paiement (intégration CUSTOM), en consommant les services API de chaque moyen de paiement :
  • Transaction par carte
  • Transaction par virement
  • Transaction par prélèvement SEPA
• utiliser nos parcours de demande de paiement sécurisés (intégration SMART), grâce à notre service dédié :
  • Demandes de paiement (PaymentRequest)

NB : si vous choisissez l’intégration SMART, certaines fonctionnalités spécifiques comme les R-transactions, la gestion des libellés bancaires, la gestion des IBAN Virtuels… sont présentées dans la documentation dans les rubriques CUSTOM dédiées à chaque moyen de paiement.

2/ À propos de l’intégration SMART

La demande de paiement permet de générer un lien de paiement menant à une page de paiement hébergée par CentralPay. Votre client peut ainsi vous régler selon les conditions de règlement que vous avez déterminé (moyens et modes de paiement autorisés, délais de règlement …). Les transactions ainsi créées sont automatiquement liées à la demande de paiement et permettent d’actualiser son statut (non payé, partiellement payé, payé…).

La demande de paiement doit être alimenté des conditions de règlement de votre panier ou de votre facture :

• Montant à régler
• Moyens de paiement acceptés (carte, virement, prélèvement, initiation de paiement)
• Modes de paiement acceptés (unitaire, par abonnement, paiement fractionné…)
• Référence de commande
• Description de commande
• Coordonnés clients
• Délais de règlement autorisé
• Délais d’expiration du lien
• …

Le lien de paiement peut être adressé à vos clients depuis :

• vos tunnels de vente ou interfaces web,
• vos outils de communications (email, sms, courriers via QR code…)
• le service de notifications email / sms de CentralPay

La page de paiement permet ensuite au client de réaliser sa ou ses transactions :

• Visualisation des informations de la demande de paiement
• Sélection du moyen ou mode de paiement
• Renseignement des données clients
• Renseignement des coordonnées de paiement

1/ Introduction

La demande de paiement (ou PaymentRequest) est le service vous permettant de générer des liens de paiement. Vous pouvez créer des demandes de paiement par API ou via le Portail utilisateur. La demande de paiement peut également être couplé au service de notification de CentralPay, vous permettant d’adresser facilement un lien de paiement par email ou sms à vos clients et de programmer des relances automatisées.

2/ Création par API

2.1/ Créer une « PaymentRequest »

Vous trouverez ci-dessous les moyens de paiement disponibles et les valeurs API correspondantes dans le service PaymentRequest :

Si vous souhaitez autoriser plusieurs moyens ou modes de paiement dans votre PaymentRequest, vous devez renseigner plusieurs fois l’objet paymentMethod[].

Exemple :
paymentMethod[]=TRANSACTION
paymentMethod[]=SCT_TRANSACTION

Attention, certaines combinaisons de moyens ou modes de paiement peuvent rentrer en conflits et votre PaymentRequest pourra retourner une erreur. Par exemple, vous ne pouvez pas autoriser une TRANSACTION et une SUBSCRIPTION, cependant vous pouvez autoriser une TRANSACTION et un INSTALLMENT.

Voici les informations principales concernant d’autres valeurs à renseigner lors de la création d’une PaymentRequest :

NOTE : pour les transactions par virement SEPA, vous pouvez définir si vous souhaitez afficher l’IBAN Virtuel dédié au Customer ou générer un IBAN Virtuel à usage unique (SCT) depuis les paramètres de vos Points de Vente.

2.2/ Envoyer une PaymentRequest par email / sms

Lors de sa création, vous pouvez demander à CentralPay d’adresser la demande de paiement à votre client. Il existe deux méthodes d’envoi :

• Via le mailer par défaut des PaymentRequest : CentralPay adresse la demande de paiement depuis un modèle d’email/sms standardisé et depuis l’email expéditeur renseigné dans votre point de vente (ou à défaut l’email expéditeur de CentralPay « no-reply@centralpay.eu »).
  • Pour cela vous devez [à compléter]
• Via le service de notification email/sms de CentralPay : CentralPay adresse la demande de paiement selon le scénario et les modèles de communication que vous avez paramétrés. Ce service permet notamment l’automatisation de relances clients, basés sur les paramètres de la demande de paiement (délais de paiement, avancement du paiement…).
  • Pour cela vous devez [à compléter]

2.3/ Fonctions spécifiques

Demande de paiement à montant libre (multi-moyens de paiements)

Il est possible d’autoriser la modification du montant à régler (avec pour maximum le montant initial), afin que vos payeurs puissent régler la somme due depuis plusieurs moyens de paiements ou à des moments différents.

Par exemple sur une demande de paiement de 500€ :

• Régler 250€ en virement puis 250€ en carte
• Ou 300€ avec une première carte puis 200€ avec une autre.
• Ou régler 350€ avec une carte, puis revenir plus tard pour régler les 150€ restants avec cette même carte.

Pour ce faire vous devez [à compléter]

Envoyer une demande de paiement à plusieurs destinataires

Il est possible d’adresser une demande de paiement à plusieurs destinataires avec un montant différent à régler pour chacun d’entre eux. Ainsi :

• 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é 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

Pour ce faire vous devez [à compléter]

3/ Création depuis le Portail utilisateur

3.1/ Création et types de demandes de paiement

• Accès Demandes de paiement – Portail utilisateur de recette
• Accès Demandes de paiement – Portail utilisateur de production

Vous pouvez créer une demande de paiement depuis le Portail utilisateur > Demandes de paiement > Liens de paiement > Créer. Les demandes de paiement créées depuis le Portail utilisateur sont obligatoirement adressées à vos clients par CentralPay. En fonction de vos besoins, vous devrez choisir l’un des types de demandes suivant :

• Demande instantanée : une demande simple, envoyée depuis les expéditeurs et les templates emails / sms standards de CentralPay.
• Demande programmée : une demande avancée, utilisant les modèles de communication, scénarios et règles d’envoi/de relance que vous aurez préalablement paramétrés depuis le service de notifications email/sms de CentralPay. Une demande programmée adressée sans avoir sélectionné de scénario de notification sera automatiquement requalifiée en demande instantanée.

Une fois créée, vous pouvez accéder à la page de paiement en cliquant sur le détail de la demande de paiement > Formulaire de paiement. Ainsi, vous pourrez retransmettre à votre client l’URL de la page en cas d’erreur d’envoi.

3.2/ Les profils de demandes de paiement

Afin de faciliter la création de demandes de paiement, vous avez la possibilité de créer des profils prédéfinis intégrant les principaux paramétrages de la demande :

• Point de vente
• Devise
• Langue
• Moyens de paiement autorisés
• Limite de paiement (délais de paiement contractuel)
• Expiration du lien (délais avant expiration du lien)
• Scénarios de notification
• Reroutage de l’email de confirmation de paiement
• Règles d’affichage (paramètres de la page de paiement)
• Création de Customer
• Pièces jointes

Vous pouvez ensuite utiliser ce profil lors de la création de vos demandes de paiement programmées via le Portail utilisateur, ou via import de fichiers plats.

3.3/ Création de demandes de paiements par import de fichiers plats

Depuis le Portail utilisateur > Demandes de paiement > Liens de paiement > Importer, vous pouvez déposer un fichier d’importation de demandes de paiement. Cette utilisation peut être recommandée pour les entreprises souhaitant adresser en fin de mois et relancer automatiquement une liste de créanciers.

Vous pouvez télécharger le modèle de fichier ci-après :

• Modèle au format CSV
• Modèle au format JSON

Quelques informations importantes :

1/ Introduction

La page de paiement (aussi appelé SmartForm) est une page hébergée et sécurisée par CentralPay destinée à la collecte des données clients et de leurs coordonnées de paiement. Générée via le service de demande de paiement, elle permet à vos clients de visualiser les détails de cette demande (montant, référence de commande…) et de sélectionner un moyen de paiement autorisé avant de passer à l’étape de règlement.

2/ Paramétrage de la page

• Accès paramétrage formulaire – Portail utilisateur de RCT
• Accès paramétrage formulaire – Portail utilisateur de PROD

Vous pouvez créer un ou plusieurs modèles de page afin de personnaliser votre parcours de paiement. Ci-dessous la liste des éléments paramétrables sur la page :

3/ Personnalisation du logo affiché sur le SmartForm

Le logo affiché sur le SmartForm est celui que vous aurez renseigné dans les paramètres du point de vente utilisé pour votre demande de paiement. Par défaut, le logo de CentralPay est affiché.

1/ Statuts liés aux demandes de paiement

2/ Webhooks liés aux demandes de paiement

Les demandes de paiement permettant indirectement la création de transactions cartes, SCT et SDD mais aussi d’autres objets comme les Customer, Subscription ou Installment, selon les cas d’usages, il peut être utile de suivre les webhooks associés.

Webhooks « PaymentRequest »

Webhooks « Transaction »

Webhooks « SCT Transaction »

Webhooks « SDD Transaction »

Webhooks « Customer »

Webhooks « Subscription »

Webhooks « Installment »

Voici les étapes d’entrée en relation vous permettant d’accéder à la plateforme CentralPay. Notez que pour les partenaires, des étapes complémentaires peuvent être demandées.

1. Qualification de votre projet
   Les équipes commerciales qualifient votre projet lors d’un échange email ou d’un appel visio : parcours de paiement et moyens de paiement souhaités, méthodes d’intégration possibles, typologie de clients adressé, volumétrie de votre projet…
2. Acceptation de l’offre commerciale
   Les équipes commerciales vous adressent nos offres commerciales correspondant à vos besoins et votre activité. En retour, elles attendent de votre part le choix de l’offre et un premier accord de principe.
3. Analyse risque de votre projet
   Votre structure et votre projet sont analysées par nos équipes conformité afin de déterminer si nous pouvons entrer en relation d’affaires, et selon quelles conditions (mesures de gestion du risque financier, de gestion de la fraude…)
4. Initiation du projet
   Vous recevez les accès à votre environnement de test et aux documentations correspondantes afin de commencer votre intégration CentralPay. Si vous avez souscrit à l’une de nos offres d’accompagnement, une réunion d’initiation du projet est organisée avec vos référents CentralPay (service commercial, service client et service intégration). Cette réunion permet notamment de guider vos équipes techniques dans leur appréciation des API CentralPay, et de prévoir les paramétrages à réaliser sur votre compte (notifications, reversements, profils utilisateurs…).
5. Création du compte CentralPay
   En parallèle de l’intégration technique, le service client CentralPay adressera un lien d’inscription permettant la création de votre compte au responsable légal de votre structure. Il devra soumettre les informations et les documents justificatifs de votre structure avant de signer électroniquement le contrat CentralPay. Suite à l’inscription, des documents supplémentaires peuvent être demandés par le service conformité de CentralPay.
   • Consulter le contrat cadre de services de paiement
   • En cas de besoin, le responsable légal de votre structure peut désigner un mandataire pour réaliser l’inscription CentralPay et être titulaire du compte CentralPay à sa place. Un modèle de délégation de pouvoir est disponible sur demande.
6. Mise en production
   Après avoir validé votre compte, votre intégration et le règlement de vos factures en attente, une date de mise en production vous sera demandée. À cette date, votre compte sera débloqué et vous pourrez encaisser vos premières transactions.

1/ Description du modèle

Le modèle « Marchand » est adressé aux personnes morales réalisant des opérations d’encaissement pour compte propre (vente de biens ou de services). Il vous permet d’accéder à la solution Smart Collection, incluant notamment :

• Le compte CentralPay
• Les services liés au compte
• Le service d’encaissement Smart
• Le service de transaction par carte
• Le service de transaction par virement
• Le service de transaction par prélèvement SEPA

2/ Frais et commissions

CentralPay vous facture un forfait plateforme fixe ainsi que les frais de service liés aux opérations réalisées sur votre compte. CentralPay prélève ces frais de service sur votre compte de paiement principal ou votre compte de commission dédié. En cas de fonds insuffisants, votre compte sera alimenté automatiquement par prélèvement SEPA ou une demande de virement SEPA vous sera adressée. Les frais mensuels fixes sont eux prélevés mensuellement par prélèvement SEPA, demandés annuellement par virement SEPA ou prélevés sur votre compte selon les conditions de votre contrat.

1/ Description du modèle

Le modèle « Intégrateur » est adressé aux éditeurs de solutions, souhaitant proposer une intégration technique clé-en-main de CentralPay à ses utilisateurs. Ils peuvent intégrer tout ou partie de la solution Smart Collection, incluant notamment :

• Le compte CentralPay
• Les services liés au compte
• Le service d’encaissement Smart
• Le service de transaction par carte
• Le service de transaction par virement
• Le service de transaction par prélèvement SEPA

Mais également tout ou partie de la solution Easy Wallet, incluant notamment :

• Les services de création de comptes
• Les services de transfert des paiements

2/ Spécificités lors de l’entrée en relation

L’intégrateur n’a pas à suivre les étapes d’entrée en relation classique.

Contrairement aux marchands ou partenaires, un intégrateur ne crée pas de compte CentralPay. Il permet uniquement à ses utilisateurs également marchands de CentralPay d’accéder plus facilement à notre plateforme technique via sa solution. CentralPay contractualise et facture ses marchands en direct, sans intervention de l’intégrateur.

Le marchand peut ensuite créer des accès API dédiés à l’intégrateur et lui communiquer afin qu’il renseigne son compte CentralPay via son intégration.

CentralPay est lié avec l’intégrateur par un contrat intégrateur spécifiant les conditions d’utilisation de nos API.

1/ Description du modèle

Le modèle « Partenaire » est adressé aux personnes morales souhaitant piloter des opérations d’encaissement pour compte de tiers (vente de biens ou de services). Il vous permet d’accéder à la solution Smart Collection, incluant notamment :

• Le compte CentralPay
• Les services liés au compte
• Le service d’encaissement Smart
• Le service de transaction par carte
• Le service de transaction par virement
• Le service de transaction par prélèvement SEPA

Mais également la solution Easy Wallet, incluant notamment :

• Les services de création de comptes
• Les services de transfert des paiements

2/ Explications du modèle de partenariat

Gérer des encaissements pour compte de tiers est une activité nécessitant un agrément hautement contrôlé et impliquant des responsabilités et des risques forts (blanchiment, financement du terrorisme, risque financier…).
En savoir plus sur les agréments de CentralPay

De ce fait, CentralPay est responsable des opérations de paiement réalisées par ses marchands et partenaires. Bien que de nombreuses opérations techniques puissent vous être déléguées, les opérations de paiement seront toujours effectuées par CentralPay.

Ainsi, pour limiter au maximum votre responsabilité, CentralPay doit avoir une relation directe avec vos sous-marchands.

Vos utilisateurs accèdent à leurs comptes CentralPay depuis votre environnement incluant des services API de CentralPay, et peuvent si besoin se connecter à notre Portail utilisateur. Vous disposez de vos propres conditions générales pour cette relation avec vos utilisateurs. Les frais que vous leur facturez pour accéder à vos services doivent être définis dans vos conditions générales.

Bien qu’en relation directe avec vos sous-marchands, CentralPay ne se substitue pas à votre rôle de partenaire. Nous entrons principalement en contact avec vos sous-marchands lors de la création de leur compte de paiement et lors des mises à jour règlementaires de leurs documents justificatifs.

Lorsque vos utilisateurs ouvrent des comptes CentralPay, ils acceptent et signent les conditions générales d’utilisation de CentralPay depuis notre portail d’inscription. Dans le même temps, ils acceptent que vous puissiez effectuer certaines opérations via votre intégration.

3/ Frais et commissions

Commissions partenaire : Vous facturez vos services à vos utilisateurs selon vos propres conditions générales. Vous pouvez préciser le montant de vos commissions dans chaque opération réalisée sur la plateforme. CentralPay se chargera de les prélever sur le compte de paiement de votre sous-marchand et de les transférer à votre compte de commission dédié. Notez que CentralPay peut contrôler vos opérations pour s’assurer que la règlementation soit respectée. Par exemple, CentralPay peut vérifier que vos commissions prélevées par le biais de la plateforme correspondent bien à vos conditions générales.

Frais CentralPay : CentralPay vous facture un forfait plateforme mensuel ainsi que des frais de service lié aux opérations réalisées pour vos sous-marchands. CentralPay prélève ces frais de service sur votre compte de commission. En cas de fonds insuffisants, votre compte sera alimenté automatiquement par prélèvement SEPA ou une demande de chargement par virement SEPA vous sera adressée. Le forfait plateforme sera lui prélevé mensuellement par prélèvement SEPA, demandé annuellement par virement SEPA ou prélevé sur votre compte de commission selon les conditions de votre contrat.

4/ Les trois types de partenaires

1. Le partenaire MOBSP
   destiné aux plateformes de ventes de biens ou de services standards (marketplace B2B ou B2C, éditeurs de solutions…). Ce modèle nécessite votre déclaration en tant que Mandataire en Opérations de Banques et Services de Paiement (MOBSP) auprès de l’ORIAS.
2. Le partenaire DME
   destiné aux plateformes de ventes de biens ou de services entre particuliers (marketplace C2C) ou des éditeurs de solutions souhaitant développer des services de porte-monnaie électronique pour leurs particuliers utilisateurs.
   Ce modèle nécessite la déclaration d’un statut de Distributeur de Monnaie Électronique par CentralPay à l’ACPR.
3. Le partenaire Agent
   destiné aux plateformes de ventes de biens ou de services souhaitant commercialiser des services de paiement ou des plateformes financières ayant besoin de piloter des transferts de valeurs avancés entre les comptes CentralPay de leurs utilisateurs.
   Ce modèle nécessite la déclaration d’un statut d’Agent Prestataire de Services de Paiement par CentralPay à l’ACPR, et son acceptation par cette dernière.

5/ Spécificités lors de l’entrée en relation

En plus des étapes d’entrée en relation classique, les partenaires doivent suivre des étapes complémentaires :

• Signature du contrat partenaire
  Les équipes commerciales de CentralPay vous adresseront un document à signer électroniquement avant l’étape d’initiation de votre projet.
• Déclaration en tant que Mandataire en Opérations de Banques et Services de Paiement auprès de l’ORIAS (partenaire MOBSP seulement)
• Déclaration en tant que Distributeur de Monnaie Électronique à l’ACPR (partenaires DME seulement)
• Demande du statut d’Agent Prestataire de Services de Paiement à l’ACPR (partenaires Agent seulement)

6/ Spécificités liées au suivi de l’activité

Il est important de noter que des réglementations s’appliquent à toute entité souhaitant devenir Agent ou DME d’un établissement financier, et que ces réglementations doivent être scrupuleusement respectées.

6.1/ Formation LCB-FT

À ce titre, une formation de deux (2) heures en matière de LCB-FT (lutte contre le blanchiment de capitaux et de financement du terrorisme) est dispensée par CENTRALPAY à tout nouvel agent ou DME, dans un délai de trois (3) mois à compter du début de son activité en tant que tel :

• Cette formation s’adresse aux dirigeants et aux membres du personnel du partenaire qui participent à la mise en œuvre des prestations externalisées.
• Le partenaire devra désigner un maximum de 10 personnes pour participer à la formation.
• La formation aura lieu à distance.
• À l’issue de la formation, CENTRALPAY remettra aux participants à la formation un support de formation
• CENTRALPAY s’engage à informer le partenaire de toutes modifications qui interviendraient en matière de LCB-FT, afin que le partenaire puisse procéder à l’actualisation des connaissances de ses salariés.
• Le partenaire s’engage à assurer la formation de tout nouvel employé.
• CENTRALPAY pourra exiger que le personnel du partenaire suive des formations supplémentaires tout au long de la relation d’affaires en cas d’insuffisance constatée.

6.2/ Reporting

Par leur statut régulé, les partenaires DME et Agent sont soumis au contrôle de leur établissement et ont un devoir de reporting régulier envers ce dernier.

Pour permettre à CENTRALPAY de contrôler les activités externalisées, le partenaire s’engage à communiquer à CENTRALPAY les reportings suivants :

• Un reporting trimestriel sur la gestion des réclamations :
  • date de réception
  • date de traitement
  • nature de la réclamation
  • solution apportée
  • date de résolution

• Un reporting trimestriel sur la gestion des remboursements (réalisés hors de la plateforme CentralPay) :
  • % de remboursement,
  • délai moyen de remboursement
  • avec une extraction des remboursements effectués

• Un reporting trimestriel sur la gestion des incidents :
  • En sus des déclarations d’incidents constatés au fil de l’eau

Lors de votre entrée en relation, CentralPay vous transmettra une liste et une trame de reporting que vous devrez alimenter et renvoyer périodiquement à CentralPay à partir de votre date de mise en production. Cette trame a été conçue pour simplifier au maximum les tâches de reporting qui vous incombent.

6.3/ Manquement contractuel

En cas de non-réalisation ou retard significatif vis-à-vis des devoirs de formation ou de reporting du partenaire, CentralPay se réserve le droit d’interrompre ou de résilier le contrat de partenaire.

Introduction

Avant de lire cette page, veuillez consulter la rubrique dédiée à l’entrée en relation pour les partenaires.

Les partenaires CentralPay basés en France opèrent avec le statut d’intermédiaires en opérations de banque et en service de paiement (IOBSP), plus précisément en tant que Mandataires en Opérations de Banques et Services de Paiement (MOBSP).

Pour devenir partenaire MOBSP de CentralPay, vous devez vous déclarer à l’ORIAS. CentralPay devra ensuite vous déclarer en tant que son mandataire. Votre partie peut être réalisée en quelques heures, celle de CentralPay prend quelques jours. L’ORIAS peut quant à elle prendre jusqu’à deux mois pour examiner votre demande.

Bien que ce processus vous incombe, CentralPay peut vous assister en cas de besoin. Contactez notre service client en cas de besoin.

1/ Préparez vos données

1.1 Obtenez votre attestation de mandat

Après avoir signé votre contrat de partenariat avec CentralPay :

1. Envoyez un e-mail à notre service client qui inclut votre raison sociale et votre numéro SIREN.
2. CentralPay vous répondra avec votre attestation de mandat. Vous aurez besoin de ce document pour l’étape 3.3.

1.2 Préparez vos documents justificatifs

Lors de l’étape 3.3 du processus d’inscription, vous devrez fournir les pièces justificatives suivantes :

• KBIS datant de moins de trois mois
• Justificatif d’aptitude professionnelle : diplôme dans une école de commerce ou de gestion agréée ou certification RNCP (NCF 122, 128, 313 ou 314, niveaux 7 à 5) ou reconnaissance par le CIEP pour les diplômes étrangers.

Si vous ne disposez pas d’un justificatif d’aptitude professionnelle accepté par l’Orias, envoyez un email à notre service client. CentralPay peut vous aider à suivre la formation nécessaire.

Voir l’image ci-jointe, faisant référence à la catégorie Niveau III – IOBSP (niveau 3).

2/ Créez votre compte ORIAS

2.1 Accéder au formulaire

1. Allez sur le site de l’ORIAS.
2. Faites défiler vers le bas jusqu’à voir la section Comment ça marche ?
3. Cliquez sur S’inscrire.

Vous serez redirigé vers le formulaire d’inscription.

2.2 Saisir les informations

1. Entrez votre numéro SIREN
2. Saisissez les informations sur votre entreprise. Assurez-vous de vous inscrire en tant que personne morale / entité juridique.
3. Saisissez les informations de votre représentant légal.
4. Saisissez les coordonnées de votre représentant légal.
5. Saisissez les coordonnées de votre entreprise, y compris votre site web si vous en avez un.
6. Entrez l’adresse de votre entreprise.
7. Vérifiez toutes les informations que vous avez saisies, puis cliquez sur Valider.

2.3 Connectez-vous à votre compte ORIAS

Vérifiez votre boîte de réception pour un email de l’ORIAS (no-reply-orias@orias.fr). L’email contient votre identifiant et un mot de passe provisoire.

1. Retournez sur le site de l’ORIAS
2. Cliquez sur Connexion / Login
3. Saisissez votre identifiant et votre mot de passe provisoire depuis votre email
4. Suivez les instructions sur votre écran pour modifier votre mot de passe, puis enregistrez-le

Après avoir enregistré votre nouveau mot de passe, vous serez redirigé vers votre espace compte ORIAS.

3/ Réalisez une nouvelle demande d’inscription

3.1 Enregistrez votre entreprise

1. Cliquez sur Nouvelle inscription pour démarrer votre inscription, un formulaire apparaît
2. Choisissez Activité IOB
3. Choisissez ensuite Mandataire non-exclusif en opérations de banque et en services de paiement (MOBSP)
4. Cliquez sur Soumettre

3.2 Fournissez des informations complémentaires

1. Sélectionnez la case précisant que vous complétez votre inscription à titre de Mandataire non exclusif en opérations de banque et en services de paiement
   • Si un autre type d’inscription est spécifié, utilisez le bouton Précédent de votre navigateur pour revenir à la page précédente et réessayez.
2. Pour la première question, choisissez la réponse : Je déclare que l’on ne me confie pas de fonds
3. Pour la deuxième question, choisissez la réponse : Accessoire, indiquant à l’ORIAS que les services financiers ne sont pas l’activité principale de votre entreprise.
4. Pour la troisième question, choisissez la réponse : Oui, indiquant à l’ORIAS que votre entreprise propose du crédit (ou d’autres services bancaires et de paiement) uniquement à titre de service secondaire.
5. Cliquez sur Aller à l’étape « Pièces justificatives »

3.3 Fournissez vos documents justificatifs

1. Soumettez votre KBIS
2. Soumettez votre mandat d’attestation, qui est le certificat de mandat de l’étape 1.1
3. Soumettez votre Capacité professionnelle pour « vous » (Niveau I IOBSP), qui constitue votre preuve d’aptitude professionnelle de l’étape 1.2.
4. Cliquez sur Aller à l’étape suivante

3.4 Payez votre inscription

La dernière étape consiste à payer votre inscription.

1. Notez que vous payez pour l’enregistrement de Mandataire non exclusif en opérations de banque et en services de paiement. Sans payer les frais, votre inscription ne peut être finalisée.
2. Choisissez de payer avec votre Carte bancaire, ou cliquez sur Choisir un autre mode de paiement pour payer par Virement (virement) ou Chèque (chèque).
3. Après avoir payé, cliquez sur Télécharger la facture pour télécharger votre reçu.
4. Cliquez sur Terminer la demande d’inscription pour finaliser votre inscription.
5. Vous recevrez votre numéro d’inscription ORIAS par e-mail, confirmant que votre inscription est terminée. Envoyez ce numéro au service client de CentralPay par email.

4/ CentralPay vous enregistre en tant que MOBSP

Après avoir envoyé à CentralPay votre numéro d’enregistrement Orias par email, CentralPay vous enregistre en tant que Mandataire non exclusif en opérations de banque et en services de paiement (MOBSP).

5/ L’ORIAS examine votre candidature

L’ORIAS examine vos documents et votre candidature pour s’assurer que votre dossier est entièrement conforme. L’ORIAS vous informera de sa décision finale par email. Si elle est approuvée, l’e-mail contient également la date à laquelle votre statut de MOBSP prendra effet.

N’hésitez pas à contacter l’ORIAS par téléphone (09.69.32.59.73) ou par email (contact@orias.fr) si vous ne recevez pas à temps les informations concernant votre candidature.

6/ Mettez à jour vos mentions légales

Après avoir reçu l’agrément de l’ORIAS et être devenu MOBSP, assurez-vous de mettre à jour vos mentions légales. Ajoutez quelque chose de similaire à l’exemple suivant au pied de page de votre site Web, dans votre page de mentions légales et partout où vous distribuez ou vendez des services de paiement.

[Raison sociale], société immatriculée au RCS de [ville d’enregistrement] sous le numéro [numéro RCS], et inscrite au Registre unique des Intermédiaires en Assurance, Banque et Finance sous le numéro d’immatriculation [numéro d’enregistrement ORIAS] en qualité de Mandataire non exclusif en opérations de banque et en services de paiement.

1/ Introduction

L’ACPR (Autorité de contrôle Prudentiel et de Résolution) est un organe de la Banque de France. En tant que régulateur, elle seule détermine la validation ou non des Agents d’un Établissement comme CentralPay. L’ACPR traite uniquement avec ses Établissements agréés, le futur Agent ne peut donc pas échanger en direct avec elle.

La déclaration d’un Agent Prestataire de Services de Paiement se déroule en trois étapes :

• Le montage et la soumission du dossier de déclaration : réalisé par CentralPay avec l’aide de son futur Agent,
• Le traitement des demandes de l’ACPR concernant le dossier : réalisé par CentralPay avec l’aide de son futur Agent,
• La décision d’acceptation : émise par l’ACPR à CentralPay.

2/ Responsabilités de l’Agent

CentralPay réalise tous les processus complexes, ou nécessitant de fortes compétences. Néanmoins, vous êtes toujours garant de la tenue d’un haut niveau d’exigence dans le suivi et l’application des règles de LCB-FT (Lutte Contre le Blanchiment et le Financement du Terrorisme). À ce titre, vous devez apporter à CentralPay des certitudes sur les conditions de réalisation des opérations qui passent par votre intermédiaire, notamment :

• L’activité de votre sous-marchand ;
• La réalité économique de l’opération ;
• La lutte contre la fraude.

Les Établissements régulés qui font appel à des Agents restent responsables des opérations réalisées par ces derniers. Un cadre juridique précis est donc mis en place.

Un statut d’agent passe par :

• La contractualisation d’un contrat Cadre d’Agent de paiement qui définit les relations entre les parties ;
• Des CGU vendeurs.

Dans le cas où un agent internalise certaines fonctions dévolues à CentralPay dans le cadre de ses obligations règlementaires, un contrat de Prestations de Services Essentiels Externalisées devra être signé. C’est par exemple le cas si l’agent internalise la gestion des KYC.

3/ Devenir Partenaire Agent CentralPay

Devenir Agent de CentralPay nécessite le suivi d’étapes qui s’étalent sur plusieurs mois.

Voici un guide qui permet de mieux comprendre les enjeux liés à l’acceptation, puis à l’instruction des dossiers de déclaration des Distributeurs.

3.1/ Résumé des étapes

1. Compréhension du modèle
   • Explication des services apportés par le partenaire
   • Définition de son modèle d’affaires
   • Validation par les services Juridique et Conformité de CentralPay
2. Offre commerciale
   • Présentation
3. Validation
   • Validation du Partenaire par les services Juridique et Conformité de CentralPay
   • Validation de la proposition commerciale et des conditions tarifaires par le Partenaire
4. Test & Intégration
   • Mise en place de la sandbox
   • Réunion de lancement de projet avec l’équipe technique
   • Phase d’intégration technique
5. Instruction du dossier ACPR
   • Collecte des éléments nécessaires à la constitution du dossier
   • Préparation du dossier d’agrément d’Agent
   • Présentation du dossier de déclaration de l’agent auprès de l’ACPR
6. Mise en production
   • Validation en environnement de test (environnement de recette)
   • Mise en production

3.2/ Pièces à fournir à CentralPay

1. Pré-constitution du dossier :
   • CGU service de paiement
   • Définition des activités régulées utilisées par le Partenaire, description des services attachés aux prestations régulées, modèle d’affaires
   • Organigramme de la société ou du groupe le cas échéant avec son effectif réparti par service
   • Structure de l’actionnariat
   • Flux prévisionnels qui seront confiés à CentralPay au cours des 3 prochaines années
   • Nombre d’enrôlements prévisionnels au cours des 3 prochaines années 
   • Reprise éventuelle de KYC existant dans le cadre d’une migration
   • Préparation du contrat d’Agent.

2. Déclaration de l’agent auprès du régulateur :
   • Signature du contrat d’Agent ;
   • Le Service Juridique CentralPay se charge de constituer le dossier de déclaration et collecte les pièces suivantes :
     • Kbis de moins de 3 mois de la société et des sociétés gérantes le cas échéant ;
     • Statuts à jour de la société et des sociétés gérantes le cas échéant datés et signés par un représentant légal ;
     • Pièce d’identité en couleur des dirigeants ;
     • CV des dirigeants daté et signé ;
     • Casier judiciaire des dirigeants ;
     • Déclaration de non-condamnation des dirigeants ;
     • Répartition de la détention de parts de la société ;
     • Kbis des personnes morales actionnaires le cas échéant et Organigramme Groupe si applicable ;
     • PV d’AG si des changements juridiques ont eu lieu récemment (fusion, actif inférieur à la moitié du capital social, changement de direction, etc.) ;
     • Peuvent être demandés également lors de l’instruction :
       • Derniers bilans et compte de résultats ;
       • États financiers de l’année en cours et/ou de l’année venant de s’écouler ;
       • Toute pièce jugée utile à la demande du régulateur.

3.3/ Délais d’instruction

Une fois la totalité des pièces collectées, le service Juridique instruit le dossier dans un délai d’environ 2 semaines.

L’ACPR dispose ensuite d’un délai de deux mois pour répondre, les premières questions arrivent généralement sous 30 jours.

L’ACPR adresse en général des questions complémentaires et/ou des demandes de documents complémentaires en fonction de la situation et/ou de l’activité de votre société.

3.4/ Instruction finalisée et agent déclaré

Une fois le dossier validé par l’ACPR, l’Agent est réputé pouvoir démarrer son activité avec CentralPay.

Votre société peut donc désormais commencer à encaisser via CentralPay et faire ouvrir des comptes de paiement à ses clients.

À l’issue de l’instruction par le régulateur et l’Agent validé, il est référencé dans les registres de l’ACPR et reçoit un numéro d’enregistrement qu’il doit utiliser dans ses communications et ses CGU.

3.5/ Particularités d’un agent spécialisé dans le domaine du télécom

Un agent travaillant dans le domaine du télécom, c’est-à-dire réalisant des encaissements via des appels sur des numéros surtaxés, se doit de produire un récapitulatif des minutes de téléphone réalisées sous chaque opérateur téléphonique.

Lors de la réception du virement de l’opérateur téléphonique chez CentralPay, ce récapitulatif doit être fourni à CentralPay. De plus, le calcul de la répartition des opérations devant être envoyées à chaque marchand via CentralPay doit également être envoyé au Service Conformité.

Le Service Conformité de CentralPay consigne ces informations et s’assure que les marchands ont bien été crédités de leurs encaissements.

1/ Introduction

Les Établissements émetteurs de monnaie électronique comme CentralPay peuvent mandater des Distributeurs de Monnaie Électronique (DME) afin de collecter des fonds et d’assurer les échanges permettant l’achat et le remboursement de ME dans un réseau de participants défini.

La déclaration d’un Distributeur de Monnaie Électronique se déroule en deux étapes :

• Le montage du dossier de déclaration : réalisé par CentralPay avec l’aide de son futur DME,
• L’instruction du dossier à l’ACPR : réalisé par CentralPay. Elle ne nécessite pas de validation particulière de l’ACPR.

2/ Responsabilité du partenaire DME

CentralPay réalise tous les processus complexes, ou nécessitant de fortes compétences. Néanmoins, vous êtes toujours garant de la tenue d’un haut niveau d’exigence dans le suivi et l’application des règles de LCB-FT (Lutte Contre le Blanchiment et le Financement du Terrorisme). À ce titre, vous devez apporter à CentralPay des certitudes sur les conditions de réalisation des opérations qui passent par votre intermédiaire, notamment :

• La réalité économique de l’opération ;
• La lutte contre la fraude.

Les Établissements régulés qui font appel à des distributeurs restent responsables des opérations réalisées par ces derniers. Un cadre juridique précis est donc mis en place.

Un statut de Distributeur de Monnaie Electronique passe par :

• La contractualisation d’un contrat Cadre de Distribution de Monnaie Électronique qui définit les relations entre les parties ;
• Des CGU d’utilisation de Monnaie Électronique.

Dans le cas où un DME internalise certaines fonctions dévolues à CentralPay dans le cadre de ses obligations règlementaires, un contrat de Prestations de Services Essentiels Externalisées devra être signé. C’est par exemple le cas si l’agent internalise la gestion des KYC ou réalise des interfaces de gestion qui ne permettrait pas à CentralPay d’assurer l’exécution du service sans le concours du PSEE.

3/ Devenir partenaire DME

Devenir Distributeur de CentralPay nécessite le suivi d’étapes qui s’étalent sur plusieurs semaines.

Voici un guide qui permet de mieux comprendre les enjeux liés à l’acceptation, puis à l’instruction des dossiers de déclaration des Distributeurs.

3.1/ Résumé des étapes

1. Compréhension du modèle
   • Explication des services apportés par le partenaire
   • Définition de son modèle d’affaires
   • Validation par le service Risque & Conformité de CentralPay
2. Offre Commerciale
   • Présentation
3. Validation
   • Validation du Partenaire par le service Risque & Conformité de CentralPay
   • Validation de la proposition commerciale et des conditions tarifaires par le Partenaire
4. Test & Intégration
   • Mise en place de la sandbox
   • Réunion de lancement de projet avec l’équipe technique
   • Phase d’intégration technique
5. Instruction du dossier ACPR
   • Collecte des éléments nécessaires à la constitution du dossier
   • Préparation du dossier
   • Présentation du dossier
6. Mise en production
   • Validation de la recette
   • Mise en production

3.2/ Pièces à fournir à CentralPay

Prochainement

1/ Introduction

Une transaction carte comprend une succession d’actions :

1. Authentification 3DS 2.0 :
   Elle permet de s’assurer que la personne réalisant la transaction est bien le titulaire de la carte. La banque du client analyse les nombreux facteurs liés au paiement adressés par CentralPay (adresse IP, localisation, appareil utilisé…) et les compare aux données habituelles de son client :
   • Si les données ne concordent pas ou que le montant de la transaction est important, elle requière une identification manuelle via un code adressé par SMS ou via son application bancaire (« authentification forte » ou « SCA »).
   • Sinon, elle autorise directement le paiement (« Frictionless »).
2. Autorisation bancaire :
   Demande effectuée par CentralPay à la banque du payeur permettant de vérifier la validité et la provision de sa carte. Les fonds « autorisés » sont bloqués jusqu’à la réalisation de la capture des fonds. Si aucune capture n’est réalisée sous un délai de 7 jours, les fonds « autorisés » sont libérés et le marchand devra renouveler son autorisation.
   Pour les activités éligibles (location, hôtellerie…), le service de « pré-autorisation » donne la possibilité au marchand d’étendre le délai d’autorisation jusqu’à 30 jours.
3. Capture :
   La capture permet d’initier le débit de la carte sur la base d’une autorisation ou d’une pré-autorisation. Un marchand peut réaliser une capture complète ou partielle du montant autorisé.

2/ Types et réseaux de cartes acceptés :

Les cartes de paiement sont émises par les banques ou les établissements de paiement agréés, elles peuvent être badgées par un ou plusieurs réseaux de carte (aussi nommés « Card Scheme »).

Les réseaux acceptés par CentralPay sont :

• Carte Bancaire
• VISA
• MasterCard
• American Express

En France, la majorité des cartes émises sont co-badgées CB et VISA ou CB et Mastercard. Dans ce cas, le client doit avoir la possibilité de choisir le réseau qu’il souhaite utiliser.

Les cartes peuvent être de débit ou de débit différé / crédit (en France la majorité des cartes sont de débit), et peuvent être des cartes de particulier (dit « Consumer ») ou des cartes de professionnels (dit « Corporate »).

À noter que ces paramètres impactent le coût de la transaction pour le marchand (interchange bancaire et frais de réseaux carte).

1/ Introduction

Le service API Transaction permet d’opérer une autorisation puis une capture de la carte de paiement de votre client. Les différents modes de paiement par carte sont pilotés via ce même service.

Pour initier la première transaction d’un client encore inconnu, vous devez d’abord collecter les données de sa carte de paiement en générant un « cardTokenId » via le service de tokenisation de CentralPay « token.js ».

Un objet « card » sera ensuite retourné en tant que « cardId », pourra être enregistré dans un « customer » et ensuite être utilisé lors des prochaines transactions de ce client (pour des paiements en 1 clic ou des paiements récurrents).

Attention, avec le Custom Form, vous devrez également intégrer le processus d’authentification 3DS 2.0 avant d’initier vos transactions.

Schéma de transaction avec « cardTokenId » via le service « token.js » :

Note : Si vous disposez déjà des données de la carte dans votre système et que vous disposez d’un agrément PCI-DSS level 1, vous pouvez directement utiliser le sous-objet « card » en adressant toutes les données de la carte de paiement (BIN, date d’expiration, CVC).

2/ Prérequis

• Déclarez les domaines autorisés
  Déclarez les domaines sur lesquels vos formulaires de paiement CUSTOM vont être hébergés.
  Allez sur votre Portail utilisateur > Administration > Mon compte > Onglet Technique > cliquez sur « Modifier » > Déclarez vos domaines dans « Hosts Custom Forms autorisés »
  • Accès Portail utilisateur de RCT – Compte > Technique
  • Accès Portail utilisateur de PROD – Compte > Technique
• Sécurisez vos pages de paiement
  Utilisez TLS (1.2 min) (Transport Layer Security) afin qu’elles utilisent les protocoles HTTPS requis par la norme
• Passez en revue et validez la conformité PCI de votre service chaque année
  Grâce à la combinaison de « CUSTOM + TOKEN.JS », vous gérez vous-même vos formulaires de paiement pour une expérience de paiement optimisée. Cette méthode implique que vous initialisez les paiements sur vos serveurs et vous devez vous conformer au niveau PCI-DSS SAQ A-EP. Vous pouvez télécharger le formulaire SAQ A-EP ici.

3/ Création d’un formulaire de paiement par carte (WEB)

Ce tutoriel explique comment utiliser le langage HTML et Token.js pour obtenir un cardTokenID afin de créer une transaction depuis votre propre formulaire de paiement CUSTOM.

Le Token.js est le JavaScript que nous mettons à votre disposition pour vous aider à implémenter le premier composant dont vous avez besoin pour créer un cardTokenID.

Une fois que vous obtenez un cardTokenId, vous serez en mesure d’initialiser une transaction pour débiter la carte de votre client.

Consultez nos exemples en ligne de formulaires CUSTOM FORM :

• Exemple de formulaire Custom Form sans 3DS 2.0
• Exemple de formulaire Custom Form avec 3DS 2.0

3.1 Créer un formulaire de paiement HTML

Contrairement à la page de paiement SMART FORM qui est généré et hébergé par CentralPay, le CUSTOM FORM doit être créé et intégré par vos soins. Vous devez donc générer le code HTML qui convient à votre parcours de paiement, avec notamment les champs suivants :

• Numéro de carte (16 digits pour CB, Visa, Mastercard – 15 digits pour Amex)
• Date d’expiration (MM/AAAA)
• CVC (3 digits pour CB, Visa, Mastercard – 4 digits pour Amex)

3.2 Envoyer les informations de carte avec le Token.js

Envoyez les données cartes du navigateur du client à la plateforme PCI-DSS de CentralPay qui vous adressera un cardTokenId en retour. Pour ce faire, vous devez ajouter dans le <body> le tag ci-dessous :

• Tag du Token.js de recette :

<script src="https://test-js.centralpay.net/js/token.js"></script>

• Tag du Token.js de production :

<script src="https://js.centralpay.net/js/token.js"></script>

Ajoutez également votre merchantPublicKey dans un tag séparé :

<script type="text/javascript">
  window.Centralpay ? Centralpay.card.setMerchantPublicKey('8ce4b92abd7c3110e2033ffbfa7cca0f097a66f1f1d267ff6c94429884ed82ac') : alert('Error loading html form');
</script>

/!\ La merchantPublicKey identifie vos requêtes vers la Plateforme. Remplacez celle présente dans l’exemple ci-dessus par la vôtre. Consultez notre rubrique sur l’Authentification de nos API pour connaitre comment la récupérer.

3.3 Réceptionner le cardTokenID dans votre système

Récupérez le cardTokenID qui vous a été retourné dans le JavaScript afin de pouvoir soumettre votre requête à la plateforme.

Toutes les données de la carte sont maintenant stockées dans cardTokenID pendant une durée de 5 min. C’est donc cette valeur que vous devrez transmettre à notre API et en aucun cas les données brutes de la carte bancaire.

3.4 Créer une transaction à l’aide de la cardTokenID

Maintenant que vous êtes en possession du cardTokenID, vous êtes prêts pour initialiser une transaction. À la différence des étapes précédentes qui se déroulent depuis le navigateur, celle-ci sera exécutée depuis vos serveurs.

Consultez les pages dédiés au mode de paiement par carte que vous souhaitez intégrer :

• Transaction par carte unitaire (standard, capture différée, vérification carte, MoTo, en 1 clic)
• Transaction par carte récurrente (abonnement, fractionné)

Ou consultez directement le swagger du service API Transaction pour avoir plus de détails techniques.

3.5 Sauvegarder les informations d’une carte dans un profil client

Le cardTokenId n’est utilisable qu’une seule fois. Si vous prévoyez d’utiliser les données de la carte ultérieurement (paiement en 1 clic, paiement récurrent…), vous devez donc créer un Customer et y enregistrer une Card.

Ainsi, la prochaine fois, au lieu d’utiliser un nouveau cardTokenId, vous utiliserez le customerID correspondant.

4/ Créer un formulaire de paiement par carte (APP)

Les marchands veulent généralement pouvoir débiter des cartes de paiement sans avoir à stocker des données sensibles sur leurs serveurs. Notre javascript Token.js rend cela simple depuis un navigateur web, mais vous pouvez utiliser la même technique dans d’autres environnements avec notre cardToken.

Ces tokens sont créés grâce à votre merchantPublicKey, qui peut être intégrée en toute sécurité dans des applications téléchargeables telles que les applications iPhone et Android. Vous pouvez ensuite utiliser ces Tokens pour initier vos transactions.

Vous devez ajouter un header « Origin » avec une URL précédemment déclaré dans vos domaines autorisés (voir 2/ Prérequis).
Pour vos tests, vous pouvez utiliser l’Origin : https://example.centralpay.net

Le protocole 3D Secure 2.0 permet de s’assurer que la personne réalisant la transaction est bien le titulaire de la carte. La banque du client analyse les nombreux facteurs liés au paiement adressés par CentralPay (adresse IP, localisation, appareil utilisé…) et les compare aux données habituelles de son client :

• Si les données ne sont pas concordantes ou que le montant de la transaction est important, elle requière une identification manuelle via un code adressé par SMS ou via son application bancaire (« authentification forte » ou « SCA »).
• Sinon, elle autorise directement le paiement (« Frictionless »).

Il existe deux types de 3DS, selon si vous souhaitez initier une transaction classique (pour laquelle le porteur est présent) ou si vous exécutez une échéance de paiement récurrent (pour laquelle le porteur n’est pas présent) :

• Le 3DS 2 « BRW » ou « Browser Authentication » (porteur participant – 1ère transaction)
  Représente la majorité des intégrations de 3DS 2. Il requiert l’authentification du client afin de vérifier qu’il est bien le porteur légitime de la carte au moment de la transaction. Il déclenche si nécessaire un challenge qui vérifie l’identité du porteur de carte (SCA).
  Découvrez comment intégrer le 3DS 2.0 BRW
  
• Le 3DS2 « 3RI Authentification » (porteur non participant – échéances de paiements récurrents)
  3DS Requestor Initiated (3RI) Authentications, ou Authentification Initialisée par le marchand lorsque le porteur n’est pas présent ou non participant.
  3RI offre la possibilité de générer les authentifications 3DS nécessaires sans que le client ne soit impliqué. Cela permet d’utiliser une authentification générée précédemment avec un client. Elle est utilisée dans les contextes suivants de paiements récurrents : Paiement fractionné, Abonnement, Refund, etc.
  Découvrez comment intégrer le 3DS 2.0 3RI

Selon les besoins de votre activité, CentralPay propose divers modes de transactions unitaires via son service API Transaction.

Attention, vous devez au préalable gérer la collecte des données carte de votre client en créant un formulaire de paiement Custom Form et intégrer l’authentification 3DS 2.0.

Les principes de base d’une transaction carte sont décrits dans la rubrique informations générales.

1/ Autorisation et capture instantanée

Pour réaliser un paiement simple par carte (autorisation puis capture instantanée) :

• Réaliser une Transaction en renseignant le paramètre « source » avec la valeur « EC »

2/ Autorisation et capture différée

Ce mode de transaction peut être utile si vous souhaitez bloquer les fonds de votre client avant de le débiter définitivement, le temps de la validation de votre commande par exemple. Ainsi, vous pouvez annuler l’opération sans être soumis aux frais de transaction ou de remboursement.

Pour réaliser un paiement par carte avec capture différée (autorisation puis capture différée), vous devez :

• Réaliser une autorisation en renseignant le paramètre « capture » de la Transaction avec la valeur « false ». Les fonds seront ainsi bloqués sur la carte du client.
• Puis débiter le montant souhaité en initiant une capture sur le « transactionId » reçu en précisant le montant souhaité (« amount »)

Vous avez 7 jours calendaires suivant l’autorisation pour réaliser la capture, à défaut les fonds du client seront libérés.

3/ Pré-autorisation et capture différée

Le service de pré-autorisation et capture différée (ou caution / PLBS) permet d’effectuer une pré-autorisation d’un certain montant, que vous pourrez ensuite capturer partiellement ou pleinement sous 30 jours. Durant cette période, les fonds vous sont garantis, ils sont donc bloqués sur la carte et ne peuvent être utilisés par votre client.

Ce service n’est accessible qu’à certaines activités autorisées (locations de véhicules ou de matériels, hôtellerie…)

Pour réaliser une pré-autorisation et capture différée, vous devez :

• Réaliser une pré-autorisation en renseignant le paramètre « source » de la Transaction avec la valeur « DP ». Les fonds seront ainsi bloqués sur la carte du client.
• Puis débiter le montant souhaité en initiant une capture sur le « transactionId » reçu en précisant le montant souhaité (« amount »)

Vous avez 30 jours calendaires suivant l’autorisation pour réaliser la capture, à défaut les fonds du client seront libérés.

4/ Vérification carte (empreinte sécurisée)

Le service d’empreinte & vérification carte permet d’effectuer une autorisation à 0€ avec authentification du porteur (3DS 2.0). Ainsi, vous disposerez des informations concernant la carte de votre client (carte de débit, de crédit, prépayée…), et vous vous assurerez qu’elle n’est pas frauduleuse (carte non volée, porteur identifié…). Ce service est généralement utilisé pour enregistrer une carte avec 3DS en vue d’un abonnement avec une date de démarrage différée.

Pour réaliser une prise d’empreinte & vérification carte (autorisation à 0€ sans capture), vous devez :

• Réaliser une Transaction en renseignant le paramètre « source » avec la valeur « RI »
• Nous vous recommandons également de créer un « customer » lors de la transaction, afin d’associer le « cardId » ainsi généré et de vous permettre un éventuel débit ultérieur de cette carte.

5/ Débit carte seul (MO/TO)

Le service de paiement MOTO (Mail Order / Telephone Order) permet d’effectuer une autorisation puis une capture d’une carte, sans la présence de son porteur. Il est généralement utilisé par les hôtels pour le débit de services ou de consommations additionnelles en fin de séjour.

Attention, ce service n’est accessible qu’à certaines activités autorisées (hôtellerie…), et apporte des résultats de conversion de moins en moins performants depuis la directive DSP2, car elle ne permet pas l’authentification du porteur de carte.

Pour réaliser un paiement MOTO, vous devez :

• Réaliser une Transaction en renseignant le paramètre « source » avec la valeur « MO » (Mail Order) ou « TO » (Telephone Order).

6/ Paiement par carte en 1 clic

Le paiement par carte en 1 clic consiste à enregistrer les données cartes de votre client, afin qu’il puisse régler sa commande sans avoir à les ressaisir. La ou les cartes du client sont stockées de manière sécurisée dans le Customer CentralPay. Il est dans ce cadre nécessaire de permettre à votre client de sélectionner la carte qu’il souhaite utiliser ou d’ajouter une nouvelle carte.

Pour réaliser un paiement par carte en 1 clic, vous devez :

• Sélectionner l’option « One-click » dans la configuration du point de vente.
• Vous assurer que vos customer ont une carte liée à leur profil.

Selon les besoins de votre activité, CentralPay propose plusieurs modes de transactions récurrentes :

• Abonnement depuis un modèle d’abonnement
  CentralPay gère le prélèvement des échéances selon un modèle d’abonnement que vous avez défini en amont.
• Abonnement depuis des transactions successives
  Vous pilotez le prélèvement de chaque échéance vous-même par API.
• Paiement fractionné
  CentralPay fractionne une somme due en plusieurs transactions et gère leur prélèvement, selon les conditions de règlement que vous avez renseigné.

Attention, vous devez au préalable gérer la collecte des données carte de votre client en créant un formulaire de paiement Custom Form, créer un profil Customer pour ce client, et intégrer les principes d’authentification 3DS 2.0.

Les principes de base d’une transaction carte sont décrits dans la rubrique informations générales.

Lors d’un paiement récurrent, votre client reçoit automatiquement un email contenant le détail de ses échéances. Ce mail contient également un lien vers notre Portail client qui lui permet de visualiser le statut de ses paiements récurrent, de changer sa carte bancaire et de résilier un abonnement si besoin est.

1/ Abonnement depuis un modèle d’abonnement

1.1/ Création

Vous devez d’abord :

• créer un formulaire de paiement Custom Form,
• créer un Customer contenant au moins une Card
• et réaliser une authentification 3DS 2.0 BRW.

Ensuite, le service d’abonnement (Subscription) vous permettra d’initier facilement un paiement par abonnement en se basant sur un modèle d’abonnement créé en amont depuis l’API CentralPay ou le Portail utilisateur.

1.2/ Cas d’intégration spécifiques

• Si le premier paiement de l’abonnement doit être d’un montant supérieur aux échéances suivantes (ex: frais d’inscription), vous pouvez d’abord initier une Transaction suivant votre authentification 3DS BRW, puis renseigner une date de démarrage (startingDate) dans l’objet Subscription.
• Si vous souhaitez simplement faire démarrer un abonnement à une date précise, vous pouvez d’abord réaliser une empreinte carte vérifiée suivant votre authentification 3DS BRW, puis renseigner une date de démarrage (startingDate) dans l’objet Subscription.

2/ Abonnement depuis des transactions successives

2.1/ Création

Vous devez d’abord :

• créer un formulaire de paiement Custom Form,
• créer un Customer contenant au moins une Card
• réaliser une authentification 3DS 2.0 BRW
• réaliser une première Transaction

Ensuite, vous pourrez initier vous-même les prochaines Transactions en utilisant l’authentification 3DS 3RI.

2.2/ Informations importantes

• pour garantir un taux de conversion optimum, le montant de la première transaction doit être supérieur ou égal aux montants des transactions suivantes réalisées avec l’authentification 3DS 3RI.
• la plateforme CentralPay ne considérera pas les transactions générées comme des « abonnements », ainsi les interfaces « Portail utilisateur » et « Portail client » afficheront ces opérations au même titre qu’une succession de transactions unitaires.
• avec ce modèle, le système d’automatisation des nouvelles tentatives ne s’appliquera pas en cas d’échec de prélèvement d’une de vos transactions.

3/ Paiement fractionné

3.1/ Création

Vous devez d’abord :

• créer un formulaire de paiement Custom Form,
• créer un Customer contenant au moins une Card
• et réaliser une authentification 3DS 2.0 BRW.

Ensuite, le service de paiement fractionné (Installment) vous permettra d’initier facilement un paiement fractionné en se basant sur les éléments renseignés dans votre requête.

Afin de pouvoir effectuer une transaction, ou créer un cardToken avec Apple Pay ou Google Pay, vous aurez besoin de mettre en place une configuration spécifique avec l’aide du support de Centralpay au préalable.

Une fois la mise en place faite, vous devez être en possession de votre token Apple Pay ou Google Pay.

Exemple :

1/ Apple Pay

– Création de CardToken avec votre token Apple pay chiffré.

Lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘applePayToken‘ au format JSON comprenant votre token Apple Pay qui inclus les éléments ‘paymentData‘, ‘paymentMethod‘ et ‘transactionIdentifier‘.
Vous pourrez ensuite effectuer une transaction à l’aide de votre cardToken normalement.

– Création de CardToken avec votre token Apple pay déchiffré.

Si vous avez déchiffré votre Token Apple Pay, lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘applePayTransactionId‘ ainsi que ‘amount‘ et ‘currency‘ de la future transaction. Les champs ‘card[]‘ seront renseignés avec les données déchiffrées. Les informations de sécurité (ECI et CAVV) doivent être passées si elles sont présentes dans le Token
Vous pourrez ensuite effectuer une transaction à l’aide de votre cardToken normalement.

– Création de Transaction avec votre token Apple pay chiffré.

Lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘applePayToken‘ au format JSON comprenant votre token Apple Pay qui inclus les éléments ‘paymentData‘, ‘paymentMethod‘ et ‘transactionIdentifier‘.

2/ Google Pay

– Création de CardToken avec votre token Google pay chiffré.

Lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘googlePayToken‘ au format JSON comprenant votre token Google Pay qui inclus les éléments ‘signature‘, ‘intermediateSigningKey‘, ‘protocolVersion‘ and ‘signedMessage‘.
Vous pourrez ensuite effectuer une transaction à l’aide de votre cardToken normalement.

– Création de CardToken avec votre token Google pay déchiffré.

Si vous avez déchiffré votre Token GooglePay, lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘googlePayMessageId‘ ainsi que ‘onlinePaymentCryptogram‘ et ‘eciIndicator‘. Les champs ‘card[]‘ seront renseignés avec les données déchiffrées.
Vous pourrez ensuite effectuer une transaction à l’aide de votre cardToken normalement.

– Création de Transaction avec votre token Google pay chiffré.

Lors de votre appel API, en plus des champs obligatoires, il faudra utiliser le champ ‘googlePayToken‘ au format JSON comprenant votre token Google Pay qui inclus les éléments ‘signature‘, ‘intermediateSigningKey‘, ‘protocolVersion‘ and ‘signedMessage‘.

1/ Remboursement

Vous pouvez rembourser une Transaction si celle-ci est « Cleared » via le service Refund ou depuis le détail de la Transaction dans le Portail utilisateur. Vous pouvez initier un remboursement total ou partiel en renseignant un montant.

Votre client recevra les fonds sur sa carte sous 3 à 5 jours ouvrés après l’opération. Votre compte de paiement est lui débité immédiatement, il doit donc être solvable pour pouvoir réaliser l’opération.

Vous ne pouvez pas annuler un remboursement une fois celui-ci réalisé.

2/ Crédit

Vous pouvez créditer la carte d’un client sans transaction initiale depuis le service Credit. Pour cela, il existe plusieurs solutions :

• Tokeniser une carte via le service cardToken pour ensuite la renseigner dans le service Credit

• Créer ou rechercher un Customer disposant d’une carte valide, puis renseigner son « customerId » ainsi que son « cardId » dans le service Credit

NB : ce service n'est disponible que pour des activités spécifiques, contactez CentralPay pour en savoir plus.

3/ Contestation

Pour tout paiement par carte, votre client a la possibilité de contester une transaction auprès de sa banque (opération nommée contestation, chargeback ou impayé) :

• pendant 120 jours à compter de la transaction sur les réseaux « Visa » ou « Mastercard »
• pendant 13 mois à compter de la date d’opération sur le réseau Français « Carte Bancaire ».

En France, une contestation n'est en principe autorisée que dans le cadre d'une utilisation frauduleuse de la carte (carte volée, prélèvements abusifs…). Cependant, dans d'autres pays européens, la contestation peut également être utilisée dans le cadre d'un litige commercial (service ou produit non rendu / non conforme).

En cas de contestation, CentralPay en est informé et crée automatiquement sur votre compte une opération de Dispute liée à la transaction contestée. Le montant de cette transaction vous sera débité afin de rembourser votre client. Des frais non remboursables s’appliquent également pour chaque contestation reçue.

À ce stade, le statut de la Dispute sera CHARGEBACK_NOTICED et vous pourrez consulter sur le Portail utilisateur ou via notre API le motif de contestation de votre client. Vous disposez ainsi d’un délai de 20 jours calendaires pour répondre en fournissant la preuve de livraison du service ou du produit. À défaut de réponse dans les délais impartis, il ne sera plus possible de répondre à la contestation.

Notez que dans le cadre des transactions non authentifiées (sans 3DS), vous devez également justifier du consentement du titulaire de la carte. Vous devez à minima prouver que le nom et prénom de votre client est bien le même que celui qui est indiqué sur la carte de paiement. 

Une fois votre réponse émise, celle-ci est étudiée par la banque de votre client avant d’adresser son verdict :

• Vous avez obtenu gain de cause, la contestation a été rejetée. Le montant de la transaction vous est remboursé et le statut de la Dispute passe en CHARGEBACK_WON.
• Vos preuves sont jugées insuffisantes, la contestation est maintenue. Le statut de la Dispute passe en CHARGEBACK_LOST.

NB : Il est possible, en amont d'une contestation, qu'un client réalise une demande d'information sur une transaction afin d'en connaitre les détails. CentralPay créera une opération Dispute avec statut RETRIEVAL_NOTICED. Vous devez répondre dans les 7 jours en fournissant la nature du service délivré, la preuve de consentement du client et/ou la preuve de livraison. Si votre réponse est acceptée, le statut de la Dispute passera à RETRIEVAL_CLOSE. À défaut de réponse, votre client pourra déclencher une contestation auprès de sa banque.

1/ Introduction

Quand une transaction par carte a été réalisée avec succès, CentralPay peut adresser un email de confirmation de paiement à votre client. Pour cela, vous devez l’activer en renseignant les paramétrages de l’email de confirmation dans votre Point de Vente.

Cet email est adressé par défaut à l’email du Customer associé à la transaction, mais vous pouvez renseigner la valeur receiptEmail de la transaction si vous souhaitez l’adresser à un autre.

2/ Paramétrage

L’email de confirmation possède une mise en forme standardisée affichant les différentes informations de paiement, vous pouvez cependant configurer plusieurs paramètres depuis le Portail utilisateur.

Le libellé de relevé bancaire correspond à la description qui sera affichée sur le relevé de compte bancaire de vos clients pour chacune de vos transactions par carte.

Lorsqu’un compte CentralPay « marchand » ou « partenaire » est créé, un libellé de relevé bancaire est défini automatiquement en utilisant le nom de votre premier Point de Vente :

Vous pouvez demander à CentralPay de modifier votre libellé, cependant il doit permettre à vos clients de vous identifier clairement ou d’accéder à votre site de réclamation.

Introduction

Dans le cadre d’une activité internationale, vos clients peuvent disposer d’une carte adossée à un compte bancaire en devises non Euros.

Quelle que soit votre intégration, ces clients pourront vous régler en Euros grâce au système de conversion automatique des réseaux carte (Visa, Mastercard, American Express). Vos clients porteront l’ensemble des coûts de conversion des devises, et vous recevrez des Euros sur votre compte CentralPay.

Dans certains cas, CentralPay peut vous permettre d’encaisser des transactions par carte bancaire dans différentes devises : Euros (EUR), Dollars (USD), Francs Suisses (CHF) et Livres (GBP). Contactez CentralPay si la gestion de transaction en devises est un enjeu pour votre activité.

Notez que dans ce cas, les coûts d’acquisition en devises (hors EUROS) sont soumis à des frais complémentaires et seront déduits du montant de vos transactions.

Les reversements (payout) par virement SEPA ne peuvent être réalisés que sur les valeurs disponibles en EUROS. Les valeurs hors EUROS sont reversées par virement SWIFT ayant des frais supérieurs. Il est cependant possible de programmer les reversements SWIFT afin qu'il ne soit réalisés qu'à partir d'un certain seuil, afin de mieux maitriser ses coûts de reversement.

1/ Introduction

Fonctionnement des OTA
Les grands OTA que sont Booking.com, Expedia.com, hotels.com ou Agoda.com peuvent collecter les règlements lors de la réservation. Dans ce cas, ils fournissent aux hôteliers, non pas les données de la carte du client, mais une alias, qui est une carte virtuelle ou VCC.

Une carte virtuelle ou VCC est généralement émise pour un usage encadré afin de limiter les risques de compromission.
Une carte virtuelle représente en quelque sorte l’alias d’une carte existante qui ne pourra être utilisé qu’à partir d’une certaine date et depuis un MCC défini. En l’occurrence, dans le secteur du tourisme, il est nécessaire d’avoir un contrat avec le MCC 7011 (HOTELS) pour pouvoir la débiter.
Ainsi, dans le cas où le numéro de carte tombait entre les mains d’une personne mal intentionnée, elle ne pourrait pas déclencher de débit sur la carte source.
Étant donné la nature spéciale des cartes issues par ces OTA, il est en général impossible de réaliser des demandes d’autorisation, de pré-autorisation ou de vérification au moment de la commande.

Si la carte n’est débitable que le jour de la réservation par un MCC 7011 par exemple, l’émetteur, en général MASTERCARD B2B PRODUCT, renverra un code d’erreur pour transaction invalide (12).

Cartes virtuelles Booking.com
Booking.com utilise des cartes virtuelles sur certaines destinations.  En fonction du paramétrage réalisé sur le site de l’hôtel, une réservation pourra être réalisée avec ou sans prise d’empreinte carte. Si l’hôtelier a choisi de demander un moyen de paiement, alors BOOKING.com génèrera une carte virtuelle et l’adressera à l’hôtelier ou à son prestataire technique. Avec la crise du covid19, booking n'autorise plus les débits de ses VCC qu'un jour après le checkin du client.
En savoir plus sur le fonctionnement des cartes virtuelles de booking.com

Cartes virtuelles Expedia
Chez EXPEDIA, il est possible de laisser le visiteur choisir entre la possibilité de payer à l’hôtel (Hotel Collect) ou de payer directement lorsqu’il réalise la réservation (Expedia Collect). Cette option est appelée Expedia Traveler Preference (ETP). Si un client utilise la méthode Expedia Collect, une carte virtuelle sera alors générée.
En savoir plus sur le fonctionnement des cartes virtuelles d'expedia.com

2/ Gestion des cartes virtuelles avec CentralPay

La meilleure méthode pour stocker une VCC et de pouvoir l’utiliser une fois disponible est de créer un « Customer » et de lui associer la carte concernée.

Deux options sont ouvertes :

• Soit la carte est débitable au moment de la création et une demande de vérification est réalisable à la création du Customer 
• Soit la carte n’est pas utilisable à la création du customer et la carte doit être créé sans vérification. Cela ne signifie pas qu’elle ne pourra pas être utilisée à terme. Cela veut simplement dire qu’elle ne doit être débitée qu’à une certaine date. En général, les OTA auront préalablement vérifié les données de la carte pour s’assurer qu’elle était débitable.

Ainsi, créer un Customer dans l’API CentralPay permet de tokeniser la carte virtuelle, sécuriser son stockage et de faciliter son utilisation lorsque les conditions d’acceptation initiales auront été réunies.

1/ Codes de retour banque liés aux transactions carte

Lorsqu’une transaction carte (objet « transaction ») est initiée, une demande d’autorisation est soumise à la banque émettrice de la carte. Cette dernière répond avec un code, permettant d’interpréter l’acceptation, le refus et la cause du refus de l’autorisation.

La banque du titulaire de la carte (appelée également banque émettrice) exprime son refus en fonction de choix qui lui sont propres et totalement indépendants de CentralPay. CentralPay n’est en possession d’aucune information complémentaire si une carte est refusée et n’a aucun moyen d’en obtenir.

Les principaux codes de retour banque :

2/ Statuts liés aux transactions carte

Statuts « Transaction »

Statuts « Refund »

Statuts « Credit »

Statuts « Disputes »

Statuts « Subscription »

Statuts « Installment »

3/ Webhooks liés aux transactions carte

Webhooks « Transaction »

Webhooks « Card »

Webhooks « Refund »

Webhooks « Credit »

Webhooks « Customer »

Webhooks « Dispute »

Webhooks « Subscription »

Webhooks « Installment »

1/ Introduction

Le virement bancaire est le moyen de paiement le plus répandu pour les règlements d’entreprises. Il consiste en un transfert direct des fonds d’un compte (bancaire ou de paiement) à un autre, sans utiliser de support additionnel comme une carte par exemple.

La personne physique ou morale qui demande l’émission du virement est dénommée le donneur d’ordre (ou l’émetteur), celle qui reçoit l’argent le bénéficiaire. Contrairement à un paiement par carte ou par prélèvement SEPA, seul l’émetteur lui-même peut initier un virement. Il se rend ainsi sur l’espace personnel de sa banque, déclare les coordonnées bancaires du bénéficiaire (IBAN + BIC + Nom de titulaire), puis renseigne un montant et une référence de virement.

Quelques informations importantes :

• Le délai de réception d’un virement classique chez CentralPay est de 4 à 24 heures ouvrées (contre 24 à 48 heures ouvrées chez la majorité des banques traditionnelles). Il sera également possible de recevoir des virements instantanés (réception <5 secondes) à partir d’octobre 2024.
• Le virement ne présente pas de risque financier majeur pour le marchand bénéficiaire, car l’émetteur s’authentifie fortement auprès de sa banque et ne peut donc pas contester cette opération.
• Les banques émettrices accordent un plafond de règlement par virement nettement plus élevé que celui appliqué aux opérations de prélèvement SEPA ou de règlement par carte.
• Selon les fonctionnalités proposées par sa banque, l’émetteur peut programmer un virement récurrent ou à date différée.

2/ Types de réseaux acceptés

Il existe deux types de virements bancaires :

• les virements SEPA (ou SEPA Credit Transfer) : utilisés pour les opérations en EUROS réalisées entre deux pays membres de la zone SEPA (= 27 pays de l’Union européenne + Royaume-Uni, Monaco, Andorre, Vatican, Suisse, Liechtenstein, Norvège, Islande et Saint-Marin)
• les virements internationaux : utilisés pour les opérations internationales en EUROS ou en devises, via le réseau SWIFT.

Les frais applicables aux réseaux SEPA sont très largement favorables (à peine quelques dizaines de centimes contre plusieurs dizaines d’euros pour SWIFT). SWIFT permet cependant plusieurs options liées au règlement de ses frais : à la charge de l’émetteur, du bénéficiaire ou partagés.

1/ Introduction

Le paiement par virement bancaire impose une responsabilité au client émetteur : celle de renseigner les coordonnées bancaires (IBAN + BIC + Nom du titulaire), le montant du règlement mais aussi la référence de virement.

Une absence ou un mauvais formatage de la référence (causé par le client ou par le système de sa banque) contraint le bénéficiaire d’analyser manuellement le virement reçu pour le rapprocher à la bonne facture et au bon poste client.

CentralPay vous permet de présenter un IBAN virtuel différent à chacun de vos clients (Customer) ou dans chacune de vos factures (PaymentRequest). Ainsi lors de la réception d’un virement, CentralPay identifie automatiquement l’émetteur et peut rapprocher la facture pour vous, selon l’IBAN virtuel utilisé par votre client, même en cas d’erreur de référence.

Un IBAN Virtuel est en tous points identique à un IBAN classique, ce qui rend le processus entièrement transparent pour vos clients.

Ce service vous permettra notamment :

• d’être informé instantanément quand un client vous a réglé par virement,
• d’automatiser vos alertes internes et vos relances clients (via le service de notifications),
• d’automatiser le rapprochement de vos paiements dans vos solutions comptables ou de facturations (ERP…),
• pour les plateformes et marketplaces : d’identifier facilement le marchand bénéficiaire et de lui transférer les fonds

Vous pourrez créer des IBAN Virtuels CentralPay depuis différents services de la plateforme :

• Depuis le service Customer
• Depuis le service SCT Transaction
• Depuis le service PaymentRequest

Chaque compte de paiement ou de monnaie électronique dispose nativement d'un IBAN Virtuel dédié

2/ Consulter l’IBAN Virtuel de ses comptes

Vous pouvez retrouver l’IBAN Virtuel de vos comptes depuis le Portail utilisateur Administration Comptes IBAN/BIC :

• Accès Comptes – Portail Utilisateur de RCT
• Accès Comptes – Portail Utilisateur de PROD

Il est également possible d’interroger l’API CentralPay avec le endpoint /bankAccount

3/ Créer un IBAN Virtuel dédié à un Customer

Vous pouvez créer un IBAN Virtuel dédié à un client lors de la création d’un nouveau Customer, ou via l’update d’un Customer existant.

Pour cela, vous devez renseigner le champ « walletIdForIban » avec l’UUID du compte de paiement sur lequel vous souhaitez recevoir les fonds.

Vous pouvez retrouver ce dernier depuis le Portail utilisateur Administration Comptes UUID :

• Accès Comptes – Portail Utilisateur de RCT
• Accès Comptes – Portail Utilisateur de PROD

En retour, vous recevrez dans le champ « bankAccounts » les valeurs « iban » et « bic » constituant l’IBAN Virtuel de votre Customer.

Le BIC des IBAN émis par CentralPay sont : CEAYFR22

4/ Création d’un IBAN Virtuel dédié à une SCT Transaction

Comme pour un Customer, vous pouvez créer un IBAN Virtuel dédié à une transaction par virement lors de la création d’une SCT Transaction.

Pour rappel, une SCT Transaction est créée automatiquement par CentralPay lorsque vous recevez un virement sur votre IBAN Virtuel principal ou celui d'un Customer. Il est cependant possible de créer une SCT Transaction en amont afin de lui affecter un IBAN Virtuel dédié et une référence personnalisée par exemple.

Pour cela, vous devez renseigner le champ « ibanWalletId » avec l’UUID du compte de paiement sur lequel vous souhaitez recevoir les fonds.

Vous pouvez retrouver ce dernier depuis le Portail utilisateur Administration Comptes UUID :

• Accès Comptes – Portail Utilisateur de RCT
• Accès Comptes – Portail Utilisateur de PROD

En retour, vous recevrez dans le champ « bankAccounts » les valeurs « iban » et « bic » constituant l’IBAN Virtuel de votre SCT Transaction.

Un IBAN Virtuel dédié à une SCT Transaction n'est plus fonctionnel une fois que sa SCT Transaction a été entièrement réglée. Il est cependant possible de recevoir plusieurs virements d'un montant inférieur sur un même IBAN pour compléter le montant de la SCT Transaction.
À noter que si un virement reçu dépasse le montant de la SCT Transaction, il sera tout de même accepté. Vous devrez réaliser un remboursement partiel pour reverser le trop perçu à votre client. 

5/ Utilisation des IBAN Virtuels depuis les demandes de paiement

Il est possible d’utiliser des IBAN Virtuels Customer ou SCT Transaction depuis le service de demande de paiement, si vous acceptez le moyen de paiement « SCT Transaction ».

Vous pouvez sélectionner le type d’IBAN Virtuel que vous souhaitez afficher dans vos demandes de paiement depuis le champ « Viban prioritaire » des paramétrages de votre point de vente. Si vous sélectionnez :

• SCT
  • La demande de paiement créera systématiquement un IBAN Virtuel dédié à la SCT Transaction
• Client
  • La demande de paiement utilisera l’IBAN Virtuel du Customer s’il en dispose déjà d’un, sinon elle en créera un automatiquement

Dans le cas d'une demande de paiement avec vIBAN à la SCT Transaction uniquement : si vous annulez la demande de paiement, le vIBAN associé ne sera plus atteignable. Ainsi, chaque virement reçu sur ce vIBAN sera automatiquement renvoyé à son émetteur.

1/ Introduction

Une SCT Transaction représente un virement bancaire reçu sur un de vos IBAN Virtuel CentralPay.

Elle peut être créée de trois manières différentes :

• Automatiquement
  si vous adressez un IBAN Virtuel dédié à l’un de vos clients ou l’un de vos comptes de paiement, CentralPay créera la SCT Transaction automatiquement lors de la réception du virement. Vous pourrez ensuite rapprocher cette SCT Transaction à votre commande/facture en récupérant la valeur du champ « description » (correspondant à la référence renseignée par votre client dans son espace bancaire).
• Depuis le service SCT Transaction
  si vous souhaitez automatiser le rapprochement du virement à la transaction, vous pouvez :
  • créer une SCT Transaction avec un IBAN Virtuel dédié : ce qui permettra un rapprochement sûr à 100% à votre transaction. Attention, dans ce cas vos clients devront déclarer un nouveau bénéficiaire dans leur espace bancaire à chaque virement qu’ils vous adresseront.
  • créer une SCT Transaction en utilisant un IBAN Virtuel Customer et récupérer la référence courte générée par CentralPay pour cette transaction : ce qui permettra de rapprocher systématiquement le virement au profil client correspondant, et potentiellement jusqu’à la transaction si votre client a bien renseigné la référence dans son virement.
• Depuis le service de demande de paiement
  si vous souhaitez déléguer à CentralPay l’affichage des informations de règlement à vos clients (montant, IBAN, BIC, référence…), vous pouvez créer une Demande de paiement autorisant les paiements par SCT Transaction. Cette option permet également de gérer facilement les virements multiples ou les règlements clients depuis plusieurs moyens de paiement.

2/ Créer une SCT transaction

Créer une SCT Transaction :

• Renseignez un montant en centimes (amount), et une devise (currency).
• Si vous souhaitez créer un IBAN Virtuel dédié à la SCT Transaction, renseignez le champ « ibanWalletId » avec l’UUID de votre compte de paiement sur lequel vous souhaitez recevoir les fonds. Vous pouvez retrouver ce dernier depuis le Portail utilisateur > Administration > Comptes > UUID.
• Si vous souhaitez utiliser un IBAN Virtuel existant (dédié à un Customer ou à un compte de paiement), renseignez le champ « iban » avec l’IBAN souhaité.
  • Vous pourrez ensuite récupérer la valeur « sepaReference » générée par CentralPay et la transmettre à votre client pour laisser CentralPay rapprocher le virement à votre transaction
  • ou renseigner la valeur « merchantSctTransactionId » avec votre propre référence personnalisée pour rapprocher vous-même le virement via nos exports d’opérations.

CentralPay met à disposition un service nommé bankReconciliation permettant de lier une ou plusieurs SCT Transaction à une demande de paiement (PaymentRequest) si vous n’utilisez pas les IBAN Virtuel dédié aux SCT Transaction.

1/ En cas d’erreur de référence par votre client

Lorsque vous utilisez les demandes de paiement avec IBAN Virtuels dédiés à un Customer et que votre client ne renseigne pas correctement la « sepaReference » lors de l’émission de son virement ; CentralPay n’est pas en mesure de rapprocher automatiquement le virement à la demande de paiement.

Vous pouvez donc utiliser le service bankReconciliation pour affecter la SCT Transaction reçue à la demande de paiement créée initialement :

• Amount = montant du virement en centimes
• wireTransferID = ID de la SCT TRANSACTION (accessible dans le hook de la SCT TRANSACTION)
• paymentRequestBreakdownId = ID du breakdown de la PaymentRequest (accessible dans le hook de la PaymentRequest)

2/ Si vous utilisez votre propre référence de commande

Si vous souhaitez organiser vos créances clients dans CentralPay grâce au service de Demandes de paiement sans utiliser la page de paiement SmartForm, voici la démarche à suivre :

• pour chaque client : créer un Customer avec vIBAN, récupérer le vIBAN et l’afficher dans votre tunnel de vente avec votre référence de commande
• créer en parallèle une paymentRequest contenant cette même référence de commande (dans le champ « merchantPaymentRequestId ») et le montant de commande
• Dès réception d’un virement client, vous identifiez la commande liée grâce au champ « description » de la SCT Transaction
• Vous recherchez ensuite une PaymentRequest avec la même référence dans « merchantPaymentRequestId »
  • si une PaymentRequest présente la même référence, vous l’associez avec le service « bankReconciliation »
  • si aucune PaymentRequest ne présente la même référence mais que le virement a été reçu sur un vIBAN Customer n’ayant qu’une seule PaymentRequest en attente ou d’un montant identique, vous pouvez faire en sorte de les rapprocher avec une bankReconciliation
  • si aucune PaymentRequest ne présente la même référence et que le Customer présente plusieurs PaymentRequest en attente de règlement ou d’un montant différent, levez une alerte dans votre système pour faire rapprocher le virement manuellement par votre service financier (qui l’associera manuellement à la bonne PaymentRequest via une bankReconciliation)
• Les virements non liés à une PaymentRequest seront ainsi facilement identifiables
• De même que les PaymentRequest non payées ou partiellement payées.

1/ Remboursement

Vous pouvez rembourser une SCT Transaction si celle-ci est « RECEIVED » via le service Refund ou depuis le détail de la SCT Transaction dans le Portail utilisateur. Vous pouvez initier un remboursement total ou partiel en renseignant un montant.

Votre client recevra les fonds sur son compte bancaire sous 24 à 48 heures ouvrés après l’opération. Votre compte de paiement est lui débité immédiatement, il doit donc être solvable pour pouvoir réaliser l’opération.

Vous ne pouvez pas annuler un remboursement une fois celui-ci réalisé.

Introduction

Les virements bancaires internationaux sont gérés via le réseau SWIFT (contrairement au réseau SEPA pour les virements européens). Ces virements peuvent être émis depuis un très grand nombre de pays en EUROS ou dans d’autres devises.

Il sera prochainement possible d’accepter des virements internationaux via le service SCT Transaction. Veuillez contacter CentralPay si ce service est un enjeu pour le développement de votre activité.

1/ Retours liés aux SCT Transactions

Il n’existe pas de code retours pour les SCT Transactions.

2/ Statuts liés aux SCT Transactions

Statuts « SCT Transaction »

Statuts « Refund »

3/ Webhooks liés aux SCT Transactions

Webhooks « SCT Transaction »

Webhooks « Refund »

Webhooks « Customer »