Log enough to explain what happened: a request ID, the object ID, the outcome class, the idempotency key, the duration and the vendor's error code. Do not log API keys, tokens, signing secrets, card data or full message bodies. Review logs regularly, because sensitive data tends to sneak in through debug statements.
Why log at all
A payment provider's go-live checklist points out that the vendor logs requests made with your keys, but recommends logging important data on your side as well. Your logs are the backup if your server cannot reach the vendor or if there is a problem with your keys, since both prevent the vendor from logging your request. It also says to examine logs regularly to make sure they hold only what you need and nothing sensitive, such as card details or personally identifiable information.
What the logging guidance says to keep out
The OWASP Logging Cheat Sheet lists data that should usually be removed, masked, sanitized, hashed or encrypted rather than recorded directly. It includes access tokens, authentication passwords, database connection strings, encryption keys and other primary secrets, session identification values, bank account or payment card holder data, and sensitive personal data. It also says to never log data unless it is legally sanctioned.
Integration code touches many of these. Authorization headers carry tokens. Request bodies carry card references or phone numbers. Error messages sometimes echo the request.
A log field plan
| Log | Do not log |
|---|---|
| Vendor request ID and your correlation ID | Authorization header or API key |
| Object ID (payment, message, user reference) | Full card details or bank account numbers |
| Idempotency key | Webhook signing secret or full signature header |
| Outcome class: success, declined, timeout, rate limited | Raw request and response bodies by default |
| HTTP status and vendor error code | Full message text or phone numbers, where avoidable |
| Duration and retry count | Stack traces that include credentials |
If you need a phone number or email to investigate, store a hashed or truncated form, or a pointer to a record that has access controls.
Steps
- Write a logging helper for vendor calls that sets the allowed fields, so developers do not craft ad hoc log lines.
- Redact headers by default. Allowlist the few you want, instead of denylisting the dangerous ones.
- Never print full responses in error handlers.
- Turn off debug HTTP logging in production for client libraries, since verbose modes can print headers and bodies.
- Set retention and access controls on the log store.
- Search for leftovers. Run a periodic search of logs for token prefixes and card number patterns.
- Treat a found secret as exposed. Rotate it. See how to rotate leaked API keys.
Logs for detection
Good logs also help you spot misuse: sudden spikes, calls from unexpected networks, a burst of declines. See detect API key misuse from logs. For timestamps, see UTC timestamps in logs.
Where Safeguard fits
Safeguard's compliance and evidence automation can help show that logging and retention controls exist. A free scan covers the libraries your logging and API clients depend on.
Quick check
Is it fine to log full vendor responses while debugging?
Only in a non production environment with test data. In production, log identifiers and outcomes instead.
What if I find a key in my logs?
Assume it is exposed. Revoke and replace it, then fix the log statement that wrote it.
Sources
- Go-live checklist, Stripe documentation
- Logging Cheat Sheet, OWASP
Last reviewed: 19 October 2026.
