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 internally within the scanner or externally; 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 HTTP 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’ll 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’s 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, doesn’t 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 mini-computer 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 don’t have this by default, just the basic electronics needed to operate the device.
For instance, our TellerScan and CheXpress models don’t 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, 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: 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’s 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’s a good question — but there’s 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 cut down 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 of 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 doesn’t 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 Mac OS 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’s 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 don’t 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’d 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!
