Legal
Privacy Policy
Last updated: 11 August 2026
This policy explains what personal data retentix handles, why, and what you can do about it. It is deliberately specific: where we say we do not do something, we do not do it.
Who we are. Osman Nuri Uluhan, a sole proprietor established in Turkey, trading as retentix. Registered address: Hurma Mah., Royal Homes Sitesi, 252. Sokak, B Blok No: 41, Konyaaltı / Antalya, Turkey. Contact: hello@retentix.co.
1. Two different situations
retentix serves two kinds of people, and your rights depend on which one you are.
If you have a retentix account — you are a Founder. We are the controller of your account data and this policy governs it directly.
If you reached a cancel flow page — you are a Subscriber of a business that uses retentix. That business decides what happens on that page and what is recorded about you. They are the controller; we only store and process the record on their behalf. If you want your data accessed, corrected, or deleted, contact that business first. You can also write to us and we will pass the request on and tell you we have done so, but we cannot act on their data without their instruction.
Read section 8 if you are a Subscriber — it is written for you.
2. What we collect
From Founders:
- email address, and authentication credentials (stored hashed, handled by Supabase Auth)
- plan tier and billing status
- product names, slugs, and the monthly revenue value you enter for each product
- your branding settings, including the powered-by preference
- the cancellation reasons, offers, and offer copy you configure
- support correspondence you send us
- a signing key for your account, so a subscriber identity your own system vouches for can be told from one that is merely claimed
- if you connect one, a restricted key to your billing provider. It is encrypted at rest and scoped to your account by row-level security — see section 10, which also explains why your signing key above is not. You can remove it yourself at any time from your settings, and removal is immediate
From cancel flow pages (Subscriber Data):
- a session identifier
- which cancellation reason was selected
- which offer was shown, its parameters, and whether it was accepted
- the customer reference supplied by the Founder — intended to be a pseudonymous identifier such as a billing-system customer ID
- a verified subscriber identifier, recorded only when the Founder's own system signed it and the signature checked out. It is not the same field as the customer reference above, which is whatever the link carried and is never verified
- timestamps and the associated product
Where the Founder has connected a billing provider key, we additionally record, for that cancellation only: whether applying the accepted offer succeeded and the provider's short code if it did not, the provider's own reference for what was created, and the price the provider reported — its amount, currency, quantity, and recurrence. These describe a subscription, not a person, and no card number or payment instrument is among them.
We also keep two operational records that are about events rather than people. When we try to notify you that an offer was accepted, we record which channel we used, whether it worked, and the provider's short failure code if it did not — never the contents of the message. And when our own payment provider tells us something about your subscription, we record which provider it was, their identifier for the event, when it happened, and what we did about it, alongside the raw message they sent. Section 6 says how long each part of that is kept.
We do not collect at all: card numbers, bank details, or any payment instrument; special-category data such as health, religion, ethnicity, or sexual orientation; biometric data; precise geolocation; browsing history or cross-site behavioural data. We do not buy data about you from anyone.
We ask Founders not to place names, email addresses, or other directly identifying data in the customer reference field. If a Founder does so anyway, that data reaches us without our asking; the Founder remains the controller of it and we handle it under this policy and our contract with them.
3. Why we process it, and on what legal basis
| Purpose | Basis (GDPR) |
|---|---|
| Creating your account and letting you sign in | Performance of a contract |
| Providing the panel, flow pages, exports, and notifications | Performance of a contract |
| Taking payment and applying your plan entitlements | Performance of a contract |
| Answering your support requests | Performance of a contract |
| Keeping the service secure, preventing abuse and fraud | Legitimate interests |
| Diagnosing errors and maintaining reliability | Legitimate interests |
| Complying with tax, accounting, and other legal obligations | Legal obligation |
Subscriber Data is processed on the instructions of the Founder who configured the flow. Their own privacy notice, not ours, tells you the basis they rely on.
We do not use your data for advertising and we do not use it to train machine learning models.
4. Who we share it with
We use a small number of service providers. Each processes data only to provide its part of the service, under a contract that restricts it to that purpose.
| Provider | What it does | Where |
|---|---|---|
| Supabase | Authentication and database | Frankfurt, Germany (eu-central-1) |
| Cloudflare | Site hosting, edge compute, DNS, email routing | Global edge network |
| Brevo (Sendinblue SAS) | Transactional email to Founders | European Union |
| Paddle (Paddle.com Market Ltd) | Merchant of Record: payments, invoicing, tax | United Kingdom and United States |
| Stripe (Stripe, Inc.) | Founder-directed billing integration: reading subscription prices and applying accepted offers, using a restricted key the Founder connects | United States |
This table lists every provider we use today. When one of them changes, the table changes with it — and that is checked automatically rather than left to memory, so a provider we have stopped using cannot quietly stay on the list.
Beyond these, we disclose data only where the law requires it, or in connection with a sale or reorganisation of the business — in which case this policy continues to apply to data already collected until it is replaced by one that is no less protective.
We do not sell personal data, and we do not share it for cross-context behavioural advertising.
5. Where your data is stored and moved
Our primary database is in Frankfurt, Germany, inside the European Economic Area. Founder account records and Subscriber Data are stored there.
Some processing necessarily happens outside the EEA. Cloudflare operates a global edge network, so a request may be served from a location near you. Brevo, which sends our email, processes it inside the European Union. Paddle, which sells and invoices your subscription, is a group of companies rather than one: which of them is your counterparty depends on where you are, and they are based in England, the United States, Canada and Ireland. Their own terms name the entity for your purchase. We are established in Turkey and access the service from there.
Where personal data leaves the EEA, we rely on the data protection terms of the provider concerned, which incorporate the European Commission's Standard Contractual Clauses or, for the United Kingdom, the transfer mechanism its own law provides. We ask each provider to commit to safeguards equivalent to those in this policy, and we do not use a provider that will not. Copies of the relevant terms can be requested from us.
If you would like to know exactly which provider handles which part of your data and on what basis, write to hello@retentix.co and we will tell you.
6. How long we keep it
| Data | Retention |
|---|---|
| Cancel flow events (Subscriber Data) | 24 months from the event, pruned daily, plus removal when the product or the account goes |
| Founder account and configuration data | For as long as your account is open |
| Support correspondence | Kept in our mailbox and deleted when we no longer need it for the request or a follow-up |
| Your signing key | For as long as your account is open |
| A connected billing provider key | Until you disconnect it, which you can do yourself at any time, or until your account closes — whichever comes first |
| Fulfilment records — whether an accepted offer was applied, and the price the provider reported | 24 months from the attempt, pruned daily, plus removal when the product goes |
| Notification delivery records — which channel, whether it worked, and the provider's failure code | 24 months from the attempt, pruned daily |
| Billing provider event records | The raw message from the provider is erased 90 days after we receive it, daily. What stays is the minimal record — which provider, their event identifier, when it happened, and what we did — kept permanently, because it is what stops the same payment event being applied twice |
| Invoices and tax records | Held by Paddle as Merchant of Record, for the period their statutory obligations require |
Closing your account is something you ask us for. Write to us and we will do it. When we do, your account record is removed and everything keyed to it goes in the same operation: your products and their cancel flow events, your fulfilment and notification records, your signing key, and any billing provider key you had connected. Backups are overwritten on their normal rotation cycle, after which the data is gone from those too. One thing does not go. The billing provider event records described above are detached from your account rather than deleted, because the minimal record is what stops a payment event being applied twice and that has to outlive the account it once belonged to.
Some rows above are bounded by a clock and some by an event — an account closing, a product being deleted, a key being disconnected. Both are periods; only one is a number. The rows that carry a number are enforced by a scheduled job that runs every day, not by a promise to remember. Where neither applies we say so rather than printing a figure nothing enforces: today that is support correspondence, which sits in our mailbox and has no rule beyond our own judgement.
7. Cookies
We use only what the service needs to work: a session cookie so you stay signed in, and security-related storage.
We run no third-party analytics, no advertising pixels, and no cross-site tracking. That is why you do not see a cookie banner here — there is nothing to consent to. If that ever changes, this page changes first, before the tool ships.
Cancel flow pages set no tracking cookies. The session identifier recorded there identifies the flow visit, not you across the web.
8. If you reached a cancel flow page
You clicked cancel on a subscription, and the business you subscribe to used retentix to build the page you saw.
What was recorded: which reason you selected, which offer you were shown, whether you accepted it, the time, and a reference code that business uses to identify your account with them. We were not told your name or your email address unless that business chose to put it in the reference field, which we ask them not to do.
Your choice on that page is an agreement between you and that business. Who carries it out depends on how they have set retentix up: by default they apply the discount, pause or downgrade themselves and we only tell them to. If they have connected a key to their billing provider, we apply it on their instruction, on their behalf, using the permissions that key allows. Either way the agreement is with them, and if an offer you accepted was not applied, contact them.
Where we do act on their billing provider, we may record what the provider told us about your subscription — the price, the currency, the quantity, and how often it recurs — together with whether the change succeeded and, if not, the provider's own short code for the refusal. We are not told your card number and never see it.
To access or delete what was recorded, contact the business. If you cannot reach them, write to hello@retentix.co with the reference and we will identify the account and pass your request on.
9. Your rights
Depending on where you live, you may have the right to know what data we hold, to get a copy, to have it corrected or deleted, to restrict or object to processing, to data portability, and not to be subject to solely automated decisions with legal effect. We do not make automated decisions of that kind.
Where we rely on consent, you can withdraw it at any time; that does not affect processing that already happened.
To exercise any of these, email hello@retentix.co or use our contact form. We will respond within the time the applicable law allows — one month under the GDPR, thirty days under Turkish law — and we may need to verify who you are first, using only the information needed to do so. We do not charge for this and we will not treat you worse for asking.
If you are in the EEA, the UK, or Switzerland, you may also complain to your national data protection authority. If you are in Turkey, you may apply to us under Article 11 of Law No. 6698 and then complain to the Personal Data Protection Authority (KVKK).
10. Security
Data in transit is encrypted. Access to production data is limited to what is needed to operate and support the service. Database access is governed by row-level security so an account can only reach its own rows, and export routes are gated server-side rather than in the browser. Passwords are hashed by our authentication provider and we never see them.
About the keys, stated plainly rather than reassuringly. The two are not held the same way, and we would rather you knew that than found it out.
The billing provider key you connect is encrypted at rest. It is encrypted with a passphrase kept in a separate secret store, and only the one server-side function that has to use it can decrypt it. It is never returned to any screen in either form. Row-level security scopes it to your account on top of that — an access boundary, which is a different thing from encryption and worth naming separately. Two things still follow. Connect a restricted key, never a full-access one, so that what it can do is bounded at your provider rather than only by us. And remove it from your settings the moment you stop wanting us to act on your provider — removal is immediate and needs no request to us.
Your account signing key is not encrypted, and the reason is not neglect. We hold the only copy of it: it is shown to you once when it is created and no part of the service will show it again. Encrypting it would put it behind a passphrase, and if that passphrase were ever lost the key would be unreadable — signature checking and key rotation would both stop, and there would be no reset we could offer you, because there is nothing left to reset from. The provider key does not have that problem: it belongs to Stripe, you can revoke it and issue a new one in a minute, and reconnecting is two clicks. Different recoverability, different answer. We regard this as an open item rather than a settled one, and if it changes this page changes with it.
No system is perfectly secure, and we will not pretend otherwise. If a breach affects your data we will tell you and the relevant authority as the law requires.
11. Children
retentix is a business tool and is not directed at children. We do not knowingly collect data from anyone under 18. If you believe we have, write to hello@retentix.co and we will delete it.
12. Changes
We will update this policy when what we do changes. The "Last updated" date at the top always reflects the current version, and we will tell Founders by email before material changes take effect.
13. Contact
Osman Nuri Uluhan, trading as retentixHurma Mah., Royal Homes Sitesi, 252. Sokak, B Blok No: 41, Konyaaltı / Antalya, Turkey
hello@retentix.co · contact form