Onboarding
The enrollment service helps CentralPay Payment Service Agents and Business Introducers meeting their compliance and customer knowledge needs.
A number of downloadable documents are required during the enrollment process. These documents will make it possible to carry out pre-transaction customer checks (known as KYC – Know Your Customer), in accordance with the European anti-money laundering law. The list of required documents may vary depending on your country of incorporation.
Therefore Payment Service Agents and Business Introducers have the option of registering their customers in order to enable them to access the payment services they have developed.
To carry out these operations, CentralPay has designed a fully dematerialized enrollment service that can be remotely accessed from a dedicated portal accessible from a mobile or computer.
The enrollment service provides:
- Collection of information and documents related to future account holders.
- Verification of this information as part of our anti-money laundering and terrorist financing obligations.
- The holder’s consent by electronic signature on service general terms of use and the pricing conditions of the Agent (or those of CentralPay for Business Introducers).
Summary of the documents asked and receipt thresholds :
Account status |
Low risk |
Medium risk |
High risk |
Individual |
<10 K€
|
> 10K€ Added to the documents already asked :
|
|
Individual with status |
<50K€
|
Between 50 and 100K€ Added to the documents already asked :
|
>100K€ Added to the documents already asked :
|
Legal entity |
<200K€
|
Between 200 and 500 K€ Added to the documents already asked :
|
>500K€ Added to the documents already asked :
|
The enrollment process
The enrollment process is based on the collection and verification of documents that identify the organization holding a payment account. This process is handled by the onboarding API. It includes a white label portal that facilitates exchanges between the future account holder and Centralpay for the collection of supporting documents. During the enrollment process or during the life of the business relationship, the compliance department may request additional information. These requests will then be sent by Centralpay, either in the form of an e-mail directly to the cardholder, or to the partner's platform in the form of a WebHook if the partner wishes to control the process on its side.
Each enrolment is necessarily preceded by an enrolment request that can be made either through the API or from the Backoffice.
The common core of this application is the pre-submission of known user profile information.
The enrolment request allows the pre-submission of the following elements :
- Preparation of the user profile :
- First name
- Last name
- Phone
- Birth date
- Birth city
- Birth country
- Preparing to choose the type of account :
- Unknown
- Company, association, public sector, ...
- Name of the legal entity
- Seniority
- Cash flow forecast
- Autoentrepreneur, craftsman, shopkeeper, ...
- Cash flow forecast
- Individual
- Cash flow forecast
- Choice of the workflow mode :
- Continuous
- Sequential
This information is used to define the risk class and therefore the necessary information collection. The user can then connect to the portal according to the integration mode chosen by the partner (see below).
Two enrollment modes are available depending on the partner's needs.
The continuous workflow is linear. It ensures that all documents are collected before the payment account is created.
The sequential workflow introduces an intermediate step before the collection of the identity documents, the signature of the TOS and thus allows to create a payment account not active before the collection of the documents. This collection can nevertheless be done in the same process or later if the user does not have them with him. This workflow makes it easier to refer a sub-merchant to a marketplace since no personal documents are required. Sequential wrapping allows for express wrapping and instant wallet allocation.
The partner has the possibility to provide a SIREN number to the enrolment request, allowing an automatic recovery of the data of the legal entity or the individual entrepreneur from the services of the commercial court clerks. This service is faster and frictionless for the user. If the partner does not have the SIREN, the user can enter one on the relevant screen.
NB : If a SIREN is erroneous or does not match with a known reference, the user has 3 tries before switching to a manual mode. In this case, he will have to fill in the different information required by the conformity. In this type of enrolment, the data recompleted by our SIREN call will prevail over the completion of the data relating to the legal entity, throughout the enrolment.
Once the account status is confirmed, compliance performs checks on the account against the information given to verify the account.
If the enrolment is inaccurate at the beginning (especially on the workflow), a new enrolment will have to be done in order to lift the limits.
1/ Continuous Workflow
The continuous workflow implies the collection of all the elements of a file before the validation by Centralpay and the creation and activation of the payment account. All the documents are necessary for the validation and the activation of the account by Centralpay.
A/ Continuous auto enrolment with SIREN
The SIREN is provided before the enrolment starts, if it is correct, a simple data validation is required.
NB : if no SIREN is recognized, the workflow automatically switches to manual mode (scheme C).
B/ Continuous auto enrolment without SIREN
The SIREN is not provided before the enrolment but during the enrolment itself, but the user will be able to indicate it at step 3.
NB : if no SIREN is recognized, the workflow automatically switches to manual mode (scheme C).
C/ Continuous manual enrolment without SIREN
No SIREN is transmitted, before or during enrolment. Data and documents are collected manually. This mode is required for associations, individuals and foreign companies.
2/ Sequential Workflow
The sequential workflow allows the allocation of a wallet number before having to provide the identification documents. The account and the associated wallet thus created have the status of "Non Active" account. It is therefore limited in its uses and does not allow the realization of financial movements. The limits must be lifted by providing the identification elements (KYC) which will be validated by Centralpay compliance.
A/ Sequential auto enrollment with SIREN
The SIREN is provided before the enrolment starts, if it is correct, a simple data validation is required.
NB : if no SIREN is recognized, the workflow automatically switches to manual mode (scheme C).
B/ Enrôlement séquentiel auto sans SIREN
The SIREN is not provided before enrolment but submitted by the user at step 3.
NB : if no SIREN is recognized, the workflow automatically switches to manual mode (scheme C).
C/ Manual sequential enrolment without SIREN
No SIREN is transmitted, before or during enrolment
The two integration modes of the service
CentralPay developed 2 integration modes for the enrollment service :
- Enrollment from CentralPay’s portal :
- Asynchronous mode : the future account holder receives an SMS or email including a link to the portal to finalize the enrollment process that can be completed at any time.
- Synchronous mode : the partner makes enrollment requests from his own forms via the API which provides him an enrollment ID allowing him to display the enrollment portal directly in iframe, pop-in. Therefore, the client proceeds with the process synchronously.
- Asynchronous mode : the future account holder receives an SMS or email including a link to the portal to finalize the enrollment process that can be completed at any time.
- Full enrollment from CentralPay’s API : the partner completely interfaced enrollment API with its own forms.
Webhook notifications
The following enrollment service notifications are available :
- ONBOARDING_ENROLLMENT_CREATED
>> An onboarding request has been generated.
- ONBOARDING_ENROLLMENT_STATUS_UPDATED
>> A change in enrollment status was noted- Partial
- Awaiting validation
- Finished
- Refused
- ONBOARDING_ADDITIONAL_DOCUMENT_REQUESTED
>> Compliance has issued a document request
- ONBOARDING_ADDITIONAL_DOCUMENT_UPDATED
>> Client has updated the requested document
- ONBOARDING_PAYMENT_ACCOUNT_CREATED
>> The account has been created
Onboarding Integration
Some information to keep in mind when integrating the enrollment process via api calls.
Enrollment workflows are evolving!
The workflows depend on the recommendations of the CPR, so they are bound to evolve and change!
(Functioning, order of information requests, etc..)
Enrollment with SIREN
What you need to know about enrollment integration with SIREN:
- First of all the request to register the SIREN must be done first, before the request to create the enrolment
- The uuid of the SIREN is then passed in the enrolment creation request via the "identityBadge" parameter. This allows to determine the appropriate worflow.
- When enrolling with SIREN, the "/complete" is not required !
- On the other hand, the password must always be defined!
Sequential Enrollment
- After the validation of the sequential enrollment, the account and the wallet are created but the wallet is not active.
- In order for the wallet to become active, the first limit lift request must be made.
- Not all limit releases can be done at once, a validation is required for each limit release.
- To know when a limit lift has been validated, a hook is configurable, it is the hook "ONBOARDING_ENROLLMENT_STATUS_UPDATED" which allows to be informed at each status modification of the enrolment and thus when a limit lift has been validated.
Regulations, returns and authorized countries
Countries authorized in regulation
Europe
- Andorra
- Austria
- Belgium
- Bulgaria
- Cyprus
- Czech republic
- Denmark
- Estonia
- Feroe Islands
- Finland
- France
- Georgia
- Germany
- Gibraltar
- Greece
- Greenland
- Hungary
- Ireland
- Iceland
- Italy
- Latvia
- Liechtenstein
- Lithuania
- Luxembourg
- Republic of Macedonia
- Malta
- Man (Isle of)
- Monaco
- Moldova
- Netherlands
- Norway
- Poland
- Portugal
- San Marino
- Slovakia
- Slovenia
- Spain
- Sweden
- Swiss
- Turkey
- United Kingdom
- State of Vatican City
Africa
- Benin
- Burkina Faso
- Cameroon
- Cap-Vert
- Congo (Republic of the Congo)
- Comoros
- Djibouti
- 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
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
- Uruguay
- United States Virgin Islands
Currencies authorized in transactions
The table below lists the processing currencies accepted in the card transactions settled in Euro. These same currencies will be open for Dollar settlement from the first semester of 2019.
The exchange rate is communicated in a dedicated service.
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 |
Countrie authorized for the establishment of a relationship
We can establish and open payment accounts for natural or legal persons from all countries of the European Economic Area provided that the account holders or directors are able to provide proof of identity in Latin alphabet.
For the moment, we do not accept entering into relationship with natural or legal persons from the United States of America.
Costs of services
CentralPay's service costs are divided into 3 categories:
- Interchange fees related to credit card transactions
- Technical costs per operation
- CentralPay operating costs
Interchange ++ fees
The interchange is the value charged by the issuing institution of a credit card (the customer's bank) to the acquiring institution (Centralpay).
The Card Scheme Fees correspond to the fees taken by the Cards networks (Visa, Mastercard, CB) to make the service work.
They are named as follows:
INTERCHANGE +
Interchange fees + card network fees (card scheme fees).
INTERCHANGE ++
Interchange fees + card network fees (card scheme fees) + CentralPay operating costs
Centralpay's business model is “INTERCHANGE ++”
Since December 2015, interchange has been standardized in Europe. Outside the European Economic Area, costs are higher and less homogeneous.
Interchange fees:
Intraregional (EEA)
- Débit, prepaid CB, VISA, MASTERCARD : 0,2 %
- Crédit, differed debit CB, VISA, MASTERCARD : 0,3 %
- Corporate CB: 0,9 %
- Corporate EU VISA : 1,65 %
- Corporate EU MASTERCARD : 1,5 %
- AMERICAN EXPRESS : 1.6%
Interregional (non EEA)
- Débit, prepaid CB, VISA, MASTERCARD : 1,15 %
- Crédit, differed debit CB, VISA, MASTERCARD : 1.5 %
- Corporate VISA ou MASTERCARD : 2 %
- AMERICAN EXPRESS : 2,4%
Card scheme fees (EEA)
- Intraregionale CB: 0.034% + 0.05 €
- Intraregionale VISA : 0.034% + 0.05 €
- Intraregionale MASTERCARD : 0.067 % + 0.10 €
Card scheme fees (non EEA)
- Interregional fee on VISA : 1,04 % + 0.15 €
- Interregional fee on MASTERCARD : 0.75 % + 0.35 €
Calculation of interchange fees
In order to allow the "Platform" account to know the possible costs of a Card transaction, CentralPay provides the card details in the JSON (Javascript) of the Card object:
europeanEconomicArea = False / True
If the card was issued from the European Economic Area, then the Intraregional interchange rules apply.
CommercialBrand
- VISA
- MASTERCARD
- AMEX
- OTHER
CardType
- DEBIT
- PREPAYED
- CREDIT
- DIFF_DEBIT
Region
- US
- CANADA
- EU
- ASIA_PACIFIC
- LATIN_AMERICA
- CEMEA
ProductType
- CONSUMER
- CORPORATE
TIP: to know the cost of a transaction, proceed as follows:
- Once received cardTokenId, make a GET to get the information from the card
- If europeanEconomicArea = False, the transaction is INTERREGIONAL and the maximum rate applies, be 2.49%
- If europeanEconomicArea = True, then calculate the value of the Type and Product type
- If type = prepayed or débit and productType = consumer then the cost is 0.285%
- If type = differed debit or credit and productType = consumer then the cost is 0.385%
- If productType = corporate, then the cost is 0.985%
Example of a JSON return from the Card object:
"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",
},
Technical fees
CentralPay charges a unit VAT expense on each transaction in or out of its "Platform".
Credit card transaction fees
Unit fees per transaction: 0.15 €.
These fees include the following costs: authorization fees, capture, costs, clearing fees, 3DS charges, anti-fraud charges, SMS fees.
Refund charges
Unit fees per operation: 0.50 €
Cancellation fees
Free
Inward and outward transfer fees from the SEPA zone
Fees by outgoing transfer: 0.15 €
CentralPay outgoing costs
CentralPay invoices its "Payment Service Agents" for running costs based on the volume of transactions in a given month.
The transfer object
Overview
The Transfer object allows the fund transfers between walletId accounts of the platform. This service is only accessible from an account with platform rights.
It gives the possibility to distribute the funds received from a "platform" account that initiates transactions from the API to a connected "Basic" account, according to business rules specific to the agent.
The transfers are made in this configuration, at the initiative of the platform either directly in addition to an existing transaction or WireTransfer, or manually independently of any action. This asynchronous mode is reserved for payment service Agents.
Fees can be applied and displayed. On each operation so that they are displayed on the recipient's statement of account. These fees decrease the gross amount and get injected in the calculation of the net amount.
Funds from transfers resulting from a Credit Card Transaction (Visa or Mastercard) are available on D + 2.
Example 1:
Amount = 100
Fee = 30
The destination account holder shall receive 70 and will be charged of 30 fees on a gross amount of 100.
Example 2:
Amount = 70
Fee = 0
The destination account holder shall receive 70 without fees explainations.
Platform account View that initiates transactions and transfers objects
Customer basic account View that does not access transactions but can consult transfers objects
Transfer types
1Manual Asynchronous Mode (only available for agents)
The "platform" account carries out the transaction on behalf of one or more beneficiaries, then during a second stage makes POST-/transfer actions to pay the funds on the dedicated accounts. The asynchronous mode is then triggered after the transaction as a BATCH.
Example:
Post Transaction -> In the currency of the post transfer authorization (once per account)-> in settlement currency (payout).
Check the balance available when you make a transfer because you can only transfer funds actually available.
2Auto Synchronous Mode
The "platform" account carries out a transaction by indicating, with new parameters, the dedicated accounts and their respective parts in order to automatically trigger POST/transfer actions on the agreed date. The amounts to be reversed are indicated in the transaction and therefore calculated by the initiator.
Example:
POST transaction (mt1 for ss-marchand1, mt2 for ss-marchand2…) -> in settlement currency (payout)
Example:
transfer[] = { "destinationWalletId": "89fe34c9-5731-44bf-8451787e9ad8a72a", "amount": 100 }
transfer[] = { "destinationWalletId": "fe385c40-bbe7-4aec-ae5b0a832241eb73", "amount": 40, "fee": 5 }
Integrate the CentralPay service fees (Interchange ++) into the fees calculation. You can only transfer a net amount that has enough money to settle our expenses.
Feasible Operations
It is possible to realize automatic transfers when they are associated to transactions or WireTransfer objects. It is therefore possible, for example, to make a single authorization (transaction with capture = 0) and to initiate a transfer up to 7 days after when the transaction status turns to capture = 1
To perform this operation it is necessary to link together the initial operational source carried out and thus to specify the sourceType and sourceId attributes.
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
This feature allows you to recall funds that you previously paid on a wallet.
This feature will be useful in case of an error or if you have issued a refund from a transaction. Indeed, in this case, the funds are withdrawn from your wallet and you will have to pull them off in your turn on the wallet of your client.
Charges may be incurred on this operation by using refundFee.
The achievable amount in a transferReversal equate to the sum of your available and pending. This allows you to make a transferReversal before the funds releasing date.
The payout object
Payouts are configurable by the user profiles of type "Legal" in the attributes of their account. They can be set automatically or manually.
Scheduled Payout
The account holder can define the period: daily, weekly (choice of the day of the week), monthly. The PAYOUT wire the funds available at D-1.
Example for a weekly PAYOUT on tuesday :
The Tuesday, Centralpay will wire the funds avalaible untill D-1, the Monday 23:59:59.
Manuals Payout
The funds are not automatically returned and must be triggered by the holder.
Payout dates
By default funds from a credit card transaction are available at D + 2. A transaction made on Monday, appear in "pending" on Monday and Tuesday and will change to "Available" on Wednesday. An Escrow date can affect the date of availability of funds and push their use accordingly.
PAYOUT rules
Modification and addition of the IBAN
The Centralpay account's change of IBAN require a stengthen verification procedure. Each holder has the possibility to change these parameters from the protected area of their account.
A triple validation is required : Identifier / Password, OTP Email, OTP SMS. However, if the holder is not able to access to the Centralpay interface to change the IBAN, the Centralpay Agent can do it for them. The IBAN change can be completed by following these steps :
1- Access to the holder account
Access to the holder account from the "Linked account" menu
2- Create a new Bank Account
In the tab “Bank Accounts” click on “New Bank account” as the example below.
3- Complete the informations
Complete all the required informations :
- Title
- Owner name
- Owner address
- Iban
- Bic
- Currency
- A copy of the Iban (this information is important beacause it helps Centralpay to judge of the consistency of the information provided)
4- The validation by Centralpay
Once these steps completed, the conformity department of Centralpay will check the informations and activate the Bank account.
- If a document is declined, an email with the problems explained will be sent to you
- If the document is accepted, the account will be created and added to the customer bank account
The customer or the agent have the possibility to set the account as the default account.