What a merchant actually sees when you pay by card online

When you pay a merchant by card online, the card network does not send them your name or address. The merchant learns your name to identify you as the cardholder, your billing address for verification, and your email address to send you the order confirmation. The payment mechanism carries the transaction; the checkout form carries the identity. Which parts of the transaction you can change, and which you cannot, is what the rest of this piece is about.

The two routes

Every card payment carries two parallel flows of information to the merchant, and the two flows travel by different routes. One moves through the card network. The other moves through the checkout form the user fills in. These are distinct, and almost all of the information that identifies the user to the merchant travels through the second route, not the first.

The card network flow runs on a four-party architecture that Visa and Mastercard have operated for decades. When you submit a payment, the merchant forwards the transaction to their acquiring bank, which routes it through the card network to your issuing bank. The issuing bank checks the account, authorises or declines, and responds back through the same path. This sequence is what Benson and Loftesness, in Payments Systems in the U.S., call the authorisation message flow, and it is governed by an international messaging standard called ISO 8583 that Visa, Mastercard, and most other card networks have used since 1987. The message is compact by design: it carries the minimum data the issuing bank needs to make an authorisation decision, plus enough routing information to return the answer.

The checkout form flow is the other half. The merchant's site asks for the card number, the expiry date, the CVV, the billing address, the name on the card, the shipping address if the purchase is physical, the email address, and often the phone number. These fields are collected by the merchant, stored in the merchant's own systems, and, in the case of the billing address, sometimes passed into the authorisation message to be verified against what the issuing bank has on file. The form flow is not defined by ISO 8583 or by the card network. It is defined by the merchant's own checkout design, the merchant's marketing needs, and the scheme rules around Address Verification Service that make verified addresses the normal price of lower fraud risk.

What the card network carries

The authorisation request from the merchant to the issuing bank contains a fixed set of fields. The primary account number, which is the sixteen-digit card number. The expiry date. The CVV, which is validated during authorisation and then discarded by compliant merchants rather than stored. The transaction amount. The merchant category code, a four-digit number classifying the type of business. The merchant name and location, because the issuing bank's fraud systems need to know where the purchase is happening. And, in card-not-present transactions where the merchant has requested it, the Address Verification Service field, which contains the billing address or postcode.

That list is close to complete. What the card network transmits from the merchant to the issuing bank is transactional data, the data the issuer needs in order to decide whether to approve the payment. The response travels back along the same path: approved or declined, a reference number, and an AVS match code if address verification was requested.

The cardholder's name does not travel through the authorisation message itself. In the card-present world this was obvious, because a merchant at the till might see the name embossed on the card, but the network did not transmit it. Online, the merchant sees the name because the checkout form collected it, not because the card delivered it. The card is not leaking identity. The form is collecting it.

The AVS field is the most interesting case because it blurs the line. When a merchant runs address verification, they populate the authorisation message with what the user typed into their checkout form, asking the issuing bank to confirm whether the address matches what is on file. The network carries the data because AVS is a network-level service, but the data originates with the user's input to the merchant, not with the card itself. Enter an incorrect address and the AVS response flags a mismatch. Enter a registered address that is not your real one and the AVS response confirms a match. The address travels because the user submitted it, not because the card carries it.

The practical consequence is narrower than it sounds. Privacy measures that operate only on the card network do not prevent identity from reaching the merchant, because the card network was not the route the identity was taking. Apple Pay and Google Pay are the clearest example. Both replace the card number with a device-specific token, so the merchant never receives the real PAN. That is a genuine protection against card number theft and one of the better measures available today for in-person or tokenised online payments. It does not touch anything on the form. The merchant still collects the name, the billing address, the email, and the delivery address, because all of those come from the checkout form, not from the card. Tokenised wallets are worth using. They are partial.

The same analysis applies to any card whose main privacy claim is at the network layer. Revolut's disposable virtual cards, which rotate the card number on each transaction, address one risk (the merchant storing a reusable number) without addressing the other (the merchant still receiving the full checkout-form bundle, and the underlying account still being in the user's real name). That the merchant cannot reuse the rotated number is useful. That the merchant still knows who made the purchase, through the form, is what the rotation does not change.

What the checkout form collects

Everything the merchant learns about the user's identity is learned through the form. On a typical online checkout the fields are: name on the card, billing address, email, phone number, and, if physical goods are being shipped, the delivery address. Some merchants also request date of birth, account passwords, marketing preferences that are almost always pre-ticked, and loyalty programme sign-ups buried in the same flow.

Each of these fields has a reason the merchant can justify. The billing address supports AVS. The shipping address supports delivery. The email supports order confirmations and, later, marketing. The phone number supports Strong Customer Authentication under the Payment Services Regulations and also supports marketing. The date of birth, where it is collected, is almost always for age gating or marketing segmentation rather than for the payment itself.

Once collected, the fields sit in the merchant's own systems. They are subject to the merchant's privacy policy, not to the card network's scheme rules. The card network does not impose retention limits on data the merchant collected at checkout that did not pass through the network. PCI-DSS, the card industry's security standard, governs how the merchant stores the card data specifically. It does not govern how the merchant uses the name, address, email, or phone number the user supplied in the same form. Those fields fall under UK GDPR and the merchant's own data practices.

The merchant ends up with two kinds of data from a single transaction. The card data, subject to PCI-DSS. The identity data, subject to the merchant's privacy policy and to UK GDPR. The two are collected in the same flow, within seconds of each other, and most users do not distinguish them. In the merchant's system they are joined at the hip: every future interaction, every marketing message, every loyalty calculation, and every data-broker sale of aggregated purchase behaviour will treat them as a single record.

This is where the reader has meaningful choices to make. UK GDPR already gives any reader the right to know what a merchant holds about them, and the right to have it erased in most circumstances. Article 15 is the Subject Access Request: any organisation that holds personal data about you must provide a copy on request, within one month, free. For a merchant you have used repeatedly, the response reveals what they actually retain, which is often more than you remember giving them and sometimes more than they should have retained. Article 17 is the right to erasure: if you no longer use a merchant's service and they have no lawful basis to keep your data, you can require them to delete it. Dormant accounts, expired subscriptions, and old loyalty sign-ups are the clearest candidates.

The two articles together are close to a free, statutory audit of your merchant data footprint. The ICO publishes template wording for both. A reader who sends half a dozen Article 15 requests to the merchants they have used most in the last two years will learn something specific and actionable about where their payment-related identity data actually lives.

Marketing preferences are the other meaningful control at the form level. Most UK merchant account settings include them. The defaults are, with vanishing few exceptions, set in the merchant's favour rather than the reader's. Going through the settings for the five or six merchants a reader uses most takes under an hour and removes the legal basis for several categories of downstream data sharing. When you do this exercise, you will find you consented to things you do not remember consenting to.

Why the pattern matters more than any single field

What reaches the merchant is one question. What the merchant keeps is another. The second question is where payment privacy actually lives.

The card network's authorisation message is transactional. The data in it is relevant to the transaction, and once the transaction settles it has limited further use. The merchant's records of the card number do have future use, because the card number recurs on future transactions and because breached card numbers can be sold, but the card industry has spent twenty years putting tokenisation mechanisms in place to limit that exposure.

The checkout form data is different. It persists. A name, an address, an email address, and a phone number are not invalidated when the transaction completes. They sit in the merchant's customer database, joined to the record of what was bought and when, and they remain there until the user exercises a right to erase them or the merchant decides on its own retention schedule. Over a year the merchant accumulates a record of what the user bought, how often, for how much, and what they looked at before buying. Over five years, the record becomes a profile.

This is the aggregation argument Schneier develops in Data and Goliath. A single transaction reveals almost nothing. The pattern of transactions reveals a great deal. Véliz, in Privacy is Power, names the debit card used to buy a book as the specific example by which payment data enters the data broker ecosystem; she is not speaking metaphorically. The purchase is the transaction; the record of the purchase is the asset. The transaction ends when the merchant confirms payment. The record does not end. It joins the other records the merchant has accumulated, and together those records support the kind of behavioural profile that would have been impossible to assemble from any single interaction.

The empirical evidence on how easily such profiles can be de-anonymised is sobering. In a 2015 paper in Science, de Montjoye and colleagues at MIT analysed three months of credit card records for 1.1 million users and found that a very small number of transactions, combined with knowledge of approximate date and location, was sufficient to uniquely identify most individuals in the dataset. The precise figure they reported was contested in a subsequent exchange in the same journal; the direction of the finding was not. It takes very little data to single out a person in a set of supposedly anonymous payment records, and the fragility comes from the pattern rather than from any single transaction.

The consequence for the reader returns to the two GDPR actions from the previous section, with a different emphasis. Article 17 erasure matters more than it first appears. The dormant account at a merchant you used twice three years ago holds a small amount of data on its own. The same account, joined with everything else that merchant knows about you and everything they have since shared with marketing affiliates, is part of a profile. Erasing the account when you no longer use it breaks the accumulation at that specific merchant. Doing this for every merchant you no longer use is the clearest single thing a UK reader can do to reduce their aggregated profile without waiting for any architectural change.

Paying with cash, where practical, is the same argument applied to transactions before they begin. Véliz's primary recommendation. A cash transaction leaves no data trail with the merchant, no record with any bank, and no entry in any payment processor's database. Cash is the most private payment mechanism available and still legal tender in the UK, despite the ongoing reduction in acceptance. For in-person purchases, nothing beats it.

The gap that nothing in UK law closes

Everything above reduces the flow of identity data to the merchant. None of it closes the flow entirely, because the merchant needs a card number to charge, and the card number is itself a persistent identifier.

Every card payment delivers a sixteen-digit number to the merchant. That number is stable across transactions from the same card, which means a merchant who stores it can recognise the same user on a future visit. The merchant's records are then joined on that number: every time the same card is used, the merchant's database grows. Over time, the card number functions as an identifier even if the name, address, and email were entered differently each time.

The UK GDPR actions described above do not change this. Exercising Article 15 reveals what the merchant holds. Exercising Article 17 deletes it, where lawful. Neither prevents the merchant from rebuilding the record the next time the same card is used. The card carries a stable identifier, and the stable identifier is what lets the merchant link transactions into a profile.

Secondary debit cards from challenger banks help at the margin. Using a card from Monzo, Starling, or Chase UK only for online purchases is not a privacy mechanism, but it is a fault line. If a merchant holding the details of that card behaves badly, you can cancel the card without disrupting your primary account. Containment, not prevention.

The only complete architectural response is a card number that is not stable. A disposable card number, specific to one transaction or one merchant, cannot be used to link transactions into a profile because there is no shared identifier to link on. The US has had this for a decade through Privacy.com. The UK has not. That is the gap eigin is being built to close. It is not the whole of payment privacy, and it is not a replacement for exercising the UK GDPR rights above. It is the part that cannot be solved at the form level, by any combination of GDPR requests, preference settings, or merchant choice.

The first reclamation

Payment privacy in the UK is not a single problem, and there is not a single answer. Some of the answer already exists in UK law and in the reader's ability to use it. Article 15 and Article 17 are there to be exercised. Cash is there to be spent. The settings are there to adjust. Some of the answer still depends on architecture that does not yet exist at the consumer level in the UK. Understanding the difference between the two is the first reclamation. The rest follows from it.

---

References

Benson, Carol Coye, and Scott Loftesness. Payments Systems in the U.S.: A Guide for the Payments Professional. 2nd edition. Glenbrook Press, 2014.

de Montjoye, Yves-Alexandre, Laura Radaelli, Vivek Kumar Singh, and Alex Sandy Pentland. "Unique in the shopping mall: On the reidentifiability of credit card metadata." Science 347(6221): 536–539 (30 January 2015). DOI: 10.1126/science.1256297. The methodology was challenged in a 2016 comment in the same journal by Sánchez, Martínez, and Domingo-Ferrer, with a response from the original authors. The finding that very few transactions suffice to re-identify most users remains the consensus direction even where the exact figure is contested.

ISO 8583. Financial Transaction Card-Originated Messages: Interchange Message Specifications. International Organization for Standardization, 1987 (revised 1993, 2003).

Schneier, Bruce. Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World. W. W. Norton, 2015.

UK GDPR, Articles 15 and 17. Information Commissioner's Office published guidance at ico.org.uk.

Véliz, Carissa. Privacy is Power: Why and How You Should Take Back Control of Your Data. Bantam Press, 2020.