Security

Four principles guide every security decision at Bellafy:

Data minimization. We collect as little personal data as possible. Your clients' end users only provide a first name and a phone number — no address, no email, no last name, no date of birth. Less data collected means less data at risk.

Delegate what specialists do better. We never try to out-engineer Stripe on payments or Supabase on database infrastructure. We use best-in-class partners and build on top of them.

Defense in depth. No single layer is a silver bullet. We combine network-level protection, application-level controls, database-level isolation, and operational practices so that a weakness in one layer does not compromise the whole system.

Transparency over marketing. We'd rather tell you what we don't have than pretend we do. This page lists concrete controls, not abstract reassurances, and includes a section on what we haven't implemented yet.

Security starts with not collecting what you don't need. Here is the exact scope of personal data processed by Bellafy.

From clinic owners (our direct customers): name, email address, password (hashed, never stored in plain text), business billing information required for invoices, and optional login credentials for two-factor authentication. Payment cards for your Bellafy subscription are handled by Stripe — we never see or store your card number.

From end users (your clients, who register in your clinic's mini-app): first name and phone number. That is the complete list. No last name, no address, no email, no date of birth, no government identifiers. The phone number is used for account recovery and nothing else.

From payments inside the mini-app: all card data is tokenized and stored by Stripe. Bellafy never receives, stores, or transmits raw card numbers, CVV codes, or expiration dates. We only receive Stripe transaction identifiers and metadata (amount, currency, status).

From web analytics: standard technical data (IP address, browser, pages viewed) via Google Analytics, subject to your cookie consent. No personally identifiable data is used for analytics.

Bellafy is not a payment processor, and we deliberately keep it that way.

All payments — both clinic subscriptions and transactions inside your mini-app — are processed by Stripe, Inc., a PCI DSS Level 1 service provider (the highest certification level in the payment card industry). Card information is entered directly into Stripe's secure iframe elements rendered on our pages; the data never passes through Bellafy's servers.

This design means we inherit Stripe's security posture for card data, including point-to-point encryption, tokenization, 3D Secure where required, and network tokens. It also means that even in a worst-case scenario where a Bellafy server is fully compromised, no card data could be exposed from it — because it isn't there.

Your clinic's Stripe Connect account is yours. Funds flow directly from the client's card to your Stripe balance (minus Stripe's processing fees and Bellafy's 3.49% application fee). Bellafy never holds your money in custody.

Bellafy runs on a modern serverless stack hosted in the United States.

Application hosting: Vercel, Inc., with servers located in the US. Vercel provides DDoS protection, automatic TLS certificate management, and a global edge network for static assets.

Database and authentication: Supabase Inc., hosted in a US region. Supabase runs on managed PostgreSQL with encryption at rest (AES-256) and managed failover. Our production project runs on the Supabase Pro plan with Point-in-Time Recovery (PITR) enabled (see Backups below).

Transactional email: Resend, operated in the US.

Bot protection and CDN: Cloudflare, Inc., with Turnstile protecting all authentication and high-risk endpoints against automated attacks.

All traffic between your browser and Bellafy is encrypted with TLS 1.3, enforced via HSTS. We do not accept plain HTTP connections.

Dashboard authentication (clinic owners). Bellafy uses email and password as the primary login method, with passwords hashed using industry-standard algorithms (bcrypt) and never stored or logged in plain text. Password resets are performed via time-limited magic links sent through Resend — no password hints, no security questions, and no SMS-based recovery (which is vulnerable to SIM-swap attacks).

Two-factor authentication (2FA). 2FA is available today for all clinic accounts, using standard authenticator apps (Google Authenticator, Authy, 1Password, or any TOTP-compatible app). We strongly recommend enabling it. When 2FA is on, logging in requires both your password and a one-time code generated on your device.

Mini-app authentication (end users). End users of your clinic's mini-app authenticate with their phone number via a one-time verification code. No passwords are involved, which eliminates password-related attack vectors entirely.

Session management. Sessions are bound to the device that created them. From your account settings you can see every active session and revoke any of them individually. Sensitive actions (changing your email, deleting your account, modifying 2FA) require re-authentication.

Multi-tenant isolation. Every table that contains clinic-specific data is protected by PostgreSQL Row-Level Security (RLS) policies in Supabase. This is a database-level guarantee: even if an application-layer bug tried to read another clinic's data, the database itself would refuse to return it. RLS is active on every multi-tenant table, without exception.

Beyond infrastructure, we apply several controls at the application layer:

Bot and abuse protection. All sign-up and login flows are protected by Cloudflare Turnstile, a modern CAPTCHA alternative that blocks automated attacks without requiring users to solve puzzles.

Rate limiting. Sensitive endpoints — authentication, password reset, contact form, partner application — are rate-limited per IP and per identifier to prevent enumeration, credential stuffing, and abuse.

Input validation. All user input is validated server-side before reaching the database. We use typed schemas (TypeScript + runtime validation) to enforce the expected shape of every incoming request.

Content Security Policy. We set strict security headers including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and Referrer-Policy to mitigate common browser-level attacks.

Secret management. Credentials (API keys, webhook signing secrets) are stored exclusively in environment variables managed by Vercel. They are never committed to source control and are rotated when any team member loses access.

Dependency hygiene. We run automated vulnerability scanning on our dependencies and review and apply security patches promptly. We keep the dependency surface minimal — fewer libraries mean fewer attack vectors.

Bellafy relies on a small, carefully selected set of subprocessors. Every one is either the industry leader in its category or a best-in-class alternative. All of them are contractually bound to process data only on our instructions and to maintain appropriate security controls.

Stripe, Inc. (United States) — payment processing, card tokenization, and Stripe Connect. PCI DSS Level 1.

Supabase Inc. (United States) — database, authentication, and file storage on managed PostgreSQL.

Vercel Inc. (United States) — application hosting and edge delivery.

Resend (United States) — transactional email delivery.

Cloudflare, Inc. (United States) — bot protection (Turnstile) and content delivery.

Google LLC (United States) — website analytics (Google Analytics), subject to user cookie consent.

A fully up-to-date list is also available in our Privacy Policy. We will notify active merchants before adding or replacing a subprocessor that handles personal data.

How long data lives, and what happens when it's deleted:

Clinic account data (your data as a Bellafy customer) is retained while your subscription is active. Upon cancellation, data enters a 30-day read-only grace period and is then permanently deleted — except for records required by tax or accounting law, which are retained in an anonymized form for up to 7 years.

End user data (your clients' data) is controlled entirely by you as the data controller. When an end user deletes their account from the mini-app, their personal data is permanently deleted from our systems immediately — not after a grace period, not retained "just in case". The only exception is anonymized booking records, which are kept for your financial reporting but no longer reference the individual.

Payment records held by Stripe follow Stripe's own retention rules, which are primarily driven by financial regulation and fraud prevention requirements.

Logs and security events (authentication attempts, webhook deliveries, error traces) are retained for operational purposes for a limited window and then rotated out.

Our production database runs on Supabase Pro with Point-in-Time Recovery (PITR) enabled. This means:

Automated daily snapshots are taken and retained for a rolling window, providing a per-day restore point for recent history.

Point-in-Time Recovery enables restoration to any moment within the retention window, with granularity measured in minutes rather than days. This protects against accidental deletions, faulty migrations, and limited-scope data corruption.

Backups are stored in Supabase's managed infrastructure, encrypted at rest, and are isolated from the production database so that a compromise of production would not extend to the backups.

We periodically verify that backups can be restored in a controlled environment. A backup you can't restore is not a backup.

If a security incident affects data we control, we act on the following timeline:

Detection and containment as the first priority — stopping the incident before anything else.

Internal investigation to determine scope, root cause, and the specific data involved.

Notification to affected merchants without undue delay, following the requirements of applicable laws (including, where applicable, the 72-hour notification window under GDPR for merchants subject to European data protection law).

Post-incident review with concrete remediation actions to prevent recurrence, shared with affected merchants when relevant.

We log and audit sensitive operations on our infrastructure so that, in the event of an incident, we can reconstruct what happened with a high degree of confidence.

We welcome reports of security vulnerabilities from the research community. If you believe you have found a vulnerability in Bellafy, please follow the guidelines below.

How to report. Send an email to support@bellafy.app with "Security report" in the subject line. Include a clear description of the issue, the steps to reproduce it, and any proof-of-concept material you have. If you prefer encrypted communication, mention it in your first message and we will coordinate a secure channel.

What to expect. We aim to acknowledge every report within 3 business days and to provide an initial assessment within 10 business days. We will keep you updated on the progress of the fix and coordinate the timing of any public disclosure with you.

What we ask in return. Please act in good faith: do not access data that is not yours, do not disrupt our service, do not publicly disclose the issue before we have had a reasonable opportunity to fix it, and do not demand payment as a condition for reporting.

Also available. A machine-readable security contact is published at https://bellafy.app/.well-known/security.txt following RFC 9116.

We believe it's more honest to list what we haven't built than to gloss over it. As of the last updated date:

Bellafy does not currently hold formal security certifications such as SOC 2 Type II or ISO 27001. These certifications are audits of processes, not of security itself, and at our current stage pursuing them would cost more time and money than they return in assurance. We will pursue them when our customer base makes the investment proportional and the certifications become a meaningful signal to our buyers.

Bellafy is not HIPAA-compliant. The service is not designed to store Protected Health Information (PHI), and our Acceptable Use Policy prohibits using Bellafy to store data that would require HIPAA compliance.

If any of these change, this page will reflect it.

Security is a shared responsibility. There are a few things only you can do:

Use a strong, unique password for your Bellafy account and never reuse it on other services.

Enable two-factor authentication on your Bellafy account. It takes two minutes and dramatically reduces the risk of account takeover.

Keep your team disciplined about accounts. Do not share logins. If a team member leaves, revoke their sessions immediately from your account settings.

Keep your Stripe account secure. It holds your money — treat it with at least the same care as you treat your bank.

Report anything suspicious. If you see logins you do not recognize, an unexpected change in your account, or anything that feels off, contact us immediately at support@bellafy.app.

We revise this page whenever material changes occur to our security posture. The "Last updated" date at the top reflects the most recent revision.

Substantive changes (for example, adding or replacing a subprocessor, or changes to data handling practices) will also be communicated to active merchants directly, in line with our Privacy Policy.

General security questions, partnership questions, and vulnerability reports can all be sent to support@bellafy.app.

Bellafy LLC

[Registered agent address, Wyoming]

In the event of any conflict between the English version of this page and any translated version, the English version shall prevail.