Suppliers who process data for us

Every company that handles data on our behalf, what we send each one, and where. Five of them, and two are wired without being switched on.

Last updated 18 August 2026.

How to read this

There are two different claims on this page and they have different evidence behind them, so they are kept apart.

What we send a supplier is a fact about our own code, and every entry below was read out of the repository rather than recalled. Where a supplier then processes it is a fact about them, and the only source worth citing is their own published terms. Where we have read those and can say something specific, the entry says what we checked. Where we have not, it says that instead of repeating a location we have not verified.

The suppliers

Neon

The database

What we send them: Everything the service stores. Accounts and the people on them, codes, every destination a code has ever had, individual scan records, daily scan totals, abuse reports, billing references and the lines we keep about each account.
Where: London. Neon's own region list gives AWS Europe (London) as aws-eu-west-2, and the endpoint our application connects to is in eu-west-2. Checked 18 August 2026.
Their terms: Neon privacy policy

Netlify

Hosting for all three sites

What we send them: Every request to this site, to the application and to the redirect that resolves printed codes. That means ordinary web server logs: the IP address the request came from, the browser's user agent and the path asked for. The redirect is also handed the scanner's IP address and a country and city worked out by Netlify, and that is where the address is turned into the daily hash and dropped.
Where: A United States company serving from locations around the world, so a request is answered by whichever location is nearest to whoever made it. Netlify's public GDPR page says its data processing agreement is incorporated by reference into its terms and does not itself state processing locations, so we are not stating one here.
Their terms: Netlify on GDPR

Brevo

Transactional email

What we send them: The recipient's email address and name, and the contents of the message. That is confirmations, invitations, password resets and the alerts our own monitoring sends us. No marketing email is sent to customers and there is no mailing list.
Where: Their own notice is the source, and we have not independently verified their processing locations, so this entry does not state one.
Their terms: Brevo privacy policy

Paddle

Payments, as merchant of record

What we send them: Nothing yet. Payments are not switched on, and the integration is pointed at Paddle's sandbox rather than at anything live. When it is switched on, Paddle takes the card details and the billing address directly and we never see either. What comes back to us is a customer reference, a subscription reference and which plan it is.
Where: For buyers outside the United States and Canada, Paddle's own buyer terms name Paddle.com Market Limited, registered in England and Wales, company number 8172165, at 30 Old Bailey, London. Checked 18 August 2026.
Their terms: Paddle buyer terms

Google

Analytics on this site, and destination safety checks

What we send them: Two separate things, and neither is currently reaching them. The analytics tag on this marketing site receives page views, and only from people who have agreed in the banner. The Web Risk service receives the address a customer has pointed a code at, so we can refuse to serve a destination known for malware or phishing. Web Risk never sees anything about a person scanning, and neither service ever sees scan data.
Where: Google operates internationally. Their own terms are the source for where each service processes what it is given.
Their terms: Google privacy policy

Wired, and not switched on

Three things exist in the code and are doing nothing today. They are here because a list that only names what is running tells you nothing about what one configuration change would start.

Paddle is pointed at the sandbox. No card has been charged through this service and no real billing data has reached them.
Google Web Risk has no key set, so the check is skipped and no destination is being sent to Google. The other safety checks, which run locally, are unaffected.
Google Ads, Meta and TikTok have no ids set. A tag with no id ships no code at all rather than shipping a script that waits, so there is nothing on the page for them. The cookie notice covers what would change if one were switched on.

The analytics tag on this site is a fourth case and a stranger one: it has an id, and the security policy this site sends means the browser refuses to fetch it. The cookie notice says so.

What we do not use

Worth stating, because the absence is the point and because each of these is a question we have been asked.

No advertising or conversion pixels, on any of the three sites.
No session recording, heatmaps, or any tool that replays what somebody did on a page.
No chat widget, no support tool holding customer conversations, and no customer relationship system.
No third-party fonts or scripts on this marketing site. The typefaces are served from this domain, and the site sends a policy that allows scripts from this address and from nowhere else. The application allows one more, which is Paddle’s checkout.
Nothing here is used to train a machine learning model, by us or by anybody we send data to.
No data is sold, and no supplier is given data for purposes of their own.

Changes to this list

If we add a supplier that processes customer data, this page changes on the day it goes live and the date at the top changes with it. Where the change affects you, we email the address on your account, which is what the privacy notice commits us to.