Security

1. Stripe and payments

• Customer workspaces connect with Stripe Connect OAuth only.
• Cancelbox never stores card numbers, CVC, or full PAN. Stripe is the PCI environment.
• Access tokens are encrypted server-side with an application key and never exposed to the browser.
• Webhooks are signature-verified before any processing. Event IDs are stored so the same event is never applied twice.
• Billing mutations use idempotency keys. A price change is not shown as saved until Stripe confirms it.
• Test and live environments are strictly separate rows.

2. Application controls

• Authentication through Cancelbox session cookies or Supabase Auth.
• Row-level security: users can access only workspaces they belong to.
• Cancellation session tokens are hashed before persistence. The public URL token is not stored in plaintext.
• Audit logs are append-only. They cannot be edited from the product.
• Demo mode is marked in the UI and cannot send email or call Stripe.

3. Data protection

• TLS in transit.
• Encryption of secrets at rest.
• Least-privilege service roles for server jobs.
• No card data in logs. We avoid logging tokens and webhook secrets.

Cancelbox is not claiming a completed SOC 2 or ISO 27001 audit on this page. When an independent report exists, it will be listed here. Until then, treat this page as a description of controls in the product, not a certification.

4. People and process

• Production access is limited to people who operate the service.
• Dependencies are kept current as part of normal engineering.
• Sentry receives error telemetry when configured; we aim to strip secrets.
• Personal-data incidents are handled under the DPA.

5. Report a vulnerability

Email security@cancelbox.co with steps to reproduce. Do not include live customer data. We will acknowledge reports we can validate. Please do not publicly disclose a vulnerability until we have had a reasonable chance to fix it.

Related: Compliance and the DPA.