Data processing agreement

This agreement is between you, the seller using Till ("Controller"), and [registered entity name], company number [company number], of [registered address] ("Processor", "Till").

It forms part of the Till terms of service and takes effect when you start using Till. Where it conflicts with the terms of service on a data protection matter, this agreement wins.

"UK GDPR", "EU GDPR", "personal data", "processing", "controller", "processor", "data subject" and "supervisory authority" have the meanings given in the applicable data protection law. "Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the EU GDPR, and the Privacy and Electronic Communications Regulations 2003, as applicable.

Which data this covers

This agreement covers buyer data only — the personal data of the people who buy from your site, which Till processes on your instructions.

It does not cover your own seller account data. For that, Till is the controller in its own right and the privacy policy applies instead. A single agreement cannot cover both, because the two sets of data are held for different people's purposes.

Subject matter

Processing of your buyers' personal data so that purchases made through Till's checkout on your website can be recorded, delivered and re-downloaded, and so that you can administer those orders.

Duration

For as long as you use Till, plus the retention periods in section 11. This agreement stays in force for as long as Till holds any of your buyers' personal data.

Nature of the processing

Collection, recording, storage, retrieval, organisation, transmission by email, restriction, erasure and pseudonymisation, carried out by automated means.

Purpose

• Creating and recording an entitlement when a buyer pays.
• Sending the buyer a delivery email with a link to their library.
• Authenticating a buyer who returns to their library, and minting short-lived signed download links for the files and versions their purchase entitles them to.
• Notifying buyers once when you publish a new version of a file they are entitled to.
• Showing you your own orders, and letting you resend a delivery email.
• Reflecting refunds, disputes and revocations onto the buyer's access.
• Recording when a buyer opens a link we issued them, and whether it opened or was refused, so you can see that what you sold is reaching the buyer and can spot a link being used by somebody else.
• Recording the country the buyer was in when they paid, as the place of supply of the sale — the fact you need in order to account for tax on it, and one that cannot be re-derived later.
• Issuing a VAT invoice for a purchase, where the buyer asks for one — creating or reusing a customer record for that buyer on your Stripe account, naming it on the payment, and having Stripe produce the numbered document off your own invoice sequence. You are the supplier and the invoice is yours; we hold no copy of it.
• Applying a discount code you created to a purchase, and recording the redemption against a one-way pseudonym of the buyer's email address so that a per-buyer limit can be enforced without a record of who used which code.
• Inviting a GitHub account a buyer names to a repository you sell access to, using the Till GitHub App you installed.
• Relaying a message from a buyer to you where they contact you about a purchase or a withdrawal, so that your own address is not published to whoever opens a link.
• Recording purchases you tell us to record without a payment — a purchase you comp, and a list of buyers you import from another platform so that they keep their access here.
• Producing an export of your own orders when you ask for one.
• Repairing failed fulfilment — a reconciliation process that walks payments back from Stripe and delivers anything that was paid for but never sent.

Data subjects

The buyers of your digital products — individuals who complete a purchase through a Till checkout on your website, and who may afterwards sign in to a Till buyer library.

Personal data

Location data is limited to country, by design. Country is recorded in two places here and nowhere else: on the purchase, as the place of supply, and on each access log record. Both are read from our own network edge, which sets the value itself and strips it from incoming requests, so it is not something a buyer's browser can choose. Where a buyer asks for a VAT invoice, the purchase's country is copied onto the customer record and the document on your Stripe account — a third place, on your account rather than in ours, and still a country and nothing finer. No city, region, coordinate or IP address is recorded against a purchase or an access record. In the access log that is enforced by the database, which accepts two letters or nothing at all; on the purchase it is enforced by the single code path that writes it. An unknown country is stored as nothing rather than as a place. Buyer IP addresses appear only in server logs and in a buyer's own sign-in session record, neither of which is joined to either field.

Access log records are kept for 400 days — a little over 13 months — and are then deleted automatically by a scheduled job. That is much shorter than the purchase records they relate to, because they serve monitoring rather than proof of sale. The country on the purchase is part of the purchase record and is kept for as long as it is.

No special category data under Art 9 and no criminal offence data under Art 10 is processed, and none should be placed in free-text fields. Card and payment instrument details are not processed by Till at all: they are collected in the buyer's browser by Stripe and transmitted directly to Stripe.

Till processes buyer personal data only on your documented instructions, including on international transfers, unless required otherwise by law — in which case we will tell you before processing, unless the law prohibits us from doing so.

Your instructions are: the terms of service, this agreement, and the actions you take in the Till dashboard, the Framer plugin and the checkout components you place on your site. Configuring your store, publishing a version, resending a delivery email or issuing a refund are all instructions given through the product.

If we consider an instruction to infringe Data Protection Law, we will tell you.

Till does not market to your buyers, does not sell or share their data, and does not use it to train anything. Two narrow uses are Till's own rather than yours, and we are a controller rather than your processor for them: monitoring our own errors, and counting purchases, deliveries and downloads to know whether the service is working. Both identify a buyer by a reference to their order or by a one-way pseudonym of their email address, not by the address, and neither is used to contact them or to profile them.

Till ensures that anyone authorised to process buyer personal data is bound by an appropriate duty of confidentiality, and that access is limited to those who need it to operate and support the service.

Till implements appropriate technical and organisational measures, having regard to the state of the art, the cost of implementation, and the risk to data subjects. The measures in place are set out in Annex 2. In summary:

• Payment data is out of scope by design. Direct charges mean card details go from the buyer's browser to Stripe and never touch Till's servers, so the highest-risk category of data in an e-commerce system is one we do not hold.
• Files are private by default. Product files are stored in private object storage with no public URL. Downloads are served through signed links that expire after five minutes.
• Access control is enforced at the data layer. A download link is only minted after the request is matched, in the database query itself, against a purchase owned by the signed-in email address, with an active status, and for a version that purchase is entitled to.
• Passwordless authentication. No passwords are stored; one-time codes are stored hashed and expire in minutes.
• Encryption. TLS in transit throughout; encryption at rest by our infrastructure providers.
• Tenant isolation. Every store's products, files and orders are scoped to that store, and file storage paths are namespaced per store.
• A buyer's link is not a credential. Each deliverable a buyer bought has its own link, and it resolves only after whoever opened it has signed in as the address that bought it. A refusal never distinguishes a link that does not exist from one that belongs to somebody else, so a link cannot be used to discover what a store sells.
• Monitoring. Structured application logging and error capture, with a reconciliation process that detects and repairs undelivered purchases.

One measure Till cannot provide, named here rather than left to be discovered: where you sell access to a private repository, withdrawing a buyer's access in Till does not remove the GitHub account we invited from the repository. Only you can, in GitHub.

You give Till general written authorisation to engage the sub-processors listed in Annex 3. Till imposes on each of them data protection obligations no less protective than those in this agreement, and remains fully liable to you for their performance.

Till will give you at least 30 days' notice by email before adding or replacing a sub-processor. If you reasonably object on data protection grounds within that period, we will work with you to find an alternative; if we cannot, you may terminate your use of Till without penalty, and section 11 applies.

Stripe also acts as an independent controller in its own right for payment processing and fraud prevention, under its own terms with you as a Stripe connected account holder. That processing is outside this agreement.

Where Till or a sub-processor transfers buyer personal data outside the UK or the EEA, the transfer is made under the European Commission's Standard Contractual Clauses, the UK International Data Transfer Addendum, or another mechanism permitted under Chapter V of the applicable GDPR. Till will make the relevant transfer documentation available on request.

Buyers should address requests to you, as their controller. If a buyer contacts Till directly, we will not respond substantively on your behalf — we will tell them to contact you, and pass the request to you without undue delay.

Taking into account the nature of the processing, Till will assist you by appropriate technical and organisational measures in responding to requests under Chapter III, including access, rectification, erasure, restriction, portability and objection.

How erasure is carried out

A purchase record is simultaneously the buyer's personal data, your proof of sale, and the buyer's own key to the files they bought. Deleting the row outright would destroy records you need for tax and for defending a chargeback.

So Till erases by pseudonymisation: the buyer's email address is replaced with a one-way hash and the identifying detail in the event log is cleared, while the amount, currency, Stripe payment reference and date are retained. Those retained fields no longer identify the buyer, and their retention is grounded in Art 17(3)(b) and Art 17(3)(e). The consequence — which the buyer must be told — is that they permanently lose library access to that purchase.

The access log described in section 3 is deleted on erasure rather than pseudonymised. It is not a record of the sale and nothing depends on it, so there is no Art 17(3) ground to keep it — and unlike the purchase record, deleting it costs the buyer nothing. The buyer's country on the purchase is retained: on its own it does not identify anybody, and it is part of what you need to account for the sale.

One limit on erasure and on restriction that you should know before you promise a buyer anything: where a buyer claimed a repository grant, Till can delete the record of the GitHub account it invited, but it cannot remove that account from the repository. Only you can, in GitHub. The same limit applies when you withdraw access rather than erase.

Requests are handled manually today. Send them to [privacy contact address] and we will act within a period that lets you meet your own one-month deadline under Art 12(3).

Till will notify you without undue delay after becoming aware of a personal data breach affecting your buyers' personal data, with the information Art 33(3) requires as far as we have it: the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken. Where we do not have all of it at once, we will provide it in phases.

Till will provide reasonable assistance with your data protection impact assessments and with any prior consultation with a supervisory authority, in each case limited to the processing carried out by Till and to information we actually hold.

On termination, and at your choice, Till will delete or return your buyers' personal data and delete existing copies — unless Data Protection Law or another law requires us to keep it.

Three qualifications, stated plainly because they are real:

• Buyers keep what they paid for. Deleting purchase records would strip buyers of access to files they already bought, which would put you in breach of your own contracts with them. Till's default is therefore to retain purchase records for six years — the tax and accounting period — and then pseudonymise them, rather than to delete on termination. Tell us if you want deletion instead, and take your own view on your buyers' rights before you do.
• The access log goes. Unlike purchase records it is not proof of anything you need, so it is deleted on termination and, in the ordinary course, 400 days after each record is written.
• Backups. Data may persist in routine encrypted backups after deletion from the live system, and is deleted as those backups age out. It remains subject to this agreement until it is.

Till will make available to you the information necessary to demonstrate compliance with Art 28, and will allow for and contribute to audits, including inspections, conducted by you or an auditor you appoint.

In practice:

• First, Till will answer reasonable written questions and provide the documentation it holds — this agreement, the sub-processor list, security documentation, and any certifications or reports our sub-processors publish.
• If that does not answer your question, you may audit on 30 days' written notice, no more than once in any 12-month period unless required by a supervisory authority or following a personal data breach.
• Audits happen during business hours, must not disrupt the service or compromise other sellers' or buyers' data, and the auditor must be bound by confidentiality and must not be a competitor of Till.
• You bear your own audit costs.

The liability provisions of the terms of service apply to this agreement. Nothing here limits either party's liability to a data subject or to a supervisory authority under Data Protection Law.

Till may update this agreement where Data Protection Law changes or where the processing changes, on at least 30 days' notice to sellers by email. This agreement is governed by the laws of England and Wales.

Controller: the seller using Till. Processor: [registered entity name].

Subject matter, duration, nature and purpose: as set out in section 2.

Categories of data subject and personal data: as set out in section 3.

Frequency: continuous, for the duration of the service.

Retention: as set out in section 11 and in the privacy policy.

The list in section 7 is Annex 3 to this agreement.