> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Customer, login, and customer account

> The shop.config sections related to the buyer: login and registration, password rules and password strength indicator, persistent login, stored customer data, input validation, and the WelcomeBack function.

Whether a buyer has to log in at all, how secure their password needs to be, how long they stay logged in, and what the shop stores about them: the sections on this page answer these questions. They are more closely related than their separation in the configuration suggests.

The starting point is the `Login` section, because it determines whether the shop has a login at all. Everything else builds on it.

Reference: Shop configuration shop.config, overview of all sections

## Login

Determines whether and when a buyer has to log in, and controls the double opt-in procedure during registration.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<Login>
   LoginMode                              = no
   LoginAllSubshops-Allow                 = no
   SubshopLogin-Allow                     =
   LoginWithDoubleOptIn-Allow             = no
   NewCustomerDoubleOptInMode             = required
   NewCustomerResendDoubleOptInMail-Allow = no
   QuickLoginErrorDestinationPage         = notify
   MaxUserOrderQuantity-Allow             = no
</Login>
```

### Login requirement

| Parameter | Purpose | Values |
| - | - | - |
| `LoginMode` | When a login is required. | `no`, `start`, `order`, `order-loginrequired`. Default `no` |

| Value | Meaning |
| - | - |
| `no` | No login required, guest orders are possible |
| `start` | Login required when entering the shop, that is, a closed shop |
| `order` | Login required only when placing the order |
| `order-loginrequired` | Login required when placing the order, with no alternative |

> [!NOTE]
>
> `order-loginrequired` is not listed in the previous documentation, but the shop system evaluates it. Any value other than the four listed silently results in `no`, that is, an open shop. A typo in this parameter therefore opens a closed shop without a warning appearing anywhere.

> [!NOTE]
>
> With `LoginMode = start`, the shop system reads the cookie shopping cart only after login. A buyer who added something to the cart before logging in will therefore only find it again afterwards.

### Subshops

| Parameter | Purpose | Values |
| - | - | - |
| `LoginAllSubshops-Allow` | Allows existing customers to log in to any subshop instead of only the one they registered in. | `yes`, `no`. Default `no` |
| `SubshopLogin-Allow` | Subshops in which a **newly** registered customer can also log in. Empty means no additional subshops. | comma-separated list of subshop IDs |

> [!WARNING]
>
> `SubshopLogin-Allow` affects new registrations only. Existing accounts are not retroactively assigned the additional subshops. The parameter name does not suggest this, but the behavior is intentional.

### Double opt-in

| Parameter | Purpose | Values |
| - | - | - |
| `LoginWithDoubleOptIn-Allow` | Enables the double opt-in procedure for new registrations and address changes. | `yes`, `no`. Default `no` |
| `NewCustomerDoubleOptInMode` | Type of procedure for new registrations. | `required`, `voluntary`, `off`. Default `required` |
| `NewCustomerResendDoubleOptInMail-Allow` | Resends the activation email when someone tries to log in to an account that has not yet been activated. | `yes`, `no`. Default `no` |
| `ChangeEmailDoubleOptInSendTo` | Sends the confirmation email for an address change to the **old** address instead of the new one. | `OldEmailAddress`. Default empty |

| Value of `NewCustomerDoubleOptInMode` | Meaning |
| - | - |
| `required` | All new accounts must confirm their email address |
| `voluntary` | New accounts confirm voluntarily, but new multiple accounts must confirm |
| `off` | New accounts do not confirm at all, but new multiple accounts must confirm |

> [!WARNING]
>
> An email address for which an unconfirmed account exists currently cannot be used again. The buyer can then only continue with a different address. Set `NewCustomerResendDoubleOptInMail-Allow` to `yes` so that they can at least request the activation email again.

> [!NOTE]
>
> `ChangeEmailDoubleOptInSendTo` is not listed in the previous documentation. Sending to the old address is the more secure option, because only the owner of the existing mailbox can then confirm the change.

### Other parameters

| Parameter | Purpose | Values |
| - | - | - |
| `QuickLoginErrorDestinationPage` | Destination page after a failed QuickLogin. | `notify`, `login`. Default `notify` |
| `MaxUserOrderQuantity-Allow` | Enables the customer-specific order quantity limit. | `yes`, `no`. Default `no` |
| `MaxUserOrderQuantitySubshop` | Subshop whose quantity limit is used. | subshop ID |
| `NewCustomerRegistrationCodeRequired-Allow` | Requires an activation code for new registrations. | `yes`, `no`. Default `no` |
| `NewCustomerBillingAddressRequired-Allow` | Requires the billing address already during new registration. | `yes`, `no`, `test`. Default `no` |
| `CustomerWithLoginCanOrderWithoutLogin-Allow` | With `no`, a guest order is rejected if an account already exists for the email address. | `yes`, `no`. Default `yes` |
| `ExternalDownloadPW` | Password for the external download. | string |
| `RefererURL` | Filter on the calling address. If it does not match, the request is rejected. | string |
| `IP-Addresses` | Filter on the visitor's IP address. | list of addresses |
| `TFA-PendingTimeoutMinutes` | How long a started two-factor login remains valid. | integer 1 to 60. Default 10 |
| `TFA-TOTPIssuerName` | Name under which the shop appears in the buyer's authenticator app. | string |

> [!NOTE]
>
> None of these parameters is listed in the previous documentation. `RefererURL` and `IP-Addresses` only apply to the first request of a session and, on a match, lead to a notice page rather than a silent rejection.

> [!WARNING]
>
> The deprecated parameter `DisableNewCustomerDoubleOptIn` is only evaluated if `NewCustomerResendDoubleOptInMail-Allow` **does not appear at all** in the configuration. As soon as that parameter is set, even to `no`, the shop system ignores the old parameter. Instead of `DisableNewCustomerDoubleOptIn`, use the value `off` in `NewCustomerDoubleOptInMode`.

Guide: Login/registration, Double opt-in, Order quantity of a product, Cross-subshop logins, Secure login procedure

## SecureLogin

The most extensive section on this page. It determines how secure a password must be, when access is blocked after failed attempts, how the email address is validated, and it holds the related error messages.

On top of that comes the password strength indicator. It rates a password as red, yellow, or green while it is being entered. For this purpose, each threshold exists twice: once as the red threshold, below which the password is rejected, and once as the yellow threshold, from which the indicator switches to green.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<SecureLogin>
   Allow                              = yes
   PWMinLength-Value                  = 8
   PWMinCharacters-Value              = 2
   PWMinNumerics-Value                = 2
   PWMinSpecialCharacters-Value       = 0
   PWMinLowerCaseCharacters-Value     = 0
   PWMinUpperCaseCharacters-Value     = 0
   PWMaxSuccessiveNumerics-Value      = 0
   PWRepeatedSignsFault-Value         = 4
   Email-PWSimilaritySignsFault-Value = 4
   PWBlackListedStrings-List          = qwertz,passwort,shopname
   DenySimplePasswordLevel            = 0
   MaxLoginFaults-Value               = 3
   BlockingTime-Value                 = 10
   DetectionTime-Value                =
   EmailCheckMode                     = domain
</SecureLogin>
```

> [!WARNING]
>
> In the shop system, the parameter for the minimum length is named `PWMinLenght-Value`, with transposed letters. The shop system reads this spelling first and only falls back to the correctly spelled `PWMinLength-Value` if the first line is missing. Both spellings therefore work, but **not at the same time**: if the misspelled line is in the configuration, it wins. The same applies to `PWMinLenght-Yellow-Value`.

### Password requirements

| Parameter | Purpose | Values |
| - | - | - |
| `Allow` | Enables the secure login procedure. | `yes`, `no` |
| `PWMinLength-Value` | Minimum length of the password. | 1 to 64. Default 6. Recommended at least 6 |
| `PWMinCharacters-Value` | Minimum number of letters. | integer. `0` disables. Default 0, recommended 2 |
| `PWMinNumerics-Value` | Minimum number of digits. | integer. `0` disables. Default 0, recommended 2 |
| `PWMinSpecialCharacters-Value` | Minimum number of special characters. Anything other than letters and digits counts as a special character. | integer. `0` disables. Default 0, recommended 2 |
| `PWMinLowerCaseCharacters-Value` | Minimum number of lowercase letters. | integer. `0` disables. Default 0 |
| `PWMinUpperCaseCharacters-Value` | Minimum number of uppercase letters. | integer. `0` disables. Default 0 |
| `PWMaxSuccessiveNumerics-Value` | Maximum number of consecutive digits. | integer. `0` disables. Default 0 |
| `PWRepeatedSignsFault-Value` | Number of identical consecutive characters from which the password is rejected. With `4`, `abc1111` fails. | 2 to 16. Any other value disables the check. Recommended 4 or higher |
| `Email-PWSimilaritySignsFault-Value` | How many identical consecutive characters the email address and password may share. With `4`, `abc222@xyz.de` and `c222Yz` fail, because `c222` appears in both. | 3 to 16. Any other value disables the check. Recommended 4 or higher |
| `PWBlackListedStrings-List` | Strings that must not appear in the password. | comma-separated list |
| `DenySimplePasswordLevel` | Detects systematic passwords, see below. | 0 to 32. `0` disables. Default 0 |

> [!WARNING]
>
> Values outside the permitted range disable the check instead of being clamped to the limit. With `PWRepeatedSignsFault-Value = 1` or `= 20`, **no** check takes place. The minimum length is an exception: it is set to 6 at 0 and capped at 64 if it exceeds 64.

### DenySimplePasswordLevel

This check finds systematic passwords such as `1234` or `86420`. The level corresponds to the number of permitted one- and two-character steps between consecutive characters. A one-character step lies between `ab`, `ba`, `89`, or `98`; a two-character step between `CE`, `ZX`, `24`, or `75`.

| Password | Steps | Rejected at level |
| - | - | - |
| `1234` | three one-character steps: 12, 23, 34 | 1, 2, and 3 |
| `86420` | four two-character steps: 86, 64, 42, 20 | 1, 2, 3, and 4 |
| `mode43` | two one-character steps (de, 43) and one two-character step (mo) | 1 and 2 |

> [!WARNING]
>
> Level `1` offers the highest security, but restricts the choice of password so much that it can hardly be explained to the average buyer. The legacy documentation therefore recommends `0`, that is, disabling the check. If you want to use it, 3 or 4 gives you high security with still acceptable usability.

### Blocking after failed attempts

The shop system blocks separately by email address and by IP address.

| Parameter | Purpose | Values |
| - | - | - |
| `MaxLoginFaults-Value` | Failed attempts until access for this email address is blocked. | integer. Default 3 |
| `BlockingTime-Value` | Duration of this block in minutes. | 1 to 60. Default 10 |
| `DetectionTime-Value` | Time window in minutes within which the failed attempts must occur. | integer. Default is the value of `BlockingTime-Value` |
| `IPAddressBlocking-Allow` | Enables blocking by IP address. | `yes`, `no`. Default `no` |
| `IPAddressBlocking_MaxLoginFaults-Value` | Failed attempts until the IP address is blocked. | integer. Default 10 |
| `IPAddressBlocking_BlockingTime-Value` | Duration of this block in minutes. | integer. Default 10 |
| `IPAddressBlocking_DetectionTime-Value` | Time window for the failed attempts of an IP address in minutes. | integer. Default 1 |

### Email address validation

| Parameter | Purpose | Values |
| - | - | - |
| `EmailCheckMode` | How strictly the entered email address is validated. | `basic`, `syntax`, `domain`. Default `domain` |
| `UseCaptchaForRequestSetPassword` | Requires a captcha when requesting a new password. | `ReCaptchaV3`, `FriendlyCaptcha`, `CaptchaEU` |

**`basic`** checks: not empty, no space, exactly one @, at least one dot, the dot comes after the @, and there are at least two characters after the last dot.

**`syntax`** includes all checks from `basic` and additionally checks the part before the @: no two consecutive dots, no dot at the beginning or end, at least one character, and only alphanumeric characters as well as `.`, `-`, `_`, and `+`. The same applies to the part after the @, without `_` and `+`, and the top-level domain must be between 2 and 10 characters long.

**`domain`** includes all checks from `basic` plus the check of the part before the @ from `syntax`, and additionally requires an MX or A record to exist for the domain.

> [!WARNING]
>
> Only `domain` checks whether a reachable mail server exists for the address at all. Without this check, it can happen that neither the activation email nor the order confirmation can be delivered, and the buyer only notices when they are missing.

> [!WARNING]
>
> `EmailCheckMode` is **not** taken into account if an `InputCheck` of type `Email` is defined for the email field of the billing or delivery address. In that case, only this InputCheck applies. If you want to set a value other than `domain` here, first check whether such an InputCheck exists and remove it.

> [!NOTE]
>
> `UseCaptchaForRequestSetPassword` is not listed in the previous documentation. Requesting a new password is a popular way to probe address lists for valid accounts, so captcha protection makes sense here.

### Error messages

| Parameter | Appears when |
| - | - |
| `NewPWLength-Txt` | the password is shorter than `PWMinLength-Value` |
| `Error1-Txt` | the password and email address are too similar, phrased from the password's perspective |
| `Error2-Txt` | too many identical characters appear in a row |
| `Error3-Txt` | access was blocked after too many failed attempts |
| `Error4-Txt` | the password and email address are too similar, phrased from the address's perspective |
| `Error5-Txt` | `DenySimplePasswordLevel` applies |
| `Error6-Txt` | one of the minimum numbers of character types is not reached |
| `Error7-Txt` | the IP address was blocked after too many failed attempts |
| `Error8-Txt` | a string from `PWBlackListedStrings-List` appears in the password |
| `Error9-Txt` | too many digits follow one another |

> [!NOTE]
>
> `NewPWLength-Txt` is not listed in the previous documentation. It states there that the minimum length message is configured in the `LoginError-Txt` section. Both are true: `LoginError-Txt` has its own parameter `NewPWLength`, and in addition there is `NewPWLength-Txt` here, in which, unlike there, the configured value is inserted.

The shop system inserts the configured values into these messages. The following are available:

| Tag | Usable in | Replaced by |
| - | - | - |
| `~PWMinLenght~` | `NewPWLength-Txt` | `PWMinLength-Value` |
| `~PWMinCharacters~` | `Error6-Txt` | `PWMinCharacters-Value` |
| `~PWMinNumerics~` | `Error6-Txt` | `PWMinNumerics-Value` |
| `~PWMinSpecialCharacters~` | `Error6-Txt` | `PWMinSpecialCharacters-Value` |
| `~PWMinLowerCaseCharacters~` | `Error6-Txt` | `PWMinLowerCaseCharacters-Value` |
| `~PWMinUpperCaseCharacters~` | `Error6-Txt` | `PWMinUpperCaseCharacters-Value` |
| `~PWRepeatedSignsFault~` | `Error2-Txt` | `PWRepeatedSignsFault-Value` |
| `~Email-PWSimilaritySignsFault~` | `Error1-Txt` and `Error4-Txt` | `Email-PWSimilaritySignsFault-Value` |
| `~PWMaxSuccessiveNumerics~` | `Error9-Txt` | `PWMaxSuccessiveNumerics-Value` |
| `~BlockingTime~` | `Error3-Txt` and `Error7-Txt` | the blocking duration in minutes |

> [!WARNING]
>
> The shop system replaces one of these tags **only if** the corresponding parameter is greater than `0`. If the parameter is set to `0` and the tag is still in the text, the buyer sees the tag as plain text. So remove the tag from the message as soon as you disable the corresponding check.

> [!NOTE]
>
> In addition, `~Email-PWSimilaritySignsFaultString~` and `~PWRepeatedSignsFaultString~` are available. They are not filled from the configuration, but only in case of an error, with the characters actually objected to. This lets you tell the buyer not only that something is wrong, but also what.

### Password strength indicator

For the indicator, each threshold has a second version with `-Yellow-` in its name. It describes the threshold from which the indicator switches from yellow to green. The thresholds without `-Yellow-` remain the red threshold, below which the password is rejected.

| Parameter | Recommended value | Associated message |
| - | - | - |
| `PWMinLength-Yellow-Value` | 8 | `NewPWLength-Yellow-Txt` |
| `PWMinCharacters-Yellow-Value` | 5 | `Error6-Yellow-Txt` |
| `PWMinNumerics-Yellow-Value` | 2 | `Error6-Yellow-Txt` |
| `PWMinSpecialCharacters-Yellow-Value` | 1 | `Error6-Yellow-Txt` |
| `PWMinLowerCaseCharacters-Yellow-Value` | 3 | `Error6-Yellow-Txt` |
| `PWMinUpperCaseCharacters-Yellow-Value` | 2 | `Error6-Yellow-Txt` |
| `PWMaxSuccessiveNumerics-Yellow-Value` | 4 | `Error9-Yellow-Txt` |
| `PWRepeatedSignsFault-Yellow-Value` | 3 | `Error2-Yellow-Txt` |
| `EMail-PWSimilaritySignsFault-Yellow-Value` | 4 | `Error1-Yellow-Txt` |
| `PWBlackListedStrings-Yellow-List` | your own list | `Error8-Yellow-Txt` |

The associated tags are named as above, with `-Yellow` appended:

| Tag | Usable in |
| - | - |
| `~PWMinLenght-Yellow~` | `NewPWLength-Yellow-Txt` |
| `~PWMinCharacters-Yellow~`, `~PWMinNumerics-Yellow~`, `~PWMinSpecialCharacters-Yellow~`, `~PWMinLowerCaseCharacters-Yellow~`, `~PWMinUpperCaseCharacters-Yellow~` | `Error6-Yellow-Txt` |
| `~PWMaxSuccessiveNumerics-Yellow~` | `Error9-Yellow-Txt` |
| `~PWRepeatedSignsFault-Yellow~` | `Error2-Yellow-Txt` |
| `~Email-PWSimilaritySignsFault-Yellow~` | `Error1-Yellow-Txt` |
| `~PWBlackListedString-Yellow~` | `Error8-Yellow-Txt` |

> [!WARNING]
>
> The tag for the blocklist is named `~PWBlackListedString-Yellow~`, in the singular, while the parameter `PWBlackListedStrings-Yellow-List` is in the plural. If you write the tag in the plural, it is displayed as plain text.

> [!WARNING]
>
> The yellow threshold must not contradict the red threshold. A yellow threshold below the red threshold results in an indicator that shows green even though the password is rejected. The shop system does not check this.

> [!NOTE]
>
> The spelling `EMail-PWSimilaritySignsFault-Yellow-Value` with a capital M is the one the shop system reads. For the parameter without `-Yellow-`, it is the other way around: there it is named `Email-PWSimilaritySignsFault-Value`. Since parameter names are compared case-insensitively, both spellings work.

Guide: Secure login procedure, Email address validation. Reference: InputCheck section, LoginError-Txt section

## SecuredPassword

Determines what happens after a buyer has reset their password via the link in the email.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<SecuredPassword>
   AutoLogin    = no
   CheckLoginID = no
</SecuredPassword>
```

| Parameter | Purpose | Values |
| - | - | - |
| `AutoLogin` | Logs the buyer in immediately after setting the password and shows the customer account. | `yes`, `no`. Default `no` |
| `CheckLoginID` | Additionally requires the user ID when setting the password. | `yes`, `no`. Default `no` |

> [!NOTE]
>
> `CheckLoginID = yes` increases security, because the link alone is then no longer sufficient. Someone who has access to the mailbox but does not know the user ID cannot proceed. The price is an additional input at a moment when the buyer has already forgotten something.

Guide: Forgotten password

## AutoLogin

The persistent login. A buyer stays logged in beyond the end of the session and does not need to enter a password on their next visit.

Because this is a security risk, the persistent login can be bound to the device, the country, and the IP address, and for particularly sensitive pages, password entry can still be enforced.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AutoLogin>
   Allow                        = no
   ExpiryTime                   = 10
   CriticalActions              =
   ReauthAlwaysBeforeCritAction = no
   ReauthAfterLastUse           = 0
   ReauthAfterLastPasswordInput = 0
   UserAgentDiffers-Allow       = yes
   CountryDiffers-Allow         = yes
   IPDiffers-Allow              = yes
</AutoLogin>
```

### Basic setting

| Parameter | Purpose | Values |
| - | - | - |
| `Allow` | Enables the function. | `yes`, `no`. Default `no` |
| `ExpiryTime` | How many days after its last use the persistent login remains valid. | integer, at least 1. Default 10 |

### Critical actions

`CriticalActions` is a comma-separated list of pages for which the shop system requires password entry despite the persistent login.

| Value | Page |
| - | - |
| `UserAccount` | customer account |
| `DelivAddressManage` | delivery address management |
| `OrderHistory` | order history |
| `PrimePackagesManage` | Prime package management |
| `ConnectedExternAccountsOverview` | management of external accounts |
| `AutoLoginManage` | management of saved logins |
| `CombinedAddress` | billing and delivery address in checkout |
| `PayDeliv` | selection of payment and shipping method |
| `PlaceOrder` | order summary |

Three parameters control exactly when password entry is required:

| Parameter | Purpose | Values |
| - | - | - |
| `ReauthAlwaysBeforeCritAction` | Always requires password entry before the first critical action. Applies once per session. | `yes`, `no`. Default `no` |
| `ReauthAfterLastUse` | Requires password entry if the persistent login has not been used for this many days. | integer. `0` disables the check. Default 0 |
| `ReauthAfterLastPasswordInput` | Requires password entry if the last password entry was this many days ago. | integer. `0` disables the check. Default 0 |

> [!WARNING]
>
> `CriticalActions` is empty by default. Without entries, a persistently logged-in buyer gets all the way to the order summary without any further check. Include at least `UserAccount` and `PlaceOrder`, because that is where the address and payment data are.

### Binding to device, country, and IP address

| Parameter | Purpose | Values |
| - | - | - |
| `UserAgentDiffers-Allow` | With `no`, the persistent login only works with the same browser used to set it up. | `yes`, `no`. Default `yes` |
| `CountryDiffers-Allow` | With `no`, it only works in the same country. The country is determined via GeoIP. | `yes`, `no`. Default `yes` |
| `IPDiffers-Allow` | With `no`, it only works with the same IP address. The last octet is ignored. | `yes`, `no`. Default `yes` |

> [!WARNING]
>
> With `CountryDiffers-Allow = no`, the persistent login also fails if **no** country could be determined at all. So expect some of your buyers to have to log in again despite the persistent login.

> [!NOTE]
>
> The last octet of the IP address is intentionally ignored with `IPDiffers-Allow = no`, because many connections receive changing addresses within the same network. Switching connections or switching from mobile data to Wi-Fi still results in a new login.

Guide: Persistent login

## UserData

Determines which particularly sensitive data the shop system stores in the customer account and how the delivery address is preselected for logged-in buyers.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<UserData>
   SaveCreditCardData-Allow         = no
   SaveBankData-Allow               = no
   SaveMaxProducts-Allow            = no
   NewUserPWChangeRequired          = no
   SubAccounts-Allow                = no
   PreSelectDefaultDelivAddr-Allow  = no
   PreSelectLastUsedDelivAddr-Allow = yes
</UserData>
```

| Parameter | Purpose | Values |
| - | - | - |
| `SaveCreditCardData-Allow` | Stores the credit card information entered with the payment service provider in the customer account. | `yes`, `no`. Default `no` |
| `SaveBankData-Allow` | Stores the entered bank details. | `yes`, `no`. Default `no` |
| `SaveMaxProducts-Allow` | Remembers the number of products per page chosen by the buyer. | `yes`, `no` |
| `NewUserPWChangeRequired` | Forces future new customers created by an ERP system to change their password after the first login. | `yes`, `no`. Default `no` |
| `SubAccounts-Allow` | Allows multiple logins with the same email address, that is, multiple accounts. | `yes`, `no`. Default `no` |

> [!NOTE]
>
> All customer data is stored encrypted. `SaveCreditCardData-Allow` requires the payment service provider to support tokenization of the card number. The shop then stores not the card number but a placeholder for it.

### Delivery address preselection

| Parameter | Purpose | Values |
| - | - | - |
| `PreSelectDefaultDelivAddr-Allow` | Preselects the delivery address the buyer has marked as default. | `yes`, `no`. Default `no` |
| `PreSelectLastUsedDelivAddr-Allow` | Preselects a delivery address according to one of the following rules. | `yes`, `always`, `alwaysFirst`, `no`. Default `yes` |

| Value | Preselected |
| - | - |
| `yes` | the most recently changed or edited delivery address |
| `always` | the most recently used delivery address |
| `alwaysFirst` | the first available delivery address, sorted by postal code |
| `no` | no delivery address; the billing address applies |

> [!NOTE]
>
> The two parameters apply one after the other. If the buyer has set a default address and `PreSelectDefaultDelivAddr-Allow` is set to `yes`, that address wins and `PreSelectLastUsedDelivAddr-Allow` no longer has any effect. The second rule only applies when there is no default address.

Guide: "Credit card" payment method, Direct debit and requesting bank details, Forced password change for new customers, Multiple accounts, Set a default delivery address

## VerifyCustomerData

Determines how strictly the shop system checks customer input for plausibility, and holds the related error messages.

Each check has three levels. With `soft`, the buyer is informed of the inconsistency but can still submit the order after confirming. With `hard`, they must correct it. With `no`, no check takes place.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<VerifyCustomerData>
   FirstName     = soft
   Zip           = soft
   BankCode      = soft
   AccountNumber = soft
</VerifyCustomerData>
```

| Parameter | Checks | Values |
| - | - | - |
| `FirstName` | salutation against first name, using a database of around 20,000 first names | `no`, `soft`, `hard`. Default `no`. Recommended `soft` |
| `Zip` | postal code against city, using a database for Germany and Austria | `no`, `soft`, `hard`. Default `no`. Recommended `soft` |
| `BankCode` | bank code against the bank's name, using a database for Germany and Austria | `no`, `soft`, `hard`. Default `no`. Recommended `soft` |
| `AccountNumber` | the account number for formal validity | `no`, `soft`, `hard`. Default `no`. Recommended `soft` |

> [!NOTE]
>
> In the previous documentation, `AccountNumber` has no description; its row in the parameter table is empty. The parameter behaves like the other three and has the same three levels.

> [!WARNING]
>
> `hard` for `FirstName` and `Zip` means that buyers with an unusual first name or a newly assigned postal code cannot place orders. Both checks rely on data sets that are never complete. `soft` is therefore the safe choice.

### Error messages

The legacy documentation lists the following messages only in the example block; in the parameter table, some are missing or have no description.

| Parameter | Appears when |
| - | - |
| `FirstNameError-Txt` | salutation and first name do not match |
| `ZipError-Txt` | postal code and city do not match |
| `BankCodeError-Txt` | bank code and bank name do not match |
| `AccountNumberError-Txt` | the account number is invalid |
| `BankUserDescrEmptyError-Txt` | the description of the bank details is missing, if it is a required field |
| `BankOwnerEmptyError-Txt` | the account holder is missing |
| `BankAccountNumberEmptyError-Txt` | the account number is missing |
| `BankNameEmptyError-Txt` | the bank is missing |
| `BankCodeEmptyError-Txt` | the bank code is missing |
| `DateOfBirthInvalidError-Txt` | an invalid date of birth was entered, for example February 31 |

### IBAN and BIC

| Parameter | Appears when |
| - | - |
| `BankAccountIBANEmptyError-Txt` | the IBAN is missing |
| `BankAccountIBANError-Txt` | the IBAN is generally incorrect |
| `BankAccountIBANLengthError-Txt` | the IBAN has the wrong length |
| `BankAccountIBANChecksumError-Txt` | the IBAN checksum is incorrect |
| `BankAccountIBANCountryError-Txt` | the IBAN country code is not supported |
| `BankAccountBICEmptyError-Txt` | the BIC is missing |
| `BankAccountBICError-Txt` | the BIC is incorrect |

> [!NOTE]
>
> The seven IBAN and BIC messages are completely missing from the parameter table in the previous documentation and only appear in the example block there. These messages in particular are worth phrasing individually, because distinguishing between wrong length, wrong checksum, and unsupported country tells the buyer where to look.

Guide: Configure customer data validation

## WelcomeCookie

The WelcomeBack function. A buyer with an existing customer account is greeted by name on a return visit without being logged in.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<WelcomeCookie>
   Allow      = yes
   CookieDays = 90
   <+Fields>
      Addressfield = FirstName,LastName
   </+Fields>
</WelcomeCookie>
```

| Parameter | Purpose | Values |
| - | - | - |
| `Allow` | Enables the function. | `yes`, `no`. Default `no` |
| `CookieDays` | After how many days the cookie and database entry are deleted. | integer |
| `+Fields` with `Addressfield` | Which address fields can be used in the greeting. | comma-separated list of technical field names, for example `FirstName,LastName` |

> [!NOTE]
>
> The cookie contains only a hash value, not the name. The shop system uses it to retrieve the fields from the database. Only the fields listed here are available in the template later, and only fields of the billing address are permitted.

> [!WARNING]
>
> Greeting by name requires that the visitor has consented to the cookie. Register the cookie in the `AgreementCookies` section; otherwise it is not set.

Guide: WelcomeBack function. Reference: WC- (WelcomeBack function)

## MKForumSSO

Specifies the error template for connecting to portals via single sign-on.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<MKForumSSO>
   TemplateError =
</MKForumSSO>
```

| Parameter | Purpose | Values |
| - | - | - |
| `TemplateError` | Template displayed when an error occurs in the SSO process. | file name |

> [!NOTE]
>
> The shop system only reads this parameter if the SSO connection is activated for the shop. Without activation, the section has no effect.

Guide: Interface to portals

## Connected external accounts

There is no separate configuration section for the overview of accounts connected to an external service. You simply assign a template in the `Templates` section:

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<Templates>
   ConnectedExternAccountsOverview = ws_connected_externaccounts.htm
</Templates>
```

You build the content of the template with the `CEA-` tags. A complete example is available there.

Reference: Templates section, CEA- (Connected external accounts). Guide: External login with Facebook

## UserDefList-1 to UserDefList-3

> [!WARNING]
>
> This function is deprecated and no longer supported. For new shops, use the selection lists of the address data fields instead.

The three sections define entries for selection lists that can be displayed on the billing and delivery address page. They were intended for questions to the buyer, who selects from predefined answers.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<UserDefList-1>
   +Entry = Erste Antwort
   +Entry = Zweite Antwort
</UserDefList-1>
```

| Parameter | Purpose | Values |
| - | - | - |
| `+Entry` | An entry in the selection list. One line per entry. | any text |

> [!WARNING]
>
> The buyer's selection is passed to the order data, but **not** permanently stored in the customer data. On the next order, the list is reset to the default.

Guide: Selection lists for address data


## Related topics

- [Customer, login and account](https://dokumentation.websale.de/en/v8s/referenz/tags/ws/kunde-anmeldung-und-konto.md)
- [MSG- (Messages)](https://dokumentation.websale.de/en/v8s/referenz/tags/msg-meldungen.md)
- [Buttons for customer account and login](https://dokumentation.websale.de/en/v8s/referenz/tags/bt/kundenkonto-und-anmeldung.md)
- [accounts - User accounts](https://dokumentation.websale.de/en/konfiguration/accounts-benutzerkonten.md)
- [DA- (Deleting the customer account)](https://dokumentation.websale.de/en/v8s/referenz/tags/da-kundenkonto-loeschen.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.