Kapta — list of subprocessors
STATUS — DRAFT. Not legally reviewed.
This list is referenced by the DPA and the ROPA. Last updated: 2026-05-12.
Tenants are notified at least 30 days before a new subprocessor is added or replaced (DPA § 4.2).
| Subprocessor | What we share | Why | Where they are | Transfer mechanism |
|---|---|---|---|---|
| FareHarbor (Booking.com) | Tenant's booking data (received from FareHarbor → returned to us via the booking-lookup endpoint when we replay) | Booking source — the tenant has separately contracted with FareHarbor; Kapta acts on the data already entrusted to FareHarbor | United States | SCCs in place between the tenant and FareHarbor; Kapta's role is processing-by-passthrough |
| Stripe (Stripe Payments Europe, Ltd. + Stripe Inc.) | Tenant company name, contact email, billing address, VAT ID, payment method tokens (for the tenant — NOT the tenant's customers) | Recurring billing for the Kapta subscription | Ireland + United States | Stripe DPA + EU SCCs (2021/914) — Module 3 (processor → sub-processor) for the Stripe Inc. (US) leg, because Kapta acts as processor for the tenant on its billing data. Stripe is also independently a controller for fraud-prevention; per-flow allocation follows stripe.com/legal/dpa |
| Cloudflare, Inc. | All HTTPS traffic in transit (terminated at Cloudflare) including TLS metadata and IPs; no application-layer data persisted by Cloudflare for the Kapta zone | Reverse proxy / DDoS protection / TLS termination | United States with global PoPs | Cloudflare DPA + EU SCCs (2021/914) — Module 3 (processor → sub-processor): Cloudflare processes the Controller's data on Kapta's behalf, so the proper module is the processor-to-sub-processor flow. Reference: cloudflare.com/cloudflare-customer-dpa |
| Holded (Eseyfact, S.L.) | Tenant's end-customer invoice data | The tenant's chosen invoicing provider | Spain | EU — no transfer mechanism needed |
| Billin (Geseycob 28, S.L.) | Tenant's end-customer invoice data | Tenant's invoicing provider | Spain | EU — no transfer mechanism needed |
| Vendus (Compsoft) | Tenant's end-customer invoice data | Tenant's invoicing provider | Portugal | EU — no transfer mechanism needed |
| Quipu (Quipu, S.L.) | Tenant's end-customer invoice data | Tenant's invoicing provider | Spain | EU — no transfer mechanism needed |
| TOConline (PRIMAVERA BSS) | Tenant's end-customer invoice data | Tenant's invoicing provider | Portugal | EU — no transfer mechanism needed |
| InvoiceXpress (InvoiceXpress, Lda.) | Tenant's end-customer invoice data | Tenant's invoicing provider | Portugal | EU — no transfer mechanism needed |
Not yet engaged
The following services are on the post-MVP roadmap but have NOT been engaged today. They will be added to the table above — with the legal name, jurisdiction, and transfer mechanism filled in — and tenants will be notified per § 4.2 of the DPA at least 30 days before activation.
- Hosting provider for the production Docker server (currently the platform runs on dev infrastructure only). The intended pick is an EU-based VPS provider so no transfer mechanism would be needed; the choice will be pinned before the first paying tenant onboards.
- Transactional email provider (when SMTP is wired). Used only to send password resets / billing receipts to tenant staff — not to end-customers.
- Error tracking (e.g. Sentry, if adopted). Used for stack traces and request metadata; the source-code redact path strips PII before transmission.
If you are reading this document as part of due diligence, the absence of these rows means the data flow does not exist yet in the running system.
Invoicing-provider relationship
The invoicing providers are NOT classical subprocessors in the "recipients we choose" sense — each tenant deliberately picks their provider and gives us an API key. We forward the booking-derived invoice data to whichever provider that tenant chose. The relationship is still listed here because tenants need to know the data flows out of Kapta.
For tenants who haven't chosen a provider, the data simply doesn't leave Kapta.
Notification cadence
When a row is added, removed, or materially changed, tenants are
notified by email + in-app banner at least 30 days before the change
takes effect. The change is also recorded in the "Changes log" section
of ROPA.md.
Source: docs/legal/SUBPROCESSORS.md