Anti-quishing on the issuer side. Data residency on the storage side.
Every Pro link runs through a seven-layer anti-quishing pipeline at issue time, at every destination change, and on a rolling schedule. The scan log is country plus device-class only, with no IP, no user agent, no cookie, no behavioral profile to leak. Single-region D1 is available on Agency and Custom Enterprise.
Data we collect
Every byte that ends up on our servers is in one of four buckets:
Account data
Email, plan tier, plan status, Stripe customer + subscription IDs, optional team name + workspace label. That's it. No phone, no address (billing address stays at Stripe), no behavioral profile.
Code data
The destination URL, a 7-char Base58 shortcode, a label + tags you set, optional QR design (colors / logo / frame), optional password gate, optional schedule. Owned by you; exportable as CSV any time.
Scan data
UTC day-bucket + country (from CF-IPCountry) + device class (mobile / tablet / desktop / unknown). Raw User-Agent is discarded immediately after classification. IP never enters the database. Cached in KV for the redirect hot path, aggregated into D1 via ctx.waitUntil. Country aggregates under 5 scans fold into "Other" to defeat re-identification.
Audit / billing metadata
Append-only log of mutations (who did what, when, in what scope), 180-day retention. Stripe webhook events deduplicated for idempotency, no customer PII beyond the Stripe customer ID. GDPR request log (export / delete / restore), retained past account deletion for on-time-honor proof.
For the full schema, see docs/SCHEMA.md in our source repo; every column is documented with a retention policy.
Where the data lives
| Surface | Provider | Region | Single-region option? |
|---|---|---|---|
| Dashboard + API | Cloudflare Pages Functions | Global edge (nearest PoP) | Yes, Agency+ only |
| Code records (D1) | Cloudflare D1 (SQLite) | Primary region assigned at provisioning (today: ENAM) | Yes, Agency+ per-tenant shard |
| Redirect hot path (KV) | Cloudflare Workers KV | Edge-replicated globally for <50ms p99 | Not available (replication is the product) |
| Encrypted backups | Cloudflare R2 | Primary region assigned at bucket create | Yes, EU / APAC jurisdictional bucket on request |
| Payments | Stripe | US, regional PII handling via Stripe's own residency | Via Stripe contract |
| Transactional email | ZeptoMail (Zoho) | IN (Zoho's EU region available on request) | Yes, Zoho EU region |
What crosses a border, exactly
- Scans never cross a border in a lossy way. A scan from Lisbon hits the Lisbon Cloudflare PoP, the worker writes day/country/device into KV at the edge, and aggregates async into D1 in its primary region. The original scanner's IP lives in Cloudflare's ephemeral request state for the duration of the HTTP request and is never persisted to our database.
- Dashboard requests terminate at the nearest Cloudflare PoP and call D1 over Cloudflare's private network. Our Pages Functions read/write D1 in its assigned region; the edge PoP serves the HTML + JS bundle from the global static-asset cache.
- Stripe webhooks cross the border once, Stripe (US) POSTs to our Cloudflare Pages endpoint, which verifies the HMAC, writes a minimal (event_id, type) row for idempotency, and dispatches downstream events.
- Transactional email (Zepto) crosses the border once per send, our worker hands a rendered template to Zepto's API; Zepto delivers to the recipient's mailserver. Content is invite links, billing-lifecycle notifications, and scan-cap alerts, no customer scan data.
Anti-quishing pipeline
QR phishing rose 146% in Q1 2026. The standard short-link vendor reacts after a customer complaint. We check every link at issue time, every time the destination is changed on our side, and on a rolling schedule because a customer can repoint their own URL on their own server without ever calling our API. The same threat-intel pipeline that powers our public scanner at check.qr.abundera.ai runs against every link we issue.
Seven detection layers, each with a pending US patent application. Every layer feeds a unified verdict; a hit on any one can block a create, refuse a destination change, or suspend an already-live link.
| Layer | What it catches | When it runs |
|---|---|---|
| Redirect-chain mutability | How many independent parties control the path between our short link and the final page. A two-hop chain through someone else's redirector is a different risk class from a direct destination. | Create, destination change, rolling re-check |
| Multi-modal payload analysis | WiFi, contact, telephony, mail, calendar, geolocation, cryptocurrency, Android intent, and inline-data payloads each get a type-specific analyzer. Hard-blocked schemes refuse at submit. | Create, destination change |
| Crawler-vs-browser cloaking | Pages that serve clean content to scanners and phishing to humans. Detected by parallel fetches with controlled fingerprint variance and a divergence score. | Create, rolling re-check |
| Destination-server mutability | Freshly-registered domains, brand-new certificates, high-churn TLDs, missing HSTS, and transport-scheme degradation. Independent of the redirect chain; a static one-hop chain to a six-day-old cert on a sketchy TLD still gets flagged. | Create, destination change, rolling re-check |
| Physical-instance provenance | Crowd-sourced hash ledger keyed by decoded payload. A single QR scanned across many disparate regions in a short window surfaces as a sticker-attack candidate. Every link we issue gets a clean provenance entry at creation, so overlay attacks against legitimate Pro codes get caught. | Continuous |
| Visual-brand divergence | If a code carries a brand logo whose canonical-domain set does not include the decoded destination, the code is brand-divergent. Applies to every Pro code that uses our center-logo feature; phisher cannot ship a Chase-logoed code pointing at a non-Chase domain. | Create, logo change, destination change |
| Sensor / venue topology | For venue-bound codes (parking meters, hotel check-in, restaurant menus, museum exhibits), the scanning device's ambient RF context is checked against the registered topology for that venue. Mismatch returns a sensor-context anomaly even on the very first scan of a fraudulent sticker. Enterprise tier; venue operator registers expected topology at code creation. | Every scan |
The customer-side change problem
A Pro link's destination URL lives on the customer's server, not ours. The customer can repoint example.com/promo from a real promo to a phishing page without ever calling the Abundera API. We treat this as the primary abuse path, not an edge case. Rolling re-checks against active destinations run on a schedule, and our cloaking-detection layer specifically targets pages that flip after submit. When a destination starts failing checks after creation, the link is auto-paused, the owner is emailed with the specific verdict, and we log the event in the audit trail.
False-positives and appeals
Threat intel is wrong sometimes. A legitimate brand on a newly-issued cert, a real promo whose page legitimately changed, a moved domain. Every block and every auto-pause includes the specific verdict layer that fired, the input that triggered it, and a one-click appeal that escalates to a human within one business day. We err on the side of pausing rather than deleting; a paused link can be re-enabled in seconds once the appeal clears.
Single-region residency (Agency+ and Custom Enterprise)
For EU-only or APAC-only buyers, Agency-tier customers can request:
- D1 placed in a single jurisdiction (EU: EEUR or WEUR; APAC: APAC). Cloudflare honors a
locationhint at database creation; we spin up a per-tenant D1 shard in the requested region (ADR-0010). - R2 bucket in the same jurisdiction, nightly encrypted D1 → R2 backups land in the matching region.
- Zepto EU region for transactional email, configured at the service level, no code change.
- KV stays global, edge replication is core to the <50ms redirect guarantee. If single-region KV is a hard requirement, talk to us; we can evaluate whether a regional-only Worker variant is feasible for your campaign.
Pricing for the single-region add-on is flat rate (no per-seat markup) and depends on the specific combination. Email enterprise@abundera.ai with your target jurisdiction + projected scan volume and we'll quote.
Compliance posture
- GDPR, minimum-data-by-design (country + device-class only, no IP, no UA, no cookies) plus one-click export and 30-day hard-delete. DPA + EU SCCs available for all paying tiers.
- CCPA, covered by the same export + delete surface. "Sale of data" is not a thing we do: no third-party sharing, no ad partners, no retargeting.
- SSO + SCIM provisioning, SAML 2.0 + OIDC single sign-on and SCIM 2.0 user & group lifecycle (Agency + Custom Enterprise tiers). RFC 7643/7644 compliance verified (20/20 on the PingIdentity-derived test suite). Per-connection feature flag means SCIM is off-by-default and enabled per customer; rate-limited to 50 RPS per token; audit-logged. Okta/Entra/JumpCloud work today as custom-SCIM apps while partner-catalog listings are in progress.
- SOC 2 Type II, in scoping. 6-9 month process. If this is a hard requirement for you, email enterprise@abundera.ai; we can share current status + projected timeline.
- PCI-DSS, out of scope for us directly; payments handled end-to-end by Stripe (PCI Level 1 certified).
Security disclosure
Found a vulnerability? Email security@abundera.ai. Coordinated disclosure, we'll acknowledge within 24h (business days), triage within 72h, and coordinate a fix + disclosure timeline with you. No bug bounty program yet; we do acknowledge researchers publicly at abundera.ai/security/ once a fix ships.