Your family's information deserves a real security team behind it.
You're trusting SplashPad with names, emails, waivers for minors, and payment activity. We take that seriously. Below is a plain-English breakdown of exactly how we protect your data — no marketing fluff, no security-theater badges. If you want the full technical version, we publish it too.
Ten controls, one goal: keep your data yours.
These are the ten controls that most matter for a platform like ours — accounts, payments, and children’s information. Every one of them is live in production today.
When you log in, we set an httpOnly cookie the browser handles automatically. It cannot be read by any script running on the page, so even a bug elsewhere in the app cannot steal your identity.
Every coach can turn on TOTP (Google Authenticator, Authy, 1Password) or email codes with one tap. We proactively remind coaches to enable it because their account holds their families’ information.
When you pick a password we check it against HaveIBeenPwned’s database of known-leaked passwords using a privacy-preserving API. Your password never leaves our server — only a 5-character SHA-1 prefix does.
The login endpoint is rate-limited (5 attempts per minute per IP) and every account locks itself for 15 minutes after 10 failed attempts, even if the attacker rotates IP addresses.
Card capture happens inside Stripe’s hosted UI. The card number goes directly from the parent’s browser to Stripe over TLS. SplashPad never sees, transmits, or stores it.
A coach can only ever see their own families and their own payments. Every request is authorized server-side before we return data — client-side checks are for UX only, never for security.
Charges, refunds, credit grants, and admin password resets all write an immutable audit-log row. If there’s ever a dispute we can reconstruct exactly who did what and when.
HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a Content-Security-Policy that forbids inline scripts, plus SameSite=Lax cookies to block cross-site request forgery.
When a coach removes a family from their roster, we scrub the coach-scoped data but preserve paid invoices and payments in anonymized form so tax records remain accurate.
Passwords never appear in log lines. Emails only show up in audit trails for actions that intrinsically require them (like a refund). Error tracking scrubs identifying info before it leaves the server.
Payment security: we’re not the ones storing your card.
Card numbers, CVVs, and expiration dates flow directly from the parent’s browser to Stripe using their hosted Elements. SplashPad servers never see the card. That means the massive PCI compliance burden lives with Stripe, one of the largest and most-audited payment processors in the world.
Each coach connects their own Stripe account. Funds flow directly from the parent to the coach; SplashPad never holds customer money. Coaches can refund payments and issue credits with full audit trails, and Stripe verifies every card charge in real time.
Credits are stored as an immutable append-only ledger. Voiding or refunding a credit inserts a compensating entry rather than mutating history — so we can always reconstruct exactly what happened.
Every incoming Stripe webhook is cryptographically verified against the account-specific signing secret before we act on it. A forged webhook cannot cause charges, refunds, or account changes.
Found something? We want to hear about it.
If you’ve found a vulnerability in SplashPad, please email security@splashpad.pro. We commit to a response within one business day and coordinated disclosure. If you give us reasonable time to fix the issue before publishing, we’ll credit you in our release notes (with your permission).
Please do not run automated scanners against production without contacting us first, and never test against real parent or coach accounts other than your own.