Guest Order Data Appearing in a Registered Shopper's Account (Order placed via SCAPI)

To prevent guest order data from appearing in a shopper's registered account, merchants must rotate the guest session immediately after a guest order is placed. The root cause is that SLAS can reassign an existing guest customer_id to a newly registered user if the session is not rotated at checkout - so the fix is to request a fresh guest token the moment order confirmation is received.

Important: The solution below assumes session rotation is executed immediately after POST /orders succeeds - before any further storefront activity and before any registration flow begins. Additional trigger points are covered at the end of this section. If rotation is deferred, the guest customer_id may still be reassigned during registration.

Follow the flow below to implement session rotation:

Trigger: POST /orders succeeds (order confirmed). Execute Steps 1 and 2 immediately.

Step 1: Get a fresh guest token

POST /shopper/auth/v1/organizations/{organizationId}/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&channel_id={siteId}

Response: new access_token, refresh_token.

Step 2: Swap tokens in the storefront

Replace the stored access_token and refresh_token with the values returned in Step 1. All subsequent SCAPI calls use the new session.

The green box shows Steps 1 and 2 above. The diagram also shows:

• The trigger (POST /orders → order confirmed) - the exact point at which rotation must begin
• The registration flow - once rotation is complete, GET /customers/{id}/orders on the new registered profile returns an empty list, confirming the guest orders are cleanly isolated

Note: The ideal trigger points(in order of preference)

• After order confirmation - immediately after POST /orders succeeds. This is the recommended and strongest boundary - execute rotation here whenever possible.
• After payment completion - applicable when using a multi-step checkout with deferred order creation, where the order is not created until after payment.
• On logout (weak fallback only) - SLAS handles session termination via /logout, but this is not a reliable mitigation on its own, as guests frequently register without explicitly logging out first.