So now that we know what data criminals want to steal,
let's see where they can find this data.
Now, you'll remember that to authorize a face‑to‑face transaction,
the whole of the magnetic stripe is sent to the issuing bank,
and so if a criminal can take a copy of this data,
they'll be able to make a cloned card by writing that magnetic stripe
data they stole from a merchant onto a blank card and the issuing bank
won't know the difference between the real card and the cloned card and
would authorize transactions from both.
Looking at a simple retail example,
the card could be read in a dedicated card terminal,
which in the payment industry is called a point of interaction,
or POI.
You'll also hear these referred to as PIN entry devices,
or PEDs, or in some markets chip and PIN machines.
So it could be sent from this device straight to the acquiring bank.
On the other hand,
the data can flow from the point of interaction
into the merchant's cash register, which you'll often see called an ECR,
or some will call it a POS, a point of sale,
then it goes straight from the ECR directly to the acquirer.
If the merchants traditionally accepted magnetic stripe transactions,
the card might even be swiped through a reader
attached to the keyboard in the ECR.
So as before,
the ECR can communicate directly with the acquirer or a POI device could
send the data through the ECR and then onto the acquirer.
And in many cases,
there will be a central server or controller in each merchant store so all
the transactions are consolidated into one place from all the cash registers
or ECRs before they get sent to the acquirer.
Now, of course, like Wired Brain Coffee,
many retailers have got more than one store or physical location,
and so you can also find that authorization messages passed from each store to
a head office system where they get sent to an acquirer.
And in some cases you'll even see a hybrid where the authorization is
requested locally from a server in a retail store,
but it's also passed through to the head office servers just in case.
So if the store authorization fails,
transactions can be authorized by going via head office.
And of course,
sometimes head office saves this data just in case
or keeps it for later processing, for example to create those clearing files.
And so depending on how the merchant gets the authorization message
from the card to the merchant's acquiring bank,
you could find authorization data here, or here on the ECR,
or here in a store server,
or here in head office at something like a payment server or a payment switch,
or even here in a database.
In ecommerce,
you'll also find differences in the way that authorization data
gets from the consumer's browser to the acquirer.
The simplest, shown here,
is that once payment data is received by Wired Brain Coffee's web server,
it's sent directly from the web server to the acquirer.
In some larger merchants,
you tend to find that they've got multiple web servers with,
say, load balances in front of them,
which means sometimes you'll also discover that the TLS or the secure
connection is terminated at that load balancer.
So sometimes you'll see payment card data present on network
equipment before it reaches the web server.
Many ecommerce merchants have a central payment system,
so the customer's cardholder data goes from the web server
over an internal network to a payment server or a payment
system and from there to the acquirer.
And of course sometimes the merchant might do things like use
encryption on their own internal network.
So there are less places you might find cardholder data.
In this example,
I've shown perhaps the cardholder data will be encrypted between
the web server and the payment server so it wouldn't be passing
through an internal firewall in plaintext.
So if you looked for cardholder data there, you wouldn't see any.
Other merchants also store a copy of the
authorization in a database just in case.
And so just as in a face‑to‑face transaction,
in an ecommerce environment,
there are lots of places you can find authorization data.
It could be here on the firewall, here on the web server,
it could be on internal networking equipment,
it could be on a payment system, or it could even be in a database.
And that's one of the reasons why working in payments is really
interesting because every merchant is different,
and so it's always a discovery to find out where cardholder data might be.
Remember,
we care about where authorization data is because the
criminal can steal the authorization data themselves and use
it to pretend to have the real card.
However, stealing data is just a poor substitute for having the actual real card,
and if at all possible, the PIN.
Have you ever wondered what happens when an issuing bank or
credit card company sends you a new payment card?
Because criminals have, they ideally like to steal cars and PINs.
Now let's imagine that for some reason Ann wants a new card,
so she asks her issuing bank.
The bank is prepared for this as earlier in the year they ordered
lots of blank cards from a card manufacturer.
The card manufacturer made blank physical cards with the bank's logo
on it and an unprogrammed magnetic stripe and chip.
It sent these to a company called a personalization bureau,
which holds them security for the bank.
When Ann asks for a new card,
the bank includes Ann's details in a personalization file that it
sends to the personalization bureau every day,
which basically contains all the cards that the bank would like
the personalization bureau to make today.
The bureau takes the blank cards and the data set from the bank and on
one card it will put Ann's name and programs the chip and the magnetic
stripe with the data for Ann's card.
The personalization bureau often looks up the postage and delivery of cards for
the bank, so they send the card to Ann. And if also Ann needs a new PIN, the
personalization bureau will typically send this in the post as well in a secure
mailer a few days after the card was sent.
Sometimes, you'll find that the card manufacturer and the
personalization bureau are the same company.
Now,
criminals would like to be able to steal the blank cards and also cards and PINs
being sent from the bank to the bureau to the customer, and that's where we'll
see there are lots of standards to protect that.