Add palm recognition to the web system you already use.
PalmVein01 connects to a Windows computer by USB. Your web application calls a Windows C++ background service, and that service manages palm-scanning instructions through the X-Telcom SDK.
Device integration layer Local or server matching
Choose by architecture Customer-controlled data
Your infrastructure
Can a browser control PalmVein01 directly?
The answer determines how the solution should be built.
There is no direct Web SDK.
The browser does not call the PalmVein01 biometric SDK or manage the USB scanner by itself.
Build a Windows bridge with the C++ SDK.
Your development team creates a Windows program and runs it as a background service. The web application sends business instructions to that service. The service translates them into scanner-level actions and returns the outcome to the web workflow.
Three layers, one controlled workflow.
The web layer controls when palm recognition is required. The service layer controls how the scanner performs it.
Web application
Manages the interface, user journey and business decision. It sends an instruction when enrollment or identification is required.
Windows C++ service
Receives the web request, invokes the X-Telcom SDK and manages the palm-scanning instructions.
PalmVein01
Captures the palm information required by the configured enrollment or identification workflow.
Keep matching local, or run it on your server.
"Where does the match happen?" is the most useful question when selecting the deployment model.
Match on the Windows device
The local Windows environment performs the biometric match. If several devices must recognize the same users, a local server can transfer enrolled feature data between them; that server distributes data and does not perform the match.
- Up to 10,000 enrolled users per local device
- Matching remains on the Windows device
- The local capacity cannot expand beyond 10,000 users
Match on infrastructure you control
Use a customer-owned server or private cloud when the platform needs centralized matching, several locations or a larger enrolled population.
- Under 10,000 users: small-model architecture can be used
- Above 10,000 users: migrate to the large-model architecture
- X-Telcom does not manage the customer's biometric data
What happens after the user clicks "Start palm scan"?
Web request
The application requests enrollment or identification.
Service call
The Windows service receives the instruction.
Scanner action
The service manages PalmVein01 through C++.
Biometric match
The configured local or server architecture performs matching.
Workflow continues
The result returns to the web application.
Which route fits your project?
Palm vein scanner web development questions.
Can PalmVein01 be integrated directly into a web page?
No direct Web SDK is currently provided. On Windows, developers can build a C++ background service for the web application to call.
Who controls the scanning process?
The web application controls the service-level request. The Windows background service manages the palm-scanning instructions and device communication through the SDK.
Does a local synchronization server perform matching?
No. In the local matching architecture, the server can transfer enrolled feature data from one device to another. Each Windows device performs its own match.
Can feature templates be moved directly to the large model?
No. Preserve the original palm-print and palm-vein images so the system can generate features for the large-model architecture without requiring users to enroll again.