01
Scope the site
A survey of the counters, gates or fare lines, the size of the roster to be enrolled, and the switch or controller already in place. The output is a terminal count and an integration list, not a quote for a platform.
Deployment tracks
One palm-vein engine, two deployment tracks.
The reader, the 512-byte template and the matching engine do not change between a supermarket counter and a factory turnstile. What changes is the system that acts on the verified result. Pick the track that matches what you already operate.
- Tracks
- 2
- Verification
- sub-1.0 s
- Throughput
- 40+/min
- Template
- 512 B
The two tracks
Shared engine
Identical up to the verified result.
Optics, capture envelope, the Frangi vessel filter, the 512-byte template and the matching engine are the same hardware and the same code in both tracks. They diverge only at the last step, where the result is handed to a payment switch or a gate controller.
700-900nm
capture window
512B
irreversible template
5-15cm
contactless hover
+/-25deg
rotation tolerance
| Dimension | PalmPay POS | SecureAccess |
|---|---|---|
| What the verified result triggers | An approved payment event on the POS | A turnstile unlatch and an attendance record |
| Matching mode | 1:N against the enrolled store roster | 1:N against the enrolled site roster |
| Latency budget | Sub-2 s complete payment cycle | Sub-1.0 s gate verification |
| Throughput target | 40+ per lane per minute | 40+ per gate per minute |
| Integration surface | UPI switch, POS terminal SDK | Access controller, HRMS attendance |
| Where the reader sits | Customer edge of the counter | Turnstile pedestal or door frame |
| Fallback when a read fails | UPI QR or card, same terminal | Card or supervisor override |
| Who enrols the user | Store staff at the counter | HR during onboarding |
From track to deployment
Four stages, whichever track you pick.
The sequence does not change between retail and enterprise. What changes is who signs off at each stage, and which system receives the verification event at the end.
02
Enrol the roster
One supervised capture session per person. Each palm resolves to a 512-byte irreversible template under AES-256-GCM, and the raw near-infrared frame is purged on the edge unit as soon as the template is derived.
03
Integrate the result
Verification events reach your POS, access controller or switch over TLS 1.3, each carrying a single-use token. SDKs cover Linux, Android and Windows, and matching runs on the terminal, so the decision does not wait on a round trip.
04
Run the pilot
Six months against an agreed success metric. The existing credential stays live alongside the palm for the first weeks, so the two records can be reconciled before anything is retired.
6months
standard pilot term
1-25+
terminals per site
0
raw biometric images retained, at any stage
Next step
Tell us what you operate.
Counters, gates, branches or fare lines. Send the count and the systems they run on, and we will come back with a scoped pilot rather than a brochure.