CORE FUNCTIONS

CentralPay provides a powerful payment processing API, enabling you to process multi-channel transactions at local and/or international levels.

If you have any problems, before do a technical support ticket, you can see in user case in doc-api.

Introduction

CentralPay API is a REST based API that allows a fast and easy integration of the payment forms. The API uses HTTP to transport and return all responses encoded in JSON.

To simplify integration and testing, CentralPay provides a sandbox where you can carry out your tests.

Authorisations are simulated in test mode.

Test and production modes can be active at the same time - each mode having separate set of public keys and two API ENDPOINT.

We ensure that the data created in test mode will never reach your customers nor cost you any money.

API ENDPOINT

The following link is the core link used to test the API: https://test-api.centralpay.net/

Presentation

The purpose of this document is to present the features of the CentralPay REST API.

By using our Tokenization service and Token.js, sensitive data will not be handled on your servers. The service is fully secure and simplifies your obligations to comply with PCI DSS rules.

2 integration methods are available:

Push & Pay and Smart Form: Ready-to-use services with automation and pre-integrated functions .
Custom form: A set of tools that allows you to design your own payment form using our Token.js instructions.

Creation of "Customer" and "Card"

"Customer" and "Card" allow you to perform recurring payments and track multiple transactions associated with a unique customer.

Marketplace & Plateforme features

Advanced features to manage marketplaces
Creation of sub-merchants with attributes management
Access to a back office that allows to perform transactions analysis and export the results

This new architecture of the API allows us to continuously improve the platform's functionalities and offer new features such as:

More information on cardholders (issuing country, type of card, category, etc.)
Directing transactions to specific acquiring accounts
Fraud detection
Management of recurring payments
Managing complex business rules
Automation system with templates and prefifined actions.

Glossary

cardTokenId	A dematerialized token of the credit card valid for 5 minutes.
Transaction	An accepted, refused or abandoned credit card transaction made by a Buyer
PoS	A physical, mobile, or online Point of Sale
Customer	A consumer or buyer for which means of payment have been registered
Card	A Payment Card : VISA, Visa Electron, Mastercard, Maestro, American Express, Diners, ...
Contract	A Merchant Contract recognized by the card schemes identifying the transactions perfomed
Wallet	A Wallet storing the monetary value

Service access

The test platform url is: https://test-api.centralpay.net/v2/rest/

This test platform allows you to test all the services explained within this documentation.

CentralPay will provide you with connection logs to execute the existing functions.

Functions

All functions use the « MIME » type: "application/x-www-form-urlencoded".

Functions use the following methods:

HTTP POST method for object creation or update
HTTP GET method for object search

Authentication

CentralPay API uses "HTTP Basic authentication" for authentication. All requests to our API have to be authenticated (provide the username and the password given by the platform) and have to be made over HTTPS.

If you only plan on using Pop-in forms, you only need to use your "API Secret Key".
You can find your Secret Key in your account settings once you log into your account.

HTTP Request

Always use HTTP-Header for serialization formats (user_agent, ...)

The Content-Type (application/x-www-form-urlencoded or multipart/form-data) must be inquire for all the request in the header.

The use of the « Idempotence-Key » field in the HTTP header request allows to authenticate the request that has been sent.

If the same « Idempotence-Key » value is sent again, the request will be considered as already processed and will not be triggered again.

This check allows the merchant to avoid sending duplicate entries.

Note: The key of « Idempotence-Key » is valid for 24 hours.

HTTP Response

In each HTTP Response, the « Request-Id » field is written in the HTTP header.

Note: If you have a specific request to be sent via CentralPay REST API, please provide us with this information.

Test tools

All functions described in the documentation can be executed with a HTML form (See examples provided in the documentation)

In order to test CentralPay services, different tools are available to check the behaviour of the API (example: Firefox Rest Easy plugin).

Searching methods

Searching methods are the same for all objects.

Requests can use either common or specific parameters.

HTTP Request

GET https://test-api.centralpay.net/v2/rest/<type_objet>/<id_objet>

HTTP Response

OBJ Json <type_objet> type

Retrieve a single object

This function allows you to retrieve objects with the object ID.

HTTP Parameters
<id_objet> UUID (36)	CentralPay object ID Required: yes Validation: UUID

HTTP Request

GET https://test-api.centralpay.net/v2/rest/<type_objet>/<id_objet>

HTTP Response

OBJ Json <type_objet> type

HTTP Request

GET https://test-api.centralpay.net/v2/rest/<type_objet>

HTTP Parameters
before Date ISO 8601	Before this date (included) Required: no Exemple : before=2022-07-01T13:00:00.000Z
after Date ISO 8601	After this date (included) Required: no Exemple : after=2022-07-01T13:00:00.000Z
limit Integer	Maximum number of T Required: no Validation: > 0 and <= 100 Note: 10 by default
page Integer	Page number Required: no Validation: > 0 Note: 1st page by default

Event Json Service
eventId String (36)	Event identifier Note: UUID Format
type String	Event type are always linked to an existing object Note: For a list of hooks you can see it here
creationDate String	Creation date Note: ISO 8601
requestId String (36)	Request Identifier Note: UUID Format Request-Id HTTP Response header
object	Event Object Note: Depends of event type, for example it will be a JSON "transaction object" if the event type is "TRANSACTION_CAPTURED"

HTTP Parameters
currency String (3)	currency of the movement Required: no
expectedAvailabilityDateBefore localDate	Before the expectedAvailabilityDate, this date included.Required: no
expectedAvailabilityDateAfter localeDate	After the expectedAvailabilityDate, this date included.Required: no
availableDateBefore localeDate	Before the availableDate, this date included.Required: no
availableDateAfter LocalDate	After the availableDate, this date included. Required: no
status Enum MovementStatus	Arrival date Required: no Validation: PENDING \| PAID \| CANCEL
type Enum MovementType	Payout status Required: no Validation: see the different type in the object.

JSON ATTRIBUTES
movementId UUID	Movement's id
creationDate LocalDate	The date of creation of the movement
currency String (3)	Currency of movement
amount Integer	Gross amount
fee Integer	fee
net Integer	Net amount
description String	Description
expectedAvailabilityDate LocalDate	planned date of avaibility
availableDate LocalDate	real date of availibility
status Enum MovementStatus	Status of the movement Note: PENDING \| PAID \| CANCEL
sourceId UUID	UUID of the original object
type Enum MovementType	type of the movement Note: TRANSACTION \| TRANSACTION_CANCEL \| REFUND \| REFUND_CANCEL \| DISPUTE \| DISPUTE_WON \| TRANSFER \| TRANSFER_CANCEL \| TRANSFER_REVERSAL \| PAYOUT \| PAYOUT_CANCEL \| PAYOUT_FAILURE \| DEPOSIT \| WIRE_TRANSFER \| WIRE_TRANSFER_CANCEL \| CREDIT \| CREDIT_CANCEL\| CUSTOMER_CREATION \| AUTHORIZATION
emissionWalletId UUID	Wallet of emission of the movement Note : used in the actions with a double movement (transfer and transferReversal)