The Integration Process
As explained in the What is SmartConnect page, SmartConnect is a cloud based platform. From the point of view of a POS system - this means that the POS software never communicates with the device directly, it will always send an API request to the cloud API endpoint, which will then forward the request to the right payment acceptance device.
This simplifies the integration process on many levels:
There are no dependencies to be installed or managed. Integrating with SmartConnect requires no SDK to be bundled with the POS software, and no drivers or DLLs or applications to be installed on the host machine running the POS software. The entire communication between the POS system and SmartConnect is made using RESTful API calls.
There is no need to handle unnecessary exception cases. Developers familiar with integrating to a specific EFTPOS Terminal directly will know the pain of handling all the possible things that could go wrong - power failure, connectivity loss, etc. This is all handled by the SmartConnect cloud engine and the corresponding SmartConnect client running on the device. As far as the POS software goes - a simple payment request is sent, and it is either successful or not, with the relevant metadata or error information in the response.
Simplified network architecture. In order for the SmartConnect integration to work, neither the host machine running the POS software nor the payment acceptance device need to "know" about each other in the local network (i.e. save each others' IP addresses or have direct ping visibility). In fact, they can be on completely separate networks, which is not an uncommon scenario in many production sites - e.g. a desktop/tablet machine using WiFi and an EFTPOS Terminal using its own mobile connection. This makes configuring the network/firewalls much easier. Both the POS host machine and the payment device need to have Internet access to the SmartConnect host (which should be white-listed in closed networks) using standard ports - the POS host machine needs to use HTTPS (port 443) and the EFTPOS Terminal TCP port 80.
Integration Flow
The integration process consists of two steps:
Pairing. Before a transaction can be made, a register needs to be paired to a payment acceptance device (typically an EFTPOS Terminal). This way, once a Transaction has been initiated - SmartConnect automatically knows which device to forward the Transaction to. The process is explained in more detail in the Pairing with a Payment Acceptance Device page.
Transactions. Once the register is paired to a payment acceptance device, it can send Transaction requests to request for payments. The API to achieve this is explained in more detail in the Initiating a Transaction page.
The concept of a Register is important here. A Register is defined as a uniquely identifiable entity that can request for payments. Usually this would be a single physical device (desktop/tablet/etc.) used by one or more operators within a Store (as a physical location). Different POS systems have different hierarchies in place (usually along these lines: Company -> Store (Site/Outlet) -> Register), and call it by different names (other commonly used terms would be Location or just POS), but the concept of a Register is always present.
Important
It is important that a Register has a unique identifier (at least for integration purposes), in the entire domain of the POS Vendor. In other words, each Register in every Store across the entire base of merchants/customers the POS Vendor works with - must have its own unique ID. A GUID is a good choice for this ID, although any ID-issuing system the POS Vendor chooses to use will work fine, so long as the uniqueness is guaranteed.
Note
If two Registers share the same ID, this will cause issues with pairing and transacting. If pairing a device to one register causes another to be unpaired, this is the most common root cause.