Security
Designed with security-first infrastructure
Veyqo holds the keys to other companies' money movement. This page describes what we actually do about that — not what we would like you to assume.
What we do not claim
Veyqo does not currently hold PCI DSS, SOC 2 or ISO 27001 certification, and is not a licensed financial institution. We will not display a badge we have not earned. When a certification is obtained, it will appear here with its scope and issue date.
In the meantime, Veyqo does not hold merchant funds: money moves through your own provider account and settles to you.
Practices
What is actually implemented
Each of these is covered by a test that fails the build if it stops being true.
Provider credentials
- Encrypted at rest with a key held outside the database.
- Stored behind a vault interface that can move to AWS KMS, Google Cloud KMS, Azure Key Vault or HashiCorp Vault without changing any provider integration.
- Never returned by any API endpoint, in any response, to any role.
- Displayed only as a prefix and last four characters, built from non-secret metadata rather than by decrypting.
- Every decryption is recorded in the audit log with actor and purpose.
API keys
- Stored as SHA-256 hashes. The plaintext is shown once at creation and is unrecoverable afterwards.
- Looked up by an indexed non-secret prefix, then compared in constant time.
- Bound to exactly one project and one environment; they cannot be used across either boundary.
- Scoped per capability, revocable instantly, with last-used tracking.
Webhooks
- Inbound provider signatures are verified against the raw request body, before any parsing, using that provider’s own documented scheme.
- Failed verifications are rejected and retained, so attempted forgeries and stale secrets are visible rather than silent.
- Duplicate provider events are caught by a database constraint, so processing stays idempotent even under concurrent workers.
- Outbound deliveries are signed with HMAC-SHA256 over a timestamped payload, so you can reject replays.
- Endpoint URLs must be public and HTTPS, and are re-checked at delivery time to defeat DNS rebinding.
Access and isolation
- Every tenant-scoped record carries its organization, and isolation is enforced by the data layer rather than by each query remembering.
- Sandbox and live are separated in five independent places, including the key prefix and the credential format check.
- Roles are enforced server-side. The interface hides what a role cannot do; the API refuses it regardless.
- Security-relevant actions are written to an append-only audit log with actor, IP, user agent and timestamp.
Card data
- Veyqo never collects, transmits or stores a card number, CVV or expiry date.
- Card entry happens on provider-hosted checkout or a provider’s own client SDK.
- This is why payment creation returns a checkout URL rather than accepting card fields — it keeps PCI scope minimal by construction.
Logging
- Redaction is applied at the logging sink itself, not at each call site, so a careless log statement still cannot leak a secret.
- Passwords, API secrets, authorization headers, provider credentials and signing secrets are never written to a log.
- Every request carries a correlation id that follows it into background jobs and audit records.
Reporting a vulnerability
If you believe you have found a security issue, email security@veyqo.org. Please include enough detail to reproduce it. We will acknowledge within two business days and will not pursue legal action against good-faith research that avoids privacy violations, data destruction and service disruption.