> 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/guides-enrolment/enrolment/enrolment-form/social-sign-in.md).
# Social sign-in
How social sign-in behaves on enrolment forms with Apple, Google, LINE, and Facebook: identification, matching rules, and the customer data returned.
Social sign-in (also called **social login**) lets customers authenticate on enrolment forms. It supports **Sign in with Apple**, **Google Sign-In**, **LINE Login**, and **Facebook Login**.
It works well for mobile flows on **iOS and Android**. It identifies customers early in the journey. It avoids password creation. It reduces duplicates caused by mistyped emails.
Place provider buttons above the form fields to encourage one-tap sign-in.
{% hint style="info" %}
This page covers **how social sign-in behaves** in The Wallet Crew (UX, matching, data expectations).
It does **not** cover provider console setup. Use these setup guides:
* [Apple Sign-in configuration](/guides-enrolment/enrolment/enrolment-form/social-sign-in/apple-sign-in.md)
* [Google Sign-in configuration](/guides-enrolment/enrolment/enrolment-form/social-sign-in/google-sign-in.md)
* [LINE Sign-in configuration](/guides-enrolment/enrolment/enrolment-form/social-sign-in/line-sign-in.md)
* [Facebook Sign-in configuration](/guides-enrolment/enrolment/enrolment-form/social-sign-in/facebook-sign-in.md)
{% endhint %}
Real-world examples
* **In-store QR enrolment:** Customers scan a QR and enrol in one tap.
* **Returning member enrolment:** Match the profile and skip known fields.
### What it does
Social sign-in adds a **provider-backed identity step** to an enrolment form. The Wallet Crew uses it to **resolve a customer early**. That customer context changes how the form behaves.
The customer taps a provider button. The provider authenticates the customer. It returns an identity payload. The Wallet Crew extracts usable attributes from that payload. The Wallet Crew then applies the configured matching rules.
One form can support new and returning customers. If a match is found, The Wallet Crew loads the profile. The customer continues as a known customer. If no match is found, the customer continues as new. A profile is created on submission.
One form can support multiple social sign-in providers at the same time (Apple, Google, LINE, Facebook).
### What this page does not cover
Provider setup is intentionally kept out of this page.
This page does **not** include:
* Apple/Google/LINE/Facebook console screenshots and step-by-step setup
* Client IDs, service IDs, keys, secrets, redirect URLs, or domain allowlists
* Provider-specific error troubleshooting (`origin_mismatch`, Apple relay email config, etc.)
Use the provider setup guides linked above for that.
### Benefits
* Faster enrolment with fewer typed fields.
* More reliable matching with provider‐verified email.
* Fewer duplicates caused by email typos.
* Better completion rates on mobile and QR journeys (less friction).
* One enrolment flow for new and returning customers.
#### UX patterns (fast enrolment, low friction)
Social sign-in works best when the form is built around it. Put provider buttons **above** the form fields. Make them the default entry path on mobile.
After sign-in, hide the email field. Or make it read-only. Keep a fallback like “Continue with email”. Skip fields already known for matched customers. Keep the new-customer path short and focused.
{% hint style="warning" %}
Apple “Hide My Email” can return a relay email. Avoid copy like “we found your personal email”. Names can be missing. Do not block submission on first/last name.
{% endhint %}
#### Enrolment speed & efficiency (what to optimize)
Optimize for a flow that completes in seconds. Assume the customer is in a queue. Ask only for what is truly needed at enrolment.
Prefer progressive profiling after enrolment. Use social sign-in to capture the matching key. Keep consents explicit but short. Keep long legal text off the critical path. Make errors specific and actionable.
For in-store QR flows, assume bad connectivity. Avoid extra network round-trips. Only add checks that reduce real fraud.
#### Security considerations
Social sign-in is a strong **identity signal**. It is not full account security. Treat it as proof the customer controls a provider account.
Provider controls such as device trust and MFA apply. A verified email is typically returned. A rule for **account ownership** is still needed in the CRM. Linking across providers is not automatic.
### Activation
Social sign-in is enabled in two places:
1. Configure the provider (Apple / Google / LINE / Facebook).
2. Enable the provider button on the enrolment form.
Provider setup is a one-time configuration per provider. Use these guides:
Once the provider is configured, enable it on the relevant enrolment form. See [Enrolment form](/guides-enrolment/enrolment/enrolment-form.md) for form settings.
#### Geo and market considerations (which providers to offer)
Provider choice is often regional. Offer the buttons customers already use.
Sign in with Apple is a strong default in iOS-heavy markets. Google Sign-In is a strong default in Android-heavy markets. Google can be constrained where services are restricted. LINE Login is especially relevant in Japan, Taiwan, and Thailand.
For programs that operate across countries, keep it simple. Use **separate enrolment forms per region**. Enable only the relevant providers on each form. This avoids confusing customers with unused buttons.
#### What data is returned
An **email** can be expected from each provider. First name and last name are provider-dependent. Treat names as optional.
Design matching rules as if only the email is available over time. Apple can return names only once. Apple can also return relay emails. See [Apple Sign-in configuration](/guides-enrolment/enrolment/enrolment-form/social-sign-in/apple-sign-in.md) for those behaviors.
{% hint style="info" %}
Facebook does not always return an email. Some accounts do not have a usable email, and some setups do not request it. Keep a fallback like “Continue with email”.
{% endhint %}
### FAQ
Can the same customer sign in with different providers?
Yes, but the result depends on the matching key in use. Most setups match on email.
If Apple and Google return the **same email**, they resolve to the same profile. If they return different emails, duplicates can appear. This happens often with Apple relay emails, work vs personal emails, or customers changing provider settings.
Avoid duplicates by linking identities in the CRM. Store the provider identifier (for example, the provider subject) against the customer when possible. Use a second identifier for matching when email is not stable. Common choices are loyalty ID, phone, or a one-time code.
Do we still need email verification?
Usually no, because the provider verifies the email.
Keep email verification when an extra assurance step is required. Common cases are high-value accounts and regulated programs. Another common pattern is step-up verification only when risk is high. Example: social sign-in for enrolment, then OTP verification before account changes or rewards redemption.
How should we handle Apple “Hide My Email”?
Treat Apple relay emails as valid emails. They can still receive messages. Do not assume they match the email held in the CRM.
When customers already exist in another system, avoid “email only” matching for Apple-heavy audiences. Add a second identifier in the flow. Use a membership number, phone number, or a one-time code. The customer can also confirm a known identifier after sign-in, before an existing profile is loaded.
What happens if the customer cancels social sign-in or the provider fails?
The customer stays unauthenticated. The form should fall back to the alternate entry path. A common fallback is “Continue with email”.
Keep the error message specific. Use wording like “Sign-in was canceled” or “Sign-in failed”. Avoid ambiguous messages like “Something went wrong”. If failures are frequent, check third‐party cookie settings, pop-up blockers, and the authorized redirect origins configured at the provider.
Can we limit which providers appear (by country or by device)?
Yes. Keep the button set minimal for each audience. Offer the providers customers already use in that market.
For programs running in multiple countries, use separate enrolment forms per region. Enable only the relevant providers on each form. For device-specific UX, keep Apple prominent on iOS and Google prominent on Android, but still provide a fallback path for customers who do not want to use social sign-in.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/guides-enrolment/enrolment/enrolment-form/social-sign-in.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
