Signature and ID scanning, right from the operator's phone

A collection point that wants customer signatures on intake documents and data extracted automatically from an ID card traditionally needs two pieces of dedicated hardware: a signature pad (like Wacom or Gemalto) and a document scanner. Both cost money, both break down, both mean an extra purchasing and maintenance step for a small or mid-size operator.

VanaGreen replaces both with a single piece of hardware the operator already has: their phone.

Phone-as-signature-pad: customers sign on the operator's phone

The operator's phone links to the tenant once, through a 6-digit code generated from Settings, valid for 10 minutes. Once linked, it becomes a dedicated signature pad: at intake, the operator opens a signature request for the collection in progress directly from the form, hands the phone to the customer, and the customer signs on screen — not on a separate pad, not on paper that then needs scanning. The signature is applied automatically to the NIR and incoming PV, alongside the operator's own signature.

This is a separate feature from the customer signature already added to Annex 2/3 (covered in an earlier post) — part of the same family of intake signature-capture improvements, but a new capture channel: the operator's phone as a dedicated device, not the screen already used for intake.

Phone-as-scanner: ID cards read straight from the camera

The second half of the feature solves another frequent manual step: creating a new individual's record in the system when they show up with an ID card to hand over waste. Instead of typing name, CNP (Romanian personal numeric ID), series and number by hand, the operator photographs the ID with their phone, and the app automatically reads the relevant fields — an OCR engine that runs entirely on the phone, not on a server. The photo itself never leaves the device; only the extracted fields (and, right after, whatever the operator corrects or confirms) go to the server.

Recognition accuracy isn't the safety mechanism here — the confirmation screen is. The operator always sees the extracted data before saving the person's record and can correct it directly, exactly like manual entry, just starting from an already-populated draft instead of a blank form. For older ID cards without a standardized reading zone, the app doesn't even try to guess the name or series — it extracts only the CNP, where it can be identified reliably in the text, and leaves the rest for manual entry, specifically to avoid introducing a wrong value where the risk of error is real.

The first live test, and three bugs fixed the same day

The feature went through a first real live-usage test, which surfaced — and got fixed quickly — three problems typical of any touch interaction on mobile, invisible until you actually hit them in the field:

• Capture stuck mid-flow, with no way to cancel — if the operator tapped "finish" right as the drawn signature hadn't yet finished being recorded internally, the request would get stuck with no recovery other than waiting for the automatic 15-minute expiration. Fixed by retaining the signature in a way that resynchronizes correctly, plus a new cancel button, so the operator never has to wait it out.
• Signature stroke that never closed on pointercancel — on real touchscreens, a drag gesture is frequently interrupted by the pointercancel event (when the OS decides the gesture is actually a scroll or a navigation), not by pointerup. The ink would appear visually on screen, but the stroke never got marked as "finished" — so the signature never actually saved, even though everything looked like it had worked.
• CSP silently blocking the signature conversion — the code that turned the drawing from a data: format into a file to upload to the server used fetch, and the server's content security policy doesn't allow that kind of request for data:. The result: complete failure, with no visible console error, no request reaching the server, no trace in the logs — the hardest kind of bug to catch. Fixed by decoding the data manually, which bypasses that mechanism entirely.

None of the three bugs would have been visible just from reading the code — they only surfaced from real use, on a real phone, with real fingers. That's exactly why live testing matters, not just automated tests, for a feature that depends on how a touchscreen actually behaves.

Why it matters for an operator

For a collection point with no budget for a signature pad and a dedicated scanner, these two features eliminate both pieces of hardware at once — using a phone the operator already carries anyway. And the fact that the feature was tested live and fixed the same day the problems appeared shows exactly what "production-ready" means for a feature like this: not just that it shipped, but that it was verified with real use and brought to a level of robustness that holds up against the unpredictable behavior of a real touchscreen.