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 Stripe webhooks are verified with Stripe's HMAC-SHA256 signature, and Plaid's with JWS/ES256. Card payments through Stripe are the only payment method PAID offers today, so no other rail sends us events.
• 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 checked against the User-Agent string it was created with. 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.
• A second factor (TOTP) is required for every merchant before the dashboard; production refuses to start if the requirement is off.
• 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.
• Every change passes a release gate (build, tests and code checks) before it can be pushed. Dependency and container vulnerability scanners (govulncheck, Trivy, npm audit) run in an extended gate that is not yet required on every release. There is no hosted CI today.
• 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:

• 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

Policies

The public editions of our policies say what is in place today and what is not:

• Information security
• Access control
• Data governance
• Anti-money-laundering summary