Social login in PrestaShop: Google, Facebook and Apple

What we would do

We would start with the shop you already run: its registration rules, customer data, theme, checkout modules, consent tools and integrations that create or update customers. Choose providers from your markets and support requests, then check whether an installed integration already meets the need. Your team must be able to maintain the provider apps and help customers recover access.

When a change is justified, configure it on an isolated staging copy with the same theme and modules, controlled test identities and deliberate provider callback settings. Block emails to real customers and exports to live customer systems from that copy. Allow mail only to controlled test inboxes, including the test identities' Apple relay addresses, and use a sandbox for integration tests. Rehearse the tests below, then switch in a planned window with the previous configuration and identity mappings protected. Agree how to reverse the change while keeping customers and orders created after launch.

If you want the options assessed against your shop, the PrestaShop Module Selection & Fit Assessment tests candidate routes on a controlled shop copy.

Choose login methods for your customers

Social sign-in can let customers authenticate with an existing provider account instead of creating another shop password. For returning customers, the benefit may be avoiding a forgotten shop password rather than speeding up first registration. It still may require account selection, consent, multifactor authentication and completion of missing shop information. Do not promise a fixed completion time.

Keep ordinary login and account recovery available, and preserve guest checkout if it suits your business. Provider sign-in is an option rather than a reason to force account creation. In native PrestaShop 1.7.8 and 9 registration, the formatter has a password field without a separate registration password-confirmation field; custom themes and modules can add fields.

Choose providers from customer demand and measured usage. There is no universal provider mix or dependable rule that one provider's users place higher-value orders. Check that your integration supports your PrestaShop version, active theme, normal login, registration and checkout login.

Provider sign-in keeps that provider's password out of your shop. It does not remove the need to protect customer records, local accounts, tokens, sessions and administrative access.

Understand the identity flow and validation

1. The shop begins a provider authorisation request tied to the customer's current session.
2. The customer authenticates with the provider and approves the requested access where required.
3. The provider returns an authorisation response to the registered callback.
4. The shop validates the response and, for an authorisation-code flow, exchanges the code through the provider's supported server endpoint.
5. The integration validates the identity, locates its existing provider mapping or completes secure account creation/linking, then establishes the shop session.

OAuth authorisation and identity verification are related but different. Google and Apple use OpenID Connect-style identity tokens. Each provider has its own supported contract; a generic profile request is not a substitute for validating that contract.

For identity tokens, check signature, issuer, audience, expiry and the expected nonce where used. Bind the response to the initiated session with the appropriate state and replay protection. Use PKCE where the provider and flow support or require it. Reject mismatches before creating an account or signing anyone in.

Store a stable provider identifier with the local customer mapping. For OpenID Connect, identify the account using the validated issuer and subject. Google explicitly recommends its stable sub claim rather than email as the identity key. See Google's OpenID Connect guidance.

Use HTTPS in production, tightly validate return destinations and protect secrets in server-side configuration. Do not put secret keys, access tokens or complete authorisation responses into routine logs. Retain tokens only when the feature needs them and rotate credentials when required.

Prepare Google sign-in

1. Create or select the appropriate Google project and configure its identity-app branding, audience and consent settings.
2. Request only the identity scopes you need, normally openid, email and, if needed, profile.
3. Create the client appropriate to the integration, commonly a web-application OAuth client.
4. Copy the actual callback URL supplied by the integration into the authorised redirect URIs. Add JavaScript origins only where its browser flow requires them.
5. Store the client ID and any required client secret through the integration's supported settings.
6. Test both a new customer and an existing customer, including an account outside the development/test audience before launch.

Match the callback's scheme, hostname, port, path and applicable query string exactly. A root-domain change, www change, shop subdirectory or language-dependent route can produce a mismatch. Keep staging and production credentials and callback settings deliberate.

Treat names and profile images as optional personal data, not required addresses or proof of customer eligibility. A provider profile does not supply every invoice or delivery field your shop needs.

Prepare Facebook login and external access

Use the current setup checklist shown for your chosen Meta app and integration. Record the app type, intended audience, requested permissions and actual HTTPS callback URL before testing. Request only the profile and email permissions that you actually use. Before launch, configure the app's required privacy-policy and user-data-deletion settings, and test the published deletion route.

Check the app's current access requirements for its type, including permission access levels, review and business verification where applicable. Development/tester success and switching to Live are not sufficient proof that ordinary external customers can sign in. Consult the official Facebook Login documentation and the settings shown for your app.

An email address may be absent or not available to the app. Detect that case, ask the customer for a contact email and verify it through an appropriate process before using it for account ownership or recovery. Do not invent a deliverable email from a provider ID or silently link an existing shop account.

Test permission refusal, partial approval, a user without a returned email, a non-role external user and a revoked connection. Show a useful fallback rather than an empty callback page.

Check Apple prerequisites and relay email

Apple's documented web setup requires an existing App Store app using Sign in with Apple. Associate the website's Services ID with the enabled primary App ID; a membership and unused App ID alone are not the complete prerequisite. Follow Apple's environment requirements.

1. Confirm the eligible app and primary App ID.
2. Create/configure the website's Services ID and associate it with that primary app.
3. Register the actual website domains and absolute HTTPS return URLs.
4. Create the appropriate private key and configure the team/client/key identifiers required by the integration.
5. Ensure the integration creates and renews the signed JWT client secret correctly, and protect the private key.

Use Apple's web configuration steps for the account configuration. Test a fresh authorisation as well as returning sign-ins.

The first authorisation can include a user object containing the name. Validate and persist it at that time, with a completion path if it is missing. Subsequent authorisations do not repeat that user object. When email is available, read it from the validated identity token; provide a completion and verification path if it is absent. Do not overwrite a stored name with an absent value. See the Apple callback documentation.

Accept Apple's verified real or private relay email. The established generated domain is @privaterelay.appleid.com. Apple's 2026 announcement schedules new Sign in with Apple relay addresses to move to @private.icloud.com later in 2026, while existing addresses keep working. Treat this as an announced transition, and confirm rollout and integration support when you implement it. Support both and avoid hard-coding a single suffix as identity verification. See the Apple relay-domain update.

Register your outbound email sources and authenticate them according to Apple's requirements. Test order, shipping and recovery messages through the relay, including a user who disables forwarding. The relay address is a valid contact endpoint, not a way to discover the hidden address. Follow the private relay instructions.

Link accounts without exposing order history

First look for an existing mapping of the validated provider identity. Once linked, use that stable mapping for later sign-ins. Email can change, be absent or be a private relay address.

If a newly encountered identity has an email matching an existing customer, treat it as a possible link, not permission to sign into that account. Require proof of control of the existing shop account, such as reauthentication or a secure verified account-recovery/linking flow. Provider trust and email-verification semantics differ.

1. Validate the provider identity and the initiated login session.
2. If its mapping exists, confirm the local account is eligible for login.
3. If a possible local match exists, explain the linking action and request the required proof.
4. Link the identity only after confirmation, with duplicate and concurrency checks.
5. If no match exists, complete the required customer fields and create one account.

Multiple providers can map to one customer after secure confirmation. Do not merge accounts simply because a name or other profile field looks similar. Treat an Apple relay email and a different Google email as different contact values until the customer proves and approves the link.

Provide unlinking and recovery without leaving the customer locked out. Before removing the last usable provider, establish another valid login method. Handle revoked consent, disabled local accounts, changed emails and provider-account deletion deliberately.

Work through an existing trade customer's sign-in

A trade customer has approved prices, saved addresses, previous orders and an ERP customer reference. They choose Google with the same email as their password account, but no provider mapping exists. Use the ownership-confirmation flow above, then check that the mapping points to the original customer record. Verify its customer group, approval status and ERP reference as well as the visible order history.

Repeat with a fresh provider identity whose email matches no account. Authentication must follow your normal trade-registration rules: proving control of a Google account does not grant trade approval or special prices. If your connector creates ERP customers on registration, check that the linking route does not send a second new-customer export. Keep the test customer's local identifier in the acceptance record so the developer can show which record was used.

Keep privacy choices and buttons clear

Document what identity and contact data you receive, why you use it, how long you retain it and which providers participate. Choose the applicable lawful basis and keep optional marketing permission separate. Authorising a provider profile is not newsletter consent.

Request only necessary scopes. A name, email or picture does not imply permission to collect friends, posts or other unrelated data. Apply your account-erasure and retention process to identity mappings and revoke credentials where appropriate, while preserving records that must lawfully remain.

Check whether third-party scripts or storage require consent for the specific deployment. Test refusal and withdrawal, with the ordinary login or guest route still usable. See the PrestaShop privacy guide for the wider shop process.

Place buttons where customers can find them on login and registration pages, with a clear ordinary-login alternative. Add checkout sign-in only when the integration preserves the current cart and returns to the correct step. Do not claim that identity sign-in automatically fills shipping addresses.

Use each provider's current approved button assets, labels and branding. Check touch targets, keyboard focus, accessible names, contrast and the return path after a popup closes. Test mobile and assistive technology rather than assuming a small logo is a clear login control.

Diagnose a button that returns without signing in

First establish where the journey stopped: before leaving the shop, at provider approval, on the callback or during local account creation. Record the provider, shop domain, browser, start page, time and a sanitised error reference. A button appearing correctly does not prove that its callback can establish a customer session.

After checking the registered URL, compare the callback reached with the hostname that started the login. Inspect canonical redirects, reverse-proxy HTTPS handling and whether the original session survives the round trip. On staging, check whether consent controls block a required script and whether the browser reports a popup or storage failure. Keep state, nonce and signature rejection enabled while tracing the cause.

If provider validation succeeds but account creation fails, check required customer fields, custom validation and errors from customer-related modules. Keep these failures distinct from a provider refusal, so support can offer the right next step without asking the customer to repeat an authorisation that already succeeded.

Test launch, failures and account recovery

Before launch, record registration and checkout completion with consistent definitions. Afterwards, measure provider starts, completions, errors, securely linked accounts and order completion over comparable traffic. High usage alone does not prove that the feature caused extra sales.

Accept the work and plan the switch

1. Write down the installed PrestaShop, theme, checkout and login-module releases, required customer fields, languages and multistore sharing settings. Record which customer integrations and consent controls are in scope.
2. Put provider apps under business-controlled access with named administrators and a recovery route. Record who maintains callback settings, handles provider notices and renews expiring credentials, including Apple's signed client secret.
3. Prepare the staging copy and its provider access. If its callback is protected by staging authentication or maintenance controls, arrange controlled access compatible with the provider flow rather than opening the whole copy.
4. Run the scenario table and keep a result for each relevant route and device. Use approved test accounts outside app developer roles where external access must be proved. Record the local customer identifier, expected outcome and actual result without collecting tokens or unnecessary personal data.
5. Back up configuration and identity mappings, rehearse migration if needed and agree the live window. Deploy the tested files and settings; keep production customer and order data current instead of replacing the live database with the staging copy.
6. Verify production callbacks and the intended app audience, then monitor failures, duplicate registrations and completed purchases. Give support the ordinary-login recovery route and a named escalation contact. Repeat relevant checks after a provider, module, theme or checkout change.

What to ask the developer or agency

• Can you demonstrate which provider identifiers map to which customer, including after a module replacement or provider-app change?
• Does disabling or uninstalling the module remove its mappings, and how will you preserve links created after launch if we reverse the change?
• Which hooks or integrations run when a customer is created or linked, and how have you checked trade groups, approval rules and customer exports?
• Where are the acceptance results, provider-account ownership details, renewal instructions and sanitised diagnostics that our support team will need?

Questions owners ask

Is Sign in with Apple the same as Apple Pay?

No. Sign in with Apple authenticates a customer account; Apple Pay is a payment method handled by a payment integration. Enabling either does not configure the other.

Can a replacement module use our existing provider links?

Only if the migration supports the stored identifiers and account mappings. A new module may use a different storage format. Some providers also scope their user identifiers to an app or developer account. Changing that app or account may therefore require a migration supported by the provider or secure account linking, as well as importing the mapping table. Require a demonstration with returning customers before switching, and agree a recovery route for any mappings that cannot be carried across.

Will signing in attach a customer's old guest orders?

Provider authentication alone does not establish ownership of past guest orders. Ask whether your shop has a supported order-claiming process and what proof it requires before exposing those orders.

Who should own the Google, Meta and Apple app accounts?

Your business needs continuing administrative access and recovery details, even if an agency performs setup. Include provider apps in supplier handover and staff offboarding so a change of developer does not leave credentials or access notices with someone who no longer maintains the shop.