Logs
Trace requests and payment reports without confusing observed activity with financial evidence.
On this page
Keep a correlation record
Use identifiers to follow the chain from source invoice to enrichment to payment attempt to report. Keep this relationship in your own backend as well as reviewing the activity exposed by Carden. Timestamps alone are not reliable identifiers.
| Identifier | What it identifies |
|---|---|
x-carden-request-id | One Carden HTTP request, including an error response. |
enrichmentRequestId | The earlier enrichment request associated with a report, when known. |
attemptId | Your stable identifier for one actual payment attempt, shared by its later status reports. |
eventId | One immutable observation being delivered to Carden; reused only for retries of that observation. |
paymentIntentId / chargeId | Stripe objects associated with the attempt. |
providerEventId | The Stripe event your merchant backend processed, if applicable. |
| Invoice reference and source version | The authoritative invoice state used for the payment data. |
Investigate in order
- Choose the correct merchant and environment in Logs or integration activity.
- Locate the request, attempt, or event using the identifiers your backend recorded.
- Identify the failing stage: invoice import, matching, transformation, payment execution, report delivery, or later reconciliation.
- Compare Carden's response with the corresponding source invoice or verified Stripe state in your backend.
- Record the correction and retry only the operation that failed.
A duplicate report response indicates an event was already accepted. A missing report can mean wrong environment, failed delivery, or a filter mismatch; it does not by itself mean no payment occurred.
Log only what you need
- Keep request IDs, event IDs, attempt IDs, HTTP status, safe error codes, and timestamps with timezone.
- Redact Authorization headers, API keys, OAuth tokens, webhook secrets, connection URLs, and customer-sensitive payload fields.
- Use access-controlled storage for raw invoice or provider evidence when your reconciliation policy requires it.
- Limit access to exports and logs containing merchant or customer information; review your retention requirements.
Prepare a useful support request
Send the affected merchant and environment, endpoint or operation, safe error message, request ID, event or sync-run ID, and a short description of the expected result. Give a timezone-aware time range. Share redacted examples through an agreed support channel rather than exposing secrets in email.
If the issue follows an outage, include your oldest undelivered report time and whether payment execution continued. That helps distinguish a reporting backlog from a payment-processing incident.