Lets say I buy something at some (physical) store and pay using a credit card on one of these electronic terminals. What information do the owners of this store get about me (or my credit card) from this transaction?

Can they find out whether multiple purchases were paid using the same credit card?

  • 1
    I have first-hand experience with information going the other way. Specifically, I made a purchase at WalMart with a credit card, and later, that card company asked me about the product. I had no idea they'd ever see that, only the total, date, etc.
    – donjuedo
    Apr 11, 2019 at 18:38
  • 4
    @donjuedo Curious, was it a Walmart-branded card? My store-branded credit cards do have that info within store. Outside of that relationship, it's possible to pass that info up the chain, but not particularly common.
    – gowenfawr
    Apr 11, 2019 at 18:44
  • 1
    @gowenfawr, It was not a WalMart-branded card. I usually use Chase, for the airline miles. There's a small chance it was one other card.
    – donjuedo
    Apr 11, 2019 at 19:27
  • 4
    The answer to this is going to vary by country due to privacy laws. You should specify where.
    – user71659
    Apr 11, 2019 at 21:53
  • 2
    If there is any sort of loyalty scheme involved, see the fine print. You may have agreed to your data being harvested/aggregated and used for research and/or marketing. Hilarity can sometimes ensue when they (or their analytics) get this wrong.
    – mckenzm
    Apr 12, 2019 at 0:04

3 Answers 3


From the card itself, the Merchant gets the track data, which includes card number, expiration date, and cardholder name.

If the Merchant requires zip code verification, they'll get your zip code, obviously.

(Card-Not-Present Merchants often get address data for billing/shipping purposes, but you asked about physical stores... and they get that from the Customer, not the card itself.)

The Merchant can track purchases made with that card within their store(s), but not those made at other, unconnected stores. Be aware that sometimes multiple stores (e.g. HomeGoods, TJ Maxx) are actually the same "Merchant" (TJX Companies).

The Processor, on the other hand, can correlate a single card's activity across multiple Merchants. They don't generally have transaction details ("what you bought") but they do have amounts, categories, Merchants, times, all of which may be provided to the Card Brands (Visa, Mastercard, ...) upon request, or law enforcement upon a subpoena.

Each processor will have a different view. If Processor A handles Merchants A, B, and C, and Processor B handles merchants D, E, and F, then the Processors will have completely disjoint sets of data to work with. In general most Merchants use a single Processor; some load-balance across multiple Processors for redundancy and availability, but most transactions will only be seen by one Processor.

Processors do a lot of data analysis to provide value-add, but not to the extent of providing individual cardholder details across Merchants. Most such data analysis is done on large, anonymous buckets, but others, like householding, require identifying factors be used in the analysis.

Processors, Card Brands, and Banks can also make loose inferences about what you're buying based on the Merchant Category Code (MCC). These aren't very exact - those salted peanuts from the Exxon station might get classified as "Gas" - but they provide some guidance. These are the codes that Corporate-issued credit cards will use to block non-work transactions.

Finally, cards themselves are informative. Merchants can tell the difference between a prepaid card and a Black Card, and they can treat the cardholder differently in accordance with their status, for example extending discounts to higher-value-card holders. This is true not only in a physical store, where the Merchant sees your card; Processors can provide this sort of metadata to Card-Not-Present Merchants as well.

(The ability to determine the type of card is not unique to Processors; it's based on the BIN (the first 6 digits of the card) and you can look it up with freely available tools like binlist.net. However, since the list changes over time, and since it's only a portion of guidance, this is a service most usefully provided by a Processor. For example, anyone can tell if a card is a Black Card - but as a Merchant you might treat a Black Card with a high chargeback rate differently than the rest. Only the Processor can integrate that guidance.)

  • Wait, even with an EMV transaction, the merchant still gets the card data? So it only protects against skimming attacks at the POS terminal, and nowhere else in the transaction processing or data storage systems? Apr 11, 2019 at 21:41
  • 3
    @PhilMiller yes, PAN is on the EMV and readable. EMV is designed to reduce fraud and cloning, not protect against disclosure - I mean, the number is still printed on the card!
    – gowenfawr
    Apr 11, 2019 at 21:48
  • Dangerous to make assumptions about the card, Platinum and Gold are de facto "stealth" black cards. Branded cards, maybe.
    – mckenzm
    Apr 12, 2019 at 0:01
  • "[The Processors] don't generally have transaction data" Citation needed. And read about Level 3 transaction data.
    – Ben Voigt
    Apr 12, 2019 at 6:51
  • 2
    @BenVoigt Citation is personal experience (I work for a large-ish Processor) and human nature. Who wants to upload their details into a platform that doesn't allow data mining or even basic, much less sophisticated, analysis? Level 3 data is, as your link states, for Corporate, B2B, and B2G, which are minority where there's a driving reason to include that data.
    – gowenfawr
    Apr 12, 2019 at 8:52

At the very least, they can get the card number. Most receipts will even have the last few digits of the card number printed on them, but the system will have had the full number at some point, and may well hold a tokenised version of the card number which is allowed under PCI (think of it being a random value which can be linked back to the card number by the tokenising service). Since the same card probably gives the same token each time (technically this is optional, but since it gives more information than the alternative, it's the more common in practice), they can go "this card also bought X, Y and Z on these dates".

They can't usually cross reference that data with other stores though - the token associated with a given card from store A is completely unrelated to that associated with a given card from store B, in a sensibly designed system. I don't know whether any tokenisation providers pool data from multiple clients, but that could be a potential nightmare under GDPR, so I'd assume not, at least in Europe.

The issuing bank can also see purchases being made, obviously, but usually in a per transaction basis, rather than individual items. That doesn't mean they can't make educated guesses about the purchases (e.g. if you make a payment to a business called "99p Donuts" for 99p, it's a pretty safe guess that you bought a donut...),

  • Are there differences in the data available between magstripe transactions and EMV transactions (or, heck, carbon copy!)? I would (naïvely, unknowingly) assume so?
    – gsnedders
    Apr 11, 2019 at 14:29
  • Kind of. The card number is present in all three, along with the expiration date, and name (see @gowenfawr answer). The main differences are in verification of the card - with carbon copy, that is someone checking the signature. With magstripe, can be a mix of person check and online verification that the card isn't marked as stolen. With chip, ideally it's checking that the person presenting the card knows the PIN (potentially combined with online verification). The differences don't affect the ability to track purchases though.
    – Matthew
    Apr 11, 2019 at 14:46
  • So the industry term is "token" and there are "tokenisation providers" ? Seems like a simple hashing algorithm would do the trick - not sure where a provider comes in.
    – JPhi1618
    Apr 11, 2019 at 17:39
  • @JPhi1618 generally Merchants send card numbers to Processors (who Process them) but often the Processor will hand back a Token and the Merchant can forget the card number. This lowers their PCI scope and requirements. It's really not impactful for this question; the Processor always has both the token and the card and the Merchant can access information using the token instead of the card number.
    – gowenfawr
    Apr 11, 2019 at 17:44
  • 1
    You don't want to hash because you then run the risk of database leaks giving away actual card numbers - you know the input format (12-18 digits, fitting a Luhn check), so can reduce the search space substantially. If the database also stores the last 4 digits, and you know the valid values for the first 6 (the issuer code), you can cut it even more.
    – Matthew
    Apr 11, 2019 at 17:44

Just to add to the previous answers: Apart from the obvious data that is entered during checkout, you can also get the issuing bank name from the first 6 numbers of the credit card number. With the bank name you can sometimes guess the country where the card was issued when you get a result like "Bank of China", "ANZ" or "Národná banka Slovenska".

I used this method (along with others) in an online store when calculating a risk factor before an order was shipped, to eliminate or flag orders that are placed with stolen credit card numbers. If user IP, delivery address and bank card are all from different countries then your order would go on hold and flagged for manual review.

  • Great tip! I’d never heard of this approach until now, but I’m sure it could prove helpful in many situations where the card processor doesn’t provide anti-fraud measures (although I’m sure most do these days, with better technology and algorithms beyond this approach).
    – Simon East
    Jul 19, 2020 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .