In an e‑commerce transaction,
which you'll also here call a customer not present or CMP transaction,
there are the same authorization, clearing,
and settlement steps in the payment process.
And just as EMV chip transactions has made customer‑present
or face‑to‑face transactions more secure,
so EMV 3‑D Secure and EMV payment tokenization has made
e‑commerce transactions more secure.
But again, I'm going to first explain how simple e‑commerce transactions happen.
Then, a bit later, we'll look at the more secure forms of them.
Let's imagine that our cardholder Ann wants to buy some coffee beans using a
payment card from the Wired Brain Coffee website. The information that Ann
will need is printed on her payment card, the PAN,
the expiration date, maybe her name as it's printed on the card, and, if we
turn the card over, the security code printed on the back of the card, which,
just like the security code that's encoded on the magnetic stripe, is called
different things by each card scheme.
I'm generally going to call it the card verification value 2 or CVV2.
That's what Visa calls it.
Mastercard calls it the CVC2.
So it's important to know that this three‑digit value, which is a
different number to the CVV value encoded on the magnetic stripe, that
way if the criminal steals data from a website,
they won't have the CV value from the magnetic stripe. They'll just have the
CVV2 value, and so they can't make a cloned physical card.
And similarly, if a criminal steals data from a point‑of‑sale system,
they won't have the CVV2 data, just the CVV. So they
can't go shopping on the internet.
Visa, Mastercard, Discover, and JCB all print their three‑digit security
code on the signature strip on the back of the card.
American Express has a four‑digit security code, which they call the
CID, and this is printed on the front of an AmEx card,
just to the right of or just below the embossed primary account number.
Now the steps in an e‑com transaction are generally the same as
they are in a normal transaction, authorization,
clearing, and settlement.
But there's another irregularity with e‑commerce that you'll see a lot, which
is a step called capture. It sort of sits after the authorization step, and
it's used because there's a delay between the merchant accepting an e‑com
transaction and the goods actually being sent to the customer. Capture is not
there in every single e‑commerce implementation. It depends on how the acquirer
works with the merchant, what the merchant does, and also the card schemes.
So let's have a look at an e‑com authorization.
In a typical e‑com authorization,
the cardholder enters their data into the merchant website. This data
consisting of a PAN, CVV2, cardholder name, and expiration date is sent,
along with the merchant's details and the amount of the transaction, to
the issuing bank for authorization.
And just as with a face‑to‑face transaction,
the merchant is going to receive an authorization
response message from the issuing bank.
In some cases, and, remember, this doesn't happen for all e‑com transactions,
there will be a delay between when the customer orders the goods or
services and when their dispatched by the merchants.
If this is the case,
the merchant often makes an agreement that, as well as sending the
authorization request when the customer places their order,
the merchant will also send a capture requests the acquirer to
confirm the transaction is really happening and that the
merchant's fulfilled their side of the contract.
This capture transaction will typically just include
the PAN and the reference number.
Often, in an e‑commerce transaction,
you'll find another third party involved that sits
between the merchant and their acquirer.
This third party is called a payment service provider, or PSP.
They can be used by all sizes of merchants. And in the early days of
e‑commerce, payment service providers were the people who actually worked
out how to make card payments happen on the internet.
Nowadays, you'll often see payment service providers also called payment
facilitators or PFs. The PSP can make it really easy for merchants to start
selling on the internet because the PSP takes care of all the complicated
paperwork with the acquirers and with the card schemes. PSPs can also be
valuable for really large merchants to use because then they just have one
interface to the PSP, and then they can say to the PSP route this transaction
to one acquirer,
route a different transaction to another acquirer, and then route this
transaction straight through to a card scheme. So they can get
independence from acquirers, which helps them in terms of negotiating
better rates from certain inquirers,
perhaps with different types of transactions or different currencies.
So you see, a PSP is used by all sizes of merchants. In e‑commerce transactions,
clearing and settlement happens just in the same way as it does in a
face‑to‑face transaction. Clearing files go from merchants to acquirers, from
acquirers to schemes, then to the issuing banks. And then settlement money
goes in the other direction back to the merchants.
One of the things that PSPs will very often do is manage this
clearing and settlement process for merchants.