Two types of entities interact with the "Platform" services :
- User profiles
- Accounts (payment and e-money)
Accounts typology
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:
"Platform" accounts
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.
"Standard" accounts
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:
- Service fees
- Costs per transaction
- Transfer costs
- Cost per account
- Chargeback
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.
"Basic"
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
Different operation types and account transfer
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
Bank authorization return codes
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:
DSP2 and Soft decline
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.
Generic bank refusal
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.
Suspicion of card fraud or theft
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.
Credit exceeded
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.
Invalid transaction
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.
Backoffice
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.
- Account : list of all the operation in your account as well as your wallet content
- Card transactions :
- Dashboard : a synthesis about the statistics of your account
- Search : Allows you to search and export all the movement in your account and its child
- Cards : all your saved cards.
- Customers : all your saved customers.
- Refunds : all your refunds.
- Disputes : all your disputes.
- Statistics : statistics about your transactions, authorizations, debits, refunds and disputes.
- Payment Request : All the payment request, with the possibility to create new ones.
- Search : access to all your information and the possibility to do precises search about these subjects :
- Operations : all the operations in your account.
- Balance : Balance of your account, with all the operations by date.
- Provitional : provisional of your account.
- Advanced : allow you to search within the Installment Payment, the subscriptions, the wire transferts, the credits and the 3DS enrollment.
- Export : allows you to exports all yoour operations.
- Logs : allows you to consult all the events and request logs of your account.
- Configuration :
- Subscriptions : allows you to manage the subscription models and to configure your subscriptions.
- Installment payment : allows you to configure your installment payment.
- Actors : allows you to manages and configure the actors of your account
- Charge : allows you to manage and configure the charge profils of your account.
- Hooks : allows you to manage your hooks
- Wire transfers : allows you to see and manage the actors that will sent to you wire transfers
- Points of sales : allows you to manage your point of sales
- Payment confirmation email : allows you to manage your payment confirmation mails. emails
- Push & Pay : allows you to manage your profiles, scenario and Settings forms
- Security :
- Users : management of the API roles of your Users
- Acceptances : allows you to create and manage the rules of payment acceptance
- allows you to access to the blacklists and whitelists
- Help & Support : Consumer and technial ressources, and the contact with the technical and consumer support teams.
Dashboard of a "Standard" account
User profiles
User profiles typology
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:
Administrator:
They access all services available for the connected level and are allowed to make defined parameters updates.
Payment account settings:
- IBAN update
- Adding a new user
- Change of payment terms mode
- Company document update
Services settings:
- Acceptance rule engine
- Hooks settings
- …
"Basic":
Limited read only
NB: it is possible to create as many rights profiles as necessary according to needs.
Principle of guarantee
CentralPay owns 3 types of protection guarantees that may apply to merchants, depending on the nature of their contract :
Collateral
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.
Bottom line
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 :
Rolling reserve
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).
For example, the variable threshold amount of the rolling reserve is 5% of the volume received over 90 days. The daily calculation of the reserve amount is : amount of transactions received during the last 90 days * 5%
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 :
Principle of guarantee and VAT to the policyholder
Principle of VAT to the policyholder
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 :
- card_country = the country of issue of the card
- card_region = the card issue area (EU, non-EU)
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.