A customer signs out, hands a shared laptop to a colleague and returns later to a page that still displays the previous account’s name. Even when the underlying session is no longer valid, the interface has created doubt. For a June review of a headless Magento build, account state deserves the same design attention as the product grid. It affects both trust and the correctness of everyday work.
Give the customer a clear account identity
Show enough context for a person to recognise the account they are using, especially where a business supports multiple users or store views. A small generic avatar may not be sufficient. The person should not have to open a private document to find out whether they are in the intended account.
Magento’s versioned customer schema exposes account and token-related operations. A custom frontend must use those capabilities within a deliberate session design. The existence of an API operation is not a complete account experience, and a local interface flag should not be treated as authority to access a protected record.
Clear private state as part of sign-out
Consider the information held in visible components, application memory and any client-side persistence. Decide what should be removed or refreshed when the session ends. A sign-out operation that changes one token while leaving a detailed account screen on display can mislead the next person using the device.
Test back navigation, refresh and reopening the app after sign-out. The correct response may be a sign-in screen or an appropriate public page, with a clear explanation when necessary. Do not rely on the customer to know which old screen is harmlessly stale and which information is still accessible.
Handle expiry while work is in progress
A session can end while someone is filling out a form or reviewing an order. Explain what happened and provide a sensible route to continue after authentication. Preserve only the information appropriate to that task and avoid carrying private state into a different person’s session.
Where an operation was submitted near expiry, determine its actual result before inviting the customer to repeat it. Otherwise a useful recovery button can create duplicate work. The interface should distinguish an unsubmitted draft, a failed request and an operation whose outcome still needs to be checked.
Review isolation with realistic account changes
Use separate test accounts, different saved addresses and recognisably different baskets. Move through sign-in, sign-out, expiry and account switching on the intended browser and application architecture. Inspect both the visible result and the relevant API responses on a safe environment.
Account identity is a continuous part of the journey. It cannot be confined to the login page. When the frontend makes the active account and the end of a session unambiguous, customers can work with greater confidence and the team can reason more clearly about which information belongs to each request.
