CentaPay

Last updated

Glossary

Terms this documentation uses, defined from what the platform actually does with them. Where the platform names a field but does not define the concept behind it, the entry says where the value comes from rather than guessing.

Availability. CentaPay is pre-launch. Production is expected in Q4 2026, with sandbox access ahead of it. Coverage differs by market, and the payment methods available differ by market too. The coverage table on our main site is the single source for what is live where, and for current dates. Nothing in this documentation should be read as a service available today.
TermWhat it is here
card_tokenA stored reference to a card, returned when a sale is made with tokenisation. It replaces the card fragment in the Formula 1 variant, so a request that sends a token signs differently from one that sends a PAN.
recurring_tokenReturned in the response and the callback when a sale is sent with recurring_init=Y. Charging it later needs the token, the card's first six and last four digits, and the payer email, because RECURRING_SALE signs with Formula 1 and sends no card fields.
schedule_idIdentifies a schedule the platform runs. It is part of the Formula 4 signature, which is why the digest differs per schedule where Formula 3 does not.
channel_idRoutes a request to a sub-account. Up to sixteen characters, optional, and available on both the acceptance and payout sides.
Sub-merchantAn account beneath yours, reached with channel_id. Settlement is aggregated with sub-merchant reporting.
DescriptorThe statement descriptor, returned on successful transactions. It is what the cardholder sees on their statement.
CascadingAn account setting under which one payment request can produce several underlying transactions. It is the reason a timed-out request must be resolved with GET_TRANS_STATUS_BY_ORDER rather than resent: a blind retry can multiply rather than repeat.
pan_typeDPAN or FPAN, present on wallet transactions only. It says whether the wallet supplied a device account number or the funding PAN.
rrn, approval_code, connector_nameAcquirer-level fields on success callbacks. They are absent unless Extended Data is enabled for your account, under Configuration, Protocol Mappings, "Add Extended Data to Callback". The platform passes these through from the acquirer rather than deriving them.
arnCarried on chargeback callbacks when configured. Like the fields above, it originates with the acquirer.
Extended DataThe account setting that adds the acquirer-level fields above to callbacks. Off by default, so a handler must treat all of them as optional.