- The check runs at the action, not at signup. The account already exists. The check sits in front of the checkout, the payout, the survey completion or the drop, and the action completes once it settles.
- People you have already verified are recognized. Most of them go through without scanning again, so the friction lands on the people you have not seen before.
- The limit matches the action. Once per lifetime for something meant to go once per person, once per period for a weekly payout, unlimited for a checkout where you only need a live human present.
- Put it where the incentive is. A face scan in front of a one dollar survey costs you completes, because there is another survey paying a dollar that does not ask. The same scan in front of the payout does not, because the person is about to be paid and has a reason to finish it.
- The outcome is yours to set. Block turns the second attempt away. Allow + flag lets it through and records it for your team.
How you start
- Create a verification for the action. One workspace runs several at once, each with its own settings, so a payout gate can be strict while a checkout stays light.
- Set Verification limit to match the action.
- Set On collision to Block where one per person is the rule, or Allow + flag where a duplicate is a judgement call.
- Put it in the flow. Paste the no-code link, or use the SDK and confirm the result on your server before the action completes.
- Run it on test keys first, and watch the completion rate on the first batch before you widen it.
Next steps
One-time passwords
A worked example, with setup for four survey platforms.
Configuration
Set what the check does.
Integration
The no-code link, or the SDK.
Guests and members
How recognition carries across your checks.