Cardvera sits between your customers and your payment stack. That position demands a security posture we're willing to publish. This page covers what we do, what's in progress, and how to reach us when you find something.
The safest data is data we never see. Every architectural decision starts from that principle.
The browser SDK never reads card fields. PANs and CVVs never touch our systems. We classify on behavior, network telemetry, and BIN prefixes only. Full card data stays between the cardholder and your gateway.
TLS 1.3 is required on every connection — browser to edge, edge to your backend, internal service to service. No TLS 1.0 or 1.1; no unencrypted channels.
Each tenant's data is isolated at the storage layer. Internal services operate on the minimum permissions needed for their function. Credentials are short-lived and rotated automatically; secrets are never embedded in code or config files.
We are currently undergoing SOC 2 Type II certification. Controls covering availability, confidentiality, and security are in scope. We will publish the report when the audit is complete.
We store behavioral signals and session metadata, not PII. Collected signals are retained only as long as operationally necessary. Verdicts are single-use; session tokens expire after each checkout flow.
We use a small, fixed list of infrastructure subprocessors. The current list is available on request. We review and re-assess subprocessors when their role changes or annually, whichever comes first.
The Cardvera SDK collects browser environment signals (runtime properties, timing, motion telemetry) and network metadata (IP, ASN, user-agent) for the purpose of producing a fraud verdict. These signals are summarized locally and transmitted to our edge over TLS. We do not collect, store, or process payment card numbers, CVV codes, full names, email addresses, or any other information that identifies a cardholder.
Collected signals are associated with a short-lived session token and a merchant tenant identifier. They are not shared between tenants, not sold to third parties, and not used for purposes other than fraud classification and model improvement within the merchant's own account context.
We process data in the United States. A Data Processing Agreement is available on request.
We welcome good-faith security research. If you've found a vulnerability in Cardvera's systems, we want to hear about it before it becomes a problem for our customers.
Email a description of the issue, steps to reproduce, and any supporting evidence to security@cardvera.io. You can also find our machine-readable policy at /.well-known/security.txt.
A clear description of the vulnerability and its potential impact; reproduction steps or a proof-of-concept; the affected URL, endpoint, or component; your contact details for follow-up.
We will acknowledge receipt within two business days, keep you informed as we investigate, and notify you when the issue is resolved. We aim to triage critical reports within five business days.
We will not pursue legal action against researchers who discover and report vulnerabilities in good faith, avoid accessing or modifying customer data, do not perform denial-of-service attacks, and report findings to us before public disclosure.
Please do not test against merchant accounts you do not own or have explicit written permission to test. Automated scanning at scale against our production edge is not permitted under this policy.
We do not currently operate a paid bug bounty program, but we publicly acknowledge responsible disclosures (with the researcher's permission) and are grateful for the effort good-faith research requires.
Contact: security@cardvera.io