<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/css" href="http://commons.oreilly.com/wiki/skins/common/feed.css?97"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;action=history&amp;feed=atom</id>
		<title>Beautiful Trade/Secure Electronic Transaction - Revision history</title>
		<link rel="self" type="application/atom+xml" href="http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;action=history&amp;feed=atom"/>
		<link rel="alternate" type="text/html" href="http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;action=history"/>
		<updated>2013-05-22T15:14:08Z</updated>
		<subtitle>Revision history for this page on the wiki</subtitle>
		<generator>MediaWiki 1.11.0</generator>

	<entry>
		<id>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;diff=24536&amp;oldid=prev</id>
		<title>Ebellis: New page: '''Secure Electronic Transaction'''   Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for  securing credit card transactions over insecure networks ...</title>
		<link rel="alternate" type="text/html" href="http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;diff=24536&amp;oldid=prev"/>
				<updated>2009-06-30T02:22:10Z</updated>
		
		<summary type="html">&lt;p&gt;New page: '''Secure Electronic Transaction'''   Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for  securing credit card transactions over insecure networks ...&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;'''Secure Electronic Transaction''' &lt;br /&gt;
&lt;br /&gt;
Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for &lt;br /&gt;
securing credit card transactions over insecure networks such as the Internet. SET utilizes &lt;br /&gt;
X.509 certificates and extensions, along with public key cryptography to identify each party &lt;br /&gt;
within the e-commerce transaction and transmit the data while maintaining confidentiality. &lt;br /&gt;
SET’s unique binding algorithm substitutes a temporary certificate for the consumer’s account &lt;br /&gt;
number, so that the online merchant never needs access to this sensitive information. Each &lt;br /&gt;
party is required to preregister with the certificate authority (CA), allowing the card issuer to &lt;br /&gt;
perform due diligence before it allows the merchant to perform e-commerce transactions, and &lt;br /&gt;
then authenticating all parties in the transaction. &lt;br /&gt;
&lt;br /&gt;
On the consumer end, SET creates a hash value of the order information together with the &lt;br /&gt;
payment information. The payment information is sent to the bank along with the signed hash &lt;br /&gt;
of the order information. The consumer-side software also sends the order information to the &lt;br /&gt;
merchant with the signed hash of the payment information. Both the cardholder and the &lt;br /&gt;
merchant create equivalent hashes, compared when they are received by the bank or payment &lt;br /&gt;
gateway. &lt;br /&gt;
&lt;br /&gt;
This protocol offers a number of different protections for the transaction: &lt;br /&gt;
&lt;br /&gt;
• It authenticates all parties in the initial transaction at time of registration with the CA. &lt;br /&gt;
• It performs additional authentication at transaction time through the exchange of &lt;br /&gt;
certificates with the consumer, merchant, and payment gateway. &lt;br /&gt;
• Sensitive data such as the account number is shared only between the consumer and the &lt;br /&gt;
bank and kept on a “need to know” basis, freeing the merchant from the need to store or &lt;br /&gt;
transmit this information. &lt;br /&gt;
&lt;br /&gt;
SET transactions &lt;br /&gt;
&lt;br /&gt;
The sequence of events required for a transaction follow: &lt;br /&gt;
&lt;br /&gt;
1. The customer obtains a credit card account with a bank that supports electronic payment &lt;br /&gt;
and SET. &lt;br /&gt;
&lt;br /&gt;
2. The customer receives an X.509 v3 digital certificate signed by the bank. &lt;br /&gt;
&lt;br /&gt;
3. The customer places an order. &lt;br /&gt;
&lt;br /&gt;
4. Each merchant has its own certificate, which it sends to the customer so his software can &lt;br /&gt;
verify that it’s a valid store. &lt;br /&gt;
&lt;br /&gt;
5. The order and payment are sent. &lt;br /&gt;
&lt;br /&gt;
6. The merchant requests payment authorization from the issuing bank. &lt;br /&gt;
&lt;br /&gt;
7. The merchant confirms the order. &lt;br /&gt;
&lt;br /&gt;
8. The merchant ships the goods or provides the service to the customer. &lt;br /&gt;
&lt;br /&gt;
9. The merchant requests payment. &lt;br /&gt;
&lt;br /&gt;
'''Evaluation of SET''' &lt;br /&gt;
&lt;br /&gt;
Unfortunately, due to the amount of overhead involved in the massive Public Key &lt;br /&gt;
Infrastructure (PKI) and registration process required by SET, it will never be widely adopted. &lt;br /&gt;
The complexities with managing it become unbearable given the size of the e-commerce &lt;br /&gt;
market.&lt;/div&gt;</summary>
		<author><name>Ebellis</name></author>	</entry>

	</feed>