Security
Understand the authentication, credential, data, and evidence boundaries of a Carden integration.
On this page
Security boundaries
| Boundary | Control / responsibility |
|---|---|
| People → Carden | WorkOS AuthKit sign-in plus merchant membership and action permissions. |
| Merchant backend → Carden | Scoped Carden API keys tied to an organization, integration, and environment. |
| QuickBooks → Carden | Intuit OAuth consent for the intended accounting company. |
| Merchant backend → Stripe | Your existing Stripe credentials and payment controls; Carden never requests them. |
| Stripe webhooks → merchant | Your backend verifies the provider event before reporting normalized facts. |
| Carden webhooks → merchant | Your backend verifies the HMAC-SHA256 signature over timestamp and raw body. |
These are distinct boundaries. An organization ID is not a credential, an event source label is not provider verification, and a successful sign-in is not permission to access every merchant.
Handle credentials safely
- Keep Carden keys in server-side secret configuration with minimal scopes and separate environments.
- Keep Stripe secret keys, restricted keys, and Stripe webhook secrets in your own backend. Carden's Stripe setup has no OAuth or credential-upload step.
- Complete QuickBooks authorization on Intuit's consent screen; do not send QuickBooks passwords to Carden.
- Treat connection invitation URLs and outbound webhook signing secrets as sensitive.
- Rotate and revoke credentials deliberately, and review who can create keys or change webhook destinations.
A browser-exposed environment variable, public source repository, analytics event, or support screenshot is not safe storage for a service secret. Use redacted identifiers when investigating an issue.
Minimize the data you send
Enrichment requests should contain the authoritative commercial invoice facts needed to prepare payment details. Payment reports accept a limited set of identifiers, amounts, statuses, times, and safe codes. They do not require a full Stripe object.
- Use processor-hosted card entry or your existing approved payment flow. Send no raw primary account number (PAN), card security code, or magnetic-stripe data to Carden.
- Exclude API secrets, payment client secrets, unrestricted metadata, and raw exception text from reports.
- Retain only necessary references for correlation; keep sensitive raw evidence in appropriately access-controlled systems.
- Separate test fixtures from production merchant records and document your own retention requirements.
Keep trust claims evidence-based
Carden's financial model depends on a traceable path from authoritative invoice data to matched payment and actual settlement costs. A reported payment is explicitly merchant-reported evidence, and an enrichment response is preparation evidence. Neither establishes settlement qualification or realized savings.
This documentation does not claim a SOC 2 report, ISO certification, PCI certification, a particular data-residency region, or a fixed retention or availability commitment. Request the applicable security materials and contractual terms from Carden for your assessment.
Disconnecting an integration stops an access path; it is not the same operation as deleting previously imported records. Agree on the scope of deletion, retained audit evidence, and any legal or contractual retention requirements.
Respond to suspected exposure
- Revoke the affected Carden credential or disable the compromised access path. Rotate related secrets in your own systems where needed.
- Preserve safe request IDs, event IDs, timestamps, affected environment, and a description of the exposure without reproducing the secret.
- Review recent key use, membership changes, and webhook destination changes.
- Contact Carden through your agreed support channel or hello@cardenpay.com to coordinate investigation; ask for a secure channel before sending sensitive evidence.
- Recover report delivery from durable storage using replacement credentials and unchanged event identities.