Security model

PAID is designed so that no single secret or host can silently move a dollar. This page describes what is implemented today; the roadmap section at the bottom lists honest gaps that are documented in our internal security posture audit.

Card data

• Card numbers are tokenized at the browser via Stripe Elements before they reach any PAID server.
• PAID never stores PANs at rest. Only opaque payment-method tokens are persisted.
• Merchants using PAID-hosted checkout stay in PCI scope SAQ A — PAN never traverses your infrastructure or ours.

Ledger

• Every financial event is hash-chained: each entry includes the SHA-256 of the previous, forming an append-only chain.
• Trust Fabric certifications are appended to an internal Merkle transparency log; inclusion proofs are issued on demand.
• Reconciliation reports surface any mismatch between processor totals and the chained ledger via POST /v1/reconciliation/run.
• Ledger integrity can be re-verified end-to-end via GET /v1/audit/verify, which replays the chain from genesis and validates every hash link.

Trust Fabric

• Every tenant must clear the admission gate (KYB, sanctions screening, jurisdiction check, volume assessment) before any live key is issued.
• Admission certificates are anchored to the internal Merkle transparency log and inclusion-proven on retrieval.
• Provider health, fraud signals, and dispute outcomes feed back into the gate continuously.

Webhooks

• Outbound webhooks are HMAC-SHA256 signed with your per-endpoint secret using the Stripe-compatible format: t=<unix_timestamp>,v1=<hmac_hex>.
• Inbound provider webhooks are verified against vendor-specific schemes: JWS/ES256 (Plaid), RSA-SHA256 (ClearBank, Binance Pay), ECDSA-P256 (Circle USDC), HMAC-SHA256 (Stripe, Dwolla).
• Timestamps in every signature are enforced as a freshness window (typically ±5 minutes) to prevent replay.
• Always compare signatures using a constant-time function (e.g. crypto.timingSafeEqual).

Encryption

• In transit: TLS 1.2+ for all client and provider traffic; hosted deployments terminate TLS 1.3.
• At rest (application layer): Plaid access tokens and provider-registry secrets are encrypted AES-256-GCM with keys sourced from configured environment variables.
• At rest (infrastructure layer): database storage relies on cloud-provider disk encryption. Column-level encryption for bulk records and KMS/HSM-backed key management are roadmap items (see below).

Authentication & access

• Merchant API access uses HMAC-SHA256 bearer-token signatures with per-request timestamps. API keys are stored as SHA-256 hashes — plaintext is never persisted.
• Keys can be rotated via POST /v1/accounts/:id/rotate-key; rotation events are logged to the audit ledger.
• Tenant isolation is enforced at the middleware layer: a merchant request cannot read or mutate another merchant's resources.
• Admin access: SSO via OIDC with mandatory MFA-claim enforcement — the IdP's amr claim must attest MFA was performed, and the resulting session is bound to a client fingerprint (SHA-256 of IP + User-Agent). Production deployments refuse to boot if MFA-claim enforcement is disabled.
• Admin mutations on /v1/admin/* require an authenticated admin session with verified MFA; the static admin API key is read-only by default.
• Merchant-facing TOTP MFA enrollment is available via /v1/mfa/* endpoints.
• Per-IP rate limit (100 req/s) and per-merchant rate limit (1000 RPM with configurable burst) at the gateway.

Operational

• Full audit log surfaced in Dashboard → Audit with verifiable hash chain.
• Structured slog logging with request-ID correlation through the call stack.
• Automated dependency and container vulnerability scanning runs in CI: govulncheck (reachable Go CVEs), Trivy image scans (CRITICAL/HIGH gate), and npm audit on every push; CodeQL (Go and TypeScript) and Dependabot updates on a weekly schedule.
• No secrets are committed to the repository; .env* patterns are gitignored.

Honest roadmap items

These controls are tracked in our internal security posture audit and are not yet in production. We disclose them publicly to keep the documentation aligned with implementation:

• Mandatory MFA on merchant dashboard surfaces (enrollment is available; making it required across all merchant flows is in progress)
• Hardware-key attestation for SAML SSO (SAML 2.0 SSO and SCIM 2.0 provisioning are implemented and enabled per deployment behind feature flags; OIDC SSO with mandatory MFA-claim is already in place)
• AWS KMS or HSM-backed key management (currently environment-variable keys)
• Transparent Data Encryption (TDE) at the database layer
• Web Application Firewall
• Full permission-table RBAC (team roles and invitations are live; the fine-grained permission model beyond the admin/merchant/team-role set is in progress)
• Public anchoring of the transparency log to an external CT-style witness