Security overview
SET-SEC-001 · Version 1.0 · 2026-11-09
This page states what SET's systems do today, for a security or vendor-risk reviewer. Each statement describes behaviour in the running code, and each has an automated test in SET's release gate unless marked otherwise. Where SET does not have something a reviewer usually asks for, section 9 says so.
1. What SET is, and what it never holds
Simple Easy Transactions (SET) is software. A licensed infrastructure provider holds the licences and provides the accounts, conversion, custody and payouts; SET onboards customers, instructs movements and keeps the ledger.
- SET never holds a user's wallet keys and never signs for a user. A SET Wallet is the user's own; SET adds no signer, policy or key of its own to it.
- SET's operator cannot move money out of any wallet. Money leaves a custodial wallet only on its owner's own signed-in request, or on a platform's own API key.
- SET does not store card numbers, bank passwords or identity documents. Identity verification is collected and held by the licensed provider. SET keeps the provider's identifiers and the status it reports.
2. Sign-in and API keys
| Control | How it works |
|---|---|
| Wallet sign-in | Every request's sign-in token is verified on the server (ES256 signature, issuer, audience, expiry). The wallet address is read from the signed identity token; the browser never supplies it |
| API keys | Shown once when issued. SET stores only a SHA-256 hash, so a key cannot be read back out of SET |
| Scopes | A SET API key is read-only, read and write, or carries the separate approve scope |
| Rotation | Keys are rotated or revoked by API or by the dashboard. A Direct Deposit partner key can overlap its replacement for up to 72 hours |
| Two-person payouts | A payout can be held until a second key with the approve scope approves it |
| Test and live | Test keys work only against the sandbox, live keys only against production. A credential from the other environment switches the feature off; it can never switch one on |
| Rate limits | Each key has its own request and write limits, stated on every answer in RateLimit-* headers |
| Operator console | Behind single sign-on with a named allow-list, checked again inside the application |
3. Money movement integrity
- Outcomes come only from verified provider events. A browser redirect or a status read in a page is never treated as proof that money moved. Each provider webhook's signature is verified, and the result is read again from the provider before it is recorded.
- An idempotent ledger. A state change and the receipt of the event that caused it are written in one database transaction. A repeated or replayed event changes nothing.
- States only move forward. A late or out-of-order event cannot move a payment back to an earlier state.
- Stablecoin deliveries are confirmed on chain before they are shown as delivered.
Idempotency-Keyon every write. The same key with the same request returns the first answer.- Travel Rule data on every movement. A movement missing required originator or beneficiary data is refused before it is sent.
4. Webhooks SET sends
Events are signed with a per-endpoint secret (HMAC-SHA-256) that the customer can rotate. Failed deliveries are retried with a doubling delay and can be redelivered by API. An event carries identifiers, amounts and states, never personal data. See Webhooks and events.
5. Data protection
| Data | Protection |
|---|---|
| In transit | TLS on every endpoint; HTTP is redirected to HTTPS |
| At rest | The database and its backups are encrypted by the hosting provider |
| Sensitive fields (payer details for Travel Rule, payment references) | Sealed again by the application with AES-256-GCM before they are written, with a key held as a secret outside the database. The database alone does not reveal them |
| Emails | A payee's email address is not stored or logged by Payable Email; a platform sees an opaque payee id |
| Secrets | Held in the hosting provider's secret store. Never in source code, test fixtures, logs or chat |
| Application logs | Event names, identifiers and status codes. No emails, names, bank details, identity data or raw provider payloads. The hosting provider's request logs include IP addresses |
More in Data handling.
6. Browser security
Every response carries security headers. Pages are served with a Content Security Policy that allows scripts only by a per-request nonce ('strict-dynamic', no 'unsafe-inline'). State-changing browser requests must come from SET's own origin; the server-to-server APIs refuse cross-site browser requests.
7. Infrastructure
SET runs on Cloudflare's developer platform (Workers and the D1 database), which provides the network, DDoS protection, TLS termination, encryption at rest and point-in-time database recovery. SET operates no servers of its own and has no office network with access to production data. Staging and production are separate deployments with separate databases and credentials.
8. Change control
- Every change goes through a pull request.
- A release gate (type checks, lint, build and the full automated test suite) must pass. A failing test, security check or privacy check blocks the release.
- Tests include source guards: for example, that every response path is wrapped in the security headers, and that no database column exists for personal data or raw payloads.
- Each substantive release has a written record: the commit, the test result, the limitations, the rollback path and the owner.
- Database changes are versioned migrations, and the database supports point-in-time recovery.
9. What SET does not have yet
A reviewer should know these before relying on SET:
- No SOC 2 or ISO 27001 report. SET has not been audited against either.
- No third-party penetration test. One has not been commissioned yet. The controls above are tested by SET's own automated suite.
- A small team. SET is founder-operated. Production access is limited to SET's operator account, behind single sign-on.
- No contractual uptime figure by default. See Availability and support.
Under a non-disclosure agreement SET provides its answers to a security questionnaire, the list of subprocessors, a data processing agreement, and an architecture walk-through. Write to support@simpleeasytransactions.com.