Skip to documentation content

Set up Stripe

Create a provider-scoped Carden key and place preparation and reporting beside the merchant's existing Stripe backend.

On this page

Confirm the merchant boundary

  • Select the merchant and Carden environment used by the payment backend.
  • Use Stripe test mode with a Carden sandbox key, and Stripe live mode with a Carden production key.
  • Keep Stripe credentials and provider webhook secrets in the merchant backend.
  • Decide whether this service uses linked QuickBooks invoices, inline invoices, reporting only, or separate preparation and reporting workers.

Link QuickBooks only when needed

  1. Connect and reconcile the intended QuickBooks company in the same merchant and environment.
  2. Review invoice and item-mapping exceptions before enabling source-backed preparation.
  3. Link that source to the Stripe integration with authority over both integrations.
  4. Create or rotate a Stripe-integration key that explicitly includes invoices:read.

Linking a source never changes existing keys. Inline CanonicalInvoice preparation and reporting-only use continue without QuickBooks access.

Issue least-privilege Carden keys

ServiceRecommended scopes
Linked-invoice preparationinvoices:read + enrichment:write
Inline preparationenrichment:write
Payment report workerpayments:write
Combined server serviceOnly the union required by the implemented modes

Store the key in server-only secret configuration. Rotate by creating and deploying a replacement, confirming successful calls and old outbox delivery, then revoking the old key. A provider account ID in a request never expands the key's tenant or environment.

Validate the test path

  1. Prepare an approved synthetic or sandbox invoice through the intended linked or inline path.
  2. Persist the preparation and diagnostic request ID before executing Stripe.
  3. Execute one test payment with the merchant's Stripe idempotency key.
  4. Persist the observed outcome and deliver an immutable payment report.
  5. Exercise duplicate delivery, denied scope, validation failure, ambiguous timeout, capture, and refund paths.

SDK packages remain governed by the checked-in seven-language release catalog. Until a package is marked published, use only an approved preview artifact supplied by Carden or the versioned HTTP API. Do not guess a registry version.