Security
This page describes controls that are implemented in the Reevit product. It does not claim a certification or regulatory approval. See the Trust Center for assurance status, evidence requests, incident reporting, subprocessors, and open compliance work.Status vocabulary
We use four labels so implementation facts are not mistaken for certifications:- Validated in product — enforced by application code and automated tests.
- Deployment-specific — depends on the environment in which Reevit is operated.
- Inherited — provided by an identified infrastructure vendor and confirmed for a particular deployment.
- Merchant responsibility — controlled by the merchant’s integration or PSP.
Transport security
Status: validated in product, with deployment-specific edge configuration. Public API examples use HTTPS. Reevit clients must connect over TLS 1.2 or newer; the negotiated TLS version and cipher suite depend on the deployed edge and client. Do not send API keys, PSP credentials, or payment data over unencrypted connections.Credential protection
Status: validated in product. PSP credentials are encrypted by the application using authenticated AES-256-GCM encryption before database storage. Credentials are decrypted only for the operation that needs them and are not returned by read APIs. The application supports externally managed encryption keys. The storage and hardware protection of the active key are deployment-specific; Reevit does not describe every deployment as HSM-backed without evidence for that deployment.Payment data scope
Status: merchant responsibility, with validated product boundaries. Reevit does not require merchants to send raw card numbers to the Reevit API. Card collection and cardholder-data handling are performed by the selected PSP or a hosted checkout surface. PSP-issued references may not be portable between providers. Using a hosted flow can reduce a merchant’s PCI scope, but eligibility for a particular Self-Assessment Questionnaire is determined by the merchant’s full integration. Reevit does not make that determination for you.Authentication and authorization
Status: validated in product.- API keys are scoped to an organization and environment.
- Permission scopes separate read and write access for resources such as payments, connections, webhooks, and payouts.
- User passwords are hashed with Argon2id.
- Sensitive dashboard and API actions create audit events.
- Test and live modes are isolated in authenticated data access.
Webhook security
Status: validated in product for supported providers; merchant responsibility for Reevit outbound webhooks. Inbound PSP webhooks are verified using the provider-specific mechanism before they can change payment state. Reevit outbound webhooks are signed; merchants must verify the signature against the raw request body, reject stale or invalid signatures, and make handlers idempotent. See Webhooks for the current signature format and examples.HTTP safeguards
Status: validated in product, with deployment-specific edge controls. The API applies security headers and rate limits. Authenticated API limits are organization-wide rather than plan-tiered; authentication endpoints use tighter endpoint-specific protection. Edge firewalls, denial-of-service protection, and certificate management are deployment-specific controls.Audit logging
Status: validated in product. Audit events record the actor, action, affected resource, outcome, and time for sensitive operations. Audit records are not removed by the plan-retention job that removes payments and webhook records from the live database.Retention implemented by the product
Status: validated in product. The table below describes application behavior. It is not a statutory-retention opinion and does not amend the Privacy Policy.Data location
Status: deployment-specific. Reevit does not publish a universal default processing region or a list of optional regions without deployment evidence. Ask privacy@reevit.io for the processing locations and transfer safeguards applicable to your account.Your integration responsibilities
- Keep secret keys in server-side secret storage.
- Use a unique idempotency key for every create or money-moving request.
- Verify signed webhooks before fulfilling an order.
- Treat browser redirects as user experience signals, not payment proof.
- Restrict API-key scopes and rotate keys after suspected exposure.
- Determine your own PCI, privacy, tax, and regulatory obligations.