The API is composed of objects allowing to realize specific operations according to needs. The complete list is available here https://ref-api.centralpay.net/.
The most used objects are listed below:
The Cardtoken object is an object that represents the "tokenized" payment card (as a token) that will be used to initiate a transaction.
The transaction object allows to debit your customer from his payment method, usually a credit card, using the cardTokenID that has just been created or from a customer object if it has been previously registered. During a transaction with a cardTokenID, a card object is returned as a cardID.
enrollement this object allows to check is the card matches with the 3D Secure 1.0 protocole.
The Card object represents the sustainable dematerialization of a payment card. It can be associated with a Customer object to allow recurring payment, setting up a subscription or a 1-click payment.
A Customer object represents your customer as a logical entity and allows to consolidate all of its activity.
A refund object represents a refund from an existing transaction. This function is accessible once the transaction status is under "cleared" status.
The refund object allows you to refund a transaction already debited. You can refund a transaction partiallly or totally. The credit will appear on your client’s card between 3 to 5 working days after the process.
A refund cannot cannot be cancelled once it is done.
This process is doable from the Backoffice (transaction details) or from the API thanks to the refund object.
The Subscription object allows you to define recurring payment cycles on one of your customers. They are defined by setting a subscription model:
- Interval unit (day / week / month)
- Interval count (distance between two interval counts)
- Interraction count (number of times the cycle is repeated)
The Installment payment object allows you to split an amount into several operations according to a defined intervalUnit, a starting date and potential charges.
You can manage payment sequences with a great agility, for example:
100 euros are charged during the transaction, then 4 payments of 300 euros for 4 months from a defined date.
The Hook objects generate "Events" that are addressed to your information system according to the status of the object with which they interact.
If you want to control the mode of transaction acceptance on the "Platform", you can use the acceptance rule engine object.
According to the data context of an incoming transaction (card type, amount, country, currency, anti-fraud score) you can define the action to perform:
- Request for OTP (code send by email or sms)
- Request for 3DS
- Request for conditional 3DS (normal transaction if the card is not 3DS)
There are more than a hundred rules available. You can also embed values / data in the rules and use them in a transaction.
A PaymentClaim is a payment request that wil be sent by email ou SMS to a customer to pay a transaction.
This object can only be used from an account that has the "Platform" authorization, which is itself a Payment Service Agent. It makes possible to distribute the funds received for a customer from a "Platform" account to the "Basic" account connected according to specific business rules to the Agent.
The transfers are done in this configuration, manually at the initiative of the agent or automatically since instructions given to Centralpay in the transaction.
This object is used to initiate an external transfer to a registered IBAN account beforehand.
The WireTransfer object allows you to set up the incoming transfer receipt in order to address them directly to a specific account.