ELECTRONIC PAYMENT GATEWAY

PRESENTED BY SURUMI K K LENNY BABU

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

1. How payment gateways work 2. Security

How payment gateways work

A payment gateway facilitates the transfer of information between a payment portal 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 1. 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. 2. 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.
4

3. 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. 4. The payment gateway forwards the transaction information to the payment processor used by the merchant's acquiring bank. 5. The payment processor forwards the transaction information to the card association (e.g., Visa/MasterCard) 6. The credit card issuing bank receives the authorization request and does fraud and credit or debit checks and then sends a response back to the processor (via the same process as the request for authorization) with a response code [eg: approved, denied]. 7. The processor forwards the authorization response to the payment gateway. 8. 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 merchant and cardholder. This is known as the Authorization or "Auth 9. The entire process typically takes 23 seconds.
5

10 The merchant then fulfills the order and the above process is repeated but this time to "Clear" the authorization by consummating the transaction. 11 The merchant submits all their approved authorizations, in a "batch" (eg: end of day), to their acquiring bank for settlement via its processor. 12 The acquiring bank makes the batch settlement request of the credit card issuer. 13 The credit card issuer makes a settlement payment to the acquiring bank (eg: the next day). 14 The acquiring bank subsequently deposits the total of the approved funds in to the merchant's nominated account (eg: the day after). 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. 15 The entire process from authorization to settlement to funding 6 typically takes 3 days.

2. Security
Since the customer is usually required to enter personal details, the entire communication of 'Submit Order' page (i.e. customer - payment gateway) is often 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 payment 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.
7

a) SECURE SOCKET LAYER

SSL can refer to:

1. 2. 3. 4. 5. 6. 7. 8. Computing and electronics Business Language Places Science Space sciences Sports Other

 Computing and electronics

Secure Socket Layer, a protocol for encrypting information over the Internet Single stuck line, a fault model for digital circuits S/SL programming language RoboCup Small Size League Semi-supervised learning, a class of machine learning techniques Serato Scratch Live, a digital DJing tool Solid State Logic A brand of audio mixing consoles
10

Business
Sasol, a company in South Africa, NYSE stock symbol SSL Solid State Logic, a manufacturer of mixing consoles and software for broadcast (Gravity) Space Systems/Loral (SS/L), a spacecraft manufacturer SSL International, a consumer healthcare manufacturer, owning brands like Durex and Scholl System Simulation Ltd, a software engineering company

Language
Selangor Sign Language, a sign language used in Malaysia Swedish Sign Language, a sign language used in Sweden

Places
South Salt Lake, Utah, a city in the US state of Utah Social Science Library, Oxford, the Oxford University departmental library for Social Sciences, on Manor 11 Road.

Science Sodium stearoyl lactylate, a food additive used as an emulsifier Solid-state lighting, a lighting technology that utilizes a cluster of LEDs Space sciences Space Sciences Laboratory, in Berkeley, California Space Systems Laboratory, at the University of Maryland, College Park, formerly at MIT
12

Sports
Swedish Super League, a floorball league in Sweden

Other
Saitama Seibu Lions, a professional baseball team in Japan's Pacific League Sesame Street Live, a touring version of the children's television show Standard sea level, the air conditions at sea level The sub-surface lines, cut-and cover railway lines forming part of London Underground Student Service Learning

13

b) Secure Electronic
Transaction

MOTIVATION

14

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.

15

Contents
1. 2. 3. 4. 5. History and development Key features Participants Transaction Dual signature

16

History and development

SET was developed by SETco, led by VISA and MasterCard (and involving other companies such as GTE, IBM, Microsoft, Netscape, RSA, Safelayer --formerly SET Projects-- 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 companies17from 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.

18

Key features
To meet the business requirements, SET incorporates the following features: Confidentiality of information Integrity of data Cardholder account authentication Merchant authentication

19

Participants
A SET system includes the following participants: Cardholder Merchant Issuer Acquirer Payment gateway Certification authority

20

Transaction
The sequence of events required for a transaction are as follows:
The customer obtains a credit card account with a bank that supports electronic payment and SET The customer receives a X.509v3 digital certificate signed by the bank. Merchants have their own certificates The customer places an order The merchant sends a copy of its certificate so that the customer can verify that it's a valid store
21

 The order and payment are sent The merchant requests payment authorization The merchant confirms the order The merchant ships the goods or provides the service to the customer The merchant requests payment

22

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

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

The End
THANK YOU