Platform services

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€ A color copy of an Identity document of the holder A second color copy of an Identity document. It can be: ID card, driving license, passport (expiry + 6 months). Failing that, it can be : national security card, latest notice of tax income or latest wage slip. A copy of the IBAN with the same contact details as the holder, with a visible bank name.	> 10K€ Added to the documents already asked : A proof of income collected by the holder : for example, a proof of ownership of the property rented, scripture of buy etc
Individual with status	<50K€ An extract from your local Register (not older than 3 months) or your VAT registration A color copy of an Identity document of the director or the representative A copy of the IBAN with the same contact details as the holder, with a visible bank name.	Between 50 and 100K€ Added to the documents already asked : A second color copy of an Identity document of the director or the representative	>100K€ Added to the documents already asked : Proof of address (less than 3 months)
Legal entity	<200K€ An extract from the Register of Companies (not older than 3 months) or a Certificate of Incorporation (Répertoire Sirène pour les associations) A color copy of an Identity document of the director or the representative The list of the ultimate beneficial owners (name, date and place of birth) A copy of the IBAN with the same contact details as the holder, with a visible bank name. Pour les associations : le dernier PV d’AG et l’extrait du journal officiel constatant sa déclaration en préfecture Pour les associations reconnue d'utilité publique : la copie du décret en Conseil d’Etat reconnaissant l’utilité publique	Between 200 and 500 K€ Added to the documents already asked : The Memorandum of Association and an Article of Association, certified by a legal representative. A color copy of an Identity document for each bénéficiaires effectifs ultimate beneficial owners.	>500K€ Added to the documents already asked : The list of the persons who own 10% or more of the stocks or the rights to vote

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
- Email
- 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

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

Tutorial of the sequential onboarding procedure.

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

Read more about Countrie authorized for the establishment of a relationship

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: 0.2 %
Credit, deferred debit: 0.3 %
Corporate: 0.9 %
Average reported in B2C: 0.23 %

Interregional (rest of the world)

All types of cards: 2.15 %

Card scheme fees

Interregional: 0.34 %
Intraregional (EEA): 0.085 %

Interchange +

Average observed in B2C Europe: 0.31 %
Average observed in B2C outside Europe: 2.49 %

Example for a European transaction:

A prepaid or debit consumer card cost is 0.2 % + 0.085 % = 0.285 %
A credit card or differed debit card cost is 0.3 % + 0.085 % = 0.385 %
A business card cost is 0.9 % + 0.085 % = 0.985 %
A card issued outside the EEA cost is 2.15 % + 0.085 % = 2.49 %
The average cost in Europe is 0.23 % + 0.085 % de card scheme fees = 0.315 %

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.

Read more about CentralPay outgoing costs

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
Note: Transaction's UUID Format

Validation: Authorized for merchant
The status of the transaction must be CLEARED or CAPTURED

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.