Request logs and events in the dashboard

When an integration misbehaves, the merchant panel shows what actually happened, without access to your servers. All of it is under Developers.

Logs (request logs)

Developers → Logs lists your own /v1 API requests, newest first: time, method and path, HTTP status, the API key or user that made the call, latency, and the object it read or changed.

Open a request to see the details: the request and response bodies, the error (type, code, decline_code, param), the Idempotency-Key and whether the response was replayed, your API version, source IP and user agent, and any warnings (a rule that is only warned about in sandbox, for example ip_not_allowed or a missing return URL registration).

• Find a request by the Request-Id (req_…) from the response header or the request_id in an error, by object id (for example pi_…), by status (402, 4xx, failed), method, path prefix, API key or time range.
• Bodies are redacted. Card numbers are cut to the first 6 and last 4 digits, CVC and expiry are removed, secrets, passwords, tokens and authorization data are replaced, and IBANs are masked. Customer contact data is masked. Bodies longer than 32 KB are truncated and marked so.
• Only requests that authenticated as your account are logged. A request with a bad key cannot be attributed to you and is not stored.
• Logs are kept for a limited time (30 days by default).

The same data is available through GET /v1/request_logs and GET /v1/request_logs/{id} with a secret key, or a restricted key that has the request_logs:read scope.

curl -G https://pay.example.com/v1/request_logs \
  -H "Authorization: Bearer sk_sandbox_YOUR_KEY" \
  --data-urlencode "status=402" \
  --data-urlencode "path=/v1/payment_intents" \
  --data-urlencode "limit=20"

Events and webhook deliveries

Developers → Events lists every event your account produced (payment_intent.succeeded, refund.failed, …) with its payload and, for each of your webhook endpoints, the deliveries: every attempt with the HTTP status, latency and a masked excerpt of your response. A delivery counter per event shows at a glance whether an event reached you.

From an event you can resend it to your endpoint again, for example after fixing a bug in your handler. Developers → Webhooks shows each endpoint with its success rate over the last 24 hours and 7 days, its status (enabled, disabled or failing) and the signing secret roll action. The webhooks guide describes retries and how to re-enable a failing endpoint.

Also under Developers

• API keys: create, restrict and revoke keys; see when each was last used.
• Settings → Allowed IP addresses and Settings → Websites & callbacks: the registrations described in the authentication guide. Their warnings and refusals appear in the logs.

Who can see what

Logs and events need the developers.view permission (owner, admin and developer roles) in the panel. Keep production request logs behind those roles: even redacted, they describe your customers' payments.

A debugging routine

1. Take the request_id from the error you received (or from your own logs).
2. Open it in Logs and compare the request body with what you meant to send.
3. Check warnings: a rule that is only a warning in sandbox will be a refusal in live.
4. For missing notifications, open the event in Events and read its delivery attempts.
5. Still stuck? Send the request_id to support; they can find the same entry.