Payment device management and integration software

Payment hardware abstraction

One of the main advantages of the platform is that the customer application is independent of the payment hardware installed in the machine.

The server handles the device-specific communications with each peripheral and exposes a higher-level interface to the application.

The architecture can be represented as:

1. Customer application
2. Socket/API
3. Payment server
4. Device drivers
5. Payment devices

Thanks to this separation, the main application can work with logical payment operations without needing to know the details of the protocol used by each device.

Bill validator control

The software integrates and manages banknote acceptors, centralising the operations needed to use them.

The server can handle events relating to banknote detection and acceptance, device states, faults and any other information reported by the peripheral.

The application receives the processed information through the common communication interface.

Coin acceptor control

The platform supports coin changers and coin validators, allowing different devices to be integrated within the same software architecture.

The server interprets the events generated by the acceptor and turns them into operations the main application can understand, considerably simplifying the development of payment logic.

Hopper management

The system controls coin-dispensing hoppers, enabling cash refund or controlled coin payout functions to be developed.

The application can request payout operations through the common interface, and the server executes the corresponding sequence on the physical device.

This brings both cash in and cash out together on a single platform.

Socket-based communication

The customer application and the payment server communicate over sockets.

This architecture decouples the two components and allows the payment server to run as an independent process.

The end application does not need direct hardware access or the device-specific payment drivers; it only has to implement the communication interface defined by the server.

Common API for different peripherals

The abstraction layer provides a uniform interface regardless of the manufacturer or technology used by each payment device.

Operations such as querying device status, enabling or inhibiting acceptance, receiving credit events, requesting a refund or handling a fault can all be exposed through a common API.

This approach makes it considerably easier to evolve the machines and add new peripherals.

Modular architecture

The server has a modular architecture that separates the general payment logic from the specific modules that manage each device.

This makes it easy to add new models of bill validators, coin changers, validators or hoppers without major changes to the main application.

Replacing one peripheral with another compatible model can be confined to the payment server and its corresponding driver.

Developed in C#

The platform is developed in C#, providing an architecture well suited to running on Windows systems on x86 hardware.

The environment supports communications, process management, event logging, configuration and diagnostic tools within a software platform widely used in self-service systems.

x86 and Windows platform

The server is designed to run on x86 architecture under Windows Embedded, making it easy to integrate into the industrial PCs and embedded systems used in automated machines.

The user application and the payment server can run independently on the same system or, depending on the communication architecture implemented, as separate components.

Monitoring and diagnostics

Centralising communications provides a single point from which to monitor the operation of all the payment devices.

The server can collect information on states, events, operations and faults, making diagnostic and maintenance tasks easier.

This information can also be used to implement activity logs and traceability of the operations carried out by the system.

Independence of the end application

The main goal of the architecture is to prevent the customer application from being tied to a particular peripheral manufacturer or model.

For example, the application can request a payment operation using the interface defined by the server, while the server determines how to communicate with the installed hardware.

The result is a more maintainable architecture that makes it easier to evolve the product throughout its life cycle.

Technical specifications