# HAL Architecture

POS hardware varies by manufacturer, but Getnet's payment software needs to talk to every device the same way. The HAL (Hardware Abstraction Layer) architecture is how Getnet solves that: a fixed contract that any manufacturer can implement. The layers above it never need to know which hardware they are driving.

## What is the HAL architecture

The architecture has four layers, each depending only on the one below it:

1. **SDK PagoNxt** — the SDK that Getnet partners embed in their own applications. It calls hardware functions through two libraries: `libposemv` (EMV processing) and `libposdigital` (general hardware access).
2. **Middleware App** — sits between the SDK and your service. It receives calls from `libposemv` and `libposdigital` and forwards them to whichever manufacturer's service is installed on the device.
3. **`libhalservice`** — the AIDL interface library Getnet provides to manufacturers. It defines every method the Middleware App can call, without defining how those methods work.
4. **Manufacturer Service App** — your implementation of `libhalservice`, package-named `com.pagonxt.hal.platform.service`. This is the only layer that knows about your device's actual hardware.

A request starts at the SDK PagoNxt layer and passes through the Middleware App unchanged. It ends at whichever Manufacturer Service App is installed on that specific device. The response travels back the same path.

## Why the middleware layer exists

Without a shared contract, Getnet's partner applications would need device-specific code for every POS manufacturer they support. The Middleware App removes that need: it calls the same methods regardless of the device. Your Manufacturer Service App is the only place where device-specific behavior lives.

This also isolates changes. Getnet can update the Middleware App or SDK PagoNxt without touching your implementation, as long as you keep implementing the interfaces `libhalservice` defines. Likewise, you can change how your device handles a card read or a print job. This never affects the Middleware App or any partner application above it.

## What your service is responsible for

Your Manufacturer Service App owns every interaction with the physical device: reading cards, printing receipts, driving the beeper and LEDs, reading the camera, and reporting usage statistics. The Middleware App never accesses hardware directly. It only calls the interfaces your service exposes and expects a response in the shape those interfaces define.

The EMV interface follows the same pattern, but with more state. Rather than a single call and response, it runs as a state machine that your service and the Middleware App step through together. See [EMV state machine](/en/pos-manufacturers/core-concept-pos-mfg/emv-state-machine) for that flow.

## Related resources

* [POS Manufacturers Overview](/en/pos-manufacturers/pos-manufacturers-overview) — where this architecture fits in the homologation process.
* [HAL integration setup](/en/pos-manufacturers/first-steps-pos-mfg/hal-integration-setup) — package name, required interfaces, and the binding Intent.
* [Service interfaces reference](/en/pos-manufacturers/reference-pos-mfg/service-interfaces) — every method your service can implement.