Pairing with a Payment Acceptance Device
Pairing a Register to a particular device enables SmartConnect to automatically "know" which device to forward the Transaction requests to. Essentially, the pairing process creates a link between the Register, identified by its unique ID, and the device, identified by a temporary pairing code. The pairing flow is:
The pairing process gets initiated on the device, which will request the temporary pairing code from SmartConnect and display it on the screen. This code has a certain TTL (time-to-live), and may periodically refresh on the device if pairing is not finalized.
The person doing the pairing would input this pairing code in the POS software, and submit it to SmartConnect via the API call.
If successful, the pairing process is now complete and the Register is ready to submit Transactions!
Depending on how each POS system handles integrations, there would typically be a way for setting up each individual integration and this would be the place to have a UI component where the pairing code can be inputted and submitted to SmartConnect. Pairing is commonly a "back-office" function, although some integrations have places the pairing controls on the POS "front-end" as well.
Pairing information is stored in SmartConnect. The POS system does not need to preserve anything - no pairing codes, device IDs, or anything else. After pairing is successful, every Transaction request will be routed to the right device accordingly so long as the Register information (ID and other metadata, explained below) remains the same.
There is no API to unpair, from the POS system. Unpairing is an operation handled by the payment acceptance device. Typically if users need to e.g. move an EFTPOS Terminal from one Register to another, they would initiate the unpairing process on the Terminal directly, then initiate another pairing on the "new" Register.
For Smartpay EFTPOS Terminals, even when doing a physical swap-out of a device (e.g. if it becomes faulty), so long as Smartpay preserves the same internal ID between the old and new device (which is almost always the case), the new device will be automatically paired once switched on.
It is important to understand the cardinality of the relationship between the Register and the payment acceptance device:
One Register can only be paired to one payment acceptance device. Sending a pairing request for an already-paired Register to another device (with a new pairing code) will unpair the previously paired device (so long as the new pairing request is successful, i.e. the pairing code valid).
One payment acceptance device can be paired to many Registers. Multiple registers (with different unique IDs) can send pairing requests to the same device. Each pairing request will be independent (i.e. a separate API call to the SmartConnect server), and use its own temporary code (i.e. pairing will be initiated multiple times on the same device).
In case there are multiple Registers paired to the same payment acceptance device, payment requests will be queued in the order in which the server receives them. Depending on how the SmartConnect client on the device is implemented - it may offer the possibility to unpair an individual register and/or unpair all paired registers at one. As stated before, the POS software does not have any control over the unpairing process.
Having one Register paired to multiple payment devices is not supported by design. This can, however, be worked around by the POS system having one "physical" Register and multiple "virtual" Registers (each having its own unique ID). Each "virtual" Register would be separately paired to a different device, and the POS would have a selector which "virtual" Register to use when initiating a Transaction. Most cloud-based POS systems can be set up this way, however it is not always convenient/easy to switch between Registers, especially when finishing a transaction on a "secondary" device.
More details can be found in the FAQ page.
The full API specification of the Pairing Request can be found in the Pairing section of the API Reference.