Operations›Security posture

Security posture.

OpenSettle's security model starts with one architectural choice: funds never enter our control. Everything below — keys, signatures, rate limits, residency — protects metadata and access, not money. This page is the engineering-facing summary; the marketing-facing certifications and policies live at /security.

Non-custody by construction

Customers transfer the full amount directly to your settlement wallet — OpenSettle never sits between you and the customer on-chain. We observe the transfer with our chain-reader workers and emit a confirmed event; the platform fee is accrued off-chain and billed monthly. We have no custody of customer funds at any point. A successful breach of OpenSettle's infrastructure cannot move merchant funds — only metadata is at stake. Internal platform audits are available on request — email security@opensettle.io; the latest report covers the May 2026 review.

Signed webhooks

Every webhook carries an x-opensettle-signature header in the form t=<timestamp>,v1=<hmac> — HMAC-SHA256 over timestamp.body keyed by the endpoint signing secret. Verify it with a constant-time compare and a 5-minute timestamp tolerance — see the Webhooks page for the reference verifier. Endpoint signing secrets are rotatable with a configurable grace period.

API keys

Every key has a scope (which environment it talks to) and a permission level(what it can do). Restricted is the recommended default for any backend that doesn't need to mint new keys or rotate webhook secrets. There’s no publishable front-end key class — the hosted checkout widget is loaded by URL, not by client-side credentials.

key-model

# Prefix     Scope   Used against
sk_live_…   live    Production workspace data
sk_test_…   test    Test-mode workspace data (sandbox tokens, no real on-chain)

# Permission levels (chosen at create time, immutable after)
restricted  Full read + write on resources, cannot mint API keys
            or manage webhook endpoint secrets. Default.
full        Everything restricted can do, plus key + webhook
            endpoint management.
readonly    GET-only across all resources.

# Rotation
Each key supports an explicit rotate flow that mints a new
secret and holds the old one valid for a configurable grace
window before revoking it.

Rate limits

Public hosted pages (checkout, invoice, portal magic-link) and authenticated API routes are gated by per-IP and per-account rate limiters before application code runs. Exceeded requests get a 429 with an explicit Retry-After header. Specific quotas are not yet published — they’ll be documented once we have enough merchant traffic to set them confidently.

DDoS protection

The API runs behind Cloudflare’s global edge (TLS termination, WAF, and L3/L4 DDoS protection). Hosted checkout, portal, and invoice routes are gated by per-IP rate limiters before they touch application code. As we grow we’ll add bot-management and L7 shaping; today the operational bar is “block obvious abuse”, not “withstand a sustained nation-state attack.”

Data residency

Customer PII (email, name, billing address) is stored in PostgreSQL on our Hetzner VPS in Nuremberg, Germany (eu-central). On-chain data is public by definition and is not subject to residency. Multi-region residency (US / APAC) is on the roadmap; until then, EU (Germany) residency is the only option.

SOC 2 & compliance

SOC 2 Type I is exploratory; pursuit is gated by a post-launch commercial milestone, and the engagement letter will be published when signed. Type II would follow Type I observation by 12 months. ISO 27001 is on the same roadmap. The architecture is designed to fall outside Money Services Business scope (non-custodial, no fiat leg, no signing authority); a US-counsel opinion confirming this position is in progress and will be linked from this page once signed. Until external certifications are issued and the counsel memo is delivered, the architecture and our internal audit report are the documentation we point to.

Incident response

Pre-launch — we don’t publish formal P1/P2 SLAs yet. Security disclosure goes to security@opensettle.io (same address listed in /.well-known/security.txt). Triage acknowledgement within 72h, fix or mitigation timeline coordinated with the reporter, public disclosure coordinated as well. SLAs will be published once we have an on-call rotation backing them.

Reconciliation Security overview