desktest.net
guide

Scanner Test Guide

This guide explains what the desktest.net Scanner Test does to your FIS WebScan install, how to read each badge and verdict, and how to fix every failure mode the tool can surface. It also includes deployment notes for IT admins pushing the page to a fleet.

Open the Scanner Test ->

What does the Scanner Test check?

FIS WebScan is FIS's browser-side alternative to the older ActiveX and Java Remote Deposit Capture clients. It is a multi-vendor wrapper for Panini, Canon, Digital Check, RDM, and Epson check scanners. Instead of loading a signed applet, the bank's deposit site talks to a small Windows service that publishes a SignalR endpoint over TLS on loopback port 58080.

The Scanner Test runs the same three-step sequence a real deposit page runs:

  1. Reach the WebScan service. A SignalR negotiate request is sent to https://localhost:58080/signalr, the WebSocket transport is upgraded, then the start message is sent. This step alone tells you whether the service is installed, the FIS CA is trusted, the page's origin is whitelisted, and the WebSocket transport is allowed.
  2. Initialize the scanner. InitScan is invoked; the scanner runs its hardware init and pushes an initialized callback (several seconds on real hardware). GetScannerData then returns the make, model, and serial via a scanInfoRetrieved callback.
  3. Capture a test document. StartFeed is invoked, the page waits up to 20 seconds for an itemScanned event, then StopFeed and Shutdown release the scanner. The front image (a Group 4 TIFF, decoded to a preview in your browser) and the MICR line are shown.

Every request is loopback-only. Confirm in DevTools: every URL hits localhost:58080 and nothing else.

When should I run this?

Reading the results

Each step shows a badge: PENDING before it runs, RUNNING while in flight, PASS or FAIL when done. A failed row expands automatically with the explanation and suggested fix.

When all three steps finish, a verdict card appears at the top. Green check: the workstation is ready. Red X: one step failed, and the card splits the problem into:

The Copy Diagnostic Report button copies a plain-text summary to your clipboard: timestamps, browser, platform, page origin, pass/fail per step, the SignalR diagnosis code, the raw driver response, and (for step 3) whether an image and MICR were received. Paste it into a ticket. It contains no scan image data.

Common failures and fixes

Step 1 fans out into four distinct diagnoses, each with a different fix. Steps 2 and 3 have one diagnosis each.

Step 1 diagnosis: whitelist

Negotiate returned HTTP 401 or 403. WebScan is running and the certificate is trusted; it refused to talk to this origin. WebScan keeps a per-workstation list of allowed origins and rejects everything else.

  1. Right-click the WebScan tray icon (the blue WS badge near the clock) and choose Settings.
  2. Select Origin Domain Settings.
  3. Enter https://desktest.net and click Add Domain.
  4. Click Update, then Yes to restart the service.
  5. Refresh this page and re-run the test.

Add your bank's real deposit origin too. The list is unioned, not exclusive.

Step 1 diagnosis: ws-failed

Negotiate succeeded over HTTPS, but the WebSocket upgrade failed. On Windows 10 and 11 this is almost always Edge UWP loopback isolation: AppContainer-sandboxed apps cannot open sockets to 127.0.0.1 unless the container is explicitly exempt.

Fix it from an administrator command prompt:

CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"

Close every Edge window and reopen. The exemption persists across reboots. On Chromium-based Edge this is rare; check that no endpoint security product is filtering loopback WebSockets.

Step 1 diagnosis: service-unreachable

The negotiate request never got a response. Three causes, in order of frequency:

  1. WebScan is not running. Check the system tray for the blue WS icon. If missing, launch WebScan from the Start menu.
  2. The FIS CA is not trusted by this browser. Chrome, Edge, and IE use the Windows certificate store, which the installer populates. Firefox uses its own store. For Firefox, import C:\Program Files (x86)\FIS\WebScan\certs\FISCA.crt via Settings ... Privacy & Security ... Certificates ... View Certificates ... Authorities ... Import, and tick "Trust this CA to identify websites".
  3. WebScan is not installed. Confirm in Add or Remove Programs.

Quick probe: open https://localhost:58080/signalr/hubs in the affected browser. Trusted page means the service is up. Cert warning means the CA. Connection refused means the service is not running.

Step 1 diagnosis: handshake-failed

Negotiate or start returned a non-2xx response that does not match the whitelist signature. Rare; usually a version mismatch between the WebScan release and the SignalR protocol the page targets (ASP.NET SignalR 2.x, wire protocol 1.5). Capture the diagnostic report and update WebScan to the version your bank currently ships.

Step 2 failure: scanner did not initialize

The hub accepted the connection, but the scanner never fired its initialized callback. Two causes: the scanner is not ready (USB, power, or a stale driver session), or it is not a Digital Check scanner. This build initializes Digital Check (TellerScan / TS-series) scanners; a Panini, Canon, or other model uses a different scanner-type code and will not initialize yet.

  1. Confirm the scanner is powered on and plugged in. Avoid USB hubs.
  2. Unplug and replug the USB cable. Wait for the Windows reconnect chime.
  3. Right-click the WebScan tray icon, choose Exit, then relaunch WebScan from the Start menu. This clears any stale driver session.
  4. Open the Scanner Demo Form shipped with WebScan. If it also cannot see the scanner, the problem is hardware or driver. If the demo form sees it but the test page does not, capture the diagnostic report and file a ticket.

Step 3 failure: no scan produced

StartFeed succeeded, but no itemScanned event arrived within 20 seconds, or the payload did not contain parseable image or MICR data. The most common cause is the obvious one: nobody fed a document. Place a check in the feeder before clicking Run Scan Test and try again. If the feeder pulls the document but the test still fails, the raw itemScanned payload is shown in the expanded row. The payload shape is the load-bearing detail for a support ticket.

For IT admins: deploying to a fleet

Two pieces of state live on each workstation: the WebScan install, and the origin-domain whitelist. The install is pushed via SCCM or your standard packaging pipeline. The whitelist is per-machine and lives in WebScanCapture_Setup.xml under the WebScan program data directory. Pre-populate it so users never see a whitelist failure on first run:

<WebScanCapture>
  <OriginDomains>
    <domain>https://desktest.net</domain>
    <domain>https://your-bank-deposit-portal.example.com</domain>
  </OriginDomains>
</WebScanCapture>

Push it via SCCM, GPO file deployment, or any tool that can write a file and restart a service. Restart the WebScanHub service so it re-reads the config. As a fallback, package a tiny per-workstation tray app that writes the file on first login and exits.

Two pre-flight checks worth automating fleet-wide:

Behind the scenes

WebScan exposes a legacy ASP.NET SignalR 2.x hub at https://localhost:58080/signalr. HTTPS GET to /signalr/negotiate returns a ConnectionToken; a WebSocket opens to /signalr/connect with that token; a final HTTPS GET to /signalr/start flips the connection to "started". After that, every hub call and event is a JSON envelope over the WebSocket. The Scanner Test invokes InitScan, GetScannerData, StartFeed, StopFeed, and Shutdown on the webScanServiceHub, and receives every result as a pushed callback event (initialized, scanInfoRetrieved, startFeedInitialized, itemScanned).

The TLS certificate on localhost:58080 is issued by the FIS Certificate Authority, a root CA the installer drops into the Windows Trusted Root store. Firefox runs its own store and does not see the Windows install, which is the most common cause of service-unreachable in mixed-browser shops.

The test page is static HTML and JavaScript. There is no backend; the diagnostic logic is in app.js in the same directory.