Trust Center
This Trust Center is the source of truth for Reevit’s current security and compliance posture. It separates implemented controls from external assurance work and does not imply a certification or regulatory determination that Reevit does not hold. Last reviewed: 25 July 2026Assurance status
Architecture and data flow
Reevit is a payment-orchestration layer between a merchant and the payment providers the merchant selects.- The merchant authenticates to Reevit with an organization- and environment-scoped credential.
- Reevit evaluates the configured route and sends the operation to the selected PSP using the merchant’s encrypted PSP credentials.
- The PSP performs payment-method collection or authorization. Reevit stores operational identifiers, status, amount, currency, and routing evidence.
- Provider webhooks are verified before they can update payment state.
- Reevit signs outbound webhook events for the merchant to verify.
Encryption and secrets
- HTTPS/TLS 1.2 or newer is required for public API traffic; the deployed edge determines the negotiated protocol and certificate controls.
- PSP credentials are encrypted in the application using authenticated AES-256-GCM before database storage.
- Deployment key custody is documented per environment. Hardware-backed key protection is not asserted universally.
- Secret credentials are not returned by read APIs.
Access and audit
API keys are scoped by organization, mode, and permission. Sensitive actions produce audit events recording actor, action, resource, outcome, and time. Access to production infrastructure and evidence is handled through the applicable operational process and is not inferred from application roles.Data location and retention
Processing location is deployment-specific. Request the locations and transfer safeguards applicable to your account from privacy@reevit.io. The application-enforced retention matrix is published on Security. The public Privacy Policy’s legal retention language is under counsel review; the product matrix does not amend it.Subprocessors
A public, deployment-specific subprocessor register has not yet been published. Before go-live, request the current list, processing purpose, and location from privacy@reevit.io. A missing public list must not be read as “no subprocessors.”Incident reporting and history
Report suspected security vulnerabilities to security@reevit.io. Report operational incidents to support@reevit.io. The public status page is the source for published operational incidents. This page does not claim that an empty history proves no incident occurred. When reporting a vulnerability, include:- the affected endpoint or component;
- reproducible steps and expected impact;
- whether any customer data may have been accessed;
- a safe contact method.
Evidence requests
Send security questionnaires and evidence requests to security@reevit.io. Include the requesting organization, deadline, intended use, and any required confidentiality terms. Evidence is shared according to sensitivity and availability; this page does not promise an artifact that does not yet exist.Questionnaire response pack
The following answers are maintained here so procurement responses remain consistent:Open assurance work
The following work requires named owners and dates outside this repository before it can be presented as initiated or complete:- Ghana payments counsel review of Bank of Ghana classification;
- Ghana Data Protection Commission registration and obligations review;
- an independent penetration-test engagement;
- a decision on the PCI, SOC 2, or ISO 27001 assurance path.