Security & data handling

How CoverPanda handles and protects your data.

A friendly overview of what we store, what we don't store, how data flows through our system, and the partners who help us run the product.

Prepared May 11, 2026 · Security & data handling overview

17 categories
Data categories tracked in our inventory
256‑bit AES
Encryption at rest
0 full PANs
Card numbers and CVCs are not stored by CoverPanda
HTTPS / TLS
All traffic between users and CoverPanda
Quick answers

The short version.

These are the questions customers usually want answered first.

What we store

Data needed to operate your workspace

CoverPanda stores account, workspace, portal, file, report, payment metadata, integration, and operational records needed to run the product.

Payment details

Sensitive payment entry stays hosted

Full card numbers, CVCs, and full payer bank account numbers are entered through our payment provider's hosted flow and are not stored by CoverPanda.

Accounting details

QuickBooks data uses authorized sync

When a customer connects QuickBooks, data moves through the QuickBooks API over HTTPS/TLS. CoverPanda stores server-side tokens, sync state, and monthly profit and loss and balance sheet reports needed for reporting.

Who has access

Access follows roles and permissions

Access is limited by authentication, organization membership, portal roles, workspace permissions, and limited CoverPanda support or engineering access.

Executive summary

A workspace for franchise teams, built on a secure managed cloud foundation.

CoverPanda is built for franchisors and their internal teams, bringing financial reporting, onboarding portals, payments, documents, tasks, and integrations into one place. Franchisees may participate through invited workflows, portals, payment requests, or shared reporting where the franchisor enables them. We use best‑in‑class managed services for specialized parts of the platform: hosting, identity, database, file storage, email, analytics, and payments.

What we store

Just what's needed to operate your workspace

  • Account & workspace data: identities, roles, units, settings
  • Contacts & portal content: invites, tasks, files, agreement status
  • Financial & bookkeeping reports: monthly profit and loss and balance sheet reports, mappings
  • Payment metadata: amounts, memos, provider IDs, last four, status
  • Merchant onboarding metadata: bank name, routing, deposit last four
  • Integration tokens (server‑side), webhooks, and sync state
  • Files, documents, AI assistant messages, generated summaries
  • Operational telemetry: logs, events, feedback, email delivery
What CoverPanda does not store

Sensitive details live with the right specialist

  • Full payment card numbers (PANs)
  • Card verification codes (CVCs)
  • Full payer bank account numbers
  • Raw bank login credentials (the bank-linking provider handles those)
  • Payment provider API secrets in application tables

API keys and webhook secrets live in environment variable stores, not in source code.

Protections

How your data is protected at each layer.

Encrypted in transit

All traffic between users and CoverPanda is served over HTTPS/TLS. No exceptions, no fallback to plaintext.

Encrypted at rest

Our managed data layer encrypts customer data at rest using 256‑bit AES. Our file storage provider documents in‑transit and at‑rest encryption for files.

Identity provider

User authentication is handled by our identity provider. The backend validates provider-issued session tokens before serving any protected data.

Role‑scoped access

Access is scoped by authentication, organization membership, portal membership, and role‑based permissions, including external portal members.

Encrypted replay creds

Where integration credentials must be replayed, they're encrypted with AES‑256‑GCM using an environment‑managed key before storage.

Verified webhooks

Webhooks from external providers are verified using provider‑specific shared secrets or signatures wherever the provider supports it.

QuickBooks account details

Customers authorize the QuickBooks connection. CoverPanda uses server-side tokens and API syncs, not emailed credentials, to retrieve monthly profit and loss and balance sheet reports.

Payments & merchant accounts

Sensitive details stay with our payment provider.

CoverPanda payments use a hosted payment-provider flow. Payers enter card or bank details directly into the provider-hosted component. We store provider IDs, payment status, and limited receipt-style display metadata, not raw account numbers or security codes.

Payments we collect

Our payment provider hosts the card and bank entry surface. We receive a tokenized session, then store status, amount, memo, provider IDs, method type, brand or bank name, expiration, and last four.

Merchant deposit details

For merchant onboarding, we may store bank display metadata returned by our payment provider, including bank name, routing number, and deposit account last four. We do not store the full deposit account number.

Hosted payment flow

Card and bank details are entered directly into our payment provider's hosted surface. CoverPanda stores payment status, provider IDs, and limited display metadata, not full card numbers, CVCs, or full payer bank account numbers.

Data flow diagrams

Where data travels, at a glance.

The standard production data flow, high‑level enough to be readable and specific enough to show the major systems and trust boundaries. Customer‑specific integrations vary by workspace, so supporting providers are grouped by purpose below.

Diagram 01 · System context

How the major boundaries connect

User browsers, the CoverPanda application, identity, payments, integrations, and operational providers, viewed from one altitude.

flowchart LR subgraph userBoundary["Customer and external user boundary"] browser["User browser<br/>Workspace users, portal members, payers"] end subgraph coverPandaBoundary["CoverPanda application boundary"] app["CoverPanda app<br/>Authenticated web application"] data["Managed data layer<br/>App data, files, reports, payment metadata"] end subgraph identityBoundary["Identity provider boundary"] identity["Identity provider<br/>Login, sessions, users, orgs"] end subgraph paymentsBoundary["Payment provider boundary"] paymentProvider["Payment provider<br/>Hosted entry, merchant onboarding"] end subgraph integrationsBoundary["Optional customer-authorized integrations"] integrations["Customer integrations<br/>Accounting, POS, bank linking, docs"] end subgraph opsBoundary["Operational providers"] ops["Operational services<br/>Email, analytics, feedback, AI"] end browser -->|"HTTPS, uploads, portal interactions"| app app -->|"application data"| data app -->|"login and session flow"| identity data -->|"membership and role checks"| identity browser -->|"provider-hosted payment entry"| paymentProvider app -->|"payment sessions, merchant onboarding"| paymentProvider paymentProvider -->|"status, provider IDs, display metadata"| data data -->|"customer-authorized sync"| integrations integrations -->|"financial, document, status records"| data app -->|"notifications, telemetry, AI workflows"| ops data -->|"selected operational data"| ops
Diagram 02 · Sensitive payment flow

Payers enter card or bank details directly into the provider

Raw card and bank details are entered directly into the provider-hosted flow. CoverPanda exchanges tokens with the provider, then stores status, provider IDs, and a small amount of display metadata.

sequenceDiagram participant Payer as Payer browser participant App as CoverPanda app participant Backend as CoverPanda backend participant Provider as Payment provider Payer->>App: Open payment request (HTTPS) App->>Backend: Validate token, portal access, org, status Backend->>Provider: Create constrained payment session Provider-->>Backend: Return session key and IDs Backend-->>App: Return session metadata for provider component App->>Provider: Load provider-hosted payment component Payer->>Provider: Enter card or bank details directly Provider-->>Backend: Webhook with status, IDs, display metadata Backend->>Backend: Store status, amount, memo, IDs, brand, last four
Diagram 03 · Merchant deposit account flow

Merchant onboarding runs through the payment provider too

Customer admins enter merchant and deposit account details into the provider‑hosted onboarding surface. We keep only display and routing metadata returned by the provider.

sequenceDiagram participant Admin as Customer admin browser participant App as CoverPanda app participant Backend as CoverPanda backend participant Provider as Payment provider Admin->>App: Start merchant onboarding App->>Backend: Request onboarding session Backend->>Provider: Create constrained onboarding session Provider-->>Backend: Return session key App->>Provider: Load provider-hosted onboarding component Admin->>Provider: Enter merchant and deposit account details Provider-->>Backend: Application status and deposit display metadata Backend->>Backend: Store merchant IDs, status, bank name, routing, last four

Primary trust boundaries

  • Browser to CoverPanda: HTTPS / TLS
  • Browser to payment provider: hosted payment and onboarding components
  • App ↔ managed backend: authenticated, scoped by identity & org
  • Backend ↔ integrations: customer‑authorized OAuth, tokens, webhooks
  • App ↔ operational providers: email, analytics, AI, parsing

Diagram notes

Not every workspace uses every integration category. This diagram groups supporting providers by function so the flow stays readable. A detailed vendor list can be shared separately when needed, and workspace-specific diagrams can remove unused integration categories.

Data inventory

Every data category, with source, purpose & retention.

This inventory summarizes the data categories CoverPanda handles. It is meant as a reference, so start with the overview and diagrams if you only need the big picture. Search by keyword or click a row to expand the details: example data, source, who it's shared with, who can access it, and how long we keep it.

17 categories
Sensitive data notes

The fine print, unhidden.

What we do store

  • Payment provider IDs and limited display metadata for operating payments
  • Merchant deposit routing number and deposit account last four when returned by the payment provider
  • OAuth access and refresh tokens (server‑side) to maintain customer‑authorized integrations
  • Encrypted integration passwords where replay is implemented

What we don't store

  • Full card numbers and card security codes
  • Full payer bank account numbers
  • Raw bank login credentials collected through the bank-linking provider
  • Payment provider API secrets in application tables

Retention

Retention varies by data type, contract, legal requirements, and enabled modules. Operational records needed for financial, payment, audit, billing, tax, dispute, or legal purposes may be retained longer than general workspace content.

Supporting provider categories

The provider categories behind the product.

We group supporting providers by function in this public overview. A private provider appendix can be shared separately when exact vendor names are needed.

D Managed data layerApplication data, reports, metadata
H Hosting & edge platformWeb delivery, logs, runtime infrastructure
ID Identity providerLogin, sessions, organizations, roles
F File storage providerUploaded documents, attachments, file metadata
P Payment providerHosted payment entry, merchant onboarding
B Subscription billing providerCoverPanda subscription billing
L Bank-linking providerCustomer-authorized account linking
E Email & notification providerInvitations, reminders, delivery status
A Analytics & feedback providersProduct telemetry, feedback, support context