What recognition hangs on
The return trip, in practice
- Same browser, already passed: the flow completes almost immediately. This is the skip window on your verification’s configuration; within it, a prior pass counts and the person skips the face check entirely. You still get a fresh token to confirm.
- Member on a new device: the new device has no history, so they start as a fresh guest. At the face check their face is recognized as belonging to a member, and the flow asks them to sign in with their number or email. One code later they’ve re-asserted their claim and they’re through.
- Guest on a new device: there’s no claim to re-assert. Their face matching their old guest record reads as a collision, and the check comes back denied until that record clears. This is the main reason to make anyone who returns a member.
Designing for the return trip
- Re-run the same call. Send returning users through the same
vycheck()orinitializeentry point. A recognized human passes through quickly instead of starting over. - Bind an identity if they’ll come back. Make repeat visitors members by attaching a phone, email, or external id, or by using the collection identity mode. It’s the difference between “recognized anywhere” and “recognized on one browser”.
- Confirm server-side every time. Recognition still produces a fresh token each trip. Always confirm it on your backend before granting access.
Guests intentionally re-verify more often than members. See
Members vs guests for why, and when to
prefer one over the other.