An unnamed, fictional example. Learn what is generated, what a business may be able to query, and which extra steps are needed for a CRM record.
One checkout. Different records.
A checkout can create an order and payment record. The demonstration uses invented identifiers and a £20 purchase.
{"order":"order_demo_01","value":"GBP 20.00"}This first animation requires the purpose check before presenting an authorised-use scenario. Software could still move data without that authority; the matching example below separates technical possibility from justified use.
Signals help assess whether a payment could be unauthorised or fraudulent. A risk score represents the system’s assessment of a transaction.
An authorised business can query data available to its account. Only exposed fields can be selected; the available fields and account scope define the query.
An export or integration can map selected fields into a receiving system. A reliable identifier enables matching. Suitable permissions and a justified purpose must be assessed separately.
Why transparency matters for SMEs and closed user groups →
Official sources checked 6 October 2026. Current documentation may differ from historic versions.
Illustrative query for account reporting. The fields available depend on the authorised account and schema. This example selects exposed payment fields.
SELECT id, customer_id, outcome_risk_level FROM charges ORDER BY created DESC LIMIT 10;
The important question is which identifiers survive each step. A payment, its merchant metadata and a security assessment can concern the same transaction while remaining different records with different access rules.
A checkout may send payment details and trigger separate device or activity requests. Stripe documents periodic requests to m.stripe.com. Trace each request and its fields separately.
A merchant can attach custom metadata, such as an internal order reference, to supported objects. A tag can add context; it is not necessarily a unique person identifier. Metadata does not automatically copy to every related object.
Sigma can query available account data and join customer and charge records. A selected export may retain a usable reference. The query uses exposed account fields; internal device and activity telemetry has its own collection and disclosure records.
Linking records does not require one network request. A single event can generate separate records that retain a common reference or a distinctive combination of attributes. In the teaching example, the linking information is deliberately retained so readers can see how a later system could reconnect the records. Collection and transfer records identify the fields available at each stage.
Collection and transfer records identify the fields available at each stage. A device identifier is not a company registration number or automatically a payment-account identifier. Establish the scope and meaning of each field before comparing it.
Stripe: advanced fraud detection ↗ · Stripe: metadata and copying rules ↗ · Stripe: transaction and customer joins ↗
Try the matching conditions using merchant report fields and an invented contact lookup. The records in this control are invented.
Invented payment reference and the selected matching field.
A lookup and account scope are assumptions that must be demonstrated.
The matching conditions are present. Destination purpose and responsibility are separate fields to review.
Matching capability and lawful authority are different questions. The demonstration can show a technically possible match even when the authority switch is off. A real match can be wrong; source identity, collisions and accuracy still need checking.
A pseudonymous or hashed identifier may remain linkable when another party has the necessary matching information. Merely removing a name does not guarantee anonymity. A common campaign tag alone usually identifies a group, not a unique person. Combinations of fields can create further identifiability risks, which this simplified example does not model.
Follow the invoice and accounting trail →This educational example demonstrates a possible matching mechanism using retained timestamps and identifiers.
Removing a name or replacing a card number does not automatically remove every way to recognise a person. Retained identifiers, order references or sufficiently distinctive attributes may permit a link if the recipient has the corresponding information.
A precise timestamp retained in two copies of an event can contribute to matching them. Combined with an order reference, amount or other distinguishing attributes and an available identity record, it may allow a person to be recognised after a name is removed. Time alone is not always unique; clock differences, retries and concurrent events must be handled. ICO: pseudonymisation and additional information ↗
Check whether timestamps, identifiers and activity values belong to the same event. Separate arrays or columns are not automatically aligned. Record time zones, repeated events, missing values and the meaning of each identifier.
A device identifier, merchant account identifier and company registration number answer different questions. Establish their scope before using them to join records.
A complete request capture could show fields sent together, destination and time. An export schema, executed query, matching recipient record and access log could then show which fields moved and how they were linked. A timestamp match alone does not supply that end-to-end evidence.
Stripe’s documentation describes periodic fraud-signal requests and states that advanced signals are used for fraud/security rather than advertising. Sigma’s documentation describes transactional reporting and CSV export of exposed account fields. Check the product configuration and documentation applicable to the event being examined.
Advanced fraud documentation ↗ · Sigma documentation ↗Checkout record 10:00:00.123 order_demo_17
Other record 10:00:00.123 identity unknown
The timestamp is a candidate link.
This control uses invented records to explore a transfer’s fields, purpose, authority, recipients and retention.