SecureLink by Digital Check® is our special network API, used across many of our TellerScan, CheXpress, and SmartSource model check scanners. It can be used in several different ways, either embedded within the scanner or externally through our SecureLink Appliance; and with new devices or existing ones already deployed.
The guide on this page explains all the different ways that SecureLink works, as well as why a network API is important in a virtual branch environment.
How a “standard” API operates your check scanner
The Application Program Interface, or API, is software that “translates” requests from a computer program into actions that are performed by your scanner. For example, if a financial institution’s teller software says, “Run the scanner now,” the API takes those instructions and turns them into commands that will make the motors turn.
For many years, the default way of doing this was to use an API that was tied to whatever program was running it. The API would be installed on a computer alongside the teller software (or RDC software, etc.), and it would output commands to drive the device. The scanner itself only needed minimal amounts of computing power to process these commands.
While straightforward and effective, this setup has some limitations in certain operating environments, which we will cover shortly.
A network API, such as SecureLink by Digital Check®, is set up to accept inputs using the standard HTTPS protocol. This is streamlined from the full set of commands used in our other APIs, such as the Digital Check API or SmartPVA used on non-network scanners.
There are advantages to this approach for portability and interoperability, which are especially important in virtual branch environments, as we will see below.
Perhaps the most critical part of our network API is that it is not designed to be installed on the computer to which the scanner is connected.
That is because in many virtual network environments, the local workstation is not intended to run software directly — it effectively acts a pass-through for data from a central server. The traditional way of installing a software package on the computer to which the scanner is connected, does not work here.
Instead, the SecureLink 2.0 API runs on a small processor “in front” of the teller workstation. In other words, it either has to be inside the scanner itself (“Embedded”), or on a minicomputer attached to the scanner (“External”). The chart at right explains the difference.
Yes and no. Depending on where the API resides (embedded or external), there may be some differences.
In order to have an “embedded” API, the scanner needs to have extra hardware components built in — specifically, a means to connect to the network (Ethernet, WiFi, or Ethernet over USB), and a CPU and enough RAM to run the API internally. Traditional USB check scanners do not have this by default, just the basic electronics needed to operate the device.
For instance, our TellerScan TS240 and CheXpress CX30 models did not have a version that came with these chips built in, so had to use the SecureLink appliance, an external module. But on our SmartSource line, as well as the CX35-Network and TS250 scanners we use embedded APIs, so you will have different models with different components: For example, the SmartSource Pro Elite (without the extra processor) and the SmartSource Expert Elite (which includes the processor).
You might be thinking: In a virtual environment, it usually works just fine to install the software on the central server and run it from there. In fact, that is one of the big advantages of a virtual setup. Why should it be different for a scanner — why not just run it from the server like everything else?
That is a good question — but there is a reason for it. As you can see in the graphic at right, a check scanner running at full speed outputs a lot of data. The amount of data is reduced quite a bit when the raw images are compressed, but a lot depends on where that compression happens. If it takes place on the server side, all the raw images cross the network at full size, which is not ideal. And if the scanner is capturing images faster than they can be sent out, then the scanner has to slow down to let the network catch up. Taking care of those basic image processing tasks onboard the device side mitigates most of those problems.
There are additional benefits to the device-side approach from a compatibility standpoint, the last point below.
The other big benefit of running the API on the device side is that it is self-contained. And since it can accept browser-based HTTP commands, it does not matter what operating system the host workstation or network is using.
Instead of needing separate APIs and separate commands for Windows, macOS, Linux, and so on — having a universal set of inputs allows the scanner to receive instructions from any device capable of outputting them in standard HTTP format.
We hope this page has helped explain what the SecureLink 2.0 API is and the use-case for a network API.
If you’re interested in using network-enabled check scanners, or if you have any questions about how SecureLink fits into your virtual branch project, please contact us to find out more!
