Security & Privacy

What happens to your bill when you upload it.

Last reviewed April 2026 · MediBill Saver Editorial Team

The Short Version

  • Bills are processed in memory, never written to disk or database on our servers.
  • Reports are AES-256-GCM encrypted with a per-analysis key before they leave our server. The key is released only after verified payment or active subscription auth.
  • Our AI provider (Google Gemini, paid tier) is contractually prohibited from using your inputs to train models.
  • We never see or store credit card numbers — Stripe handles every payment.
  • Vulnerability reports go to security@medibillsaver.com. See /.well-known/security.txt for the full RFC 9116 disclosure record.

Encryption

In transit: TLS 1.2+ everywhere. HSTS is preload-eligible (max-age 2 years, includeSubDomains, preload). Browsers will refuse to connect over plain HTTP after the first visit.

At rest (analysis blobs): Each completed analysis is encrypted with AES-256-GCM using a unique per-analysis key derived server-side. The encrypted payload is sent to your browser; the decryption key is held separately and only released to your browser after Stripe confirms payment (one-time tier) or after subscription cookie verification (Family/Pro). We never persist the readable analysis on our servers.

At rest (subscription state): A small numeric counter (remaining bills this cycle) is stored in Upstash Redis keyed to your Stripe customer ID. The counter resets each billing cycle and clears on cancellation. Subscription cookies are HMAC-SHA-256 signed with a server-only secret — they can't be forged.

No-Storage Architecture

Your uploaded bill is read into memory, sent to Google Gemini for analysis, and discarded. The bytes never touch our disk or database. We don't store the bill content or any bill-derived hash; refund-abuse protection runs through Stripe Radar and our published refund Terms, not a server-side fingerprint.

The full report your browser displays comes from the encrypted blob plus the decryption key, both delivered fresh from the analyze endpoint. If you close the tab without saving the report, it's gone — neither we nor an attacker breaching our infrastructure can reconstruct it.

AI Processor Disclosure

We use Google Gemini 2.5 Flash (paid tier) for bill analysis. The paid tier is contractually no-train: per Google's Generative AI terms, paid-tier inputs are not used to improve, train, or fine-tune Google's models, and are retained only briefly for abuse-monitoring purposes.

We do not use Gemini's free tier (which has different terms), and we do not send bill content to any other third-party AI service.

Subprocessors

Every external service we use, what it receives, and why:

ProcessorReceivesPurpose
Google GeminiBill image / PDFAI analysis, paid tier no-train
StripeEmail, payment method (card data goes directly to Stripe, not us)Payments, subscriptions, affiliate payouts
VercelRequest metadata, IPApp hosting and edge delivery
Upstash RedisHashed IP, Stripe customer ID, numeric countersRate limiting, subscription state
Neon PostgresAffiliate emails, ref codes, conversion ledgerAffiliate program operations
ResendRecipient email, message body, attached PDFReceipts, recovery links, letter delivery, full-report PDF after payment
Cloudflare TurnstileBot-detection challengeCAPTCHA on free upload
SentryError class names, stack metadataError monitoring (no bill content captured)
Plausible & Vercel AnalyticsPage path, country (no cookies; daily-rotating hashed visitor identifiers, not stable fingerprints)Privacy-preserving traffic analytics

Bot & Abuse Protection

  • Cloudflare Turnstile on free uploads — invisible CAPTCHA that catches automated submissions without disrupting humans.
  • Per-IP rate limiting on every paid endpoint via Upstash Redis.
  • Refund-abuse posture is policy-based: 30-day refund window, one refund per customer per 90-day period, Stripe Radar fraud rules, and manual review at billing@. No bill content or bill-derived hash is retained server-side.
  • Stripe Radar rules block suspicious card and email patterns at the payment processor.

Compliance Posture

  • HIPAA: not a covered entity, business associate, or subcontractor. The patient is the data subject and consents to the processing they request. See Terms §8.
  • CCPA / CPRA: Sensitive Personal Information handled per Cal. Civ. Code §1798.140(ae).
  • Washington MHMDA: Consumer health data policy at /consumer-health-privacy. GPC signal honored on every page.
  • FTC Health Breach Notification Rule: 16 CFR Part 318 acknowledged in Privacy Policy.
  • CARL / California auto-renewal: Bus. & Prof. Code §17602 compliant — express affirmative consent captured at checkout, one-click cancel via Stripe Customer Portal.

Vulnerability Disclosure

If you find a security issue, please email security@medibillsaver.com. The full disclosure record is at /.well-known/security.txt (RFC 9116 format).

We aim to acknowledge reports as quickly as we can and to prioritize fixes for critical issues. We don't run a paid bug-bounty program at this time, but we'll credit researchers who follow responsible-disclosure practice.

Pre-launch security review

Automated security scans run on every deploy — HTTP headers, static bundle, API-endpoint behavior, robots and sitemap hygiene, common-path probing. Every legal document (Terms, Privacy, Consumer Health Privacy, Cookies, Accessibility, Methodology) was reviewed pre-launch for substantiation, editorial neutrality, and disclosure completeness. Identified findings ship as quickly as we can.

Related Pages