Verified Bidirectional Account Linking Across a Nine-Brand Identity Platform

That flexibility created an identity problem. When a customer signed in with a new Apple or Google identity whose email already belonged to an existing account, the platform had to decide what to do. Linking the two automatically on an email match alone would be unsafe: a matching email address suggests a relationship, but it does not prove the person signing in actually controls that inbox. The platform needed a way to connect compatible Apple and Google identities to one shared account without ever granting access on an email match by itself, and to do it consistently across all nine brands, including the awkward cases: Apple's private relay addresses, password-enabled accounts, risky sign-ins, and provider outages.

The constraints were concrete. Linking had to be bidirectional and order-independent: Google first then Apple, or Apple first then Google, had to reach the same shared account. Apple's Hide My Email had to be handled separately, because a private-relay address that did not match the customer's real account email must not silently link into that account. Verification had to reuse the same code-challenge mechanism already trusted for elevated-risk authentication, so linking inherited proven controls rather than inventing new ones. Risk had to modulate friction: low-risk sign-ins should stay frictionless while medium, high and undetermined risk required an OTP. Repeated failures had to be contained through a blocking policy that applied at the account level, across every brand, not per brand. And provider failures had to fail safe, never leaving a customer with a partial or duplicate account.

The same verified path covered both linking directions. If a customer created an account with Google and later chose Continue with Apple using the same shared email, the system detected the existing account, sent a code to its email, and linked Apple after successful verification. The reverse, Apple's Share My Email first and Google later, resolved to the same shared account through the same challenge. After linking, the customer could sign in with Apple, with Google, or with email and password wherever one had been configured, and land on the same account.

Apple's Hide My Email stayed a deliberately separate path. When the private-relay address did not match the customer's undisclosed personal email, the identities were not eligible for same-email linking. Rather than link the relay into an unrelated account, the platform showed a limited-access explanation and created a separate relay-email account. Beyond first-time linking, the same account carried its own lifecycle: a customer could set a password on a social account, change the primary email (which delinked the previous social provider and required re-verification), and every returning sign-in still passed through risk evaluation before a session was issued.

From there the flow branched into clearly bounded outcomes. An eligible email match issued a linking code to the existing account's email; on successful verification the provider was linked, on failure the attempt was rejected and recorded. An Apple relay email that did not match routed to a limited-access explanation and a separate relay-email account. Once resolved to a shared cross-brand account, the account status was checked: a blocked account was shown as blocked, an active account was scored into a risk category. Low risk issued an authenticated session directly; medium, high and undetermined risk sent an authentication OTP, and repeated failed challenges, up to a fixed threshold, blocked the shared account across all nine brands. The account itself exposed password setup and email changes, where changing the primary email delinked the previous social provider and required provider re-verification. Provider service failures did not create partial state: they returned a safe error and retry that routed back into the same orchestrator, so a failed Apple or Google call never produced a half-linked or duplicate account. The linking boundary combined three checks: a validated provider response, a compatible same-email match, and a successful email code challenge, and failed code submissions ran through the same challenge-control and blocking policy as risk OTPs.