Three architectural choices that define our security posture
Funds never touch Quarvo's accounts
We run as a Stripe Connect platform. Every payment intent is created on the merchant's own Stripe account. Quarvo's fee is collected via application_fee_amount, deducted from the merchant's settlement — we never act as an intermediary holding customer funds. This is a deliberate choice that keeps us out of the money-transmission compliance category and reduces every operational risk that comes with custodying money.
We never see, store, or process raw card numbers
Card data is captured by Stripe Elements (PCI-DSS Level 1 compliant) directly in the customer's browser, tokenized to a pm_xxx token, and only the token ever touches Quarvo infrastructure. The raw PAN, CVV, and full expiry are out of scope for our environment. Stripe carries the PCI burden; we benefit from inheriting their controls without inheriting their attack surface.
Customers never see partial charges
The two-phase commit pattern guarantees that all N card authorizations either complete together or none commit. If any auth fails or times out in Phase 1, every successful auth is voided before the customer sees the error. The customer's available credit on each card is restored within minutes. This is a security property as much as a UX one — partial-state failures are how trust is broken.
How data actually flows
The simplest way to understand our security model is to see what data goes where. Card data never touches Quarvo. Personal data is minimal. Merchant funds always settle through the merchant's own infrastructure.
pm_xxx), transaction amounts, session IDs, merchant account IDs.
What Quarvo never stores: card numbers, CVVs, customer SSN, customer addresses (those stay with Stripe and the merchant).
What we collect from merchants
- Account identifiers — Stripe Connect account ID, merchant business name, contact email.
- Configuration — webhook URLs, supported card networks, integration mode (Shopify / Woo / API).
- Aggregate metrics — recovery rate, GMV recovered, decline counts. Used for billing and dashboard reporting.
What we collect from customers
- Tokenized card references — Stripe-issued
pm_xxxtokens. No raw PAN, ever. - Session metadata — transaction amount, allocation per card, success/failure outcome.
- Browser context (minimal) — IP address (for fraud screening), user-agent. No tracking pixels, no third-party advertising IDs.
Encryption
In transit
All Quarvo APIs require TLS 1.2 or higher. Internal service-to-service communication uses mutual TLS (mTLS) where possible, plain TLS otherwise. Customer-facing endpoints enforce HSTS with a 12-month max-age and the preload directive.
At rest
Database storage uses AES-256-GCM. Encryption keys are managed in a hardware security module (HSM) rotated quarterly. Sensitive fields (merchant API keys, webhook signing secrets) are wrapped with envelope encryption — even a database breach exposes only ciphertext.
Backups
Encrypted at rest with separate key material from the primary database. Backup access requires multi-party authorization (no single engineer can decrypt). Retention: 30 days hot, 90 days cold.
Compliance roadmap
We're transparent about where we are on each compliance track. Some are in place, some are in progress, and some are planned for once the platform reaches the volume tier where they're required.
Subprocessors
The full list of vendors that may process Quarvo customer or merchant data. We notify customers 30 days in advance of any addition. Last reviewed: May 2026.
Incident response
If we detect a security incident affecting customer or merchant data, we follow a documented response plan:
- Hour 0–1 — Containment. Affected systems are isolated; on-call engineer paged; incident commander assigned.
- Hour 1–4 — Triage. Scope of impact determined; preserved evidence collected; preliminary root cause identified.
- Hour 4–24 — Customer notification. Affected merchants notified by email and in-dashboard banner. Initial public statement on status page if widely material.
- Days 1–7 — Remediation. Root cause fixed in production; controls added to prevent recurrence; post-mortem published internally.
- Days 7–14 — Public post-mortem. For incidents affecting more than 5 merchants or any customer card data, we publish a detailed post-mortem on the changelog.
Regulatory notification (GDPR Article 33: 72 hours; state-level breach laws: varies) is handled in parallel with customer notification.
Vulnerability disclosure
If you find a vulnerability, please tell us.
We operate a coordinated vulnerability disclosure (CVD) program. Researchers who report security issues responsibly will receive prompt acknowledgment, regular updates on remediation progress, and (where applicable) public credit in our changelog.
Out of scope: social engineering, physical attacks, third-party services not operated by Quarvo, denial-of-service attacks against production.
Safe harbor: We will not pursue legal action against researchers acting in good faith and within the program's rules.