Skip to content
Request access

Guide

How to add social login to a BigCommerce store: app or custom build

Four realistic ways to let shoppers sign in on BigCommerce, what BigCommerce’s own documentation says about each, and a checklist for choosing. We make one of the options, so it comes last, after the checklist.

Published and updated

Before the detail

The short answer

Stay with BigCommerce’s own settings if guest checkout and passwords already serve you. Use BigCommerce’s passwordless link if forgotten passwords are the problem and an emailed link is acceptable. Use an app if you want Google sign-in across your pages, checkout included, without code to maintain. Build it yourself if you need something no app offers and have a developer who will own it.

The rest of this guide gives the constraints behind each answer, so you can check them against your own store rather than take our word for it.

Definitions

What social login means on BigCommerce

On a BigCommerce storefront, a shopper’s account is a BigCommerce customer: a record with an email address, a password that BigCommerce stores, saved addresses and an order history. “Social login” means a third party, usually Google, tells your store who the shopper is, so the shopper does not type a password. But BigCommerce still has to sign a customer in. The identity from Google must be matched to a BigCommerce customer and turned into a BigCommerce storefront session. That matching and that hand-off are where most of the design decisions are.

Three BigCommerce features shape every approach. The Customer Login API signs a customer in from outside. The Scripts API puts code on storefront pages without editing the theme. The Optimized One-Page Checkout is where most orders end. The next section takes them in turn, using what BigCommerce’s own pages say, with links so you can read them yourself.

What BigCommerce documents

The constraints that decide the build

The Customer Login API signs a customer in, but only a server can

BigCommerce’s Customer Login API, opens in a new tab page describes it as a way to “enable single sign-on for storefront customers using the Customer Login API and JSON Web Tokens”, and lists integrating with an identity provider among its uses. The rules that matter for a build:

  • The token is a JSON Web Token signed with your app’s OAuth client secret; the page’s example uses HS256. A secret cannot live in theme code or a browser, so something running on a server must create every token.
  • The claims include operation (always customer_login), store_hash and customer_id, plus optional channel_id (default 1), redirect_to and request_ip. The customer has to exist already, so signing in a new shopper means creating their customer first.
  • The iat claim is valid for 30 seconds, and the address /login/token/{token} can be visited once. A token is made at the moment of sign-in and followed straight away, never in advance.
  • BigCommerce states: “A customer account has a single active storefront session.” Signing in again, or out, invalidates the customer access tokens issued before.
  • It needs an API account with the Customers Login scope set to Login, and the app must be installed on the store to get store-level tokens.

In practice that means a server, a secret to protect, and code that finds or creates the right customer before it signs anyone in.

The Scripts API puts the buttons on the page, within limits

If you would rather not edit theme templates, BigCommerce’s Scripts API, opens in a new tab guide describes the alternative: a script installed through the API. Its limits are worth reading before you plan around it.

  • Each app can have 10 API-created scripts, inline scripts can include up to five <script> tags, and on BigCommerce-hosted storefronts a new or updated script takes 20 seconds to cache.
  • An API-created script can be updated or deleted only by the API account that created it. Control panel users can change the consent category of any script in Script Manager, or delete it.
  • Blueprint, a legacy theme engine, “does not support rendering scripts inserted using the Scripts API or the Script manager.”
  • For Catalyst storefronts the guide says versions before 1.1 do not render scripts added through the Scripts API, and that scripts “are not guaranteed to fire on every page navigation”, because Next.js supports client-side navigation. We mention it because it affects every script-based approach. Store Social Login does not currently claim Catalyst support.

Checkout has the strictest rules

The same guide says: “To render scripts, the store must have BigCommerce’s Optimized One-Page Checkout enabled.” It also says every script on the checkout page needs at least one subresource-integrity (SRI) hash, to meet PCI 4.0 requirement 6.4.3, and that a hash stops matching when the script’s contents change, after which the script fails to execute. A custom build with a checkout script therefore needs a step that regenerates the hash on every change. BigCommerce’s Optimized One-Page Checkout, opens in a new tab article adds that a store on a custom checkout no longer receives automatic updates such as new features, bug fixes and security updates.

BigCommerce’s own passwordless login is a link, for existing customers

The Passwordless Customer Login, opens in a new tab page describes an endpoint your application posts to, {store-url}/login.php?action=passwordless_login, with an email address and an optional redirect URL. BigCommerce emails a one-time link, and the response includes an expiry in seconds (900 in the example). If the email does not belong to a customer the endpoint returns 404, a 429 means the request was rate limited, the redirect must be on the store’s domain, and the email uses the store’s own templates. The Optimized One-Page Checkout article describes a checkbox that lets existing customers use the link on the checkout page. So it is a link, not a code; it needs an account that already exists; and it is not social login. For a store whose problem is forgotten passwords, it may be enough.

Guest orders do not link themselves

BigCommerce’s Guest Customers and Checkout, opens in a new tab guide says guest orders show a customer_id of 0 in exports and API data, and describes linking an order to an account by hand: open Edit order, switch “Order for” to Existing customer, pick the customer and save. It also flags possible matches under “Guests who may be customers”. Whichever approach you choose, decide what should happen to those orders when the shopper signs in. The steps, and where doing it by hand stops scaling, are in how to link guest orders to customer accounts in BigCommerce.

Google’s consent screen shows your app’s name only after verification

If you build with Google, shoppers see Google’s consent screen. Google’s OAuth app branding help, opens in a new tab says: “The app name will be displayed on the OAuth consent screen only if your app has been verified” and “Without verification, only your application domain will be visible to users.” Google’s brand verification guide, opens in a new tab asks for a publicly accessible home page, a privacy policy hosted on the same domain, and authorized domains verified in Google Search Console.

Side by side

Four ways to do it

The same questions asked of each approach. Where a cell says “ask”, the answer differs from product to product and we have not reviewed them one by one.

Four ways to add sign-in to a BigCommerce store, compared across what each covers, new accounts, duplicate accounts, past guest orders, theme edits, maintenance and Google's consent screen
What it coversPassword onlySign-in, create-account and checkout, with BigCommerce’s own forms and password recovery.BigCommerce’s passwordless linkCheckout, through a setting that lets existing customers use it. Elsewhere it is an endpoint for your own code, or an app, to call.A social-login appVaries. Ask which it covers: the sign-in page, the create-account page, checkout, the header menu, the account page.A custom buildWhatever you build. Each page is its own piece of work, and checkout has the strictest rules.
New accountsPassword onlyThe shopper fills in the form and chooses a password.BigCommerce’s passwordless linkNo. The endpoint answers 404 when the email “does not belong to a customer”.A social-login appVaries. Ask whether a new shopper gets an account in one step, and what the app asks them for.A custom buildYou build it. The Customer Login API signs in a customer_id, so the customer must exist before you sign them in.
Duplicate accountsPassword onlyNothing to reconcile: there is no second sign-in identity.BigCommerce’s passwordless linkNothing to reconcile: the link goes to an address that is already a customer.A social-login appAsk what happens when a provider-verified email already has a password account: a second account, a merge, or a connection after verification.A custom buildYours to decide: which customer a verified email belongs to, and what to do when more than one customer has it.
Past guest ordersPassword onlyStay guest orders (customer_id 0) until someone links them by hand with Edit order.BigCommerce’s passwordless linkNot part of it. Linking is still by hand.A social-login appVaries. Ask whether past guest orders join the account on sign-in, and what permission that needs.A custom buildNot done for you. You would find orders by verified email and reassign them through the API, with the Orders: Modify scope.
Theme editsPassword onlyNone.BigCommerce’s passwordless linkNone for the checkout setting. Elsewhere, whatever calls the endpoint.A social-login appVaries. Ask whether it needs template edits or loads through the Scripts API.A custom buildEither edit your Stencil templates, or load a script through the Scripts API and live with its limits: 10 scripts per app, and on checkout the Optimized One-Page Checkout and an integrity hash.
Ongoing maintenancePassword onlyBigCommerce’s.BigCommerce’s passwordless linkBigCommerce’s endpoint. Any code that calls it is yours.A social-login appThe vendor’s, within what BigCommerce and Google change. Ask how checkout and theme changes are handled.A custom buildYours: the Google client and its verification, the client secret, theme and checkout changes, and a new integrity hash whenever a checkout script changes.
Google consent screenPassword onlyNot applicable: there is no Google screen.BigCommerce’s passwordless linkNot applicable.A social-login appDepends on whether it uses its own Google client or lets you bring yours. Ask what shoppers will see.A custom buildYours. Google shows your app’s name only after brand verification; before that, only the application domain.

Sources: BigCommerce’s Passwordless Customer Login, opens in a new tab, Customer Login API, opens in a new tab, Scripts API, opens in a new tab and Guest Customers and Checkout, opens in a new tab pages, and Google Cloud Help.

Decide

A decision checklist

Answer these eight about your own store. Each says what the answer changes.

  1. Is your storefront a Stencil theme?

    BigCommerce says Blueprint stores do not render scripts inserted through the Scripts API, which rules out anything that loads that way. Catalyst has conditions of its own: version 1.1 or later, and scripts that are not guaranteed to fire on every client-side navigation.

  2. Is your checkout the Optimized One-Page Checkout?

    Scripts on the checkout page render only with it. A custom checkout no longer receives BigCommerce’s automatic updates, and sign-in on it is yours to build and maintain.

  3. Do you want sign-in at checkout, or only on the login page?

    Checkout has the strictest rules, and it is where “Continue as guest” has to be kept. Cost the work for each page separately.

  4. What should happen when a verified email already has an account?

    A second account splits order history. A merge or a connection needs a rule for proving the address and a decision about the old password.

  5. What should happen to past guest orders?

    BigCommerce’s guide describes linking them as something you do by hand. If you want them to follow the shopper, someone has to build or buy that, and grant the Orders: Modify scope.

  6. Who will maintain it?

    The Google client and its verification, the client secret, theme and checkout changes, and on checkout a fresh integrity hash after every script change.

  7. What should Google’s consent screen say?

    Your app’s name appears only after Google verifies the brand. To show your own store’s name, the redirect address has to sit on a domain you own and have verified, with a public home page and privacy policy on it.

  8. Do you need accounts at all?

    If most orders are guest orders and you are content with that, password sign-in with guest checkout, or BigCommerce’s passwordless link for existing customers, may be all you need.

How the answers point

  • Password sign-in with guest checkout is enough when most orders are guest orders and you do not need repeat-customer accounts.
  • BigCommerce’s passwordless link fits when the problem is forgotten passwords on accounts that already exist, and a link by email is acceptable.
  • A social-login app fits when you want Google sign-in on several pages, checkout included, no theme edits, and nobody on your side to maintain code.
  • A custom build fits when you need something an app does not offer, such as another identity provider, your own account-matching rules or a storefront type apps do not support, and you have a developer who will own the Google client, the secret, the checkout script and its hash.

The home page sets out two sourced figures on forced accounts and forgotten passwords, with their samples and dates, if you are weighing whether accounts are worth pursuing: why merchants add sign-in.

Disclosure

Where Store Social Login fits

It is the app option. Here is what it does and what it does not, stated plainly.

  • Methods. Google, Facebook, X and email code. You choose which appear and where: the create-account page, the sign-in page, checkout, and the header account menu where your theme supports it.
  • Installation. Through the Scripts API, with no theme edits. The script finds your theme’s own forms and reuses their styling, and a theme scan in the dashboard reports which pages it found.
  • Checkout. On the customer step of the Optimized One-Page Checkout, with “Continue as guest” kept; a custom checkout can opt in through documented attributes. See sign-in at BigCommerce checkout.
  • Session. It ends in a native BigCommerce session through the Customer Login API, and BigCommerce stays the system of record. See security and shopper data.
  • Duplicates. It connects a sign-in to an existing customer only when the provider has verified the email and exactly one customer in your store has that address, and it retires the old password at that moment. With several matches it does not guess.
  • Guest orders. Past guest orders under the verified address join the account on sign-in, once your store has granted the Orders: Modify permission. An order that an existing account owns is never moved.
  • Consent screen. By default Google shows this app’s name; Google has verified its branding. With your own Google client and a sign-in address on your domain, it can show your address and, once Google has verified your brand, your store’s name; that takes setup, and there is a guide.

Limits. It is built for Stencil storefronts, around Cornerstone-derived themes, and does not support Blueprint themes. It runs on a store’s primary storefront channel only. Other setups, such as headless storefronts, B2B Edition or several storefronts, are not something we claim today. It is in a private rollout, with no public pricing and no marketplace listing yet.

If that matches your answers to the checklist, request access and tell us your storefront address and theme. If it does not, the table above should point you to one of the other three.

Request access

Questions about adding social login

Can I add Google sign-in to BigCommerce without an app?

Yes. BigCommerce’s Customer Login API is the supported way to sign a customer in from outside. A custom build needs a server that verifies the Google sign-in, finds or creates the BigCommerce customer, and signs a short-lived token with your app’s OAuth client secret, plus a way to put the buttons on your pages. The constraints section above lists what that involves.

Does social login work on every BigCommerce theme?

Not on every one. BigCommerce says Blueprint stores do not render scripts inserted through the Scripts API, which rules out script-based approaches there. For Catalyst storefronts BigCommerce documents extra conditions, and scripts are not guaranteed to fire on every client-side navigation. Ask any vendor, or your developer, which themes and storefront types have actually been tested.

Do shoppers have to be signed in to check out?

That is the Customer accounts setting under Settings, Checkout. It can allow guest checkout, allow it and create an account after ordering, or require an account. Sign-in options at checkout work beside whichever you choose, but where an account is required there is no guest option to keep.

What happens to orders a shopper placed as a guest?

BigCommerce records them as guest orders, with a customer_id of 0, and its guide describes linking them to an account by hand: Edit order, then Order for: Existing customer. An app or custom code can make the same change on a verified sign-in, using the Orders: Modify scope. Decide which you want before you choose an approach.

Keep reading

Add social login to your BigCommerce store.

Store Social Login is in a private rollout, so access is by request. Tell us about your store and we will reply about getting sign-in onto your storefront.

Request accessSee how it works

Asking costs nothing and commits you to nothing. You will need your storefront address and, if you know it, your theme.