Ronda never sees a card number.

The short version

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, per customer and per business — a business’s live card attempts are capped across every address, and stop for a while when declines pile up — and a daily ceiling on refunds.
• A paid charge far above what the business usually takes raises an alert for a person to look at.
• 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 five times in August 2026, each pass going after what the last one missed — the money paths, authentication, the merchant dashboard, the customer-facing pages, and the developer API. Every defect found was fixed and covered by a test that was itself verified by breaking the fix and watching the test fail. Three findings were retracted when they turned out to be wrong. No live payment was ever affected. But every one of those reviews was our own, and a penetration test by people who did not write the code is a different thing again. 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 rules are thresholds — per address, per customer, per business, on declines and on unusual amounts — and the per-business ones are set by judgement, not yet tuned on real traffic. There is no machine-learned risk model.
• Rate limits are counted per API key, per IP address, per business and — on the customer-facing pages — per object, so neither a single checkout nor a whole business can be hammered from a pool of addresses. Requests that are not card attempts still have no single ceiling across all of one account’s keys and addresses.

Reporting a vulnerability