Single sign-on overview

How it works

SSO covers two directions:

• Checkout SSO (incoming): when a customer who’s already logged into your site proceeds to checkout, your site’s SSO endpoint passes an authentication token to Foxy. If the token is valid, the customer skips re-entering their email and password. For security, a saved credit card still requires the CSC unless your store is configured to only require it for new cards.

• Outgoing (“reverse”) SSO: after a transaction completes, Foxy can generate an authentication token from the receipt page and pass it to your site, logging the customer in automatically.

The basic flow for checkout SSO:

1. 1

   A customer creates an account or logs into your site.

2. 2

   Your site syncs that customer’s information to Foxy using the API.

3. 3

   When the customer starts checkout, Foxy redirects them to your SSO endpoint.

4. 4

   Your endpoint checks the customer’s authentication status on your site (using session or cookie data), then either sends them back to checkout authenticated, sends them back unauthenticated, or takes another action such as redirecting to a login or registration page.

Alternate uses

Beyond standard single sign-on, the same mechanism supports a few other scenarios:

• Making checkout entirely private, requiring authentication before purchase, for members-only stores or similar setups.

• Validating a customer’s cart before checkout, such as confirming order limits, applied discounts, or referrer and coupon values.

• Offering single-click upsells on the receipt, or logging a customer into your site automatically after checkout, using outgoing SSO.

Requirements

SSO requires a working site and Foxy setup that uses the API to keep your customer records synced with Foxy’s.

Identifying customers: email vs. customer ID

Foxy treats a customer’s email as a unique identifier, so no two customers in a store can share one. If your system allows customers to change their email, filtering by email may not capture a customer’s full purchase history, since past purchases stay tied to whatever email was active at the time. If your database can store custom attributes, store the Foxy customer ID alongside the customer record. Unlike email, it never changes, making it a more reliable long-term identifier.

Best practices

Allow checkout as a guest, or at least without requiring registration on your site first, whenever possible. This keeps the fewest hurdles between a customer and a completed purchase. Customers can still be synced on both sides either way: from your site to Foxy using the API, and from Foxy to your site using webhooks after checkout.

Notes

• SSO shouldn’t be combined with checkout pre-population to set customer values, since the two features can conflict. Combining them is possible but requires thorough testing before relying on it.