Not a vulnerabilityNothing is exploited and no payment fails. The forwarding is configured deliberately, usually to measure how well something sells, and the system performs it correctly.
What it is
At the moment a payment is initiated or confirmed, the system reports it to parties outside the chain that executes it: what was bought, the amount, an order reference, and an identifier for the customer or the device. In a browser or an app this is a measurement or advertising component; at a terminal or till it is a reporting integration alongside the payment path. The same shape occurs outside retail: a public body reporting each step of a transaction, with a case reference and a status, to a marketing or analytics party.
Why it is a separate entry
What someone buys is among the most revealing records there is, from medicines to political membership dues. A payment involves the payer, the merchant and the parties that move the money; everyone else is an addition the person cannot see, at a moment when they are concentrating on paying rather than on who is watching.
How it arises
a purchase event sent to an advertising component to attribute a campaign
basket contents included in an analytics event because the template offered the field
a loyalty or reporting integration in a till system that forwards line items
funnel steps of a payment or application flow reported to an analytics party, keyed to a long-lived identifier
Not to be confused with
Parties that execute the payment, such as the acquirer, the scheme or the issuer, are not this entry. Nor is an internal record kept by the merchant. The distinguishing feature is a recipient with no role in executing the payment receiving what was bought or what it cost, tied to an identifier.
How to establish it
At payment confirmation, a request to a host under a registrable domain belonging to neither the merchant nor a party in the payment chain, carrying the amount, an order reference or item identifiers together with a customer or device identifier.
method network-with-identifierQoD 88
Requirements on the measurement
your own purchase, your own means of payment; never someone else's transaction
capture through to the confirmation screen, since the reporting frequently fires only there
record which parties belong to the payment chain before judging the rest, so the boundary is drawn before the finding
for a terminal or till, capture at the gateway rather than on the device
What would refute it
by handThe recipient is part of the payment chain, such as an acquirer, gateway or fraud-prevention party under contract for that purpose.finding falls
automatedThe transmitted event carries no identifier and no line detail, only that a purchase occurred.weakens
not from the captureThe recipient acts strictly as a processor for the merchant and does not use the data for its own purposes.reclassify
automatedThe reporting only fires after consent was registered and refusing removes it.weakens
Where this plugs into existing processes
The one question that surfaces itWho receives a message when a customer pays, and which of those actually move the money?
In a DPIA, verify this
Verify which parties receive a message at the moment of payment, and which of them execute the payment.
As a procurement clause
At payment confirmation no party outside the payment chain receives the amount, the order reference or line detail, demonstrated by a capture of one complete purchase.
With a complaint, hand over
A capture from basket to confirmation, the list of recipients at confirmation, and the payment chain named separately.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-6-1-a
eu-gdpr-5-1-c
eu-gdpr-9-1
Objections, and the answer
“It is only an order total, not personal data.”
It travels with an identifier and an order reference, which is what makes it usable. Amount plus identifier plus time is a record about a person.
“We need it to measure our advertising.”
That is a purpose for the merchant, not a role in the payment. It has to stand on its own basis, and the person has to be able to refuse it without failing to pay.
“The item description is generic.”
Test it against the actual payload. Where the line detail names the product, the objection is answered by the capture.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0025: Transaction data outside the payment chain. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0025
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0025, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.