Encryption

Purpose

What's encrypted, and where responsibility for that encryption actually sits.

Card details (the original sale): never touch SellVia's servers or infrastructure at all — the purchase happens entirely on the merchant's own website, outside SellVia's systems (reversed 2026-08-07, 01. Money Flow). SellVia has zero exposure to this transaction, stronger than the original hosted-checkout design.
Card details (merchant billing): the one place SellVia might touch payment card data — collecting the merchant's payment method for periodic billing (05. Payment Flow) uses Swich's checkout (updated 2026-08-23 from Paddle) — Swich is PCI-DSS v4.0.1 certified per its own materials, which supports the same "SellVia stays out of full PCI-DSS scope" claim, but this hasn't been independently verified for SellVia's specific integration pattern the way the Paddle claim was
Identity/KYC documents: not confirmed to be handled entirely within Swich's own onboarding the way Paddle's was (updated 2026-08-23) — whether Swich collects KYC at all, and keeps it off SellVia's database, is unverified pending real integration; don't assume parity with the Paddle-era claim

Data at rest: standard database encryption at rest (provided by the managed Postgres provider, per 06. Infrastructure)
Data in transit: HTTPS everywhere, enforced at the Cloudflare/Nginx layer (per 06. Infrastructure)
Secrets: API keys (Swich, Ory Kratos — updated 2026-08-23 from Paddle) never committed to source control — see Secrets Management

Updated 2026-08-23: the framing "most of the hardest encryption/compliance burden is offloaded to Paddle" no longer fully holds — Swich replaces Paddle for payments, but as a processor rather than a Merchant of Record it's unconfirmed whether it absorbs the same KYC/compliance burden. This is a real open question now, not a settled non-issue. (Clerk is separately stale here too — auth is Ory Kratos, switched 2026-08-04.)