Fraud Controls
Part of Checkout security and access
Keeping sensitive payment data out of application logs
Design useful checkout logs without collecting card details, credentials or raw payment requests, and respond if sensitive data appears.
Design checkout logs around an explicit allowlist of fields, not payment request bodies. Before release, test the fields and inspect every destination that could receive a record, including forwarded and archived copies.
Record what an investigation needs
Record an order or attempt reference, event type and time, safe error category, provider status, component and release identifier. A provider reference is useful only if it does not act as a credential; exclude passwords, API keys, JSON Web Tokens and any credential-like reference.
Keep full card numbers, card verification codes, payment form or API request bodies, session tokens and unrelated customer details out of logs. Preserve the provider’s original status so staff can distinguish a failure from a payment still processing.
Choose fields for the integration and purpose of the log. Do not log a whole object just because it contains one useful status.
Prevent collection at the source
Use an explicit allowlist of permitted fields rather than relying on rules that strip a few known secret names. Review request and response middleware, exception handlers that attach local variables, payment SDK debug settings and browser error tools that may capture form values.
Keep credentials out of URLs and query strings because web servers and proxies may log them before application redaction runs. If a fault needs extra diagnostics, give the collection an owner, restricted access and a defined end; raw payment-body logging should not be routine.
PCI DSS Requirement 3.3.1.2 prohibits storing card verification codes after authorisation, even if encrypted. Treat a full card number in a log as stored cardholder data, and do not rely on masking what staff see to protect a value already stored.
PCI DSS Requirement 3.4.1 addresses masking PAN when displayed; Requirement 3.5.1 addresses protection of PAN when stored, processed or transmitted. Masking can leave the full PAN stored, while truncation removes part of it; the two are not interchangeable.
Have a Qualified Security Assessor (QSA) or payment-security specialist identify the applicable PCI DSS v4.x requirements for the payment data flow and log controls. A provider-hosted form does not establish that every merchant log is harmless.
PCI DSS requirements relevant to payment logging
- 3.3Requirement .1.2 — No storage of CVV after authorisation
- 3.4Requirement .1 — Mask PAN when displayed
- 3.5Requirement .1 — Protect PAN when stored, processed or transmitted
Check the destinations
At the release gate, review the permitted-field list and test a successful attempt, a failed attempt and an exception in the provider’s permitted test environment. Inspect the application logs, error trackers, proxies, monitoring services and support exports, plus web server, network device, operating system and database logs where checkout data could reach them.
Follow records into forwarded and archived copies, and check that support staff can still join order and provider records using safe references. Use provider-approved test data, not a real customer’s card details.
Block release until the tests show that sensitive fields are absent from every checked destination. Record the review and approval for changes to checkout logging, middleware or payment SDK debug settings.
Set access and retention rules for each log platform. Limit who can read or export records, record access where the platform permits, and remove records when no longer needed under applicable business and legal rules.
If sensitive data appears
Stop new collection and restrict access to affected records. Establish what data entered which systems and when, including forwarded copies, archives and exports, and preserve the evidence needed to determine this without copying the sensitive value into a new ticket.
Ask a payment-security specialist to assess card-data implications and a privacy adviser to assess personal-information implications where relevant. After evidence and preservation needs are established, arrange removal of affected records and copies, then verify that collection has stopped.
Base remediation and any notification decisions on the established facts and advice from the relevant specialists.
