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. Voir le certificat de CentralPay ➜
	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 offers modular payment solutions that enable the consolidation of payment collection processes for its own account and the automation of payouts on behalf of third-party accounts. The types of services and transactions offered by CentralPay vary depending on the needs and business activities of its merchants and partners.

CentralPay is an independent company that fully owns its technology and licenses. This ensures the greatest possible autonomy in its choice of partnerships and its future development.

CentralPay is authorized to enter into business relationships with companies registered in the European Economic Area.

ACPR ( ) (Bank of France)	Electronic money institution: CentralPay is an electronic money institution regulated by the Banque de France through its prudential supervision and resolution authority, the ACPR (CIB 17138).
	PSD2: CentralPay complies with the Second Payment Services Directive, which sets forth requirements regarding strong customer authentication and data protection, among other things.
	PCI DSS: CentralPay is certified annually at the highest possible level for banking data security and fraud prevention: PCI DSS Level 1. View CentralPay’s certificate ➜
	EBA CLEARING & EPC: As a member of the European Payment Council and through its connection to EBA CLEARING, CentralPay provides Integration of the European SEPA payment schemes to send and receive Bank transfers and SEPA Direct Debits using its own IBANs and virtual IBANs.
	SWIFT: Connected to the SWIFT network, the most widely accepted messaging system worldwide, CentralPay is able to exchange international financial transactions with most participating banks and financial institutions.
	Visa, Mastercard, debit cards, American Express: CentralPay is accredited by the major card networks to optimize the payment experience and conversion rates for all its users.

1. Entrée en relation

Pour commencer, découvrez nos offres et choisissez la méthode d’entrée en relation la plus adaptée à votre projet :

2. Création de votre profil marchand de test

CentralPay met à votre disposition un environnement de test (RCT) pour développer et valider votre intégration :

• Profil de test « Marchand standard«  : Pour tester uniquement la solution d’encaissement Smart Collection, demandez un profil marchand de test via notre formulaire
• Profil de test « Marchand partenaire ou mandataire » : Pour tester l’encaissement (Smart Collection) et les transferts de paiements (Easy Wallet), contactez notre service client. Nous créerons et paramétrerons votre profil marchand de test en conséquence

3. Choix de votre méthode d’intégration

Choisissez la méthode d’intégration qui correspond à vos besoins :

• Intégration Smart : Utilisez les demandes de paiement et la page de paiement CentralPay pour encaisser vos transactions. Les parcours clients sont préconfigurés, pour un déploiement rapide
• Intégration Custom : Intégrez directement les services API pour les transactions par carte, par virement SEPA (SCT) et/ou par prélèvement SEPA (SDD). Cette approche vous permet de maîtriser entièrement l’expérience client, mais requiert un développement plus avancé

4. Paramétrage de votre profil marchand

Votre profil Marchand CentralPay peut être configuré de manière autonome ou avec l’accompagnement de notre équipe support.

ℹ️ Les paramétrages réalisés sur votre profil marchand de test (RCT) ne sont pas automatiquement répliqués en production (PROD). Veillez à les reconfigurer une fois votre profil de production activé.

Paramétrages principaux :

Paramétrages secondaires :

5. Simuler des paiements

Avant la mise en production, effectuez des simulations de paiement client dans votre profil de test (RCT) pour vérifier l’intégration :

• Carte : Utilisez nos cartes de test pour simuler différents statuts de transaction
• Virement SEPA (SCT) : Créez une ou plusieurs transactions SCT puis demandez à notre support de simuler leur traitement
• Prélèvement SEPA (SDD) : Utilisez un IBAN/BIC de test fourni dans notre documentation

6. Mise en production

Une fois vos tests validés en environnement de recette (RCT), préparez le passage en production (PRD).

ℹ️ Rappel : Aucun paramétrage n'est automatiquement copié de la RCT vers la PROD.

• Récupérer les credentials API pour l’environnement PROD
• Vérifier l’URL API de production
• Récupérer la merchantPublicKey pour générer des cardToken
• Informer CentralPay de toute mise en production ou évolution majeure
• Déclarer l’URL de votre site dans la configuration de votre point de vente
• Vérifier l’accès à la page support depuis le Portail Marchand

Si nécessaire, vous pouvez effectuer une à deux transactions réelles à 1 € pour vérifier le bon fonctionnement du paiement en production.

1. Establishing a relationship

To get started, explore our offerings and choose the best way to get in touch based on your project:

2. Creating your test merchant profile

CentralPay provides you with a test environment (RCT) to develop and validate your integration:

• “Standard Merchant” test profile: To test only the Smart Collection payment solution, request a test merchant profile using our form
• “Partner Merchant or Agent” test profile: To test payment collection (Smart Collection) and payment transfers (Easy Wallet), please contact our customer service team. We will create and configure your test merchant profile accordingly.

3. Choosing your integration method

Choose the integration method that best suits your needs:

• Smart Integration: Use payment requests and the CentralPay payment page to process your transactions. Customer flows are preconfigured for rapid deployment
• Custom Integration: Directly integrate API services for card transactions, SEPA credit transfers (SCT), and/or SEPA direct debits (SDD). This approach gives you full control over the customer experience, but requires more advanced development.

4. Setting up your merchant profile

You can set up your CentralPay merchant profile on your own or with assistance from our support team.

ℹ️ The settings configured in your test merchant profile (RCT) are not automatically replicated in production (PROD). Be sure to reconfigure them once your production profile is activated. 

Main settings:

Secondary settings:

5. Simulate payments

Before going live, run customer payment simulations in your test profile (RCT) to verify the integration:

• Card: Use our test cards to simulate different transaction statuses
• SEPA Credit Transfer (SCT): Create one or more SCT transactions, then ask our support team to simulate their processing
• SEPA Direct Debit (SDD): Use a test IBAN/BIC provided in our documentation

6. Deployment

Once your tests have been validated in the acceptance testing environment (RCT), prepare for the transition to production (PRD).

ℹ️ Reminder: No settings are automatically copied from the RCT to the PROD environment.

• Retrieve the API credentials for the PROD environment
• Verify the production API URL
• Retrieve the merchantPublicKey to generate cardToken
• Notify CentralPay of any production deployment or major change
• Enter your website’s URL in your point-of-sale settings
• Check access to the support page from the Merchant Portal

If necessary, you can make one or two live transactions for €1 to verify that the payment system is working properly in production.

Find below the list of HTTP return codes:

(*) Only possible for the creation of a transaction

Find below the list of HTTP return codes:

(*) Only possible for the creation of a transaction

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 :

The Merchant Profile represents a Merchant technically and operationally within the CentralPay platform.

It serves as the foundation for:
• Its accounts: payment or electronic money accounts;
• Its administration: API access, user profiles, available payment services;
• Its technical configuration: webhooks, notifications, points of sale, acceptance rules, bank accounts;
• Its regulatory file: KYC/KYB, AML-CFT, risk scoring, contracting, pricing schedule…

The Merchant Profile corresponds to the API object Merchant and is created automatically after validation of its registration (via the API object Merchant-Enrollment).

1. Profile Types by Contractual Model

Each Merchant type is associated with a specific contractual model.

Standard Type : STANDARD

The standard Merchant is a business or professional that collects payments for its own account. It has one or more payment accounts and can access CentralPay services via API or through a partner.

👉 Learn more about the Merchant model

Integration Partner Type : INTEGRATOR

The Integration Partner supports multiple standard Merchants in their technical integration with CentralPay. Each standard Merchant has its own point of sale and an individual contract. The Integrator uses the API access provided by each Merchant within the framework of a contractual relationship.

• May have a payment account and a commission account for its own needs
• A separate point of sale is created for each supported Merchant
• May perform API calls and technical actions via access delegated by the Merchant (monitoring Technical Instructions, configuration, RUN), without access to balances or authority to initiate/modify/execute a payment operation in its own name
• CentralPay invoices each Merchant directly

👉 Learn more about the Integrator Partner model

MOBSP Integration Partner Type : INTEGRATOR + MOBSP

The MOBSP Integration Partner is an Integrator with a regulatory mandate. It can initiate a relationship request on behalf of a standard Merchant and provide technical support via the onboarding API. Like any Integrator, it acts solely through the API access provided by the Merchant.

• Same rights and operation as an Integrator
• May initiate a complete enrollment request via API
• May support the merchant during enrollment

👉 Learn more about the MOBSP Integrator Partner model

Technical Partner Type : TECHNIQUE

The Technical Partner develops a shared solution (e.g., marketplace, SaaS platform) and operates from one or more points of sale opened in its name, to which standard Merchants can be attached. It uses its own API access to transmit commercial data and monitor operations linked to these points of sale, without ever having execution authority over payment operations.

• One or more points of sale may be used to consolidate merchant activities (e.g., marketplace, SaaS platform)
• CentralPay API access specific to the Technical Partner
• CentralPay invoices the Technical Partner
• Cannot initiate enrollment on behalf of and for the account of merchants (unless MOBSP framework applies)

👉 Learn more about the Technical Partner model

MOBSP Technical Partner Type : TECHNIQUE + MOBSP

The MOBSP Technical Partner is authorized to initiate a relationship request on behalf of its users. It can transmit the necessary information via the onboarding API but does not intervene in the execution of payment operations.

• Same rights and operation as a Technical Partner
• May initiate a complete enrollment request via API
• May support the merchant during enrollment

👉 Learn more about the MOBSP Technical Partner model

EMD Agent Type : DME

The EMD Agent (Electronic Money Distributor) transmits loading, transfer, or refund instructions in electronic money on behalf of Participants. It operates within the electronic money model (CUSTOM currencies) and may receive a commission on operations, without providing regulated payment services (e.g., SEPA transfer, direct debit, card).

👉 Learn more about the EMD Agent model

PSP Agent Type : AGENT

The PSP Agent is a Payment Service Provider (PSP) Agent registered with ACPR. It acts on behalf of and for the account of CentralPay within a strictly defined contractual scope. Depending on the model adopted (Simple Agent / Collecting Agent / Delegated Agent), it may support enrollment, perform certain level 1 KYC/KYB due diligence, and/or intervene in the collection, allocation, and provision of funds via mechanisms provided by CentralPay. CentralPay remains responsible for the payment services provided and regulatory controls.

👉 Learn more about the PSP Agent model

Participant Type : BASIC

The Participants are natural or legal persons who are clients of a CentralPay Intermediary Merchant (Agent or EMD). They have one or more payment accounts or electronic money accounts to receive funds issued by the Intermediary and can access the Merchant Portal to view their operations and manage their outgoing transfers.

They operate to sell products or services, for LMNP activity, or for non-commercial needs (crowdfunding, personal wallet, collective projects, etc.).

Participants open accounts with CentralPay. The relationship may be initiated and/or supported by the Intermediary Merchant, but regulated services remain provided by CentralPay. The framework for account usage is defined by the applicable CentralPay documents (and, where applicable, by the Intermediary’s Terms of Use for commercial conditions and the services it provides).

2. Contact Email Configuration

You can customize the contact email addresses associated with your merchant profile so that notifications, reminders, or contractual communications are properly addressed to the right contacts.

• Contact email: primary contact for the merchant profile
• Administrative email: responsible for legal or contractual matters
• Technical email: responsible for integration or incidents
• Financial email: responsible for billing or banking flows

ℹ️ By default, these addresses are initialized with the email of the merchant profile holder. They can be modified at any time from the Merchant Portal. 

Access to contact email configuration:

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

Notifications can be sent based on events related to certain API objects:

• Payment request (paymentRequest)
• Chargeback (dispute)
• Installment payment (installment)
• Card Transaction (transaction)
• Payout (payout)
• Card Refund (refund)
• Subscription (subscription)
• Card credit (credit)
• SDD Transaction (sddTransaction)
• Reversed SDD Transaction (sddTransactionReversal)
• Mandate (mandate)

1. Notification scenario types

Automatically notify your customers and alert your colleagues when certain events occur on your CentralPay Merchant profile: receipt of a transfer, customer dispute, payment failure, etc.

You control the content of each notification using custom templates and define a delivery method by email, by SMS, or by JSON. This automates the reconciliation of your collections, customer notifications, and even updates to your information system.

2. Configuring notification templates

2.1. Template configuration

To start configuring your notifications, you must create your communication templates (email, SMS, or hook) by filling in the requested elements, such as the email subject, the sender name and email address, the message body, etc.

You can insert dynamic elements (tags) into the message body by typing the « # » character, which will display the list of tags available for the selected notification scenario type.

Please note: if you use email notifications, please ask us to provide our SPF and DKIM keys so that you can authorize CentralPay to send emails from your domain.

For SMS, please calculate the number of characters: you will be billed for one SMS per 160 characters (including spaces).

Access to email template settings:

Access to SMS template settings:

Access to hook template settings:

2.2. Configuring the header and footer for email templates

When creating an email template, a « header » and a « footer » must be created. For example, you can add your logo in the header and your contact details or legal notices in the footer.

Access to email header settings:

Access to email footer settings:

3. Configuring notification scenarios

To specify to the platform the sending conditions and recipients for your notifications, you must create a scenario that includes one or more sending rules.

After choosing the desired scenario type, you can create a sending rule. This rule is split into two parts: « WHEN » defines the event that triggers the notification, while « THEN » lets you choose the actions that will be performed when the event occurs.

Access to notification scenario settings:

3.1. In the « WHEN » section:

• Type « # » to view all attributes available for your scenario
• Use logical operators to build your rule:
  • For strings (must be enclosed in quotation marks «  »):
    • = (equals)
    • != (not equal to)
    • in (in the following)
    • not in (not in the following)
  • For numbers (note: amounts must be entered in cents):
    • = (equals)
    • != (not equal to)
    • < (less than)
    • <= (less than or equal to)
    • in (in the following)
    • not in (not in the following)
  • For booleans (true/false statements):
    • = (equals)
    • != (not equal to)
• You can use conditions to complete your rule:
  • AND (to add another activation condition)
  • OR (to add another activation possibility)

It is possible to set priorities by placing parentheses around conditions. If you use AND and OR in the same rule, you must set priorities. If you use AND multiple times or OR multiple times, you must also prioritize each part.

Rule examples:

#end_user_country in ('FRA', 'BE')

#authorisation_status = 'FAILURE' or (#transaction_amount > 100000 and #context = 'TRANSACTION_RISKY' )

#transaction_amount > 100000 and ( #authorisation_status = 'FAILURE' or #context = 'TRANSACTION_RISKY' )

((#transaction_amount > 100000 and #context = 'TRANSACTION_RISKY') or ( #authorisation_status = 'FAILURE' and #transaction_amount < 100000 )) and (#card_product_type = 'Consumer')

Before you can save a rule, you must first test it using the « test » button. This verifies that your rule is grammatically correct. Please note: this does not guarantee that your rule matches what you intended to do.

3.2. In the « THEN » section:

« THEN » lets you choose the recipient and the template used for the notification. You only have access to templates that match the required template type (SMS, Email, Hook) and that match the selected scenario type (card transaction, payment request, refund, etc.).

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

1. The two Smart Collection integration modes

The Smart Collection solution allows you to collect payments from various payment methods.

You can choose to:

• Create and integrate your own payment flows (CUSTOM integration), by consuming the API services of each payment method:
  • Card transaction ➝
  • Transfer transaction ➝
  • SEPA direct debit transaction ➝
    
    
• Use our secure payment request flows (SMART integration), via our dedicated service:
  • Payment requests (PaymentRequest) ➝
  • The EscrowDate parameter can affect the funds availability date of a transaction (applies to AGENT partners only)

ℹ️ If you choose SMART integration, specific features such as R-transactions, bank descriptor management, Virtual IBAN management, etc., are presented in the documentation under the CUSTOM sections dedicated to each payment method.

2. About SMART integration

The payment request allows you to generate a payment link leading to a payment page hosted by CentralPay. Your customer can thus pay you according to the payment terms you have determined (authorized payment methods and modes, payment deadlines, etc.). Transactions created in this way are automatically linked to the payment request and allow its status to be updated (unpaid, partially paid, paid, etc.).

The payment request must be populated with the payment terms of your cart or invoice:

• Amount to be paid
• Accepted payment methods (card, transfer, direct debit, payment initiation)
• Accepted payment modes (one-off, subscription, installment payment…)
• Order reference
• Order description
• Customer details
• Authorized payment deadline
• Link expiration time
• …

The payment link can be sent to your customers from:

• Your sales funnels or web interfaces
• Your communication tools (email, SMS, mail via QR code…)
• The CentralPay email / SMS notification service

The payment page then allows the customer to carry out their transaction(s):

• Viewing payment request information
• Selection of payment method or mode
• Entering customer data
• Entering payment details

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

1. Operation

A card transaction comprises a sequence of actions:

1.1. 3DS 2.0 Authentication

This ensures that the person making the transaction is indeed the cardholder. The customer’s bank analyzes numerous payment-related factors provided by CentralPay (IP address, location, device used, etc.) and compares them to its customer’s usual data:

• If the data does not match or the transaction amount is significant, it requires manual identification via a code sent by SMS or through its banking application (« strong authentication » or « SCA »)
• Otherwise, it directly authorizes the payment (« Frictionless »)

1.2. Bank Authorization

A request made by CentralPay to the payer’s bank to verify the validity and funds availability of their card. The « authorized » funds are blocked until the funds are captured. If no capture is performed within 7 days, the « authorized » funds are released, and the merchant will need to renew their authorization.

For eligible activities (rental, hospitality, etc.), the « pre-authorization » service allows the merchant to extend the authorization period up to 30 days.

1.3. Capture

Capture initiates the debit of the card based on an authorization or pre-authorization. A merchant can perform a full or partial capture of the authorized amount.

2. Accepted Card Types and Networks

Payment cards are issued by banks or approved payment institutions; they can be branded by one or more card networks (also called « Card Scheme »).

The networks accepted by CentralPay are:

• Debit Card
• VISA
• MasterCard
• American Express

In France, the majority of cards issued are co-branded CB and VISA or CB and Mastercard. In this case, the customer must have the option to choose the network they wish to use.

Cards can be debit or deferred debit / credit (in France, the majority of cards are debit), and can be for individuals (referred to as « Consumer ») or for professionals (referred to as « Corporate »).

Note that these parameters impact the transaction cost for the merchant (interchange fees and card network fees).

1. Fonctionnement

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

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

Quelques informations importantes :

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

2. Types de réseaux acceptés

Il existe deux types de virements bancaires :

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

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

CentralPay est atteignable par toutes les banques de l’Espace Économique Européen utilisant les réseaux SEPA (via STEP2 pour les SCT/SDD, ainsi que TIPS et RT1 pour les « Instant SCT »). Seuls les virements de réseaux internationaux ou en devises hors EUROS ne sont pas recevables pour le moment (via réseau SWIFT par exemple).

1. Operation

Bank transfers are the most common method of payment for business transactions. They involve the direct transfer of funds from one account (bank or payment account) to another, without using any additional medium, such as a card.

The individual or legal entity requesting the transfer is called the payer (or sender), and the one receiving the money is the payee. Unlike a card payment or a SEPA direct debit, only the sender themselves can initiate a wire transfer. To do so, they log in to their bank’s online banking portal, enter the beneficiary’s bank details (IBAN + BIC + account holder’s name), and then specify an amount and a transfer reference.

Some important information:

• The processing time for a standard transfer with CentralPay is 4 to 24 business hours (compared to 24 to 48 business hours at most traditional banks). Starting in October 2024, it will also be possible to receive instant transfers (processed in <5 seconds).
• The transfer does not pose a significant financial risk to the receiving merchant, since the sender undergoes strong authentication with their bank and therefore cannot dispute the transaction
• Issuing banks set a settlement limit for wire transfers that is significantly higher than the limit applied to SEPA direct debit transactions or card payments
• Depending on the features offered by their bank, the sender can set up a recurring transfer or a deferred transfer

2. Accepted Network Types

There are two types of bank transfers:

• SEPA transfers (or SEPA Credit Transfers): Used for transactions in euros between two member countries of the SEPA area (= 27 European Union countries + the United Kingdom, Monaco, Andorra, the Vatican, Switzerland, Liechtenstein, Norway, Iceland, and San Marino)
• International wire transfers: Used for international transactions in euros or other currencies via the SWIFT network

The fees for SEPA networks are very favorable (just a few tenths of a cent, compared to several tens of euros for SWIFT). SWIFT, however, offers several options for paying these fees: they can be borne by the sender, the recipient, or shared between the two.

CentralPay is accessible to all banks in the European Economic Area that use the SEPA networks (via STEP2 for SCT/SDD, as well as TIPS and RT1 for “Instant SCT”). Only transfers made through international networks or in currencies other than the euro are not currently accepted (via the SWIFT network, for example).

Le prélèvement SEPA (SEPA Direct Debit ou « SDD » en anglais) permet à un créancier (marchand) de prélever un montant dû directement sur le compte de son débiteur (client). Il est principalement destiné aux règlements récurrents (abonnements ou paiements en plusieurs fois) mais peut-être dans certains cas utilisé pour des règlements ponctuels (par exemple pour le règlement de factures entre professionnels).

Étant émis à l’initiative du créancier, il requiert la collecte préalable d’une autorisation de son débiteur. Le marchand édite ainsi un « Mandat SEPA » précisant les conditions de prélèvement et les coordonnées bancaires des deux parties que son débiteur devra signer.

1. Les deux types de prélèvement SEPA

Il existe deux types de prélèvements SEPA :

• Le prélèvement SEPA « CORE » : le plus répandu, il permet aux créanciers de débiter des comptes de particuliers comme de personnes morales. Le mandat SEPA est édité et signé entre les deux parties sans contraintes particulières. Le débiteur est cependant protégé et peut contester un prélèvement CORE sans motifs auprès de sa banque sous 8 semaines
• Le prélèvement SEPA « B2B » : réservé aux prélèvements entre entreprises. Le mandat SEPA est édité, signé puis doit être transmis par le débiteur à sa banque. Le parcours de contractualisation requiert ainsi une action forte du débiteur et la validation de sa banque. Cependant, les prélèvements initiés depuis ce type de mandats ne sont pas contestables.
  CentralPay ne propose pas ce service de prélèvement SEPA type « B2B »

2. Risques de rejet et de contestation

Le prélèvement SEPA étant un moyen de paiement dont les transactions sont initiées sans authentification forte du client, les risques de rejets et de contestations sont à prendre en considération.

👉 Consultez la rubrique « R-Transaction SDD » pour en savoir plus sur les rejets et contestations SDD

3. Informations importantes

• Le prélèvement SEPA est utilisable sur la vaste majorité des comptes bancaires « courants » des pays de la zone SEPA et certains de l’Espace Économique Européen hors SEPA. Cela dépend de la connectivité aux réseaux SEPA des banques des débiteurs. Les comptes spéciaux type « comptes épargnes » ne sont pas atteignables
• Les opérations SEPA sont traitées en devise EUROS (€) uniquement
• Les opérations SEPA sont traitées lors des jours ouvrés uniquement (hors weekend et jours fériés). Ainsi, le délai de réception des fonds varie entre 2 à 5 jours à compter de la date d’initiation de l’opération
• Le débiteur doit être informé par le créancier des prélèvements à venir, au moins 14 jours avant la date, soit par l’envoi d’un échéancier, d’une notification ou d’une facture
• La durée de validité d’un mandat SEPA est de 36 mois après la dernière transaction opérée sur ce mandat
• Dans le cadre d’un prélèvement SEPA sur le compte bancaire d’une entreprise (personne morale), le créancier doit veiller à ce que le mandat SEPA soit adressé et signé par le dirigeant ou un responsable habilité (gérant, service comptabilité…)
• Le prélèvement SEPA est particulièrement adapté aux transactions récurrentes d’un montant situé entre 20 et 200 EUR pour les débiteurs particuliers, et entre 20 et 2 000 EUR pour les débiteurs personnes morales

The SEPA Direct Debit (or “SDD”) allows a creditor (merchant) to collect an amount owed directly from the debtor’s (customer’s) account. It is primarily intended for recurring payments (subscriptions or installment payments) but may, in certain cases, be used for one-time payments (for example, to settle invoices between businesses).

Since it is issued at the creditor’s initiative, it requires prior authorization from the debtor. The merchant therefore prepares a “SEPA Direct Debit Mandate” specifying the terms of the direct debit and the bank details of both parties, which the debtor must sign.

1. The two types of SEPA direct debits

There are two types of SEPA direct debits:

• The SEPA “CORE” direct debit: the most widely used type, it allows creditors to debit the accounts of both individuals and legal entities. The SEPA direct debit mandate is drawn up and signed by both parties without any specific restrictions. However, the debtor is protected and may dispute a CORE direct debit with their bank within 8 weeks without providing a reason.
• The SEPA “B2B” direct debit: reserved for direct debits between businesses. The SEPA direct debit mandate is printed, signed, and then must be submitted by the debtor to their bank. The onboarding process thus requires significant action on the part of the debtor and validation by their bank. However, direct debits initiated using this type of mandate cannot be disputed.
  CentralPay does not offer this “B2B” SEPA direct debit service

2. Risks of rejections and contests

Since the SEPA Direct Debit is a payment method in which transactions are initiated without strong customer authentication, the risks of rejections and disputes must be taken into account.

👉 See the “R-Transaction SDD” section to learn more about SDD rejections and disputes

3. Important information

• The SEPA Direct Debit can be used with the vast majority of “checking” accounts in SEPA countries and some in the European Economic Area outside the SEPA zone. This depends on the connectivity of the payees’ banks to the SEPA networks. Special accounts, such as “savings accounts,” are not accessible.
• SEPA transactions are processed in euros (€) only
• SEPA transactions are processed on business days only (excluding weekends and holidays). As a result, the time it takes for funds to be received ranges from 2 to 5 days from the date the transaction is initiated.
• The creditor must notify the debtor of upcoming debits at least 14 days in advance, either by sending a payment schedule, a notice, or an invoice
• A SEPA direct debit mandate is valid for 36 months after the last transaction processed under that mandate
• In the case of a SEPA direct debit from a business’s (legal entity’s) bank account, the creditor must ensure that the SEPA direct debit mandate is addressed to and signed by the executive or an authorized representative (manager, accounting department, etc.).
• The SEPA Direct Debit is particularly well-suited for recurring transactions ranging from 20 to 200 EUR for individual payers and from 20 to 2,000 EUR for corporate payers

Cette section explique le fonctionnement de la création de comptes CentralPay, qu’il s’agisse de comptes de paiement ou de comptes de monnaie électronique, ainsi que les méthodes disponibles pour initier un enrôlement utilisateur via nos outils (portail ou API), en fonction du modèle de partenariat.

1. Types de comptes

CentralPay permet l’ouverture de deux types de comptes réglementés :

L’attribution du type de compte dépend du modèle économique du marchand et de son éventuelle gestion par un mandataire (DME ou Agent).

2. Fonctionnement global de l’enrôlement

L’ouverture d’un compte passe systématiquement par une procédure d’enrôlement incluant :

1. La création d’une demande d’enrôlement : initiation d’un dossier contenant les premières informations (email, nom, prénom)
2. La complétion de l’enrôlement : soumission par l’utilisateur des informations réglementaires et des justificatifs (KYC/KYB)
3. La validation de l’enrôlement : analyse par CentralPay, pouvant aboutir à une ouverture de compte, une demande complémentaire ou un refus

3. Deux interfaces possibles

4. Conformité et réglementation

Afin de respecter le cadre réglementaire applicable aux Prestataires de Services de Paiement, la répartition des rôles est strictement encadrée :

• CentralPay initie seul la contractualisation avec l’utilisateur
• Le partenaire technique ne peut pas inciter, conseiller ni initier une ouverture de compte
• Le partenaire technique n’intervient pas dans la collecte de justificatifs
• Seuls les partenaires enregistrés comme MOBSP, ou les mandataires Agent ou DME peuvent intervenir dans les étapes d’enrôlement élargies

ℹ️ Le partenaire technique peut créer une demande d'enrôlement contenant uniquement les données de contact (email, nom, prénom, raison sociale), sans envoyer lui-même de lien d'enrôlement. CentralPay reste seul décideur de la suite du processus.

This section explains how to create CentralPay accounts, whether payment accounts or e-money accounts, as well as the methods available for initiating user onboarding through our tools (portal or API), depending on the partnership model.

1. Types of accounts

CentralPay allows users to open two types of regulated accounts:

The assignment of an account type depends on the merchant’s business model and whether the account is managed by an agent (DME or Agent).

2. General enrollment process

Opening an account always involves a registration process that includes:

1. Creating an enrollment request: starting a file containing basic information (email, last name, first name)
2. Completion of the registration process: submission by the user of required information and supporting documents (KYC/KYB)
3. Enrollment validation: review by CentralPay, which may result in account opening, a request for additional information, or a rejection

3. Two possible interfaces

4. Compliance and regulation

In order to comply with the regulatory framework applicable to Payment Service Providers (PSP), the division of roles is strictly regulated:

• CentralPay is the only party that initiates the contract process with the user
• The technical partner may not encourage, advise, or initiate the opening of an account
• The technical partner does not participate in the collection of supporting documents
• Only partners registered as MOBSPs, or Agent or EMD representatives, may participate in the expanded enrollment steps

ℹ️ The technical partner can create an enrollment request containing only contact information (email, last name, first name, company name), without sending an enrollment link themselves. CentralPay retains sole discretion over the rest of the process.

La solution Easy Wallet permet aux plateformes d’encaisser des paiements et de les transférer à des tiers tout en respectant la réglementation européenne.

Pour ce faire, le module comprend deux principaux services :

• L’inscription, permettant la création de comptes de paiement et de monnaie électronique pour les marchands d’une plateforme
• Le transfert, permettant le transfert des transactions vers ces comptes de paiement et de monnaie électronique

Selon le modèle de contractualisation CentralPay, les possibilités d’inscription et de transferts sont différentes.

1. Les types de transferts

Selon le modèle de partenariat établi avec CentralPay, le transfert des paiements est réalisé différemment :

• Partenaires MOBSP : Vous devez utiliser le service de transfert via transaction
• Agents PSP : Vous pouvez utiliser le service de transfert libre ou transfert via transaction
• Distributeurs de ME : Vous devez utiliser le service de transfert via transaction pour la phase d’encaissement en devise. Ensuite, vous pouvez utiliser le service de transfert libre uniquement pour mouvementer la monnaie électronique entre les comptes de vos marchands participants

Pour connaitre votre modèle de partenariat, veuillez vous rapprocher de votre contact CentralPay.

The Easy Wallet solution enables platforms to process payments and transfer them to third parties in compliance with European regulations.

To achieve this, the module includes two main services:

• The registration, which enables the creation of payment and electronic money accounts for merchants on a platform
• The transfer, which enables transactions to be transferred to these payment and electronic money accounts

According to the CentralPay contract model, the options for registration and transfers vary.

1. Types of transfers

According to the partnership model established with CentralPay, payouts are processed differently:

• MOBSP Partners: You must use the transfer service via transaction
• PSP Agents: You can use the free transfer service or transfer via transaction
• EM Distributors: You must use the transfer service via transaction for the foreign currency collection phase. Then, you may use the free transfer service only to transfer electronic money between the accounts of your participating merchants.

To find out what type of partnership you have, please contact your CentralPay representative.

You’ll find below instruction to use our swagger properly

1 – This is where you can choose the server you’ll call for your tests. For now, only RCT (Test Api) is available.
2 – In order to do your tests, you’ll need to authenticate with your credentials. You can use here your RCT (test) Api login and password. You can also use our test login : Doctest:4I9HJRTd
Don’t use your Production login for the tests, you’ll get a 401 error.

3 – This is where you will be able to see the parameters for each endpoint, and do your tests.

4 – Try it out. Use this if you want to be able to test the endpoint. Make sure you’re authenticated before doing so.
5 – This is where you’ll be able to use the test values of your choosing. By default, most values are already filled, but use yours for better results.
6 – Click here once values are filled to call our Api and do your tests.
7 – This is where you’ll see the results once you called our Api. You’ll also find here by default responses example for this endpoint.

You’ll find below instruction to use our swagger properly

1 – This is where you can choose the server you’ll call for your tests. For now, only RCT (Test Api) is available.
2 – In order to do your tests, you’ll need to authenticate with your credentials. You can use here your RCT (test) Api login and password. You can also use our test login : Doctest:4I9HJRTd
Don’t use your Production login for the tests, you’ll get a 401 error.

3 – This is where you will be able to see the parameters for each endpoint, and do your tests.

4 – Try it out. Use this if you want to be able to test the endpoint. Make sure you’re authenticated before doing so.
5 – This is where you’ll be able to use the test values of your choosing. By default, most values are already filled, but use yours for better results.
6 – Click here once values are filled to call our Api and do your tests.
7 – This is where you’ll see the results once you called our Api. You’ll also find here by default responses example for this endpoint.

Le service d’abonnement vous permet se réaliser automatiquement des transactions récurrentes sur vos profils clients en se basant sur un modèle d’abonnement défini en amont depuis l’API CentralPay ou le Portail Marchand. Il est ensuite possible d’ajouter des échéances ou de modifier leur montant à la volée depuis les services Invoice & Invoice Item.

Ce service permet de générer soit des transactions carte, soit des transactions SDD (prélèvement SEPA).

Définitions utiles pour cette section : – SubscriptionModel :  modèle d’abonnement (définissant le montant et la fréquence d’abonnement) – Subscription :  abonnement appliqué à un client – Invoice :  facture, option à utiliser si vous devez modifier la valeur à l’intérieur d’un plan d’abonnement – InvoiceItem :  ligne ou article inclus dans la facture. Une facture a potentiellement plusieurs lignes ou éléments

ℹ️ Le service "Subscription" n'est pas le seul moyen de réaliser des transactions récurrentes. 
Consultez la page Transaction carte récurrente ou la page Transaction par prélèvement pour prendre connaissance du détail par moyen de paiement.

1. Créer un modèle d’abonnement (subscriptionModel)

Accès :

Le subcriptionModel vous permet de pouvoir créer différents types d’abonnements en fonction de vos services proposés. Par exemple, si vous avez à votre disposition deux types d’offre d’abonnement, le premier en utilisant les caractéristiques de base de votre service et l’autre en utilisant les fonctionnalités avancées, vous allez devoir créer deux modèles :

• Un pour l’offre d’abonnement « basique »
• Un pour l’offre d’abonnement « avancé »

Chaque « SubscriptionModel » possède un ID unique. Vous fournirez cet identifiant dans vos requêtes API lorsque vous souhaiterez appliquer un abonnement à un client sur la base de ce modèle.

Vous pouvez utiliser les attributs suivants :

• amount : montant à renseigner en centimes
• intervalUnit : DAY / WEEK / MONTH / YEAR (jour / semaine / mois / année)
• intervalCount : nombre de « intervalUnit » entre deux échéances (ex : si intervalUnit = DAY et intervalCount = 10, alors il y aura une transaction tous les 10 jours)
• iterationCount : nombre d’échéances (attention la première transaction n’est pas comptabilisée dans ce paramètre, elle s’ajoute donc à ce nombre)

Exemple :

• amount = 3000
• intervalUnit = DAY
• intervalCount = 3
• iterationCount = 3

Ainsi votre modèle d’abonnement sera configuré pour facturer à votre client 30,00 EUR tous les 3 jours pendant 4 échéances (pour un total d’un abonnement de 12 Jours).

2. Créer un abonnement (subscription)

Pour créer un abonnement, vous devez d’abord créer un Customer contenant au moins :

• Une Card (si vous souhaitez opérer des transactions carte)
• Ou un Mandate (si vous souhaitez opérer des transactions par prélèvement SEPA)

Vous pouvez ensuite créer une Subscription :

• Selon le moyen de paiement souhaité :
  • pour des transactions carte : renseignez l’identifiant du profil client « customerId »
  • pour des transactions par prélèvement SEPA : renseignez l’identifiant du mandat SEPA « mandateId » et renseignez la date souhaitée de la transaction dans « requestedCollectionDate »
  • pour des transactions entre comptes CentralPay : renseignez l’identifiant du compte émetteur « walletId »
• Renseignez l’identifiant du modèle d’abonnement « subscriptionModelId »
• Renseignez l’IP de votre client dans « endUserIp »
• Renseignez l’identifiant de votre point de vente CentralPay dans « pointOfSaleId »

Notez qu’à la création d’un abonnement, votre client reçoit automatiquement un email contenant le détail de ses échéances. Cet email contient également un lien vers notre Portail client qui lui permet de visualiser le statut de ses paiements récurrent, de changer sa carte bancaire ou son mandat SEPA et de résilier un abonnement si besoin est.

ℹ️ Un client pouvant à tout moment résilier son abonnement depuis le portail client mis à sa disposition. Veillez à vous inscrire aux webhooks d'annulation d'abonnement. Si votre abonnement comprend une période d'engagement, il est préférable d'utiliser la méthode d'abonnement par transactions successives, ou demander à CentralPay de ne pas diffuser le lien vers le portail client.

3. Automatisation des nouvelles tentatives en cas d’échec

En cas d’échec de prélèvement d’une échéance, CentralPay réalise de nouvelles tentatives de prélèvement selon les paramètres définis dans le Portail Marchand.

Accès :

Comportement des champs :

• Heure de transaction : heure à laquelle les échéances de prélèvement seront réalisées par CentralPay
  • Sélection d’une valeur de 4 à 23
• 1er échec de paiement de facture : comportement en cas d’un premier échec de prélèvement
  • Réessayer dans 1, 3, 5 ou 7 jours = nouvelle tentative de prélèvement à J+X après la transaction initiale
  • Stop = le système appliquera directement l’action finale, sans prendre en compte les actions suivantes.
• 2nd échec de paiement de facture : comportement en cas d’un deuxième échec de prélèvement
  • Réessayer dans 1, 3, 5 ou 7 jours = nouvelle tentative de prélèvement à J+X après la précédente tentative
  • Stop = le système appliquera directement l’action finale, sans prendre en compte les actions suivantes.
• 3eme échec de paiement de facture : comportement en cas d’un troisième échec de prélèvement
  • Réessayer dans 1, 3, 5 ou 7 jours = nouvelle tentative de prélèvement à J+X après la précédente tentative
  • Stop = le système appliquera directement l’action finale, sans prendre en compte les actions suivantes.
• Action finale : comportement si les actions précédentes ont échoué
  • CANCELED = Annulation de l’abonnement (modification du statut de l’abonnement en CANCELED)
  • FAILURE = Échec de l’abonnement (modification du statut de l’abonnement en FAILURE)
  • UNPAID = Abonnement impayé (modification du statut de l’abonnement en FAILURE + envoi de hook SUBSCRIPTION_UNPAID)

4. Fonctions d’annulation des abonnements

Il existe deux fonctions d’annulation d’abonnement depuis l’API, le Portail Marchand ou le Portail Client :

• Annuler : l’abonnement est annulé immédiatement
• Annuler en fin de période : l’abonnement sera annulé à la fin de l’échéance en cours (afin de laisser l’abonné bénéficier de votre service durant sa dernière période payée). Par API, vous devrez renseigner le champ « atPeriodEnd ».
  • Note : Durant ce laps de temps, vous pouvez réactiver l’abonnement avec le service « reactivate » des Subscription.

ℹ️ Les abonnements dont l'ensemble des échéances ont été réalisées passent automatiquement en statut CANCELED.

5. Modifier le montant d’une échéance d’abonnement

CentralPay crée un invoice pour chaque échéance d’un abonnement (Subscription), selon le modèle d’abonnement associé (subscriptionModel).

Vous pouvez procéder à des actions manuelles à n’importe quel moment pour modifier les échéances (invoice) d’un abonnement (subscription). Vous trouverez ci-dessous une liste d’actions possibles :

• Modifier le montant d’une échéance : Le service invoiceItem vous permet de modifier le montant d’une échéance (invoice) en renseignant un montant positif ou négatif qui s’additionnera au montant initial de l’échéance. L’invoiceItem sera pris en compte lors de la prochaine échéance de l’abonnement, qu’elle soit créée manuellement ou automatiquement. Vous avez également la possibilité de spécifier une échéance donnée dans votre requête en renseignant un invoiceId.
• Créer une échéance supplémentaire : les échéances (invoice) dites « périodiques » sont créées automatiquement selon votre subscriptionModel. Vous avez la possibilité de créer d’autres échéances ponctuelles sur votre abonnement en créant une invoice.
• Supprimer un invoiceItem non traité : s’il n’est pas encore lié à une facture
• Fermer une échéance à venir : si vous souhaitez que CentralPay ne réalise pas le prélèvement d’une échéance (et/ou ses nouvelles tentatives automatiques), vous pouvez fermer cette dernière depuis le service « close » de l’invoice. Au besoin vous pourrez rouvrir cette échéance via le service « reopen » de l’invoice, si elle n’a pas été payée ou qu’il reste des nouvelles tentatives programmées.
• Forcer le paiement d’une échéance : les transactions sont effectuées automatiquement par le service d’abonnement, vous pouvez cependant initier la transaction en avance ou réaliser une nouvelle tentative manuellement avec le service « pay » de l’invoice. Ces paiements « manuels » ne sont pas comptabilisés par le système de nouvelles tentatives automatisées. Cette action peut être effectuée sur une facture fermée.

6. Schéma complet de création d’un abonnement

The subscription service allows you to automatically process recurring transactions on your customer profiles based on a subscription template defined in advance via the CentralPay API or the Merchant Portal. You can then add due dates or modify the amounts on the fly using the Invoice & Invoice Item services.

This service allows you to generate either card transactions or SDD (SEPA Direct Debit) transactions.

Useful definitions for this section: – SubscriptionModel : subscription template (specifying the subscription amount and frequency) – Subscription : subscription appplied to a customer – Invoice : invoice, use this option if you need to change the amount within a subscription plan – InvoiceItem : line item or item included in the invoice. An invoice may contain multiple line items or items

ℹ️ The "Subscription" service is not the only way to process recurring transaction.
Visit the Recurring card transactions page or the Direct debit transactions page for details by payment method.

1. Create a subscription template (subscriptionModel)

Access:

The subcriptionModel allows you to create different types of subscriptions based on the services you offer. For example, if you have two types of subscription plans available—one that includes the basic features of your service and the other that includes advanced features, you will need to create two models:

• One for the “basic” subscription plan
• One for the “advanced” subscription plan

Each “SubscriptionModel” has a unique ID. You will provide this ID in your API requests when you want to apply a subscription to a customer based on that model.

You can use the following attributes:

• amount : amount to be entered in centimes
• intervalUnit : DAY / WEEK / MONTH / YEAR (day / week / month / year)
• intervalCount : the number of « intervalUnit » units between two due dates (e.g., if intervalUnit = DAY and intervalCount = 10, then there will be a transaction every 10 days)
• iterationCount: number of installments (note that the first transaction is not included in this parameter; it is therefore added to this number)

Example:

• amount = 3000
• intervalUnit = DAY
• intervalCount = 3
• iterationCount = 3

This means your subscription template will be set up to bill your customer 30.00 EUR every 3 days for 4 billing cycles (for a total subscription period of 12 days).

2. Create a subscription (subscription)

To create a subscription, you must first create a Customer that contains at least:

• A Card (if you wish to make card transactions)
• Or a Mandate (if you wish to make card transactions via SEPA direct debit)

You can then create a Subscription:

• Depending on your preferred payment method:
  • for card transactions : enter the customer profile ID « customerId »
  • for transactions via SEPA direct debit : enter the mandate SEPA direct debit ID « mandateId » an enter the desired transaction date in “requestedCollectionDate”
  • for transactions between CentralPay accounts : enter the sender’s account ID “walletId”
• Enter the subscription template ID « subscriptionModelId
• Enter your client’s IP address in “endUserIp”
• Enter your CentralPay point-of-sale ID in the “pointOfSaleId” field

Please note that when a subscription is created, your customer automatically receives an email containing the details of their payment schedule. This email also includes a link to our Customer Portal, where they can view the status of their recurring payments, update their credit card or SEPA direct debit information, and cancel a subscription if necessary.

ℹ️ Customers can cancel their subscription at any time through the customer portal provided to them. Be sure to subscribe to the subscription cancellation webhooks. If your subscription includes a minimum commitment period, it is best to use the recurring payment method or ask CentralPay not to share the link to the customer portal.  

Automating retries in case of failure

If a payment fails to be debited, CentralPay will make additional debit attempts based on the settings defined in the Merchant Portal.

Access:

Field behavior:

• Transaction time: the time at which the direct debit payments will be processed by CentralPay
  • Selection of a value between 4 and 23
• First failed invoice payment: What to do in the event of a first failed direct debit
  • Try again in 1, 3, 5, or 7 days = a new attempt to process the transaction on day+X after the initial transaction
  • Stop = the system will immediately perform the final action, without considering the subsequent actions.
• Second failed invoice payment: What to do in the event of a second failed direct debit
  • Try again in 1, 3, 5 or 7 days = a new attempt to process the transaction on day+X after the previous attempt.
  • Stop = the system will immediately perform the final action, without considering the subsequent actions.
• Third failed invoice payment: What to do in the event of a third failed direct debit
  • Try again in 1, 3, 5 or 7 days = a new attempt to process the transaction on day+X after the previous attempt.
  • Stop = the system will immediately perform the final action, without considering the subsequent actions.
• Final action: What to do if the previous actions failed.
  • CANCELED = Subscription cancelation (changing the subscription status to CANCELED)
  • FAILURE = Subscription failure (subscription status changed to FAILURE)
  • UNPAID = Unpaid subscription (subscription status changed to FAILURE + SUBSCRIPTION_UNPAID hook sent)

4. Subscription cancellation functions

There are two ways to cancel a subscription via the API, the Merchant Portal, or the Customer Portal:

• Cancel: the subscription is canceled immediately
• Cancel at the end of the billing period: The subscription will be canceled at the end of the current billing period (so that the subscriber can continue to use your service during their last paid period). When using the API, you must fill in the “atPeriodEnd” field.
  • Note: During this time, you can reactivate your subscription using the “reactivate” feature in Subscriptions.

ℹ️ Subscriptions for which all payments have been made automatically change to CANCELED status.

5. Change the amount of a subscription payment

CentralPay creates an invoice for each billing cycle of a subscription, based on the associated subscription model (subscriptionModel).

You can take manual actions at any time to modify the billing dates (invoices) for a subscription. Below is a list of possible actions:

• Modify the amount of an invoice installment: The invoiceItem service allows you to modify the amount of an invoice installment by entering a positive or negative amount that will be added to the original installment amount. The invoiceItem will be applied to the next subscription installment, whether it is created manually or automatically. You can also specify a particular installment in your request by providing an invoiceId.
• Create an additional payment due date: so-called “recurring” payment due dates (invoices) are created automatically based on your subscription model. You can create additional one-time payment due dates for your subscription by creating an invoice.
• Delete an unprocessed invoiceItem: if it is not yet linked to an invoice
• Close an upcoming payment due date: if you do not want CentralPay to process a payment (and/or its automatic retry attempts), you can close it using the “close” feature on the invoice. If necessary, you can reopen this payment due date using the “reopen” feature on the invoice if it has not been paid or if there are still scheduled retry attempts remaining.
• Forcing a payment due: transactions are processed automatically by the subscription service; however, you can initiate the transaction in advance or retry it manually using the “pay” feature on the invoice. These “manual” payments are not tracked by the automated retry system. This action can be performed on a closed invoice.

6. Complete guide to creating a subscription

CentralPay s’emploie à une croissance saine, permettant à nos utilisateurs d’être quotidiennement accompagnés par des équipes stables et expertes dans leur domaine (conformité, monétique, sécurité…).

Ainsi, nos services client et support sont joignables du lundi au vendredi depuis l’espace « Aide & Support » de votre Portail Marchand, par email ou par visioconférence sur rendez-vous.

1. Avant d’adresser une demande technique

Quelques points que vous pouvez vérifier préalablement :

• Authentification : Êtes-vous correctement authentifié ?
• Environnement : Êtes-vous sur le bon environnement du Portail Marchand et de l’API (RCT ou PROD) ?
• Autorisation : Avez-vous les autorisations nécessaires pour réaliser cette opération ? L’erreur HTTP 403 signale une erreur d’autorisation.
• Erreur HTTP : Consultez la signification des codes d’erreurs HTTP CentralPay. Si vous recevez un code erreur HTTP 500, veuillez contacter immédiatement le support technique.

2. Informations à communiquer pour toutes demandes techniques

• Les dates et heures précises des évènements concernés
• Le lien (URL) de la page concernée
• Une ou des capture(s) d’écran, idéalement une vidéo (Cloudapp permet de faire une vidéo d’une page du navigateur Google Chrome)
• Un UUID (ou id) de l’opération concernée et son type (transaction carte, remboursements, demande de paiement…)
• L’environnement sur lequel vous travaillez (recette RCT ou production PROD)
• Une description précise du problème rencontré ou de votre interrogation

Ces informations nous permettrons de vous accompagner et d’analyser votre situation plus efficacement.

Vos demandes seront traitées de façon prioritaire si elles sont envoyées depuis l’espace « Aide et Support » du Portail Marchand :

CentralPay is committed to healthy growth, ensuring that our users receive daily support from stable teams of experts in their respective fields (compliance, electronic payments, security, etc.).

Our customer service and support teams can be reached Monday through Friday via the « Help & Support » section of your Merchant Portal, by email, or by videoconference by appointment.

1. Before submitting a technical request

Here are a few things you can check beforehand:

• Authentication: Are you properly authenticated?
• Environment: Are you in the correct environment for the Merchant Portal and the API (Sandbox or LIVE)?
• Authorization: Do you have the necessary permissions to perform this operation? HTTP error 403 indicates an authorization error.
• HTTP Error: See the meanings of CentralPay HTTP error codes. If you receive an HTTP 500 error code, please contact technical support immediately.

2. Information to Provide for All Technical Inquiries

• The specific dates and times of the relevant events
• The link (URL) to the relevant page
• One or more screenshots, ideally a video (Cloudapp lets you record a video of a page in the Google Chrome browser)
• A UUID (or ID) for the transaction in question and its type (Card Transaction, Refund, Payment Request, etc.)
• The environment in which you are working (Sandbox testing or LIVE production)
• A detailed description of the problem you are experiencing or your question

This information will help us support you and analyze your situation more effectively.

Your requests will be given priority if they are submitted through the « Help and Support » section of the Merchant Portal:

Le flux BRW (Browser) s’applique aux transactions initiées par le client (CIT — Customer-Initiated Transaction) : le titulaire de la carte est présent et valide lui-même le paiement. Cette CIT authentifiée sert aussi de socle aux transactions MIT futures.

👉 Pour une transaction initiée par le marchand sans le porteur (facturation récurrente, montant variable, usage-based, frais ponctuels), consultez la documentation du flux 3RI.

❌ Attention au choix du flux : utiliser le BRW pour une transaction initiée par le marchand (MIT) entraîne une non-conformité, une friction inutile et une réduction importante du taux de conversion.

1. Les grandes étapes du flux BRW

Le flux BRW enchaîne cinq étapes côté API, dont deux conditionnelles : versioning (la carte est-elle authentifiable ?) → 3DS Method (si nécessaire) → authentification → challenge (si la banque l’exige) → résultat, avant de réaliser la transaction.

ℹ️ Tout le processus doit se dérouler sur une seule et même page web, sans redirection vers une page bancaire, grâce à une solution d'iframe. C'est une contrainte du process bancaire.

Pour accélérer votre intégration du flux BRW, vous pouvez partir d’une application d’exemple complète (PHP / Twig) qui rejoue toute la séquence décrite sur cette page : formulaire de paiement CUSTOM, versioning, 3DS Method en iframe, authentication, gestion du challenge, results puis transaction, le tout sur une seule et même page, conformément à la contrainte bancaire.

👉 Télécharger le code d’exemple  ·  Voir la démo en ligne

Avant de lancer le code d'exemple, renseignez vos identifiants dans le fichier .env (API_USER, API_PASSWORD, POS_UUID) et faites pointer HOST_CENTRALPAY_API_CORE vers l'environnement de test https://test-api.centralpay.net/v2/rest/.

2. Versioning

Le versioning est la première étape : il interroge le réseau de la carte pour savoir si elle peut être authentifiée en 3DS 2.2, et récupère les éléments techniques nécessaires à la suite. Concrètement, vous adressez à l’API CentralPay le PAN de la carte (Primary Account Number, le numéro à 16 chiffres).

Exemple (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/versioning' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'acctNumber=4000001000000067'

Comprendre la réponse. Une carte est dite « enrôlée » lorsque la banque qui l’a émise participe au protocole 3DS 2.2 pour cette carte. C’est la banque émettrice qui en décide : ni vous ni CentralPay ne pouvez enrôler une carte. Le versioning sert justement à savoir si c’est le cas.

• Carte non enrôlée → le versioning retourne une erreur 404 : l’authentification 3DS 2.2 est impossible pour cette carte. Prévoyez un repli (basculement en 3DS1 si supporté, ou refus du paiement selon votre politique de risque).
• Carte enrôlée → vous recevez un identifiant d’opération, le threeDSServerTransID (généré par CentralPay et conservé jusqu’au résultat final), ainsi que, le cas échéant, les données nécessaires au « 3DS Method » (une URL + une donnée encodée en base64).

Pour une carte enrôlée, deux réponses sont possibles :

Version 1 (la plus fréquente) — un 3DS Method est attendu :

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "threeDSMethodURL": "https://test-3dss-demo.centralpay.net/acs/3ds-method",
    "threeDSMethodDataForm": {
        "threeDSMethodData": "eyJ0aHJlZURTTWV0aG9kTm90aWZpY2F0aW9uVVJMIjoiaHR0cHM6Ly90ZXN0LTNkc3MuY2VudHJhbHBheS5uZXQvM2RzLzNkcy1tZXRob2Qtbm90aWZpY2F0aW9uLyIsInRocmVlRFNTZXJ2ZXJUcmFuc0lEIjoiOWNjNmIzM2MtZGQzNS00ZmJkLTgxY2QtZmQ5Y2YwYWVlZDljIn0="
    },
    "errorDetails": null
}

Les champs threeDSMethodURL et threeDSMethodData sont renseignés : passez à l’étape 3. 3DS Method.

Version 2 — pas de 3DS Method :

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "threeDSMethodURL": null,
    "threeDSMethodDataForm": null,
    "errorDetails": null
}

Seul threeDSServerTransID est renseigné (les champs 3DS Method sont vides) : passez directement à l’étape 4. Authentification.

3. 3DS Method

À quoi ça sert ? Le 3DS Method permet à la banque du porteur — via son ACS (Access Control Server, le serveur de la banque émettrice qui authentifie le porteur) — de collecter discrètement des informations techniques sur le navigateur du client, avant l’authentification. Ces informations enrichissent son analyse de risque et augmentent les chances d’une authentification frictionless (sans challenge pour le porteur).

Quand l’exécuter ? Uniquement si le versioning a renvoyé une valeur pour threeDSMethodURL et threeDSMethodData (cas « Version 1 » ci-dessus). Sinon, passez directement à l’authentification.

Comment ? Chargez l’threeDSMethodURL dans une iframe invisible (masquée à l’écran : cet échange est purement technique et ne doit rien afficher au porteur) et postez-y le champ threeDSMethodData. C’est le navigateur du porteur qui effectue cet appel vers la banque, en arrière-plan.

4. Authentification (BRW)

L’appel est adressé à l’URL 3ds2/authentication de l’API CentralPay. Cette requête transmet les données contextuelles liées au porteur et à son navigateur, qui permettent à la banque de décider si une authentification active (challenge) est nécessaire.

Exemple (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/authentication' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'threeDSServerTransID=7d031b8e-7fb7-4215-b866-eaacb395002f' \
--data-urlencode 'cardTokenId=5b9nb5cf-4470-4e58-b690-dd8965860eb8' \
--data-urlencode 'deviceChannel=02' \
--data-urlencode 'messageCategory=01' \
--data-urlencode 'purchaseAmount=1000' \
--data-urlencode 'purchaseCurrency=EUR' \
--data-urlencode 'threeDSRequestorAuthenticationInd=01' \
--data-urlencode 'browserJavaEnabled=true' \
--data-urlencode 'browserLanguage=fr-FR' \
--data-urlencode 'browserColorDepth=24' \
--data-urlencode 'browserScreenHeight=1052' \
--data-urlencode 'browserScreenWidth=1853' \
--data-urlencode 'browserTZ=120' \
--data-urlencode 'browserIP=127.0.0.1' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0' \
--data-urlencode 'browserAcceptHeader=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
--data-urlencode 'notificationURL=http://dev4.dev.centralpay.net:1101/requestor/challenge-notification' \
--data-urlencode 'threeDSRequestorURL=https://www.centralpay.eu'

💡 deviceChannel=02 indique le canal navigateur, propre au flux BRW. Les paramètres browser* (caractéristiques du navigateur du porteur) sont donc obligatoires ici.
Pour augmenter le taux d'authentification Frictionless, enrichissez cette requête avec les données contextuelles du porteur → voir Optimiser le taux de Frictionless

Champs à préciser selon l’objet de la CIT. Le champ threeDSRequestorAuthenticationInd est obligatoire : il indique la nature de l’authentification. Une CIT BRW peut servir soit à authentifier un paiement (messageCategory=01, PA), soit à authentifier une carte ou son porteur sans débit (messageCategory=02, NPA) — par exemple pour enregistrer une carte, la mettre à jour ou en vérifier le porteur. Les deux champs se renseignent de façon cohérente :

• recurringExpiry → date après laquelle plus aucune autorisation ne sera effectuée (format YYYYMMDD).
• recurringFrequency → nombre minimum de jours entre deux autorisations (1 à 999).
• purchaseInstalData → nombre maximum d’autorisations (échéances) prévues pour le paiement échelonné (1 à 999).

ℹ️ Les cas 04, 05 et 06 sont des authentifications hors paiement : aucun montant ni champ de récurrence n'est requis. Elles ne préparent pas forcément une MIT — ce sont souvent une fin en soi (enregistrer, vérifier ou maintenir une carte). La carte ainsi authentifiée pourra ensuite servir à des transactions CIT (porteur présent) comme MIT (3RI).

La réponse contient un statut d’authentification (transStatus) qui détermine la suite à donner :

❌ Pas d’autorisation — ne pas effectuer la transaction

✅ Autorisation sans challenge

🔐 Autorisation après challenge

Exemples de réponses :

C — Challenge requis :

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "transStatus": "C",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "acsURL": "https://test-3dss-demo.centralpay.net/acs/challenge",
    "acsChallengeMandated": "Y",
    "base64EncodedChallengeRequest": "eyJtZXNzYWdlVHlwZSI6IkNSZXEiLCJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImU2MDFlYjQ0LTU2N2MtNDM4Ny05MmZjLWU2ZjIzMjJiODIyYiIsImFjc1RyYW5zSUQiOiI3ZTQzZDI4ZC00M2RkLTRmM2MtYTcwOS00YjZkZDVlZjc5Y2QiLCJtZXNzYWdlVmVyc2lvbiI6IjIuMS4wIn0=",
    "contractId": "71602dd0-2790-4743-877b-e72530d7576d"
}

Y — Authentification réussie (challenge non nécessaire) :

{
    "threeDSServerTransID": "7d994177-32d8-43f7-87a4-3a3cd734cbfe",
    "transStatus": "Y",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "authenticationValue": "MTIzNDU2Nzg5MDA5ODc2NTQzMjEa",
    "eci": "02",
    "contractId": "71602dd0-2790-4743-877b-e72530d7576d"
}

Les champs requis pour la transaction sont présents : threeDSServerTransID, transStatus, authenticationValue (le cavv — Cardholder Authentication Verification Value, le cryptogramme qui prouve l’authentification) et eci (Electronic Commerce Indicator, qui indique le niveau d’authentification obtenu et conditionne le transfert de responsabilité en cas de fraude). Le xid n’est pas fourni : c’est une référence libre destinée aux marchands.

N — Transaction refusée :

{
    "threeDSServerTransID": "6396b832-3e5b-4143-bde6-f5r1c1e47da0",
    "transStatus": "N",
    "eci": "00",
    "contractId": "258128f3-5db9-4235-918a-f1d786f67c29"
}

5. Challenge

Le challenge est l’étape où le porteur s’authentifie activement auprès de sa banque (code à usage unique reçu par SMS, validation dans l’application bancaire, biométrie…). Il n’a lieu que si l’authentification a renvoyé transStatus = C.

• Une iframe doit soumettre un formulaire à l’acsURL retournée à l’étape 4.
• Le seul paramètre envoyé est creq, dont la valeur est le base64EncodedChallengeRequest issu de l’authentification.
• À la fin du challenge, l’URL que vous avez fournie (notificationURL) est appelée par la banque.

En environnement de test, le challenge s’affiche sous forme d’un OTP (One-Time Password, code à usage unique) ; en production, c’est la fenêtre de l’ACS de la banque qui s’affiche :

OTP de test :

• 1234 → Y (simule un challenge réussi – Authentification réussie)
• 4444 → A (simule un challenge réussi – Non authentifié / vérifié, mais une preuve de tentative est fournie.)
• 1111 → N (simule un challenge échoué – Non authentifié / compte non vérifié)
• 2222 → R (simule un challenge échoué – Authentification / vérification rejetée)
• 3333 → U (simule un challenge échoué – Authentification / vérification impossible (problème technique ou autre)

6. Réponse du challenge

À l’issue du challenge, le résultat est transmis dans le paramètre cres, encodé en base64. Décodez-le pour lire le statut. Exemple en PHP :

$retour = json_decode(base64_decode($_POST['cres']), true);

• Si le statut est Y ou A, le challenge est validé et le paiement est autorisé : appelez GET /results (étape 7) pour récupérer les données 3DS nécessaires à la transaction.
• Toute autre valeur signifie que le challenge a échoué : le paiement est refusé.

7. Résultat

Cette étape récupère les données 3DS définitives à reporter dans la transaction. Adressez le threeDSServerTransID de l’authentification.

ℹ️ Si l'authentification a directement retourné transStatus = Y (sans challenge), les données 3DS y figurent déjà : cette étape n'est pas nécessaire.

Appel :

curl --location -g --request GET 'https://test-api.centralpay.net/v2/rest/3ds2/results/{{threeDSServerTransID}}' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA=='

Réponse :

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "transStatus": "Y",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "authenticationValue": "JAmi21makAifmwqo2120cjq1AAA=",
    "eci": "01"
}

🔁 Préparer les MIT futures (3RI). Si cette CIT doit servir de référence à des paiements ultérieurs initiés par le marchand, conservez l'acsTransID de la séquence d'authentification : il sera requis comme threeDSReqPriorRef côté 3RI.

8. Transaction

Données à renseigner pour valider une transaction authentifiée en 3DS 2.2 :

• 3ds[threeDSServerTransID] = threeDSServerTransID
• 3ds[status] = transStatus
• 3ds[cavv] = authenticationValue
• 3ds[eci] = eci (obligatoire si disponible)
• 3ds[xid] = paramètre custom, référence libre destinée aux marchands

Exemple (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/transaction' \
--header 'Origin: https://example.centralpay.net' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'currency=EUR' \
--data-urlencode 'amount=1500' \
--data-urlencode 'endUserIp=9.64.32.8' \
--data-urlencode 'endUserLanguage=ita' \
--data-urlencode 'merchantTransactionId=cpcg_12654de89ce44' \
--data-urlencode 'pointOfSaleId=1beb8574-cf4c-4b12-b065-d12b3f0eaa90' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1' \
--data-urlencode 'browserAcceptLanguage=it_IT' \
--data-urlencode 'paymentRequestBreakdownId=5485d7e6-60c3-753c-94d3-682eaaf9ae6e' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'receiptEmail=support@centralpay.eu' \
--data-urlencode 'capture=true' \
--data-urlencode 'cardTokenId=5b9nb5cf-4470-4e58-b690-dd8965860eb8' \
--data-urlencode 'order[cardholderEmail]=support@centralpay.eu' \
--data-urlencode 'order[firstName]=John' \
--data-urlencode 'order[lastName]=Doe' \
--data-urlencode 'source=EC' \
--data-urlencode '3ds[xid]=35876533346561303461' \
--data-urlencode '3ds[cavv]=JAmi21makAifmwqo2120cjq1AAA=' \
--data-urlencode '3ds[eci]=01' \
--data-urlencode '3ds[status]=Y' \
--data-urlencode '3ds[threeDSServerTransID]=7d031b8e-7fb7-4215-b866-eaacb395002f'

Étape suivante : pour les transactions ultérieures initiées par le marchand (MIT), voir 3DS 2.2 – 3RI.

The BRW (Browser) flow applies to Customer-Initiated Transactions (CIT): the cardholder is present and authorizes the payment personally. This authenticated CIT also serves as the foundation for future MIT transactions.

👉 For a transaction initiated by the merchant without the cardholder (recurring billing, variable amounts, usage-based charges, one-time fees), see the 3RI flow documentation.

❌ Be careful when choosing the payment flow: Using BRW for a merchant-initiated transaction (MIT) results in non-compliance, unnecessary friction, and a significant drop in the conversion rate.

1. The main steps in the BRW workflow

The BRW flow consists of five steps on the API side, two of which are conditional: versioning (is the card authenticatable?) → 3DS Method (if necessary) → authentication → challenge (if required by the bank) → result, before completing the transaction.

ℹ️ The entire process must take place on a single web page, without being redirected to a bank page, using an iframe solution. This is a requirement of the banking process. 

To speed up your integration of the BRW flow, you can start with a complete sample application (PHP/Twig) that replicates the entire sequence described on this page: CUSTOM payment form, versioning, 3DS Method in an iframe, authentication, challenge handling, results, and then the transaction, all on a single page, in accordance with banking requirements.

👉 Download the sample code · View the online demo

Before running the sample code, enter your credentials in the file .env  (API_USER,  API_PASSWORD,  POS_UUID) and point it HOST_CENTRALPAY_API_CORE to the test environment https://test-api.centralpay.net/v2/rest/.

2. Versioning

The versioning is the first step: it queries the card network to determine whether the card can be authenticated using 3DS 2.2, and retrieves the technical information needed for the rest of the process. Specifically, you send the card’s PAN (Primary Account Number, the 16-digit number) to the CentralPay API.

Sample (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/versioning' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'acctNumber=4000001000000067'

Understanding the response. A card is said to be “enrolled” when the bank that issued it participates in the 3DS 2.2 protocol for that card. This is determined by the issuing bank: neither you nor CentralPay can enroll a card. Versioning is used precisely to determine whether this is the case.

• Card not enrolled → versioning return a 404 error: the 3DS 2.2 authentification is impossible for this card. Plan for a fallback (switch to 3DS1 if supported, or decline the payment according to your risk policy).
• Card enrolled → you receive a transaction ID, the threeDSServerTransID (generated by CentralPay and retained until the final result is available), as well as, if applicable, the data required for the “3DS Method” (a URL and data encoded in Base64).

For a rolled-up card, there are two possible answers:

Version 1 (the most common) — a 3DS Method is expected:

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "threeDSMethodURL": "https://test-3dss-demo.centralpay.net/acs/3ds-method",
    "threeDSMethodDataForm": {
        "threeDSMethodData": "eyJ0aHJlZURTTWV0aG9kTm90aWZpY2F0aW9uVVJMIjoiaHR0cHM6Ly90ZXN0LTNkc3MuY2VudHJhbHBheS5uZXQvM2RzLzNkcy1tZXRob2Qtbm90aWZpY2F0aW9uLyIsInRocmVlRFNTZXJ2ZXJUcmFuc0lEIjoiOWNjNmIzM2MtZGQzNS00ZmJkLTgxY2QtZmQ5Y2YwYWVlZDljIn0="
    },
    "errorDetails": null
}

The threeDSMethodURL and threeDSMethodData field have been filled in: proceed to step 3. 3DS Method.

Version 2 — no 3DS Method:

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "threeDSMethodURL": null,
    "threeDSMethodDataForm": null,
    "errorDetails": null
}

Only threeDSServerTransID is filled in (the 3DS Method fields are empty): proceed directly to Step 4. Authentication.

3. 3DS Method

What is it used for? The 3DS Method allows the cardholder’s bank — via its ACS (Access Control Server, the issuing bank’s server that authenticates the cardholder) — to discreetly collect technical information about the customer’s browser, before authentication. This information enhances the bank’s risk analysis and increases the likelihood of frictionless authentication (without requiring the cardholder to complete a challenge).

When should this be executed? Only if versioning returned a value for threeDSMethodURL and threeDSMethodData (the “Version 1” case above). Otherwise, proceed directly to authentication.

How? Load the threeDSMethodURL into an invisible iframe (hidden from view: this exchange is purely technical and should not display anything to the user) and post the threeDSMethodData field there. The user’s browser makes this call to the bank in the background.

4. (BRW) Authentification

The request is sent to the CentralPay API URL 3ds2/authentication. This request transmits contextual data related to the cardholder and their browser, which allows the bank to determine whether active authentication (challenge) is required.

Sample (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/authentication' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'threeDSServerTransID=7d031b8e-7fb7-4215-b866-eaacb395002f' \
--data-urlencode 'cardTokenId=5b9nb5cf-4470-4e58-b690-dd8965860eb8' \
--data-urlencode 'deviceChannel=02' \
--data-urlencode 'messageCategory=01' \
--data-urlencode 'purchaseAmount=1000' \
--data-urlencode 'purchaseCurrency=EUR' \
--data-urlencode 'threeDSRequestorAuthenticationInd=01' \
--data-urlencode 'browserJavaEnabled=true' \
--data-urlencode 'browserLanguage=fr-FR' \
--data-urlencode 'browserColorDepth=24' \
--data-urlencode 'browserScreenHeight=1052' \
--data-urlencode 'browserScreenWidth=1853' \
--data-urlencode 'browserTZ=120' \
--data-urlencode 'browserIP=127.0.0.1' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0' \
--data-urlencode 'browserAcceptHeader=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
--data-urlencode 'notificationURL=http://dev4.dev.centralpay.net:1101/requestor/challenge-notification' \
--data-urlencode 'threeDSRequestorURL=https://www.centralpay.eu'

💡 deviceChannel=02 indicates the browser channel, specific to the BRW feed. The browser* (the cardholder's browser characteristics) are therefore required here.
To increase the frictionless authentication rate, enrich this request with contextual data about the cardholder → see Optimizing the Frictionless Rate 

Fields to be specified based on the purpose of the CIT. Field threeDSRequestorAuthenticationInd is required: it specifies the type of authentication. A CIT BRW can be used to authenticate a payment (messageCategory=01, PA), or to authenticate a card or its holder without a charge (messageCategory=02, NPA) — for example, to register a card, update it, or verify the cardholder. Both fields must be filled out consistently:

• recurringExpiry → the date after which no further authorizations will be issued (format YYYYMMDD).
• recurringFrequency → minimum number of days between two authorizations (1 to 999).
• purchaseInstalData → maximum number of authorizations (due dates) specified for installment payments (1 to 999).

ℹ️ Cases 04, 05, and 06 are non-payment authentications: no amount or recurrence field is required. They do not necessarily lead to an MIT transaction — they are often an end in themselves (to register, verify, or maintain a card). The card authenticated in this way can then be used for both CIT (cardholder present) and MIT (3RI) transactions.  

The response contains an authentication status (transStatus) that determines the next steps:

❌ No authorization — do not complete the transaction

✅ Authorization without challenge

🔐 Authorization after challenge

Sample of responses:

C — Challenge required:

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "transStatus": "C",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "acsURL": "https://test-3dss-demo.centralpay.net/acs/challenge",
    "acsChallengeMandated": "Y",
    "base64EncodedChallengeRequest": "eyJtZXNzYWdlVHlwZSI6IkNSZXEiLCJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImU2MDFlYjQ0LTU2N2MtNDM4Ny05MmZjLWU2ZjIzMjJiODIyYiIsImFjc1RyYW5zSUQiOiI3ZTQzZDI4ZC00M2RkLTRmM2MtYTcwOS00YjZkZDVlZjc5Y2QiLCJtZXNzYWdlVmVyc2lvbiI6IjIuMS4wIn0=",
    "contractId": "71602dd0-2790-4743-877b-e72530d7576d"
}

Y — Authentication successful (no challenge required):

{
    "threeDSServerTransID": "7d994177-32d8-43f7-87a4-3a3cd734cbfe",
    "transStatus": "Y",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "authenticationValue": "MTIzNDU2Nzg5MDA5ODc2NTQzMjEa",
    "eci": "02",
    "contractId": "71602dd0-2790-4743-877b-e72530d7576d"
}

The required fields for the transaction are present: threeDSServerTransID, transStatus, authenticationValue (the CAVV — Cardholder Authentication Verification Value, the security code that verifies authentication) and eci (Electronic Commerce Indicator, which indicates the level of authentication achieved and determines the transfer of liability in the event of fraud). The xid is not provided: it is an optional reference intended for merchants.

N — Transaction declined:

{
    "threeDSServerTransID": "6396b832-3e5b-4143-bde6-f5r1c1e47da0",
    "transStatus": "N",
    "eci": "00",
    "contractId": "258128f3-5db9-4235-918a-f1d786f67c29"
}

5. Challenge

The challenge is the step in which the cardholder actively authenticates themselves with their bank (one-time code received via text message, validation in the banking app, biometrics, etc.). It occurs only if the authentication returned transStatus = C.

• An iframe must submit a form to the acsURL page returned in step 4.
• The only parameter sent is creq, whose value is the base64EncodedChallengeRequest obtained from authentication.
• At the end of the challenge, the URL you provided (notificationURL) is called by the bank.

In a test environment, the challenge appears as an OTP (One-Time Password); in production, the bank’s ACS window appears:

Test OTP:

• 1234 → Y (simulates a successful challenge – Authentication successful)
• 4444 → A (simulates a successful challenge – Not authenticated/verified, but a proof of the attempt is provided.)
• 1111 → N (simulates a failed challenge – No authenticated/unverified account)
• 2222 → R (simulates a failed challenge – Authentication/verification declined)
• 3333 → U (simulates a failed challenge – Authentication/verification failed (technical issue or other problem)

6. Challenge response

Once the challenge is complete, the result is returned in the cres parameter, encoded in Base64. Decode it to read the status. Example in PHP:

$retour = json_decode(base64_decode($_POST['cres']), true);

• If the status is Y or A, the challenge is validated and the payment is authorized: call GET /results (step 7) to retrieve the 3DS data required for the transaction.
• Any other value means the challenge failed: the payment was declined.

7. Result

This step retrieves the final 3DS data to be included in the transaction. Send the threeDSServerTransID authentication request.

ℹ️ If the authentication returned transStatus = Y directly (without a challenge), the 3DS data is already included: this step is not necessary.

Call:

curl --location -g --request GET 'https://test-api.centralpay.net/v2/rest/3ds2/results/{{threeDSServerTransID}}' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA=='

Response:

{
    "threeDSServerTransID": "7d031b8e-7fb7-4215-b866-eaacb395002f",
    "transStatus": "Y",
    "acsTransID": "375d90ad-3873-498b-9133-380cbbc8d99d",
    "authenticationValue": "JAmi21makAifmwqo2120cjq1AAA=",
    "eci": "01"
}

🔁 Prepare for future MITs (3RI). If this CIT is to serve as a reference for subsequent payments initiated by the merchant, retain the acsTransID from the authentication sequence: it will be required as threeDSReqPriorRef on the 3RI side.

8. Transaction

Information required to validate a transaction authenticated using 3DS 2.2:

• 3ds[threeDSServerTransID] = threeDSServerTransID
• 3ds[status] = transStatus
• 3ds[cavv] = authenticationValue
• 3ds[eci] = eci (required if available)
• 3ds[xid] = custom parameter, free-form reference for merchants

Sample (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/transaction' \
--header 'Origin: https://example.centralpay.net' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'currency=EUR' \
--data-urlencode 'amount=1500' \
--data-urlencode 'endUserIp=9.64.32.8' \
--data-urlencode 'endUserLanguage=ita' \
--data-urlencode 'merchantTransactionId=cpcg_12654de89ce44' \
--data-urlencode 'pointOfSaleId=1beb8574-cf4c-4b12-b065-d12b3f0eaa90' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1' \
--data-urlencode 'browserAcceptLanguage=it_IT' \
--data-urlencode 'paymentRequestBreakdownId=5485d7e6-60c3-753c-94d3-682eaaf9ae6e' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'receiptEmail=support@centralpay.eu' \
--data-urlencode 'capture=true' \
--data-urlencode 'cardTokenId=5b9nb5cf-4470-4e58-b690-dd8965860eb8' \
--data-urlencode 'order[cardholderEmail]=support@centralpay.eu' \
--data-urlencode 'order[firstName]=John' \
--data-urlencode 'order[lastName]=Doe' \
--data-urlencode 'source=EC' \
--data-urlencode '3ds[xid]=35876533346561303461' \
--data-urlencode '3ds[cavv]=JAmi21makAifmwqo2120cjq1AAA=' \
--data-urlencode '3ds[eci]=01' \
--data-urlencode '3ds[status]=Y' \
--data-urlencode '3ds[threeDSServerTransID]=7d031b8e-7fb7-4215-b866-eaacb395002f'

Next step: For subsequent merchant-initiated transactions (MIT), see 3DS 2.2 – 3RI.

Ce guide vous accompagne dans l’installation, la configuration et l’utilisation du plugin CentralPay pour WooCommerce (WordPress).

ℹ️ La plateforme CentralPay prend en charge différents moyens (carte, virement et prélèvement SEPA, initiation de paiement) et modes de paiement (paiement en une fois, abonnement, en plusieurs fois, etc.). Ce plugin permet uniquement l'encaissement de transactions cartes unitaires. 

Vous souhaitez demander une évolution du plugin, rendez-vous sur https://support.centralpay.com : Support & Paramétrage > Suggérer une nouvelle fonctionnalité.

1. Téléchargement du plugin

• Pour WooCommerce ➝ Télécharger l’archive ZIP du plugin CentralPay

⚠️ Veillez à ne pas la décompresser manuellement.

2. Installation sur WordPress

1. Connectez-vous à votre interface d’administration WordPress
2. Allez dans Extensions > Ajouter
3. Cliquez sur Téléverser une extension
4. Sélectionnez le fichier centralpay221.zip et cliquez sur Installer maintenant
5. Une fois l’installation terminée, cliquez sur Activer l’extension

3. Configuration du module

1. Allez dans WooCommerce > Réglages > Paiements
2. Cliquez sur CentralPay pour accéder à la configuration
3. Renseignez les champs suivants puis cliquez sur Enregistrer les modifications :

4. Statut de commande

Le plugin WooCommerce de CentralPay intègre automatiquement une URL de retour (return_url) dans le lien du formulaire de paiement. Cette URL permet de rediriger le client vers la page de confirmation de commande (/checkout/order-received/) et d’actualiser le statut de la commande en fonction du résultat du paiement.

Si le client final ferme la fenêtre de paiement avant d’être redirigé, la mise à jour de la commande peut ne pas se déclencher correctement côté WooCommerce.

Pour garantir la mise à jour fiable du statut de commande, nous recommandons de mettre en place un Hook (callback serveur à serveur) dans votre Backoffice CentralPay.

Étapes de configuration :

1. Accédez à :
   Production : https://backoffice.centralpay.net/admin/hook/
   Test : https://test-backoffice.centralpay.net/admin/hook/
2. Créez un Hook avec les paramètres suivants :
   • Événement : Point de Vente > TRANSACTION_SUCCEDEED
   • Affecté au Point de Vente : sélectionnez votre Point de Vente WooCommerce
   • URL : https://votre-site-woocommerce.com/?wc-api=cpay_validation
     (Remplacez par l’URL de votre site WooCommerce.)
3. Sauvegardez le Hook

Le paramètre /?wc-api=cpay_validation est nécessaire pour que le plugin WooCommerce de CentralPay reconnaisse la notification et déclenche la mise à jour du statut de la commande.

Cette configuration doit être réalisée à la fois dans votre environnement de test et sur votre profil marchand de production.

5. Personnalisation du logo

Vous pouvez également personnaliser l’interface de paiement en ajoutant le logo de votre site via le Backoffice :

1. Accédez à : https://backoffice.centralpay.net/admin/point_of_sale/
2. Dans le détail de votre Point de Vente, cliquez sur Modifier
3. Importez votre logo dans la section Logo

Ce logo sera affiché directement dans le formulaire de paiement pour une expérience utilisateur plus cohérente.

6. Mode test

• Activez le mode test dans la configuration (attention, vous devez disposer d’un profil marchand CentralPay de test et renseigner les identifiants de ce profil de test)
• Utilisez les cartes de test fournies par CentralPay pour simuler des paiements
• Vérifiez le bon fonctionnement :
  • Du formulaire de paiement
  • Des redirections
  • Des statuts de commande

7. Suivi des paiements

• Retrouvez tous vos paiements dans WooCommerce > Commandes
• Le plugin CentralPay met à jour automatiquement les statuts des commandes
• En cas de besoin, un journal des événements est disponible dans le fichier error.log du plugin

8. Langues disponibles

Le plugin est disponible en :

• 🇫🇷 Français
• 🇬🇧 Anglais

Vous pouvez modifier ou ajouter vos propres traductions via les fichiers .po présents dans le dossier /languages, ou en utilisant un plugin comme Loco Translate.

9. Désinstallation

Pour désinstaller le plugin :

• Désactivez-le via le menu des extensions
• Cliquez sur Supprimer
• Le script de désinstallation supprimera les paramètres du plugin

10. Support

Pour toute question ou assistance, contactez notre support technique depuis https://support.centralpay.com.
Merci d’indiquer votre identifiant marchand, l’URL de votre site et le plus de détails possible sur votre besoin.

This guide will walk you through the installation, configuration, and use of the CentralPay plugin for WooCommerce (WordPress).

ℹ️ The CentralPay platform supports various payment methods (credit/debit cards, Bank transfers, SEPA Direct Debits, and Payment Initiation Service (PIS)) and payment options (one-time payments, subscriptions, installment plans, etc.). This plugin only allowsfor the processing of one-time credit/debit card transactions.   

If you'd like to request a change to the plugin, please visit https://support.centralpay.com: Support & Settings > Suggest a new feature.

1. Download the plugin

• For WooCommerce ➝ Download the CentralPay plugin ZIP archive

⚠️ Be sure not to unzip it manually.

2. Installation on WordPress

1. Log in to your WordPress admin dashboard
2. Go to Extensions > Add
3. Click  » Upload an Extension« 
4. Select the file  » centralpay220.zip  » and click  » Install Now« 
5. Once the installation is complete, click  » Enable Extension« 

3. Module Configuration

1. Go to WooCommerce > Settings > Payments
2. Click on CentralPay to access the settings
3. Fill in the following fields, then click  » Save Changes « :

4. Order Status

The CentralPay WooCommerce plugin automatically includes a redirect URL (return_url) in the payment form link. This URL redirects the customer to the order confirmation page (/checkout/order-received/) and updates the order status based on the payment result.

If the end customer closes the payment window before being redirected, the order update may not trigger correctly on the WooCommerce side.

To ensure that order status is updated reliably, we recommend setting up a hook (server-to-server callback) in your CentralPay Backoffice.

Setup steps:

1. Go to:
   Production: https://backoffice.centralpay.net/admin/hook/
   Testing: https://test-backoffice.centralpay.net/admin/hook/
2. Create a hook with the following parameters:
   • Event: Point of Sale (POS) > TRANSACTION_SUCCEDEED
   • Assigned to a Point of Sale (POS): Select your WooCommerce POS store
   • URL: https://votre-site-woocommerce.com/?wc-api=cpay_validation
     (Replace with the URL of your WooCommerce site.)
3. Save the Hook

The ` /?wc-api=cpay_validation ` parameter is required for the CentralPay WooCommerce plugin to recognize the notification and trigger the order status update.

This configuration must be set up both in your Test environment and on your production Merchant Profile.

5. Logo Customization

You can also customize the payment interface by adding your website’s logo through the Backoffice:

1. Go to: https://backoffice.centralpay.net/admin/point_of_sale/
2. In your Point of Sale details, click Edit
3. Upload your logo in the  » Logo » section

This logo will be displayed directly in the payment form to provide a more consistent user experience.

6. Test Mode

• Enable test mode in the settings (please note: you must have a CentralPay test Merchant Profile and enter the credentials for that test Merchant Profile)
• Use the test cards provided by CentralPay to simulate payments
• Check that it is working properly:
  • From the payment form
  • Redirects
  • Order Statuses

7. Payment Tracking

• View all your payments in WooCommerce > Orders
• The CentralPay plugin automatically updates order statuses
• If needed, an event log is available in the plugin’s ` error.log ` file

8. Available Languages

The plugin is available in:

• 🇫🇷 French
• 🇬🇧 English

You can edit or add your own translations using the ` .po ` files located in the ` /languages` folder, or by using a plugin such as Loco Translate.

9. Uninstallation

To uninstall the plugin:

• Disable it through the Extensions menu
• Click  » Delete« 
• The uninstall script will delete the plugin’s settings

10. Support

If you have any questions or need assistance, please contact our technical support team at https://support.centralpay.com.
Please include your Merchant ID, your website URL, and as many details as possible about your request.

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

ℹ️ Before reading this page, please see the section on onboarding for partners.

CentralPay partners based in France operate as intermediaries in banking and payment services (IOBSP), specifically as Intermediaries for Banking and Payment Services (MOBSP).

To become a CentralPay MOBSP partner, you must register with ORIAS. CentralPay will then need to register you as its Intermediary. Your part of the process can be completed in a few hours, while CentralPay’s part takes a few days. ORIAS, for its part, may take up to two months to review your application.

Although this process is your responsibility, CentralPay can assist you if needed. Please contact our customer service department if you need help.

1. Prepare your data

1.1. Get your certificate of appointment

After signing your partnership agreement with CentralPay:

1. Send an email to our customer service department that includes your company name and SIREN number
2. CentralPay will respond with your authorization certificate. You will need this document for step 3.3.

1.2. Gather your supporting documents

During Step 3.3 of the registration process, you will need to provide the following supporting documents:

• Commercial register issued within the last three months
• Proof of professional qualifications: a degree from an accredited business or management school; an RNCP certification (NCF 122, 128, 313, or 314, levels 7 through 5); or recognition by the CIEP for foreign degrees

If you do not have proof of professional competence accepted by Orias, please send an email to our customer service department. CentralPay can help you complete the necessary training.

See the attached image, which refers to the Level III – IOBSP category (Level 3).

2. Create your ORIAS account

2.1. Access the form

1. Go to the ORIAS website
2. Scroll down until you see the  » How Does It Work? » section .
3. Click  » Sign Up« 

You will be redirected to the registration form.

2.2. Enter the information

1. Enter your SIREN number
2. Enter your business information. Be sure to register as a legal entity.
3. Enter your legal representative’s information
4. Enter the contact information for your legal representative
5. Enter your company’s contact information, including your website if you have one
6. Enter your business address
7. Check all the information you’ve entered, then click  » Submit. »

2.3. Log in to your ORIAS account

Check your inbox for an email from ORIAS (no-reply-orias@orias.fr). The email contains your username and a temporary password.

1. Return to the ORIAS website
2. Click  » Sign In  » /  » Login »
3. Enter your username and the temporary password provided in your email
4. Follow the instructions on your screen to change your password, then save it

After saving your new password, you will be redirected to your ORIAS account page

3. Submit a new registration request

3.1. Register Your Business

1. Click  » New Registration  » to begin the registration process; a form will appear
2. Select IOB Activity
3. Next, select  » Non-Exclusive Intermediary for Banking Transactions and Payment Services (MOBSP)« 
4. Click Submit

3.2. Please provide additional information

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
   • If a different registration type is specified, use your browser’s Back button to return to the previous page and try again.
2. For the first question, select the answer:  » I declare that I am not entrusted with any funds. »
3. For the second question, select the answer:  » Minor, » indicating to ORIAS that financial services are not your company’s primary business activity
4. For the third question, select the answer: Yes, indicating to ORIAS that your company offers credit (or other banking and payment services) solely as a secondary service
5. Click  » Go to the ‘Supporting documents’ step »

3.3. Please provide your supporting documents

1. Submit your Commercial register
2. Submit your authorization form, which is the authorization certificate from Step 1.1
3. Submit your Professional Competency for « you » (Level I IOBSP), which serves as your proof of professional competence for Step 1.2.
4. Click « Go to the next step« 

3.4. Pay your registration fee

The final step is to pay your registration fee.

1. Please note that you are paying for registration as a non-exclusive Intermediary for banking transactions and payment services. Your registration cannot be finalized without paying the fee.
2. Choose to pay with your credit card, or click  » Select another payment method  » to pay by Bank transfer or check.
3. After you’ve paid, click  » Download Invoice  » to download your receipt
4. Click  » Complete Registration  » to finalize your registration
5. You will receive your ORIAS registration number by email, confirming that your registration is complete. Please email this number to CentralPay’s customer service department.

4. CentralPay registers you as a MOBSP

After you email your Orias registration number to CentralPay, CentralPay will register you as a non-exclusive Intermediary for banking operations and payment services (MOBSP).

5. ORIAS reviews your application

ORIAS will review your documents and application to ensure that your file is fully compliant. ORIAS will notify you of its final decision via email. If your application is approved, the email will also include the date on which your MOBSP status will take effect.

Please feel free to contact ORIAS by phone (09.69.32.59.73) or email (contact@orias.fr) if you do not receive the information regarding your application in a timely manner.

6. Update your legal notices

After receiving approval from ORIAS and becoming a MOBSP, be sure to update your legal notices. Add something similar to the following example to the footer of your website, to your legal notices page, and anywhere else you distribute or sell payment services.

[Company Name], a company registered with the Trade and Companies Register (RCS) of [City of Registration] under number [RCS number], and listed in the Single Register of Insurance Intermediaries, Banking and Finance under registration number [ORIAS registration number] as a non-exclusive Intermediary for banking transactions and payment services.

À compter du 9 octobre 2025, la Vérification du bénéficiaire (VoP – Verification of Payee) deviendra obligatoire pour tous les virements SEPA, qu’ils soient classiques ou instantanés. Ce dispositif, gratuit pour les utilisateurs, vise à renforcer la sécurité des paiements en réduisant à la fois :

• les fraudes au virement (notamment les fraudes au faux RIB),
• les erreurs de saisie d’IBAN ou de nom du bénéficiaire.

Concrètement, avant l’exécution d’un virement, l’établissement du payeur doit interroger l’établissement du bénéficiaire pour vérifier la concordance entre l’IBAN et le nom du titulaire du compte. En cas de discordance, une alerte est affichée au payeur, qui conserve la liberté de poursuivre ou non l’opération.

Enjeux du dispositif

• Protection des utilisateurs : limiter les virements mal orientés ou frauduleux.
• Sécurité du système de paiement SEPA : accompagner le déploiement du virement instantané en Europe.
• Confiance des entreprises et des particuliers : améliorer la transparence et la fiabilité des paiements.
• Harmonisation européenne : instaurer une norme commune pour tous les PSP (banques, établissements de paiement et de monnaie électronique).

Base légale

• Règlement (UE) 2021/1230 sur les virements instantanés en euros et la modification du règlement (UE) n° 260/2012 (SEPA), qui introduit l’obligation de VoP.
• Règlement (UE) 2015/847 sur les informations accompagnant les transferts de fonds, qui impose la transmission exacte des informations sur le payeur et le bénéficiaire.
• Code monétaire et financier :
  • Articles L.133-6 et L.133-7 relatifs à l’autorisation des opérations de paiement et à l’exactitude des informations,
  • Articles L.561-5 et suivants relatifs aux obligations de vigilance en matière de LCB-FT.
• Doctrine de l’ACPR, qui dans plusieurs décisions a sanctionné l’insuffisance de dispositifs de vérification et de correspondance entre l’identité du client et son compte

Foire aux questions (FAQ)

1. Qu’est-ce que la VoP ?

La Vérification de l’Ordre de Paiement (VoP) est un service réglementaire instauré au niveau européen.
Elle permet de comparer automatiquement le nom du bénéficiaire d’un virement avec l’IBAN renseigné par le payeur, avant l’exécution du virement.
Objectif : renforcer la sécurité des paiements et réduire les fraudes (notamment fraude au faux RIB).

2. Qui est concerné ?

• Les payeurs : particuliers ou entreprises qui initient un virement.
• Les bénéficiaires : toute personne physique ou morale recevant des virements (vous, en tant que client CentralPay).
• Les prestataires de services de paiement (PSP) : banques, établissements de paiement ou de monnaie électronique, qui doivent intégrer la VoP dans leurs systèmes.

3. Comment fonctionne la VoP concrètement ?

Lorsqu’un virement est initié :

1. Le payeur saisit l’IBAN et le nom du bénéficiaire.
2. Sa banque interroge le PSP du bénéficiaire (via un canal sécurisé) pour vérifier la concordance entre l’IBAN et le nom enregistré dans la base du bénéficiaire.
3. La réponse est renvoyée au PSP du payeur et affichée au payeur.

4. Quels résultats peuvent apparaître ?

Trois cas sont possibles :

• Correspondance exacte : l’IBAN et le nom concordent → le virement peut être initié sans alerte.
• Correspondance partielle : l’IBAN correspond mais le nom est différent (fautes de frappe, abréviation, orthographe différente). Le payeur reçoit un avertissement et peut :
  • corriger le nom,
  • ou confirmer qu’il s’agit bien du bénéficiaire attendu.
• Absence de correspondance : l’IBAN et le nom ne correspondent pas → le payeur reçoit une alerte forte. Il peut annuler ou décider de poursuivre en acceptant le risque.

Est-ce que la VoP bloque un virement ?

Non. La VoP ne bloque pas l’exécution d’un virement. Elle fournit une information supplémentaire au payeur qui reste libre de valider ou non l’opération.
Toutefois, certaines banques peuvent paramétrer des règles internes de blocage en cas de discordance totale.

Quels échanges ont lieu entre banques et PSP ?

• Le PSP du bénéficiaire (ex. CentralPay) conserve dans sa base le nom exact du titulaire du compte.
• Lors d’une requête VoP, il répond par un code standardisé indiquant : correspondance, correspondance partielle ou absence de correspondance.
• Ces échanges sont sécurisés, tracés et limités aux seules données nécessaires, conformément au Règlement (UE) 2015/847 sur l’accompagnement des virements.
• Aucune autre donnée personnelle (adresse, documents KYC, etc.) n’est transmise.

Quels sont les avantages de la VoP ?

• Pour le payeur : réduction des risques de fraude au virement, détection des erreurs de saisie.
• Pour le bénéficiaire : limitation des retards de paiement liés aux erreurs, sécurisation de l’image vis-à-vis de ses clients.
• Pour le système financier : meilleure prévention des fraudes et conformité avec les standards européens.

Que dois-je faire en tant que bénéficiaire CentralPay ?

• Communiquer à vos clients l’IBAN correct et le nom exact enregistré auprès de CentralPay (raison sociale complète, sans abréviation).
• Vérifier que vos factures, contrats et supports incluent toujours les mêmes coordonnées bancaires.
• En cas de changement de dénomination sociale ou d’utilisation d’un nom commercial, informer rapidement vos clients et CentralPay pour mettre à jour les données.

Que se passe-t-il en cas de non-concordance fréquente ?

Si vos clients rencontrent souvent des alertes VoP lors de virements, cela peut indiquer que vos coordonnées bancaires ne sont pas communiquées de façon homogène.

CentralPay peut vous accompagner pour réviser et harmoniser vos informations de paiement afin d’éviter les frictions.

Illustration du VoP par le CNMP

Effective October 9, 2025, Verification of Beneficiary (VoP) will become mandatory for all SEPA bank transfers, whether standard or instant. This system, which is free for users, aims to enhance payment security by reducing both:

• Bank transfer fraud (particularly fraud involving fake bank account information),
• errors in entering the IBAN or the Beneficiary’s name.

Specifically, before executing a bank transfer, the payer’s financial institution must check with the Beneficiary’s financial institution to verify that the IBAN matches the account owner’s name. If there is a discrepancy, an alert is displayed to the Payer, who remains free to decide whether or not to proceed with the transaction.

Challenges of the Program

• User protection: limiting misdirected or fraudulent bank transfers.
• SEPA Payment System Security: Supporting the Rollout of Instant Bank Transfers in Europe.
• Business and Consumer Confidence: Improving the Transparency and Reliability of Payments.
• European harmonization: establishing a common standard for all PSPs (banks, payment institutions, and Electronic money institutions).

Legal Basis

• Regulation (EU) 2021/1230 on instant bank transfers in euros and amending Regulation (EU) No. 260/2012 (SEPA), which introduces the VoP requirement.
• Regulation (EU) 2015/847 on information accompanying fund transfers, which requires the accurate transmission of information about the Payer and the Beneficiary.
• Monetary and Financial Code:
  • Articles L.133-6 and L.133-7 concerning the authorization of payment transactions and the accuracy of information,
  • Articles L.561-5 et seq. concerning due diligence obligations in the area of AML/CFT.
• ACPR doctrine, which in several decisions has penalized the inadequacy of verification procedures and the failure to ensure that a customer’s identity matches their account

Frequently Asked Questions (FAQ)

1. What is VoP?

The Payment Order Verification (VoP) is a regulatory service established at the European level.
It automatically compares the name of the Beneficiary of the bank transfer with the IBAN provided by the Payer before the bank transfer is executed.
Objective: to enhance payment security and reduce fraud (particularly fraud involving fake bank account information).

2. Who is affected?

• Payers: individuals or businesses that initiate a bank transfer.
• Beneficiaries: Any individual or entity that receives bank transfers (you, as a CentralPay customer).
• Payment Service Providers (PSPs): banks, payment institutions, or Electronic money institutions, which must integrate VoP into their systems.

3. How does VoP actually work?

When a bank transfer is initiated:

1. The payer enters the IBAN and the beneficiary’s name.
2. The sender’s bank queries the beneficiary’s payment service provider (via a secure channel) to verify that the IBAN matches the name on file for the beneficiary.
3. The response is sent back to the payer’s PSP and displayed to the payer.

4. What results might occur?

There are three possible scenarios:

• Exact match: The IBAN and name match → the bank transfer can be initiated without a warning.
• Partial match: The IBAN matches, but the name is different (typos, abbreviations, different spelling). The payer receives a warning and can:
  • correct the name,
  • or confirm that this is indeed the intended Beneficiary.
• Mismatch: The IBAN and name do not match → the payer receives a high-priority alert. The payer can cancel the transaction or decide to proceed by accepting the risk.

Does the VoP block a bank transfer?

No. VoP does not block the execution of a bank transfer. It provides additional information to the Payer, who remains free to approve or reject the transaction.
However, some banks may set internal rules to block transactions in the event of a complete mismatch.

What kind of data exchanges take place between banks and PSPs?

• The Beneficiary’s PSP (e.g., CentralPay) stores the exact name of the account owner in its database.
• When a VoP query is made, it responds with a standardized code indicating: match, partial match, or no match.
• These transactions are secure, traceable, and limited to only the necessary data, in accordance with Regulation (EU) 2015/847 on the reporting of bank transfers.
• No other personal data (address, KYC documents, etc.) is shared.

What are the benefits of VoP?

• For the payer: reduced risk of bank transfer fraud; detection of data entry errors.
• For the beneficiary: reduced payment delays caused by errors; protection of the company’s reputation with its customers.
• For the financial system: improved fraud prevention and compliance with European standards.

What should I do as a CentralPay Beneficiary?

• Provide your customers with the correct IBAN and the exact name on file with CentralPay (full company name, without abbreviations).
• Make sure your invoices, contracts, and other documents always include the same bank account information.
• If your company name changes or you start using a trade name, notify your customers and CentralPay promptly so that your information can be updated.

What happens if there are frequent discrepancies?

If your customers frequently encounter VoP alerts when making bank transfers, this may indicate that your bank account information is not being provided consistently.

CentralPay can help you review and standardize your payment information to avoid friction.

Illustration of VoP by the CNMP

CentralPay n’identifie pas le pays TVA des acheteurs : cette responsabilité incombe au marchand. Pour justifier correctement vos déclarations, collectez le pays de l’acheteur, conservez vos preuves, et transmettez‑les à CentralPay afin qu’elles figurent dans vos exports et historiques de transaction.

Public cible : marchands B2C vendant des biens ou services dans plusieurs pays de l’Union européenne.

1) Principe général

La TVA applicable dépend du pays de résidence de l’acheteur (consommateur final), non du pays du marchand ni du moyen de paiement utilisé.

Le marchand doit donc déterminer, conserver et déclarer le pays de son client afin d’appliquer la bonne TVA. CentralPay n’a ni la légitimité réglementaire ni la fiabilité technique pour déterminer ce pays à sa place.

En clair : vous êtes responsable de collecter et de stocker les informations nécessaires à la détermination du pays TVA.

2) Pourquoi CentralPay ne peut pas déterminer le pays du client

Les indices techniques accessibles à un PSP (carte, IP, etc.) ne permettent pas une identification fiable du pays de l’acheteur :

• Pays BIN (carte) : peu fiable pour la TVA. Les cartes de banques en ligne sont souvent émises dans un autre pays que celui du détenteur.
• Pays IP : faussé en cas d’utilisation de VPN, proxy, mobile ou cloud.
• Payeur ≠ Acheteur : la personne qui paie n’est pas forcément celle soumise à la TVA (ex. carte d’un proche ou d’un employeur).

C’est pourquoi CentralPay ne réalise aucune analyse pour identifier le pays du client. Seul le marchand détient l’information fiscale valide.

3) Ce que vous devez faire en tant que marchand

3.1 Collecter le pays de l’acheteur

• Intégrez la sélection du pays de facturation dans votre tunnel de commande.
• Transmettez ces informations à CentralPay via l’API au moment de la transaction.

3.2 Transmettre le pays à CentralPay

⚠️ Si vous n’alimentez pas Customer.country, CentralPay ne peut pas afficher ni exporter le pays de vos acheteurs. Vos exports ne permettront donc pas de justifier vos déclarations TVA.

4) Ce que CentralPay fournit dans les exports

CentralPay met à disposition des exports comportant :

Des exports personnalisés peuvent être mis en place si vous souhaitez inclure d’autres champs ou formats (SFTP, e‑mail…).

5) Bonnes pratiques de conformité TVA

1. Toujours collecter le pays de facturation côté front (champ obligatoire ou déduit du profil client).
2. Croiser au moins deux preuves non contradictoires pour chaque commande.
3. Gérer les divergences : si les indices diffèrent (ex. IP ≠ carte), demandez un justificatif avant de facturer.
4. Enregistrer les preuves pendant au moins 10 ans (durée légale pour les services numériques UE).
5. Vous enregistrer à l’OSS/IOSS si vous vendez à des consommateurs dans plusieurs pays de l’UE.
6. Relier facture, transaction et preuves pour chaque vente.

6) Exemples de cas

7) FAQ

CentralPay peut‑il déterminer le pays à ma place ?
Non. Nous exposons des indices (pays BIN, etc.), mais la décision et la preuve fiscale relèvent de vous.

Puis‑je me baser uniquement sur le BIN ?
Non, le BIN n’est pas une preuve fiable. Utilisez toujours le pays de facturation comme référence principale.

Comment vérifier que mes exports sont complets ?
Vérifiez la présence de buyer_country_declared dans vos fichiers. Si le champ est vide, votre front n’a pas transmis le pays.

CentralPay does not identify buyers’ VAT countries: this is the Merchant’s responsibility. To ensure your tax filings are accurate, collect the buyer’s country of residence, keep your records, and submit them to CentralPay so they can be included in your export files and transaction histories.

Target audience: B2C merchants selling goods or services in several European Union countries.

1) General Principle

The applicable VAT depends on the buyer’s (end consumer ‘s) country of residence, not on the Merchant’s country or the payment method used.

The merchant must therefore determine, record, and report the customer’s country in order to apply the correct VAT rate. CentralPay has neither the regulatory authority nor the technical capability to determine this country on the merchant’s behalf.

In short: You are responsible for collecting and storing the information needed to determine the VAT country.

2) Why CentralPay Cannot Determine the Customer’s Country

The technical indicators available to a PSP (card, IP address, etc.) do not allow for reliable identification of the buyer’s country:

• BIN Country (card): unreliable for VAT purposes. Online bank cards are often issued in a country other than the cardholder’s.
• IP Country: May be inaccurate when using a VPN, proxy, mobile device, or cloud service.
• Payer ≠ Buyer: The person who pays is not necessarily the person liable for VAT (e.g., a card belonging to a family member or an employer).

That is why CentralPay does not perform any analysis to identify the customer’s country. Only the Merchant has the valid tax information.

3) What You Need to Do as a Merchant

3.1 Collect the buyer’s country

• Integrate the billing country selection into your checkout process.
• Send this information to CentralPay via the API at the time of the transaction.

3.2 Submit the country to CentralPay

⚠️ If you do not enter the information at Customer.country, CentralPay will not be able to display or export the countries of your buyers. Your export files will therefore not be sufficient to support your VAT filings. 

4) What CentralPay Provides in the Exports

CentralPay provides export files that include :

Custom exports can be set up if you want to include additional fields or formats (SFTP, email, etc.).

5) Best Practices for VAT Compliance

1. Always collect the billing country on the front end (required field or derived from the Customer Profile).
2. Cross-check at least two non-contradictory pieces of evidence for each order.
3. Handling Discrepancies: If the information differs (e.g., IP ≠ map), request supporting documentation before billing.
4. Retain records for at least 10 years (the legal retention period for digital services in the EU).
5. Register with the OSS/IOSS if you sell to consumers in multiple EU countries.
6. Link invoices, transactions, and receipts for each sale.

6) Case Examples

7) FAQ

Can CentralPay determine the country for me?
No. We provide guidance (BIN countries, etc.), but the decision and the tax documentation are your responsibility.

Can I rely solely on the BIN?
No, the BIN is not a reliable source of information. Always use the billing country as your primary reference.

How can I verify that my exports are complete?
Check to see if the  » buyer_country_declared  » field is present in your files. If the field is empty, your front-end system did not include the country.

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 operates its services from two data centers in France. The equipment and services at these two sites are fully redundant.

1. Highly Resilient Hosting

• Two TIER III-designed data centers located in Tours
• Active/active environment between the two sites
• Contractual service level agreements (SLAs) of 99.9%
• Recognized standards: ISO 27001, PCI DSS, Code of Conduct

2. An infrastructure that ensures the security of your data

• Network core with speeds of up to 10 Gb/s
• Fully redundant power supply system, with power density ranging from 600 mA to 32 A
• Access control system with two-factor authentication (ID card and personal code)
• Video surveillance and an alarm system connected 24 hours a day, 7 days a week to our remote monitoring center
• FirePro Aerosol Fire Suppression System

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

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

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

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

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

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

Issuer response codes returned to CentralPay after a card authorization request.

These values generally correspond to the ISO 8583 “Response code” (DE39) returned by card networks/issuers. Depending on the scheme, country, and routing, you may also receive network-specific or gateway-specific variants (for example alphanumeric or 3-digit codes).

Important: the same code can cover multiple issuer-side reasons. Unless explicitly stated, CentralPay passes these codes as received. For troubleshooting, combine the response code with your transaction context (amount, currency, 3DS result, merchant category, card brand, retries).

Most common response codes

All response codes (exhaustive)

The following codes may be returned depending on the network, country, routing, or integration. This section is exhaustive compared to the previous version of this page, and includes both standard and non-standard variants.

Issuer response codes returned to CentralPay after a card authorization request.

These values generally correspond to the ISO 8583 “Response code” (DE39) returned by card networks/issuers. Depending on the scheme, country, and routing, you may also receive network-specific or gateway-specific variants (for example alphanumeric or 3-digit codes).

Important: the same code can cover multiple issuer-side reasons. Unless explicitly stated, CentralPay passes these codes as received. For troubleshooting, combine the response code with your transaction context (amount, currency, 3DS result, merchant category, card brand, retries).

Most common response codes

All response codes (exhaustive)

The following codes may be returned depending on the network, country, routing, or integration. This section is exhaustive compared to the previous version of this page, and includes both standard and non-standard variants.

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.

Customer profiles (Customer) unify and secure all your customer data for easier management. They interact with other CentralPay services and notably allow you to:

• Centralize their payment history (across all sales channels and payment methods)
• Digitize and securely store their payment methods (cards, SEPA mandates, virtual IBANs)
• Easily track their recurring payments (subscriptions, split payments) or pending settlements (payment requests)

In certain cases, they can also be associated with an e-money account, allowing the customer to receive and use funds within the network of the e-money distributor partner.

A Customer must be identified by either their email address or their phone number.

It is also possible to declare other information concerning them, such as their last name, first name, language, personalized reference, default payment method, etc.

1. Usage

Creating a Customer is mandatory for performing:

• Subscriptions or split payments by card
• 1-click card payments
• SEPA direct debit payments
• SEPA transfer payments with a dedicated Virtual IBAN
• Creating an anonymous e-money account

2. Interfaces

You can view all Customers on your account from your Merchant Portal Account Customers

Your Customers also have access to a customer portal allowing them to manage payments made to your company:

3. Creating a Customer

There are two methods for creating a Customer:

• Create a Customer via the dedicated API service, which then allows you to create a Card, manage a Virtual IBAN for this Customer, initiate a transaction, a payment request, etc.
• Create a Customer via a payment request

CentralPay ensures Customer uniqueness: if you initiate a payment request with Customer creation while their email or phone number is already known in your account, CentralPay will not create a new Customer and will associate the transaction with the existing profile.

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.

1. Organization of anti-fraud services

Anti-fraud services are segmented into 4 tools:

• Whitelist
  The purpose of the « whitelist » is to make the application of a transaction acceptance rule selective. It becomes inoperative for identified customers, VIPs, or trusted customers who are included in a « whitelist ». « Whitelists » apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for certain user populations.
• Blacklist
  The « blacklist » service makes it possible to refuse payments. As with « whitelists », « blacklists » apply to data specific to the cardholder (card, IP, phone, email).
• Transaction acceptance rules
  This tool makes it possible to build the specific rules that define the conditions for accepting a payment.
• Anti-fraud scoring
  The scoring service detects potentially fraudulent transactions based on cross-analysis of multiple payment-related data points.

The transaction processing phases are always executed in this order.

If the input data meets all the conditions of the defined « whitelist », the « blacklist » service will not be executed and the transaction will be processed normally.

If the input data meets one of the conditions of the defined « blacklist » and is not included in the « whitelist » service, the transaction will be refused and the « acceptance rule » service will not be executed. Each service is executed top-down with respect to the CentralPay actor hierarchy, which means that a platform can apply its anti-fraud service settings to its merchants, but the reverse is not possible.

2. Fraud scoring tool

CentralPay relies on a fraud detection service based on machine learning algorithms.

This predictive engine is built from a large sample of data provided by CentralPay in JSON format and sourced from transaction, refund, dispute data.

This service relies on behavioral classification linked to the merchant’s business sector.

The engine returns an action and a score. The action instructs the payment service to accept or refuse the transaction.

The score classifies the risk level by providing a percentage probability of fraud. This score is then interpreted in the rules engine.

The score enables the merchant and the algorithm to interact together to improve.

Scores are classified as follows:

• From 0 to 19 = low risk
  Transaction accepted
  No action
• From 20 to 59 = medium risk
  Transaction accepted
  Action: Send an event with score details for manual review and learning
• +60 = high risk
  Transaction refused
  Action: Send an event with score details for manual review and learning

This fraud exposure analysis service analyzes the fraud risk exposure context of each transaction. This service returns a score that makes it possible to automatically process the expected response in the rules engine.

The score is based on cross-analysis of the following data:

• IP risk index
• Proxy detection
• TOR network detection
• IP address verification
• Confidence factors
• Email checks
• Address & phone checks
• High-risk shipping address
• IP address geolocation
• Identification of the devices used
• Email address
• Browser type
• Country mismatches
• Shipping address distance
• Billing address distance
• Email domain
• Time
• Order amount
• Country
• Phone number
• IP owner
• Email owner
• Card address verification

3. Whitelists and blacklists

3.1. Whitelist

The purpose of the « whitelist » is to make the application of an acceptance rule selective. This rule becomes inoperative for identified customers, VIPs, or trusted customers who are included in a « whitelist ».

The anti-fraud service then moves on to the next step.

« Whitelists » apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for a user population.

3.2. Blacklist

The « blacklist » step makes it possible to refuse payments.

As with « whitelists », « blacklists » apply to data specific to the cardholder:

• Country
• Geographic regions
• Card numbers
• Phone numbers
• Email
• IP addresses
• IBAN

4. Transaction acceptance rules

The acceptance rules engine is a powerful, modular application component that makes it possible to adapt the processing behavior to be applied to each transaction, such as:

• Allow
• Refuse
• Alert

This service therefore makes it possible to define actions to be performed on each transaction from a wide list of available attributes: fraud score, cardholder location, total sales amount over 7 or 30 days, VIP whitelist customer, specific parameter provided by the merchant…

An acceptance rule is a logical condition. It makes it possible to authorize, restrict, and/or prohibit transactions.
A rule consists of 4 elements: the action, the attributes, the operators, the values.

The syntax of a rule is as follows: « Action » « if » « Attribute » « Comparison operator » « Comparison value »

Example:

REFUSE if card_country != 'FRA'

The rule shown in this example makes it possible to automatically refuse payments when the card country is not France.
The grammar syntax chosen by the platform for its acceptance engine is very similar to SQL syntax (used to interact with databases).

4.1. Available actions

• ALLOW
  Allows the payment
• REFUSE
  Refuses the payment
• ALERT
  Sends a « webhook » notification for the associated transaction

4.2. Available attributes

By typing « # », the available attributes are displayed.

In a rule, an attribute is always followed by a comparison operator.

List of attributes:

In the case of custom_acceptance_data[‘key’] = ‘value’, for it to be taken into account, the exact same field must be included in the request for the targeted object.

Logical operators and parentheses:

Logical operators AND and OR

The syntax used to define rules makes it possible to create multiple conditions within the same rule. The conditions will remain defined in the same way, with the only difference being that a keyword will be placed between the conditions.

The keywords are and and or. They define how the rules engine will interpret the sequence of these rules. « AND » corresponds to inclusion and « OR » to exclusion.

Example:

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

The previous example allows payments whose amount is less than 10 AND whose card is French. If one or the other of the defined conditions is not met, the action will not be executed.

Example:

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

The previous example allows payments whose amount is less than 10 OR whose card is French. If one or the other of the defined conditions is met, the action will be executed.

Parentheses

Using parentheses when defining a multi-condition rule makes it possible to define condition blocks and the priorities between these blocks. The principle is the same as for priorities in mathematical operators.

Example:

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

In the previous example, the rules engine will first interpret the block (#card_country = ‘FRA’ or #currency = ‘EUR’). That is, the payment will be allowed if (the card is French or the currency is the euro), AND the amount is less than 10.

Rule execution order

Rules are executed in an order to be defined. This order is important because as soon as a transaction meets the criteria of a rule, the following rules will not be processed.

Rules are executed in the display order of the list in the interface.
A position indicator is displayed in each list. To change a rule’s position, simply drag it to the desired position.

Rule examples:

ALLOW if #amount < 1000 and #transactions_amount_daily < 10000

This example allows transactions whose amount is less than 10 if the sum of the day’s transaction amounts is less than 100.

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

This rule blocks payments if the risk score exceeds 3 or if the IP used and the card issuing region correspond to the ‘ASIA_PACIFIC’ zone.

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

This rule requires a 3D Secure transaction if the card country is not France, the United States, or Great Britain.

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

This previous example ALLOWS payments IF the amount is LESS THAN 100 AND the sum of the day’s transaction amounts is LESS THAN 1000 OR the currency is € or $ AND the sum of the month’s transaction amounts is LESS THAN 10,000.

The logical operators « AND » and « OR » are only syntactically correct in lowercase.

4.3. Available comparison operators

• = (equals)
• != (not equal to)
• < (less than)
• <= (less than or equal to)
• in (in the following)
• not in (not in the following)

The comparison operators = , != , > , < , >= and <= must be followed by a value.

The IN and NOT IN operators are followed by a list of comparison values.
A list of values is enclosed in parentheses, and the values inside the list are separated by commas.

Example:

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

The example shown above makes it possible to refuse all payments whose currency is not the Euro, the US Dollar, the Pound Sterling, or the Swiss Franc.

This syntax avoids writing multiple rules or multiple conditions within the same rule.

4.4. Available values:

Depending on the value type, the syntax used to define the value will not be the same:

• Integers (numeric value without decimals): Standard syntax (e.g., 100)
• Doubles (numeric value with decimals): The value is defined with a dot as the decimal separator (e.g., 12.32)
• String: The value is defined between single quotes (e.g., ‘FRA’)
• Booleans: The value is true or false (e.g., false)

ℹ️ "Amount" values must be entered in centimes (e.g., for €10, enter 1000).

4.5. Logical operators:

The available operators are AND and OR. They define how the rules engine will interpret the sequence of these rules. « AND » enables inclusion, while « OR » enables exclusion.

Example:

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

The example shown above makes it possible to refuse payments whose amount is less than €10 AND whose card is not French. If one or the other of the defined conditions is not met, the action will not be executed.

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 entrer en conflit 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 :

The payment request (PaymentRequest) is the service that allows you to generate payment links. You can create payment requests via API or via the Merchant Portal. The payment request can also be paired with the CentralPay notification service, allowing you to easily send a payment link to your customers by email or SMS and schedule automated reminders.

1. API creation

1.1. Create a PaymentRequest

Below are the available payment methods and the corresponding API values in the PaymentRequest service:

If you want to allow multiple payment methods or modes in your PaymentRequest, you must provide the paymentMethod object multiple times.

Example:

paymentMethod[]=TRANSACTION
paymentMethod[]=SCT_TRANSACTION

⚠️ Some combinations of payment methods or modes may conflict and your PaymentRequest may return an error. For example, you cannot allow a TRANSACTION and a SUBSCRIPTION; however, you can allow a TRANSACTION and an INSTALLMENT.

Here is the key information about other values to provide when creating a PaymentRequest:

ℹ️ For SEPA transfer transactions, you can define whether you want to display the Virtual IBAN dedicated to the Customer or generate a single-use Virtual IBAN (SCT) from the settings of your Points of Sale.

1.2. Send a PaymentRequest by email / SMS

When creating it, you can ask CentralPay to send the payment request to your customer. There are two sending methods:

• Via the default PaymentRequest mailer: CentralPay sends the payment request using a standardised email/SMS template and from the sender email configured in your point of sale (or, failing that, CentralPay’s sender email « no-reply@centralpay.eu »).
  • To do this, you must [coming soon]
    
    
• Via the CentralPay email/SMS notification service: CentralPay sends the payment request according to the scenario and communication templates you have configured. This service notably enables automated customer reminders, based on the payment request parameters (payment deadlines, payment progress, etc.).
  • To do this, you must [coming soon]