Skip to documentation content

Security

Protect identity, credentials, tenant boundaries, invoice data, provider observations, and financial evidence.

On this page

Security boundaries

BoundaryControl and responsibility
People → CardenWorkOS AuthKit sign-in plus merchant membership and action permissions.
Merchant backend → CardenScoped Carden keys tied to one organization, integration, environment, and scope set.
QuickBooks → CardenIntuit OAuth consent for the intended accounting company.
QuickBooks → payment integrationExplicit same-context source link and invoices:read opt-in with authority over both providers.
Merchant backend → Stripe or SquareMerchant-owned provider credentials, payment controls, and idempotency.
Provider webhook → merchantMerchant verifies the provider signature before normalizing an observation.
Carden webhook → merchantMerchant verifies Carden HMAC-SHA256 over timestamp and raw body.

An organization ID is not a credential, an event source label is not provider verification, and successful sign-in is not permission to access every merchant.

Handle credentials safely

  • Keep Carden keys in server-only secret configuration with minimum scopes and separate environments.
  • Keep Stripe and Square secrets in the merchant backend; Carden provider setup never asks for payment credentials.
  • Complete QuickBooks authorization on Intuit's consent screen; never send a QuickBooks password to Carden.
  • Treat connection invitations and webhook signing secrets as sensitive.
  • Rotate and revoke deliberately and review who can create keys or change destinations.

Existing keys receive no automatic invoices:read when a source is linked. Invoice detail includes sensitive business data, source references, and approved mappings and remains limited to explicitly authorized workflows.

Browser-exposed variables, public source, analytics events, and support screenshots are not secret storage. Use redacted identifiers when investigating.

Minimize data

Preparation contains only authoritative commercial facts needed for provider context. Reports accept allowlisted IDs, amounts, states, times, and safe codes. They do not require raw provider objects.

  • Use processor-hosted card entry or an approved merchant payment flow.
  • Send no raw primary account number, security code, magnetic-stripe data, provider access token, payment client secret, or unrestricted metadata.
  • Keep sensitive raw invoice, provider, and settlement evidence in approved access-controlled systems.
  • Separate test fixtures from production records and document retention requirements.

Keep trust claims evidence-based

A report is merchant-reported evidence and a preparation response is transformation evidence. Neither establishes direct provider verification, settlement qualification, or realized savings.

These docs do not assert a SOC 2 report, ISO certification, PCI certification, specific data residency, or fixed retention or availability commitment. Request current security materials and contractual terms from Carden.

Disconnecting stops an access path and is not the same as deleting imported records or immutable audit evidence. Agree on deletion scope and legal or contractual retention.

Respond to suspected exposure

  1. Revoke the affected Carden credential or disable the compromised access path; rotate related merchant secrets as needed.
  2. Preserve safe request IDs, event IDs, timestamps, environment, and exposure description without reproducing secrets.
  3. Review key use, memberships, source links, and webhook destination changes.
  4. Contact Carden through the agreed support channel and request a secure evidence channel.
  5. Resume durable report delivery with replacement credentials and unchanged event identities.