PCI DSS compliance for tracking providers: what TrackLayer does vs what you do

PCI DSS is the payment-card security framework that applies to organizations that store, process, or transmit cardholder data, as well as systems that can affect the security of that data. For merchants, the first scope question is usually merchant level. Card brands group merchants into four levels based mainly on annual transaction volume and risk profile. The exact thresholds can vary by brand and acquirer, but the operating logic is stable: higher-volume merchants face more formal validation, while smaller merchants often complete self-assessment with supporting evidence.

The standard itself is organized around 12 core requirements, covering topics such as network security, secure configuration, access control, logging, vulnerability management, testing, and governance. Those requirements matter because PCI DSS is not only about the payment form. It also cares about every connected system that can expose or influence cardholder data. That is why scope control matters so much. If a tracking vendor never touches CHD, it should not be pulled into the card-data environment by accident.

Validation also depends on the right SAQ type. SAQ-A is usually the narrowest merchant path and is meant for ecommerce businesses that fully outsource card-data capture to PCI DSS compliant third parties. Other SAQ variants apply when merchants host payment pages, embed different payment elements, or otherwise handle more of the payment flow directly. The practical test is simple: if your site, backend, or vendors can see CHD, your SAQ obligations move beyond the narrowest model.

TrackLayer is built for an SAQ-A style deployment boundary. We do not store, process, or transmit CHD, meaning cardholder data such as PAN, expiry date, CVV, or cardholder name tied to the payment instrument should never enter TrackLayer in the first place. Our role is to receive business events after the payment processor has already handled the payment interaction.

In the standard setup, your payment processor owns the payment fields, tokenization, authorization, capture, and card network communication. TrackLayer receives the commercial result: successful checkout, order amount, currency, order reference, customer linkage, consent state, and destination routing logic. That design keeps payment collection with the processor and keeps TrackLayer focused on attribution, analytics, and auditability.

That separation does not remove your merchant responsibility. You still need to confirm the real implementation matches the intended architecture. If custom code, support workflows, logs, or transformations start copying payment fields into TrackLayer or neighboring systems, scope changes. The right compliance stance is not “TrackLayer is safe by default, so nothing else matters.” It is “TrackLayer stays out of scope when the merchant preserves the clean boundary.”

Teams often mix privacy vocabulary with PCI vocabulary. A hashed email is not cardholder data under PCI DSS. By itself, it does not represent a payment credential and does not create card-data scope for TrackLayer. That matters because many attribution setups rely on hashed email for matching, and merchants sometimes assume any sensitive-looking identifier is automatically a PCI artifact.

The important distinction is that something can be outside PCI card-data scope and still remain regulated under privacy law. Hashed email can still be personal data under GDPR when it can be linked to a person or used for profiling or advertising measurement. So the correct compliance posture is split-brain on purpose: PCI asks whether payment credentials are present, while GDPR asks whether personal data is present and processed lawfully.

The recommended pattern is to send business outcomes, not payment instrument details. For a completed purchase, TrackLayer should receive a canonical event such as `order.completed` with fields like `value`, `currency`, `order_id`, customer identifier, and optional product or subscription context. That gives marketing, analytics, and finance teams the signal they need without dragging card data into the tracking layer.

What should not be sent is just as important. Do not include card number, BIN, issuer details, cardholder name, last four copied from the processor unless explicitly justified elsewhere, or raw payment method payloads. The tracking contract should describe the commercial event, not the mechanics of how the processor funded it.

Recommended
event: order.completed
value: 129.00
currency: EUR
order_id: ord_2026_0418_9842

Avoid
card_number
bin
cardholder_name
expiry_date
cvv

The cleanest PCI posture comes from using payment processors that already isolate credential capture and then emitting post-payment webhooks into TrackLayer. In that model, TrackLayer becomes the consumer of payment outcomes, not the collector of payment data. This is the normal path for Stripe, Adyen, Checkout.com, and Braintree integrations.

By default, none of these integrations need to expose CHD to TrackLayer. The risk shows up only when merchants add custom webhook transformations, verbose debugging, or warehouse syncs that preserve processor payloads more broadly than needed. The safe operating rule is to normalize events at the edge and drop any payment fields that are not required for analytics or audit.

Annual PCI assessment is easier when your event pipeline leaves a defensible trail. TrackLayer audit logs record who configured a destination, when webhook endpoints were added or changed, which event mappings were deployed, whether deliveries succeeded, and how retries or suppressions were handled. That does not replace your formal PCI evidence set, but it gives merchants concrete operational proof that the tracking layer was managed in a controlled way.

In practice, those logs help with assessor questions such as: when did the processor integration change, who approved the payload contract, when was a risky field removed, and how can the team show that only approved business events were forwarded? A clean audit log also helps security and privacy teams align their narratives. The same event history that supports PCI scoping can support incident review, GDPR accountability, and vendor-change governance.

The strongest merchant workflow is to pair TrackLayer audit records with architecture diagrams, webhook schemas, processor documentation, and a short written data-flow statement saying that CHD is collected only by the payment processor. Assessors do not want theory alone. They want evidence that the implemented system still matches the declared scope.