Home Delivery

Overview

Introduction

The "Home Delivery" option serves as the default method for shipping items directly to the customer’s home address. Alongside Collection Points and Store Pickup, it represents one of three available Delivery Options.

Unlike the "Collection Point" or "Store Pickup" options, Home Delivery necessitates detailed customer address information to ensure successful shipping. SCAYLE’s is offering a customizable address component to capture essential shipping details, including country, street, and house number, as well as additional information such as Tax ID, gender options, and birth date.

In addition to configurable customer details, SCAYLE provides the ability to validate addresses using third-party services and to autocomplete address fields based on user input. These validation and suggestion features can be customized to meet specific needs and used third-party providers.

Understand Home Delivery

Home Delivery comprises several components, offering a high degree of customization.

Shipping Address

SCAYLE's address form is specifically designed to manage essential shipping details at the shop country level. It features customizable fields for customer names, individually configurable gender options, and the ability to dynamically add or remove address fields. Titles can also be customized or removed as needed.

Field positions can be adjusted to enhance usability, while field validations and field formats ensure data accuracy. Additionally, the user interface can be tailored to create a seamless and personalized Checkout Experience. This flexibility accommodates unique country-specific requirements while improving overall customer conversion.

Billing Address

SCAYLE’s Billing Address feature simplifies the input of billing information for customers. During the checkout process, users can easily enter their billing address, which can be pre-filled from their saved addresses or automatically populated based on the shipping address, enhancing convenience and efficiency.

Google Autocomplete

SCAYLE provides an out-of-the-box solution that leverages Google Autocomplete for address completion features. This integration significantly enhances the checkout experience with its Address Prediction capability, which suggests complete address options as users type, facilitating faster and more accurate input. Additionally, the Real-time Suggestions feature offers immediate feedback, reducing errors and streamlining the checkout process by minimizing manual entry.

Address validation

At SCAYLE, external data sources can be leveraged to validate shipping addresses submitted by customers. The Checkout Webcomponent can request address validation through integrated APIs based on user input; if the input is incorrect, it opens a modal allowing users to select a corrected address from the options provided by the external data source. Based on generic APIs provided by SCAYLE, nearly any given external source can be integrated.

Address Book:

SCAYLE's Address Book feature offers customers a convenient way to manage their shipping and billing addresses. Users can effortlessly add, edit, or delete addresses, ensuring their information is always up to date. This feature significantly enhances the user experience by enabling customers to easily access and manage multiple shipping addresses.

Best Practices

Checkout Defaults

json

Copy

Prerequisites

Configure

Customize

Shipping and Billing countries

Make address form fields mandatory

Enable google autocomplete for address form

Google autocomplete is a really handy feature that shortens the process of filling out the form for the user. Instead of having to manually fill every single field, user can just select a suggestion from the list, and automatically populate all (or almost all) required address fields.

When you reach the configuration directory, just toggle the "enabled" button, click save at the top right corner. Et voila, google autocomplete has been enabled.

Enable Address Form Title Field ( Professor, Ph.Dd etc)

Some people consider their identity defined by different academic titles they acquire throughout their life. To strengthen their sense of importance, we enable them to "select" the title field, with 3 possible options:

• Prof. Ph.D.
• Ph.D.
• Professor.

After proper configuration it should look like this:

When you reach the configuration directory, just toggle the "enabled" button, click save at the top right corner. Et voila, title has been enabled.

Separate Street and House Number Fields

By default, street and house number are ONE , full-width input field, so the form is visually shorter.

However, in some cases it might be a favourable option to separate the fields, eg. in order to improve the quality of the shipping data. After separating the fields, we get two separate input fields looking more less like this:

When you reach the configuration directory, just toggle the "Separate Fields" button, click save at the top right corner. Et voila, separate street and house number fields has been enabled.

Change the position of House Number Field when Separated from Street Field

In some cases you may want to change the order of the Street and House Number fields.

Byf default, when Street field is separated from the House Number Field - street comes first.

Compare the default configuration when the fields are separate:

vs adjusted position of the house number, that after changes - comes first:

When you reach the configuration directory, just scroll down to the "House Number" section, find an option called: "Position", set the value to "First", click save at the top right corner. Et voila, now

NOTE! In order for the option to work as expected, please make sure you have the "separate field" option enabled in General Setttings.

Special Component ( NL, BG, US only)

Special Component is a special address field component, developed for three countries:

• Netherlands
• Bulgaria
• US

Each of those countries has some special requirements, related either to the layout of the address fields (different cultural norms) address suggestions or (as US) a custom "state" logics.

For those countries a Special Component can be enabled in the panel, that offers a more customised version of address form. Please read more about Special Component here.

Adjust address validations

Base Address validations

Address fields are thoughtfully designed with various validation rules to help ensure that users submit accurate and correct information.

Here's the short overview of fields and their corresponding validators.

Country Overwrites Validators

On top of the default validators, each country can have it's own country-specific validator, that overwrites the default one. As an example, zip-code field for Austria has a custom validator that overwrites the "zipc-ode" format by providing an explicit Regex format, against which all values are validated.

json

Copy

In order to provide a custom format and adjust the default zipcode validator for a specific country, please navigate to the configuration directory, and within Zip-Code section - find the "Format" input field and place the new regex validator value in it.

Then, click save at the top right corner. Et voila, zipcode new validator has been enabled.

Layered Validation

On top of the default validations, and validation rules adjusted to country requirements, sometimes we have a "business" or "technological" requirements, that, for example might force us to accept an input:

a) Without space

json

Copy

b) Containing at least one lowercase letter

json

Copy

c) Containing at least one special character

json

Copy

These are the typical "strong password" requirements. However you can use simmilar set of rules to validate the input for any of the address fields. The way to do that is via so called "Layered Validation".

Let's take a look once again at our zip-code example, to showcase the possibilites of "Layered Validation"

When you reach the configuration directory, navigate to the Zip Code section. You will find a "Layered Navigation Tab. Click the (+Layered Validation) button to add new rule.

We have two columns - Format and Translation Key

Let's say that we want to test the zipcode field for the presence o dash (-). Let's provide a regex rule for that:

regex

Copy

Let's input the value into the Format Field.

Next, let's add the translation key. Since we don't want to wait for new translations update, let's use one of the custom keys, that aren't in use at the moment.

Let's pick a key called custom6. You can adjust the translation value within Crowdin, for now we can go with something like: "Error, missing dash -".

Now, scroll to the top of the page and in the right corner click "save". Congrats, you saved your first Layered validation.

This is how it's gonna look after user provides zip-code with missing dash:

Enable Zip-Code-based City suggestions

By default, zip-code based city suggestions are turned off.

Copy

However, by enabling the "completion" option on zipcode config, whenever user provides a value for the "zip code" field (say: 01067) the value of city field will get updated automatically (Dresden).

Mappings are loaded from the dedicated CDN, that stores all the zipcode-city mappings per country.

json

Copy

When you reach the configuration directory, open the "Completion" tab within "Zip Code" section, and toggle the "Enabled" button. Then, click save at the top right corner. Et voila, city completion based on zipcode has been enabled.

Enable City-based Zip-Code suggestions

By default, city-based zip-code suggestions are turned off.

Copy

However, by enabling the "completion" option on city configuration, whenever user provides a value for the "city" field (say: New York) , moves to the "zipcode" field and starts writing - a dropdown with suggested list of zipcodes matching New York will show up.

Mappings are loaded from the dedicated CDN, that stores all the city-zipcodes mappins per country.

json

Copy

When you reach the configuration directory, open the "Completion" tab within "City" section, and toggle the "Enabled" button. Then, click save at the top right corner. Et voila, zipcode suggestions based on city has been enabled.

Change the position of ZipCode Field

In some situations you might be willing to change the order of zipcode - city fields, by putting City field first. The best way to achieve it, is by changing the "position" property value of zipcode, from "first" to "second".

Please compare the default layout when zipcode is positioned in the "first" place:

Vs layout when zipcode is positioned "second", after city field

When you reach the configuration directory, open the "Position" dropdown within "Zip Code" section, and choose the "second" option.. Then, click save at the top right corner. Et voila, the position of zipcode field has been changed.

Adjust Home Delivery to Multi-country-setup

Feature

SCAYLEs Checkout supports a range of specific use cases for a multi-country setup. The following example demonstrates how to handle the "Tax ID" field to illustrate the overall Checkout capabilities in a multi-country configuration.

Exemplary use case: Consider a scenario when for a specific country (Say Austria) you would like to enable TAX ID collection, so the buyers can claim their tax exemptions and assure proper invoicing. How can this be accomplished?

Configuration steps

"2"3"4"5"6DoneStep 1

Copy

Navigate to Settings ➜ Checkout ➜ Configurations ➜ Dynamic Fields

Preview

Customer Tax ID Field

Copy

Notifications

json

Copy

json

Copy

HTML Slots

HTML Slots serve as dynamic placeholders within the Webcomponent. They act as small portals through which the parent website can inject customized content into the checkout Webcomponent, offering a flexible way to change the appearance.

Please refer to the general documentation to understand how to setup HTML Slots for Home Delivery.

HTML Slot Example

Copy

Improvement Ideas (internal)

Mike:

So the biggest issue that I see so far, are oftenly missing default configurations on the panel.

For what I checked there are two main areas affected:

a) Toggle values (on-off buttons) that are enabled by default (true). In panel they are very oftenly false. So we are showing wrong "default" state of shop. Example:

1. Features -> App Deep Link Rewrites (false on panel, true in defaults)
2. Features -> Review (false on panel, true in defaults)
3. Address Form -> Street house number -> Required (false on panel, true in defaults)

It seems that especially Address Form and Features areas are affected. I think we would need a task for Panel to go over every option and check if its correct. Martin Brixius

b) Dynamic Fields - areas are not enabled by default, even when we have defaults for them.

As an example, by default we have the Dynamic Fields enabled for following areas: register, guest, paymentBelowMobileBasket with following checkboxes:

json

Copy

However THEY ARE NOT VISIBLE IN THE PANEL.

As an example, when I go to dynamic fields, register - it first asks me to ENABLE THE AREA.

A bit weird for area, that is already enabled and has some default values.

What can go wrong? A lot. Problem is especially significant with arrays.

If we don't render default checkboxes, user might create his own checkboxes within this area.

Adding one new checkbox, can effectively overwrite all the existing defaults, making them disappear.

We already had that situation with eg. links. People were adding new links, and defaults (also array) were disappearing. So now we have the input field, that showcases already existing ones.

Maybe we should use simmilar approach? Although, we also had simmilar situation with layered validation for passwords layever validation - and now the defaults are visible.

Fix? Just make sure that the Panel properly encapsulates the Defaults - so the config defaults are visible.