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.

1. Un hébergement hautement résilient

• 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

2. 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é.

Le compte Marchand est ouvert au nom d’une entité (personne physique ou morale) et permet d’accéder aux services CentralPay d’encaissement, de paiement ou de gestion de la monnaie électronique. Il constitue la base :

• Contractuelle : rattachement à une grille tarifaire, acceptation des CGU, contrat d’acceptation le cas échéant
• Technique : authentification, accès API, création des utilisateurs
• Fonctionnelle : paramétrage des points de vente, scénarios de notification, reversements, règles d’acceptation
• Réglementaire : gestion du KYC/KYB, conformité à la réglementation

Un compte Marchand peut contenir un ou plusieurs comptes de paiement ou comptes de monnaie électronique, selon les services activés.

1. Types de comptes selon le modèle contractuel

Chaque type de compte Marchand est associé à un modèle contractuel précis.

Standard Type : STANDARD

Le Marchand standard est une entreprise ou un professionnel qui encaisse des paiements pour son propre compte. Il dispose d’un ou plusieurs comptes de paiement, d’un contrat d’acceptation, et peut accéder aux services CentralPay via API ou via un partenaire.

👉 En savoir plus sur le modèle Marchand

Partenaire Intégrateur Type : STANDARD + INTEGRATEUR

Le Marchand Partenaire Intégrateur accompagne plusieurs Marchands standards dans leur intégration technique avec CentralPay. Chaque Marchand standard dispose de son propre point de vente et d’un contrat individuel. L’Intégrateur utilise les accès API fournis par chaque Marchand, dans le cadre d’une relation contractuelle.

• Peut disposer d’un compte de paiement et d’un compte de commission pour ses propres besoins
• Un point de vente distinct est créé pour chaque Marchand accompagné
• Peut initier des transactions techniques via les accès API du Marchand
• CentralPay facture chaque Marchand directement

👉 En savoir plus sur le modèle Partenaire Intégrateur

Partenaire Intégrateur MOBSP Type : STANDARD + INTEGRATEUR + MOBSP

Le Marchand Partenaire Intégrateur MOBSP est un Intégrateur disposant d’un mandat réglementaire. Il peut initier une demande d’entrée en relation pour le compte d’un Marchand standard, et l’accompagner techniquement via l’API d’onboarding. Comme tout Intégrateur, il agit uniquement via les accès API fournis par le Marchand.

• Mêmes droits et fonctionnement qu’un Intégrateur
• Peut initier une demande d’enrôlement complète via API
• Peut accompagner le marchand durant l’enrôlement

👉 En savoir plus sur le modèle Partenaire Intégrateur MOBSP

Partenaire Technique Type : STANDARD + TECHNIQUE

Le Marchand Partenaire Technique développe une solution d’encaissement opérée depuis son ou ses propres points de ventes, pour le compte de plusieurs Marchands standards. Il utilise ses propres accès API pour superviser les opérations liées à cette structure centralisée.

• Un seul point de vente est utilisé pour regrouper les activités des marchands (ex: marketplace, plateforme SaaS)
• Accès API CentralPay propre au Partenaire Technique
• CentralPay facture le Partenaire Technique
• Ne peut pas initier d’enrôlement ni agir au nom des utilisateurs

👉 En savoir plus sur le modèle Partenaire Technique

Partenaire Technique MOBSP Type : STANDARD + TECHNIQUE + MOBSP

Le Marchand Partenaire Technique MOBSP est mandaté pour initier une demande d’entrée en relation au nom de ses utilisateurs. Il peut transmettre les informations nécessaires via l’API d’onboarding, mais n’intervient pas dans l’exécution des opérations de paiement.

• Même droit et fonctionnement qu’un Partenaire Technique
• Peut initier une demande d’enrôlement complète via API
• Peut accompagner le marchand durant l’enrôlement

👉 En savoir plus sur le modèle Partenaire Technique MOBSP

Mandataire DME Type : DME

Le Marchand Mandataire DME (Distributeur de Monnaie Électronique) transmet des instructions de chargement, de transfert ou de remboursement pour le compte de sous-marchands. Il agit en tant qu’intermédiaire technique sur la monnaie électronique, et peut percevoir une commission sur les opérations.

👉 En savoir plus sur le modèle Mandataire DME

Mandataire Agent Type : AGENT

Le Marchand Mandataire Agent est un Agent prestataire de services de paiement (Agent PSP) enregistré auprès de l’ACPR. Il peut inscrire des sous-marchands, gérer le KYC/KYB, encaisser des paiements, piloter les reversements, et opérer un compte de collecte. Il agit au nom et pour le compte de CentralPay dans le cadre de services réglementés.

👉 En savoir plus sur le modèle Mandataire Agent

Sous-marchand Type : BASIC

Les Sous-Marchands sont des entités finales rattachées à un Marchand Mandataire (DME ou Agent). Ils disposent d’un compte de paiement ou de monnaie électronique pour recevoir des fonds, et peuvent accéder au portail Marchand pour consulter leurs opérations et gérer leurs reversements.

On distingue deux types de sous-marchand selon leur finalité :

• Sous-marchand commercial : agit à des fins commerciales (vente de biens ou de services)
• Sous-marchand finance : agit à des fins non commerciales (ex. chargement de wallet pour accès à un service, projet interne ou collaboratif…)

Les sous-marchands ouvrent des comptes Chez CentralPay mais n’entrent pas en relation d’affaires directe avec CentralPay. Leur cadre d’utilisation et leurs tarifications sont définis dans les CGU des Agents auxquels ils sont rattachés.

2. Paramétrage des emails de contact

Vous pouvez personnaliser les adresses email de contact associées à votre compte pour que les notifications, relances ou échanges contractuels soient bien adressés aux bons interlocuteurs.

• Email contact : référent principal du compte
• Email administratif : en charge des sujets juridiques ou contractuels
• Email technique : en charge de l’intégration ou des incidents
• Email financier : en charge de la facturation ou des flux bancaires

ℹ️ Par défaut, ces adresses sont initialisées avec l’email du titulaire du compte. Elles peuvent être modifiées à tout moment depuis le Portail Marchand.

Accès à la configuration des emails de contact :

Les profils clients (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 paiement (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…

1. 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

2. Interfaces

Vous pouvez consulter l’ensemble des Customers de votre compte depuis votre Portail Marchand Compte Customers

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

3. 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.

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 Marchand 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 Marchand ou dans vos exports de données

Lors de la création de votre compte Marchand CentralPay, un premier point de vente est créé automatiquement. Vous pouvez ensuite vous rendre sur votre portail Marchand pour paramétrer ce dernier, ou en créer de nouveaux :

1. 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
  • Cocher « 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 Marchand 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 Marchand…)
  • 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 Marchand…)
  • 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 emails 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)

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 Marchand 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 :

1. Utilisation

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.

2. 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.

ℹ️ Uniquement réservé aux Mandataires DME et à leurs sous-marchands.

Les comptes de ME (Monnaie Électronique) sont utilisés pour stocker et échanger des fonds dans une devise CUSTOM (devise dédiée à un mandataire DME). Un mandataire DME peut demander la création de comptes de ME pour les sous-marchands 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 mandataire 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 :

1. Utilisation

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

2. 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 mandataire 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é »

3. Création de comptes de ME

Si vous êtes mandataire DME de CentralPay, vous pouvez demander la création de comptes de ME pour vos sous-marchands.

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)

1. Types de scénarios de notification

Notifiez vos clients et alertez vos collaborateurs automatiquement lorsque certains évènements ont lieu sur votre compte Marchand 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.

2. Paramétrage des modèles de notification

2.1. Paramétrage des modèles (templates)

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).

Accès paramétrage de templates emails :

Accès paramétrage de templates SMS :

Accès paramétrage de templates hooks :

2.2. Paramétrage du header et footer pour templates emails

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.

Accès paramétrage de l’en-tête d’email (header) :

Accès paramétrage du pied de page d’email (footer) :

3. Paramétrage des scénarios de notification

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.

Accès paramétrage de scenarios de notification :

3.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’activation)

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.

3.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 :

• Liste blanche (whitelist)
  Le but de la « whitelist » est de rendre sélective l’application d’une règle d’acceptation. Elle 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
• 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)
• 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
• 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.

Liste des attributs :

Dans le cas du custom_acceptance_data[‘key’] = ‘value’, afin qu’il soit pris en compte il est nécessaire que l’exact même champs soit reporté dans la requête de l’objet visé.

Les opérateurs logiques et parenthésage :

Opérateurs logiques AND et OR

La syntaxe utilisée pour définir les règles permet de créer plusieurs conditions au sein de la même règle. Les conditions resteront définies de la même manière, à la seule différence qu’un mot clé sera placé entre les conditions.

Les mots clés 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 » correspond à l’inclusion et le « OR » à l’exclusion.

Exemple :

ALLOW if #amount < 1000 and #card_country = 'FRA'

L’exemple précédent autorise les paiements dont le montant est inférieur à 10 ET dont la carte est française. Si l’une ou l’autre des conditions définies n’est pas remplie, l’action ne sera pas exécutée.

Exemple :

ALLOW if #amount < 1000 or #card_country = 'FRA'

L’exemple précédent autorise les paiements dont le montant est inférieur à 10 OU dont la carte est française. Si l’une ou l’autre des conditions définies est remplie, l’action sera exécutée.

Parenthèses

L’utilisation des parenthèses dans la définition d’une règle multi-conditions permet de définir des blocs de conditions et les priorités entre ces blocs. Le principe est le même que celui des priorités pour les opérateurs mathématiques.

Exemple :

ALLOW if #amount < 1000 and (#card_country = 'FRA' or #currency = 'EUR')

Dans l’exemple précédent, le moteur de règle va d’abord interpréter le bloc (#card_country = ‘FRA’ or #currency = ‘EUR’). C’est à dire que le paiement sera autorisé si (la carte est française ou que la devise est l’euro), ET que le montant est inférieur à 10.

Ordre d’exécution des règles

Les règles sont exécutées dans un ordre à définir. Cet ordre est important car dès qu’une transaction répond aux critères d’une règle, les règles suivantes ne seront pas traitées.

Les règles sont exécutées dans l’ordre d’affichage de la liste de l’interface.
Un indicateur de position est affiché dans chaque liste. Pour changer la position d’une règle, il suffit de la faire glisser à la position souhaitée.

Exemples de règles :

ALLOW if #amount < 1000 and #transactions_amount_daily < 10000

Cet exemple autorise les transactions dont le montant est inférieur à 10 si la somme des montants des transactions de la journée est inférieur à 100.

REFUSE if #risk_score > 3 or (#ip_regions = 'ASIA_PACIFIC' and #card_region = 'ASIA_ PACIFIC')

Cette règle bloque les paiements si le score de risque dépasse 3 ou que l’IP utilisée ainsi que la région d’émission de la carte correspondent à la zone ‘ASIA_PACIFIC’.

THREE_D_SECURE if #card_country NOT IN ('FRA', 'USA', 'GBR') 

Cette règle demande une transaction 3D Secure si le pays de la carte n’est pas la France, les Etats-Unis, ou la Grande Bretagne.

ALLOW (#amount < 10000 and #transactions_amount_daily < 100000) or (#currency IN ('EUR', 'USD') and #transactions_amount_monthly < 1000000)

Cet exemple précédent AUTORISE les paiements SI le montant est INFÉRIEUR à 100 ET que la somme des montants des transactions du jour est INFÉRIEUR à 1000 OU que la devise est € ou $ ET que la somme des montants des transactions du mois est INFÉRIEURE à 10 000.

Les opérateurs logiques « AND » et « OR » ne sont syntaxiquement correct qu’en minuscule.

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)

ℹ️ 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.

Les reversements bancaires (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 Marchand ou l’API Payment. Ils peuvent également être automatisés depuis le Portail Marchand.

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

1. Les deux modes de reversement

1.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 :

Cas 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.

1.2. Reversement manuel (via BO ou API)

Vous avez la possibilité d’exécuter des payouts manuellement depuis le Portail Marchand 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.

2. 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.

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

3. Création d’un reversement manuel

3.1. Payout manuel par Portail Marchand

Depuis le Portail Marchand 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 ».

3.2. Payout manuel par API

Consultez le détail dans la rubrique : Développeurs Payout

4. 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.

5. Retours, statuts et webhooks

Consultez les statuts PAYOUT ➝

Consultez les webhooks PAYOUT ➝

Vous pouvez réaliser plusieurs exports de votre compte aux formats CSV, EXCEL, ou JSON depuis votre Portail Marchand. 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 Marchand Compte Exports .

1. Export comptable des opérations du compte

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, etc.

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 :

Accès :

2. 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 :

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 »

Accès :

Vous pouvez réaliser plusieurs exports de votre compte aux formats CSV, EXCEL, ou JSON depuis votre portail Marchand. 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 Marchand Compte Exports

1. Export des transactions cartes

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 :

Accès :

2. Export des remboursements cartes

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.

Accès :

3. Export des contestations de transactions cartes

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.

Accès :

4. Export des abonnements (cartes et SDD)

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.

Accès :

Les webhooks permettent d’adresser des notifications HTTP sur les URL de votre choix en fonction des évènements (events) qui surviennent sur votre compte Marchand 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 Marchand CentralPay. Par exemple, une transaction réussie ou échouée, la création d’un nouvel abonnement (subscription), 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.

Consultez la liste des webhooks dans la rubrique : Développeurs Webhook notifications

CentralPay propose plusieurs modes d’entrée en relation, selon votre situation :

• Vous êtes un marchand standard, partenaire ou mandataire en relation directe avec CentralPay
• Vous êtes un sous-marchand d’un marchand mandataire, ou un marchand rattaché à un partenaire technique utilisant la solution CentralPay

Ce guide détaille les différentes étapes, selon votre profil. Certaines étapes peuvent être adaptées ou simplifiées selon les modalités de votre intégration.

1. Marchands en direct

Le parcours d’entrée en relation comporte six étapes principales.

1.1. Qualification de votre projet

Nos équipes commerciales échangent avec vous pour analyser votre projet :

• Parcours de paiement envisagé (web, mobile, point de vente, récurrent…)
• Moyens de paiement souhaités (carte, virement, SEPA, Pay By Bank…)
• Méthodes d’intégration (API, portail, connecteur)
• Typologie de vos clients finaux (B2B, B2C, abonnements…)
• Volumétrie estimée (fréquence et montants)

1.2. Pré-analyse conformité de votre projet

Sur la base des informations fournies, notre service conformité effectue une pré-analyse réglementaire visant à :

• Vérifier la compatibilité de votre activité avec notre cadre réglementaire
• Identifier les points de vigilance potentiels (secteur sensible, flux complexes…)
• Prédéfinir les éventuelles garanties ou conditions particulières

1.3. Signature du contrat cadre

Une fois cette pré-analyse validée, vous êtes invité à signer le contrat cadre de services de paiement ou de monnaie électronique.

• Voir le contrat cadre de services de paiement
• Un représentant légal peut désigner un mandataire pour signer à sa place (modèle de délégation disponible sur demande)

1.4. Lancement de l’intégration

Après signature du contrat :

• Vous recevez vos accès à l’environnement de test
• Vous accédez aux documentations techniques CentralPay

Si vous bénéficiez d’un accompagnement personnalisé, une réunion d’onboarding est organisée pour configurer vos premiers paramétrages (notifications, reversements, droits utilisateurs…).

1.5. Création du compte Marchand CentralPay

Le représentant légal reçoit un lien d’inscription sécurisé pour créer le compte :

• Il complète les informations juridiques
• Il valide les Conditions Générales d’Utilisation
• L’analyse de conformité complète est alors déclenchée

Cette analyse peut donner lieu à :

• Des demandes de documents complémentaires (KYC/KYB, contrats, justificatifs…)
• Un refus d’ouverture si les critères réglementaires ne sont pas remplis
• Une validation du compte, menant à son ouverture

1.6. Mise en production

Une fois l’ensemble des étapes validées, y compris l’intégration et les éventuelles factures initiales :

• Une date de mise en production est convenue
• Votre compte est débloqué
• Vous pouvez encaisser vos premières transactions

2. Sous-marchands et Marchands liés à un partenaire technique

Si vous êtes un marchand intégré via un partenaire technique ou mandataire de CentralPay, le parcours est simplifié.

Vous entrez directement à l’étape 5 : Création du compte Marchand CentralPay.

2.1. Étape unique : Création du compte et validation réglementaire

• Vous recevez un lien d’inscription transmis par votre partenaire ou directement par CentralPay.
• Ce lien vous permet de :
  • Compléter les informations relatives à votre structure
  • Décrire précisément votre activité, la typologie de vos clients finaux et la volumétrie estimée de vos opérations
  • Valider les Conditions Générales d’Utilisation et signer le contrat cadre

Les aspects techniques (intégration, parcours, moyens de paiement) sont déjà définis dans le cadre de la convention signée avec le partenaire technique ou le mandataire.

L’analyse de conformité complète de CentralPay reste obligatoire avant validation du compte.

Cette page présente les documents que CentralPay est susceptible de demander à ses utilisateurs et partenaires lors de l’ouverture d’un compte. Les pièces à fournir varient selon :

• Le type de structure (particulier, société, association, organisme public…)
• Le profil de risque (faible, moyen, élevé)
• Le type d’activité exercée

Ces exigences répondent aux obligations réglementaires en matière de lutte contre le blanchiment des capitaux et le financement du terrorisme (LCB-FT).

1. Documents communs (socle KYC)

Quel que soit le profil, les documents de base à fournir sont :

• Une pièce d’identité valide :
  • Utilisateur de l’Espace Economique Européen (EEE) : Carte Nationale d’Identité (CNI), passeport, carte de séjour
    • Récépissé de renouvellement de titre de séjour (accompagné du titre de séjour périmé) accepté pour les utilisateurs « personnes physiques ». Récépissé de demande de 1er titre de séjour non accepté
  • Utilisateur hors EEE : uniquement le passeport (passeports issus d’un pays sur liste noire GAFI non acceptés)
    
    
• Un justificatif de domicile de moins de 3 mois :
  • Facture d’énergie ou d’eau (moins de 3 mois)
  • Facture de téléphonie fixe / box internet (moins de 3 mois)
  • Avis d’imposition, taxe foncière ou d’habitation (moins de 3 mois)
  • Quittance de loyer d’un organisme public (moins de 3 mois)
  • Attestation d’hébergement accompagnée de :
    • Pièce d’identité de l’hébergeur
    • Justificatif de domicile de l’hébergeur (moins de 3 mois)
  • Pour les clients étrangers :
    • Extrait de relevé bancaire de moins de 3 mois
      
      
• Relevé d’Identité Bancaire (RIB) au nom du client
  
• Déclaration de l’activité exercée et des canaux de commercialisation

Des documents complémentaires peuvent être demandés selon le niveau de risque et l’activité.

2. Exigences selon le type d’utilisateur

2.1. Personnes Physiques (KYC)

2.2. Personnes morales (KYB)

La création d’un compte Marchand CentralPay pour une société, association ou toute autre personne morale doit être réalisée par l’un de ses dirigeants officiellement enregistrés (ex. : gérant, président), figurant dans un registre officiel (type extrait Kbis ou équivalent).

Le dirigeant peut toutefois désigner une autre personne (mandataire) pour effectuer la création du compte à sa place. Dans ce cas :

• Une délégation de pouvoir rédigée par le dirigeant ou, à défaut, le modèle de procuration CentralPay devra être complété et signé
• Lors du processus de création, les documents suivants seront requis :
  • La pièce d’identité du mandataire
  • La pièce d’identité du dirigeant (mandant)

ℹ️ Ce dispositif permet de sécuriser la procédure tout en vous offrant une gestion souple et conforme à la réglementation.

Cas particulier : société dirigée par une autre société

Si la société pour laquelle le compte est créé est elle-même dirigée par une autre personne morale, CentralPay doit identifier toutes les entités intermédiaires, jusqu’à la personne physique exerçant un contrôle effectif (ex. : détention de plus de 25% du capital).

Dans ce cadre :

• Des documents KYC/KYB seront demandés pour chaque société intermédiaire
• La personne physique réalisant l’enrôlement doit figurer sur un registre officiel, ou fournir une délégation de pouvoir valide ou une procuration CentralPay signée

3. Formats de fichiers acceptés et exigences techniques

3.1. Formats de fichiers acceptés

Pour garantir la lisibilité et le bon traitement de vos documents, nous acceptons uniquement les formats suivants :

• PDF : recommandé pour les documents multipages (ex : avis d’imposition, statuts) et les Relevés d’Identités Bancaires (RIB)
• JPEG / JPG / PNG / PDF : pour les photos d’identité, captures d’écran ou documents scannés

3.2. Poids et résolution des fichiers

• Taille maximale par fichier : 10 Mo
• Résolution minimale recommandée : 300 DPI
• Pour les photos prises avec un smartphone : privilégiez le mode « document » ou « scanner » si disponible

3.3. Documents non acceptés

Les documents suivants seront systématiquement refusés :

• Documents expirés
• Photos floues, mal cadrées ou illisibles
• Documents coupés ou tronqués (informations ou bords manquants)
• Scans en noir et blanc
• Fichiers compressés ou d’archives (.zip, .rar…)
• Documents retouchés ou modifiés numériquement

3.4. Conseils pour une soumission réussie

• Vérifiez la netteté et la lisibilité avant l’envoi
• Évitez les reflets et ombres sur les documents photographiés
• Adressez des copies numériques en couleur (scan ou photo nette)
• N’envoyez pas de documents à travers des captures d’écran d’ordinateur
• Assurez-vous que le document est à jour et en cours de validité

CentralPay et ses partenaires sont autorisés à entrer en relation d’affaires et à ouvrir des comptes de paiement ou de Monnaie Électronique pour des personnes physiques ou morales résidant ou établies dans les pays suivants :

Remarques :

• L’ouverture de compte est conditionnée à l’analyse du dossier par les équipes conformité
• Pour les territoires d’outre-mer, l’éligibilité s’applique uniquement aux zones sous souveraineté française

Pour garantir la conformité réglementaire, la sécurité des opérations et la réputation de ses services, CentralPay interdit formellement certaines activités. Toute personne ou entité souhaitant ouvrir un compte Marchand CentralPay doit s’assurer que son activité est conforme aux exigences ci-dessous.

L’exercice de l’une des activités suivantes peut entraîner le refus d’entrée en relation, la suspension du compte ou sa clôture immédiate.

1. Activités interdites de manière absolue

1.1. Activités soumises à conditions strictes

Certaines activités peuvent être envisagées sous réserve d’une analyse renforcée par les équipes conformité et de la fourniture de justificatifs réglementaires valides :

• Jeux en ligne ou paris (avec licence délivrée par l’autorité compétente)
• Vente d’alcool ou de tabac (avec autorisation légale)
• Plateformes de streaming ou d’abonnement (sous conditions anti-fraude)

2. En cas de doute…

• CentralPay se réserve le droit d’interprétation et de décision unilatérale en matière d’acceptation ou de rejet d’une activité, y compris en cas d’évolution réglementaire
• Pour toute activité atypique ou présentant des risques, une analyse renforcée peut être demandée, avec obligation de transparence sur les flux, les bénéficiaires, et les clients finaux

📩 Contactez votre interlocuteur CentralPay si vous avez des questions sur l’éligibilité d’un projet.

La réserve représente les sommes qui sont maintenues sur votre compte Marchand 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 sujettes 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 Marchand : 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 Marchand : 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 Marchand 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 de la réserve glissante est visible depuis le Portail Marchand : Administration Reversements Seuil variable

L’utilisation des services CentralPay est encadrée par plusieurs documents contractuels que chaque titulaire de compte doit consulter et accepter avant l’activation de son compte.

👉 Consultez les dernières versions en vigueur des conditions générales CentralPay

1. Deux types de CGU applicables

CentralPay propose deux catégories de comptes, soumises à des conditions générales distinctes en fonction du service souscrit :

Obligation d’acceptation :

Ces conditions générales doivent être lues et acceptées électroniquement par le titulaire de chaque compte, qu’il soit ouvert directement par un marchand, ou via un partenaire CentralPay.

2. Contrat cadre pour les encaissements pour compte propre

Dans le cas où un compte est utilisé pour encaisser des fonds pour compte propre (modèle marchand standard), CentralPay met également à disposition un modèle de contrat cadre dédié :

• Ce contrat précise les droits et obligations liés à l’utilisation du compte pour l’encaissement d’opérations commerciales,
• Il est signé électroniquement par le représentant légal ou par une personne habilitée (via délégation de pouvoir).

👉 Consultez les dernières versions en vigueur des conditions générales CentralPay

1. Les types d’acteurs

2. Les types de comptes

3. Les dénominations d’objets ou d’opérations

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) ➝
  • Le paramètre EscrowDate peut influer sur la date de disponibilité des fonds d’une transaction (concerne uniquement les partenaires AGENT)

ℹ️ 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, etc.). Les transactions ainsi créées sont automatiquement liées à la demande de paiement et permettent d’actualiser son statut (non payé, partiellement payé, payé, etc.).

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

La demande de paiement (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 Marchand. 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.

1. Création par API

1.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

⚠️ 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 :

ℹ️ 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.

1.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 [prochainement]
    
    
• 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 [prochainement]

1.3. Fonctions spécifiques

Envoyer une 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.

Exemple :

Cas d'une demande de paiement de 500 € :

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

Pour ce faire, vous devez [prochainement]

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 [prochainement]

2. Création depuis le Portail Marchand

2.1. Création et types de demandes de paiement

Vous pouvez créer une demande de paiement depuis le Portail Marchand Demandes de paiement Liens de paiement Créer .

Les demandes de paiement créées depuis le Portail Marchand 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.

Accès :

2.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 Marchand, ou via import de fichiers plats.

2.3. Création de demandes de paiements par import de fichiers plats

Depuis le Portail Marchand 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.

Télécharger le modèle :

• Au format CSV➝
• Au format JSON ➝

Quelques informations importantes :

La page de paiement (aussi appelée 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.

1. Paramétrage de la page

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 :

Accès :

2. 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

Consultez les Statuts Payment Request ➝

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.

Consultez les Webhooks PaymentRequest ➝

Consultez les Webhooks Transaction ➝

Consultez les Webhooks SCT Transaction ➝

Consultez les Webhooks SDD Transaction ➝

Consultez les Webhooks Customer ➝

Consultez les Webhooks Subscription ➝

Consultez les Webhooks Installment ➝

Les APIs CentralPay permettent d’interagir de manière sécurisée avec notre plateforme pour créer des comptes, initier des paiements ou automatiser des opérations métiers.

Nos APIs reposent sur le protocole HTTP(S) et utilisent un format de réponse en JSON. L’authentification est obligatoire pour chaque requête, sauf exception précisée.

1. Les APIs disponibles

CentralPay met à disposition deux APIs principales :

2. URLs des environnements

Deux environnements sont disponibles selon votre étape d’intégration :

Les identifiants d’accès sont différents entre test et production.

Vous pouvez également accéder à votre Portail Marchand à des fins de consultation ou de paramétrage :

3. Authentification API

L’API CentralPay utilise l’authentification HTTP Basic, qui repose sur deux éléments obligatoires à inclure dans chaque appel :

• Identifiant API (login)
• Mot de passe API

Toutes les requêtes doivent être transmises en HTTPS. Ces identifiants sont distincts entre les environnements de test et de production.

Pour récupérer vos identifiants API, suivez les étapes suivantes :

3.1. Étape 1 – Accéder au Portail Marchand

• Pour l’environnement de production : https://backoffice.centralpay.net/
• Pour l’environnement de test : https://test-backoffice.centralpay.net/

3.2. Étape 2 – Ouvrir la section technique

Depuis le menu de navigation : Administration > Mon compte > Technique

• Lien direct en production : https://backoffice.centralpay.net/admin/actor/account#technical_tab
• Lien direct en test : https://test-backoffice.centralpay.net/admin/actor/account#technical_tab

3.3. Étape 3 – Récupérer l’Identifiant API (login)

1. Dans l’onglet Technique, localisez la zone « Identifiant API »
2. Cliquez sur l’identifiant affiché pour l’ouvrir en détail
3. Copiez la valeur indiquée dans le champ Login

⚠️ Ce login est à fournir dans l’en-tête Authorization de vos requêtes (sous forme de base64 avec le mot de passe, voir plus bas).

3.4. Étape 4 – Générer un Mot de passe API

1. Toujours dans le même écran, cliquez sur le bouton Modifier
2. Cliquez ensuite sur Générer un mot de passe
3. Copiez immédiatement le mot de passe généré, attention il n’est affiché qu’une seule fois
4. Cliquez enfin sur Mettre à jour pour valider le nouveau mot de passe

Si vous perdez le mot de passe, vous devrez recommencer cette opération pour en générer un nouveau.

ℹ️ Bonnes pratiques :
- L’identifiant et le mot de passe peuvent être révoqués ou régénérés à tout moment depuis le portail marchand.
- Ne partagez jamais ces identifiants en clair.
- Stockez le mot de passe dans un gestionnaire sécurisé après sa génération.

4. Clé publique Marchand (MerchantPublicKey)

Certains services, comme cardToken, ne nécessitent pas d’identifiant/mot de passe mais uniquement une clé publique marchand (MerchantPublicKey) pour authentifier la requête.

Où la trouver :

• Connectez-vous au Portail Marchand de production ou de test
• Accédez à : Administration > Technique
• Copiez la clé dans la section Merchant Public Key

5. Méthodes HTTP et MIME Types

Nos APIs sont conformes au style REST, avec les méthodes HTTP suivantes :

Les types MIME suivants sont utilisés :

• application/x-www-form-urlencoded
• multipart/form-data

Le Content-Type doit être systématiquement précisé dans les en-têtes HTTP.

6. En-têtes HTTP à utiliser

Chaque appel API doit inclure un certain nombre d’en-têtes HTTP correctement renseignés :

7. Idempotence : sécuriser les réémissions

L’en-tête Idempotence-Key permet de garantir qu’une même requête envoyée plusieurs fois avec la même clé ne sera traitée qu’une seule fois.

Cela est particulièrement utile lors d’une erreur réseau ou d’un doute sur la réussite d’un appel.

La valeur de l’en-tête Idempotence-Key est un hachage SHA1 des principaux champs métier de la requête. Elle doit être unique par combinaison fonctionnelle de données. Exemple pour une opération carte :

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

La clé Idempotence-Key est valable pendant 24h maximum sur nos serveurs

8. Réponses HTTP

Chaque réponse retournée par l’API contient des éléments de traçabilité utiles dans les en-têtes :

La réponse JSON du corps dépend bien sûr de la ressource appelée (paiement, transfert, onboarding…), mais le header Request-Id est systématique.

9. Déclaration de vos domaines pour les services CustomForm

Pour certains services tels que cardToken, qui dépendent des formulaires embarqués (CustomForm), il est nécessaire de déclarer au préalable les domaines web qui hébergent ces formulaires.

Sans cette déclaration, toute tentative d’appel aux services concernés depuis un domaine non autorisé entraînera une erreur 403 (Forbidden).

1. Connectez-vous au Portail Marchand :
   • Production
   • Test
2. Accédez à :
   • Administration > Mon compte > Technique
3. Cliquez sur Modifier
4. Dans le champ Hosts Custom Forms autorisés, saisissez l’URL ou les domaines à autoriser (ex : https://www.votre-site.com)
5. Enregistrez les modifications

Une fois cette étape effectuée, les services comme cardToken pourront être appelés depuis les domaines déclarés, conformément aux règles de sécurité imposées par CentralPay.

Le Portail Marchand est une interface web connectée aux APIs de CentralPay. Il permet de consulter l’activité et d’administrer votre compte Marchand CentralPay. Les marchands Mandataires peuvent également consulter le détail des comptes de leurs sous-marchands.

Accès :

1. Fonctionnalités

Le Portail Marchand 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 « Mandataires » 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

ℹ️ Les comptes ayant des droits "Basic" (sous-marchands de mandataires) 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 Marchand.

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

Lors de la création du compte Marchand 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 »
  • Prochainement

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 ».

ℹ️ 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.

Accès :

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

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 Marchand (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 du Portail Marchand, les créations de rôles utilisateurs du Portail, la création et la gestion d’utilisateurs API…
• Standard read only : Prochainement
• Prochainement

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

Accès :

2.3. 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.

Accès :

3. Liste des types d’opérations visibles sur le Portail Marchand

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 :

Soit via la page d’accueil du portail Client, en renseignant les informations d’un de leurs paiements opéré avec votre compte Marchand CentralPay :

Ou 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 Marchand : Compte Customer Détail CustomerId

• Portail Client de RCT : https://test-customer.centralpay.net/customer/?uuid=[CustomerId]
• Portail Client de PROD : https://customer.centralpay.net/customer/?uuid=[CustomerId]

Le portail d’inscription permet la création d’un Compte Marchand 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 marchands Mandataires, 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 :

1. Fonctionnement

Une transaction carte comprend une succession d’actions :

1.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é, etc.) 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 »)

1.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, etc.), le service de « pré-autorisation » donne la possibilité au marchand d’étendre le délai d’autorisation jusqu’à 30 jours.

1.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).

Le service API Transaction permet d’effectuer une autorisation suivie d’une capture des fonds sur la carte bancaire de votre client. Tous les modes de paiement par carte (paiement simple, récurrents, MoTo, etc.) sont gérés via ce service.

Lorsqu’un client souhaite effectuer un premier paiement, ses données de carte doivent être collectées pour générer un cardTokenId, grâce au service de tokenisation « token.js » de CentralPay. Ce token temporaire permet ensuite de créer une ressource Card, identifiée par un cardId, pouvant être enregistrée dans un objet Customer. Ce rattachement est indispensable pour permettre des paiements ultérieurs sans redemander la carte (paiement en 1 clic, récurrents, etc.).

ℹ️ Avec un formulaire de paiement personnalisé (CUSTOM FORM), l'intégration de l'authentification 3DS 2.2 est obligatoire avant d'exécuter une transaction.

Schéma du flux de paiement avec cardTokenId :

ℹ️ Si vous disposez d'une certification PCI-DSS de niveau 1 et que vous gérez les données de carte, vous pouvez directement créer un objet /card en envoyant les données (PAN, date d'expiration, CVC) à l'API, sans passer par token.js.

1. Prérequis

1.1. Déclarer vos domaines

Avant d’utiliser le token.js, vous devez déclarer les domaines hébergeant vos formulaires Custom dans votre Portail Marchand. Allez dans Administration Mon compte Technique Modifier , puis complétez le champ Hosts Custom Forms autorisés.

Accès :

1.2. Sécuriser votre formulaire

Assurez-vous que vos pages de paiement utilisent le protocole HTTPS avec TLS 1.2 ou supérieur.

1.3. Conformité PCI-DSS

L’utilisation de token.js implique que vous gérez vous-même l’affichage du formulaire et le déclenchement du token. Cette méthode impose de respecter les exigences PCI DSS SAQ A-EP.

Téléchargez le formulaire A-EP ➝

2. Intégration du formulaire de paiement

2.1. Créer un formulaire de paiement HTML

Contrairement au Smart Form hébergé par CentralPay, le Custom Form est créé par vos soins, via votre propre code HTML. Vous devez implémenter les champs suivants :

• Numéro de carte : 16 chiffres pour CB/Visa/Mastercard, 15 pour American Express
• Date d’expiration : format MM/AAAA
• CVC : 3 chiffres (CB/Visa/Mastercard), 4 chiffres (Amex)

Vous pouvez consulter nos exemples de formulaires Custom Form :

• Consultez l’exemple de formulaire Custom Form sans 3DS 2.2 ➝
• Consultez l’exemple de formulaire Custom Form avec 3DS 2.2 ➝

2.2. Intégration du script token.js

Ajoutez dans votre page le script token.js pour générer un cardTokenId :

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

Ajoutez ensuite votre clé publique marchand (MerchantPublicKey) dans un tag distinct :

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

Vous pouvez voir où retrouver votre MerchantPublicKey depuis la page Authentification de nos API.

Intégration dans une application mobile

Si vous utilisez une WebView dans votre application, vous pouvez intégrer soit un formulaire personnalisé avec token.js, soit un formulaire hébergé via le service PaymentRequest. Ces options vous permettent d’externaliser la collecte des données carte tout en offrant une expérience utilisateur fluide.

Dans une application mobile native, le script token.js n’est pas compatible. Vous devez alors collecter les données de carte via les champs de l’application, puis appeler directement l’API cardToken en utilisant votre merchantPublicKey.

L’appel à l’API cardToken doit inclure un en-tête HTTP Origin correspondant à une URL déclarée dans votre compte Marchand CentralPay (voir 2.1 Prérequis).

Pour vos tests, vous pouvez utiliser l’Origin suivant : https://example.centralpay.net

ℹ️ Pour les applications mobiles natives, les données de carte sont transmises directement depuis le device de l’utilisateur vers CentralPay, sans passer par les serveurs du marchand. Cependant, ce type d’intégration nécessite de veiller à respecter les exigences de sécurité et de conformité PCI-DSS applicables à la collecte et la transmission de données de carte dans un environnement natif.

2.3. Créer un Customer et rattacher une carte

ℹ️ Le cardTokenId est un token à usage unique, dont le CVC est temporaire (10 minutes en production, 5 minutes en RCT). Passé ce délai, le token expire automatiquement (status=EXPIRED) et ne peut plus être utilisé, ce qui entraînera l’erreur suivante : "cardTokenId": "Card token already used". 

Que vous utilisiez la carte immédiatement (paiement simple) ou que vous souhaitiez la réutiliser plus tard (paiement en 1 clic, récurrent, etc.), il est recommandé de commencer par créer un objet Customer, puis d’enregistrer une Card à l’aide du cardTokenId. L’authentification 3DS 2.2 pouvant parfois allonger le délai de traitement, cette séquence permet d’éviter l’expiration du CVC associé au cardToken.

1. Créez un objet customer via l’endpoint POST /customer ou récupérez le customerId s’il est déjà connu
2. Créez une card en utilisant POST /card en spécifiant le cardTokenId émis par le token.js et le customerId

Une fois la card rattachée à un customer, le CVC devient permanent et les transactions futures peuvent être initiées sans limite de temps.

Si vous n'utilisez pas le token.js (certification PCI-DSS requise), vous pouvez directement créer une card sans passer par le cardToken en fournissant le PAN + expiration + CVC + customerId

3. Authentification 3DS 2.2

Avant d’initier une transaction par carte, vous devez vérifier l’identité du porteur via une authentification 3DS 2.2. Cette étape est obligatoire pour les transactions carte unitaire comme pour les transactions carte récurrente.

ℹ️ Exception : Les transactions de type MoTo (Mail Order / Telephone Order) ne sont pas soumises à l’authentification 3DS. Vous pouvez créer la transaction directement après la création de la carte.

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 »)

1. Caractéristiques

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) :

1.1. Le 3DS 2 « BRW » ou « Browser Authentication » (porteur participant – 1ère transaction)

Il 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 ➝

1.2. Le 3DS2 « 3RI Authentification » (porteur non participant – échéances de paiements récurrents)

Le 3DS Requestor Initiated (3RI) Authentications, ou Authentification Initialisée par le marchand, est utilisée lorsque le porteur n’est pas présent ou non participant.

Le 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 et une 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 assurez 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 Marchand.

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 Marchand » 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.

1. Apple Pay (Custom Form)

1.1. Via token Apple Pay déchiffré

CentralPay permet le traitement des paiements par carte effectués via Apple Pay, dans le cadre d’une intégration Custom (hors Smart Form).

ℹ️ CentralPay ne prend actuellement en charge que les tokens Apple Pay déchiffrés. Cette méthode implique une responsabilité PCI-DSS importante de votre part (formulaire SAQ-D). Renseignez-vous et assurez-vous d'être en conformité avant de développer ce mode d'intégration.

Prérequis

1. Créer un compte Apple Developer :

• Inscrivez-vous au programme Apple Developer
• Créez vos identifiants de marchand Apple Pay (Merchant ID)
• Générez votre certificat de traitement Apple Pay via le portail Apple
• Déclarez votre domaine (Apple Pay Merchant Domain)

2. Intégration côté device :

• Implémentez Apple Pay côté frontend via Apple Pay JS (pour les sites web) ou PassKit (pour les apps iOS)
• Collectez le token Apple Pay (ApplePayToken) après validation du paiement par l’utilisateur (Face ID, Touch ID…)

Étape 1 : Déchiffrement du token Apple Pay

Le déchiffrement du token Apple Pay doit être effectué sur votre backend, à l’aide de :

• Votre certificat de traitement Apple Pay
• Votre clé privée
• La documentation Apple : Payment Token Format

Le résultat contiendra :

{
  "applicationPrimaryAccountNumber": "5454********2664",
  "applicationExpirationDate": "YYMMDD",
  "paymentData": {
    "cryptogram": "base64-cryptogram",
    "eciIndicator": "05"
  }
}

Étape 2 : Création du cardToken CentralPay

Utilisez l’endpoint POST /cardToken de l’API CentralPay

ℹ️ Où trouver la merchantPublicKey ?
Connectez-vous à votre portail         
            CentralPay Back Office  Administration  Technique  Merchant Public Key        
        

Exemple :

card[number]=5454696696312664
card[expirationMonth]=12
card[expirationYear]=2031
onlinePaymentCryptogram=MGnp3S1LBgJxAANgdNCRAoABFIA=
applePayTransactionId=3d2b17abed2696ca...
amount=2500
currency=EUR
merchantPublicKey=abcdef123456...

Le cardToken généré contient toutes les données nécessaires à l’authentification Apple Pay.

Étape 3 : Création de la transaction CentralPay

Utilisez l’endpoint POST /transaction de l’API CentralPay

Champs requis :

cardToken=...
amount=2500
currency=EUR
pointOfSaleId=...
endUserIp=...
merchantTransactionId=...

Le cardToken encapsule déjà le contexte Apple Pay et les données d’authentification.

Étape 4 : Testing avant mise en production

L’environnement de test CentralPay permet de valider l’ensemble de votre intégration Apple Pay sans déclencher de véritables paiements. Il est fortement recommandé d’utiliser cet environnement pour toutes les phases de développement, de debug et de validation côté frontend comme backend.

Différences entre environnement de test et de production :

• Les URLs des API sont différentes : Elles utilisent le préfixe test-
  • Test : https://test-api.centralpay.net/v2/rest/transaction
  • Production : https://api.centralpay.net/v2/rest/transaction
• Les identifiants API (login + secret) sont propres à l’environnement de test. Ils ne sont pas interchangeables avec ceux de production
• La clé publique Apple Pay (merchantPublicKey) est également spécifique à l’environnement

2.2. Via token ApplePay chiffré

ℹ️ Au 18/04/2025, cette méthode n’est pas encore disponible chez CentralPay.
Si cette méthode d’intégration vous intéresse, veuillez contacter le support CentralPay afin de connaître les livrables associés et les modalités d’accès.

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 incluent les éléments paymentData, paymentMethod et transactionIdentifier.
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 (Custom Form)

2.1. Via token Google Pay déchiffré

Pour pouvoir accepter les paiements Google Pay via CentralPay, vous devez configurer correctement votre compte marchand Google et gérer les clés de chiffrement nécessaires au déchiffrement des tokens.

ℹ️ Cette méthode implique une responsabilité PCI-DSS importante de votre part. Renseignez-vous et assurez-vous d'être en conformité avant de développer ce mode d'intégration.

Prérequis

1. Créer un compte Google Pay Business :

• Accédez au Google Pay Business Console
• Créez un Merchant Profile ou connectez-en un existant
• Renseignez vos coordonnées de société et d’activité

2. Enregistrer votre domaine :

• Dans la console Google Pay, allez dans l’onglet « Domains« 
• Ajoutez votre domaine de production et de test (ex : example.com)
• Google vous demandera d’y héberger un fichier de vérification pour valider votre propriété

3. Générer votre paire de clés de chiffrement :

Google Pay chiffre les tokens envoyés à votre site en utilisant une clé publique que vous fournissez.

• Générez votre paire de clés (exemple avec OpenSSL)

# Générer la clé privée
openssl ecparam -name prime256v1 -genkey -noout -out private-key.pem

# Extraire la clé publique
openssl ec -in private-key.pem -pubout -out public-key.pem

• Convertissez la clé publique au format Google (base64 sans en-tête PEM)

# Supprimer les lignes "-----BEGIN..." et "-----END..."
# et ne garder que le bloc de contenu base64

4. Enregistrer votre clé publique dans Google Pay

• Dans la console Google Pay, allez dans “Payment Processing”
• Ajoutez un nouvel encrypting key
• Donnez-lui un nom, collez votre clé publique au format Base64, et sélectionnez le type : ECv2
• Cette clé sera utilisée pour chiffrer tous les tokens envoyés à votre site

Étape 1 : Déchiffrement du token Google Pay

Une fois Google Pay intégré côté frontend (Google Pay JS ou Android), vous recevrez un token chiffré via :

paymentData.tokenizationData.token

Ce champ contient un JSON chiffré (pas un JWT), que vous devez déchiffrer sur votre backend à l’aide de la clé privée correspondant à la clé publique enregistrée chez Google.

Google propose une bibliothèque de déchiffrement officielle en Java, mais des portages existent en Node.js, PHP, Python, etc.

Consultez la documentation officielle (Payment Data Cryptography) ➝

Une fois déchiffré, vous obtiendrez une structure similaire à :

{
  "pan": "4111111111111111",
  "expirationMonth": "12",
  "expirationYear": "2030",
  "cryptogram": "AgAAAAAAAIR8CQrXcIhbQAAAAAA=",
  "eciIndicator": "05"
}

Ce sont ces données que vous devrez envoyer à CentralPay pour créer un cardToken.

Étape 2 : Création du cardToken via l’API CentralPay

Utilisez l’endpoint POST/cardToken de l’API CentralPay

ℹ️ Où trouver la merchantPublicKey ?
Connectez-vous à votre portail         
            CentralPay Back Office  Administration  Technique  Merchant Public Key        
        

Exemple :

card[number]=5454696696312664
card[expirationMonth]=12
card[expirationYear]=2031
onlinePaymentCryptogram=MGnp3S1LBgJxAANgdNCRAoABFIA=
googlePayTransactionId=ABCD-EFGH-1234
amount=2500
currency=EUR
merchantPublicKey=abcdef123456...

Le cardToken généré contient toutes les données nécessaires à l’authentification Google Pay.

Étape 3 : Création de la transaction CentralPay

Utilisez l’endpoint POST/transaction de l’API CentralPay.

Champs requis :

cardToken=...
amount=2500
currency=EUR
pointOfSaleId=...
endUserIp=...
merchantTransactionId=...

Le cardToken encapsule déjà le contexte Google Pay et les données d’authentification.

Étape 4 : Testing avant mise en production

L’environnement de test CentralPay permet de valider l’ensemble de votre intégration Google Pay sans déclencher de véritables paiements. Il est fortement recommandé d’utiliser cet environnement pour toutes les phases de développement, de debug et de validation côté frontend comme backend.

Différences entre environnement de test et de production :

• Les URLs des API sont différentes : elles utilisent le préfixe test-
  • Test : https://test-api.centralpay.net/v2/rest/transaction
  • Production : https://api.centralpay.net/v2/rest/transaction
• Les identifiants API (login + secret) sont propres à l’environnement de test
  Ils ne sont pas interchangeables avec ceux de production
• La clé publique Apple Pay (merchantPublicKey) est également spécifique à l’environnement

2.2. Via token Google Pay chiffré

CentralPay permet l’intégration directe de Google Pay via le mode “gateway” (passerelle de paiement), sans nécessiter de déchiffrement du token côté serveur. Dans ce mode, CentralPay est désigné comme prestataire (gateway) auprès de Google Pay, et gère la validation du token pour vous.

Prérequis

1. Créer un compte Google Pay Business :

• Accédez au Google Pay Business Console
• Créez un Merchant Profile ou connectez-en un existant.
• Renseignez vos coordonnées de société et d’activité.

2. Enregistrer votre domaine :

• Dans la console Google Pay, allez dans l’onglet « Domains »
• Ajoutez votre domaine de production et de test (ex : example.com)
• Google vous demandera d’y héberger un fichier de vérification pour valider votre propriété

3. Réaliser votre intégration frontend Google Pay :

• Implémentez Google Pay côté frontend via Google Pay JS (pour les sites web) ou Google Pay API Android (pour les applications mobiles)
• Collectez le token Google Pay (tokenizationData.token) après validation du paiement par l’utilisateur (code PIN, empreinte digitale, reconnaissance faciale…).

ℹ️ Google propose un tutoriel officiel pour cette intégration : Google Pay API | Google for Developers

4. Récupérez vos identifiants CentralPay :

• MerchantPublicKey : Connectez-vous à votre portail CentralPay Back Office → Administration → Technique → Merchant Public Key
• Login API : Connectez-vous à votre portail CentralPay Back Office → Administration → Technique → Identifiant API et copiez l’identifiant
• Pass API : Connectez-vous à votre portail CentralPay Back Office → Administration → Technique → Cliquez sur votre Identifiant API → Modifier → Générer , copiez votre pass API et mettez à jour

Étape 1: Configuration de Google Pay côté frontend

1. Définir la version de l’API :

const baseRequest = {
  apiVersion: 2,
  apiVersionMinor: 0
};

2. Utiliser CentralPay comme passerelle de paiement :

Configurez la tokenisation comme suit :

const tokenizationSpecification = {
  type: 'PAYMENT_GATEWAY',
  parameters: {
    gateway: 'centralpay',
    gatewayMerchantId: 'YOUR_GATEWAY_MERCHANT_ID'
  }
};

Remplacez YOUR_GATEWAY_MERCHANT_ID par votre MerchantPublicKey fourni par CentralPay.

3. Environnement de test ou production :

// Environnement de test
const paymentsClient = new google.payments.api.PaymentsClient({ environment: 'TEST' });

// Environnement de production
const paymentsClient = new google.payments.api.PaymentsClient({ environment: 'PRODUCTION' });

Étape 2 : Récupération du token Google Pay

Lorsqu’un utilisateur final valide un paiement via Google Pay, l’API retourne un token au format JSON dans :

paymentData.paymentMethodData.tokenizationData.token

Ce champ contient une chaîne JSON représentant un objet du type :

{
  "signature": "MEYCIQDn...",
  "protocolVersion": "ECv2",
  "intermediateSigningKey": {
    "signedKey": "{...}",
    "signatures": ["MEUCID..."]
  },
  "signedMessage": "{...}"
}

Ce bloc devra être transmis tel quel à l’API CentralPay lors de la création du cardToken dans le champ googlePayToken.

Étape 3 : Envoi du token à CentralPay (création du cardToken)

Faites un appel à l’endpoint POST /cardToken de CentralPay avec les paramètres suivants :

Paramètres requis :

Exemple de requête (format x-www-form-urlencoded) :

amount=2500
currency=EUR
merchantPublicKey=abcdef123456...
googlePayToken={"signature":"MEYCIQDn...","protocolVersion":"ECv2",...}

Ne déchiffrez pas le token vous-même : CentralPay s’occupe de sa validation côté serveur.

Étape 4 : Création de la transaction

Une fois que le cardToken est obtenu, vous pouvez déclencher une transaction de manière standard via l’endpoint POST /transaction.

Exemple de paramètres :

cardToken=...
amount=2500
currency=EUR
pointOfSaleId=...
endUserIp=...
merchantTransactionId=...

Le cardToken contient déjà toutes les informations d’authentification : pas besoin d’ajouter de cryptogramme ou de champ CVV.

Étape 5 : Testing avant mise en production

L’environnement de test CentralPay permet de valider l’ensemble de votre intégration Apple Pay sans déclencher de véritables paiements. Il est fortement recommandé d’utiliser cet environnement pour toutes les phases de développement, de debug et de validation côté frontend comme backend.

Différences entre environnement de test et de production :

• Les URLs des API sont différentes : elles utilisent le préfixe test-
  • Test : https://test-api.centralpay.net/v2/rest/transaction
  • Production : https://api.centralpay.net/v2/rest/transaction
• Les identifiants API (login + secret) sont propres à l’environnement de test
  Ils ne sont pas interchangeables avec ceux de production
• La clé publique Apple Pay (merchantPublicKey) est également spécifique à l’environnement

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 Marchand. 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

ℹ️ 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 Marchand 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.

ℹ️ 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.

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.

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 Marchand.

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 Marchand CentralPay est créé, un libellé de relevé bancaire est défini automatiquement en utilisant le nom de votre premier Point de Vente : CPAY*NomDuPointDeVente

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.

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 Marchand 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. Fonctionnement

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. Suite à la crise du Covid 19, Booking.com 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.com
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 (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 :

Consultez la liste complète des codes de retour banque ➝

2. Statuts liés aux transactions carte

Consultez les Statuts Transaction ➝

Consultez les Statuts Refund ➝

Consultez les Statuts Credit ➝

Consultez les Statuts Disputes ➝

Consultez les Statuts Subscription ➝

Consultez les Statuts Installement ➝

3. Webhooks liés aux transactions carte

Consultez les Webhooks Transaction ➝

Consultez les Webhooks Card ➝

Consultez les Webhooks Refund ➝

Consultez les Webhooks Credit ➝

Consultez les Webhooks Customer ➝

Consultez les Webhooks Dispute ➝

Consultez les Webhooks Subscription ➝

Consultez les Statuts Installement ➝

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.