CentralPay propose des solutions de paiement modulaires permettant l’unification des flux d’encaissement pour compte propre et l’automatisation des versements 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é.

1. Les types d’acteurs

2. Les types de comptes

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

Le Profil Marchand représente techniquement et opérationnellement un Marchand dans la plateforme CentralPay.

Il est le support de :
• Ses comptes : de paiement ou de monnaie électronique ;
• Son administration : accès API, profils utilisateurs, services de paiement disponibles ;
• Sa configuration technique : webhooks, notifications, points de vente, règles d’acceptation, comptes bancaires ;
• Son dossier réglementaire : KYC/KYB, LCB-FT, scoring de risque, contractualisation, grille tarifaire…

Le Profil Marchand correspond à l’objet API Merchant et est créé automatiquement après validation de son inscription (via l’objet API Merchant-Enrollment).

1. Types de profils selon le modèle contractuel

Chaque type de 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, 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 : INTEGRATOR

Le 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 réaliser des appels API et actions techniques via les accès délégués par le Marchand (suivi d’Instructions Techniques, paramétrage, RUN), sans accès aux soldes ni pouvoir d’initier/modifier/exécuter une opération de paiement en son nom propre
• CentralPay facture chaque Marchand directement

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

Partenaire Intégrateur MOBSP Type : INTEGRATOR + MOBSP

Le 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 : TECHNIQUE

Le Partenaire Technique développe une solution mutualisée (ex. marketplace, plateforme SaaS) et opère depuis un ou plusieurs points de vente ouverts à son nom, auxquels des Marchands standards peuvent être rattachés. Il utilise ses propres accès API pour transmettre des données commerciales et suivre les opérations rattachées à ces points de vente, sans jamais disposer d’un pouvoir d’exécution sur les opérations de paiement.

• Un ou plusieurs points de vente peuvent être utilisés 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 l’enrôlement au nom et pour le compte des marchands (sauf cadre MOBSP applicable)

👉 En savoir plus sur le modèle Partenaire Technique

Partenaire Technique MOBSP Type : TECHNIQUE + MOBSP

Le 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êmes droits 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 Mandataire DME (Distributeur de Monnaie Électronique) transmet des instructions de chargement, de transfert ou de remboursement en monnaie électronique pour le compte de Participants. Il agit dans le cadre du modèle monnaie électronique (devises CUSTOM) et peut percevoir une commission sur les opérations, sans fournir de services de paiement régulés (ex. virement SEPA, prélèvement, carte).

👉 En savoir plus sur le modèle Mandataire DME

Mandataire Agent Type : AGENT

Le Mandataire Agent est un Agent de Prestataire de Services de Paiement (Agent PSP) enregistré auprès de l’ACPR. Il agit au nom et pour le compte de CentralPay dans un périmètre strictement défini contractuellement. Selon le modèle retenu (Agent simple / Agent collecteur / Agent délégataire), il peut notamment accompagner l’enrôlement, réaliser certaines diligences KYC/KYB de niveau 1, et/ou intervenir dans la collecte, la ventilation et la mise à disposition des fonds via les mécanismes prévus par CentralPay. CentralPay demeure responsable des services de paiement fournis et des contrôles réglementaires.

👉 En savoir plus sur le modèle Mandataire Agent

Participant Type : BASIC

Les Participants sont des personnes physiques ou morales clientes d’un Marchand Mandataire de CentralPay (Agent ou DME). Ils disposent d’un ou plusieurs comptes de paiement ou de monnaie électronique pour recevoir des fonds émis par le Mandataire, et peuvent accéder au portail Marchand pour consulter leurs opérations et gérer leurs versements sortants.

Ils agissent pour vendre des produits ou services, pour une activité LMNP, ou pour des besoins non commerciaux (crowdfunding, wallet personnel, projets collectifs…).

Les participants ouvrent des comptes chez CentralPay. L’entrée en relation peut être initiée et/ou accompagnée par le Marchand Mandataire, mais les services régulés restent fournis par CentralPay. Le cadre d’utilisation des comptes est défini par les documents CentralPay applicables (et, le cas échéant, par les CGU du Mandataire pour les conditions commerciales et les services qu’il fournit).

2. Paramétrage des emails de contact

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

• Email contact : référent principal du profil marchand
• 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 profil marchand. 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 vos comptes 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 profil 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 profil marchand (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 profil marchand, 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, versement 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 versements 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 profil Marchand CentralPay. Ainsi, chaque compte de paiement sera lié à un compte bancaire différent et adressera des versements 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 mandataire AGENT de CentralPay, vous pouvez créer des comptes pour vos marchands en utilisant le service de demande d’enrôlement.

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

Le modèle Marchand standard s’adresse aux entreprises (personnes morales) qui souhaitent utiliser la plateforme CentralPay pour encaisser des paiements pour leur propre compte dans le cadre d’une activité de vente de biens ou de services.

1. Description du modèle

Ce modèle vous donne accès à l’ensemble des services de Smart Collection, la solution d’encaissement complète proposée par CentralPay.

🔗 Plus d’informations sur Smart Collection

Les fonctionnalités incluses sont les suivantes :

• Le Profil Marchand CentralPay
  Un profil marchand standard contenant un ou plusieurs comptes de paiement dédiés à votre activité, avec IBAN individuel, suivi des opérations et des versements.
• Les services liés au compte
  Outils de gestion, profils utilisateurs, accès API, notifications, reporting…
• Le service d’encaissement Smart
  Centralisation de vos flux, routage automatisé, gestion des statuts et des versements.
• Transactions par carte bancaire
  Acceptation Visa/Mastercard, 3D Secure, Apple Pay/Google Pay, gestion des remboursements et des contestations.
• Transactions par virement
  Génération d’IBAN virtuels, notifications de réception, rapprochements automatiques.
• Transactions par prélèvement SEPA
  Débits ponctuels ou récurrents, gestion des mandats, suivi des rejets.

2. Frais et commissions

Des commissions fixes et variables sont appliquées en fonction des opérations réalisées (transactions, versements, rejets, etc.). Vous pouvez consulter les tarifications publiques sur notre site.

• Les frais sont débités :
  • Soit directement de votre compte de paiement principal
  • Soit depuis un compte de commission dédié, si celui-ci est activé

En cas de solde insuffisant, CentralPay pourra procéder à un prélèvement SEPA sur votre compte bancaire ou vous adresser une demande de virement complémentaire.

CentralPay propose deux modèles distincts pour les partenaires souhaitant accompagner des marchands CentralPay dans leur intégration technique : le Partenaire Technique et le Partenaire Intégrateur. Dans les deux cas, les marchands restent en relation contractuelle directe avec CentralPay ; les modalités d’accès API, de mutualisation et de facturation diffèrent selon le modèle.

Selon la nature de leur activité, ces partenaires peuvent également être immatriculés à l’ORIAS en qualité d’IOBSP (mandataire – “MOBSP”) afin d’encadrer juridiquement certaines activités de présentation et d’accompagnement des marchands lors de leur entrée en relation avec CentralPay. Ce statut ne confère aucun droit d’accès aux fonds ni aucun pouvoir d’exécution d’opérations de paiement.

1. Partenaire Intégrateur

Le Partenaire Intégrateur est un prestataire technique mandaté par un ou plusieurs marchands standards. Il intervient en leur nom et pour leur compte, afin de faciliter leur connexion aux services CentralPay.

Chaque marchand standard dispose de son propre point de vente (POS), de son propre profil Marchand CentralPay, et signe directement ses documents de souscription et son contrat (CCSP) avec CentralPay. L’Intégrateur ne détient aucun droit contractuel sur les comptes ou fonds du marchand.

1.1. Responsabilités et fonctionnement

• L’Intégrateur utilise les accès API délégués par chaque marchand (identifiants dédiés “Intégrateur”), dans le cadre d’un mandat contractuel entre l’Intégrateur et le marchand
• Il peut réaliser des actions techniques nécessaires à l’intégration et au RUN (paramétrage, suivi d’Instructions Techniques, maintenance), exclusivement via ces accès, sans pouvoir consulter les soldes ni initier / modifier / annuler une opération de paiement
• Les parcours sont généralement réalisés en “1 pour 1” : un client (payeur) règle un seul marchand, chaque marchand conservant son environnement et ses accès propres

1.2. Facturation

• Chaque marchand est facturé directement par CentralPay au titre des services souscrits dans son CCSP
• Le Partenaire Intégrateur n’intervient à aucun moment dans les flux financiers

1.3. Pour aller plus loin sur le modèle d’Intégrateur

2. Partenaire Technique

Le Partenaire Technique est un acteur qui développe une solution mutualisée (ex. : marketplace, plateforme SaaS), à destination de plusieurs marchands standards. Il opère depuis un ou plusieurs points de vente ouverts à son nom dans CentralPay, auxquels des marchands peuvent être rattachés.

Les opérations sont traitées par CentralPay au moyen d’un mécanisme interne de “Compte de Traitement” (utilisé par CentralPay pour recevoir et traiter temporairement les fonds en vue de leur transmission au bénéficiaire final). Le Partenaire Technique n’y dispose d’aucun droit de disposition : il transmet uniquement des données commerciales et conserve une visibilité sur les flux rattachés à ses points de vente, sans jamais pouvoir déclencher un transfert.

2.1. Responsabilités et fonctionnement

• Le Partenaire Technique dispose de ses propres accès API délivrés par CentralPay
• Il peut transmettre des Instructions Techniques (données commerciales, panier, commission, références, évènements logistiques…), et suivre les transactions rattachées aux marchands liés à ses points de vente
• Il n’a aucun accès aux fonctionnalités de transfert (notamment l’endpoint transfer) et ne peut pas accéder aux soldes ni effectuer de versements : CentralPay décide et exécute les opérations et mises à disposition de fonds
• Dans ce cadre, CentralPay peut gérer des paiements en mode “1 pour X” : un client (payeur) peut régler plusieurs marchands simultanément, CentralPay assurant ensuite la ventilation/mise à disposition au bénéfice des marchands

2.2. Facturation

• Le Partenaire Technique est facturé par CentralPay en fonction des opérations réalisées via son (ou ses) point(s) de vente, conformément aux conditions prévues au CCSP et aux documents de souscription applicables
• Lorsqu’une commission est prévue, CentralPay peut, sur la base des données commerciales transmises et selon les règles contractuelles, ventiler les flux : la part de commission est alors créditée sur le compte de commission du Partenaire Technique, sans que celui-ci ne détienne de fonds de tiers

Pour aller plus loin sur le modèle de Partenaire Technique

• Le Partenaire Technique développe une solution mutualisée (ex. : marketplace, plateforme SaaS) intégrant CentralPay. Il opère depuis un ou plusieurs points de vente ouverts à son nom, qui accueillent les transactions de marchands standards associés
• Chaque marchand associé contracte directement avec CentralPay (CCSP et documents de souscription) et dispose de son propre profil Marchand CentralPay
• Le Partenaire Technique transmet à CentralPay les données commerciales des transactions (montant commercial, références, commission, évènements logistiques…). Ces données ne déclenchent aucun effet financier automatique : CentralPay analyse, contrôle, puis décide de traiter l’opération et d’initier les mises à disposition nécessaires
• CentralPay peut décider d’appliquer une retenue temporaire et/ou une date de déblocage pour la mise à disposition des fonds au bénéfice d’un marchand (ex. : jusqu’à une livraison/expédition), selon sa politique de risque, les règles des réseaux et ses obligations réglementaires
• Le Partenaire Technique ne détient jamais de fonds de tiers, ne donne aucun ordre de paiement, et ne peut intervenir dans les versements ou la tenue de compte. Il n’agit ni pour compte de tiers ni au nom de CentralPay
• L’accès du Partenaire Technique est limité à une vue et à des fonctionnalités strictement nécessaires à la transmission et au suivi d’Instructions Techniques ; il n’existe aucun accès au “Compte de Traitement” en tant que compte (pas de droit d’exécution, pas de droit de disposition, pas d’accès aux soldes)
• En cas d’immatriculation ORIAS en qualité d’IOBSP (mandataire – “MOBSP”) et si un cadre contractuel distinct le prévoit, le Partenaire Technique peut accompagner les marchands dans leur entrée en relation (transmission de lien d’inscription, assistance documentaire), sous réserve de validation préalable par CentralPay

3. Règles de conformité communes

Pour les deux modèles :

• Le Partenaire n’est pas prestataire de services de paiement, ne dispose d’aucun pouvoir d’exécution d’opérations de paiement et ne détient aucun fonds de tiers dans le cadre des services de paiement
• Les comptes, la mise à disposition des fonds, les versements et la protection des fonds sont gérés et encadrés par CentralPay, en sa qualité de PSP
• Aucune délégation réglementaire d’exécution de service de paiement (type agent PSP) n’est accordée à ces partenaires

3.1. Relation contractuelle avec les marchands

Le Partenaire (technique ou intégrateur) conserve sa propre relation commerciale avec ses utilisateurs et reste responsable des services proposés sur sa plateforme. Il définit librement les conditions générales d’utilisation applicables à ses services.

De leur côté, les marchands associés :

• Ouvrent leur propre profil Marchand CentralPay, lors d’un parcours d’enrôlement individualisé
• Signent directement avec CentralPay le CCSP et les documents de souscription applicables (dont la désignation éventuelle d’un partenaire)
• Reconnaissent que le partenaire pourra réaliser certaines actions techniques dans le cadre de son intégration (ex. : transmission d’une commande, remontée de panier, suivi d’Instructions Techniques), sans que cela ne constitue un ordre de paiement ni un accès aux fonds

CentralPay agit alors directement auprès du marchand associé pour :

• la création et la gestion de son compte (signature électronique, affectation des POS, rattachement au partenaire)
• le traitement réglementaire des justificatifs transmis (KYC/KYB, lutte contre le blanchiment et le financement du terrorisme)
• la mise à jour documentaire ou les vérifications complémentaires nécessaires à la bonne exécution des services de paiement

L’ensemble de cette organisation repose sur un dispositif contractuel strictement balisé :

• Le partenaire signe un contrat dédié avec CentralPay, encadrant son rôle et ses droits d’accès (API/portail) et, le cas échéant, les modalités de commissionnement
• Les marchands associés signent directement leurs documents contractuels CentralPay (CCSP et souscription), dans lesquels leur association au partenaire peut être précisée
• Les conditions générales du partenaire s’appliquent uniquement à l’usage de sa propre plateforme. Elles ne peuvent ni interférer avec les services de paiement CentralPay, ni se substituer aux documents contractuels CentralPay

4. Déclaration ORIAS (IOBSP / “MOBSP”)

Un Partenaire Intégrateur ou un Partenaire Technique peut, si son activité le nécessite, être immatriculé à l’ORIAS en qualité d’IOBSP (mandataire – “MOBSP”). Ce statut est distinct de celui d’agent de prestataire de services de paiement (au sens de l’article L.523-1 du Code monétaire et financier).

Cette immatriculation peut permettre, selon le cadre contractuel applicable :

• De présenter les services de CentralPay et d’assister le marchand dans ses démarches d’entrée en relation
• D’accompagner la constitution du dossier (sans jamais se substituer aux contrôles réglementaires réalisés par CentralPay)

Ce statut ne modifie en rien les restrictions précédemment énoncées : il ne confère aucun droit sur les fonds et aucun pouvoir d’exécution d’opérations de paiement. CentralPay demeure seul responsable de l’entrée en relation, des contrôles réglementaires et de l’exécution des services de paiement.

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

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

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

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

1. Préparez vos données

1.1. Obtenez votre attestation de mandat

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

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

1.2. Préparez vos documents justificatifs

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

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

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

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

2. Créez votre compte ORIAS

2.1. Accéder au formulaire

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

Vous serez redirigé vers le formulaire d’inscription.

2.2. Saisir les informations

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

2.3. Connectez-vous à votre compte ORIAS

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

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

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

3. Réalisez une nouvelle demande d’inscription

3.1. Enregistrez votre entreprise

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

3.2. Fournissez des informations complémentaires

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

3.3. Fournissez vos documents justificatifs

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

3.4. Payez votre inscription

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

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

4. CentralPay vous enregistre en tant que MOBSP

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

5. L’ORIAS examine votre candidature

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

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

6. Mettez à jour vos mentions légales

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

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

Agent de Prestataire de Services de Paiement (Agent PSP) ou Distributeur de Monnaie Électronique (DME)

Certains projets nécessitent un cadre réglementaire spécifique permettant à des mandataires d’agir au nom et pour le compte de CentralPay, établissement agréé et supervisé par l’ACPR. Deux statuts principaux peuvent être mobilisés en France :

• L’Agent de Prestataire de Services de Paiement (Agent PSP), pour les projets nécessitant une gestion active des flux de paiement (encaissements, transferts, versements), dans le strict cadre d’un mandat et sous la responsabilité de CentralPay
• Le Distributeur de Monnaie Électronique (DME), pour des projets reposant sur des mécanismes de valeur stockée / monnaie électronique (plateformes C2C, titres prépayés, réseaux fermés, etc.), dans le cadre d’un contrat de distribution

Ces modèles peuvent offrir une autonomie opérationnelle importante au mandataire, mais s’accompagnent de contraintes réglementaires fortes et d’une supervision permanente, sous la responsabilité de CentralPay.

1. Agent de Prestataire de Services de Paiement (Agent PSP)

1.1. Cas d’usage typiques

• Plateformes B2B avec flux financiers complexes
• Outils de gestion financière ou de trésorerie pour tiers
• Solutions SaaS intégrant l’encaissement et la mise à disposition de fonds à des bénéficiaires

1.2. Rôle de l’Agent

L’Agent PSP agit en tant que représentant réglementaire de CentralPay pour la fourniture de services de paiement, au nom et pour le compte de CentralPay, dans les limites du mandat et des droits techniques configurés.

Fonctionnalités (selon périmètre contractuel et habilitations) :

• Mise en relation commerciale et promotion des services CentralPay auprès des utilisateurs finaux (les “Participants”)
• Accompagnement des Participants à l’ouverture de comptes CentralPay (parcours CentralPay et/ou parcours piloté par l’Agent, selon modèle retenu)
• Ouverture, au nom de l’Agent, de comptes techniques dédiés à la ségrégation des flux (ex. compte de collecte et compte de commission), sans que l’Agent ne devienne propriétaire des fonds des Participants
• Transmission à CentralPay des demandes/instructions nécessaires à la bonne exécution des services (ex. affectation des fonds, demandes de versement, demandes de remboursement), CentralPay restant seul exécutant
• Gestion du support de premier niveau (N1) et traitement opérationnel défini comme prestation externalisée, avec escalade vers CentralPay lorsque requis

1.3. Les 3 options du modèle Agent (délégation KYC/KYB)

Le modèle Agent de CentralPay prévoit trois niveaux de délégation en matière d’inscription et de contrôles KYC/KYB. Une seule option est applicable à la fois, et le niveau retenu est formalisé contractuellement :

• Option A – Agent simple (absence de délégation de contrôle) : l’Agent agit comme Agent PSP déclaré mais sans délégation KYC/KYB. Il se limite à la mise en relation commerciale et oriente les Participants vers les parcours/outils fournis par CentralPay. Il ne reçoit aucun mandat pour collecter des pièces justificatives ni effectuer des contrôles.
• Option B – Agent collecteur (délégation de la complétude administrative) : l’Agent est mandaté pour constituer le dossier administratif du Participant pour le compte de CentralPay. Il collecte les pièces et réalise des vérifications strictement formelles de complétude (lisibilité, validité apparente, cohérence documentaire). Il ne réalise pas d’analyse de risque, ni filtrage sanctions/PPE, ni analyse approfondie ; la décision d’entrée en relation demeure celle de CentralPay.
• Option C – Agent délégataire de contrôle (délégation de niveau 1) : option réservée aux Agents disposant d’une organisation conformité dédiée et expressément validée par CentralPay. L’Agent peut collecter les pièces KYC/KYB, vérifier la complétude/cohérence et assurer un contrôle de vigilance de niveau 1 exclusivement formel et administratif. Il peut également participer au traitement des alertes de niveau 1 (collecte/qualification administrative/transmission), selon des procédures strictes. CentralPay conserve la décision finale et peut révoquer l’option à tout moment en cas de défaillance.

1.4. CentralPay reste responsable

• CentralPay reste pleinement responsable des services fournis aux Participants
• L’Agent agit dans le strict cadre du mandat qui lui est confié, et selon les habilitations techniques mises en place
• Toute activité réalisée via la plateforme est auditable, traçable et documentée

1.5. Contraintes réglementaires

• Signature d’un contrat d’Agent et de ses documents associés
• Enregistrement officiel en tant qu’Agent sur le registre de l’ACPR (via CentralPay)
• Évaluation de la capacité organisationnelle du mandataire et exigences renforcées (conformité, sécurité, confidentialité, continuité, contrôle interne)
• Reporting périodique à CentralPay (volume d’activité, incidents, qualité de service) et possibilité d’audit sur pièce ou sur site
• Formations obligatoires des équipes opérationnelles, selon le périmètre de délégation

2. Distributeur de Monnaie Électronique (DME)

2.1. Cas d’usage typiques

• Plateformes de vente entre particuliers (C2C)
• Réseaux d’enseignes prépayées ou de bons cadeaux
• Programmes de fidélité à valeur monétaire stockée

2.2. Rôle du DME

Le DME agit pour le compte de CentralPay dans la mise à disposition et la gestion opérationnelle de la monnaie électronique, dans les limites prévues par le contrat de distribution et les règles définies par CentralPay.

Fonctionnalités :

• Mise en relation de CentralPay avec les utilisateurs finaux (les “sous-marchands” / utilisateurs de monnaie électronique)
• Transmission à CentralPay des instructions de chargement (montant, bénéficiaire, commission), CentralPay restant seul émetteur/exécutant
• Visualisation et suivi des opérations via un dispositif de suivi dédié (ex. vue consolidée / compte centralisateur selon modèle), sans droit de disposition sur les fonds
• Transmission des demandes/instructions permettant la circulation de monnaie électronique entre utilisateurs dans un cadre défini (réseau fermé, règles contractuelles), sous contrôle de CentralPay
• Transmission des demandes de remboursement de monnaie électronique à la demande de l’utilisateur, selon les règles applicables
• Détention d’un compte de commission pour percevoir les frais définis dans ses CGU

2.3. Limites fonctionnelles

• Le DME ne détient jamais les fonds : il agit comme intermédiaire et ne peut pas conserver, stocker ou utiliser les fonds collectés
• Il n’est pas autorisé à créer/émettre lui-même de la monnaie électronique
• Il ne peut pas offrir de services de paiement non explicitement autorisés dans le cadre contractuel défini par CentralPay
• Il ne peut pas sous-traiter son activité, sauf accord explicite de CentralPay

2.4. Contraintes réglementaires

• Signature d’un contrat de distribution avec CentralPay
• Déclaration / formalités de mise en conformité réalisées sous l’initiative et la responsabilité de CentralPay, selon la réglementation applicable
• Mise en conformité organisationnelle : dispositifs internes de sécurité, confidentialité, gestion des incidents, continuité d’activité
• Supervision permanente par CentralPay, incluant :
  • Contrôle de l’usage de l’API / des habilitations
  • Reporting régulier sur l’activité
  • Formation obligatoire des équipes du DME
  • Validation des CGU utilisées auprès des utilisateurs

Rôle de l’ACPR

L’ACPR (Autorité de Contrôle Prudentiel et de Résolution), adossée à la Banque de France, tient le registre des prestataires régulés et de leurs agents. Dans le cadre d’un modèle Agent PSP, CentralPay (établissement agréé) constitue et dépose la notification/dossier d’enregistrement de l’Agent et demeure l’unique interlocuteur de l’ACPR.

Le futur Agent ne peut pas déposer de dossier directement auprès de l’ACPR : les échanges sont pilotés par CentralPay, avec le concours de l’Agent (transmission de pièces, réponses aux questions, éléments d’organisation).

Étapes de déclaration d’un Agent

1. Responsabilités de l’Agent

En tant qu’Agent PSP, l’Agent agit au nom et pour le compte de CentralPay dans le périmètre défini contractuellement. CentralPay reste pleinement responsable de la fourniture des services de paiement et de la conformité réglementaire ; toutefois, l’Agent doit appliquer strictement les procédures et exigences opérationnelles fixées par CentralPay, notamment en matière de LCB-FT et de lutte contre la fraude.

L’Agent est notamment responsable de :

• La compréhension de l’activité de ses marchands/Participants et de la cohérence économique des opérations initiées via son modèle
• La mise en œuvre des dispositifs opérationnels attendus (process internes, contrôles, traçabilité, gestion des incidents) et du respect des consignes CentralPay
• La lutte contre la fraude (détection, escalade, coopération) et le respect des obligations de vigilance dans le périmètre confié
• La coopération avec CentralPay en cas de demande d’information (contrôles, audit, questions ACPR), et la transmission rapide des pièces demandées

L’Agent doit signer :

• Un Contrat d’Agent PSP avec CentralPay (mandat / externalisation / supervision / flux)
• Le CCSP (Contrat Cadre de Services de Paiement) applicable à l’Agent en sa qualité de client professionnel de CentralPay (accès plateforme, services souscrits)
• Des CGU Agent (ou documentation équivalente) encadrant sa relation avec ses Participants, incluant les mentions nécessaires sur les parcours, la ventilation, les dates de déblocage et les éventuelles demandes de versements

Selon le périmètre retenu (et les annexes applicables), certaines fonctions peuvent être déléguées à l’Agent (ex. collecte et contrôles formels KYC/KYB). CentralPay reste seule décisionnaire de l’entrée en relation, de l’ouverture/maintien des comptes et des décisions réglementaires.

2. Devenir Partenaire Agent CentralPay

Le processus d’enregistrement d’un Agent dépend de la complétude du dossier, du niveau de délégation opérationnelle et des échanges avec l’ACPR. En pratique, il s’étale généralement sur plusieurs semaines et peut être prolongé si des pièces complémentaires sont demandées.

2.1. Résumé des étapes

2.2. Pièces à fournir à CentralPay

Phase 1 – Pré-constitution du dossier

• CGU Agent / documentation contractuelle Participants (parcours, consentements, information “agent”, ventilation/commission, dates de déblocage, modalités de remboursement)
• Définition des activités régulées, services associés, modèle d’affaires
• Organigramme (y compris répartition des effectifs par service) et description des rôles clés
• Structure de l’actionnariat / gouvernance
• Flux prévisionnels sur 3 ans confiés à CentralPay (volumes, montants, typologies)
• Nombre d’enrôlements prévisionnels sur 3 ans
• Cas de reprise de KYC existant (migration) le cas échéant

Phase 2 – Déclaration auprès du régulateur

• Signature du Contrat d’Agent (préalable au dépôt du dossier)
• CentralPay collecte et dépose les pièces suivantes (liste indicative) :
  • Kbis < 3 mois de la société et, le cas échéant, des sociétés de tête/dirigeantes
  • Statuts à jour signés
  • Pièces d’identité couleur des dirigeants
  • CV des dirigeants datés et signés
  • Casier judiciaire des dirigeants (si demandé)
  • Déclarations de non-condamnation des dirigeants
  • Répartition de la détention des parts / actionnariat
  • Kbis des personnes morales actionnaires (si applicable) + organigramme de groupe (si applicable)
  • PV d’AG récents (fusion, perte > 50% du capital, changement direction, etc.)
  • Registre des bénéficiaires effectifs (si demandé)

Peuvent également être demandés par l’ACPR :

• Bilans et comptes de résultat récents
• États financiers en cours ou de l’année précédente
• Toute pièce jugée utile par le régulateur

2.3. Délais d’instruction

• Instruction par CentralPay : généralement ~2 semaines à compter de la réception d’un dossier complet
• Délai ACPR : variable ; peut aller jusqu’à ~2 mois, avec premières questions sous 30 jours en général

2.4. Fin d’instruction

• L’Agent peut démarrer l’activité uniquement après enregistrement effectif (publication sur le registre public)
• Avant enregistrement, CentralPay n’active pas l’Agent en production et peut maintenir les comptes de l’Agent bloqués (IN/OUT)
• L’Agent est référencé dans les registres publics avec un numéro/identifiant d’enregistrement pouvant devoir figurer dans certaines communications/mentions

2.5. Particularité – Agents Télécom SVA (numéros surtaxés)

• Obligation de fournir un récapitulatif des minutes par opérateur
• Transmission du détail de répartition des encaissements (ventilation) à CentralPay
• CentralPay met en place des contrôles complémentaires afin de s’assurer que les marchands/Participants sont correctement crédités

3. Traitement des flux agent

Cette section définit les règles applicables au traitement et au contrôle des flux financiers dans un modèle Agent. Elle précise les responsabilités, la structure des comptes et les contrôles complémentaires mis en œuvre afin de répondre aux exigences légales et prudentielles.

3.1. Responsabilité de l’établissement

Conformément au Code monétaire et financier (CMF), l’Agent agit au nom et pour le compte de CentralPay. CentralPay demeure pleinement responsable du respect des obligations réglementaires, notamment en matière de LCB-FT, de sécurité et de protection des fonds.

CentralPay met en place un dispositif de contrôle interne couvrant l’ensemble du cycle des flux, y compris ceux traités dans le cadre de ses Agents (supervision, auditabilité, traçabilité).

3.2. Comptes opérationnels des agents

Pour les besoins de ségrégation des flux, CentralPay met à disposition (dans ses livres) :

• Compte de Collecte : compte de transit destiné à recevoir les fonds liés aux opérations initiées via le modèle Agent, et à permettre leur affectation/ventilation vers les comptes des Participants
• Compte de Commission : destiné à recevoir la rémunération revenant à l’Agent (commissions) et à régler les frais dus à CentralPay
• Compte de paiement Agent (optionnel) : destiné aux opérations courantes de l’Agent pour son compte propre (approvisionnement, paiement de factures SaaS, etc.), distinct des flux tiers et des commissions

3.3. Traitement des opérations

Lorsqu’un Agent initie une transaction pour le compte d’un ou plusieurs Participants :

1. L’Agent transmet à CentralPay les informations nécessaires à la ventilation (part des Participants, commission Agent, références), soit directement dans la transaction, soit au plus tard en fin de journée via un traitement par lot lorsque cela est objectivement nécessaire.
2. CentralPay exécute ensuite, sous sa responsabilité, les opérations d’affectation/ventilation et, le cas échéant, les mouvements nécessaires (dont la commission vers le compte de commission), conformément au cadre contractuel et aux contrôles réglementaires.

Le Compte de Collecte doit rester un compte de transit : l’Agent ne doit pas conserver passivement des fonds de tiers au-delà des délais strictement nécessaires au traitement (pas de “trésorerie flottante”).

Les modalités de versement sortant (Payout) sont encadrées par CentralPay ; le Compte de Collecte n’a pas vocation à servir de compte de versement sortant “libre”.

3.4. Dates de déblocage et montants prévisionnels

Fonctionnement

Selon le modèle contractuel, l’Agent peut transmettre ou paramétrer (en qualité d’intermédiaire mandaté par le Participant) une date de déblocage (endpoint API : EscrowDate) correspondant à un évènement contractuel objectivable (ex. livraison/expédition/fin de prestation). Cette date ne produit aucun effet financier automatique : CentralPay demeure seule décisionnaire de la mise à disposition des fonds (acceptation, refus, report, encadrement).

Jusqu’à la date de déblocage :

• Les fonds restent protégés et indisponibles (ni accessibles à l’Agent, ni utilisables par le Participant)
• Le Participant peut visualiser l’opération sous forme d’opération à venir ou de montant prévisionnel, avec affichage de la date de disponibilité, sans constituer un crédit au solde disponible

Conditions de conformité

L’usage des dates de déblocage est autorisé uniquement si :

• Information claire : l’Agent doit expliquer à ses Participants comment fonctionne la date de déblocage (principes, délais, exceptions).
• Affichage transparent : l’interface Participant doit indiquer la date de l’opération, la date de disponibilité prévue et un statut “indisponible avant cette date”.
• Mentions dans les CGU Agent : les CGU signées par les Participants doivent préciser :
  • Que la date de déblocage correspond à la date contractuelle à laquelle les fonds deviennent utilisables.
  • Qu’il est impossible pour le Participant d’utiliser ces fonds avant cette date.
  • Que CentralPay peut refuser, différer, suspendre ou encadrer la mise à disposition au regard de ses obligations réglementaires, de sa politique de risque et des règles des réseaux de paiement.
• Gestion des exceptions : en cas d’annulation, de remboursement, d’impayé ou de litige :
  • Si la transaction source est annulée/remboursée, les fonds ne seront pas mis à disposition.
  • En cas d’impayé (ex. chargeback carte) ou de risque, CentralPay peut retenir/ajuster les montants en attente ou compenser lors de règlements ultérieurs.
  • La date de déblocage peut être reportée (litige/incident) ; le Participant doit être informé via son interface/notifications.

Ce mécanisme ne constitue ni un séquestre au sens du droit civil, ni un service de conservation fiduciaire : il s’agit d’une mise à disposition différée sous contrôle exclusif de CentralPay.

3.5. Gestion des versements sortants

Fonctionnement

CentralPay peut mettre à disposition des Participants (et, selon les habilitations, à l’Agent agissant comme intermédiaire mandaté) différents modes de gestion des versements sortants :

• Versements sortants automatisés (paramétrage de règles/plannings, lorsque prévu contractuellement)
• Versements sortants ponctuels (demande via portail/API selon les droits accordés)

Conditions de conformité

Lorsque l’Agent est autorisé à transmettre des demandes de versement sortant pour le compte de ses Participants, il doit recueillir leur consentement et décrire clairement le mode de fonctionnement dans les CGU Agent. CentralPay demeure seule responsable de l’exécution et peut refuser, suspendre ou encadrer ces demandes conformément à ses obligations.

À retenir

Le dispositif présenté garantit :
- La séparation stricte des flux tiers / commissions / compte propre
- L’absence de droit de disposition de l’Agent sur les fonds de tiers
- La traçabilité complète des opérations (auditabilité)
- La supervision active par CentralPay
- La conformité aux exigences du CMF et aux attentes de supervision

Le respect de ce dispositif est obligatoire. Toute anomalie (fraude, incident, incohérence de ventilation, non-respect des procédures) doit être signalée immédiatement à votre Account Manager CentralPay.

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

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

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

1. Responsabilité du mandataire DME

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

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

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

Un statut de Distributeur de Monnaie Électronique passe par :

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

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

2. Devenir mandataire DME

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

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

2.1. Résumé des étapes

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

2.2. Pièces à fournir à CentralPay

Prochainement

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)
• Versement sortant (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 profil 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 des transactions. Elle 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 versements sortants sont des virements émis depuis votre compte de paiement CentralPay vers le compte bancaire associé.

Ils peuvent être réalisés manuellement depuis le Portail Marchand ou via l’API Payment, ou encore être automatisés selon la fréquence définie dans vos paramètres de reversement.

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

1. Modes de versement

1.1. Versement automatique

Le titulaire du compte peut définir la périodicité du versement automatique selon trois options :

• Quotidienne
• Hebdomadaire : choix du jour de la semaine (ex. chaque mardi)
• Mensuelle : choix du jour du mois (ex. le 5 du mois)

Le service de versement automatique exécute chaque virement à 01h00 du jour sélectionné, à partir des fonds disponibles (AVAILABLE) sur le compte de paiement.

Cas d’un versement hebdomadaire programmé le mardi :
CentralPay exécutera la création du virement le mardi matin avec les fonds disponibles sur le compte de paiement jusqu’à 01h00.

ℹ️ En cas de versement quotidien, l’intégralité des fonds disponibles est virée chaque jour vers votre compte bancaire. 
Le solde de votre compte CentralPay est donc nul en début de journée.
Si vous devez effectuer des remboursements clients, ceux-ci pourront être réalisés à partir du début d’après-midi (vers 14h), une fois les fonds des transactions du jour crédités par les banques émettrices. 
Une évolution permettra prochainement de différer les versements automatiques d’un ou plusieurs jours afin de conserver des fonds disponibles tout en maintenant une lecture comptable cohérente. Contactez le support si vous êtes concernés.

Lettrage des versements automatiques

Chaque versement automatique est associé à la liste détaillée des opérations incluses dans le virement. Cette fonction permet un rapprochement automatique entre les opérations encaissées et le versement correspondant.

Le détail des opérations d’un versement est accessible depuis le Portail Marchand Administration Mon compte Versements en sélectionnant le versement souhaité.

Le premier versement automatique ne contient pas encore de détail, car il initialise le système de lettrage. Les versements suivants incluent la liste complète des opérations concernées.

1.2. Versement manuel (via Portail Marchand ou API)

Un versement peut être exécuté manuellement depuis le Portail Marchand ou via l’API Payment. Le montant du versement peut être librement défini, dans la limite des fonds disponibles sur le compte.

Les ordres de versement effectués avant 05h00 sont exécutés immédiatement. Ceux créés après 05h00 sont exécutés le lendemain à 05h00.

2. Identification des opérations liées à chaque versement

Le lettrage des versements est une fonctionnalité du Portail Marchand qui associe chaque versement automatique à la liste détaillée des opérations incluses dans ce versement.

Périmètre : le lettrage s’applique exclusivement aux versements automatiques. Les versements manuels ne disposent pas de cette association automatique.

Contenu du détail : liste des opérations correspondant au versement, incluant les montants, dates de valeur et références nécessaires au rapprochement comptable.

2.1. Accéder au détail d’un versement automatique

Depuis le Portail Marchand Administration Mon compte Versements :

• Sélectionnez le versement concerné dans la liste.
• Ouvrez le détail du versement pour afficher les opérations associées.
• Utilisez le bouton Exporter pour télécharger les données si nécessaire.

Ou, depuis le Portail Marchand Compte Mes opérations :

• Filtrez par Type = Versement sortant ou par Date de valeur.
• Dans la colonne Actions du versement, cliquez sur la flèche, puis sur Voir les opérations du versement.

ℹ️ Le premier versement automatique ne comporte pas de détail : il sert d’initialisation du lettrage.
Les versements automatiques suivants incluent la liste complète des opérations associées.

2. Disponibilité des fonds

Les versements comprennent uniquement les fonds disponibles (AVAILABLE) sur le compte de paiement. Les fonds issus d’une transaction par carte bancaire deviennent disponibles à J+2.

Exemple :
Une transaction carte réalisée le lundi apparaît en « Pending » le lundi, devient « Available » le mardi soir, le versement automatique est exécuté le mercredi à 01h00, et le virement SEPA est crédité sur le compte bancaire le jeudi.

ℹ️ Le paramètre EscrowDate peut influer sur la date de disponibilité des fonds d’une transaction (cas spécifique aux partenaires / mandataires).

3. Création d’un versement manuel

3.1. Depuis le Portail Marchand

Seuls les utilisateurs titulaires du compte (« Legal ») ou disposant d’un rôle administrateur (« Natural Admin ») peuvent créer un versement manuel depuis le Portail Marchand.

Depuis le Portail Marchand Administration Mon compte Versements :

• Cliquez sur Transferts externes.
• Sélectionnez le compte d’émission.
• Indiquez le montant du versement et l’IBAN destinataire.
• Cliquez sur Confirmer le transfert.

Une fois validé, le versement est exécuté selon les délais mentionnés ci-dessus.

3.2. Depuis l’API

La création d’un versement manuel peut également être réalisée via l’API Payment. Pour les détails techniques, consultez la documentation développeur : Développeurs Versement sortant .

4. Versements en devises via le réseau SWIFT

Les virements internationaux sont exécutés via le réseau SWIFT, contrairement aux virements SEPA utilisés dans la zone européenne. Ce service permet d’émettre des versements en euros ou dans d’autres devises vers des comptes situés hors zone SEPA.

Si le compte bénéficiaire n’est pas accessible via SEPA ou s’il s’agit d’un compte en devise, les versements peuvent être réalisés via SWIFT. Ce service est activé sur demande auprès de votre interlocuteur CentralPay.

ℹ️ Les virements SWIFT présentent des frais supérieurs aux virements SEPA. Il est possible de paramétrer un seuil de fonds disponibles avant déclenchement automatique des versements.

5. Retours, statuts et webhooks

Pour suivre le cycle de vie des versements et automatiser leur traitement :

• Consulter la documentation des statuts de versement ➝
• Consulter la documentation des webhooks de versement ➝

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 Fichiers d’export .

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 relevé de compte est généré, puis mis à disposition dans l’espace sécurisé de votre compte ( Mes comptes Relevés de compte ). Il présente les montants totaux de crédit et de débit réalisés, incluant un détail « dont fonds » et « dont frais » afin de distinguer la nature.

Nous vous proposons deux types de relevés : détaillé ou synthétique. 
- Le relevé détaillé fait apparaitre l'ensemble des opérations de la période sélectionnée.
⚠️ Si vous possédez un grand nombre d'opérations, il est possible que celles-ci n'apparaissent pas sur le relevé. Dans ce cas, nous vous conseillons de réaliser un export au format CSV, Excel ou JSON.
- Le relevé synthétique regroupe vos opérations par jour et par type d'opération, pour la période sélectionnée.

Pour bien comprendre votre relevé de compte détaillé : A) Le total du montant des débits sur votre compte pour la période donnée : – dont fonds : ensemble des débits de nature « fond » (versements sortants, etc.) – dont frais : ensemble des débits de nature « frais » (frais CentralPay, etc.) B) Le total du montant des crédits sur votre compte pour la période donnée : – dont fonds : ensemble des encaissements sur votre compte (= chiffre d’affaires). – dont frais : ensemble des opérations pour compenser des opérations ou ajuster des frais (remboursement de frais, etc.). C) Solde de clôture du mois précédent le relevé. D) Solde de clôture du mois du relevé téléchargé.

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 profil 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’un évènement intervient sur votre profil 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

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 ➝

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 marchand participant d’un mandataire, ou un marchand standard 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, versements, droits utilisateurs…).

1.5. Création du profil Marchand CentralPay

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

• 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 profil, 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 profil est débloqué
• Vous pouvez encaisser vos premières transactions

2. 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 profil Marchand CentralPay.

2.1. Étape unique : Création du profil 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 profil.

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 profil 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 profil 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 profil 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 de réserve CentralPay afin de permettre de couvrir les R-transactions (rejets, refus, retours, remboursements, contestations, impayés) lorsque votre compte de paiement n’est pas solvable. 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 Versements 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 compte doit donc dépasser la valeur du pied de compte pour autoriser les versements sortants (payout).

Le détail du pied de compte est visible depuis le Portail Marchand : Administration Versements 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 sur votre compte de réserve 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 si votre compte de paiement n’est pas solvable. 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 Versements 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. 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 profil marchand 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>