Cooloff is a Wix app that adds the withdrawal function required by Article 11a of Directive 2011/83/EU to an online shop, and, if the merchant switches it on, Germany's termination button under § 312k BGB; it keeps a record of every declaration the shop receives. This policy explains what personal data the app handles, where that data lives, and who is responsible for it.
Cooloff is installed by a merchant onto their own website. The merchant is the data controller for everything a consumer submits through the withdrawal form: it is their contract, their customer, and their legal duty to acknowledge the withdrawal and keep the record.
Eitan Plaks, Dalia Ravikovitch 5, Rosh HaAyin 4840301, Israel, develops and maintains the app and acts as a processor on the merchant's behalf. Contact: eitanp214@gmail.com. The data processing agreement is the European Commission's standard contractual clauses under Art. 28(7) GDPR with the annexes filled in: data processing agreement, which also says how to conclude it.
Only what the withdrawal function needs, and only when a consumer submits the form or requests a code in it to select individual items:
| Data | Why |
|---|---|
| Name | Identifies who is withdrawing, as the declaration requires. |
| Email address | The address the acknowledgement of receipt is sent to. |
| Order or contract reference, as typed | Identifies the contract being withdrawn from. |
| Optional message | Free text the consumer chooses to add. |
| Date and time of receipt | Article 11a(4) requires the exact moment to be confirmed. |
| Page address and language | Shows where the declaration was made and in which language. The country derived from them sets the time zone of the acknowledgement of receipt and the provision it cites. |
| Selected items, when chosen | Name and quantity of the items a partial withdrawal covers. |
| Matched order details, when found | Order number, date, totals and payment or fulfilment status, so the merchant can act on the withdrawal. |
| Reference and checksum | A short reference, which the acknowledgement of receipt also states, and a SHA-256 checksum over the content of the declaration, stored with the record and shown on the evidence PDF. |
| Handling status | Sending status of the acknowledgement, cancellation and refund, the merchant's notes and handling notes written by the app, so the merchant can see what happened to the declaration. |
| Order number and email address when an item-selection code is requested | Checked against the site's orders. If both match, a code is emailed to the order's address; with that code the form shows the order's items to choose from. Neither the request nor the code is stored; the code is valid for 10 to 20 minutes. |
| The caller's IP address | Only in the memory of the server instance handling the request, in a counter that recognises bursts of requests from one address: until the first request that uses the same counter after one minute has passed, or until the instance stops. Email addresses are counted the same way, with windows of ten minutes to one hour, to limit repeated emails and code attempts. Neither is stored, and both limit only emails and item selection, never the recording of a declaration. |
The termination button (§ 312k BGB). Only when the merchant switches it on in Settings and a consumer terminates through it, the app also handles: the kind of termination (ordinary or extraordinary), for an extraordinary termination the reason given, and the requested end date, as typed; together with the name, contract reference, email address, date and time of receipt, reference and checksum listed above. The purpose is the confirmation § 312k(4) BGB requires (the content, the date and time of receipt, and when the contract ends) and the merchant's record. Terminations are kept in the same store as withdrawal declarations, under the same access rules and retention.
The app does not ask for, and has no use for, payment details, identity documents, or any special category of data. The optional message field and the termination reason field are not meant for it.
The merchant's own details. For the acknowledgement of receipt the merchant enters a business name and a contact email address in Settings; for the privacy note in the form they can also give the address of their privacy policy. The business name is part of the button's configuration and can therefore be read in the page source of the merchant's website. The contact email address, the privacy policy address and, if entered, the return instructions are stored in the app's data collection "Cooloff settings" inside the merchant's own site and are not published in the page. The merchant writes the return instructions; the app copies them unchanged into every acknowledgement of receipt. A merchant on Cooloff Pro, the paid plan, can also enter up to three further email addresses of their team; each receives the same copy of every declaration as the contact address. They are stored in the same data collection and are not published either. On installation the app takes the site's name and leaves the email address empty. Settings shows the email address of the Wix account only as a suggestion; an address is stored only when the merchant saves. Installations before 15 September 2026 took the Wix account's address automatically. On those installations the contact email address is in the page source until the merchant opens the app's Withdrawals page or saves Settings, either of which moves it into the data collection. The merchant can change or clear it in Settings at any time. When the withdrawal form is first opened on a page, it asks the app's backend for the stored privacy policy address. The request carries nothing the visitor entered, and only the shop's privacy policy address is returned.
The merchant processes the declaration to comply with the legal obligation to acknowledge and document the withdrawal (Art. 6(1)(c) GDPR together with § 356a BGB in Germany, and the national measure transposing Art. 11a of Directive 2011/83/EU elsewhere); for a termination, the obligation to confirm it (Art. 6(1)(c) GDPR together with § 312k(4) BGB); and to perform, unwind or end the contract (Art. 6(1)(b) GDPR). Retention beyond that purpose rests on the merchant's own commercial and tax record-keeping duties.
Records are written to a data collection inside the merchant's own Wix site, on Wix infrastructure. The developer does not run a separate database, does not copy records out of the merchant's site, and does not build a profile of consumers across shops. The emails sent through Resend carry details of the declaration and remain with Resend (see below). Uninstalling the app leaves the records with the merchant, which is deliberate: they are the trader's evidence that the withdrawal was received and acknowledged.
No other third party receives this data. It is not sold, rented, or used for advertising.
Cooloff's listing on the Wix App Market is a page operated by Wix. So that the developer can see how many people view that listing and click "Add to Site", Wix places a Google Analytics tag on that page under the developer's measurement ID. This affects only the listing page on wix.com, never the app itself, never a merchant's site, and never a consumer using the withdrawal form. Google's own privacy terms govern that measurement. The website cooloffapp.com sets no cookies. It uses Cloudflare Web Analytics, which counts page views without cookies, without local storage and without identifying individual visitors; Cloudflare's privacy terms govern that measurement.
Cooloff sets no cookies. The button and form do not use local storage, session storage, analytics or advertising tags, fingerprinting, or any cross-site tracking. They store nothing in the visitor's browser; only the answer carrying the privacy policy address may stay in the browser's ordinary cache for up to five minutes.
Usage statistics for the developer. Cooloff reports two events to the statistics Wix provides to app developers: that a merchant opened the app's dashboard, and that the withdrawal button was switched on for a site. Wix links each event to the app's installation on that site. The events contain no data about the site's visitors or customers, and nothing is reported when a consumer submits a withdrawal or a termination. For these events the developer is the controller; the legal basis is the developer's legitimate interest in knowing whether the app is set up and used (Art. 6(1)(f) GDPR).
Retention is the merchant's decision, and it is bound by their own record-keeping duties. In Germany a withdrawal declaration and its acknowledgement are business correspondence, kept six years under § 257(4) HGB and § 147(3) AO; accounting vouchers eight years, and the documents listed in § 257(1) no. 1 HGB ten years. The merchant can delete individual records in the app's dashboard at any time (the dashboard shows the newest 2,000 records) and export up to 100,000 records per export as CSV.
Data subjects in the EU and the UK have the right to access, correct, delete, restrict and port their data, and to object to its processing. Because the merchant is the controller, these requests should be addressed to the shop the withdrawal was sent to. If you contact the developer instead, the request will be passed to that merchant and supported without delay. You may also complain to your national supervisory authority.
The developer is based in Israel, which the European Commission recognises as providing an adequate level of data protection.
Two bases cover the delivery service Resend (Plus Five Five, Inc., San Francisco, USA), both checked on 7 September 2026: certification under the EU-U.S. Data Privacy Framework — listed as "Resend" on the U.S. Department of Commerce register, status Active – Re-certification under Review — and the EU Standard Contractual Clauses under Implementing Decision (EU) 2021/914, which form part of the Resend DPA. There is no Swiss-U.S. certification. Resend engages sub-processors of its own; it publishes the current list itself.
Wix.com Ltd. is also based in Israel. For hosting the app's backend as the developer's sub-processor, the data processing agreement relies on the same adequacy decision (Annex IV). The site itself is covered by the merchant's own contract with Wix, including the transfer safeguards Wix publishes.
All traffic runs over HTTPS. The app's backend endpoints check the caller's identity before returning any record, and withdrawal records are readable only through the merchant's own dashboard. The mail provider key is stored as a server-side secret and is never exposed to the browser.
If this policy changes materially, the date at the top of the page changes with it, and the change is listed here: