Architecture

Get Central (TPV-PC) operates as an intermediary layer between a merchant's local business logic and the Redsys payment infrastructure. This architecture is designed to offload the complexities of hardware management and financial security from the main Point-of-Sale (POS) application.

Get Central supports two primary local integration models: TPVPC Implantado and Slim Pack. Both follow the same core payment architecture, but they differ in how transaction screens, receipt handling, and integration paths are managed.

System Components

The ecosystem consists of three main architectural tiers that work in synchronization to process a transaction.

1. The Merchant Application (POS)

The high-level software where the business logic resides. It is responsible for initiating transaction requests through the Get Central integration layer. The POS application does not handle raw card data, which significantly reduces its security compliance requirements.

In TPVPC Implantado, the POS can operate in a more transparent way and handle merchant-facing messages directly in its own interface.
In Slim Pack, the POS still initiates the transaction flow, but part of the communication and operational flow is handled directly by the library.

2. The Get Central Middleware

This component acts as the "brain" of the integration. It manages the physical connection to the PIN Pad, orchestrates the SSL/TLS handshake with the Redsys hosts, and enforces the business rules defined by the transaction model.

In TPVPC Implantado, the middleware is primarily exposed as a native library, and in the JavaScript integration path it is accessed through the local TpvpcPinPadImplantadoService.
In Slim Pack, the middleware is delivered as a local Windows DLL and follows a more closed model, displaying communication and processing screens and managing receipt printing through the configured default printer.

3. The PIN Pad (Hardware)

The physical device where the customer interacts with their card and enters their PIN. In this architecture, the PIN Pad serves as a secure entry point, encrypting sensitive data at the source before transmitting it through the middleware to the financial network.

Data Flow Lifecycle

A typical data cycle begins when the POS application sends an operation request to the middleware. The middleware validates the request and translates it into hardware-level instructions for the PIN Pad.

  1. Initiation: POS starts the transaction request.
  2. Interaction: Middleware activates the PIN Pad and coordinates the transaction flow.
  3. Encryption: PIN Pad encrypts sensitive data and passes it to the middleware.
  4. Transmission: Middleware opens a secure SSL/TLS channel to Redsys and transmits the payload.
  5. Response: Middleware receives the authorized or denied response and returns a parsed XML result to the POS.

Depending on the integration model, merchant-facing messages and receipt handling may be managed either by the POS application or by the library itself.

Benefits of the Architecture

This architecture provides Decoupled Logic by separating business rules from payment processing for easier software updates and hardware swaps, along with Scope Reduction since sensitive data is encrypted within the PIN Pad, keeping the POS workstation out of scope for many PCI-DSS requirements. Additionally, a Unified Transaction Model keeps the transaction flow conceptually consistent across the supported integration models.

Next Steps

To continue your integration, explore the following implementation resources:

On this page

Architecture