University of Jammu

The Business School

MBA 106: Computer Applications In Management

Online Payment Protocols

Submitted To: Submitted By:

Mrs. Versha Mehta Kartik Gupta (18)

Faculty Varun Kumar (39)

TBS, JU MBA, 1st Sem

E-commerce payment system

An e-commerce payment system facilitates the acceptance of electronic payment for online
transactions. Also known as Electronic Data Interchange (EDI), e-commerce payment
systems have become increasingly popular due to the widespread use of the internet-based
shopping and banking. In the early years of B2C transactions, many consumers were
apprehensive of using their credit and debit cards over the internet because of the perceived
increased risk of fraud. Recent research shows that 30% of people in the United Kingdom
still do not shop online because they do not trust online payment systems. However, 54% do
believe that it is safe to shop online which is an increase from 26% in 2006.

There are numerous different payments systems available for online merchants. These
include the traditional credit, debit and charge card but also new technologies such as digital
wallets, e-cash, mobile payment and e-checks. Another form of payment system is allowing a
3rd party to complete the online transaction for you. These companies are called Payment
Service Providers (PSP), a good example is Paypal or WorldPay.

Credit Cards and Smart Cards

Over the years, credit cards have become one of the most common forms of payment for e-
commerce transactions. In North America almost 90% of online B2C transactions were made
with this payment type. Turban et al. goes on to explain that it would be difficult for an online
retailer to operate without supporting credit and debit cards due to its widespread use.
Increased security measures such as the use of the card verification number (CVN) which
detects fraud by comparing the verification number on the printed on the signature strip on
the back of the card with the information on file with the cardholder's issuing bank. Also
online merchants have to comply with stringent rules stipulated by the credit and debit card
issuers (Visa and MasterCard) this means that merchants must have security protocol and
procedures in place to ensure transactions are more secure. This can also include having a
certificate from an authorised certification authority (CA) who provides PKI infrastructure
for securing credit and debit card transactions.

Despite this widespread use in North America, there are still a large number of countries such
as China, India and Pakistan that have some problems to overcome in regard to credit card
security. In the meantime, the use of smartcards has become extremely popular. A Smartcard
is similar to a credit card; however it contains an embedded 8-bit microprocessor and uses
electronic cash which transfers from the consumers’ card to the sellers’ device. A popular
smartcard initiative is the VISA Smartcard. Using the VISA Smartcard you can transfer
electronic cash to your card from your bank account, and you can then use your card at
various retailers and on the internet.

There are companies that enable financial transactions to transpire over the internet, such as
PayPal.

Many of the mediaries permit consumers to establish an account quickly, and to transfer
funds into their on-line accounts from a traditional bank account (typically via ACH
transactions), and vice versa, after verification of the consumer's identity and authority to
access such bank accounts. Also, the larger mediaries further allow transactions to and from
credit card accounts, although such credit card transactions are usually assessed a fee (either
to the recipient or the sender) to recoup the transaction fees charged to the mediary.
The speed and simplicity with which cyber-mediary accounts can be established and used
have contributed to their widespread use, although the risk of abuse, theft and other problems
—with disgruntled users frequently accusing the mediaries themselves of wrongful behaviour
—is associated with them.

Electronic Bill Presentment and Payment

Electronic bill presentment and payment (EBPP) is a fairly new technique that allows
consumers to view and pay bills electronically. There are a significant number of bills that
consumers pay on a regular basis, which include: power bills, water, oil, internet, phone
service, mortgages, car payments etc. EBPP systems send bills from service providers to
individual consumers via the internet. The systems also enable payments to be made by
consumers, given that the amount that appears on the e-bill is correct. Banks in Canada have
been offering these on-line payment services for some time now, and are growing in
popularity. Other service providers such as Rogers Communications and Aliant accept major
credit cards within the bill payment sections of their websites. This service is in addition to
the original EBPP method of a direct withdrawal from a bank account through a bank such as
Scotiabank.

The biggest difference between EBPP systems and the traditional method of bill payment, is
that of technology. Rather than receiving a bill through the mail, writing out and sending a
check, consumers receive their bills in an email, or are prompted to visit a website to view
and pay their bills.

Three broad models of EBPP have emerged. These are:

1. Consolidation, where numerous bills for any one recipient are made available at one
Web site, most commonly the recipient's bank. In some countries, such as Australia,
New Zealand and Canada, the postal service also operates a consolidation service.
The actual task of consolidation is sometimes performed by a third party, and fed to
the Web sites where consumers receive the bills. The principal attraction of
consolidation is that consumers can receive and pay numerous bills at the one
location, thus minimising the number of login IDs and passwords they must
remember and maintain.
2. Biller Direct, where the bills produced by an organisation are made available through
that organisation's Web site. This model works well if the recipient has reasons to
visit the biller's Web site other than to receive their bills. In the freight industry, for
example, customers will visit a carrier's Web site to track items in transit, so it is
reasonably convenient to receive and pay freight bills at the same site.
3. Direct email delivery, where the bills are emailed to the customer's In Box. This
model most closely imitates the analog postal service. It is convenient, because almost
everyone has email and the customer has to do nothing except use email in order to
receive a bill. Email delivery is proving especially popular in the B2B market in many
countries.

Major providers of outsourced bill production services have developed facilities to process
bills through consolidation, biller direct and email delivery services, thus enabling major
billers to have all their bills, paper and electronic, processed through the one service. Niche
service providers in many countries provide one or two of these models, but generally do not
integrate with paper bill production.
Electronic Data Interchange

Electronic data interchange (EDI) is the structured transmission of data between

organizations by electronic means. It is used to transfer electronic documents or business data
from one computer system to another computer system, i.e. from one trading partner to
another trading partner without human intervention.

It is more than mere e-mail; for instance, organizations might replace bills of lading and even
cheques with appropriate EDI messages. It also refers specifically to a family of standards,
e.g. UN/EDIFACT, ANSI X12.

The National Institute of Standards and Technology in a 1996 publication defines electronic
data interchange as "the computer-to-computer interchange of strictly formatted messages
that represent documents other than monetary instruments. EDI implies a sequence of
messages between two parties, either of whom may serve as originator or recipient. The
formatted data representing the documents may be transmitted from originator to recipient via
telecommunications or physically transported on electronic storage media.". It goes on further
to say that "In EDI, the usual processing of received messages is by computer only. Human
intervention in the processing of a received message is typically intended only for error
conditions, for quality review, and for special situations.

EDI can be formally defined as 'The transfer of structured data, by agreed message standards,
from one computer system to another without human intervention'. Most other definitions
used are variations on this theme. Even in this era of technologies such as XML web services,
the Internet and the World Wide Web, EDI may be the data format used by the vast majority
of electronic commerce transactions in the world.

Standards

EDI is considered to be a technical representation of a business conversation between two

entities, either internal or external. Note that there is a perception that "EDI" constitutes the
entire electronic data interchange paradigm, including the transmission, message flow,
document format, and software used to interpret the documents. EDI is considered to describe
the rigorously standardized format of electronic documents. EDI is very useful in supply
chain.

The EDI standards were designed to be independent of communication and software

technologies. EDI can be transmitted using any methodology agreed to by the sender and
recipient. This includes a variety of technologies, including modem (asynchronous, and
bisynchronous), FTP, E-mail, HTTP, AS1, AS2, etc. It is important to differentiate between
the EDI documents and the methods for transmitting them. When they compared the
bisynchronous protocol 2400 bit/s modems, CLEO devices, and value-added networks used
to transmit EDI documents to transmitting via the Internet, some people equated the non-
Internet technologies with EDI and predicted erroneously that EDI itself would be replaced
along with the non-Internet technologies. These non-internet transmission methods are being
replaced by Internet Protocols such as FTP, telnet, and E-mail, but the EDI documents
themselves still remain.

As more trading partners use the Internet for transmission, standards have emerged. In 2002,
the IETF published RFC 3335, offering a standardized, secure method of transferring EDI
data via e-mail. On July 12, 2005, an IETF working group ratified RFC4130 for MIME-based
HTTP EDIINT (aka. AS2) transfers, and is preparing a similar RFC for FTP transfers (aka.
AS3). While some EDI transmission has moved to these newer protocols, the providers of the
value-added networks remain active.

EDI documents generally contain the same information that would normally be found in a
paper document used for the same organizational function. For example an EDI 940 ship-
from-warehouse order is used by a manufacturer to tell a warehouse to ship product to a
retailer. It typically has a ship to address, bill to address, a list of product numbers (usually a
UPC code) and quantities. It may have other information if the parties agree to include it.
However, EDI is not confined to just business data related to trade but encompasses all fields
such as medicine (e.g., patient records and laboratory results), transport (e.g., container and
modal information), engineering and construction, etc. In some cases, EDI will be used to
create a new business information flow (that was not a paper flow before). This is the case in
the Advanced Shipment Notification (856) which was designed to inform the receiver of a
shipment, the goods to be received and how the goods are packaged.

There are four major sets of EDI standards:

• The UN-recommended UN/EDIFACT is the only international standard and is

predominant outside of North America.
• The US standard ANSI ASC X12 (X12) is predominant in North America.
• The TRADACOMS standard developed by the ANA (Article Numbering
Association) is predominant in the UK retail industry.
• The ODETTE standard used within the European automotive industry

All of these standards first appeared in the early to mid1980s. The standards prescribe the
formats, character sets, and data elements used in the exchange of business documents and
forms. The complete X12 Document List includes all major business documents, including
purchase orders (called "ORDERS" in UN/EDIFACT and an "850" in X12) and invoices
(called "INVOIC" in UN/EDIFACT and an "810" in X12).

The EDI standard says which pieces of information are mandatory for a particular document,
which pieces are optional and give the rules for the structure of the document. The standards
are like building codes. Just as two kitchens can be built "to code" but look completely
different, two EDI documents can follow the same standard and contain different sets of
information. For example a food company may indicate a product's expiration date while a
clothing manufacturer would choose to send colour and size information.

Specifications

Organizations that send or receive documents between each other are referred to as "trading
partners" in EDI terminology. The trading partners agree on the specific information to be
transmitted and how it should be used. This is done in human readable specifications (also
called Message Implementation Guidelines). While the standards are analogous to building
codes, the specifications are analogous to blue prints. (The specification may also be called a
mapping but the term mapping is typically reserved for specific machine readable instructions
given to the translation software.) Larger trading "hubs" have existing Message
Implementation Guidelines which mirror their business processes for processing EDI and
they are usually unwilling to modify their EDI business practices to meet the needs of their
trading partners. Often in a large company these EDI guidelines will be written to be generic
enough to be used by different branches or divisions and therefore will contain information
not needed for a particular business document exchange. For other large companies, they may
create separate EDI guidelines for each branch/division.

Transmission

Trading partners are free to use any method for the transmission of documents. In the past
one of the more popular methods was the usage of a bisync modem to communicate through
a value added network (VAN). Some organizations have used direct modem to modem
connections and bulletin board systems (BBS), and recently there has been a move towards
using some of the many Internet protocols for transmission, but most EDI is still transmitted
using a VAN. In the healthcare industry, a VAN is referred to as a "clearinghouse".

Value-added networks

In the most basic form, a VAN (value-added network) acts as a regional post office. They
receive transactions, examine the 'from' and the 'to' information, and route the transaction to
the final recipient. VANs provide a number of additional services, e.g. retransmitting
documents, providing third party audit information, acting as a gateway for different
transmission methods, and handling telecommunications support. Because of these and other
services VANs provide, businesses frequently use a VAN even when both trading partners
are using Internet-based protocols. Healthcare clearinghouses perform many of the same
functions as a VAN, but have additional legal restrictions that govern protected healthcare
information.

VANs also provide an advantage with certificate replacement in AS2 transmissions. Because
each node in a traditionally business-related AS2 transmission usually involves a security
certificate, routing a large number of partners through a VAN can make certificate
replacement much easier. Value Added Networks

• Value Added Networks are the go-between in EDI communications.

• The VAN is responsible for routing, storing and delivering EDI messages. They also
provide delivery reports
• Depending on the VAN type, messages may need extra envelopes or may be routed
using intelligent *VANs which are able to read the EDI message itself.
• VANs may be operated by various entities

Telecom companies

• Industry group consortiums

• A large company interacting with its suppliers/vendors

Internet/AS2

Until recently, the Internet transmission was handled by nonstandard methods between
trading partners usually involving FTP or email attachments. There are also standards for
embedding EDI documents into XML. Many organizations are migrating to this protocol to
reduce costs. For example, Wal-Mart is now requiring its trading partners to switch to the
AS2 protocol (Wal-Mart EDI Requirement).
AS2 (Applicability Statement 2) is the draft specification standard by which vendor
applications communicate EDI or other business-to-business data (such as XML) over the
Internet using HTTP, a standard used by the World Wide Web. AS2 provides security for the
transport payload through digital signatures and data encryption, and ensures reliable, non-
repudiable delivery through the use of receipts.

EDI via the Internet (Web EDI)

The Internet, as with VAN providers, uses its own communications protocols to ensure that
EDI documents are transmitted securely. The most popular protocols are File Transfer
Protocol Secure (FTPS), Hyper Text Transfer Protocol Secure (HTTPS), and AS2.

The Internet has provided a means for any company, no matter how small or where they are
located in the world, to become part of a major supply chain initiative hosted by a global
retailer or manufacturing company. Many companies around the world have shifted
production of labour intensive parts to low-cost, emerging regions such as Brazil, Russia,
India, China, and Eastern Europe. Web-based EDI, or webEDI, allows a company to interact
with its suppliers in these regions without the worry of implementing a complex EDI
infrastructure.

In its simplest form, webEDI enables small to medium-sized businesses to receive, turn
around, create and manage electronic documents using just a web browser. This service
seamlessly transforms your data into EDI format and transmits it to your trading partner.
Simple pre-populated forms enable businesses to communicate and comply with their trading
partners' requirements using built-in business rules. Using a friendly web-based interface,
EDI transactions can be received, edited and sent as easily as an email. You will also be able
to receive EDI documents and send EDI invoices and shipping documents with no software
to install. All you require is an Internet connection. WebEDI has the added advantages that it
is accessible anywhere in the world and you do not need a dedicated IT person to manage any
software installation.

Even though VANs offer a very secure and reliable service to companies wishing to trade
electronically, the Internet is making EDI more available to all. This is especially important
in the emerging markets where IT awareness and infrastructure are very limited. WebEDI is
traditionally based on the “hub and spoke” model, with major trading partners or Application
Service Providers (ASPs) being the hubs and smaller partners being the spokes.

• Hubs or ASPs implement EDI using email or virtual mailboxes

• Trading partners can send EDI messages directly to a web-enabled EDI messaging
site, via the hub. EDI messages are simply sent using a web browser

• Systems that are currently being developed will enable EDI messages to be displayed
in a web browser and directed via open standard XML, directly into the user's
accounts system

• WebEDI-based users can interact with VANs without incurring the costs of setting up
a dedicated VAN connection
Interpreting data

Often missing from the EDI specifications (referred to as EDI Implementation Guidelines)
are real world descriptions of how the information should be interpreted by the business
receiving it. For example, suppose candy is packaged in a large box that contains 5 display
boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI
document says to ship 10 boxes of candy it may not be clear whether to ship 10 consumer
packaged boxes, 240 consumer packaged boxes or 1200 consumer packaged boxes. It is not
enough for two parties to agree to use a particular qualifier indicating case, pack, box or each;
they must also agree on what that particular qualifier means.

EDI translation software provides the interface between internal systems and the EDI format
sent/received. For an "inbound" document the EDI solution will receive the file (either via a
Value Added Network or directly using protocols such as FTP or AS2), take the received EDI
file (commonly referred to as a "mailbag"), validate that the trading partner who is sending
the file is a valid trading partner, that the structure of the file meets the EDI standards and
that the individual fields of information conforms to the agreed upon standards. Typically the
translator will either create a file of either fixed length, variable length or XML tagged format
or "print" the received EDI document (for non-integrated EDI environments). The next step is
to convert/transform the file that the translator creates into a format that can be imported into
a company's back-end business systems or ERP. This can be accomplished by using a custom
program, an integrated proprietary "mapper" or to use an integrated standards based graphical
"mapper" using a standard data transformation language such as XSLT. The final step is to
import the transformed file (or database) into the company's back-end enterprise resource
planning (ERP) system.

For an "outbound" document the process for integrated EDI is to export a file (or read a
database) from a company's back-end ERP, transform the file to the appropriate format for
the translator. The translation software will then "validate" the EDI file sent to ensure that it
meets the standard agreed upon by the trading partners, convert the file into "EDI" format
(adding in the appropriate identifiers and control structures) and send the file to the trading
partner (using the appropriate communications protocol).

Another critical component of any EDI translation software is a complete "audit" of all the
steps to move business documents between trading partners. The audit ensures that any
transaction (which in reality is a business document) can be tracked to ensure that they are
not lost. In case of a retailer sending a Purchase Order to a supplier, if the Purchase Order is
"lost" anywhere in the business process, the effect is devastating to both businesses. To the
supplier, they do not fulfill the order as they have not received it thereby losing business and
damaging the business relationship with their retail client. For the retailer, they have a stock
outage and the effect is lost sales, reduced customer service and ultimately lower profits.

In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an

EDI document in relation to a particular system, not the direction of merchandise, money or
other things represented by the document. For example, an EDI document that tells a
warehouse to perform an outbound shipment is an inbound document in relation to the
warehouse computer system. It is an outbound document in relation to the manufacturer or
dealer that transmitted the document.
Advantages of using EDI over paper systems

EDI and other similar technologies save a company money by providing an alternative to, or
replacing information flows that require a great deal of human interaction and materials such
as paper documents, meetings, faxes, etc. Even when paper documents are maintained in
parallel with EDI exchange, e.g. printed shipping manifests, electronic exchange and the use
of data from that exchange reduces the handling costs of sorting, distributing, organizing, and
searching paper documents. EDI and similar technologies allow a company to take advantage
of the benefits of storing and manipulating data electronically without the cost of manual
entry. Another advantage of EDI is reduced errors, such as shipping and billing errors,
because EDI eliminates the need to rekey documents on the destination side. One very
important advantage of EDI over paper documents is the speed in which the trading partner
receives and incorporates the information into their system thus greatly reducing cycle times.
For this reason, EDI can be an important component of just-in-time production systems.

According to the 2008 Aberdeen report "A Comparison of Supplier Enablement around the
World", only 34% of purchase orders are transmitted electronically in North America. In
EMEA, 36% of orders are transmitted electronically and in APAC, 41% of orders are
transmitted electronically. They also report that the average paper requisition to order costs a
company $37.45 in North America, $42.90 in EMEA and $23.90 in APAC. With an EDI
requisition to order costs are reduced to $23.83 in North America, $34.05 in EMEA and
$14.78 in APAC.

Barriers to implementation

There are a few barriers to adopting electronic data interchange. One of the most significant
barriers is the accompanying business process change. Existing business processes built
around slow paper handling may not be suited for EDI and would require changes to
accommodate automated processing of business documents. For example, a business may
receive the bulk of their goods by 1 or 2 day shipping and all of their invoices by mail. The
existing process may therefore assume that goods are typically received before the invoice.
With EDI, the invoice will typically be sent when the goods ship and will therefore require a
process that handles large numbers of invoices whose corresponding goods have not yet been
received.

Another significant barrier is the cost in time and money in the initial set-up. The preliminary
expenses and time that arise from the implementation, customization and training can be
costly and therefore may discourage some businesses. The key is to determine what method
of integration is right for the company which will determine the cost of implementation. For a
business that only receives one P.O. per year from a client, fully integrated EDI may not
make economic sense. In this case, businesses may implement inexpensive "rip and read"
solutions or use outsourced EDI solutions provided by EDI "Service Bureaus". For other
businesses, the implementation of an integrated EDI solution may be necessary as increases
in trading volumes brought on by EDI force them to re-implement their order processing
business processes.
The key hindrance to a successful implementation of EDI is the perception many businesses
have of the nature of EDI. Many view EDI from the technical perspective that EDI is a data
format; it would be more accurate to take the business view that EDI is a system for
exchanging business documents with external entities, and integrating the data from those
documents into the company's internal systems. Successful implementations of EDI take into
account the effect externally generated information will have on their internal systems and
validate the business information received. For example, allowing a supplier to update a
retailer's Accounts Payables system without appropriate checks and balances would be a
recipe for disaster. Businesses new to the implementation of EDI should take pains to avoid
such pitfalls.

Increased efficiency and cost savings drive the adoption of EDI for most trading partners. But
even if a company would not choose to use EDI on their own, pressures from larger trading
partners (called hubs) often force smaller trading partners to use EDI. An example of this is
Wal-Mart`s insistence on using EDI with all of its trading partners; any partner not willing to
use EDI with Wal-Mart will not be able to do business with the company.

Electronic money

Electronic money (also known as e-currency, e-money, electronic cash, electronic

currency, digital money, digital cash or digital currency) refers to money or scrip which is
only exchanged electronically. Typically, this involves the use of computer networks, the
internet and digital stored value systems. Electronic Funds Transfer (EFT) and direct deposit
are all examples of electronic money. Also, it is a collective term for financial cryptography
and technologies enabling it.

While electronic money has been an interesting problem for cryptography (see for example
the work of David Chaum and Markus Jakobsson), to date, the use of e-money has been
relatively low-scale. One rare success has been Hong Kong's Octopus card system, which
started as a transit payment system and has grown into a widely used electronic money
system. London Transport's Oyster card system remains essentially a contactless pre-paid
travelcard. Two other cities have implemented functioning electronic money systems. Very
similar to Hong Kong's Octopus card, Singapore has an electronic money program for its
public transportation system (commuter trains, bus, etc.), based on the same type of (FeliCa)
system. The Netherlands has also implemented an electronic money system known as
Chipknip, which is based upon the same system in Hong Kong..

A number of electronic money systems use Contactless payment transfer in order to facilitate
easy payment and give the payee more confidence in not letting go of their electronic wallet
during the transaction.

Electronic money systems

In technical terms, electronic money is an online representation, or a system of debits and

credits, used to exchange value within another system, or within itself as a standalone system.
In principle this process could also be done offline.

Occasionally, the term electronic money is also used to refer to the provider itself. A private
currency may use gold to provide extra security, such as digital gold currency. Some private
organizations, such as the United States armed forces use independent currencies such as
Eagle Cash.

Centralised systems

Many systems—such as Paypal, WebMoney, cashU, and Hub Culture's Ven—will sell their
electronic currency directly to the end user, but other systems only sell through third party
digital currency exchangers.

In the case of Octopus card in Hong Kong, electronic money deposits work similarly to
regular bank deposits. After Octopus Card Limited receives money for deposit from users,
the money is deposited into a bank. This is similar to debit-card-issuing banks redepositing
money at central banks.

Some community currencies, like some LETS systems, work with electronic transactions.

Decentralised systems

Decentralised electronic money systems include:

• Bitcoin, an anonymous distributed electronic money system

• Ripple monetary system, a project to develop a distributed system of electronic
money independent of local currency.
• PKTP, a pseudonymous distributed electronic money system

Offline 'anonymous' systems

In the use of offline electronic money, the merchant does not need to interact with the bank
before accepting money from the user. Instead merchants can collect monies spent by users
and deposit them later with the bank. In principle this could be done offline, i.e. the merchant
could go to the bank with his storage media to exchange e-money for cash. Nevertheless the
merchant is guaranteed that the user's e-money will either be accepted by the bank, or the
bank will be able to identify and punish the cheating user. In this way a user is prevented
from spending the same funds twice (double-spending). Offline e-money schemes also need
to protect against cheating merchants, i.e. merchants that want to deposit money twice (and
then blame the user).

Using cryptography, anonymous ecash was introduced by David Chaum. He used blind
signatures to achieve unlinkability between withdrawal and spend transactions.In
cryptography, e-cash usually refers to anonymous e-cash. Depending on the properties of the
payment transactions, one distinguishes between online and offline e-cash. The first offline e-
cash system was proposed by Chaum and Naor. Like the first on-line scheme, it is based on
RSA blind signatures.

Future progression

The main focuses of electronic money development are:

1. being able to use it through a wider range of hardware such as secured credit cards
 2. linked bank accounts that would generally be used over an internet means, for
exchange with a secure micropayment system such as in large corporations (PayPal).

Issues

Although electronic money can provide many benefits—such as convenience and privacy,
increased efficiency of transactions, lower transaction fees, and new business opportunities
with the expansion of economic activities on the Internet—there are many potential issues
with the use of e-money. The transfer of digital currencies raises local issues such as how to
levy taxes or the possible ease of money laundering. There are also potential macro-economic
effects such as exchange rate instabilities and shortage of money supplies (total amount of
electronic money versus the total amount of real money available, basically the possibility
that digital cash could exceed the real cash available).

Another issue is related to computer crime, in which computer criminals may actually alter
computer databases to steal electronic money or by reducing an account's amount of
electronic money. One way to resolve these issues is by implementing cyberspace regulations
or laws that regulate the transactions and watch for signs of fraud or deceit.

As recently discussed by several scientists and economists a society highly dependent on

electronic money could make the whole monetary system vulnerable towards massive solar
storms equivalent to for example the Carrington event of 1859.

Payment service provider

A payment service provider (PSP) offers merchants online services for accepting electronic
payments by a variety of payment methods including credit card, bank-based payments such
as direct debit, bank transfer, and real-time bank transfer based on online banking. Some
PSPs provide unique services to process other next generation methods (Payment systems)
including cash payments, wallets such as PayPal, prepaid cards or vouchers, and even paper
or e-check processing.

Typically, a PSP can connect to multiple acquiring banks, card, and payment networks. In
many cases, the PSP will fully manage these technical connections, relationships with the
external network, and bank accounts. This makes the merchant less dependent on financial
institutions and free from the task of establishing these connections directly - especially when
operating internationally.

Furthermore, a full service PSP can offer risk management services for card and bank based
payments, transaction payment matching, reporting, fund remittance and fraud protection in
addition to multi-currency functionality and services.

PSP fees are typically levied in one of two ways: as a percentage of each transaction or a low
fixed cost per transaction.

US-based on-line payment service providers are supervised by the Financial Crimes
Enforcement Network (or FinCEN), a bureau of the United States Department of the
Treasury that collects and analyzes information about financial transactions in order to
combat money laundering, terrorist financiers, and other financial crimes.
List of on-line payment service providers

The following is a list of on-line payment service providers:

• Adyen
• Beenz
• Buckaroo Online Payment Services
• CreditCall
• CyberBucks (of DigiCash),
• eCash
• Elavon
• Envoy Services Ltd
• Flooz
• HSBC
• iCheckGateway.com
• iKobo
• Mollie
• Mondex
• Moneybookers
• Ouroboros
• Pago
• PayPal
• PayPoint.net
• PayXpert
• Peppercoin
• RBS WorldPay
• UGS
• WebMoney

The following is a brief study about PayPal:

PayPal

PayPal is an e-commerce business allowing payments and money transfers to be made

through the Internet. PayPal serves as an electronic alternative to traditional paper methods
such as checks and money orders.

A PayPal account can be funded with an electronic debit from a bank account or by a credit
card. The recipient of a PayPal transfer can either request a check from PayPal, establish their
own PayPal deposit account or request a transfer to their bank account. PayPal is an example
of a payment intermediary service that facilitates worldwide e-commerce.

PayPal performs payment processing for online vendors, auction sites, and other commercial
users, for which it charges a fee. It sometimes also charges a transaction fee for receiving
money (a percentage of the amount sent plus an additional fixed amount). The fees charged
depend on the currency used, the payment option used, the country of the sender, the country
of the recipient, the amount sent and the recipient's account type. In addition, eBay purchases
made by credit card through PayPal may incur a "foreign transaction fee" if the seller is
located in another country, as credit card issuers are automatically informed of the seller's
country of origin.
On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its corporate
headquarters are in San Jose, California, United States at eBay's North First Street satellite
office campus. The company also has significant operations in Omaha, Nebraska; Scottsdale,
Arizona; and Austin, Texas in the U.S., Chennai, Dublin, Berlin and Tel-Aviv. As of July
2007, across Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), China's
bankcard association, to allow Chinese consumers to use PayPal to shop online.PayPal is
planning to expand its workforce in Asia to 2,000 by the end of the year 2010.

History

Beginnings

The current incarnation of PayPal is the result of a March 2000 merger between Confinity
and X.com. Confinity was founded in December 1998 by Max Levchin, Peter Thiel, Luke
Nosek, and Ken Howery, initially as a Palm Pilot payments and cryptography company.
X.com was founded by Elon Musk in March 1999, initially as an Internet financial services
company. Both Confinity and X.com launched their websites in late 1999. Both companies
were located on University Avenue in Palo Alto. Confinity's website was initially focused on
reconciling beamed payments from Palm Pilots with email payments as a feature and X.com's
website initially featured financial services with email payments as a feature.

At Confinity, many of the initial recruits were alumni of The Stanford Review, also founded
by Peter Thiel, and most early engineers hailed from the University of Illinois at Urbana-
Champaign, recruited by Max Levchin. On the X.com side, Elon Musk recruited a wide range
of technical and business personnel, including many that were critical to the combined
company's success, such as Amy Klement, Sal Giambanco, Roelof Botha of Sequoia Capital,
Sanjay Bhargava and Jeremy Stoppelman.

To block potentially fraudulent access by automated systems, PayPal used a system (see
CAPTCHA) of making the user enter numbers from a blurry picture, which they coined the
Gausebeck-Levchin test.

eBay watched the rise in volume of its online payments and realized the fit of an online
payment system with online auctions. eBay purchased Billpoint in May 1999, prior to the
existence of PayPal. eBay made Billpoint its official payment system, dubbing it "eBay
Payments," but cut the functionality of Billpoint by narrowing it to only payments made for
eBay auctions. For this reason, PayPal was listed in many more auctions than Billpoint. In
February 2000, the PayPal service had an average of approximately 200,000 daily auctions
while Billpoint (in beta) had only 4,000 auctions. By April 2000, more than 1,000,000
auctions promoted the PayPal service. PayPal was able to turn the corner and become the first
dot-com to IPO after the September 11 attacks.

Acquisition by eBay

In October 2002, PayPal was acquired by eBay for $1.5 billion. PayPal had previously been
the payment method of choice by more than fifty percent of eBay users, and the service
competed with eBay's subsidiary Billpoint, Citibank's c2it, whose service was closed in late
2003, and Yahoo!'s PayDirect, whose service was closed in late 2004. Western Union
announced the December 2005 shut down of their BidPay service but subsequently sold it in
2006 to CyberSource Corporation. BidPay subsequently ceased operations on December 31,
2007. Some competitors which offer some of PayPal's services, such as Google Checkout,
Wirecard, Moneybookers, 2Checkout.com, CCNow and Kagi, remain in business, despite the
fact that eBay now requires everyone on its Australian and United Kingdom sites to offer
PayPal. Eventually eBay moderated its position, and mandated that sellers on eBay Australia
offer PayPal as one of the (but not necessarily the only) payment methods. These accepted
payment methods include bank deposit, cheques and money orders, escrow, and credit cards
(processed by other than PayPal).

In January 2008, PayPal agreed to acquire Fraud Sciences, a privately-held Israeli start-up
company with expertise in online risk tools, for $169 million, in order to enhance eBay and
PayPal's proprietary fraud management systems and accelerate the development of improved
fraud detection tools. In November 2008, the company acquired Bill Me Later, an online
payments company offering transactional credit at over 1000 online merchants in the US.

PayPal's total payment volume, the total value of transactions, was US$ 60 billion in 2008, an
increase of 27 percent over the previous year, and US$ 71 billion in 2009, an increase of 19
percent over the previous year. The company continues to focus on international growth and
growth of its Merchant Services division, providing e-payments for retailers off eBay.

Business today

Currently, PayPal operates in 190 markets, and it manages over 223 million accounts, more
than 73 million of them active. PayPal allows customers to send, receive, and hold funds in
19 currencies worldwide. These currencies are the Australian dollar, Brazilian real, Canadian
dollar, Chinese renminbi yuan (only available for some Chinese accounts, see below), Euro,
pound sterling, Japanese yen, Czech koruna, Danish krone, Hong Kong dollar, Hungarian
forint, Israeli new sheqel, Mexican peso, New Zealand dollar, Norwegian krone, Polish zloty,
Singapore dollar, Swedish krona, Swiss franc and U.S. dollar. PayPal operates locally in 13
countries.

Residents in 194 markets can use PayPal in their local markets to send money online. PayPal
revenues for Q1 2009 were $643 million, up 11 percent year over year. 42 percent of
revenues in q1 2009 were from international markets. PayPal's Total Payment Volume
(TPV), the total value of transactions in Q1 2009 was nearly $16 billion, up 10 percent year
over year.

In 2008, PayPal's TPV off eBay exceeded volume on eBay for the first time. PayPal's Total
Payment Volume in 2008 was $60 billion representing nearly 9 percent of global e-commerce
and 15 percent of US e-commerce.

At an analyst day on March 11, 2009, eBay CEO, John Donahoe announced that PayPal
could be a larger driver of revenue than the eBay marketplaces business. RIM announced that
PayPal will be the only payment mechanism for its Blackberry App World, which launched
on April 1, 2009.

In November 2009 PayPal opened its platform, allowing other services to get access to its
code and to use its infrastructure in order to enable peer-to-peer online transactions.
Although PayPal's corporate headquarters are located in San Jose, PayPal's operations center
is located near Omaha, Nebraska, where the company employs more than 2,000 people as of
2007. PayPal's European headquarters are in Luxembourg and international headquarters in
Singapore. The company also recently opened a technology center in Scottsdale, Arizona,
and Chennai India.

Bank status

In the United States, PayPal is licensed as a money transmitter on a state-by-state basis.

PayPal is not classified as a bank in the United States, though the company is subject to some
of the rules and regulations governing the financial industry including Regulation E
consumer protections and the USA PATRIOT Act.

Commencing 2 July 2007, as PayPal (Europe) S.à r.l. & Cie, S.C.A., PayPal moved its
European operations from the UK to Luxembourg. As a Luxembourg entity, it is since
regulated as a bank by the Commission de Surveillance du Secteur Financier (CSSF) and
provides PayPal service throughout the European Union.

Safety and protection policies

The PayPal Buyer Protection Policy states that the customer may file a buyer complaint
within 45 days if he did not receive an item or if the item they purchased was significantly
not as described. If the buyer used a credit card, he might get a refund via chargeback from
his credit-card company.

According to PayPal, it protects sellers in a limited fashion via the Seller Protection Policy. In
general the Seller Protection Policy is intended to protect the seller from certain kinds of
chargebacks or complaints if seller meets certain conditions including proof of delivery to the
buyer. PayPal states the Seller Protection Policy is "designed to protect sellers against claims
by buyers of unauthorized payments and against claims of non-receipt of any merchandise".
The policy includes a list of "Exclusions" which itself includes "Intangible goods", "Claims
for receipt of goods 'not as described'" and "Total reversals over the annual limit". There are
also other restrictions in terms of the sale itself, the payment method and the destination
country the item is shipped to (simply having a tracking mechanism is not sufficient to
guarantee the Seller Protection Policy is in effect).

Security

Security key

In early 2006, PayPal introduced an optional security key as an additional precaution against
fraud. A user account tied to a security key has a modified login process: the account holder
enters their login ID and password, as normal, but is then prompted to press the button on the
security key and enter the six-digit number generated by it. This two-factor authentication is
intended to prevent an account from being compromised by a malicious third party without
access to the physical security key. However, the user (or malicious third party) can
alternatively authenticate by providing the credit card or bank account number listed on their
account. Thus, the PayPal's implementation does not offer the security of true two-factor
authentication.
The key currently costs US$5.00 for all users with no ongoing fees. The option of using a
security key with one's account is currently available only to users registered in Australia,
Germany, Canada, the United Kingdom and the United States.

MTAN

It is also possible to use a mobile phone to receive an MTAN (Mobile Transaction

Authentication Number) via SMS. Like all security measures, there have been reports of
vulnerabilities to older mobile handsets.

Regulation

In Europe, PayPal is registered as a bank in Luxembourg under the legal name PayPal
(Europe) Sàrl et Cie SCA, a company regulated centrally by the Luxembourg bank authority,
the Commission de Surveillance du Secteur Financier (CSSF). Prior to this move, PayPal had
been registered in the UK as Paypal (Europe) Ltd, an entity which was licensed as an
Electronic Money Issuer with the UK's Financial Services Authority (FSA) from 2004. This
ceased in 2007, when the company moved to Luxembourg.

In the US, although PayPal has an extensive User Agreement, PayPal is not directly regulated
by the U.S. federal government, because it serves as a payment intermediary. The law is
unclear as to whether PayPal is a bank, narrow bank, money services business or money
transmitter. PayPal could also be subject to state regulation, but state laws vary, as do their
definitions of banks, narrow banks, money services businesses and money transmitters. The
most analogous regulatory source of law for PayPal transactions comes from P2P payments
using credit and debit cards. Ordinarily, a credit card transaction, specifically the relationship
between the issuing bank and the cardholder, is governed by the Truth in Lending Act (TILA)
15 U.S.C. §§ 1601-1667f as implemented by Regulation Z, 12 C.F.R. pt. 226, (TILA/Z).
TILA/Z requires specific procedures for billing errors, dispute resolution and limits
cardholder liability for unauthorized charges. Similarly, the legal relationship between a debit
cardholder and the issuing bank is regulated by the Electronic Funds Transfer Act (EFTA) 15
U.S.C. §§ 1693-1693r, as implemented by Regulation E, 12 C.F.R. pr. 205, (EFTA/E).
EFTA/E is directed at consumer protection and provides strict error resolution procedures.
However, because PayPal is a payment intermediary and not otherwise regulated directly,
TILA/Z and EFTA/E do not operate exactly as written once the credit/debit card transaction
occurs via PayPal. Basically, unless a PayPal transaction is funded with a credit card, the
consumer has no recourse in the event of fraud by the seller.

In India, as of January 27, 2010, PayPal has no cross-border money transfer authorization.
The New York Times article "India’s Central Bank Stops Some PayPal Services" Reserve
Bank of India spokesman Alpana Killawalla stated, "Providers of cross-border money
transfer service need prior authorization from the Reserve Bank under the Payment and
Settlement Systems Act, PayPal does not have our authorization." PayPal is not listed in the
"Certificates of Authorisation issued by the Reserve Bank of India under the Payment and
Settlement Systems Act, 2007 for Setting up and Operating Payment System in India".

Criticism and limitations

The current PayPal user agreement is 25 pages long. If you buy an item from a PayPal
merchant, you are agreeing to an additional layer of arbitration beyond the merchant himself.
Thus even if the merchant rips you off, PayPal has not violated their own policy until you
have gone through an extra arbitration process with PayPal. Only when PayPal fails to
arbitrate according to their 25-page user agreement can you then go through the normal
dispute resolution with your credit card. In other words, you are making a contract with
PayPal under a 25-page policy, not the simple 1-page policy you'd expect from any reputable
merchant.

In September 2005, Richard Kyanka, owner of the website Something Awful, set up an
account to collect donations for Hurricane Katrina to be given to the Red Cross. Owing to the
high rate at which donations were made, the account was automatically frozen, and Kyanka
criticized the time and difficulty involved in getting PayPal's customer service to unfreeze the
account. In response to the concerns of Something Awful members over the charity used by
PayPal, United Way, Kyanka finally opted to have the money refunded to the donors so that
they could donate directly to their charities of choice, though PayPal did not refund exchange
and handling fees for international donors.

In March 2008, Australian current affairs show Today Tonight aired a segment criticising
PayPal, with regard to safety, freezing accounts and customer service.

Several PayPal gripe sites have been created complaining of problems such as the freezing of
accounts of eCommerce stores if they experience rapid growth, preventing them from being
able to pay suppliers and fulfill orders. One such site, Paypalsucks.com, ranked third on a
Forbes Magazine listing of "Top Corporate Hate Web Sites" in 2005 based on "hostility" and
"entertainment value" of web forum postings and other criteria.

In June 2008, the Australian Competition and Consumer Commission found that, "The
evidence available does not support the view that PayPal is the most secure method of
payment, or offers the best service for all transactions."

In February 2010, Paypal stopped or reversed all "personal" transactions in or out of India
without prior notice. Funds already transferred and transactions that had previously been
"completed" were reversed leaving many vendor accounts over-drafted. Companies,
contractors and service providers throughout India were left in debt to Paypal for services
they had already provided when Paypal, without warning or consent, returned funds vendors
had already received and withdrawn.

In spite of its international reach, Paypal has limited functionalites for multi-country users,
most notably the impossibility to have bank accounts in several countries, or to have a
shipping address in a different country than one's bank account / credit card.

In March 2010, Paypal froze donations to Cryptome, seizing over $5300 of in-transit
donations. PayPal refused to inform Cryptome of the reason for this action, claiming that to
disclose why the donations had been confiscated would violate Cryptome's own privacy. A
week later, PayPal offered an apology, which was rejected by Cryptome founder John Young
as "insulting and unacceptable".

In August 2010, PayPal froze the account of Markus Persson, developer of independent video
game Minecraft. His account contained around €600,000.
In September 2010, PayPal froze the account of the open-source revision control software
TortoiseSVN The lead developer compared the situation to a car shop that "decides not to do
business with you anymore. ... But then the shop owner tells you that they keep your car for
half a year first because that's their policy."

3-D Secure

3-D Secure is an XML-based protocol used as an added layer of security for online credit and
debit card transactions. It was developed by Visa to improve the security of Internet
payments and offered to customers as the Verified by Visa service. Services based on the
protocol have also been adopted by MasterCard, under the name MasterCard SecureCode,
and by JCB International as J/Secure.

3-D Secure adds another authentication step for online payments.

3-D Secure should not be confused with the Card Security Code which is a short numeric
code that is printed on the card.

Description and basic aspects of the protocol

The basic concept of the protocol is to tie the financial authorization process with an online
authentication. This authentication is based on a three domain model (hence the 3-D in the
name). The three domains are:

• Acquirer Domain (the merchant and the bank to which money is being paid).
• Issuer Domain (the bank which issued the card being used).
• Interoperability Domain (the infrastructure provided by the credit card scheme to
support the 3-D Secure protocol).

The protocol uses XML messages sent over SSL connections with client authentication (this
ensures the authenticity of both peers, the server and the client, using digital certificates).

A transaction using Verified by Visa/SecureCode will initiate a redirect to the website of the
card issuing bank to authorize the transaction. Each issuer could use any kind of
authentication method (the protocol does not cover this) but typically, a password-based
method is used, so to effectively buy on the Internet means using a secret password tied to the
card. The Verified by Visa protocol recommends the bank's verification page to load in an
inline frame session. In this way, the bank's systems can be held responsible for most security
breaches.

The main difference between Visa and MasterCard implementations resides in the method to
generate the AAV (Accountholder Authentication Value): MasterCard uses UCAF (Universal
Cardholder Authentication Field) and Visa uses CAVV (Cardholder Authentication
Verification Value).

Implementing the protocol

The specifications are currently at version 1.0.2. Previous versions 0.7 (only used by Visa
USA) and 1.0.1 have become redundant and are no longer supported. MasterCard and JCB
have adopted version 1.0.2 of the protocol only.
In order for a Visa or MasterCard member bank to use the service, the bank has to operate
compliant software that supports the latest protocol specifications. Once compliant software
is installed, the member bank will perform product integration testing with the payment
system server before it rolls out the system.

ACS providers

In 3-D Secure protocol, ACS (Access Control Server) is on the issuer side (banks). Currently,
most banks outsource ACS to a third party. This means the buyer's web browser shows
unfamiliar domain names instead of the banks' domain names.RJ

MPI providers

Each 3-D secure transaction involves two simple internet request/response pairs:
VEReq/VERes and PAReq/PARes. Visa and MasterCard don't license merchants for sending
requests to their servers. They isolate their servers by licensing software providers which are
called MPI (merchant plug-in) providers.

Merchants

The advantage for merchants is the reduction of "unauthorized transaction" chargebacks. The
disadvantage for merchants is that they have to purchase MPI to connect to the
Visa/MasterCard Directory Server. This is expensive (setup fee, monthly fee and per-
transaction fee); at the same time it represents additional revenue for MPI providers.
Supporting 3-D Secure is complicated and, at times, creates transaction failures.

Buyers/credit card holders

The main advantage for cardholders is that there is a decreased risk of other people being able
to use their payment cards fraudulently on the Internet.

In most current implementations of 3-D Secure, the issuing bank or its ACS provider prompts
the buyer for a password that is known only to the bank/ACS provider and the buyer. Since
the merchant does not know this password and is not responsible for capturing it, it can be
used by the issuing bank as evidence that the purchaser is indeed their cardholder. This
decreases risk in two ways:

1. Copying card details, either by writing down the numbers on the card itself or by way
of modified terminals or ATMs, does not result in the ability to purchase over the
Internet because of the additional password, which is not stored on or written on the
card.
2. Since the merchant does not capture the password, there is a reduced risk from
security incidents at online merchants; while an incident may still result in hackers
obtaining other card details, there is no way for them to get the associated password.

In spite of the prevalence of password-based implementations, 3-D Secure does not require
the use of password authentication, and it is perfectly possible to use it in conjunction with
smart card readers, security tokens and the like. These types of devices may provide a better
user experience for customers as they free the purchaser from having to use a secure
password. Some issuers are now using such devices as part of the Chip Authentication
Program or Dynamic Passcode Authentication schemes.

One significant disadvantage is that cardholders may see their browser connect to unfamiliar
domain names as a result of some vendors' MPI implementations and the use of outsourced
ACS implementations by issuing banks, which may make it easier to perform phishing
attacks on cardholders.

Criticism

Verifiability of site identity

The system involves a pop-up window appearing during the online transaction process,
requiring the cardholder to enter a pre-agreed password which their card issuing bank will be
able to authenticate. The problem for the cardholder is determining if this pop-up window is
really from "your bank" - or could perhaps be from a fraudulent website attempting to harvest
your card details. Many of these pop-up windows have access to the security certificate
missing - eliminating a way to confirm who is at the other end of that window.

The 3-D secure ends up in some cases providing little security to the cardholder, and can act
as a device to pass liability for fraudulent transactions from the bank/retailer to the
cardholder. This is because the legal conditions applying to the 3-D secure service are
sometimes worded to make it more difficult for the cardholder to escape liability for
fraudulent cardholder not present transactions.

The "Verified by Visa" system has drawn some criticism, since it is hard for users to
differentiate between the legitimate Verified by Visa pop-up window or inline frame, and a
fraudulent phishing site. This is because the pop-up window is served from a domain which
is:

• Not the site where the user is shopping.

• Not the card issuing bank
• Not visa.com or mastercard.com

Indeed, the Verified by Visa system has been mistaken by users for a phishing scam and has
itself become the target of some phishing scams. The newer recommendation to use an inline
frame (IFrame) instead of a popup has reduced user confusion, but at the cost of making it
harder for the user to verify that the page is genuine in the first place—as of 2010, most web
browsers do not provide a simple way to check the security certificate for the contents of an
iframe.

Some card issuers also use Activation During Shopping (ADS), in which cardholders who are
not registered with the scheme are offered the opportunity of signing up (or forced into
signing up) during the purchase process. This will typically take them to a form in which they
are expected to confirm their identity by answering security questions which should be
known to their card issuer. Again, this is done within the iframe where they cannot easily
verify the site they are providing this information to—a cracked site or illegitimate merchant
could in this way gather all the details they need to pose as the customer.
Cardholders who are not willing to take the risk of registering their card during a purchase,
with the commerce site controlling the browser to some extent, can instead go to their bank's
home page on the web in a separate browser window and register from there. When they go
back to the commerce site and start over they should see that their card is registered. The
presence on the password page of the Personal Assurance Message (PAM) that they chose
when registering is their confirmation that the page is coming from the bank. This still leaves
some possibility of a man-in-the-middle attack if the card holder cannot verify the SSL
Server Certificate for the password page. Some commerce sites will devote the full browser
page to the authentication rather than using a frame (not necessarily an iFrame, which is a
less secure object anyway). In this case the lock icon in the browser should show the identity
of either the bank or the operator of the verification site. The cardholder can confirm that this
is in the same domain that they visited when registering their card, if it is not the domain of
their bank.

Mobile browsers present particular problems for 3-D Secure, due to the common lack of
certain features such as frames and pop-ups. Even if the merchant has a mobile Web site,
unless the issuer is also mobile aware, the authentication pages may fail to render properly, or
even at all.

Secure Electronic Transaction

Secure Electronic Transaction (SET) was a standard protocol for securing credit card
transactions over insecure networks, specifically, the Internet. SET was not itself a payment
system, but rather a set of security protocols and formats that enable users to employ the
existing credit card payment infrastructure on an open network in a secure fashion. However,
it failed to gain traction. VISA now promotes the 3-D Secure scheme.

SET was developed by SETco, led by VISA and MasterCard (and involving other companies
such as GTE, IBM, Microsoft, Netscape, RSA and VeriSign) starting in 1996. SET was based
on X.509 certificates with several extensions. The first version was finalised in May 1997 and
a pilot test was announced in July 1998.

SET allowed parties to cryptographically identify themselves to each other and exchange
information securely. SET used a blinding algorithm that, in effect, would have let merchants
substitute a certificate for a user's credit-card number. If SET were used, the merchant itself
would never have had to know the credit-card numbers being sent from the buyer, which
would have provided verified good payment but protected customers and credit companies
from fraud.

SET was intended to become the de facto standard of payment method on the Internet
between the merchants, the buyers, and the credit-card companies. Despite heavy publicity, it
failed to win market share. Reasons for this include:

• Network effect - need to install client software (an e-wallet).

• Cost and complexity for merchants to offer support and comparatively low cost and
simplicity of the existing SSL based alternative.
• Client-side certificate distribution logistics.

Key features
To meet the business requirements, SET incorporates the following features:

• Confidentiality of information
• Integrity of data
• Cardholder account authentication
• Merchant authentication

Participants

A SET system includes the following participants:

• Cardholder
• Merchant
• Issuer
• Acquirer
• Payment gateway
• Certification authority

Transaction

The sequence of events required for a transaction are as follows:

1. The customer obtains a credit card account with a bank that supports electronic
payment and SET
2. The customer receives a X.509v3 digital certificate signed by the bank.
3. Merchants have their own certificates
4. The customer places an order
5. The merchant sends a copy of its certificate so that the customer can verify that it's a
valid store
6. The order and payment are sent
7. The merchant requests payment authorization
8. The merchant confirms the order
9. The merchant ships the goods or provides the service to the customer
10. The merchant requests payment

Dual signature

An important innovation introduced in SET is the dual signature. The purpose of the dual
signature is the same as the standard electronic signature: to guarantee the authentication and
integrity of data. It links two messages that are intended for two different recipients. In this
case, the customer wants to send the order information (OI) to the merchant and the payment
information (PI) to the bank. The merchant does not need to know the customer's credit card
number, and the bank does not need to know the details of the customer's order. The link is
needed so that the customer can prove that the payment is intended for this order.

The message digest (MD) of the OI and the PI are independently calculated by the customer.
The dual signature is the encrypted MD (with the customer's secret key) of the concatenated
MD's of PI and OI. The dual signature is sent to both the merchant and the bank. The
protocol arranges for the merchant to see the MD of the PI without seeing the PI itself, and
the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using
the MD of the OI or PI. It doesn't require the OI or PI itself. Its MD does not reveal the
content of the OI or PI, and thus privacy is preserved.

Payment gateway

A payment gateway is an e-commerce application service provider service that authorizes

payments for e-businesses, online retailers, bricks and clicks, or traditional brick and mortar.
It is the equivalent of a physical point of sale terminal located in most retail outlets. Payment
gateways protect credit card details by encrypting sensitive information, such as credit card
numbers, to ensure that information is passed securely between the customer and the
merchant and also between merchant and the payment processor.

How payment gateways work

A payment gateway facilitates the transfer of information between a payment portal (such as
a website, mobile phone or IVR service) and the Front End Processor or acquiring bank.
When a customer orders a product from a payment gateway-enabled merchant, the payment
gateway performs a variety of tasks to process the transaction:

• A customer places order on website by pressing the 'Submit Order' or equivalent

button, or perhaps enters their card details using an automatic phone answering
service.
• If the order is via a website, the customer's web browser encrypts the information to
be sent between the browser and the merchant's webserver. This is done via SSL
(Secure Socket Layer) encryption.
• The merchant then forwards the transaction details to their payment gateway. This is
another SSL encrypted connection to the payment server hosted by the payment
gateway.
• The payment gateway forwards the transaction information to the payment processor
used by the merchant's acquiring bank.
• The payment processor forwards the transaction information to the card association
(i.e., Visa/MasterCard)
• If an American Express or Discover Card was used, then the processor acts as the
issuing bank and directly provides a response of approved or declined to the payment
gateway.
• Otherwise, the card association routes the transaction to the correct card issuing bank.
• The credit card issuing bank receives the authorization request and sends a response
back to the processor (via the same process as the request for authorization) with a
response code. In addition to determining the fate of the payment, (i.e. approved or
declined) the response code is used to define the reason why the transaction failed
(such as insufficient funds, or bank link not available)
• The processor forwards the response to the payment gateway.
• The payment gateway receives the response, and forwards it on to the website (or
whatever interface was used to process the payment) where it is interpreted as a
relevant response then relayed back to the cardholder and the merchant.
• The entire process typically takes 2–3 seconds
 • The merchant submits all their approved authorizations, in a "batch", to their
acquiring bank for settlement.
• The acquiring bank deposits the total of the approved funds in to the merchant's
nominated account. This could be an account with the acquiring bank if the merchant
does their banking with the same bank, or an account with another bank.
• The entire process from authorization to settlement to funding typically takes 3 days.

Many payment gateways also provide tools to automatically screen orders for fraud and
calculate tax in real time prior to the authorization request being sent to the processor. Tools
to detect fraud include geolocation, velocity pattern analysis, delivery address verification,
computer finger printing technology, identity morphing detection, and basic AVS checks.

Security

• Since the customer is usually required to enter personal details, the entire
communication of 'Submit Order' page (i.e. customer - payment gateway) is carried
out through HTTPS protocol.
• To validate the request of the payment page result, signed request is often used -
which is the result of the hash function in which the parameters of an application
confirmed by a «secret word», known only to the merchant and payment gateway.
• To validate the request of the payment page result, sometimes IP of the requesting
server has to be verified.
• There is a growing support by acquirers, issuers and subsequently by payments
gateways for Virtual Payer Authentication (VPA), implemented as 3-D Secure
protocol - branded as Verified by VISA, MasterCard SecureCode and J/Secure by
JCB, which adds additional layer of security for online payments. 3-D Secure
promises to alleviate some of the problems facing online merchants, like the inherent
distance between the seller and the buyer, and the inability of the first to easily
confirm the identity of the second.

Certificate authority

In cryptography, a certificate authority or certification authority (CA) is an entity that

issues digital certificates. The digital certificate certifies the ownership of a public key by the
named subject of the certificate. This allows others (relying parties) to rely upon signatures or
assertions made by the private key that corresponds to the public key that is certified. In this
model of trust relationships, a CA is a trusted third party that is trusted by both the subject
(owner) of the certificate and the party relying upon the certificate. CAs are characteristic of
many public key infrastructure (PKI) schemes.

Commercial CAs charge to issue certificates that will automatically be trusted by most web
browsers (Mozilla maintains a list of at least 36 trusted root CAs, though multiple
commercial CAs or their resellers may share the same trusted root). The number of web
browsers and other devices and applications that trust a particular certificate authority is
referred to as ubiquity.

Aside from commercial CAs, some providers issue digital certificates to the public at no cost.
Large institutions or government entities may have their own CAs.

Issuing a certificate
A CA issues digital certificates that contain a public key and the identity of the owner. The
matching private key is not similarly made available publicly, but kept secret by the end user
who generated the key pair. The certificate is also a confirmation or validation by the CA that
the public key contained in the certificate belongs to the person, organization, server or other
entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's
credentials, so that users and relying parties can trust the information in the CA's certificates.
CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is
responsible for saying "yes, this person is who they say they are, and we, the CA, verify that".

If the user trusts the CA and can verify the CA's signature, then he can also verify that a
certain public key does indeed belong to whoever is identified in the certificate.

Subversion of CA

If the CA can be subverted, then the security of the entire system is lost for each user for
whom the CA is attesting a link between a public key and an identity.

For example, suppose an attacker, Eve, manages to get a CA to issue to her a certificate that
claims to represent Alice. That is, the certificate would publicly state that it represents Alice,
and might include other information about Alice. Some of the information about Alice, such
as her employer name, might be true, increasing the certificate's credibility. Eve, however,
would have the all-important private key associated with the certificate. Eve could then use
the certificate to send digitally signed email to Bob, tricking Bob into believing that the email
was from Alice. Bob might even respond with encrypted email, believing that it could only
be read by Alice, when Eve is actually able to decrypt it using the private key.

A notable case of CA subversion like this occurred in 2001, when the certificate authority
VeriSign issued two certificates to a person claiming to represent Microsoft. The certificates
have the name "Microsoft Corporation", so could be used to spoof someone into believing
that updates to Microsoft software came from Microsoft when they actually did not. The
fraud was detected in early 2001. Microsoft and VeriSign took steps to limit the impact of the
problem.

Security

The problem of assuring correctness of match between data and entity when the data are
presented to the CA (perhaps over an electronic network), and when the credentials of the
person/company/program asking for a certificate are likewise presented, is difficult. This is
why commercial CAs often use a combination of authentication techniques including
leveraging government bureaus, the payment infrastructure, third parties' databases and
services, and custom heuristics. In some enterprise systems, local forms of authentication
such as Kerberos can be used to obtain a certificate which can in turn be used by external
relying parties. Notaries are required in some cases to personally know the party whose
signature is being notarized; this is a higher standard than is reached by many CAs.
According to the American Bar Association outline on Online Transaction Management the
primary points of US Federal and State statutes enacted regarding digital signatures has been
to "prevent conflicting and overly burdensome local regulation and to establish that electronic
writings satisfy the traditional requirements associated with paper documents." Further the
US E-Sign statute and the suggested UETA code help ensure that:
 1. a signature, contract or other record relating to such transaction may not be denied
legal effect, validity, or enforceability solely because it is in electronic form; and
2. a contract relating to such transaction may not be denied legal effect, validity or
enforceability solely because an electronic signature or electronic record was used in
its formation.

In large-scale deployments, Alice may not be familiar with Bob's certificate authority
(perhaps they each have a different CA server), so Bob's certificate may also include his CA's
public key signed by a different CA2, which is presumably recognizable by Alice. This
process typically leads to a hierarchy or mesh of CAs and CA certificates.

Providers

Worldwide, the certificate authority business is fragmented, with national or regional

providers dominating their home market. This is because many uses of digital certificates,
such as for legally binding digital signatures, are linked to local law, regulations, and
accreditation schemes for certificate authorities.

However, the market for SSL certificates, a kind of certificate used for website security, is
largely held by a small number of multinational companies. This market has significant
barriers to entry since new providers must undergo annual security audits (such as WebTrust
for Certification Authorities) to be included in the list of web browser trusted authorities.
More than 50 root certificates are trusted in the most popular web browser versions. A 2009
market share report from Net Craft as of January of that year determined that VeriSign and its
acquisitions (which include Thawte and Geotrust) have a 47.5% share of the certificate
authority market, followed by GoDaddy (23.4%), and Comodo (15.44%).

Open source implementations

There exist several open source implementations of certificate authority software. Common
to all is that they provide the necessary services to issue, revoke and manage digital
certificates.

Some well known open source implementations are:

• EJBCA
• OpenCA
• OpenSSL, which is really an SSL/TLS library, but comes with tools allowing its use
as a simple certificate authority.
• gnoMint

References

1. Third of internet users too scared to use credit card to shop online. (2009). Retrieved:
May 12, 2009 from The Telegraph
2. Turban, E. King, D. McKay, J. Marshall, P. Lee, J & Vielhand, D. (2008). Electronic
Commerce 2008: A Managerial Perspective. London: Pearson Education Ltd. p.550
3. Turban, E. King, D. McKay, J. Marshall, P. Lee, J & Vielhand, D. (2008). Electronic
Commerce 2008: A Managerial Perspective. London: Pearson Education Ltd. p.554
4. Mastercard: Security Rules and Procedures-Merchant Edition (PDF). 2009. Retrieved:
May 12, 2009
5. Kantor, Michael; James H. Burrows (1996-04-29). "ELECTRONIC DATA
INTERCHANGE (EDI)". National Institute of Standards and Technology.
http://www.itl.nist.gov/fipspubs/fip161-2.htm. Retrieved 2008-05-13.
6. North Dakota Medicaid Companion Guide
7. Wisconsin Medicaid EDI Information
8. Nebraska Medicaid Submission Requirements
9. Bergeron, François; Louis Raymond (1992 ). "The advantages of electronic data
interchange". ACM SIGMIS Database. pp. 19..31.
http://doi.acm.org/10.1145/146553.146556.
10. David Chaum, Blind signatures for untraceable payments, Advances in Cryptology —
Crypto '82, Springer-Verlag (1983), 199-203. (PDF)
11. Chaum, D., Fiat, A., and Naor, M. 1990. Untraceable electronic cash. In Proceedings
on Advances in Cryptology (Santa Barbara, California, United States). S. Goldwasser,
Ed. Springer-Verlag New York, New York, NY, 319-327. (PDF)
12. Fox, Justin (2010-05-07). "Will God Destroy Our Money or Will We Do It First?".
Blogs.hbr.org. http://blogs.hbr.org/fox/2010/05/will-god-destroy-our-money-or.html.
Retrieved 2010-09-05.
13. Haug, Espen (2010-04-18). "SSRN-When Will God Destroy Our Money?".
Papers.ssrn.com. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1591768.
Retrieved 2010-09-05.
14. "antiworm: Verified by Visa (Veriphied Phishing?)". Antiworm.blogspot.com. 2006-
02-02. http://antiworm.blogspot.com/2006/02/verified-by-visa-veriphied-
phishing.html. Retrieved 2010-08-11.
15. Muncaster, Phil. "Industry lays into 3-D Secure - 11 Apr 2008". IT Week.
http://www.itweek.co.uk/itweek/news/2214146/industry-lays-secure. Retrieved 2010-
08-11.
16. Brignall, Miles (2007-04-21). "Verified by Visa scheme confuses thousands of
internet shoppers". The Guardian (London).
http://www.guardian.co.uk/money/2007/apr/21/creditcards.debt. Retrieved 2010-04-
23.
17. "Verifed by Visa and MasterCard SecureCode: or, How Not to Design
Authentication" (PDF).
http://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf. Retrieved 2010-08-
11.
18. "Is securesuite.co.uk a phishing scam?". Ambrand.com.
http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/. Retrieved 2010-
08-11.
19. "Verified By Visa Activation - Visa Phishing Scams". MillerSmiles.co.uk. 2006-08-
22. http://www.millersmiles.co.uk/report/3279. Retrieved 2010-08-11.
20. "Activation During Shopping". Visaeurope.com.
http://www.visaeurope.com/documents/vbv/verifiedbyvisa_activationduringshopping.
pdf. Retrieved 2010-08-11.
21. http://www.mozilla.org/projects/security/certs/included/, List of Trusted Root
Certificate Authorities, 2/10/2010.
22. Verisign, Inc. (31 January 2001). "Jan 2001 - Advisory from VeriSign, Inc.".
http://www.verisign.com/support/advisories/authenticodefraud.html. Retrieved 2008-
12-02.
23. Microsoft, Inc. (22 March 2001). "Microsoft Security Bulletin MS01-017".
http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx. Retrieved 2008-
12-02.