secure payment

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 encrypt sensitive information, such as credit card numbers, to ensure that information passes securely between the customer and the merchant.
A payment gateway facilitates the transfer of information between a payment portal (such as a website 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 processor used by the merchant's acquiring bank. The 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 acquiring bank and directly provides a response of approved or declined to the payment gateway. 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 and a relevant response then relayed back to the cardholder and the merchant. The entire process typically takes 2-3 seconds The merchant must then ship the product prior to being allowed to request to settle the transaction. 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.
Secure Electronic Transaction (SET) is a standard protocol for securing credit card transactions over insecure networks, specifically, the Internet. SET is not itself a payment system, but rather a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network in a secure fashion.
SET was developed by VISA and MasterCard (involving other companies such as GTE, IBM, Microsoft, Netscape, RSA and VeriSign) starting in 1996. SET is based on X.509 certificates with several extensions. SET makes use of cryptographic techniques such as digital certificates and public key cryptography to allow parties to identify themselves to each other and exchange information securely. SET uses a blinding algorithm that, in effect, lets merchants substitute a certificate for a user's credit-card number. This allows traders to credit funds from clients' credit cards without the need of the credit card numbers.
SET was heavily publicized in the late 1990's as the credit card approved standard, but 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, adequate SSL based alternative. Client-side certificate distribution logistics. SET was said to become the de facto standard of payment method on the Internet between the merchants, the buyers, and the credit-card companies. When SET is used, the merchant itself never has to know the credit-card numbers being sent from the buyer, which provide a benefit for e-commerce.
People today pay for online purchases by sending their credit card details to the merchant. A protocol such as SSL or TLS keeps the card details safe from eavesdroppers, but does nothing to protect merchants from dishonest customers or vice-versa. SET addresses this situation by requiring cardholders and merchants to register before they may engage in transactions. A cardholder registers by contacting a certificate authority, supplying security details and the public half of his proposed signature key. Registration allows the authorities to vet an applicant, who if approved receives a certificate confirming that his signature key is valid. All orders and confirmations bear digital signatures, which provide authentication and could potentially help to resolve disputes.
A SET purchase involves three parties: the cardholder, the merchant, and the payment gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set dual signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him.
All parties are protected. Merchants do not normally have access to credit card numbers. Moreover, the mere possession of credit card details does not enable a criminal to make a SET purchase; he needs the cardholder’s signature key and a secret number that the cardholder receives upon registration. The criminal would have better luck with traditional frauds, such as ordering by telephone. It is a pity that other features of SET (presumably demanded by merchants) weaken these properties. A merchant can be authorized to receive credit card numbers and has the option of accepting payments given a credit card number alone.
SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder’s and merchant’s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:
The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder’s bank examines the completed form. The dual signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals. SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets.