Integration Approaches

Payter solutions currently offer a choice of 4 potential Integration/Implementation approaches, each with specific benefits designed for target markets or other user requirements. A summary of each can be found below, with links to each full specification and supporting documentation.

Regardless of which specific integration method most suits your needs and technology stack, a standardized approach to the generic requirements of any card based payment transaction is additionally documented here which serves as a useful reference guide to payment processing as a general topic.. Further industry specific guidance and best practice guides are then also available under the Industry Use Cases section.

Cloud Payment Services (CPS)

The latest and most powerful modern JSON RESTful API for full integration to all Payter solutions utilising Payter’s own Cloud based routing service, incorporating detailed input/output data flows, tight control over the remote device, and webhook functionality for real-time results and other feedback from deployed Payter devices.

Payter Session Protocol (PSP)

A Payter defined Serial based local integration protocol, accessible via Serial RS232 (P6x only), Serial over USB (Apollo only) or Serial over TCP/IP (P6x and Apollo devices) methods supporting a powerful array of integration options to control the device user-interface and payment processing flow.

MDB - Vending

The most successful and widespread communication standard in the global vending industry, MDB provides an off-the-shelf, plug-and-play solution to implementing cashless payment products on vending and coffee machines of all kinds requiring only the selection of a small number of configuration options.

Standalone Autoscan & Pulse

These options are grouped together as they so often go hand-in-hand, though it is quite possible to utilize Autoscan entirely on it’s own. Commonly used in charitable donation scenarios and any other repeating, fixed value sales environment, Autoscan is simply a configuration to repeatedly be in a “waiting for card” state to process a payment for a pre-configured and often fixed value. It is however possible to provide a variation on this configuration to support a small number of transaction value options for users to select from.

Pulse provides an electrical pulse integration option, allowing for direct Machine to Machine communication to occur with even the simplest and/or oldest host systems.

Other Interfaces

In addition to the main payment integration options, additional interfaces are also available for performing optional tasks. These include:

Apollo User Interface

The Apollo device family incorporates a full-color interactive touch-screen display. Utilising this and Payter’s UI Framework via this API, it is possible for integrators to create custom interfaces to capture data/actions/intent from users including anything from simple button presentation and response triggers, to more complex solutions involving background images, logos and other graphical assets, numerous button formats, layered menus and more.

MyPayter Data API

MyPayter provides a powerful online portal for both remote Terminal Management (TMS) but also payment transaction reporting and analytics. It is however recognised that many users of Payter solutions would prefer to utilise this data within their own or other 3rd party tools. The MyPayter Data API provides a set of capabilities that allow queries or full and regular extraction of the data contained within the solution for an integrators own use cases.

Payter Transaction Host

The Payter Transaction Host (PTH) is a method for handling proprietary cards via Payter terminals. The integrator can implement a CUG (Closed user group) service in the form of a Soap 1.1 host that complies with the PTH protocol defined by a WSDL file. This service once implemented can be used as a closed wallet system without requiring modification to the terminals firmware. The service allows for functions such as adding and deducting funds from propriety cards and checking the available balance. The integrators developed host is then responsible for accepting or rejecting authorisation requests.