Social sign-in

Let users authenticate on enrolment forms with Apple, Google, LINE, or Facebook. Use the provider-verified email to create or retrieve a customer profile.

Social sign-in (also called social login) lets users 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.

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
• Google Sign-in configuration
• LINE Sign-in configuration
• Facebook Sign-in configuration

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 user taps a provider button. The provider authenticates the user. It returns an identity payload. The Wallet Crew extracts usable attributes from that payload. The Wallet Crew then applies your matching rules.

One form can support new and returning users. If a match is found, The Wallet Crew loads the profile. The user continues as a known customer. If no match is found, the user continues as new. A profile is created on submission.

One form can support multiple social sign-in 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 users.

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 you already have for matched users. Keep the new-user path short and focused.

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.

Enrolment speed & efficiency (what to optimize)

Optimize for a flow that completes in seconds. Assume the user is in a queue. Ask only for what you truly need 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 user controls a provider account.

You benefit from provider controls like device trust and MFA. You typically get a verified email. You still need a rule for account ownership in your CRM. You also do not get automatic linking across providers.

Activation

You enable social sign-in 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:

Google

Apple

LINE

Facebook

Once the provider is configured, enable it on the enrolment form you want. See Enrolment form for form settings.

Geo and market considerations (which providers to offer)

Provider choice is often regional. Offer the buttons your 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.

If you operate across countries, keep it simple. Use separate enrolment forms per region. Enable only the relevant providers on each form. This avoids confusing users with unused buttons.

What data you get

You can expect an email from each provider. First name and last name are provider-dependent. Treat names as optional.

Design your matching rules as if you only get email over time. Apple can return names only once. Apple can also return relay emails. See Apple Sign-in configuration for those behaviors.

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”.

FAQ

Can the same user sign in with different providers?

Yes, but the result depends on what you use as the matching key. Most setups match on email.

If Apple and Google return the same email, they resolve to the same profile. If they return different emails, you can create duplicates. This happens often with Apple relay emails, work vs personal emails, or users changing provider settings.

Avoid duplicates by linking identities in your CRM. Store the provider identifier (for example, the provider subject) against the customer when you can. 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 you need an extra assurance step. 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 in your CRM.

If you already have customers 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. You can also let the user confirm a known identifier after sign-in before you load an existing profile.

What happens if the user cancels social sign-in or the provider fails?

The user stays unauthenticated. The form should fall back to your 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 you see frequent failures, 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 your users already use in that market.

If you operate in multiple countries, use separate enrolment forms per region. Enable only the relevant providers on each form. If you want device-specific UX, keep Apple prominent on iOS and Google prominent on Android, but still provide a fallback path for users who do not want to use social sign-in.