CubeCart Right of Withdrawal: A Built-In Cancellation Workflow
CubeCart 6.7.4 added a Right of Withdrawal workflow: a way for customers to formally request cancellation of an order, and for you to manage those requests in the back office with an audit trail. For UK and EU merchants this replaces a process most of us have been running through the support inbox.
The background
Under the UK Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, and the equivalent EU Consumer Rights Directive, customers buying at a distance generally have a cooling off period, usually 14 days, in which they can withdraw from the contract without giving a reason. You are required to provide information about that right and to handle requests properly.
An important caveat before anything else: this article describes a software feature, not your legal obligations. There are exemptions (bespoke goods, perishables, unsealed hygiene products, digital content the customer has begun downloading, among others), there are rules about refund timescales and return postage, and the details differ by jurisdiction and by what you sell. CubeCart’s feature does not determine any of that. If you are unsure of your position, take proper advice.
What the feature does is give you a consistent, recorded process for handling requests you receive.
How it works
From the customer’s side: a withdrawal request can be submitted against an order from their order list or from the receipt. They get an acknowledgement email.
The setting on the Features tab. The day limit only hides the button; the legal 14 day right runs from delivery.
Click for full sized image
From your side: a new management screen under Customers, Withdrawal Requests, with four states.
- New when the request arrives
- Accepted when you agree to it
- Rejected when you do not
- Refunded once money has gone back
Decision emails go out automatically. Three new email templates are added during upgrade, imported across every shipped language.
Why doing this in the store beats doing it by email
The request is attached to the order. No searching a mailbox to work out which order a message from six weeks ago referred to.
Acknowledgement is automatic and timestamped. Since acknowledging requests promptly is part of what is expected of you, having that happen without anyone remembering to do it is worth something on its own.
There is a record. If a request is ever disputed, whether by the customer, a card issuer during a chargeback, or a trading standards enquiry, you can show what was requested, when, what you decided and when the money went back. An email thread can show that too, if the right person still has it and nobody deleted anything.
It does not depend on one person. A request sitting in an individual’s inbox while they are on holiday is a common way for a 14 day clock to be missed. A queue with states is visible to whoever is working.
The thing to check before you rely on it
The storefront side ships as two Foundation skin templates: content.withdraw.php and content.withdraw.done.php.
If you run a custom skin, those templates will not exist in it, and the customer facing part of this feature will not appear until they are added. The admin side works either way, but customers will have no way to submit a request.
This applies to any third party skin, including ours. It is exactly the kind of gap that is easy to miss, because nothing errors: the feature simply is not there, and you would only notice by looking for it. Check on a staging copy after upgrading rather than assuming.
The withdrawal email macros were tidied further in 6.7.5, so be on at least that version if you are customising the emails.
Setting it up sensibly
- Confirm the customer facing pages actually appear on your skin. Place a test order on a staging copy and try to submit a request as the customer.
- Read the three email templates and rewrite them in your own words. Default templates are functional and impersonal. This is a customer who wants to cancel; the tone matters more than usual.
- Decide who monitors the queue and how often. A feature nobody looks at is worse than an inbox somebody does look at.
- Make sure your published terms match what the feature does. If your returns policy page describes a different process to the one customers now see in their account, you have created a contradiction.
- Agree what happens at the Refunded step. The status change does not move money. Somebody still has to issue the refund through your payment provider, and the record is only useful if the state reflects reality.
Worth doing?
If you sell physical goods to UK or EU consumers, yes. You are handling these requests already, whether or not you have a system for it, and the compliance value of a timestamped record is real.
If you sell only to businesses, or only digital goods where the exemptions apply, it is likely less relevant, though a structured cancellation queue is not useless even then.
If you host your CubeCart store with us and want the withdrawal templates checked against your skin before you go live, or added to a custom skin that does not have them, get in touch.
