Security and PCI posture

The short version

Ronda never sees a card number. Cards are entered on your bank's hosted page, and what comes back to us is a token that only works against your own merchant account. That single architectural choice is what places Ronda in PCI DSS SAQ-A, the lightest self-assessment tier, and it is enforced by design rather than by policy: there is no field anywhere in the system that could hold a card number.

Where money can and cannot move

• Funds settle from your acquiring bank into your own account. Ronda is never in the flow of funds.
• Every charge carries an idempotency key with a unique database constraint, so a retry cannot double-charge.
• The payment intent is recorded before the bank is called, never after.
• Every money movement is written to an append-only ledger; updates and deletes are blocked at the database.
• The charging worker runs as a single process and claims work under a row lock, so two workers cannot bill the same period.

Credentials and keys

• Bank vPOS credentials are encrypted at rest with AES-256-GCM and are never displayed after saving.
• Secret API keys are stored only as a SHA-256 hash and shown exactly once.
• Publishable keys can only open a checkout session — they cannot read or charge anything.
• Keys are scoped, rotatable, revocable, and can be restricted to an IP allowlist.
• Secrets are stripped from logs by a redaction pass, not by convention.

Account security

• Email verification, breach-checked passwords, login rate limiting and account lockout.
• TOTP two-factor authentication with single-use backup codes; mandatory for Ronda staff admin access.
• Session list and per-session revocation; an email on sign-in from a new device.
• Owner, admin and viewer roles, enforced on the server for every mutation.

Integration security

• Webhook payloads are signed with a timestamped HMAC, so a captured delivery cannot be replayed later.
• Merchant-supplied webhook URLs are validated and re-resolved before each delivery; private, loopback and cloud-metadata addresses are refused.
• Card-testing velocity limits per IP and per customer, and a daily ceiling on refunds.
• The hosted checkout, payment links, the customer portal and hosted invoices run a per-request nonce Content-Security-Policy with no inline script permitted at all, and no third-party script of any kind.
• Where a checkout returns a customer to a page the business chose, that page’s address is named on the button before they click it.

What is not done yet

• No independent penetration test has been performed. Ronda has been reviewed twice, in August 2026: once by the process that wrote the code, and once by a separate review that went looking for what the first one missed. The second found six further defects in how money is counted — including one that let a repeated checkout submission record a payment more than once — and all six were fixed and covered by tests. No live payment was affected. But both reviews were automated, and a penetration test by people who did not write the code is a different thing again, and it has not happened.
• No SOC 2 or ISO 27001 certification. Ronda is early.
• No WAF or DDoS mitigation beyond what the hosting providers offer by default.
• Fraud scoring is limited to velocity and amount thresholds; there is no machine-learned risk model.
• Rate limits are counted per API key and per IP address. There is no ceiling that follows an account across many addresses, so a determined attacker with a large pool of them still gets a bucket per address.

Reporting a vulnerability

Email security@ronda.sh. Please give us a reasonable window to fix an issue before disclosing it. We will confirm receipt within two business days.