Les coûts de services
Les coûts de services de CentralPay sont répartis en 3 catégories :
- Les frais d’interchange liés aux transactions par carte bancaire
- Les frais techniques par opération
- Les frais de fonctionnement CentralPay
Frais d'interchange ++
L’interchange correspond à la valeur chargée par l’établissement émetteur d’une carte de paiement (la banque du client final) à l’établissement acquéreur (la banque du commerçant).
Les "Card Scheme Fees" correspondent aux frais pris par les réseaux Cartes (Visa, Mastercard, CB) pour faire fonctionner le service.
INTERCHANGE +
Les frais d’Interchange + les frais des réseaux cartes (card scheme fees).
INTERCHANGE ++
Les frais d’Interchange + les frais des réseaux cartes (card scheme fees) + les frais de fonctionnement de l'Etablissement
Le modèle économique de CentralPay est celui de l’INTERCHANGE ++.
Depuis décembre 2015, l’interchange a été normalisé en Europe. En dehors de l’Espace Économique Européen, les frais sont plus élevés et moins homogène.
Frais d’interchange E-commerce (carte non présente) applicable aux Agents de Centralpay:
Interchange Intrarégional (EEA)
- Débit, prépayé CB, VISA, MASTERCARD : 0,2 %
- Crédit, débit différé CB, VISA, MASTERCARD : 0,3 %
- Corporate réseau CB: 0,9 %
- Corporate EU VISA : 1,65 %
- Corporate EU MASTERCARD : 1,5 %
- AMERICAN EXPRESS : 1.6%
Interchange Interrégional (Hors EEA)
- Débit, prépayé CB, VISA, MASTERCARD : 1,15 %
- Crédit, débit différé CB, VISA, MASTERCARD : 1.5 %
- Corporate VISA ou MASTERCARD : 2 %
- AMERICAN EXPRESS : 2,4%
Card scheme fees (EEA)
- Opération Intraregionale réseau CB: 0.034% + 0.05 €
- Opération Intraregionale réseau VISA : 0.034% + 0.05 €
- Opération Intraregionale réseau MASTERCARD : 0.088 % + 0.05 €
Card scheme fees (Hors EEA)
- Opération interrégionale réseau VISA : 1,04 % + 0.15 €
- Opération interrégionale réseau MASTERCARD : 0.75% + 0.35 €
Frais d’interchange Point de vente physique (Carte Présente) applicable aux Agents de Centralpay:
Interchange Intrarégional (EEA)
- Débit, prépayé CB, VISA, MASTERCARD : 0,2 %
- Crédit, débit différé CB, VISA, MASTERCARD : 0,3 %
- Corporate réseau CB: 0,9 %
- Corporate EU VISA, : 1,5%
- Corporate EU MASTERCARD : 1,5%
- AMERICAN EXPRESS : 1.6%
Interchange Interrégional (Hors EEA)
- Débit, prépayé VISA, MASTERCARD : 0,2 %
- Crédit, débit différé VISA, MASTERCARD : 0,3 %
- Corporate VISA, MASTERCARD : 2 %
- AMERICAN EXPRESS : 2.4%
Card scheme fees (EEA)
- Opération Intraregionale réseau CB: 0.014% + 0.05 €
- Opération Intraregionale réseau VISA : 0.014% + 0.05 €
- Opération Intraregionale réseau MASTERCARD : 0.042 % + 0.05 €
Card scheme fees (Hors EEA)
- Opération Intraregionale réseau VISA : 0.47 % + 0.15 €
- Opération Intraregionale réseau MASTERCARD : 0.70 % + 0.35 €
Calculs des frais d'interchange
Afin de permettre au compte "Plateforme" de connaître les coûts éventuels d’une transaction Carte, CentralPay fournit le détail de la carte dans le JSON de l’objet card :
europeanEconomicArea = False / True
Si la carte a été émise depuis l’espace économique européen, alors les règles d’interchange Intrarégional s’appliquent.
CommercialBrand
- VISA
- MASTERCARD
- AMEX
- OTHER
CardType
- DEBIT
- PREPAYED
- CREDIT
- DIFF_DEBIT
Region
- US
- CANADA
- EU
- ASIA_PACIFIC
- LATIN_AMERICA
- CEMEA
ProductType
- CONSUMER
- CORPORATE
Conseil : pour connaître le coût lié à une transaction, procéder comme suit :
- Une fois le cardTokenId reçu, faire un GET pour obtenir les informations de la carte
- Si europeanEconomicArea = False, la transaction est INTERRÉGIONNAL et la tarification maximale s’applique, soit 2.49%
- Si europeanEconomicArea = True, alors calculer les valeurs du couple Type et Product type
- Si type = prepayed ou débit et productType = consumer alors le coût est 0.285%
- Si type = differed debit ou credit et productType = consumer alors le coût est 0.385%
- Si productType = corporate, alors le coût est 0.985 %
Exemple de retour JSON de l’objet Card :
"card": {
"cardId": "9140aec5-0c6e-4c70-a6c2-b96e43792d03",
"merchantCardId": null,
"creationDate": "2018-08-13T14:31:07.009+02:00",
"commercialBrand": "VISA",
"first6": "400000",
"last4": "0002",
"expirationMonth": 12,
"expirationYear": 2018,
"country": "fr",
"cardholderName": "John DOE",
"cardholderEmail": "jdoe@gmail.com",
"description": null,
"customerId": null,
"fingerprint": "7b3572ef401515f48ed58282bbedad69236408e3",
"additionalData": {},
"cardTokenId": "ea9d68cd-152b-4176-8911-5e1a5062bcfa",
"cardType": "debit",
"region": "EU",
"productType": "consumer",
"europeanEconomicArea": "true",
},Frais de technique
CentralPay facture des frais monétiques unitaires HT sur chaque transaction entrante ou sortante de sa "Plateforme".
Frais de transaction par carte bancaire
Frais unitaire par transaction : 0.15 €.
Ces frais intègrent les coûts suivants : frais d’autorisation, de capture, de remise, de 3DS, d’antifraude et de SMS.
Frais de remboursement
Frais unitaires par opération : 0.50 €
Frais de tenue de compte
1.95 € / mois et par compte de paiement actif
Frais de prélèvement SDD ou virement SCT entrant ou sortant issue de la zone SEPA
SCT entrant : 0.15 € + 0.3%
SCT sortant : 0.15 €
SDD : 0.15 € +0.3%
Rejet SDD : 7.5 €
Frais de fonctionnement CentralPay
L'Etablissement facture à ses "Agents de Services de Paiement" des frais de fonctionnement basés sur le volume d’opérations réalisées au cours d’un mois donné.
Onboarding
Le service d’enrôlement (ou onboarding) permet de répondre aux besoins de conformité et de connaissance client des Agents de services de paiement et des Apporteurs CentralPay.
Un certain nombre de documents à télécharger sont requis pendant le processus d’enrôlement. Ces documents vont permettre de procéder aux vérifications clients avant transaction (connues sous le nom de KYC – Know Your Customer), conformément à la loi européenne anti-blanchiment d'argent. La liste de documents nécessaires peut varier selon votre pays d'incorporation.
Les Agents de services de paiement et les Apporteurs ont donc la possibilité d’enregistrer leurs clients afin de leur permettre d’accéder aux services de paiement qu’ils auront développés.
Pour réaliser ces opérations, CentralPay a conçu un service d’enrôlement entièrement dématérialisé, réalisable à distance depuis un portail dédié accessible depuis un mobile ou un ordinateur.
Le service d’enrôlement (ou onboarding) assure :
- La collecte d’informations et de documents liés aux futurs titulaires du compte.
- La vérification de ces informations dans le cadre de nos obligations de lutte anti-blanchiment et de financement du terrorisme.
- La prise de consentement du titulaire par signature électronique sur les conditions générales d’utilisation du service et des conditions tarifaires de l’Agent ou celles de l'Etablissement pour les Apporteurs.
Récapitulatif des pièces demandées et des seuils d'encaissement :
|
Statut |
Risque faible |
Risque moyen |
Risque élevé |
|
Individuel |
<10 K€
|
> 10K€ En plus de ce qui est demandé :
|
|
|
Entrepreneur individuel |
<50K€
|
Entre 50 et 100K€ En plus de ce qui est demandé :
|
>100K€ Justificatif de domicile (moins de 3 mois) |
|
Personne morale |
<200K€
|
Entre 200 et 500 K€
|
>500K€ La liste et la pièce d'identité des personnes détenant plus de 10% des actions ou des droits de votes |
Le processus d’enrôlement
Le processus d'enrôlement repose sur la collecte et la vérification de documents identifiant l'organisation titulaire d'un compte de paiement. Ce processus est traité par l'API d'onboarding. Il inclut un portail en marque blanche qui facile les échanges entre le futur titulaire et Centralpay pour la collecte des pièces justificatives. Lors de l'instruction d'un enrôlement ou au cours de la vie de la relation d'affaire, le service de conformité peut etre amené à demander des éléments complémentaires. Ces demandes seront alors adressées par Centralpay, soit sous forme d'email directement au titulaire, soit à la plateforme du partenaire sous forme de WebHook si ce dernier souhaite maitriser le processus de son coté.
Chaque enrôlement est nécessairement précédé d'une demande d’enrôlement qui peut être réalisée soit par l’API, soit depuis le Backoffice.
Le tronc commun à cette demande est la pré-soumission des informations connues du profil utilisateur.
La demande d’enrôlement permet la pré-soumission des éléments suivants :
- Préparation du profil utilisateur :
- Prénom
- Nom
- Mobile
- Date
- Ville de naissance
- Pays de naissance
- Préparation du choix du type de compte :
- Inconnu
- Entreprise, association, secteur public, ...
- Nom de la personne morale
- Ancienneté
- Prévisionnel d’encaissement
- Autoentrepreneur, artisan, commerçant, ...
- Prévisionnel d’encaissement
- Particulier
- Prévisionnel d’encaissement
- Prévisionnel d’encaissement
- Choix du mode de workflow :
- Continu
- Séquentiel
Ces informations participent à la définition de la classe de risque et donc de la collecte d’informations nécessaire. L’utilisateur peut ensuite se connecter au portail selon le mode d’intégration choisi par le partenaire (voir plus bas).
Deux modes d'enrollements sont disponibles selon les besoins du partenaire.
Le workflow continuel est linéaire. il assure la collecte de l'ensemble des pièces avant de créer le compte de paiement.
Le worflow sequentiel introduit une étape intermédiaire avant la collect des pièces d'identité, à la signature des CGU et permet ainsi de créer un comptre de paiement non actif avant la collecte des documents. Cette collecte peut néanmoins se réaliser dans la coniuité du processus démarré ou ulterieurement si l'utilisateur ne les a pas avec lui. Ce workflow permet de réferencer un sous-marchand d'une place de marché plus facilement puisqu'aucune pièce personnelle ne lui sera demandé. L'enrolement séquentiel permet un enrolemement Express et l'atribution d'un wallet instantané.
Le partenaire dispose de la possibilité de fournir un numéro de SIREN à la demande d'enrôlement permettant ainsi une récupération automatique des données de la personne morale ou de l'entrepreneur individuel depuis les services des greffes de tribunaux de commerce. Ce service est plus rapide et sans friction côté utilisateur. Si le partenaire ne dispose pas des SIREN, l'utilisateur pourra en saisir un sur l'écran concerné.
NB : Si un SIREN est érroné ou ne match pas avec une référence connue, l'utilisateur dispose de 3 essais avant de basculer sur un mode manuel. Dans ce cas, il devra remplir lui même les différentes informations exigées par la conformité. Dans ce type d'enrôlement les données recomplétée par notre appel de SIREN seront prévalentes sur la complétions des données relatives à la personne morale, tout au long de l'enrôlement.
Une fois le statut du compte confirmé, la conformité effectue des vérifications sur le compte par rapport aux informations données pour vérifier le compte.
Si l'enrôlement est inexacte au début (notamment sur le workflow), un nouvel enrôlement devra être effectué afin de une levée des limites.
1/ Workflow « Continuel »
Le workflow « Continuel » implique la collecte de l'ensemble des éléments d'un dossier avant la validation par Centralpay et la création et l'activation du compte de paiement. L'ensemble des pièces est nécessaire pour la validation et l'activation du compte par Centralpay.
A/ Enrôlement continuel auto avec SIREN
Le SIREN est fournit avant le début de l'enrôlement, s'il est correct, une simple validation des données est requis.
NB : si aucun SIREN n'est reconnu, le workflow passe automatiquement en mode manuel (schéma C).
B/ Enrôlement continuel auto sans SIREN
Le SIREN n'est pas fournit avant l'enrôlement mais lors de l'enrôlement en tant que tel, mais l'utilisateur pourra l'indiquer à l'étape 3.
NB : si aucun SIREN n'est reconnu, le workflow passe automatiquement en mode manuel (schéma C).
C/ Enrôlement continuel manuel sans SIREN
Aucun SIREN n'est transmis, avant ou pendant l'enrôlement. Les données et les pièces sont collectées manuellement. Ce mode est requis pour les associations, les particulier et les société de droit étranger.
2/ Workflow « Séquentiel »
Le workflow « séquentiel » permet, lui, de faire un enrôlement en fonction du prévisionnel d'encaissement annuel. Quand le compte est créé si le prévisionnel d'encaissement annuel est dépassé, vous devez fournir de nouveaux documents d'identification (KYC) qui devront être validés par la conformité de Centralpay.
A/ Enrôlement séquentiel auto avec SIREN
Le SIREN est fournit avant le début de l'enrôlement, s'il est correct, une simple validation des données est requis.
NB : si aucun SIREN n'est reconnu, le workflow passe automatiquement en mode manuel (schéma C).
B/ Enrôlement séquentiel auto sans SIREN
Le SIREN n'est pas fournit avant l'enrôlement mais soumis par l'utilisateur à l'étape 3.
NB : si aucun SIREN n'est reconnu, le workflow passe automatiquement en mode manuel
C/ Enrôlement séquentiel manuel sans SIREN
Aucun SIREN n'est transmis, avant ou pendant l'enrôlement
Les deux modes d’intégration du service
CentralPay a développé 2 modes de consommation du service d’enrôlement :
- Enrôlement depuis le portail CentralPay :
- Mode asynchrone : le futur titulaire du compte reçoit un SMS ou email incluant un lien vers le portail lui permettant de finaliser le processus d’enrôlement qui peut être réalisé à n’importe quel moment.
- Mode synchrone : le partenaire effectue des demandes d’enrôlement depuis ses propres formulaires via l’API qui lui fournit un identifiant d’enrôlement lui permettant d’afficher le portail d’enrôlement directement en Iframe, pop-in. Le client poursuit donc le processus de manière synchrone.
- Mode asynchrone : le futur titulaire du compte reçoit un SMS ou email incluant un lien vers le portail lui permettant de finaliser le processus d’enrôlement qui peut être réalisé à n’importe quel moment.
- Enrôlement complet depuis l’API CentralPay : le partenaire a complètement interfacé l’API d’enrôlement avec ses propres formulaires.
Les notifications Webhook
Les notifications liées au service d'enrôlement suivantes sont disponibles :
- ONBOARDING_ENROLLMENT_CREATED
>> Une demande d'enrôlement a été générée
- ONBOARDING_ENROLLMENT_STATUS_UPDATED
>> Un changement d'état d'un enrôlement a été constaté- Partiel
- Attente de validation
- Terminé
- Refusé
- ONBOARDING_ADDITIONAL_DOCUMENT_REQUESTED
>> La conformité a émis une demande de document
- ONBOARDING_ENROLLMENT_DOCUMENT_INVALID
>> Des documents du titulaire du compte ont été concidérés comme invalide par la conformité
- ONBOARDING_ADDITIONAL_DOCUMENT_UPDATED
>> Le client a mis à jour le document demandé
- ONBOARDING_ENROLLMENT_WORKFLOW_RESET
>> Le workflow est revenu à son état initial
- ONBOARDING_PEP_SANCTION_SEARCH_RESULT
>> La recherche PEP/SANCTION a été efféctuée - les statuts possibles :
* ACCEPTED : aucun hit PEP ou SANCTION sur la recherche. Le compte peut etre activé ou débloqué.
* NEED_MANUAL_VALIDATION : ce statut indique la présence d'un hit potentiel. Le service conformité de Centralpay est en cours d'analyse et de traitement du hit. Le compte est alors bloqué en PAY IN et PAY OUT en attendant le résultat de l'analyse.
* ACCEPTED_FALSE_POSITIVE : le hit est levé après vérification de la conformité. Ce statut intervient après le statut NEED_MANUAL_VALIDATION.
* REFUSED : Le Hit est confirmé. Le compte est refusé après analyse. Ce statut intervient après NEED_MANUAL_VALIDATION
* ACCEPTED_PEP : l'analyse confirme la présence d'une Personne Politiquement Exposée validée par le service conformité. Ce statut intervient également après le statut NEED_MANUAL_VALIDATION
- ONBOARDING_PAYMENT_ACCOUNT_CREATED
>> Le compte a été créé
- PAYMENT_ACCOUNT_STATUS_UPDATED (en service en février 2024)
>> Informe sur le statut du compte selon le blocage des PAY IN ou PAYOUT
Les valeurs transmises sont :- creationDate : date d'ajout de la nouvelle configuration
- merchantUuid : UUID du marchand
- EnrollmentUuid : UUID de l'enrolement du marchand
- Les statuts des blocages possibles sont :
- NONE : PAY IN & PAY POSSIBLE
- IN : PAY IN BLOCKED
- OUT : PAYOUT BLOCKED
- IN_OUT : PAY IN & PAYOUT BLOCKED
Pour plus d’information sur ce service, voir : https://ref-api.centralpay.net/plateform#207-onboarding
Intégration de l'onboarding
Quelques informations à retenir lors de l'intégration du processus d'enrôlement via les appels api.
Les workflows des enrôlements sont évolutifs !!
Les workflows dépendents des recommandations de la CPR, ils sont donc voués à évoluer et à changer !!
(Fonctionnement, ordre de demandes des informations, etc..)
Enrôlement Séquentiel
- Après la validation de l'enrôlement séquentiel, le compte et le wallet sont créés mais le wallet n'est pas actif
- Pour que le wallet s'active, il faut faire la première demande de levée de limites
- Toutes les levées de limites ne peuvent pas se faire en une seule fois, une validation est nécessaire pour chaque levée de limites
- Pour savoir quand une levée de limites a été validée, un hook est configurable, il s'agit du hook "ONBOARDING_ENROLLMENT_STATUS_UPDATED" qui permet d'être informé à chaque modification de status de l'enrôlement et donc quand une levée de limite a été validée.
Enrôlement avec SIREN
Ce qu'il faut savoir sur l'intégration de l'enrôlement avec SIREN :
- Tout d'abord la requête pour enregistrer le SIREN doit être fait en premier, avant la requête de création de l'enrôlement
- L'uuid du SIREN est ensuite passé dans la requête de création de l'enrôlement via le paramètre "identityBadge". Cela permet de déterminer le worflow qui convient.
- Lors d'un enrôlement avec SIREN, le "/complete" n'est pas requis !
- Par contre, il faut toujours définir le password.
Règlements, reversements et pays autorisés
Pays autorisés pour l'établissement d'une relation d'affaires
Les Agents de Services de Paiement et Distributeurs de Monnaie Electronique sont autorisés à entrer en relation d'affaires et à ouvrir des comptes de paiement ou de Monnaie Eletronique pour des personnes physiques ou morales issues de tous les pays de l'Union Européenne, de l’Espace Économique Européen et dans un pays tiers imposant des obligations équivalentes de lutte contre le blanchiment et le financement du terrorisme tels que définis par CentralPay.
Espace Economique Européen :
- Allemagne
- Autriche
- Belgique
- Bulgarie
- Chypre
- Croatie
- Danemark
- Espagne
- Estonie
- Finlande
- France et Outre mer *
- Grèce
- Hongrie
- Irlande
- Islande
- Italie
- Lettonie
- Lituanie
- Liechtenstein
- Luxembourg
- Malte
- Norvège
- Pays-Bas
- Pologne
- Portugal
- République tchèque
- Roumanie
- Slovaquie
- Slovénie
- Suède
*Outre mer français : Guadeloupe - Guyane française - Martinique - Mayotte - Polynésie française - Réunion - Saint-Barthélemy - Saint-Martin (français) - Saint-Pierre-et-Miquelon - Wallis-et-Futuna
Pays tiers qualifiés équivalent en terme de LCB-FT par CentralPay
- Afrique du Sud,
- Argentine,
- Australie,
- Brésil,
- Canada,
- Etats-Unis,
- Hong-Kong,
- Japon,
- Mexique,
- Nouvelle-Zélande,
- Royaume Uni,
- Singapour,
- Suisse
L'entrée en relation d'affaires dans ces pays implique la fourniture de justificatifs d’identité en alphabet latin et de registres de commerce et de statuts traduits en Anglais ou en Français.
Pays autorisés en règlement
Europe
- Andorra
- Austria
- Belgium
- Bulgaria
- Cyprus
- Czech republic
- Denmark
- Estonia
- Feroe Islands
- Finland
- France et outre mer
- Georgia
- Germany
- Gibraltar
- Greece
- Greenland
- Hungary
- Ireland
- Iceland
- Italy
- Latvia
- Liechtenstein
- Lithuania
- Luxembourg
- Republic of Macedonia
- Malta
- Monaco
- Moldova
- Netherlands
- Norway
- Poland
- Portugal
- Slovakia
- Slovenia
- Spain
- Sweden
- Swiss
- United Kingdom
Africa
- Benin
- Burkina Faso
- Cameroon
- Cap-Vert
- Congo (Republic of the Congo)
- Comoros
- Djibouti
- Guinea
- Kenya
- Lesotho
- Malawi
- Morocco
- Rwanda
- Saint Helen's Island
- South Africa
- Swaziland
- Tanzania
- Togo
- Senegal
America
- Argentina
- Brazil
- Canada
- Chile
- Curaçao
- Dominica
- Dominican Republic
- Falkland Islands
- Honduras
- Jamaica
- Mexico
- Paraguay
- Peru
- Puerto Rico
- Saint Martin (Dutch)
- Salvador
- United States of America
- Uruguay
Middle East
- Armenia
- Azerbaijan
- Bahrein
- Israel
- Jordan
- Occupied Palestinian Territory
- Oman
- Qatar
- Saudi Arabia
- Tunisia
Asia
- Bhutan
- China
- East Timor
- Hong Kong
- India
- Japan
- Malaysia
- Philippines
- Singapore
- South Korea
- Taiwan
- Thailand
- Vietnam
Oceania
- Australia
- Brunei Darussalam
- Cocos Island
- Cook Islands
- Fiji
- Kiribati
- New Caledonia
- New Zealand
- Solomon Islands
Devises autorisées dans les transactions
Le tableau ci-dessous liste les devises de processing acceptées dans les Transactions Carte réglées en EURO.
Le taux de change est communiqué dans un service dédié.
| ISO_CODE | SWIFT_CODE | CURRENCY NAME |
|---|---|---|
| 784 | AED | U.A.E. Dirham |
| 971 | AFN | Afghanistan Afghani |
| 008 | ALL | Albainian LEK |
| 051 | AMD | Armenian Dram |
| 532 | ANG | Netherlands Antillia |
| 973 | AOA | Angola Kwanza |
| 032 | ARS | Argentine Peso |
| 036 | AUD | Australian Dollar |
| 533 | AWG | Aruban Guilder |
| 944 | AZN | Azerbaijanian Manat |
| 977 | BAM | Bosnian Conv. Mark |
| 052 | BBD | Barbados Dollar |
| 050 | BDT | Taka |
| 975 | BGN | Bulgarian Lev |
| 048 | BHD | Bahraini Dinar |
| 108 | BIF | Burundi Franc |
| 060 | BMD | Bermudan Dollar |
| 096 | BND | Brunei Dollar |
| 068 | BOB | Bolivian Peso |
| 986 | BRL | Brazilian Real |
| 044 | BSD | Bahamian Dollar |
| 064 | BTN | Ngultrum |
| 072 | BWP | Pula |
| 974 | BYR | Belarussian Ruble |
| 084 | BZD | Belize Dollar |
| 124 | CAD | Canadian Dollar |
| 976 | CDF | Franc Congolais |
| 756 | CHF | Swiss Franc |
| 152 | CLP | Chilean Peso |
| 156 | CNY | Yuan Renminbi |
| 170 | COP | Colombian Peso |
| 188 | CRC | Costa Rican Colon |
| 192 | CUP | Cuban Peso |
| 132 | CVE | Cape Verde Escudo |
| 203 | CZK | Czech Koruna |
| 262 | DJF | Djibouti Franc |
| 208 | DKK | Danish Krone |
| 214 | DOP | Dominican Peso |
| 012 | DZD | Algerian Dinar |
| 818 | EGP | Egyptian Pound |
| 232 | ERN | Eritrean Nakfa |
| 230 | ETB | Ethiopian Birr |
| 978 | EUR | Euro |
| 242 | FJD | Fiji Dollar |
| 238 | FKP | Falkland Islands |
| 826 | GBP | Pound Sterling |
| 981 | GEL | Georgian Lari |
| 936 | GHS | Ghana Cedi |
| 292 | GIP | Gibraltar Pound |
| 270 | GMD | Dalasi |
| 324 | GNF | Syli |
| 320 | GTQ | Quetzal |
| 328 | GYD | Guyana Dollar |
| 344 | HKD | Hong Kong Dollar |
| 340 | HNL | Lempira |
| 191 | HRK | Croatian Kuna |
| 332 | HTG | Gourde |
| 348 | HUF | Hungarian Forint |
| 360 | IDR | Rupiah |
| 376 | ILS | Israel Shekel |
| 356 | INR | Indian Rupee |
| 368 | IQD | Iraqi Dinar |
| 364 | IRR | Iranian Rial |
| 352 | ISK | Iceland Krona |
| 388 | JMD | Jamaican Dollar |
| 400 | JOD | Jordanian Dinar |
| 392 | JPY | Japanese Yen |
| 404 | KES | Kenyan Shilling |
| 417 | KGS | Kyrgyzstan Som |
| 116 | KHR | Riel |
| 174 | KMF | Comoros Franc |
| 408 | KPW | North Korean Won |
| 410 | KRW | Korean Won |
| 414 | KWD | Kuwaiti Dinar |
| 136 | KYD | Cayman Island Dollar |
| 398 | KZT | Tenge |
| 418 | LAK | Kip |
| 422 | LBP | Lebanese Pound |
| 144 | LKR | Sri Lanka Rupee |
| 430 | LRD | Liberian Dollar |
| 426 | LSL | Lesotho Loti |
| 440 | LTL | Lithuanian Litas |
| 428 | LVL | Latvian Lat |
| 434 | LYD | Libyan Dinar |
| 504 | MAD | Morrocan Dirham |
| 498 | MDL | Moldovian Leu |
| 969 | MGA | Malagasy Ariary |
| 807 | MKD | Macedonian Denar |
| 104 | MMK | Kyat |
| 496 | MNT | Tugrik |
| 446 | MOP | Pataca |
| 480 | MUR | Mauritius Rupee |
| 462 | MVR | Maldive Rupee |
| 454 | MWK | Malawi Kwacha |
| 484 | MXN | Mexican Peso |
| 458 | MYR | Malaysian Ringgit |
| 943 | MZN | Mozambique Metical |
| 516 | NAD | Namibia Dollar |
| 566 | NGN | Naira |
| 558 | NIO | Cordoba |
| 578 | NOK | Norwegian Krone |
| 524 | NPR | Nepalese Rupee |
| 554 | NZD | New Zealand Dollar |
| 512 | OMR | Rial Omani |
| 590 | PAB | Balboa |
| 604 | PEN | Peru Inti |
| 598 | PGK | Kina |
| 608 | PHP | Philippine Peso |
| 586 | PKR | Pakistan Rupee |
| 985 | PLN | Polish Zloty |
| 600 | PYG | Guarani |
| 634 | QAR | Qatari Rial |
| 946 | RON | New Romanian Lei |
| 941 | RSD | Serbian Dinar |
| 643 | RUB | Russian Ruble |
| 646 | RWF | Rwanda Franc |
| 682 | SAR | Saudi Riyal |
| 090 | SBD | Solomon Islands Doll |
| 690 | SCR | Seychelles Rupee |
| 938 | SDG | Sudanese Pound |
| 752 | SEK | Swedish Krona |
| 702 | SGD | Singapore Dollar |
| 654 | SHP | St. Helena Pound |
| 694 | SLL | Leone |
| 706 | SOS | Somali Shilling |
| 968 | SRD | Suriname Dollar |
| 678 | STD | Dobra |
| 222 | SVC | El Salvador Colon |
| 760 | SYP | Syrian Pound |
| 748 | SZL | Lilangeni |
| 764 | THB | Thailand Baht |
| 972 | TJS | Tajik Somoni |
| 934 | TMT | Manat |
| 788 | TND | Tunisian Dinar |
| 776 | TOP | Paanga |
| 949 | TRY | Turkish Lira |
| 780 | TTD | Trinidad and Tobago |
| 901 | TWD | New Taiwan Dollar |
| 834 | TZS | Tanzanian Shilling |
| 980 | UAH | Hryvnia |
| 800 | UGX | Uganda Shilling |
| 840 | USD | United States Dollar |
| 858 | UYU | Uruguayan Peso |
| 860 | UZS | Uzbekistan Sum |
| 937 | VEF | Bolivar |
| 704 | VND | Dong |
| 548 | VUV | Vatu |
| 882 | WST | Tala |
| 950 | XAF | CFA Franc BEAC |
| 951 | XCD | East Caribbean Dolla |
| 952 | XOF | CFA Franc BCEAO |
| 953 | XPF | CFP Franc |
| 886 | YER | Yemini Rial |
| 710 | ZAR | Rand |
| 967 | ZMW | Zambian Kwacha |
| 716 | ZWD | Zimbabwe Dollar |
L'objet transfer
Vue d'ensemble
L’objet transfer permet le mouvement de fonds entre des comptes walletId de la plate-forme. Ce service n’est accessible qu’à partir d’un compte possédant des droits "Plateforme".
Il donne ainsi la possibilité de distribuer les fonds reçus d’un compte "Plateforme" qui initie les transactions depuis l’API vers un compte "Basic" connecté, selon des règles métier spécifiques à l’agent. Chaque opération de transfer est identifiée par un merchantTransferId unique.
Les transferts sont effectués dans cette configuration, à l’initiative de la plateforme, soit directement en complément d’une transaction ou wireTransfer existant, soit manuellement indépendamment de toute action. Ce mode asynchrone étant réservé aux Agents de service de Paiement.
Des frais peuvent être appliqués et affichés sur chaque opération de manière à les afficher sur le relevé de compte du destinataire. Ces frais diminuent le montant brut et rentrent dans le calcul du Montant net.
Les fonds issus de transfers issus d'une Transaction Carte Bancaire, Visa ou Mastercard, sont disponibles à J+2.
Exemple 1 :
Amount = 100
Fee = 30
Le détenteur du compte de destination recevra 70 et constatera 30 de frais sur un montant brut de 100.
Exemple 2 :
Amount = 70
Fee = 0
Le détenteur du compte de destination recevra 70 sans indication de frais.
Vue compte plateforme qui initie les transaction et les transfer
Vue client compte "Basic" qui ne voit pas les transaction mais constate les transfer
Type de transfer
1Mode Asynchrone Manuel (valable uniquement pour les Agents)
La "Plateforme" réalise la transaction pour le compte d’un ou plusieurs bénéficiaires, puis dans une deuxième étape réalise des appels POST /transfer pour reverser les fonds sur les comptes concernés. Le mode asynchrone est donc réalisé après la transaction sous forme de BATCH.
Exemple :
POST transaction -> dans la devise de l’autorisation POST /transfer (1 fois par compte) -> dans la devise de règlement (payout).
Pensez à vérifier le solde disponible lorsque vous faites un mouvement car vous ne pouvez transférer que des fonds réellement disponibles.
2Mode synchrone Auto
Le compte "Plateforme" réalise une transaction en indiquant, avec de nouveaux paramètres, les comptes concernés et leurs parts respectives afin de déclencher automatiquement des appels POST /transfer à la date convenue. Les montants à reverser sont indiqués dans la transaction et donc calculés par l’initiateur.
Exemple :
POST transaction (mt1 pour ss-marchand1, mt2 pour ss-marchand2…) -> dans la devise de règlement (payout)
Exemple :
transfer[] = { "destinationWalletId": "89fe34c9-5731-44bf-8451787e9ad8a72a", "amount": 100 }
transfer[] = { "destinationWalletId": "fe385c40-bbe7-4aec-ae5b0a832241eb73", "amount": 40, "fee": 5 }Veillez à intégrer les frais de services de CentralPay (Interchange ++) dans le calcul des Fees. Vous ne pouvez déplacer qu’un montant net qui laisse suffisamment de fonds pour régler nos frais.
Opérations possibles
Il est possible de réaliser des transferts automatiques lorsqu’ils sont associés aux objets transaction ou wireTransfer. Il est donc possible, par exemple, de faire une autorisation seule (transaction avec capture=0) et d’initialiser le transfert jusqu’à 7 jours après lorsque la transaction passe avec le statut capture=1.
Pour réaliser cette opération, il faut rattacher la source initiale de l’opération réalisée et donc préciser les attributs sourceType et sourceId.
http://ref-api.centralpay.net/plateform#182-create-a-transfer
| sourceId String (36) |
Identifier of the transfer source Required: no Validation: Authorized for merchant |
|
sourceType String |
Currency Required: yes (if the HTTP parameter sourceId is set) Values: TRANSACTION |
transferReversal
Cette fonction vous permet de rappeler des fonds que vous avez préalablement versés sur un wallet.
Cette fonction vous sera utile en cas d’erreur ou si vous avez émis un refund depuis une transaction. En effet, dans ce cas, les fonds sont retirés de votre wallet et vous devrez les retirer à votre tour sur le wallet de votre client.
Des frais peuvent être perçus sur cette opération en utilisant refundFee.
Le montant réalisable dans un transferReversal équivaut à la somme des available et pending disponibles. Cela vous permet d'effectuer un transferReversal avant la date de libération des fonds.
L'objet payout
Les Payouts sont configurables par les profils utilisateurs de type "Légal" dans les attributs de leur compte. Ils peuvent être paramétrés en automatique ou manuel.
Cas des reversements automatique
Le titulaire du compte peut définir la période : quotidien, hebdomadaire (choix du jour de la semaine) ou mensuel.
Le PAYOUT exécute les sommes disponibles à Jour J 0h05.
Exemple d'un reversement hebdomadaire programmé le mardi :
Centralpay exécutera la demande de création du virement (PAYOUT) le mardi matin avec les fonds disponibles (AVAILABLE) sur le wallet jusqu'au mardi 0h05.
Cas des reversements manuels
Les fonds ne sont pas automatiquement reversés et les PAYOUT doivent être déclenchés par son titulaire.
Tout déclenchement manuel de PAYOUT avant 5h00 le matin sera executé pour mise à disposition des fonds.
Dates de reversement
Par défaut les fonds issues d'une transaction par carte bancaire sont disponibles à J+2. Une transaction réalisée le lundi, apparaîtra en "Pending" le lundi et le mardi et passera à "Available" le mercredi. Une date d'Escrow peut influer sur la date de disponibilité des fonds et repousser d'autant leur utilisation.
Règles de PAYOUT
Modification et ajout de l'IBAN par l’agent
Le changement d’IBAN sur un compte Centralpay nécessitent une procédure de vérification renforcée. Chaque titulaire a la possibilité d’en changer les paramètres depuis l’accès sécurisé à son compte.
Une triple validation est requise : Identifiant / Mot de passe, OTP Email, OTP SMS. Cependant, si le titulaire n’est pas en mesure d’accéder à l’interface Centralpay pour réaliser cette opération, l’Agent peut le réaliser à sa place. Le changement d'IBAN s'effectue en suivant ces étapes :
1- Accéder au Compte titulaire
Accéder au compte du titulaire depuis le menu “compte lié”
2- Création d'un nouveau compte
2 – Dans l’onglet “Compte bancaire” cliquer sur le bouton “Nouveau Compte” comme dans l’exemple ci-dessous.
3- Remplir les informations
3 – Saisissez toutes les informations requises, notamment :
- Libellé
- Titulaire du compte
- Adresse du titulaire
- Iban
- Bic
- Devise
- Copie de l’IBAN (cette information est importante car elle permet de vérifier la cohérence de l ’information)
4- Validation de l'IBAN par Centralpay
Une fois ces étapes franchises, la conformité de Centralpay validera les données et activera l’IBAN.
- Si une pièce est refusée, alors un mail détaillant les manquements vous sera adressé
- Si la pièce est acceptée alors le compte bancaire sera créé et apparaitra dans le compte du client.
Le client ou l’Agent à la possibilité de definir un compte comme étant son compte par défaut.
