Introduction

This document describes the Electronic Withdrawal feature, which enables consumers to submit a contract withdrawal online. The feature is primarily intended for B2C consumers in the EU. Under EU law, consumers have a statutory right to withdraw from distance contracts within a defined period. The Electronic Withdrawal feature supports merchants by providing a simple online entry point for withdrawal, guiding consumers through a structured process, and ensuring that they receive a confirmation via e-mail. In addition, it offers configuration options that allow merchants to align the availability and evaluation of electronic withdrawal with their business and legal setup.

This document includes two sections: business processes and technical concepts. The business process part covers the high-level concept and behavior of the electronic withdrawal flow, the main configuration options, and the key limitations and responsibilities around its use. The section on technical concepts focuses on technical details such as new data objects.

References

• Cookbook - Withdrawal

• Concept - Order Fulfillment Status Import

Business Processes

Withdrawal Creation Process

Consumers access the feature through a clearly labeled entry point such as a “Withdraw from contract” link in the shop’s footer or another prominent location. No login or app installation is required; consumers only need information related to their order.

The withdrawal process is implemented as a guided two‑step flow:

1. The consumer identifies the relevant order by entering the order number and the invoice e-mail address used when placing the order. If a matching order is found, the system creates an electronic withdrawal request linked to that order and the consumer is taken to a withdrawal form.

2. On the withdrawal form, the consumer sees the order‑related information and enters additional personal information required for the declaration. This includes a contact e-mail address for the withdrawal. This address can differ from the e-mail used in the order, allowing consumers to receive the confirmation at an address that is currently accessible to them. After completing the form, the system updates the existing electronic withdrawal request with the additional information from the form.

Once the form has been submitted, the system sends a confirmation e-mail to the contact address provided in the withdrawal form.

All follow‑up activities, such as evaluating the request, arranging product returns, and handling refunds or credit notes, are performed manually by the merchant outside this feature.

Configuration

The following settings can be configured in the Intershop Commerce Management channel preferences:

Withdrawal Eligibility

The central business rule of the feature is the evaluation of whether an order is currently eligible for electronic withdrawal. This evaluation is based on various factors such as the withdrawal period and a minimum start date as well as an overall feature toggle per channel. By default, the feature is disabled.

If enabled, the electronic withdrawal is available from the moment the order is created until a certain number of days after the customer has received the last item of the order. In a typical EU setup, this period is fourteen days after delivery, but the feature does not hard‑code this value. Instead, the number of days after delivery can be configured per channel so that merchants can align the electronic withdrawal window with their own legal assessment. To perform this evaluation correctly, the system relies on a delivery date associated with the order. If this information is missing, the feature cannot fully assess whether the post‑delivery part of the withdrawal period has been reached or expired. Merchants are therefore expected to provide delivery dates for the relevant orders, for example, via import processes.

In addition, the feature offers a configurable minimum start date for evaluation. Electronic withdrawal is technically possible for orders going back many years. To avoid the need to provide delivery dates for very old orders, merchants can configure a fixed date before which orders are simply ignored by the electronic withdrawal evaluation. Orders created before this minimum start date are treated as ineligible for electronic withdrawal, regardless of other criteria, while later orders are evaluated normally.

The feature is designed for B2C consumers. Out of the box, the evaluation logic only considers the B2C customer type as eligible for electronic withdrawal. If a merchant wants to extend electronic withdrawal to B2B or to introduce more complex customer‑type rules, this requires custom implementation in the project.

In summary, an order is eligible for electronic withdrawal only if:

• It belongs to a channel where the feature is enabled

• It is not older than the configured minimum start date

• It is associated with a supported customer type and

• It falls within the configured withdrawal period as determined from the delivery date and period length

E-Mails

The Electronic Withdrawal feature sends a confirmation e-mail for each withdrawal to the customer. This e-mail is sent to the contact address specified in the withdrawal form. This confirmation e-mail contains the content of the withdrawal declaration, the date of submission, and the relevant order reference. It serves as confirmation on a durable medium for the consumer.

The configuration allows merchants to define the sender address used for all withdrawal-related e-mails. A single sender address is configured and applied to the confirmation e-mail, enabling merchants to align this message with their established communication channels and branding.

If a corresponding e-mail address is configured, an additional e-mail is sent to the channel’s shop manager. This e-mail is an exact copy of the confirmation e-mail sent to the customer.

Viewing Withdrawal Information in Intershop Commerce Management

On the order detail page in Intershop Commerce Management, you can review both the delivery date and any withdrawal-related details for the order. If a withdrawal exists, an additional withdrawal section is displayed. This section provides the withdrawal creation date, the withdrawal period end date, and the current withdrawal status.

Limitations and Responsibilities

Functional Scope and Merchant Responsibilities

The Electronic Withdrawal feature provides a technical framework for receiving and documenting withdrawal declarations online, but it does not replace the merchant’s legal or operational responsibilities.

Merchants remain fully responsible for providing and maintaining legally correct texts around withdrawal rights, including the pre‑contractual information on the website, any statutory model withdrawal forms, and the content of customer communications such as e-mails and confirmation texts. The feature offers technical means to display and send this information, but it does not supply or validate the legal content itself.

Similarly, the feature does not automate the handling of withdrawals beyond the creation, storage, and update of the electronic withdrawal request. All subsequent steps, such as assessing the request, informing the customer, organizing product returns, and executing refunds or credit notes, are part of the merchant’s manual processes and are not covered here. The design of those processes, as well as their compliance with applicable law, lies outside the scope of this document.

From a technical perspective, the quality of the electronic withdrawal evaluation depends on the completeness and correctness of certain data, most notably the delivery dates. If delivery dates are missing, incorrect, or not kept in sync with reality, the system may not be able to determine the withdrawal period accurately. Merchants must therefore ensure that relevant data is provided and maintained appropriately, and that imports or integrations feeding this data are reliable.

Any customization that extends the standard behavior, for instance, adding support for additional customer types such as B2B or introducing special eligibility rules for certain products, are implemented at project level. The responsibility for designing, implementing, and validating such extensions lies with the project team and the merchant. They must ensure that custom logic remains consistent with applicable legal requirements and with the overall withdrawal handling process.

Compatibility with the IOM Connector

The Electronic Withdrawal feature relies on the presence of delivery dates on orders. In the standard setup, delivery dates can be imported via the XML Order Status Import feature. This feature, however, cannot be used in combination with the IOM connector. At the same time, the IOM connector does not provide a way to import delivery dates.

Projects that use the IOM connector must therefore implement an alternative mechanism, such as a custom API or integration, to supply and maintain delivery dates for the affected orders.

Technical Concepts

Order Import and Export

The Electronic Withdrawal feature relies on order import processes to keep delivery and withdrawal information in sync with external systems. Merchants or connected systems update the order status and delivery date via the order status import, and receive both the delivery status with the delivery date and the current withdrawal information via the order export.

Withdrawal Creation and Verification Process

The diagram below shows the relevant steps during the creation and verification of a withdrawal request:

Relevant Data Objects

This section documents the main data objects and classes introduced by the Electronic Withdrawal feature.

Database Objects

The diagram below illustrates the relationships between the new database objects and their integration into the existing order model.

Java Layer

The diagram below illustrates the key Java interfaces and classes involved in the withdrawal creation and evaluation process.

Customer E-Mails

Electronic withdrawal uses a dedicated e-mail template for the confirmation message. The template defines the content and layout of the e-mail sent to the customer after the withdrawal data has been submitted.

Template name:

email/withdrawal/WithdrawalCreatedNotification

Captcha Protection

To protect the withdrawal creation endpoint against misuse, the API requires a valid captcha token for each request. This is necessary because the feature is publicly accessible and must also support guest orders, so the API cannot rely on customer authentication.

The withdrawal creation API cannot be used without captcha validation. Consequently, if the feature is used for a channel, captcha must be enabled in that channel’s captcha preferences in Intershop Commerce Management.