Effective 2026-05-10.
Card data never touches our servers
NoShowSaver uses Stripe Connect Standard. The card is collected by Stripe's hosted Checkout flow, the authorization hold is created against Stripe's vault, and the resulting PaymentIntent ID — not the card number — is what we store. We never see, log, or transmit full PANs, CVVs, or expiration dates. Stripe is PCI DSS Level 1 certified and is the system of record for every charge.
Authorization holds, not stored payment methods
When an end client books, we ask Stripe to place a refundable authorization hold on the card for the amount of your no-show fee. The hold expires automatically per Stripe's rules (typically 7 days for card networks) if we don't capture or cancel it. We capture only when our webhook confirms the appointment was missed per your policy; we cancel automatically when the appointment is completed or rescheduled inside the grace window.
Connected-account model
Funds settle directly to your Stripe account. We are a platform on top of your Stripe Connect account, not a payment processor. Revoking our Connect access in your Stripe dashboard is sufficient to stop us from creating new charges.
Data we hold
- Booking metadata from Calendly (name, email, phone if you collect it, event time, custom-question answers).
- Stripe identifiers — Connect account ID, customer ID, PaymentIntent ID, last-four and brand for receipts.
- Your account, workspace settings, policy configuration, and SMS templates.
- Audit log of authorization, capture, refund, and dispute events.
Encryption
All traffic between your browser, end clients' browsers, and NoShowSaver runs over TLS 1.2+. The managed Postgres holding booking records and OAuth tokens is encrypted at rest by our database provider. We do not layer additional application-level encryption on top of that today; when we do, we will note it here.
Authentication and access
Owner accounts authenticate with email and password handled by our authentication provider; password hashes are never stored in our application database. Sessions are HTTP-only cookies bound to a workspace ID. Workspace data is isolated at the database layer — every query is scoped by workspace ID.
Internal access to production data is restricted to NoShowSaver engineers, requires multi-factor authentication, and is logged.
Subprocessors
The following providers receive end-client data as part of normal operation:
- Stripe — payment processing, authorization holds, dispute evidence.
- Twilio — SMS delivery for reminders and dispute messages.
- Calendly — booking source and webhook delivery.
- Vercel — application hosting (United States).
- Railway — background worker hosting (United States).
- Neon — managed Postgres (United States).
We will email account holders at least 14 days before adding a new subprocessor that handles end-client data.
Compliance posture
NoShowSaver is early-stage and we are honest about that. We are not SOC 2 audited today; we expect to begin a Type I audit once the company hits a customer count that warrants it. We are not HIPAA-covered and do not sign Business Associate Agreements. PCI scope is reduced to SAQ-A by virtue of using Stripe Connect.
Reporting a vulnerability
Email security@noshowsaver.app with a description of the issue and steps to reproduce. We acknowledge reports within two business days and will not pursue legal action against good-faith research that avoids data exfiltration, destruction, or impact on other customers. We do not currently run a paid bounty program, but we will credit reporters who want to be named.
Incident response
If we discover or are notified of a security incident affecting customer data, we will notify affected account holders by email within 72 hours of confirmation, including what we know, what we don't know yet, and what action (if any) is required of you.
General questions
Anything else: support@noshowsaver.app.