Payment systems have come and gone during past years. They exist, no matter what form they take, in order to make payment for goods and services possible. Face to face physical transfer of cash tokens of some form has been the predominant method of payment for many hundreds of years.
It’s a simple exchange: I give you something and you give me some cash token that I think has some intrinsic value (wampum or gold or government-issued bills) in return.
It’s not that simple
Underlying this simple exchange are many mandatory factors. Think about what is taken for granted. First, both parties to an exchange have to agree on who gets what in the exchange before it can happen. Secondly, payment must be delivered and verified to be of the correct amount. Thirdly, both sides to the transaction must be able to take their part of the bargain away from wherever the transaction occurred.
E-commerce is all about trading products or services by computer networks instead of doing it in a physical brick-and-mortar marketplace. Making these transactions via computer instead of face-to-face brings up a whole new class of problems. For example, how may the buyer know what the seller has if they cannot directly see it? How may the seller know he will be paid for what he gives in the transaction? How can the seller do the fulfillment (physical delivery of a product) to complete the transaction?
These were the kinds of concerns that initially held up the growth of Web-based e-commerce. Systems had to be developed to assure that all of the steps in the trade could be reliably done. While developing a website that was both attractive and functional was a lot of work, it eventually got done. But there was more to this deal than having a pretty face.
Sellers are only part of payment systems
Figuring out payment systems was not something a seller could develop on their own. It was far too complex. Now, payment systems generally have four characteristics:
These are flippantly referred to as CAIN, the four horsemen of payment systems.
Confidentiality means just the buyer and seller (and any parties they agree to add to the transaction like a product supplier) are the only ones that can see the transaction details. This is just a hop over from integrity concerns, that the transaction information will not be available to unauthorized use after the transaction occurs and the transaction data is being stored by some method. A data breach such as the one that happened to Target is a breakdown of integrity.
Authentication means that the system checks itself to assure internal consistency of the process. Non-repudiation means the system has some method in place so that neither party can modify the transaction after it has occurred, or deny that it occurred in the first place.
Enter the credit cards
Credit cards have handled payments like these routinely over the last quarter century. They have gotten rather good at it, actually. They are the most used payment system for e-commerce just because of the reliability that they have demonstrated over time. Buyers and sellers will usually have a business relationship with the credit card company (who, by the way, could be a bank that issues a debit card) that is already in force at the time of the transaction.
The system is already there and active. It’s convenient. It seems simple.
But, it’s a complicated system under it’s exterior. There is a whole series of data constructs specified by the credit card companies, known as the Payment Card Industry Data Security Standard (PCI DSS), to enable electronic data exchange among the participants just because of that complexity. This standard was a compromise between the many credit card companies that was encouraged by the Feds to avoid MasterCard and Visa establishing their own defacto data standard named SET. PCI DSS is generally aimed at protecting cardholder information, hence reducing fraud. It’s up to version 3.0 now, since starting in 2006. While PCI DSS is not mandated by federal law, some states have referred to it in regulatory context.
The network used for this payment systems consists of a series of transaction aggregators that feed and respond to each other. A “merchant gateway”would be just this sort of transaction aggregator.
The full VISA transaction system looks like this:
The transaction flow goes through the network until it shows up at the card issuer or credit card company. The request to authorize the user requires a response, which travels back to the requestor. The seller will either complete the transaction (or not) depending on the information that the response contains.
But there is another level to how the seller actually gets paid by the card issuer. Usually, the seller aggregates all the authorization requests it has made during some time period and submits them in a batch for actual payment. Transfers are then made to the seller’s financial account from the issuer.
The problem facing the seller is that they have very little control (just the way PCI DSS wants it) over the financial network system. Rather than being able to examine all transactions over the private network, for example, he or she can only examine their own transactions. System throughput can only be guessed at by the gateway-connected user, but it becomes almost a matter of faith that the payment system network is adequately maintained. Either that, or a good SLA is in force.
In the data highway hierarchy, payment system networks are like highways. They are big and they are fast, with many vehicles back and forth. And unless you've got someone watching over all of your company's transactions, you likely have no idea when major accidents occur along the way.