Two types of entities interact with the "Platform" services :
- User profiles
- Accounts (payment and e-money)
Two types of entities interact with the "Platform" services :
They represent payment or e-money accounts, purpose of the service provided by the Institution.
An account type can either be "individual" or "Legal entity". The accounts are the financial support of the provided operations. They are created once the regulatory enrollment is completed and validated by CentralPay. A user profile is associated to an account for viewing, checking and setting.
Each account can operate according to 3 modes:
They are exclusively used by Payment Service Agents and Business Introducers in combination with "Basic" accounts to which they are connected. Their purpose is primarily to control the transactions flow by distributing the funds for which they are responsible. They are therefore at the initiative of the transactions and they define the transfers to be made to the benefits of the "Basic" accounts. "Platform accounts" can use the API. A Point of Sale (POS) and a contract must have been assigned to them.
NB: the partner is notified of an enrollment status and closing by a HOOK notification. This notification includes: the account holder name, the enrollment code chosen by the partner, the account number giving the ability to make transfers.
They control their own flow of transactions using the API and are directly beneficiaries of the operations they perform.
Doing so, they are responsible for each operation performed and support the operational costs defined by the agent or by CentralPay:
Contrary to "BASIC" accounts, a Point of Sale (POS) and a contract must have been assigned to them.
In this mode, the transfer object is not accessible.
It is thus possible to create an automatic charge and payout profile so that Centralpay collects on each transaction on behalf of its agent.
"Standard" accounts are monthly billed by the Agent but receive their funds directly from CentralPay. "Standard" account Business Introducers receive a commission from Centralpay.
A "Basic" account doesn’t interact with the API and doesn’t allow to initiate transactions. They receive funds for transactions carried out for them by a "Platform" account. They are therefore only the receiver of the "transfer" made by the "Platform" accounts. They are invoiced by the Agent or by CentralPay if a Business Introducer is involved. In both cases, they receive their funds directly from CentralPay.
NB : an account can be :
- "Platform" account: in case of Agents or Business Introducers initiating transactions on behalf of third parties (Basic account).
- "Standard" account: in case of an online store that performs transactions for its own account
- "Basic" account: in case of a sub-merchant of a market place or a Platform
- "Standard" and "Basic" account simultaneously: in case of a specific activity in addition to its participation in a marketplace or a platform
CentralPay allows the association of a large number of operations integrated into the API.
Type of object | Value | Function |
---|---|---|
AUTHORIZATION | Debit | Reservation of funds on the wallet |
TRANSACTION | Credit | Card transaction |
TRANSACTION_CANCEL | Debit | Card transaction cancellation |
REFUND | Credit | Refund a card transaction |
REFUND_CANCEL | Debit | Cancellation Refund card transaction |
DISPUTE | Debit | Chargeback |
DISPUTE_WON | Credit | Cancellation of a Chargeback |
TRANSFER | Debit | Internal transfer between CentralPay wallet |
TRANSFER_CANCEL | Credit | Cancel transfer pending |
TRANSFER_REVERSAL | Credit | Refund of a valid transfer |
PAYOUT | Debit | External transfer to a bank account |
PAYOUT_CANCEL | Credit | Cancellation of an external transfer |
PAYOUT_REVERSAL | Crédit | Remboursement d’un virement externe validé |
WIRE_TRANSFER | Credit | Incoming transfer |
WIRE_TRANSFER_REVERSAL | Debit | Incoming wire transfer cancellation |
CREDIT | Debit | Refund without prior transaction |
CREDIT_CANCEL | Credit | Refund without prior transaction cancellation |
SDD_TRANSACTION | Credit | Transaction between two exterior bank account |
SDD_TRANSACTION_CANCEL | Debit | Transaction between two exterior bank account cancellation |
DEPOSIT | Credit | Adding funds to the wallet |
Example of the holder's detail page on a standard account (connected to the API)
Example of page managing payments on a standard account (connected to the API)
Example of page managing the users connected to a standard account type (connected to the API)
Summary of Available and Forecast Funds
Transfer request screen to an account
Balance of a standard account (connected to the API)
List of unit operations performed on a "Standard" type account (connected to the API)
"Basic" account example, not connected to the API
Failed payments have a different code from zero. These codes are a response to an authorization request made by Centralpay to the cardholder’s bank.
The cardholder’s bank (also called the issuer bank) expresses its refusal on the basis of its own choice and completely independent of Centralpay. Centralpay does not have any additional information if a card is refused and has no way to obtain it.
However, here is a classification of bank return codes:
Code A1 - Repli VADS
The bank refuse the paiement du to the lack of strong autentication (3DS 1.0 or 3DS 2.0).
The transaction needs to be redo with a 3DS system to avoid this code.
Codes 57, 3 and 5
The bank refuses without giving any special status.
It could be a wrong CVV code or some other decision we don’t know about.
This status does not indicate that the bank will not accept the authorization after further attempts.
Codes 4, 7, 14, 15, 31, 33, 34, 41, 43, 54, 55, 56, 59, 63, 76
The issuing bank believes that its client is no longer in possession of the card and that it is a fraud.
Codes 51, 61
The card exceeded the limit.
The card can be accepted again later, the limit being calculated over 7 days, a card can totally be accepted again the next day.
Code 12
The bank refuses without giving any particular status.
This can be :
- Simply an invalid transaction
- A code 75 from the issuing bank (the card's PIN code has been incorrect too many times)
- A wrong CAVV (provided by the ACS during a 3DS authentification)
- A hidden "A1-Replis VADS"
Or some other decision that we do not know about.
The administration and consultation portal, called Backoffice, allows you to visualize and perform a large number of actions.
Here are the ones that are available to Agents administrators.
Dashboard of a "Standard" account
They represent individuals who, depending on their rights, can access one or more payment accounts as well as certain backoffice services. These profiles can be named as “legal” if thye are connected to payment account rights.
Each profile level can receive the specific rights allowing to access dedicated services, as follows:
They access all services available for the connected level and are allowed to make defined parameters updates.
Payment account settings:
Services settings:
Limited read only
NB: it is possible to create as many rights profiles as necessary according to needs.
CentralPay owns 3 types of protection guarantees that may apply to merchants, depending on the nature of their contract :
A fixed sum is paid at the start of the contract in order to cover the credit risk in case the merchant cannot meet his repayment obligations towards his customers.
The detail of the Collateral (deposit sum) is visible from the API protected account area, in the "Payments" tab :
The deposits must expire after 30 days.
In the absence of Collateral, a fixed sum can be taken directly from transactions to guarantee reimbursement to customers if necessary. Therefore, the wallet must exceed the value of the bottom line to authorize outgoing transfers.
The detail of the bottom line (fixed threshold amount) is visible from the API protected account area, in the "Payments" tab :
Depending on the industry and the account settlement process, a rolling reserve may be automatically opened. This is an additional protection guarantee which makes possible to maintain between 5 and 10% of the merchant collection volume on the CentralPay account in order to allow the automatic refunds in case of chargebacks, fraud or in order to cover any operational costs. This sum belongs to the merchant's treasury ; it is kept for a certain number of days to be released (between 90 to 180 days).
The amount of the rolling reserve is visible from the general view of the CentralPay account :
This variable threshold amount is also visible from the API protected account area, in the "Payments" tab :
The term "provision of service" means an activity which does not concern the delivery of tangible material goods, but a particular skill performed by the service provider for remuneration. The VAT applicable to services provided by a French service provider follows the rules of Directive 2006/112/ EC (strengthened on 01/01/2020) and its terms of application.
The payment of VAT for a service provision must be made in the customer's country. For example, a French company selling services to a customer in Germany, must pay VAT at the German rate. To do this, the merchant must identify the destination country of the service. CentralPay makes it possible, based on :
These information are available after exporting account transactions. To find it, the merchant must first carry out a search in the operations tab, then export the results (under CSV, EXCEL, or JSON).
In the exported report, the detail of each operation is represented in the form of spreadsheet lines. Therefore, the information concerning the "card_country" and "card_region" are easily identifiable for each transaction. The aim is to facilitate the bank reconciliation or any other billing item.