Everyone who can touch your data, and where they sit.
This is the full list of third parties engaged by FIT PUP LTD to process customer data, per UK GDPR Article 28. We notify customers of changes at least 30 days in advance and honour a reasonable objection right. Two further groups are listed separately below and are not Article 28 sub-processors we engage: opt-in transport paths (Telegram, a customer-configured alert webhook) and your own connected mailbox providers.
The important negative
In our production deployment, invoice content is never sent to any third-party OCR, AI, analytics, or document-processing service — extraction runs on OCR and language models we host ourselves, so no model or extraction vendor appears on this list. (Email transport is a separate matter — see the Resend row and its note below.)
Current sub-processors
| Provider | Purpose | Data | Location | Transfer basis |
|---|---|---|---|---|
| Hetzner Hetzner Online GmbH (Germany) | Hosting, compute, and storage — the infrastructure the product runs on. | All product data: invoice documents, supplier records and bank details, user accounts, audit events. | EU — Finland (Helsinki, HEL1-DC8) | Within the EU; no third-country transfer. |
| Cloudflare Cloudflare, Inc. (USA) | DNS, CDN, and TLS termination at the network edge for all inbound traffic; and Cloudflare Turnstile anti-bot verification on the public demo/contact form. | Transient request data in transit (including invoice uploads) at the edge, not stored at rest; plus, for demo-form submissions, a Turnstile verification token and the visitor's IP address. | Global edge; corporate entity in the USA. | UK IDTA / EU SCCs as applicable for the US-established processor. |
| Resend Resend (USA) | Email transport. Always: outbound transactional email (review alerts, account notifications) and delivery of website demo/contact-request emails. Optionally, for workspaces that switch on email-forwarding intake: inbound receipt of forwarded supplier invoices. | Outbound alert emails: recipient email address plus alert metadata — workspace name, the invoice number and the invoice's original filename, supplier name, amount, review reason, and a review link. No invoice documents or full bank details. Website demo/contact requests: the details a visitor submits (name, work email, company, phone, invoice volume, and their answer about supplier bank-detail changes). Inbound (opt-in only): the forwarded invoice email and its attachments — invoice content that may include supplier bank details — received and stored by Resend under Resend's own retention policy (PayHQ reads them for ingestion but does not purge them from Resend afterwards). | USA | UK IDTA / EU SCCs as applicable. |
- Resend: Outbound email alerts (metadata only, no invoice documents) go through Resend whenever email notifications are enabled. Inbound email-forwarding intake via Resend is a separate, optional, opt-in interim arrangement, offered only to customers who expressly agree to it, while we build a more sovereign EU-hosted inbound path. A workspace with email notifications and inbound intake both off routes no data through Resend.
Data residency
Customer data is stored in the EU with Hetzner in Finland (Helsinki, HEL1-DC8). Cloudflare terminates TLS at its global edge before traffic reaches our EU infrastructure — we name that here rather than claim data “never leaves the EU”. Outbound alert emails carry no invoice content or bank details. The Cloudflare edge is an always-on transit path to a US-established processor — it terminates TLS for all traffic, including invoice uploads — and is not something a workspace can opt out of. Beyond that default, the additional paths that reach a non-EU destination are all opt-in. The only opt-in path to a PayHQ-engaged sub-processor is email-forwarding intake via Resend (US), which carries invoice content. The rest are the separately-listed opt-in transport paths and your own connected mailboxes, not sub-processors we engage: the Telegram intake bot and a connected Microsoft 365 mailbox where an operator enables the Graph connector can carry invoice content (a direct Google/Gmail connector is planned, not yet available); and the Telegram alert channel and a customer-configured alert webhook (US for Slack, or wherever the workspace points it) carry alert metadata only (workspace and supplier name, amount, reason, an invoice label, and a review link). A workspace that enables none of the opt-in paths keeps invoice data on our EU infrastructure, with the Cloudflare edge as the only transit exposure. (Website demo/contact submissions are separate controller-side data — see the Privacy Notice.)
Opt-in transport paths (not Article 28 sub-processors we engage)
These are third parties your data can transit when a workspace switches on an optional integration. They are notArticle 28 sub-processors PayHQ engages: we hold no DPA or SCCs with them and cannot bind them, and enabling either is the workspace’s own choice. They are therefore outside the 30-day notice/objection process and the “terms no less protective” commitment above — see the DPA §4/§5 carve-out.
| Path | Purpose | Data | Location | Transfer basis |
|---|---|---|---|---|
| Telegram Telegram FZ-LLC (Dubai; internationally operated infrastructure) | A separate, optional Telegram integration — off unless a workspace switches it on. Two uses: an alert channel that posts review alerts, and an invoice-intake bot a user forwards invoices to. In both, Telegram is the transport that carries the message to PayHQ; all processing happens on our own servers, never on Telegram's. | Alert channel: alert metadata only (workspace name, supplier name, amount, review reason, an invoice label such as the invoice number or original filename, and a review link). Intake bot: the invoice documents a user forwards to reach PayHQ — invoice content that may include supplier bank details. PayHQ downloads a copy for processing but does not delete the message, so the forwarded document also remains in the user's Telegram chat and Telegram's infrastructure under Telegram's own retention. | International (Telegram-operated infrastructure); forwarded content is retained by Telegram under its own policy. | Opt-in transport. PayHQ does not hold an Article 28 DPA or SCCs with Telegram — a workspace accepts this when it enables the integration. |
| Slack / customer-configured webhook Slack Technologies, LLC (USA) — or another endpoint the workspace configures | Optional alert channel — posts review alerts to a customer-configured webhook URL (typically a Slack incoming webhook), only if that channel is switched on. | Alert metadata only: workspace name, supplier name, amount, review reason, an invoice label (invoice number or original filename), and a review link. No invoice documents or full bank details. | USA for Slack; otherwise wherever the configured webhook points. | Opt-in, workspace-chosen destination. PayHQ does not provide an IDTA/SCC transfer basis for this alert webhook — a workspace accepts that when it configures the channel. |
- Telegram: Telegram is a separate opt-in module, off by default: with no Telegram integration connected, nothing is routed through Telegram. PayHQ runs no extraction, analysis, or storage of customer data on Telegram — invoices are processed only once they reach our own servers — but this is transport we do not control: PayHQ downloads the forwarded document and does not purge it, so a copy remains in the user's Telegram chat and Telegram's storage under Telegram's retention policy.
- Slack / customer-configured webhook: The destination is any https/http URL the workspace enters — it is not restricted to Slack hosts in code — so where the alert metadata goes is under the workspace's control, not a fixed Slack-only path.
Planned sub-processors
These are not engaged yet and no customer data flows to them today. They will move to the list above, with notice, only when the corresponding feature ships and a contract is in place.
| Provider | Purpose | Location |
|---|---|---|
| Payee-verification providers | Confirmation of Payee (UK) / Verification of Payee (EU) — checking a supplier account name against its bank details. | EU / UK, provider-dependent. |
Customer-connected data paths (your own providers)
These are not sub-processors we engage — they are your own third-party providers that PayHQ integrates with under your authorisation. They fall outside the Article 28 sub-processor change/objection process above, because we cannot give notice for, or bind, a provider that is under your own agreement.
| Provider | Purpose | Data | Location |
|---|---|---|---|
| Microsoft 365 (connected mailbox) | Optional mailbox intake — when a workspace connects its own Microsoft 365 mailbox, PayHQ reads new messages and their attachments to ingest invoices. Available where an operator enables the Graph connector; off by default. | The connected mailbox's messages and attachments that PayHQ retrieves (invoice content, which may include supplier bank details). | Provider-dependent (the customer's own tenant and region). |
| Google / Gmail (connected mailbox) | Planned mailbox intake — direct reading of a connected Google/Gmail mailbox to ingest invoices. Not yet available. | The connected mailbox's messages and attachments that PayHQ would retrieve (invoice content, which may include supplier bank details). | Provider-dependent (the customer's own tenant and region). |
- Microsoft 365 (connected mailbox): Off by default and not part of the self-serve connect flow (which today provisions only email-forwarding intake via Resend). Direct Microsoft 365 mailbox reading is wired via the Microsoft Graph connector and is active for a workspace only where an operator has configured and enabled it. It remains your own mailbox provider under your own agreement — not an Article 28 sub-processor PayHQ independently engages, which is why it is listed here rather than above.
- Google / Gmail (connected mailbox): On our roadmap and not available today; no Google/Gmail mailbox is read. When it ships it will be off by default and remain your own mailbox provider under your own agreement — not an Article 28 sub-processor PayHQ independently engages.
Machine-readable
The same list is available as JSON at /trust/subprocessors.json so you can watch it for changes. To be notified of updates, email [email protected].