Security and Recurring Payments

Security in Get Central is based on hardware-backed encryption and a recurring token issued against the card. This architecture ensures that sensitive card data is protected from the moment it is captured by the PIN pad until it is processed by the authorization network.

The Security Model

All card-present operations rely on a certified PIN pad that acts as the secure entry point for sensitive card data. The device encrypts card information internally before transmission, ensuring that raw card data is never exposed to the POS application or operating system.

The TPVPC establishes a secure communication channel with the authorization host using industry-standard SSL/TLS mechanisms. This channel is fully managed by the TPVPC, including certificate validation and session handling, so the POS application does not interact with cryptographic material or sensitive payloads.

As a result, the POS application never processes or stores Primary Account Numbers (PAN).

Recurring Payments with a Token

For use cases that require card-on-file or recurring billing, Get Central supports a recurring token. It allows future charges to be executed without requiring the physical card or exposing sensitive data.

The recurring token is available only when explicitly enabled and is subject to terminal and merchant configuration by the acquirer.

Recurring Token Lifecycle

The process runs in four steps:

1. Activation

Before registering cards for recurring use, the application must activate recurring mode by calling:

fnDllActivaRecurrente()

This activation lasts for the operating session and must be performed again after each library initialization.

2. First Recurring Payment

The cardholder must be present for the initial registration. The application executes a payment operation using:

cTipoOper = "PAGO"
a valid amount (including zero-value validation if enabled)

If the operation is authorized and the recurring token is enabled, the authorization host returns the token in the XML response.

3. Token Retrieval

The generated token is returned inside the XML response and must be stored by the application for future use.

XML Tag	Description
`<token>`	Reference token associated with the card.

The token is a hexadecimal reference string with no intrinsic value outside the Get Central ecosystem.

4. Payments with the Recurring Token

For future payments, the application executes a payment operation using the stored token. These operations do not require cardholder presence or PIN pad interaction.

Referenced transactions follow the same authorization rules as card-present payments.

Benefits of the Recurring Token

Using a recurring token provides several advantages:

Card data outside the POS: Sensitive card data never enters the POS application.
Improved security posture: Tokens cannot be reversed to obtain card data.
Operational flexibility: Enables subscriptions, delayed charges, and recurring billing models.
Customer convenience: Eliminates repeated card-present interactions.