Settle legal
Security Policy
How Settle protects merchant and customer data, what we ask of you, and how to report a vulnerability responsibly.
Last updated: September 12, 2026
1. Our security posture
The most important security property of Settle is what it does not do: it never takes custody of funds and never holds a private key. Payments move directly between wallets. That removes the single largest category of loss in payments infrastructure, and it means a compromise of our systems cannot move your money.
2. Controls in place
No custody, by architecture
We hold no funds and no private keys, so there is no hot wallet to drain and no treasury to compromise. The worst-case impact of a platform breach is bounded by design rather than by policy.
Database-enforced tenant isolation
Every merchant-scoped table is protected by Postgres Row Level Security. A browser session is physically unable to read another merchant's rows even if application code contained a bug.
Least-privilege key separation
The browser only ever receives a publishable key constrained by RLS. The service-role key that bypasses RLS exists solely in server-side environments and is never shipped to the client.
Authenticated inbound webhooks
Blockchain event webhooks are verified by HMAC signature before they are processed, so a forged callback cannot mark an invoice paid.
On-chain verification of every settlement
A payment is only marked settled once a transfer of the exact amount, token, and recipient is confirmed on-chain. Submitting an unrelated transaction hash settles nothing.
Signed outbound webhooks
Deliveries to merchant endpoints carry an HMAC signature so you can verify a payload genuinely came from us before acting on it.
Rate limiting on public surfaces
Public endpoints are throttled per IP and per API key, protecting both the platform and the finite unique-amount space from exhaustion.
Encryption in transit and at rest
All traffic is served over TLS. Data at rest is encrypted by our database and hosting providers.
3. What we ask of you
Treat your secret API key like a password: store it in an environment variable, never commit it, and rotate it from the dashboard if it is exposed. Verify the signature on every webhook before acting on it. Above all, check your payout address carefully — an address typo sends funds somewhere unrecoverable, and no one, including us, can reverse that.
4. Reporting a vulnerability
We welcome reports from security researchers. Email [email protected] with enough detail to reproduce the issue: the affected endpoint or page, the steps taken, and the impact you believe it has. A proof of concept helps. We aim to acknowledge reports within three business days and to keep you updated while we investigate.
5. Safe harbour
If you make a good-faith effort to comply with this policy during your research, we will not pursue or support legal action against you. To stay within scope you must: avoid privacy violations and any access to data that is not your own; avoid degradation of the service, including denial-of-service and high-volume automated scanning; not exploit an issue beyond the minimum needed to demonstrate it; not modify or destroy data; and give us reasonable time to remediate before public disclosure.
Out of scope: findings against third-party providers, social engineering of staff or users, physical attacks, and reports produced solely by an automated scanner without a demonstrated impact. Attacks against public blockchain networks themselves are also out of scope — we do not operate them.
6. Rewards
We do not currently run a paid bug bounty. We will credit researchers who report valid issues, with their permission. If that changes, this page will say so.
7. Incident notification
If a security incident affects merchant or customer personal data, we will notify affected merchants without undue delay, describing what happened, what data was involved, what we have done, and what you should do. Where a notification duty applies to us under applicable data protection law, we will meet it within the statutory deadline.