Turning an EU legal obligation into enforced software

The problem

Under EU consumer law, online buyers have a statutory right to withdraw from a purchase within 14 days. For most stores this is handled as a policy page and an email address — which technically satisfies almost nothing.

It puts the burden on the customer to compose a valid declaration, on staff to interpret and track it, and on the business to somehow produce evidence years later if a dispute or an audit arises.

The specific failure modes are concrete:

• Withdrawal requests arriving as free-text emails that may not constitute a valid declaration
• No reliable record of when a request was made relative to the deadline
• No consistent way to determine which orders are still eligible
• No durable archive if a customer or a regulator asks for one

Terrecotte del Sole sells into Italy and across the eurozone, so this isn't a single-jurisdiction question. The same directive applies in every member state they ship to, and "we'll deal with it if it comes up" is a policy that only looks affordable until it comes up.

Why the obvious solutions didn't work

Generic returns plugins model a merchant's own returns policy: a commercial arrangement the merchant defines and can change at will.

A statutory withdrawal right is a different thing. The window is fixed by law rather than preference. Eligibility is determined by legal criteria rather than store settings. The record-keeping requirement outlives the order itself.

A returns workflow that a store admin can freely reconfigure isn't a compliance system. It's a compliance risk with a user interface.

What I built

A custom plugin implementing the whole obligation as an enforced system rather than a documented policy, built to the specification set by the client's legal counsel rather than to my own reading of the directive.

Customer dashboard

A dedicated Recesso section in My Account showing eligible orders and the status of every request made. The customer's own rights become visible rather than buried in terms and conditions.

One-click withdrawal form

Pre-filled from the order record, so the customer produces a complete, valid declaration by confirming rather than by composing. They add optional notes and submit.

This is the difference between a request the business can act on immediately and an ambiguous email that needs interpreting.

Server-side enforcement of the 14-day window

The decision that matters most in the whole build.

The withdrawal button disappears from the interface once the window closes — but the server validates the deadline independently on every submission, computed from the order record rather than from a stored flag. A hidden UI element is a suggestion. Server-side validation is enforcement. Anyone crafting a request directly against the endpoint after day 14 gets exactly the same answer as anyone using the form.

Try it. Drag past day 14, then use the bypass button — the interface stops offering the option, and the server refuses independently.

Automatic dual notification

An admin alert, so no request sits unnoticed in an inbox. And a customer confirmation receipt containing the full declaration.

That receipt does real work in both directions: it gives the customer proof they exercised their right, and it gives the business a timestamped record that the request was acknowledged.

Admin review workflow

Every request is reviewed, approved or rejected from WooCommerce admin. The decision and its outcome stay attached to the order rather than living in somebody's email.

Permanent retention

Every request is stored durably against the order's unique identifier, surviving order archival and staff turnover. The evidence exists whether or not anyone remembers the case.

The result

The system went live in July 2026 and has not yet needed to process a withdrawal — the store runs a low order volume and no customer has exercised the right since launch.

That's worth stating plainly rather than dressing up, because it's the honest measure of what this project delivered. The value here was never throughput. It was that a legal exposure became a controlled process before it was tested, rather than after.

• Statutory obligation moved from policy text to enforced software
• Deadline enforcement that cannot be bypassed client-side
• Every future request captured as a valid, timestamped, complete declaration
• A permanent, auditable record for compliance and dispute resolution
• Built to the specification of the client's legal counsel

The client's own summary was that they were relieved to know they were now fully compliant with the law — which is the outcome a compliance system is supposed to produce. Not a saving. An absence of exposure.