> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/configure/advanced-configuration/enrolment-form/enable-email-check-in-on-enrolment-forms.md).
# Enable Email Check-in on Enrolment Forms
Check whether a customer already exists by email, then secure access with optional verification before a pass is issued.
Most enrolment forms are filled in by people who are already customers. Someone who joined a loyalty programme two years ago, changed phone, and now scans a QR code in store has no memory of having an account, and no reason to think the form is asking them to create a second one. Without a check, that is exactly what happens: a duplicate profile, a second pass, and a points balance split across two records that support has to merge by hand.
Email check-in prevents that. It puts the email address first, before anything else is collected, and uses it to decide which journey the customer is on. A recognised address continues as a returning customer. An unrecognised one continues as a new registration. The customer sees one form either way.
Because an email address alone is not proof of ownership, recognising someone is not the same as letting them in. A returning customer is asked to confirm the address before the existing profile and its pass are handed over.
Real-world examples
* A retailer runs an in-store QR campaign. Half the people who scan it are already in the loyalty programme; email check-in returns their existing pass instead of creating a second one.
* A brand migrating from a plastic card scheme lets customers claim their existing account by email rather than re-registering from scratch.
* A programme with high-value benefits requires a verification code on every check-in, so a mistyped or guessed address cannot surface someone else's balance.
* A campaign form asks only for an email address, and collects the remaining fields only when the address is new.
## How the journey branches
The form opens with a single email field. When the address is submitted, The Wallet Crew looks for a matching customer profile and the journey branches.
If no profile matches, the form continues as a normal registration: the remaining fields are collected, a profile is created, and the pass is issued at the end of the flow.
If a profile does match, the customer is challenged to prove the address belongs to them. The challenge is sent by email, either as a one-time code to type back into the form or as a link that returns the customer to the flow already authenticated. Once the challenge succeeds, the existing profile is reused and its pass is issued or re-issued, rather than a new record being created.
{% hint style="info" %}
Identification is not consent. Recognising a returning customer says nothing about whether they agreed to marketing. Consent is collected explicitly, and separately, on the form.
{% endhint %}
## What has to be in place first
Email check-in depends on three things being configured on the tenant.
An **email provider** must be connected, because the challenge is delivered as an email. Any of the supported providers works; the relevant journey is the challenge email that authenticates a customer with a verification code or a link. Without a provider, the check-in step can recognise a customer but cannot complete the challenge.
The **security configuration** carries the two settings that govern the behaviour. `accountChallengers` declares how a customer may be challenged, and `checkInSecurityMode` determines how strictly the check is applied. `checkInSecurityMode` is set to full by default, which is the safe starting point: a matched profile is never released without a successful challenge.
The **enrolment form** must run a flow that includes the check-in step. Forms are configured from Settings → Enrolment, where each form is bound to the flow it executes.
{% hint style="warning" %}
Relaxing `checkInSecurityMode` below its default means a matched profile can be returned on the strength of an email address alone. Anyone who guesses or mistypes a customer's address then sees that customer's data. Treat any change to this setting as a security decision, not a conversion optimisation.
{% endhint %}
## Customise the challenge email
The challenge email is a normal tenant email and is translated through the same localization files as the rest of the enrolment form. Programmes that need to vary the message — a different template per campaign, per language, or per pass type — can do so with the `runtime.emailAccountChallenger.templateFinder` script hook, which selects the template to use at the moment the challenge is sent.
Wording matters more here than elsewhere. A customer who asked for a loyalty card and receives an unexplained code is likely to ignore it, and the enrolment is lost at the last step. The message should name the brand, say what the code is for, and state how long it remains valid.
## Verify the setup
Test both branches before the form goes live, using two addresses that can actually receive mail.
With an address that is **not** in the customer base, complete the form and confirm that a new profile is created, a pass is issued, and no challenge email is sent.
With an address that **is** in the customer base, submit the form and confirm that the challenge email arrives, that the code or link works, and that the pass returned afterwards belongs to the existing profile rather than a newly created one. Check the customer list afterwards: a second profile for the same address means the check-in step did not run.
Finally, submit the recognised address and abandon the challenge. The existing profile must not be released, and no pass should be issued.
## Common pitfalls
A challenge email that lands in spam looks to the customer like a broken form. Sender reputation and authentication records on the sending domain matter as much as the form itself.
A customer base with duplicates already in it will not be deduplicated by enabling check-in. The step prevents new duplicates; it does not merge existing ones.
When social sign-in is also enabled on the form, the provider has usually verified the address already, so an additional email challenge tends to add friction without adding assurance. Keep both only where the programme genuinely needs a second factor, such as before a high-value redemption.
## FAQ
Does email check-in slow down enrolment?
For a new customer, no: no challenge is sent and the form behaves as it always did. For a returning customer it adds one step, which is generally faster than re-entering a full registration and avoids a duplicate account that would have to be merged later.
What happens if a customer never opens the challenge email?
The flow does not complete and no pass is issued. The existing profile is left untouched. The customer can start the form again and request a new challenge.
Can email check-in be used together with social sign-in?
Yes, and both identify a returning customer early. Social sign-in is usually the smoother of the two on mobile because the provider has already verified the address. Email check-in is the fallback when a customer does not use, or does not want to use, a social account.
Is the verification step mandatory?
By default, yes: `checkInSecurityMode` is full, so a matched profile is released only after a successful challenge. The setting can be relaxed, but doing so exposes existing customer data to anyone who submits the right email address.
Which email address is matched against?
The address stored on the customer profile. A customer who enrolled with one address and checks in with another is treated as a new customer, which is the usual reason a duplicate still appears after check-in is enabled.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.thewalletcrew.io/configure/advanced-configuration/enrolment-form/enable-email-check-in-on-enrolment-forms.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.