BigCommerce checkout
Sign-in at BigCommerce checkout, with guest checkout intact
Store Social Login adds sign-in to the customer step of BigCommerce’s Optimized One-Page Checkout and leaves “Continue as guest” where it was. This page shows what a shopper sees in each state, what your store needs, and how a custom checkout can opt in.
1/5 Checkout opens on the Customer step as BigCommerce draws it: an email address, Continue, and a link for shoppers who already have an account. Shipping, Billing and Payment wait below.
Why checkout
Why checkout is the place to ask for an account
A shopper at checkout has a full cart and a typed email, so it is the natural moment for a store to want an account: it is what makes their next order quicker. It is also the moment an account form gets in the way of the order they came to place. The home page lists two sourced figures, with their samples and dates, on how often shoppers say they give up over an account they did not want or a password they forgot. See why merchants add sign-in.
BigCommerce lets a store choose how hard to push. Under Settings, then Checkout, the Customer accounts setting allows guest checkout, allows it and creates an account after ordering, or requires an account. BigCommerce’s Guest Customers and Checkout, opens in a new tab guide spells out what guest checkout costs the store: guest orders show a customer_id of 0 in exports and API data, and guests are grouped under an anonymous placeholder customer that lowers the customer count in analytics. Requiring an account avoids that, but it asks every shopper for something some of them did not want to give.
Sign-in at checkout is the third option. It leaves that setting alone. It gives a shopper who is willing a quicker way to an account, a tap on Google or a code by email. It recognises a shopper whose address already has an account and offers the way that account signs in. And it leaves “Continue as guest” exactly where it was for everyone else. The store keeps the guest orders it would have had anyway, and gains a way to join them to an account later.
What the shopper sees
Four checkout states, and what each one offers
The customer step changes with what BigCommerce knows about the shopper. The app follows it and offers only what that shopper can use.
The options are shown as text, top to bottom. The real buttons take your theme’s styling, apart from Google’s, which keeps Google’s own look under Google’s brand rules. Which methods appear, in what order and in what words is your choice in the dashboard.
State 1 of 4
No address yet
The shopper reaches the customer step before BigCommerce knows their email, or opens the create-account form.
Offered, top to bottom
- Sign in with Google
- Sign in with a codeWe’ll email you a one-time code
- or
- Sign in with email
- or
- Continue as guest
The methods you placed come first, in your order. “Sign in with email” slides the store’s own fields back in under the “or”, and “Continue as guest” gives way when they open. On the create-account form the wording changes to “Sign up with …”.
State 2 of 4
An address already set up with Google
The shopper types an address that BigCommerce matches to an account already connected to Google on this store.
The shopper reads
Looks like jamie@example.com has an account that is set up with Google sign-in. To continue, sign in with Google or check out as a guest.
Offered, top to bottom
- Sign in with Google
- Sign in with a code
- or
- Continue as guest
The code button joins Google’s when you placed it. Google opens on that address. If the shopper picks another Google account, the app refuses it: nothing is created or linked, and the shopper is sent back to choose again. When the checkout has BigCommerce’s sign-in link control, it is offered in a line under the buttons.
State 3 of 4
An address with a password account
The shopper types an address that has a store account but is not connected to Google.
The shopper reads
Looks like jamie@example.com has an account. To continue, get a code by email, use your password or check out as a guest.
Offered, top to bottom
- Sign in with a codeSent straight away to that address
- Use your password
- or
- Continue as guest
The code button comes first when you placed it, and the notice names only what is offered. Google is not offered here, even if you placed it on checkout: the shopper may use a different Google address, and signing in with the wrong account is worse than one more step. They can connect Google from their account page. Choosing the password folds the button away and slides the store’s own field into its place, with “Forgot password?” underneath.
State 4 of 4
Signed in
The shopper has signed in by any method, here or earlier.
The sign-in choices have done their job. The app’s block lives on the customer step, so what follows is BigCommerce’s own checkout, which pre-fills a signed-in customer’s email and last-used addresses. In the background, the app joins any past guest orders under the verified address to the account (see below).
The checkout belongs to BigCommerce, so the app is careful with it. Nothing the checkout manages is moved, wrapped or given a new class. The app adds its block beside the form’s own nodes and hides the ones that give way with stylesheet rules, so the checkout can re-render without losing track of its own markup.
Guests
“Continue as guest” stays
The guest option is repeated, never replaced, and never invented.
When the checkout renders a control for it, the app shows “Continue as guest” inside its own block, under an “or”, and pressing it presses BigCommerce’s own control. In every state the option appears only when the checkout has a control to press. Where the checkout has none, the app shows none.
Whether that control exists is the store’s decision. A store that requires an account has no guest checkout, so there is nothing to repeat. Where guest checkout is on, the Existing accounts setting decides what happens to a shopper whose address already has an account: they can be allowed to check out as a guest, prompted to sign in but still allowed to continue, or required to sign in. Where a store requires existing accounts to sign in, the app offers no guest option beside such an address either.
The wording and colours of the guest button are yours, set in the dashboard. A guest who checks out still gets what they came for, and the order is not lost to you: it joins their account the next time they sign in with a verified address.
Requirements
What your store needs
Three are settings in your BigCommerce control panel. The rest is how the app is installed.
| Setting | What BigCommerce offers | What it means for the app |
|---|---|---|
| Checkout typeSettings › Checkout | What BigCommerce offersOptimized One-Page Checkout, or a custom checkout. | What it means for the appThe app attaches itself to the Optimized One-Page Checkout. A custom checkout opts in with the contract below. |
| Customer accountsSettings › Checkout › General settings | What BigCommerce offersGuests allowed; guests allowed with an account created after ordering; or an account required to check out. | What it means for the appWhere an account is required there is no guest checkout, so BigCommerce renders no guest control and the app shows no “Continue as guest”. Otherwise it stays. |
| Existing accountsShown only when guest checkout is on | What BigCommerce offersAllow existing accounts to check out as guests; prompt them to sign in but still allow a guest checkout; or require them to sign in. | What it means for the appDecides whether “Continue as guest” appears beside an address that already has an account. Where sign-in is required, no guest option is shown. |
Settings and labels are as BigCommerce words them in its Optimized One-Page Checkout, opens in a new tab and Guest Customers and Checkout, opens in a new tab articles. Beyond those settings, four things must be true.
- A Stencil storefront. The app is installed through BigCommerce’s Scripts API, opens in a new tab, and BigCommerce’s guide says a Blueprint store “does not support rendering scripts inserted using the Scripts API or the Script manager.” Blueprint themes are therefore not supported.
- The Optimized One-Page Checkout. The same guide says: “To render scripts, the store must have BigCommerce’s Optimized One-Page Checkout enabled.” You choose it under Settings, Checkout, Checkout type. Merchants with private themes may need to add support for it themselves.
- An integrity hash on the checkout script. BigCommerce requires at least one subresource-integrity hash on every script on the checkout page, and the app’s loader is installed with its hash.
- The primary storefront channel. Today the app runs on a store’s primary storefront channel only.
The script appears in your storefront’s Script Manager. BigCommerce says control panel users can change the consent category of any script there, or delete it. Attaching past guest orders needs one more permission, described next.
Order history
Past guest orders attach on sign-in
A shopper who checked out as a guest last month finds that order in their account after signing in this month.
01
A guest checks out
BigCommerce records a guest order, with a customer_id of 0.
02
The same address signs in
Later, with Google or an emailed code, either of which proves the address.
03
The order joins the account
The app reassigns it to the signed-in customer: the change a merchant makes by hand with Edit order.
In BigCommerce, linking a guest order to an account is a manual job. The Guest Customers and Checkout, opens in a new tab guide describes it: open the order’s Action menu, choose Edit order, switch “Order for” to Existing customer, pick the customer and save. It also flags orders whose email matches an existing account, which you can find with the “Guests who may be customers” search. The app makes that same change at the moment the address has been proven (see how to link guest orders to customer accounts in BigCommerce).
After a verified sign-in is recorded, the app lists the store’s orders under the verified address, the newest fifty on the storefront channel, and reassigns the ones placed as a guest, or under a customer the store has since deleted, to the signed-in customer. The rules around it are strict.
- An order that a living account owns is never moved, whatever its email says.
- A password sign-up never attaches anything, because nothing has verified the address.
- It never fails the sign-in. Whatever it could not attach waits for the next sign-in.
- It needs the Orders: Modify permission. A store that installed before that permission was requested grants it by re-authorising the app, and the dashboard says so until it has. A dashboard switch, on by default, controls the behaviour.
An order a shopper places as a guest at checkout joins their account the next time they sign in and the address is verified.
For developers
A custom checkout can opt in
Mark each customer-step form with a data attribute and the same block appears, built from your own markup.
On the Optimized One-Page Checkout the app finds the form that checkout-js renders, form.checkout-form[data-test="checkout-customer-returning"], and attaches on its own. A checkout built some other way, such as a rebuilt Cornerstone checkout, can opt in by marking its forms. BigCommerce notes in its Optimized One-Page Checkout, opens in a new tab article that a custom checkout, installed from a hosted script URL, no longer receives automatic updates such as new features, bug fixes and security updates. So the opt-in is deliberate: nothing attaches to a form you have not marked.
| Attribute | Put it on | What the script does |
|---|---|---|
data-bc-auth="sign-in" | Put it onThe returning-customer form | What the script doesOffers the sign-in methods you placed on checkout, collapsed above the form’s own fields, with “Sign in with email” revealing them. |
data-bc-auth="create" | Put it onThe create-account form | What the script doesThe same, worded “Sign up with …”. |
data-bc-auth-email="<address>" | Put it onA sign-in form, once the address is known | What the script doesThe address the form is already about. The script asks the app whether that address is Google-connected on this store, then offers only what applies. |
The script also reads the following from inside a marked form, so a custom checkout gets the full behaviour when it provides them.
| Element | How the script uses it |
|---|---|
[type="submit"] | How the script uses itThe form’s own button. The app’s buttons copy its classes, so they take the checkout’s styling. |
.form-field, .form-actions | How the script uses itWrappers around the fields and the submit. Hidden while the choice is collapsed, shown when the shopper picks email. |
legend, .form-legend | How the script uses itWhere present, the block is placed after it. Otherwise it goes at the top of the form. |
.alertBox--info | How the script uses itAn existing notice. When the address is known, the app’s notice is a copy of it carrying the app’s words, so it keeps your notice styling. |
[data-test="customer-signin-link"] | How the script uses itBigCommerce’s “Send me a sign-in link”. Offered in a line under the buttons in the Google-connected state, when it exists. |
[data-test="forgot-password-link"] | How the script uses it“Forgot password?”, or any link in the form whose text says “forgot”. Hidden while collapsed; a line of the app’s stands in for it once the store’s own fields open. |
[data-test="customer-cancel-button"] | How the script uses itBigCommerce’s “Cancel”, which returns to the guest form. Where no address is known, the block offers “Continue as guest” under an “or” that presses it. |
[data-test="customer-guest-continue"] | How the script uses itBigCommerce’s “Continue as guest”, rendered when the store lets a shopper whose address has an account check out without signing in. When it exists, the known-address state offers it; when it does not, no guest option is shown. |
<form data-bc-auth="sign-in"
data-bc-auth-email="jamie@example.com">
<p class="form-legend">Returning customer</p>
<div class="form-field">…</div>
<div class="form-actions">
<button type="submit">Sign in</button>
<button type="button"
data-test="customer-guest-continue">
Continue as guest
</button>
</div>
</form>Nothing in the form is moved, wrapped or re-classed. Everything the app adds sits beside your nodes, and anything of yours that gives way is hidden by a rule keyed on data-bca-collapsed or data-bca-known, attributes the script sets on the form. A framework that re-renders the form, React or Vue, can leave those attributes alone: the script re-mounts its block when the children change.
In the dashboard, the Checkout row on each method’s page reports the last seven days: “Seen on N checkout visits” when the script found a form to attach to, or that it loaded on the checkout and found nothing, with a pointer to this contract. The report carries no shopper data, only the surface name and a yes or no.
Questions about checkout sign-in
Does sign-in at checkout replace “Continue as guest”?
No. It adds options beside it. The app repeats BigCommerce’s own guest control under an “or”, and only when the checkout renders one, so a store that requires an account shows no guest option. The wording and colours of the guest button are yours to set.
Why is Google not offered when an address has a password account?
Because the shopper may use a different Google address, and signing in with the wrong account is worse than one more step. They are offered an emailed code if you placed it, their password, or guest checkout, and can connect Google from their account page. When an address is already connected to Google, Google opens on that address and any other Google account is refused.
What does my store need for sign-in to appear at checkout?
A Stencil storefront, not a Blueprint one, with the Optimized One-Page Checkout turned on under Settings, Checkout, and the app installed on your primary storefront channel. A checkout built another way can opt in with a small set of data attributes.
What happens to an order a shopper placed as a guest?
It stays a guest order until the shopper next signs in with a verified address. Then the app reassigns it to their account, unless an existing account already owns it. This needs the Orders: Modify permission and a dashboard switch that is on by default.
Can I reword the buttons at checkout?
Yes. You can reword and recolour the code button and its line, the store’s own “Sign in with email” button and “Continue as guest”, and choose between “Sign in with Google” and “Continue with Google” and one of Google’s button themes. Google’s button keeps its own look under Google’s brand rules.
Keep reading
- Why merchants add sign-in
The two sourced figures on forced accounts and forgotten passwords, with samples and dates.
- Google sign-in for BigCommerce stores
Sign in with Google on the login, create-account and checkout pages.
- BigCommerce passwordless login with an email code
The six-digit code at checkout, and how it differs from BigCommerce’s emailed link.
- Security and shopper data
What the app asks for, stores and never touches, and how a shopper reaches a BigCommerce session.
- How to add social login to BigCommerce
An app or a custom build: the Scripts API, checkout limits and a decision checklist.
- Link guest orders to customer accounts in BigCommerce
The steps to do it by hand in the control panel, and how sign-in does it for you.
- Show your store’s name on Google sign-in
Use your own Google client and a sign-in address on your domain.
Put sign-in at your BigCommerce checkout.
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.
Asking costs nothing and commits you to nothing. You will need your storefront address and, if you know it, your theme.