EU EU jurisdiction · Built in Czech Republic

I built this because the EU CAPTCHA market has a hole.

Vladislav Rajtmajer

Vladislav Rajtmajer

Solo founder, captchaapi.eu

@VRajtmajer · github.com/rajtik76

I work in EU billing & compliance code daily.

In Q1 2026, a German customer asked me to recommend a CAPTCHA they could put on their forms without triggering GDPR consent banners or sending visitor data outside the EU. I went looking. The shortlist was thin: a couple of EU-based providers, none of them cheap, most of them with generic enterprise pricing for what is, technically, a small piece of infrastructure.

I noticed the gap. I had spent the year building Billify (my Czech B2B invoicing tool) and working through VIES, § 92a ZDPH, DUZP timing, and Schrems II implications for SaaS providers. I knew the EU compliance terrain well enough to build a CAPTCHA that fits it — not retrofitted, but designed for it from the start.

So I built captchaapi.eu.

EU

What "EU-focused" actually means here

When most providers say "GDPR-compliant," they mean a privacy policy and a checkbox. I mean three specific things — none of which are marketing claims.

1. The CAPTCHA never sends visitor data outside the EU.

All compute and storage runs in Hetzner Online GmbH's Nuremberg datacenter (Germany). I do not use any of Hetzner's US or Singapore regions. There is no replication or fail-over to non-EEA infrastructure. This is not a configuration choice that could change tomorrow; it is the entire deployment topology.

This matters because most large CAPTCHA providers are US-based. Under the CLOUD Act (18 U.S.C. § 2713), US authorities can compel a US-headquartered provider to hand over data — including data stored on EU servers — without notifying the data subject. Schrems II (CJEU C-311/18) confirmed that this is incompatible with GDPR Article 46 unless supplementary measures bridge the gap. The current bridge — the EU–U.S. Data Privacy Framework (Commission Implementing Decision 2023/1795) — is itself under legal challenge before the EU General Court (case T-553/23, Latombe v Commission). Its two predecessors, Safe Harbour and Privacy Shield, were both struck down by the CJEU on substantially similar grounds. The cheapest supplementary measure is to not be on a US provider in the first place.

2. Zero cookies — by design, not by choice.

The CAPTCHA uses a stateless proof-of-work mechanism. There are no session cookies, no fingerprinting, no localStorage writes used for tracking. The HMAC-signed captcha_attestation is verified server-side with no third-party round-trip.

Under the ePrivacy Directive (2002/58/EC, Article 5(3), as amended by 2009/136/EC), any storage or access to terminal-equipment information requires consent unless it is "strictly necessary" for the service the user requested. Most large CAPTCHA providers fail this test. They store cookies for behaviour modelling, profile re-use across sites, and ad-tech integration — none of which is "strictly necessary" for verifying that a form submission is human.

Zero cookies means the integrator does not need a consent banner for the CAPTCHA layer. That alone removes one of the most common GDPR audit findings on B2B websites.

3. EU-only sub-processors. All of them.

Hetzner (Germany) runs the infrastructure. WEDOS (Czech Republic) handles transactional email. Stripe handles B2B payments through Stripe Payments Europe Ltd. (Ireland). The full list with transfer mechanisms and DPA references is on the sub-processors page.

The unusual part: invoicing is in-house. Not a third-party SaaS. I built it myself (it is the same engine as my Billify product), running on the same Hetzner infrastructure under the same legal entity. There is no extra company in the data path with its own privacy policy.

My commitment: no second product on visitor data.

I will never collect, retain beyond technical necessity, or commercialise data about end-users gathered through the CAPTCHA layer. The business is the CAPTCHA itself — the API call, the verification, the proof-of-work. It is not behavioural profiles, fingerprints, or visitor patterns aggregated across integrators. There is no second product line built on visitor data, and there will not be one.

How EU compliance is encoded in the codebase

Most of this section is technical. If you are a procurement or compliance reviewer, the summary above is enough. If you are a developer or an audit reviewer, the details are below.

Implementation details for the EU-billing reviewer

EU compliance for a SaaS provider is not only about hosting jurisdiction — it is also about getting tax invoicing right. captchaapi.eu issues invoices through in-house tooling (the same engine as Billify). The compliance behaviours below are encoded directly in the codebase, not handled out of band.

VIES live validation.

Every EU B2B customer's VAT ID is validated against the VIES SOAP service before a reverse-charge invoice is issued. The renewal cron pre-checks VIES three days before the payment attempt and again on the day of charge — a customer whose VAT ID has been deactivated cannot end up with a falsely-marked reverse-charge invoice. Each verification (Valid / Invalid / Down) is persisted to a vies_verifications audit table with the consultation number returned by VIES.

§ 92a ZDPH proof retention.

Czech VAT law (§ 92a of the Czech VAT Act) requires the issuer of a reverse-charge invoice to retain proof that the recipient's VAT ID was valid at the time of supply. The latest VALID VIES response, no older than three days at the moment of payment, is what satisfies this. The implementation enforces the three-day window — not a manual process that might miss an edge case.

DUZP anchored to payment receipt.

The Date of Taxable Supply (DUZP) on every Czech reverse-charge invoice is the day the payment was received in the Stripe account, computed in Prague timezone. This matches the Czech tax authority's reading of § 21 ZDPH for cash-basis suppliers and avoids the timezone-drift edge cases that affect issuers using UTC.

Schrems II / DPF disclosures.

International transfer mechanisms for the two payment processors (Stripe Payments Europe Ltd. — primarily Ireland; Lemon Squeezy LLC — Merchant of Record, US) are documented with their specific Commission Implementing Decisions (DPF 2023/1795 and SCC 2021/914). The page is updated when transfer mechanisms change; it is not legal boilerplate.

End-user IP retention: hashed, ephemeral, never persisted.

The only end-user personal data the CAPTCHA layer touches is the visitor's IP address — and even that is held only as a one-way SHA-256 hash with a server-side secret salt, kept in ephemeral cache memory (Redis): up to two minutes for short-term rate limiting and up to 24 hours as a cross-sitekey abuse-reputation counter (refreshed on each failure and expiring automatically when none follow). It is never persisted to the database or long-term storage. The CAPTCHA widget sets no cookies and performs no behavioural profiling. This is documented in DPA Section 3 as a contractual commitment, not a marketing claim.

No DPO, openly.

Article 37(1) GDPR sets thresholds for mandatory DPO appointment. The current processing activities do not meet those thresholds (no public-authority status, no large-scale systematic monitoring, no large-scale special-categories processing). I review this annually as the service grows, and the disclosure is on the privacy page. It would be easier to claim a DPO exists. It is more honest to say it does not, and explain why.

If your due diligence questionnaire wants more detail on any of these, send it to info@captchaapi.eu. I write the answers myself; there is no compliance-team filter.

Why I am in a position to do this

I am not a marketing-first founder who pivoted into compliance. The opposite: I have been building EU-billing software for longer than captchaapi.eu has existed.

  • Billify is my Czech B2B invoicing tool. It is the same engine that issues captchaapi.eu's invoices. Building it gave me working knowledge of VIES, § 92a ZDPH, DUZP, ARES (the Czech business registry), and the difference between IČO (company ID) and DIČ (VAT ID) — distinctions that matter when routing B2B vs B2C tax flows correctly.
  • I work in this terrain daily. EU SaaS compliance is not a side concern; it is the primary domain of my work.
  • captchaapi.eu's design decisions reflect that. The Free tier is hard-capped on purpose ("free" means non-commercial only). The paid tiers keep serving over limit on the same baseline PoW curve as in-quota traffic so visitors are not blocked for the customer's overage — soft serve, not soft difficulty. Three billing jurisdictions are wired separately (Czech direct, EU B2B reverse charge, ROW + EU B2C via Lemon Squeezy as Merchant of Record). Each is a tax-law decision encoded in product behaviour.

The pitch is simple: I am not asking you to trust marketing copy about EU compliance. I am asking you to read the code, the legal pages, and the sub-processor list — and verify each claim against the corresponding regulation.

What you can do next