Securely Accepting Credit Cards Real-Time

UPDATE: A variation of this method has now been implemented! For more details, please click here.

This document details my idea for how a business (XYZ, Inc. with domain name xyz.com) might act as a proxy for securely accepting and processing credit cards in real time. This system could be used to sell existing information/images in real-time. It is not intended (nor useful) for selling merchandise that will be delivered at a later time (regular secure servers work fine for those transactions). If you know of someone already doing something like this, please let me know. Technical, legal and other comments are extremely welcome at sarang@sarangworld.com.

• The merchant never sees the customer's credit card number, only XYZ does; customer doesn't have to trust the merchant.
• Merchant doesn't require a credit card account, only an account with XYZ; XYZ partitions out payments on a monthly basis after collecting from credit card company.
• Online merchants are often willing to pay significant fees for convenience.... XYZ could take 10% off the top of each transaction.
• No cybercash/ecash/wallets/cookies, no waiting. Just good old fashioned credit cards.
• No special technology required for credit-card verification online, so solution is available now.... the verification is handled traditionally.
• Use of encryption at each stage strongly reduces effectiveness of spoofing and interception.

Description of Method

1. Define a new MIME-type (x/credit-card-transaction or something) with a specific extension, call it "$$$" (in reality, we'll have to use something else, since $ is a Unix-special character).
2. If a merchant wants to sell a URL (ie, a piece of information), he places his "merchant code", the price, and other relevant information in a $$$ file; the URL itself is placed in an access-controlled directory that can only be reached by machines in the xyz.com domain.
3. When the customer clicks on the $$$ file, a XYZ-written popup program or plugin informs the customer "The item you wish to purchase costs $xxx.yy; if you want to buy it, enter your credit card number and expr. date"; if the customer decides to purchase, the plugin/popup looks up XYZ's current public key, and encodes the data (credit card number, exp. date, current time and date, price, merchant code etc) on the client side, and sends the encrypted data to a machine on xyz.com; the popup also invents a public/private key pair for the customer and passes along the public key.
4. Upon arrival at xyz.com the data is decrypted, and passed on to people (actual physical human beings, still available in many states!) who record the transaction, process the credit card in the normal way (ie, offline), and then indicate whether the transaction was approved or disapproved.
5. If disapproved, xyz.com sends a message back to the customer indicating the transaction couldn't be completed.
6. If approved, xyz.com accesses the purchased information (in the XYZ-access-only directory on the merchant's machine). If the merchant has cgi-bin, xyz.com instead tells the merchant's machine to send the data encrypted with xyz.com's public key, to avoid interception during transmission from merchant to xyz.com. (the cgi-bin script for encrypting the data would be pre-written, similar to the plugin/popup that encrypts the customer's information)
7. xyz.com now encrypts the data with the customer's public key, and sends the information to the customer; the popup/plugin then decodes the information and presents it to the customer.

Featured links:

• Read my blog
• Need to contact me urgently? Send me an email and I haven't replied?
• Save the CFSI; help bring the complete Friends scripts back online!
• Nitpicker's Guide (of sorts) to Friends
• Time/weather/astronomy in various world locations

Please do not email this address: 266bbf60-4b997242@st.sitesuck.com

Search SarangWorld

SarangWorld Home Page