> For the complete documentation index, see [llms.txt](https://docs.akinon.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akinon.com/technical-guides/commerce/guest-user-lifecycle.md). # Guest User Lifecycle A **guest user** is the customer account that Akinon Commerce creates when a shopper places an order without signing in. This guide covers how that account is created during checkout, how sign-in works for it, how it is converted into a full membership, what it can see, and when its data is anonymized. *** ## 1. Overview **Key characteristics:** * A guest user is a real customer account whose customer type is *Guest*. It is not an unidentified visitor — the account exists, with an order attached to it. * It is created **at order completion**, not when the shopper enters the checkout. * It is created with an **unusable password**, so no password will ever match. * Email-existence checks, and password reset by email or by phone, only consider registered accounts, so a guest is invisible to them. * The SMS one-time-code sign-in path is an exception: it does not narrow the match by account type, so a guest **can** sign in through it, subject to the email verification check described in section 4.2. * Immediately after checkout the guest **is** signed in, via the session created at order completion. This is what lets the order-success page show the order. The exception is a project that sets `ACCOUNT_EMAIL_VERIFICATION = "mandatory"` — a project-level setting, not a dynamic setting — while `SHOULD_SEND_VERIFICATION_EMAIL` is left enabled; then sign-in waits until the address is verified. See sections 4.1 and 8. * A guest can see **only its most recent order** (except the cancellation view — see section 6): the order list and order detail both resolve to it, and the legacy order endpoints return nothing. * Converting to a membership is a normal registration. There is no special "guest upgrade" endpoint. * Anonymization of a guest account is a **manual, explicit action**. Nothing expires or deletes guest records automatically. The three kinds of shopper this page refers to: | | Unauthenticated shopper | Guest account | Member account | | ----------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | When the account exists | No account exists yet; the email address and phone number given at checkout are kept in the session | Created at order completion (section 3.1, step 6) | Created by registration; registering with a guest account's email address converts that account (section 5) | | Password | Not applicable | Unusable; no password will ever match | The password given at registration | | Can sign in | Not applicable | Signed in by the session created at order completion, except in the configuration described in section 4.1; afterwards only by one-time code (sections 4.1 and 4.3) | Yes, by email and password once any required email verification is complete (section 5.2), or by one-time code (section 4.3) | | Orders it can see | Not applicable | Only the most recent order; the cancellation view resolves to the oldest; legacy order endpoints return nothing (section 6); any of its orders can also be looked up without signing in by order number and email address (section 6.1) | Its order history, including orders placed as a guest with the same email address (section 5.1) | *** ## 2. Lifecycle at a glance ```mermaid stateDiagram-v2 [*] --> Unauthenticated Unauthenticated --> Guest: order placed Guest --> Guest: another order, same email Guest --> Member: registers with the same email Guest --> Anonymized: anonymization requested Member --> Anonymized: anonymization requested ``` A guest account comes into existence when an unauthenticated shopper places an order, and further orders with the same email address reuse it (section 3.2). Registering with that email address converts it into a member account in place (section 5). Either kind of account is anonymized only by an explicit request (section 7.2). *** ## 3. Guest checkout flow Checkout is a chain of pages. The order of the steps is not a fixed list: each page determines which page follows it, and checkout moves forward along the chain, skipping pages whose conditions are already satisfied. ### 3.1 Step by step The diagram follows an unauthenticated shopper through the steps in the table below. ```mermaid flowchart TD A[Shopper enters checkout] --> B{"Step 0: CAN_GUEST_PURCHASE enabled?"} B -- No --> L[Sent to the login page] B -- Yes --> C["Step 1: email address and phone number"] C --> P{"Phone verification on and number not yet verified?"} P -- Yes --> V["One-time code sent to the number and entered"] P -- No --> D V --> D{"Email or phone already on a registered account?"} D -- Yes --> R[Shopper asked to sign in] D -- No --> E{"More than one active delivery option?"} E -- Yes --> F["Step 2: delivery option"] E -- No --> G["Step 3: address"] F --> G G --> H["Step 4: shipping and payment options"] H --> I["Step 5: payment"] I --> J{"Step 6: guest account with this email already?"} J -- No --> K[Guest account created] J -- Yes --> U[Existing guest account reused] K --> S["Step 7: order success page"] U --> S ``` | # | Step | What happens for a guest | | - | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | Entering checkout | If `CAN_GUEST_PURCHASE` is disabled and the shopper is not authenticated, checkout continues on the login page. | | 1 | Basket / index | The shopper supplies an email address and a phone number. For an unauthenticated shopper these are stored **in the session**, not against a customer account — no account exists yet. If the shopper is not signed in and the email address already belongs to a registered account, the step responds with *"This email already in use. You can login to continue."* and the shopper continues by signing in. A phone number already recorded on a registered account is handled the same way. An email address or phone number that belongs only to a guest account is accepted. When guest phone verification is enabled (the `checkout-phone` entry of `VERIFICATION_TOKEN_CONF`; disabled by default), a phone number entered here is accepted once the shopper has confirmed it with a one-time code sent by text message to that number; until then the step responds with *"Phone number is not verified."* A number verified once in the session is not asked for again, a changed number is. Without a phone number the step needs no code, and signed-in members are not asked. See [How to Verify Guest Phone Numbers at Checkout](https://docs.akinon.com/tutorials/commerce/how-to-verify-guest-phone-numbers-at-checkout). | | 2 | Delivery option | Shown only when more than one delivery option is active. A delivery option restricted to registered users is not available to a guest or to an unauthenticated shopper. | | 3 | Address | The shipping and billing addresses are created. Address identifiers touched by an unauthenticated shopper are tracked in the session for a limited time; see section 7.1. Phone verification for address phone numbers (the `address-phone` entry of `VERIFICATION_TOKEN_CONF`) applies to registered members only; a guest or an unauthenticated shopper is not asked for a code at this step. | | 4 | Shipping / payment options | A shipping option or payment option restricted to registered users is not available to a guest or to an unauthenticated shopper. | | 5 | Payment | Saving a card is available to registered accounts. For a guest or an unauthenticated shopper the response carries *"Register and then continue to checkout in order to save credit card."* and checkout continues without saving the card. A 3-D Secure rule can be configured to apply to guests and unauthenticated shoppers only. Wallet-style payment methods that link stored cards to a customer do not link them to a guest or an unauthenticated shopper. | | 6 | **Order creation** | If the checkout has no customer account attached, a **guest user is created now** from the shipping address (first name, last name, email) plus the phone number captured in step 1. The shopper is signed in as part of this, except in the configuration described in section 4.1 (`ACCOUNT_EMAIL_VERIFICATION = "mandatory"` with `SHOULD_SEND_VERIFICATION_EMAIL` enabled). | | 7 | Order success | The success page indicates whether the account has a usable password, and provides an API token for it. A guest account — new or reused — never has one. Storefronts use this to offer "create an account". | ### 3.2 What the guest account looks like The account created at step 6 has: | Property | Value | Why it matters | | ------------------------- | ---------------------------------------------- | --------------------------------------------------------------------- | | Customer type | Guest | Every guest-specific rule keys off this. | | Password | **Unusable** | No password will ever authenticate this account. | | Email | The shipping address email | Stored as submitted. | | Phone | The phone from step 1, **if one was supplied** | May be empty. | | Email verification status | Requires verification | Used by the conversion flow and by sign-in; see sections 4.2 and 5.2. | | API token | Created | Used by the storefront for the immediate post-order session. | {% hint style="info" %} **Reuse of a guest account.** If an order is placed again later with the **same email address**, the existing guest account is reused rather than a second one being created, **for as long as that account is still a guest**. When the account is reused, its name is replaced with the name on the new order's shipping address, its email and SMS permissions are switched off, its call permission is cleared, and its phone number is replaced if the new order includes one. Once it has been converted to a membership (section 5) it is no longer reused: the address now belongs to a registered account, so a shopper who is not signed in is asked to sign in at step 1 of checkout (section 3.1). {% endhint %} The "is this email already taken?" check does not see guest accounts, which is why registering with the same email address later is allowed at all. What happens next is not a second account, though: see section 5. *** ## 4. Signing in with a guest account ### 4.1 The session after checkout Immediately after checkout the shopper is signed in as the guest account, through the session created at order completion. The storefront uses the account's API token for this post-order session, and the session is what lets the order-success page and the order detail page show the order without a login (section 6). It lasts for the rest of that browser session. The exception is a project that sets `ACCOUNT_EMAIL_VERIFICATION = "mandatory"` — a project-level setting, not a dynamic setting — while `SHOULD_SEND_VERIFICATION_EMAIL` is left enabled; then sign-in waits until the address is verified. See section 8. Once that browser session ends, there is no way back in through the normal sign-in paths — see section 4.2. The account has no password to sign back in with. Sign-in by one-time code is covered in section 4.3. ### 4.2 Sign-in paths A guest account is created **without a usable password and without a discoverable email address**, so none of the normal sign-in or password-recovery paths can find it. Sign-in does not check whether an account is a guest. The behaviour follows from how the account is created and which accounts each sign-in path considers. The response a shopper receives is the standard credentials message, *"Unable to log in with provided credentials."*, not "this is a guest account". | Sign-in path | Can a guest use it? | Reason | | ---------------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email + password | No | The account is created with an **unusable password**. No submitted password matches it, so this path does not sign the account in. | | "Is this email registered?" checks | No | These checks only consider registered accounts. A guest email reads as *not registered* — which is also why registering with that email is accepted — see section 5. | | Password reset by email | No | Password reset by email only considers registered accounts, so no reset email is sent. | | Password reset by phone | No | Password reset by SMS only considers registered accounts. | | SMS one-time code (OTP) login | See section 4.3 | Sign-in by one-time code matches **on the phone number among active accounts**, not on account type. | {% hint style="warning" %} **The email verification gate also applies to sign-in.** When `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` is enabled, sign-in by email and password and sign-in by one-time code both wait for verification on an account that is marked as requiring it and whose email address is not verified; the response is *"Please verify your email address before login."* Accounts created at guest checkout carry that mark (section 3.2) and keep it after conversion; other accounts are not affected. {% endhint %} Messages in this guide are quoted in English. The response uses the project's language, so a shopper may see a translation. ### 4.3 Sign-in by one-time code Sign-in by one-time code does not narrow the match by account type. In principle, a guest account that has a phone number recorded, and whose phone number is unique across active accounts, can therefore be signed in with a one-time code. It is the only path in section 4.2 that a guest can use. Two conditions limit this in practice: * A guest account only has a phone number if one was captured at checkout; it is optional. * If the same phone number exists on both a guest account and a registered account, and both are active, the number matches more than one account, so this path does not select either of them and responds with "Unable to log in with provided credentials." * When `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` is enabled, the verification check in section 4.2 applies: a guest whose email address is not verified receives *"Please verify your email address before login."* and signs in once the address is verified. With the setting disabled (the default), or once the address is verified, the guest is signed in. A later guest order with the same email address and a different phone number replaces the number on the guest account; the earlier number then no longer finds it. Signing in with a one-time code does not convert the account. It remains a guest account, so the order visibility described in section 6 still applies. The shopper can view and update their profile details. To become a member, the shopper registers as described in section 5. ### 4.4 Becoming a member To return as a recognised customer the shopper must **register** — an account creation, not a sign-in — using the same email address they gave at checkout. The registration is accepted — the duplicate-email check does not see guest accounts — and it converts their existing guest account into a member account, order history included. See section 5. *** ## 5. Converting a guest into a member There is **no dedicated "convert guest to member" endpoint.** Conversion is an ordinary registration against the standard registration endpoint. ```mermaid sequenceDiagram participant S as Shopper participant F as Storefront participant C as Commerce registration S->>F: Registers with the guest email address F->>C: Registration request C->>C: Existing guest account found C->>C: Account converted in place C->>C: Email verification gate alt Gate disabled C-->>F: 201 else Gate enabled C-->>F: 400, please verify your email address end ``` The gate is `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION`; section 5.2 describes both responses. ### 5.1 What happens When the shopper registers with **the same email address** as their guest account: 1. The "is this email already taken?" check does not see guest accounts, so the registration is accepted. 2. The registration then looks specifically for a **guest** account with that email address, finds it, and writes the new registration onto **that same account** — name, password, phone number, contact permissions, gender, date of birth, language and account type. The phone number is replaced with the one on the registration form, and cleared if the form sends none; this decides whether one-time-code sign-in can find the account afterwards (section 4.3). 3. No second account is created. The guest account *becomes* the member account. This is the important consequence: because it is the same account, **the orders placed as a guest stay with the shopper** and appear in their order history as a member. If the shopper registers with a **different** email address, none of the above applies: an ordinary new account is created, and the guest account — along with its orders — remains separate. {% hint style="info" %} **Phone number uniqueness.** When `PHONE_NUMBER_UNIQUE_VALIDATOR_ACTIVE` is enabled, the registration form checks the phone number against every active account, the guest account included. A registration that sends the phone number already recorded on the guest account therefore responds with *"Phone number is already in use with another account."*, and the account stays a guest. The shopper completes the registration by leaving the phone number out or by giving a different one; the phone number can be added to the profile afterwards. With the setting disabled (the default), registration with the same phone number converts the account as described above. {% endhint %} ### 5.2 The email verification gate `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` decides whether a converted account whose email address is not yet verified may be used immediately: | Setting | Registration response | What the shopper must do | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Disabled (default) | `201`. It carries an authentication key and the shopper is signed in — unless the project sets `ACCOUNT_EMAIL_VERIFICATION = "mandatory"`, in which case the `201` carries no authentication key and the shopper is not signed in. At registration this applies whatever `SHOULD_SEND_VERIFICATION_EMAIL` is set to. | Nothing — or, under `"mandatory"`, verify the address, then sign in | | Enabled | `400`, with the message *"Please verify your email address before login."* and no authentication key. The registration is still saved. | Open the confirmation email — or, if the shopper registers within the interval described below the table, the one sent with the order — verify the address, then sign in. Until then, sign-in by email and password or by one-time code responds with the same message. | {% hint style="warning" %} **Note for integrators:** when the gate is enabled, the `400` response means the registration has been saved and is waiting for email verification. The account has already been converted to a member account; the response only signals that sign-in waits until the email address is verified. {% endhint %} In both cases the registration **sends confirmation email** to an unverified address: * With `ACCOUNT_EMAIL_VERIFICATION` set to `"optional"` (the default) or `"mandatory"`, the shopper receives **two** emails at registration: the confirmation email for the converted account, and the welcome email for the new member, which also asks for verification. Either one verifies the address. * With `ACCOUNT_EMAIL_VERIFICATION` set to `"none"`, only the first of the two is sent. {% hint style="info" %} **Confirmation email interval.** The confirmation email for the converted account is not sent to the same address again within a short interval — three minutes by default, set by the project-level setting `ACCOUNT_EMAIL_CONFIRMATION_COOLDOWN`. The welcome email is sent regardless. A shopper who registers within that interval after the confirmation email sent with the order therefore receives one email at registration — the welcome email — or none under `"none"`. The email sent with the order can still be used to verify the address. {% endhint %} {% hint style="info" %} **What `SHOULD_SEND_VERIFICATION_EMAIL` governs.** It acts only at the moment the guest account is first created, at checkout — see section 8 for its full effect there. It does not change the registration response described above; its only link to registration is that an email it sent at checkout counts toward the interval above. The two settings act at different moments and do not combine to keep a shopper out: a shopper who registers receives an email they can verify with, or already received one with the order. {% endhint %} *** ## 6. What a guest account can see Immediately after checkout the shopper is signed in as the guest account — except under the mandatory email-verification configuration described in section 4.1 — which is how the order-success page and the order detail page work without a login. That access is narrow: | Endpoint | Guest behaviour | | ---------------------------- | --------------------------------------------------------------------------------- | | Order list | Returns **only the single most recent order**. | | Order detail | Always resolves to the most recent order, regardless of which order is requested. | | Cancellation view | Resolves to the **oldest** order on the account, not the most recent. | | Legacy order list and detail | Return **nothing**. | The cancellation view only differs from the other two when a guest account holds more than one order (see section 3.2); with a single order — the normal case — all three views resolve to the same one. ### 6.1 Looking up an order without signing in A guest does not need to sign in to follow an order. The anonymous order lookup (`POST /users/orders/anonymous/`) returns the order when the request carries the order number and the email address given at checkout. It works this way: * The order number is sent in the `number` field. * The email address matches the one on the order; letter case is ignored. * By default, only orders that belong to a guest account are returned. Once the account has been converted into a membership (section 5), the shopper signs in and finds the same orders in their order history instead. When `ALLOW_ANONYMOUS_ACCESS_TO_REGISTERED_ORDERS` is enabled, orders of member accounts are returned as well, and cancellation and return requests made the same way accept them too. The same lookup is the entry point for cancellation and return requests on a guest order. See *API Reference → Commerce → Users → Anonymous User Orders & Cancellations*. *** ## 7. Anonymous data and anonymization Two separate mechanisms govern anonymous data. Neither one deletes guest orders. ### 7.1 The anonymous address session window While a shopper is unauthenticated, the identifiers of the addresses they create or edit during checkout are kept **in their session**, so that the same browser session can continue to read and edit those addresses. `ANONYMOUS_ADDRESS_EXPIRE_SECONDS` sets how long that session reference stays valid (default: 1800 seconds). The timer is refreshed whenever an address is added, changed or deleted in the session. Once it lapses, the session stops returning those address identifiers. {% hint style="info" %} **This setting does not delete anything.** It controls visibility through the session only. The address rows remain in the database, attached to the order, unchanged. {% endhint %} ### 7.2 Anonymization Anonymization is an explicit, manual action. An operator requests it from the customer record or through the anonymization endpoint; where `SELF_ANONYMIZATION_ENABLED` is enabled, a signed-in shopper — guest or member — can also request it for their own account. With the setting disabled (the default), the self-service request responds with `403`. **There is no scheduled job and no automatic expiry.** A guest account and its order data persist until someone anonymizes them. ```mermaid flowchart TD A[Anonymization requested] --> B{"Open order in a blocking status?"} B -- Yes --> C["Waits until those orders are completed"] B -- No --> D[Anonymization applied] D --> E["Account deactivated, orders kept"] ``` When an account is anonymized: | Data | What happens | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email address and username | The part before the `@` is replaced with a hash; the domain is kept | | First name, last name, phone | Replaced with hashes | | Password | Replaced with a random value | | Account state | Marked as anonymized and **deactivated** | | Audit trail | The operator's id, the timestamp, and whether the anonymization was self-service or operator-triggered are recorded on the account | | Registered email addresses | Each one is hashed the same way as the account email | | Social account links | Deleted | | Addresses | First name, last name, phone number, address line, title, company name, tax number, tax office and text values in extra fields are replaced with random values; the address email is hashed the same way as the account email | | Transactions | For payment, pay-on-delivery, loyalty, cash-register and BKM Express transactions, the email is hashed and raw request and response payloads are cleared | | Bank transfer records | The email is hashed; account holder name and IBAN are replaced | **Not changed by anonymization:** * On addresses: the identity number, the postcode, the delivery notes, and the country, city, township and district. * On orders: the order's own copy of the customer's email address, the IP address recorded on the order, the order notes, the gift-box note and extra fields. * On legacy orders: the customer's email address and the shipping and billing address text. * On order requests: the first name, last name, phone number and email address. * On transactions: the IP address recorded on the transaction, and the email on B2B transactions. This list names the fields on addresses, orders, order requests and transactions that come up most often in support; it is not a complete inventory of what anonymization leaves unchanged. Other records linked to a customer are outside the scope of this page. Orders themselves are **not deleted**. They remain attached to the anonymized account, and the order fields listed above keep their values. ### 7.3 When anonymization waits for open orders Anonymization is applied once the account has no order in any of these states: Cancellation waiting, Waiting, Payment waiting, Confirmation waiting, Approved, Preparing, Ready for pickup. While such an order exists, the response reports an uncompleted order; the request can be repeated once those orders reach a final state. {% hint style="info" %} **Guest accounts can be anonymized.** The restriction above is about open orders, not about account type. If a guest customer does not appear in an anonymization list, that is a filter in the listing being used, not a limitation of anonymization itself. {% endhint %} *** ## 8. Configuration reference | Setting | Default | Where it takes effect | Effect | | ----------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `CAN_GUEST_PURCHASE` | `true` | Step 0 of the flow (section 3.1) | Master switch. When disabled, an unauthenticated shopper continues on the login page, and checkout starts once they sign in. | | `SHOULD_SEND_VERIFICATION_EMAIL` | `true` | Order creation, step 6 (sections 3.1 and 5.2) | Whether a verification email is sent when the guest account is created at checkout. It does not change the registration response; registration sends its own confirmation email, except that an email sent at checkout counts toward the interval described in section 5.2. Disabling it also drops the email-verification requirement applied at order creation, which neutralises `ACCOUNT_EMAIL_VERIFICATION = "mandatory"` for that sign-in. | | `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` | `false` | Registration, and sign-in by email and password or by one-time code (sections 4.2, 4.3 and 5.2) | When enabled, registration against a guest account returns `400`, and an account marked as requiring verification — in practice, one created at guest checkout — signs in by email and password or by one-time code once its email address is verified. | | `ANONYMOUS_ADDRESS_EXPIRE_SECONDS` | `1800` | Address step (section 7.1) | How long the session keeps its reference to addresses created while unauthenticated. **Does not delete data.** | | `ALLOW_ANONYMOUS_ACCESS_TO_REGISTERED_ORDERS` | `false` | Anonymous order lookup and cancellation (section 6.1) | Whether orders of member accounts can be looked up, cancelled and returned without signing in, by order number and email address. Disabled: only orders of guest accounts are accepted. Enabled: orders of both guest and member accounts are accepted; the email address must still match the one on the order. | | `CHECKOUT_WITH_TOKEN_ALLOW_ANONYMOUS` | `false` | Token-based checkout entry — not otherwise covered in this guide | Whether a checkout link issued with a token may be opened by a visitor who is not signed in. Disabled: a token tied to a customer sends the visitor to the login page, and a token with no customer returns `404`. Enabled: a token tied to a customer signs the visitor in as that customer, and a token with no customer opens checkout when the visitor has a session (otherwise `404`). A visitor who is already signed in continues only with a token tied to that same customer. With a token tied to a different customer the visitor is signed out and the response is `401`, whatever the setting. With a token with no customer the response is `404` and the visitor stays signed in when the setting is disabled; when it is enabled, the visitor is signed out and the response is `401`. | Four other settings affect the flow without appearing in this table: * `ACCOUNT_EMAIL_VERIFICATION` is a project-level setting rather than a dynamic setting. Set to `"mandatory"`, it holds back both the sign-in performed at order creation and the one performed at registration until the address is verified — see sections 3.1, 4.1 and 5.2. At order creation only, disabling `SHOULD_SEND_VERIFICATION_EMAIL` cancels that hold, because it clears the verification requirement before the sign-in is attempted. * `PHONE_NUMBER_UNIQUE_VALIDATOR_ACTIVE` (default `false`) decides whether registration against a guest account may reuse the guest's own phone number (section 5.1). * `SELF_ANONYMIZATION_ENABLED` (default `false`) decides whether a signed-in shopper, guest or member, can anonymize their own account (section 7.2). * `VERIFICATION_TOKEN_CONF` — its `checkout-phone` entry (disabled by default) decides whether a guest confirms the phone number with a one-time code at step 1 (section 3.1). ### 8.1 How the settings combine * `CAN_GUEST_PURCHASE` disabled ⇒ nothing else in this table matters; there are no guest accounts to govern. * `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` and `SHOULD_SEND_VERIFICATION_EMAIL` act at different moments and do not combine to keep a shopper out. See section 5.2. * `ANONYMOUS_ADDRESS_EXPIRE_SECONDS` is unrelated to the other settings. It governs session visibility during checkout, not account lifecycle. * `ALLOW_ANONYMOUS_ACCESS_TO_REGISTERED_ORDERS` only widens the anonymous order lookup and cancellation (section 6.1) to member accounts; it does not affect guest checkout. {% tabs %} {% tab title="At checkout" %} When an order creates a new guest account, the outcome depends on `ACCOUNT_EMAIL_VERIFICATION` and `SHOULD_SEND_VERIFICATION_EMAIL`. `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` plays no part at this moment. | `ACCOUNT_EMAIL_VERIFICATION` | `SHOULD_SEND_VERIFICATION_EMAIL` | Signed in after the order | Verification email sent | | ---------------------------- | -------------------------------- | ------------------------------------------------ | ----------------------- | | `"optional"` (default) | Enabled | Yes | Yes | | `"optional"` (default) | Disabled | Yes | No | | `"mandatory"` | Enabled | No — sign-in waits until the address is verified | Yes | | `"mandatory"` | Disabled | Yes | No | | `"none"` | Enabled | Yes | No | | `"none"` | Disabled | Yes | No | | {% endtab %} | | | | {% tab title="At registration" %} When a shopper registers against a guest account whose email address is not yet verified, the outcome depends on `ACCOUNT_EMAIL_VERIFICATION` and `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION`. `SHOULD_SEND_VERIFICATION_EMAIL` does not change the response or the key; an email it sent at checkout counts toward the interval described in section 5.2. "Emails sent" assumes no confirmation email reached the same address within that interval; otherwise one fewer is sent at registration. | `ACCOUNT_EMAIL_VERIFICATION` | `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` | Response | Authentication key | Emails sent at registration | | ---------------------------- | ----------------------------------------------------- | -------- | ------------------ | --------------------------- | | `"optional"` (default) | Disabled | `201` | Yes | Two | | `"optional"` (default) | Enabled | `400` | No | Two | | `"mandatory"` | Disabled | `201` | No | Two | | `"mandatory"` | Enabled | `400` | No | Two | | `"none"` | Disabled | `201` | Yes | One | | `"none"` | Enabled | `400` | No | One | | {% endtab %} | | | | | | {% endtabs %} | | | | | *** ## 9. Troubleshooting sign-in issues A recurring support question is why a customer who placed a guest order cannot sign in afterwards. In most cases the answer is that the customer placed an order as a guest, and a guest account has no usable password and no discoverable email address, so none of the normal sign-in or password-recovery paths can find it (section 4.2). The steps below confirm whether the customer is a guest and whether the behaviour they report is expected. {% hint style="info" %} **The symptom as it appears in support tickets.** A shopper whose phone number exists on both a guest account and a registered account receives *"Unable to log in with provided credentials."* even though both the number and the code were correct (section 4.3). Storefronts often render this as wording of their own — "phone number or code is incorrect", for example — which is why the complaint usually describes the code as not accepted. {% endhint %} Given a customer complaint of "I cannot log in": {% stepper %} {% step %} **Identify the sign-in path** If the shopper was using the SMS one-time code, start from the phone number (step 2). Otherwise, go to step 3 and read the account type from the customer record. {% endstep %} {% step %} **One-time code: start from the phone number** Search for accounts carrying that number, then read off which case applies: * **More than one active account has it.** That duplicate is the cause — see section 4.3 — and this is the expected behaviour. The duplicate must be resolved on the accounts themselves; meanwhile the registered account can still be signed into with its email address and password. If the registration form carries a phone number and `PHONE_NUMBER_UNIQUE_VALIDATOR_ACTIVE` is enabled, registration responds with *"Phone number is already in use with another account."* for the same reason (section 5.1). * **Exactly one active account has it, and it is a guest.** If `GUEST_USER_REGISTRATION_REQUIRES_EMAIL_VERIFICATION` is enabled and the response reads *"Please verify your email address before login."*, the guest's email address is not verified yet (see section 4.3). Otherwise the one-time code should work for a guest, so guest status does not explain this response; raise a support request with the phone number and the time of the attempt. * **No account has it.** Either no phone number was captured at checkout — it is optional, see section 4.3 — or a later guest order with the same email address replaced it with a different number, also described in section 4.3. No one-time code can reach the shopper through this number. In the second case the newer number is subject to the conditions in section 4.3; otherwise the shopper registers as described in section 4.4. The one-time-code checks end here. {% endstep %} {% step %} **Confirm whether the account is a guest** Find the customer record and read its account type. The customer detail screen shows this as the customer type; a value of *Guest* confirms the account was created by a guest checkout. Every guest account is created without a usable password, so no password and no password-reset path applies to it. {% endstep %} {% step %} **Tell the shopper what to do** If step 3 shows a guest account, this is how guest accounts work. Two options are open to the shopper: * To follow an existing order, look it up with the order number and the email address given at checkout (section 6.1). No sign-in is needed. * To sign in from now on, register with the same email address given at checkout, as described in section 4.4. The guest orders move into the new member's order history. {% endstep %} {% endstepper %} *** ## 10. Related documentation * [Dynamic Settings](/technical-guides/commerce/dynamic-settings.md) — full reference for each setting above. * [User Email Validation & Normalization](/technical-guides/commerce/user-email-validation-and-normalization.md) — why the same address can exist on more than one account. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akinon.com/technical-guides/commerce/guest-user-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.