Legal

Privacy policy

Till handles two quite different sets of personal data, under two different roles. This policy explains both: the data we hold about sellers as a controller, and the data we handle about buyers on a seller's behalf as a processor.

Draft of 5 August 2026

Draft — not legal advice

This document was prepared from Till's source code and architecture as a starting point for review. It has not been written or checked by a qualified solicitor, and it must be before Till takes a real payment or onboards a real seller. Highlighted values are unresolved. Nothing here is legal advice.

1. Who we are

Till is a Framer plugin and hosted service that lets a seller sell digital files directly from their own website. It is operated by [registered entity name], company number [company number], registered at [registered address] ("Till", "we", "us").

For questions about this policy or about your personal data, contact [privacy contact address].

2. Our two roles

Which parts of this policy apply to you depends on how you came to Till.

If you are a seller, we are the controller

You signed in to Till, connected Stripe and uploaded files to sell. We decide how your account data is used, so we are the controller for it and this policy is our Art 13 notice to you.

If you are a buyer, the seller is the controller

You bought a digital file from a seller's own website. The seller is the merchant and the controller of your purchase data; Till is their processor, storing and delivering that data on their documented instructions under a data processing agreement. Your first point of contact for questions or requests about your purchase is the seller you bought from. We will help them answer you, and we will pass your request on if you come to us instead.

Three things are ours even in that case: your Till sign-in account, if you create one to use your buyer library; our own error monitoring; and the counts we keep of how the service is being used, for which you are identified by a reference to your order or by a one-way pseudonym of your email address rather than by the address itself. We are the controller for all three.

3. What we hold about sellers

Personal data held about sellers
Data	Why we hold it	Lawful basis
Name and email address	Your account identity, sign-in, and service email we send you.	Art 6(1)(b) — performance of our contract with you
One-time sign-in codes	Passwordless sign-in. Stored hashed and short-lived, so the code itself is not recoverable from our database.	Art 6(1)(b)
Session records — IP address, browser user agent, expiry	Keeping you signed in, and detecting abuse of an account.	Art 6(1)(b) and Art 6(1)(f) — our legitimate interest in securing the service
Store details — store name, brand name, reply-to email, website domain, Framer staging domain, business country, selling currency	Running your store: rendering your checkout on the right domain, and putting your brand rather than ours on the emails your buyers receive.	Art 6(1)(b)
Your Stripe connected account identifier and whether it can accept charges	Routing payments to your Stripe account and telling your buy buttons whether the store is live.	Art 6(1)(b)
Your head-office address and the default product tax code for your store	Asked for once, on the same step as your business country and before your Stripe account exists, because Stripe fixes an account's country as soon as the account has any state and asking later would mean a second onboarding pass. Stored and not yet used for anything: Till calculates no tax today, and this is what it will need when it does.	Art 6(1)(b)
Your partner or affiliate codes, and the identifier of your installation of the Till GitHub App	Appending your own partner code to a link deliverable when a buyer opens it, and inviting the GitHub accounts your buyers name to a repository you sell access to. The GitHub value is an installation identifier, not a credential — we hold no GitHub token of yours.	Art 6(1)(b)
Your products, prices, product images and the files you upload	The thing you are using Till to do. Files are held in private storage; product images are deliberately public because they are rendered on your published page.	Art 6(1)(b)
Your plan and your Till subscription — which plan your store is on, our Stripe customer and subscription references for you, the subscription's status as Stripe reports it, when the paid period ends, and whether you have asked to cancel at the end of it	Billing you for Till Pro, and knowing what your store is entitled to. Note this is the one place the relationship reverses: for your own sales we are not the merchant, but for your Till subscription we are. We store the plan rather than asking Stripe on every page load, so a store we have given Pro to by hand has a plan and no subscription at all.	Art 6(1)(b)
How you use Till — the steps you take in the dashboard and the plugin (signing in, adding a product, uploading a file, connecting Stripe, placing a component, hitting a plan limit), recorded against your account identifier and your email address	Seeing where sellers get stuck so we can fix it, and knowing whether a release helped. Recorded on our servers as you take the action rather than by watching your browser, and not used to advertise to you or shared with anyone but the provider in section 6.	Art 6(1)(f) — our legitimate interest in understanding and improving the service

We never see your bank or identity documents. Stripe Connect onboarding happens on Stripe's own hosted pages. Your bank details, identity verification documents and tax information go directly to Stripe and are governed by Stripe's privacy policy and the Stripe Connected Account Agreement, which you accept with Stripe, not with us.

4. What we hold about buyers

When you buy a digital file through a seller's site, Till records the purchase on the seller's behalf so the file can be delivered to you and re-downloaded later.

Personal data held about buyers
Data	Why it exists
Your email address	Where the download is sent, and the key to your buyer library. Where the purchase went through a card payment it is also passed to Stripe as the receipt address; a purchase the seller comped or imported never reaches Stripe at all.
The payment — amount, currency, Stripe payment intent reference, whether the purchase included future updates, which version of the product you bought where it sells more than one, how the purchase came to exist (a card sale, a comp from the seller, or a record the seller imported from another platform), and its status (active, comped, refunded, revoked or under dispute)	The seller's record of the sale, their basis for refunds and disputes, and what decides which deliverables and which versions of a file you may download.
The country you were in when you paid, as a two-letter code	It is the place of supply of the sale, so it is what decides whether tax was due and at what rate — a question the seller has to be able to answer years later, when your request is long gone and you may have moved. Country and nothing finer: no city, no region and no IP address is recorded against a purchase, and where our network cannot tell us a country we store nothing rather than a guess.
Delivery and download history — when the delivery email was sent, how many downloads you have made, and a timestamped log of purchase, download, resend, refund, dispute, revocation, restoration and comp events	Proving the file was delivered, supporting the seller in a chargeback, and letting you and the seller see what happened to an order.
Why access was withdrawn, and the seller's own note about it, where that happens	So that you are told plainly what happened rather than shown an empty library, and so a withdrawal can be reversed — the reason is what lets a seller who wins a dispute restore exactly what the dispute took, and leave a deliberate withdrawal alone. The note is the seller's words to you.
One link per deliverable you bought, and — for a private repository — the GitHub account name you gave us when you claimed it	The links are how you reach what you bought; each one only opens for the address that bought it. The GitHub name is stored so we can tell you which account was invited, which is the only way to tell a typo from a claim you have forgotten making.
Which new-version notifications you have already been sent	So a seller publishing an updated file emails each buyer once and not repeatedly.
A VAT invoice, where you ask for one — a customer record on the seller's own Stripe account holding your email address and the country of the sale, and the invoice document itself, which carries both of those alongside the amount, the currency, the product and the date of supply	So you can be given a numbered invoice for a purchase you need to put through your own books. It is created only if you ask: no invoice exists for a purchase nobody requested one for. The document is issued and stored by Stripe on the seller's account, because the seller is the supplier and the invoice is theirs — we hold no copy of it, and the number on it comes off their own sequence.
Where a seller runs a discount code — a one-way pseudonym of your email address, the code, the discount and what you were charged	The pseudonym is what lets “one use per person” be enforced without keeping a record of who used which code, and it is deliberately not your address.
Your Till sign-in account, if you use the buyer library — your email address, sign-in sessions with IP address and browser user agent	Signing you in to re-download your purchases without a password.
An access log of the links we give you — which file or link you opened, when, whether it opened or was refused, the country your request came from, and whether the seller's partner code was applied to the link	So the seller can see that what they sold is reaching the person who bought it, can spot a link being used by somebody else, and can see that the partner code they entered is actually being applied. The country comes from our own network and is the only location we record: we do not store your IP address against it, and the database itself will not accept anything finer than a country.

We never see your card details. Payment fields are rendered by Stripe inside your browser and submitted directly to Stripe. Card numbers do not reach Till's servers and are never stored by us.

Separately from the seller's record above, we count the moments that tell us whether Till is working — a checkout being started, a purchase being fulfilled, a delivery email going out, a file being downloaded. Those counts are ours rather than the seller's, so we are the controller for them, and they identify you by a reference to your order, or by a one-way keyed pseudonym of your email address at the moments before an order exists. They carry the product, the store, the amount, the currency and the Stripe payment reference, and never your email address itself.

A seller can also give you a purchase without a payment, or bring a purchase you made on another platform across to Till by uploading their own record of it. Either way the record says which of those it is, we hold the same fields as above, and the seller — who supplied it — is the controller for it.

If the seller sells access to a private code repository, claiming it sends the GitHub account name you type to GitHub, which invites that account and emails it. Nothing else about you is sent, and your Till email address is not. If what you bought is a link, opening it takes you to somebody else's website — the seller's template on Framer, a Notion page, wherever the link points — and what that site does with your visit is covered by its own privacy notice and not by ours.

Held — do not publish until tax calculation is switched on (plan stream G4)

Two rows join the table above on the deploy that turns tax calculation on, and this paragraph replaces nothing — it is an addition:

The tax charged on your purchase — the amount, the rate and the jurisdiction it was charged for. It exists because it is the seller's filing record, and it is kept as long as the purchase record is.
A business tax identifier, if you give one — a VAT or GST number you type at checkout so that the reverse charge or a zero rate can be applied. It is passed to Stripe, which validates it and decides the treatment. Give one only if you are buying as a business; nothing asks a consumer for one and none is needed.

Also to change on that deploy: section 6's Stripe row gains tax calculation as a purpose, and the retention list in section 9 has to say how long a tax record is kept — which is the seller's statutory period, not ours to shorten.

If you ask a seller's purchase page for a VAT invoice, we ask Stripe — on the seller's account, never ours — to create a customer record for your email address and the country of the sale, to name that customer on the payment you already made, and to issue the numbered document. The purpose is the one you asked for and nothing else: the record is not used to market to you, and the country on it is the country already held against the purchase rather than a fresh reading of where you are now.

Review note — remove before publication

Signing in to the buyer library no longer provisions an empty seller store record. That gap — an organisation and a site row created for every buyer who opened their library — is closed: provisioning now follows intent, and a store is created the first time someone actually opens a seller dashboard. A buyer's erasure request therefore no longer touches records that read as "seller" records. Accounts created before that change still carry the empty rows, so a one-off tidy-up is worth doing before publication.

The access log row above is new and needs a look of its own. Our lawful basis for it is legitimate interests as a processor acting on the seller's instruction — the seller needs to know their buyers are receiving what they paid for — and it should be named in the legitimate interests assessment section 5 asks for, not folded into the analytics one. The country is not sent to our analytics provider; it is held for the seller only.

The country on the purchase is a second, separate disclosure and was missing until this draft. It is a different field from the access log's, in a different table, kept for six years rather than thirteen months, and justified differently: it is the place of supply, so the basis is the seller's legal obligation to account for tax (Art 6(1)(c) in the seller's hands, and Art 6(1)(b) as between us and them) rather than the legitimate interest that carries the access log.

It now has a reader, and the minimisation question has changed shape. This paragraph previously said nothing in Till read the field, and invited a reviewer to treat collecting it as defensible only because re-deriving it later is impossible. That argument is no longer the one to test: the buyer invoice reads the country and writes it onto a Stripe customer on the seller's account as the address on the document. So the field is used for the purpose it was collected for, and the question a reviewer should ask instead is a narrower one — whether onward disclosure to the seller's own Stripe account is within what section 4 and the DPA describe, which is where it is now described. Tax calculation (stream G4) will be its second reader and does not change the basis.

One asymmetry worth recording, because the DPA claims a technical guarantee: the access log's country column is constrained in the database to two letters or nothing, so nothing finer can be stored there whatever a later change attempts. The purchase's country column has no such constraint — it is country-only by the one code path that writes it. Either add the same constraint (a migration) or do not describe both as enforced by the database.

5. Why we are allowed to do this

Art 6(1)(b) — contract. Everything needed to run your account and to deliver a purchase you made: sign-in, storing the sale, sending the download, keeping your library available.
Art 6(1)(f) — legitimate interests. Error monitoring, security, preventing fraud and abuse of the service, and measuring how the service is used so we can improve it. Our interest is in Till working, being understood, and not being abused; the processing is limited to what that needs, buyers are counted under a pseudonym rather than by name, and you can object using the contact route below.
Art 6(1)(c) — legal obligation. Keeping transaction records for the period tax and accounting law requires.

For buyer purchase data we act on the seller's instructions. The seller relies on Art 6(1)(b) — the contract of sale between you and them — and it is the seller, not Till, who is answerable for that choice.

6. Who else sees this data

We do not sell personal data and we do not share it for advertising. We use a small, fixed set of service providers, each of which processes data only on our instructions under a written contract:

Sub-processors
Provider	What it does	What it receives
Stripe	Payments and Stripe Connect, invoicing on the seller's account, and separately our own subscription billing	For your sales: buyer email address as the receipt address, the amount and currency, and a reference to the product and store. Where a buyer asks for a VAT invoice, additionally: their email address and the two-letter country of the sale, as a customer record and an invoice document on the seller's own connected account. Card details go to Stripe directly from the buyer's browser, and seller onboarding data goes to Stripe directly. For a Till Pro subscription, separately: the seller's email address and payment details, taken on Stripe's own hosted checkout — we never see the card.
Resend	Transactional email	Recipient email address and the content of the email — sign-in codes, purchase delivery emails, new-version notifications, notices we send a seller about their own store such as a chargeback, and a message a buyer asks us to relay to the seller they bought from (which carries the buyer's address as the reply address, so the seller replies to them and not to us).
PostHog	Error monitoring and product analytics	Technical details of an error — stack trace and request context — and the named events described in sections 3 and 4. Sellers are identified by their Till account identifier and email address. Buyers are identified by a reference to their order, or by a keyed one-way pseudonym of their email address where no order exists yet; their address itself is not sent. Events are recorded by our servers as they happen rather than from your browser, so pageview tracking and autocapture are switched off, session recording is switched off, and no PostHog cookie or stored identifier is set.
Vercel	Hosting and file storage	Requests to Till, including IP addresses in server logs, and the product files sellers upload — held privately and served only through short-lived signed links.
GitHub	Repository invitations, where a seller sells access to a private repository	Only where you claim such a purchase, and only what you type: the GitHub account name to invite, and the repository the seller nominated. Your Till email address is not sent. GitHub then emails the account it invited, under its own privacy notice.
Neon	Database	Everything described in sections 3 and 4, at rest.

We may also disclose data where we are legally required to, or to establish or defend a legal claim.

7. Cookies

Till sets one kind of cookie: your sign-in session. It is what keeps you signed in to the dashboard or to your buyer library, it is set only after you choose to sign in, and it is strictly necessary to provide the service you asked for. Under regulation 6(4) of the Privacy and Electronic Communications Regulations, a cookie of that kind does not require consent.

There is deliberately nothing else. We run no advertising or analytics cookies, no tracking pixels and no session recording. The usage counts described above are recorded by our own servers as the thing happens, not by watching your browser, which is why they cost you no cookie; the small amount of monitoring code that does run in the page is configured to keep nothing at all — no cookie, no stored identifier, forgotten as soon as you leave. That is why you will not see a cookie banner on this site: there is nothing non-essential for you to consent to, and a banner offering a choice that does not exist would be worse than none.

The Till checkout component on a seller's own website sets no cookies at all. Buying through a seller's site does not put anything of ours in your browser unless you sign in to your library.

8. Where the data goes

Our database and our error monitoring are hosted in the European Union. Some of our providers are established in, or process data in, the United States. Where personal data is transferred outside the UK or the EEA, it is covered by the European Commission's Standard Contractual Clauses together with the UK International Data Transfer Addendum, or by another safeguard permitted under Chapter V of the UK GDPR and the EU GDPR.

9. How long we keep it

Sign-in codes: minutes. They expire quickly and are deleted once used or expired.
Sessions: deleted after they expire.
Seller accounts and stores: for as long as the account is open, and for a reasonable period afterwards to handle disputes and outstanding obligations.
Purchase records: six years, because they are the seller's tax and accounting records and the evidence behind any chargeback. After that they are pseudonymised rather than deleted — see section 10.
Payment event logs: 90 days.
The access log described in section 4: 400 days — a little over 13 months — then deleted automatically. Far shorter than the purchase record it relates to, and deliberately: a purchase record is the seller's proof of sale, while an access log only answers whether something odd is happening on a store, which it stops being able to answer long before six years are up. A year plus a month, so that a seller comparing this month with the same month last year still has both.
Abuse counters: the short window they cover, then swept. They hold a pseudonym or a token rather than your address, and nothing that survives the window is a record of anything.
Error reports: according to our monitoring provider's retention settings, currently a matter of months, and they hold technical context rather than content.

Review note — remove before publication

These periods describe the intended retention schedule, with two exceptions, both of which ARE enforced by the scheduled sweeps that run daily: the access log's 400 days, and the abuse counters. Everything else on this list is still intent — expired sessions and the ledger of payment events we have already handled are currently retained indefinitely. Either add those two to the sweep before publishing this section (it is one entry each in the job registry that already exists, not new machinery) or change the wording to describe what actually happens.

The "13 months" this list used to say was rounded from the 400 days the code actually enforces. Published copy and enforced behaviour have to be the same number, so the copy moved rather than the constant: 400 days is what the retention argument in packages/core/src/resolutions.ts is actually for — twelve months plus a month of overlap — and 13 calendar months can be as few as 395 days, which would have made the published figure shorter than the reality.

10. Your rights

Under the UK GDPR and the EU GDPR you have the right to:

ask what personal data we hold about you and get a copy of it;
have inaccurate data corrected;
have data erased, in the circumstances described below;
restrict or object to processing we carry out on a legitimate-interests basis;
receive data you gave us in a portable format; and
complain to a supervisory authority — in the UK, the Information Commissioner's Office at ico.org.uk.

How erasure works for a purchase record

A purchase record is three things at once: your personal data, the seller's proof that they made a sale, and your own key to the library where your files live. Deleting it outright would destroy a record the seller needs for tax and for defending a chargeback.

So when we erase a buyer from a purchase record, we pseudonymise it: your email address is replaced with a one-way hash that cannot be reversed back to your address, and the identifying detail in the event log is cleared. What remains is the amount, the currency, the Stripe payment reference, the country of supply and the date — figures that no longer identify you and that we are entitled to keep under Art 17(3)(b), for compliance with a legal obligation, and Art 17(3)(e), for the establishment or defence of legal claims. The practical consequence is that you lose access to that purchase in your library, because the address you would sign in with is no longer on the record.

The access log described in section 4 is deleted rather than pseudonymised — nothing depends on it, so there is no reason to keep it. One thing erasure cannot reach, stated plainly because you should not have to discover it: a GitHub account we invited to a seller's repository stays invited. We can delete the record that we invited it; only the repository's owner can remove the access itself.

There is no self-service delete button today. Requests are handled manually. Email [privacy contact address] from the address the request concerns and we will respond within one month, as Art 12(3) requires. If you are a buyer, contact the seller you bought from first where you can — they are the controller, and we act on their instruction.

Review note — remove before publication

The pseudonymisation routine and the DSAR export are not yet built; both are manual database work at present. The one-month response commitment is the statutory deadline and is stated here as fact, so someone has to actually be able to meet it from day one.

Both routines also have to reach the analytics store, and neither can today. The events described in sections 3 and 4 sit with our analytics provider keyed to a seller's account id, an order reference, or a keyed pseudonym — so an erasure that pseudonymises the database leaves those events behind, and an access request answered from the database alone is incomplete. Decide what an erasure means for them (delete the person in the provider, or rely on retention ageing them out) and write it into this section, because the sentence above currently promises more than the tooling can do.

11. How we protect it

Everything travels over TLS.
Product files are stored privately and are never given a public URL. Downloads are served through signed links that expire after five minutes and are only minted after we have checked that the person asking owns that purchase and is entitled to that version of the file.
Sign-in is passwordless. There is no password for us to leak, and one-time codes are stored hashed.
Card data never reaches our servers; Stripe handles it and carries the PCI scope.
Every store's data is scoped to that store, and every download request is re-authorised in the database query itself rather than being hidden in the interface.
Errors are captured and monitored so failures are noticed rather than silent.

12. Changes to this policy

We will update this page when what we do changes, and we will change the date at the top. If a change materially affects how we use your personal data, we will tell sellers by email before it takes effect.

13. Contact

[registered entity name], [registered address]. Privacy enquiries: [privacy contact address]. General enquiries: [support contact address].