Security

This page describes how TipPage is engineered and operated from a security standpoint. It is written for transparency, in plain English. It is not a compliance certification, and it deliberately leaves out details that would only be useful to an attacker.

If anything here is unclear, or you believe something is wrong, we want to hear about it - see Reporting a vulnerability below.

Card numbers never touch TipPage's servers. Card payments are collected and processed by Stripe, a certified PCI-DSS Level 1 payment processor; the card form on a tip page is delivered by Stripe, and the card details travel directly from the tipper's browser to Stripe.

Because charges are made by TipPage rather than by the individual streamer, streamers never see a tipper's card details, billing address, or email - and tippers see TIPPAGE.COM LTDon their statement rather than the streamer's legal name. PayPal tips are the exception: they move directly between the tipper's and the streamer's PayPal accounts under PayPal's own receipts and rules.

TipPage never holds streamer funds. Money settles into the streamer's own Stripe or PayPal account.

The credentials TipPage holds on your behalf - the OAuth tokens for your connected Twitch account and payment account - are encrypted at rest with AES-256-GCM envelope encryption, with keys managed per streamer. A database copy on its own is not enough to read them.

Developer API keys are never stored at all: we keep only a one-way hash of the key, and the full key is shown once, at the moment it is created. A key can be rotated or revoked from the dashboard at any time. Webhook signing secrets are stored encrypted per streamer.

The ban engine exists to stop a banned person from paying their way back onto your stream. The signals it compares are put through one-way hashes, scoped per streamer, before they are stored. What we keep can answer one question - is this the same person this streamer banned - and cannot be read back into a name, an email address, or a card number.

Because the hashes are scoped per streamer, a ban on one tip page cannot be used to identify or track the same person on another streamer's page. Platform-wide fraud screening operates separately, on payment-fraud signals provided by the payment processor.

TipPage's cluster accepts no inbound connections and has no public origin address. Traffic reaches it only through an encrypted tunnel that the cluster itself opens outward to a global edge network. There is no port to scan and no origin IP to find: from the internet's point of view, the infrastructure only ever dials out.

The edge network terminates TLS close to the visitor, absorbs denial-of-service traffic, and forwards clean requests down the tunnel, where a gateway inside the cluster routes them per hostname to the right service. All traffic between your browser, tip pages, overlays and our services is encrypted in transit; internal traffic between services never leaves the cluster's private network.

TipPage runs as a fleet of independent services on our own Kubernetes cluster - the tip pages, the payment pipeline, the queues, the chat bot, and the realtime tier that feeds overlays are separate deployments. A fault or a traffic spike in one cannot cascade into the others, and each is scaled on its own.

Services run as multiple stateless replicas from immutable images: any replica can serve any request, shared state lives in the data layer, and if a machine fails, its workload is rescheduled and traffic re-routes automatically. Deploys are rolling and zero-downtime - new code is health-checked before it receives traffic, and overlays hold their realtime connection straight through a release.

Each service carries only its own credentials, and secrets live in the cluster's secret store, never in code or images.

Card tips are authorised before they are captured. The screening window sits between the two: a tip from a banned or suspicious payer is blocked while the money is still a hold, so the payment is simply released rather than refunded, and the tipper's money never actually moves.

Fraud screening runs platform-wide, so a card burned on one streamer is blocked for all of them. On top of that sit the per-streamer defences described elsewhere on this page and the site: the ban engine, the AI word filter that reads every message before it can play on stream, chat moderation, and rate limiting on every public endpoint.

Signing in to TipPage is done through Twitch - we never see or store a password. Sessions are kept in HttpOnly, Secure cookies that JavaScript on the page cannot read.

Team access is permission-scoped: a team member sees only the areas of the dashboard you have granted them, and access can be revoked with one click. Invite links work exactly once and expire after 7 days if unused. Developer API keys are scoped the same way - a key granted read access to the queue cannot touch anything else.

Webhooks that TipPage sends to a developer's endpoint are signed with HMAC-SHA256 and carry a timestamp, so the receiver can verify that a delivery genuinely came from TipPage and is not a replay of an old one.

Endpoint URLs are validated before delivery so webhooks cannot be aimed at internal or private network addresses, and in production they are delivered over HTTPS only.

If you believe you have found a security issue in TipPage, email hello@tippage.com. Include what you found, where, and the steps to reproduce it; a proof of concept helps but is not required. We read these promptly, we'll keep you updated while we investigate and fix, and we're happy to credit you for the find if you'd like.

We will not pursue action against research done in good faith within these rules:

• Test only against your own accounts, pages and data.
• Do not access, modify or disrupt other people's accounts, tips, streams or overlays.
• No denial-of-service testing, no spam, and no social engineering of streamers, tippers or TipPage staff.
• If you stumble into someone else's data, stop, don't keep a copy, and tell us what happened.

Give us a reasonable window to fix an issue before sharing it publicly, and we'll work with you on timing.