Security
What we do, and what we do not claim.
Chekvo sits next to your money, so this page states the controls plainly and marks the things that are designed but not yet built rather than implying they exist.
Card data never touches our servers
| Risk | Control | Status |
|---|---|---|
| Cross-tenant data access | Every tenant query is built through a context that requires a workspace; integration tests assert that a valid ID from another workspace returns nothing. | Built |
| Credentials at rest | AES-256-GCM envelope encryption. Never logged, never returned by any API, redacted before they can reach the audit log. | Built |
| Password attacks | scrypt (N=16384) with per-user salts, per-account lockout with backoff, and identical responses whether or not an account exists. | Built |
| Session theft | Random token in an httpOnly, SameSite cookie; only its SHA-256 hash is stored, so a database leak yields no usable sessions. Revocation is immediate. | Built |
| Double-charging | Idempotency keys on every money-moving call, with a unique constraint on the ledger enforced by the database rather than by care. | Built |
| Price tampering | Every amount is recomputed server-side from the store catalogue. Prices submitted by the browser are ignored entirely. | Built |
| Webhook forgery and replay | Constant-time signature comparison plus a timestamp tolerance window; replays inside the window are defeated by the unique ledger key. | Built |
| Card skimming on the checkout page | No raw merchant HTML on the payment origin. Rich content uses a constrained schema; the escape hatch is a sandboxed iframe with no scripts and no same-origin access. | Built |
| Ledger tampering | Append-only at the database level: UPDATE and DELETE on ledger and audit entries are blocked by trigger. Corrections are new entries. | Built |
| Insider and partner risk | Five least-privilege roles and an immutable audit log recording actor, IP and before/after on every privileged change. | Built |
| Silent loss of a captured payment | Capture, ledger entry and store-sync job share one transaction; failures escalate to a human-visible reconciliation queue and a daily invariant sweep. | Built |
| Account takeover via a second factor | Two-factor authentication. | Designed |
| Server-side request forgery | Allow-list validation and private-range blocking on merchant-supplied URLs. | Designed |
| Formal assurance | Independent penetration test and SOC 2 Type II. | Not started |
What we are not
Chekvo is not a payment processor and does not hold your customers’ funds. Money moves from the shopper to your own connected Whop account, under Whop’s terms and on your own payout schedule. We cannot change your payout destination, and we cannot move your money anywhere except back to your customers as a refund. That is a deliberate architectural choice: the checkout layer should never become a new place for your money to sit.
Reporting a vulnerability
Email security@chekvo.com with details and, if you have one, a proof of concept. We acknowledge within one business day and will not pursue legal action against good-faith research that avoids privacy violations, data destruction and service degradation.