PAID

Last reviewed: 2026-10-30

Access control at PAI'D

This is the public edition of our access control policy. It covers how merchants, software and the operator sign in to PAI'D, and what each of them can reach. It describes what the code does today, including the parts that are not finished.

Merchants signing in to the dashboard

  • Passwords are stored only as bcrypt hashes (cost 12). We never store or log the password itself.
  • Failed sign-ins lock the account after five wrong attempts. The first lock lasts 15 minutes, and repeat locks grow up to 24 hours.
  • A second factor is required. Every merchant sets up an authenticator app (TOTP) before reaching the dashboard. In production the service refuses to start if this requirement is switched off. Recovery codes are stored only as hashes.
  • Passkeys (WebAuthn) are available as an option.

Sessions

A signed-in session is a random identifier held on our server, not a self-contained token. Each session:

  • ends after 8 hours, or after 30 minutes without activity, whichever comes first;
  • lives in a cookie that page scripts cannot read, sent only over HTTPS;
  • needs a separate anti-forgery token on every request that changes something;
  • is checked against the browser identification (user agent) sent when it was created. If they don't match, the session is deleted and the person must sign in again.

API keys

Software talks to PAI'D with API keys.

  • A key is 32 random bytes. It is shown once, when it is created. We store only its SHA-256 hash, so we cannot show it again or recover it.
  • Merchants can create restricted keys limited to a set of scopes, with an expiry date, and can revoke any key. A restricted key can reach only the routes its scopes allow; any route without a scope mapping is refused.
  • Older full-access keys still work and can reach everything on the merchant's own account. We recommend restricted keys for new integrations.
  • Every API request is tied to the merchant account that owns the key or session, and requests are rate-limited per account and per address.

Operator access

PAI'D has one operator today.

  • Any change made through the operator tools needs a signed-in operator session that has passed a second factor.
  • A shared operator key exists for read-only checks and automation. In production it cannot change anything: the service refuses to start if that key is allowed to make changes.
  • Operator sign-in can go through a single sign-on provider. When it does, production requires the provider to confirm that a phishing-resistant second factor was used.

What is recorded

Sign-ins and changes to keys and payments are written to our append-only, hash-chained audit log (see the Information Security summary). Each part of the service records its own events. There is no single layer that records every operator action, and actions taken with the shared read-only key are not tied to a named person.

Not in place yet

  • No separate operator roles. The code defines roles such as finance and support, but no route checks them yet, so every operator has full operator access. With one operator this changes nothing today. It must change before a second person is added.
  • No network restriction on operator access, such as an address allowlist or client certificates.
  • No scheduled access reviews. With one operator there is no one else to review.
  • No separation of duties. One person can both make a change and approve it.

Questions about access, or a report of a suspected problem: security@trustfabric.ai