Security & privacy

This foundation reduces exposure but does not replace security review, operations, or certification before handling real funds.

Boundaries

• Human accounts: HttpOnly sessions, verified email, and workspace membership.
• Integrator backend: scoped, revocable keys stored as peppered digests.
• Checkout: random, expiring capability restricted to one session.
• Frame: exact CSP origin; visual options have no financial authority.
• Personal data: AES-256-GCM before persisting prefilled and payer information.

Keep encryption keys separate from database and backups. Losing a key can make fields unrecoverable; leaking it together with the database defeats this protection.

Wallet policy

No recipient configuration or wallet-selection route exists. Unknown fields are rejected. Live policy is closed in code and remains closed even with valid credentials.

Operations

Use TLS, private variables, an unexposed database, a non-superuser application role, and encrypted backups. Review file and log access. Do not log passwords, keys, session capabilities, documents, emails, payment bodies, or complete checkout URLs.

Before launch

Define personal-data retention/deletion, incident response, administrative MFA, commercial quotas, dependency review, and external testing. Data-subject flows, legal basis, and privacy policies need review for the actual product.

Public request boundaries

The web proxy applies the same 16 KiB body limit as the API before buffering streamed input. Webhook destinations must resolve to public IP addresses; IPv6 forms are normalized before classification. Private, mapped and special-purpose ranges are rejected. The marketing preview opens only a same-origin, short-lived sandbox session, and completion messages must match the iframe window, origin and checkout ID.