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

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.

#	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.
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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

---

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.

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.

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.

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.

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.

---

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.

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

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

---

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.

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.

Given a customer complaint of "I cannot log in":

1

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.

2

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.

3

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.

4

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.

---

10. Related documentation

• Dynamic Settings — full reference for each setting above.
• User Email Validation & Normalization — why the same address can exist on more than one account.