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.

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.

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.

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.

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.

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.