“Withdraw from Contract Here”: How to Implement a Withdrawal Button in an Online Store

The button is the visible part of the process. Behind it, the store needs a record of the submission, automatic notifications, an admin module and traceable handling. If the store only sends a message to a shared inbox, staff may struggle to establish which cases have been processed and which still need attention.

The implementation challenge is to make submission straightforward for customers and handling reliable for the merchant. The legal details below retain the Bulgarian context of this article, alongside the EU framework.

What does the law require, and when did it take effect in Bulgaria?

Article 52a of Bulgaria's Consumer Protection Act introduces an online withdrawal function. It was inserted by Section 7 of the amendment published in State Gazette No. 87 on 24 September 2026, and took effect on that date under Section 83. It requires a visible, easily accessible entry point, a way to submit a statement and a separate, unambiguous confirmation action. See the official Bulgarian State Gazette text.

The EU basis is Directive (EU) 2023/2673, which adds Article 11a to Directive 2011/83/EU and sets 19 June 2026 as the application date. The EU date and the Bulgarian effective date must be distinguished.

The implementation needs to follow the rules applicable to the particular contracts. The function does not create a right of withdrawal for every purchase. Statutory exceptions for certain personalized goods and services, for example, need separate assessment. See Your Europe: the right of withdrawal and exceptions.

What is the difference between receiving a withdrawal statement and reviewing it?

Submission and internal processing are separate events. The admin workflow establishes the facts and organizes subsequent actions; a valid exercise of the right of withdrawal is not subject to an employee's discretionary approval.

This nature of the right is also explained in the Active Consumers guide: it is exercised through a unilateral statement and is not granted at the merchant's discretion.

The system therefore needs separate records of:

• when the customer submitted the statement;
• when and how the acknowledgement of receipt was sent;
• how the particular case was checked and processed.

The acknowledgement should not wait for an employee to open the order. Equally, the automatic email should not claim that a refund has already been issued or that every subsequent action is complete.

Why should the form avoid searching only for “active orders”?

An order's store status is not a sufficient criterion for access to the withdrawal form. A delivered order may be marked as completed, while an older purchase may be recorded in a different system.

Other situations arise in everyday operations:

• the customer checked out as a guest;
• an invoice number was entered instead of an order number;
• a prefix was added or a typing mistake was made;
• the store was migrated and order references changed;
• the ERP is temporarily unavailable.

The recommended architecture accepts the statement as an independent record. It then attempts to match it to an order. If no match is established, the record is retained as “Clarification required” rather than being lost.

The public form checks that necessary fields have been completed and the email address has an acceptable format. It should not make “you have no active order” a submission barrier. Entering an arbitrary order number must not reveal another customer's information.

What should the customer form look like?

A useful form collects enough information for the statement and subsequent communication without unnecessary mandatory fields. The following is a practical implementation proposal:

An email address is necessary for the acknowledgement method selected here. A name and order number alone are insufficient when automatic matching may fail.

If the order number is unknown, the form should allow other sufficient details identifying the contract. It should not force the customer to invent a number to continue. The reference field should not accept digits only if the store uses letters, hyphens or prefixes.

A reason for withdrawal, photograph, telephone number or bank account should not automatically become a mandatory condition for submission. Information required for subsequent actions can be collected separately. For partial withdrawal, an optional description of the relevant items can be offered without publicly retrieving an unverified order.

Two clear actions

The initial entry point is “Withdraw from contract here” and opens the form. After completing it, the customer sees what they are submitting and finishes with “Confirm withdrawal”.

The preview can be on the same screen. A lengthy process with questionnaires or compulsory registration is unnecessary. For an already identified customer, details can be prefilled with an opportunity to check and correct them.

The form should work for guest purchases, on mobile devices and through keyboard navigation. Access should not depend on accepting marketing cookies.

What should happen after the customer confirms?

The system first saves the statement and the email dispatch task, then starts internal matching. This is the recommended model for a reliable implementation.

1. Check the minimum completeness of the submitted information.
2. Create a unique reference and record the server date and time.
3. Save the statement's content and the acknowledgement address.
4. Create the automatic email task within the same operation.
5. Display confirmation with the saved submission reference.
6. Send the acknowledgement and track the result.
7. Match the information to order records and notify the responsible team.

Saving the statement should not depend on the ERP or courier system responding. The internal order link may remain empty until matching has been checked. The reference entered by the customer and the internal order identifier are separate fields.

Record the timestamp when the server receives the customer's final confirmation, not when a background task processes it later. Display a clear time zone and preserve the timestamp when the same technical submission is retried.

If saving fails, do not display a false “successfully submitted” message. Give the customer a clear explanation and access to the advertised alternative contact methods.

What should the automatic email contain?

The email should acknowledge receipt and reproduce the submitted statement with its date and time. Bulgarian Article 52a(5) requires an acknowledgement on a durable medium without undue delay and no later than the end of the working day. This is a Bulgarian requirement, not a universal deadline for every jurisdiction. See the State Gazette text.

For this workflow, the most practical approach is an automatic email immediately after reliable recording. The on-screen message supplements the email; it does not replace it. A link to content that can be changed is not a sufficient substitute for including the statement itself in the message.

Example template:

Subject: Withdrawal statement received — reference {{REQUEST_REFERENCE}}

We received your withdrawal statement on {{SUBMITTED_AT_WITH_TIMEZONE}}.

Name provided: {{CUSTOMER_NAME}}

Order or contract reference provided: {{CONTRACT_REFERENCE}}

Statement content: {{DECLARATION_TEXT}}

Recorded submission reference: {{REQUEST_REFERENCE}}

Further communication about processing will use this reference. Contact: {{MERCHANT_CONTACT}}.

The template is populated from the submitted statement. Until identity has been checked, the email does not include addresses, amounts, items or documents retrieved from an order located by its number.

If email dispatch is delayed or fails, the statement remains recorded. Dispatch is retried in a controlled way and the team receives an alert. The statement's timestamp is not replaced by the time of the retry email.

How should the admin module work?

The admin system should provide an overview of statements and an auditable processing history. Recommended operational states are:

These states organize work. They do not change when the customer submitted the statement.

Email status is separate: pending, sent or failed. A statement marked “Received” can therefore have an acknowledgement delivery problem at the same time.

An employee should see the original information, possible matches, identity checks, delivery dates and communication history. Linking a statement to an order should record who performed the action, when and why. The original statement remains unchanged.

How should the order and withdrawal period be checked?

Review should use the actual contract and delivery information, not simply the order date. For ordinary online purchases of goods, the 14-day period generally relates to receiving the goods; services have a different starting point. See the official Your Europe explanation.

The admin workflow therefore checks:

• the relationship between the sender and the contract;
• receipt of the goods or the applicable starting event;
• split deliveries and missing information;
• whether the right of withdrawal applies to the particular contract;
• the withdrawal information supplied and any relevant timing circumstances;
• the submitted statement's date and time.

Software can provide a preliminary indication. An unknown delivery date or disputed case should be marked “Review required” rather than triggering an automatic negative response. The applicable timing rules and exceptions should be agreed with a legal professional for the merchant's sales.

After review, the system can send return instructions, a specific request for clarification or a reasoned response. Asking for clarification must not recast an already received statement as unsubmitted. Sending the acknowledgement alone should not trigger an unchecked refund or disclosure of customer data.

How can duplication and misuse be prevented?

Protection should preserve access to the form and separate receipt of a statement from actions affecting an order. Necessary technical measures include a secure connection, input validation and restricted admin permissions.

If the customer presses the button twice, the same technical submission should return the same reference. A unique submission key can provide this behavior. Deduplicating by order number alone is unsuitable: the customer may submit a new statement or clarification.

The public response should not reveal whether another person's order exists. Anti-spam measures should be proportionate and accessible, without requiring account creation or email verification as an additional step to complete the withdrawal submission.

Define retention periods and authorized users for the records. Technical logs should not unnecessarily copy the full personal information.

How should the feature be tested before launch?

Acceptance testing should cover the complete process, including external service failures. Minimum scenarios include:

• a guest purchase and submission from a mobile device;
• a completed order and an unmatched order reference;
• contract details submitted without a known order number;
• a double click and a retry after a network problem;
• a temporarily unavailable ERP;
• a failed email followed by retry and an alert;
• a statement submitted close to the withdrawal deadline;
• an attempt to access another customer's order;
• preservation of the original statement after an administrative correction.

A successful result means a reliable record, an accurate timestamp, an acknowledgement containing the actual statement and visibility for the responsible employee. An email sent without a corresponding admin record is insufficient.

Frequently asked questions

Is a PDF form in the footer enough?

Not for the interactive function described here. A file does not provide online submission, a separate confirmation action and automatic acknowledgement of the statement. It can remain an additional resource.

Should an incorrect order number cause rejection?

In the proposed model, the statement is saved and routed for clarification. The form does not expose order information or change another customer's records. Matching takes place internally.

Can the only email be sent after staff review?

The acknowledgement of receipt is separate from the follow-up response. The implementation should send the first promptly and the second according to the necessary processing actions.

Should the form automatically cancel an order?

Receiving a statement should not trigger unverified financial or inventory changes. Once the contract, sender and applicable rules have been established, authorized actions can be automated, such as stopping fulfilment or creating a return task.

How can Sirius Software implement this workflow?

Sirius Software can develop the feature as part of the online store and its administrative workflows. The solution can include a public form, a reliable statement register, automatic emails, an admin module and connections to orders, CRM, ERP and courier systems.

Analysis covers the platform, guest purchases, order numbering, available delivery data, staff permissions and subsequent actions. Development follows the agreed legal rules and includes testing, monitoring and traceability.

The budget depends on the existing store, available admin functionality and required connections. A form with a register and emails has a different scope from a workflow covering partial returns, payment operations and warehouse documents.

Request development of an online contract withdrawal feature. Include the store URL and platform, how withdrawals are currently handled and which actions you want automated. We will discuss a suitable implementation and scope for assessment.

Related services and guidance: software development and ERP integrations and preparing a technical specification.

Author and sources

Author: Georgi Papucharov, founder of Sirius Software. This article describes a technical implementation model for an online store. Applicable periods, exceptions and customer-facing wording need to be aligned with the particular contracts.