Request early accessEarly access

Legal

Security

Last updated:

This page explains how WCX protects stores, Buyers and payment data. It describes measures that are built into the platform today.

1. Encrypted connections

Every WCX page and API, including this website, the Seller dashboard and store pages, is served over HTTPS (TLS). Store pages also send HTTP Strict Transport Security for one year, so browsers always use HTTPS. Store pages cannot be embedded in other sites.

2. Payments and card data

  1. WCX never receives, stores or processes full card numbers, expiry dates or security codes. Buyers type their card details into payment fields provided by the payment processor (Stripe or Whop). These fields load directly from the processor's servers, and the details go straight to the processor.
  2. Under the Payment Card Industry Data Security Standard (PCI DSS), every party that processes, transmits or stores card data must comply with it. Stripe states that it is certified as a PCI Service Provider Level 1.
  3. The checkout page loads no advertising, analytics or page-measurement scripts. Besides our own checkout code, the only scripts there are the processor's (including the wallets it offers, such as Apple Pay, Google Pay or PayPal) and our bot protection, under a strict Content Security Policy with Trusted Types. One-click offer pages, where a payment sheet with the processor's fields can open if a one-click charge does not go through, never load advertising pixels. If the store's page analytics is on, it can run on those pages, but it cannot read the processor's payment fields.
  4. We keep only the card brand, last four digits and card country reported by the processor, to show the Buyer which card is being used. For one-click post-purchase offers, references to the saved payment method are encrypted and deleted when the offer window closes (24 hours at most).
  5. When a bank asks for extra verification (3-D Secure), the Buyer completes it in the processor's own interface.
  6. Checkout is protected by Cloudflare Turnstile and per-IP rate limits, with stricter limits on payment attempts. Buyers see generic decline messages, so the details cannot help anyone testing stolen cards.
  7. Payment notifications from processors are accepted only with a valid signature. The signature is checked over the raw request, within a 5-minute window, using a constant-time comparison.

3. Protecting personal data

  1. Minimization. Buyers' emails and phone numbers are stored as SHA-256 hashes plus a masked form. The readable email is kept only where it is needed to send the Buyer's emails, and it is encrypted (AES-256-GCM) until payment.
  2. Encryption at rest. The database (Neon) and file storage (Cloudflare R2) encrypt data at rest with AES-256. The application also encrypts connected-account credentials (AES-256-GCM) with a key that can be rotated.
  3. Private files. In the WCX members library, digital products are kept in private storage and delivered only to Buyers who have access, through signed links: download links expire after 5 minutes, and links to watch a video or listen to audio in the library expire after 4 hours and work only with the Buyer's library session. Every request checks access again, so a refund or chargeback ends it immediately.
  4. Logs without personal data. Emails, phone numbers, tokens, signatures and request payloads are redacted. Error reports leave out request bodies, cookies, headers and query strings.
  5. Short retention periods, described in our Privacy Policy.

4. Access control

  1. The Seller dashboard and API sit behind Cloudflare Access, and the application checks the identity token on every request.
  2. Permissions are set by role and store (owner, editor, analyst, and assistant, a drafts-only role). Each organization's data is isolated: a request for another organization's store is answered as "not found".
  3. Significant changes are recorded in an audit log. Secrets are kept in Cloudflare's secret storage, never in code. Routes that change data are protected against cross-site request forgery.

5. The Buyers' library

  1. Buyers sign in with a 6-digit code sent by email. It expires in 10 minutes, allows 5 attempts and is stored only as a keyed hash (HMAC-SHA-256). The response is the same whether or not an email has purchases, so the form cannot be used to find out who bought.
  2. The session cookie is Secure, HttpOnly, SameSite=Strict and limited to the library's host. Session tokens are stored only as hashes, and signing out revokes them.
  3. Purchased content is not stored on the device for offline use.

6. Report a vulnerability

  1. Write to with the subject "Security report". Include the affected address or feature, the steps to reproduce it, the impact, and how to contact you.
  2. Please do not access, change or delete data that is not yours. Test only with your own account or store. Do not run denial-of-service, spam, social-engineering or physical attacks. Give us reasonable time to fix the issue before you disclose it.
  3. We acknowledge reports within 2 business days, keep you informed, and credit you if you wish. We do not run a paid bug bounty. We will not take legal action against good-faith research that follows these guidelines.

Questions about this page? Write to .