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 what “translates” requests from a computer program into actions that are performed by your scanner. For example, if a bank’s teller software says, “Run the scanner now,” the API is what 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 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 is being run (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 RNDIS), and a CPU and enough RAM to run the API internally. Regular 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 do not have a version that comes with these chips built in, so they are all physically the same, but they have to use the SecureLink appliance, an external module. But on our SmartSource line, as well as the CX35-RNDIS 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).
Also worth noting: most network-ready scanners tend to have a built-in Ethernet port, although with an external module, or the emerging use of Ethernet-over-USB (see right), this is not always the case.
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 spits out 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 gets rid of 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 PC or network is using.
That makes a big difference compared to the standard way of using an API. In other words, if the API was installed on the PC, and that PC was running Windows, then the API had to be written for Windows. To be installed on a Mac, it had to be written for macOS X. If the scanner was trying to communicate with an Android device, there would need to be an Android API, and so on.
Instead, having a universal set of inputs allows the scanner to receive instructions from any device using any operating system, as long as it is capable of outputting them in the standard protocol (which most are).
Not only is it much simpler to use and maintain a single API — you do not have to worry about whether we have an API for your particular operating system.
We hope this page has helped explain what the SecureLink API is and why you would use a network API — as well as how SecureLink, the API, is different from SecureLink, the external hardware device, even though they’re commonly referred to by the same name.
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!
