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 cards2. 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.