Tlt~e METHOD FOR SECURE PAYMENT WITH STANDARD CREDIT
CARDS IN ELECTRONIC COMMERCE SYSTEM
~ Field of the invention This invention relates to electronic commerce and, more particularly, to a system and method for credit card related transactions an open electronic public system such as the Internet.
~ Background of the invention With the rapid growth of Internet sites along with the advent of flat rate pricing, millions of Internet users now rely on multiple sites for e-mail, chat, news, and many other products and services involving transaction.
Presently there are over 1 SO million Internet users, each of whom must use a browser to "surf' the Internet. By 2001, it is estimated that there will be over 700 million worldwide Internet users.
And, in the next five years, conservative forecasted volume of transaction on the web will exceed 57 billion of dollars.
This invention significantly improves the level of confidence and the actual security of payment transactions on the web.
While most major banks are currently using a form or another of high security encryption for at home banking and investment, which appears to satisfy sophisticated and learned users, none of those systems have yet provide the level of comfort and comprehension needed for the average user.
Businesses of all sizes are struggling to take advantage of the relatively new electronic marketplace. But the development of systems for executing secure credit card transactions across electronic networks hasn't follow course. Most existing or proposed schemes are essentially existing credit card systems adapted for operation over the Internet.
The biggest challenge appears to securely obtain or transmit a customer's credit card information in a way that simulate what happens in bricks-and-mortar stores. Traditionally, a customer would give his credit card information on a paper imprint or via a magnetic reader, a payment amount would be associated with it, the information would or would not be scrambled to verify card validity and obtain an authorization number from the issuer. Since credit electronic payment systems are built around the conventional, bundled service credit card transaction processing systems, the same basic architecture has been applied to web sites ~in order to avoid replacing existing equipment and protocols at the merchant's end. The merchant still acts as the main transaction hub. It is the merchant's responsibility to verify the cardholder's legitimacy and to obtain clearance from the issuer.
Merchants have access to the standard customer information. Even if some of the systems provide authentication using digital signatures or the added security of smart cards through peripheral computer apparatuses, hackers or fraudulent employees may still have access to stored data. It is worth to note that one of the major sources of fraud is not illegal transaction as much as pirating legitimate cardholders' data to manufacture counterfeited plastic cards.
Other desirable aspects of a standard credit card secure system is that it would allows all cardholders to make transaction on the Internet with existing and familiar credit account, while giving the credit card company a significantly increased level of security against fraud, that in turn may help merchants to deal with charge-back problems.
Brief description of the drawings In the appended drawings:
Figure 1 is a block diagram illustrating an actual transaction according to the prior art;
Figure 2 is a block diagram illustrating a first embodiment of the data flow of the method of the present invention;
Figure 3 is a block diagram illustrating a second embodiment of the data flow of the method of the present invention;
Figure 4 is a diagram illustrating the external specifications of the presentinvention;
Figure 5 is a block diagram illustrating the architecture of a system embodying the method of the present invention; and Figure 6 is a diagram illustrating the internal specifications of the presentinvention.
~ Summary of the invention This invention relates to an electronic commerce and transaction system, its components and methods for their use.
This invention accessibility and simplicity allows everyone to understand why they can now safely use their existing credit or payment card account for any type of transaction on the Internet.
In this invention's system, vital information that appears on credit cards and are stored in financial institutions' current and well-protected internal system will remain securely there. They will never be transferred to a third party on the Internet (or via any other means).
The sensitive information that will eventually be transmitted on the Internet to merchants, service providers or anyone accepting credit card payment, is an EphemeralTM Credit Card Numbers (ECCN) that is virtually useless to any other party but the legitimate users.
In one aspect, the invention is a method of credit card payment in an electronic commerce environment wherein customers have existing accounts with a Bank and where each customer shares a respective secret with that same Bank. This secret is set up prior to any actual transaction and, in preferred embodiments, is a dynamic secret. This secret is used to uniquely identify a customer in the encrypted communication established to obtain an ECCN.
In some embodiments, the shared secret is a private key (PHI) stored in the user's computer andlor a computer agent's software access password known only by the user.
According to the method of this invention, a given Bank issues a computer agent software to all customers. The software is capable of establishing an encrypted secure session that provides a unique identification of the customer. In preferred embodiments, the customer must use a private password to get access to the computer agent software application.
The customer first visits merchant website and shops as usual.
Once an intent of purchase is expressed, customer's computer agent automatically obtains from the Bank's system server an ECCN with which a credit or payment card transaction may be completed as usual.
In some embodiment, the user enters a distinct private password to confirm his purchase intent.
In preferred embodiments, segments of data obtained by cardholder at merchant site are linked to the ECCN to make it purchase, merchant and/or user specific.
The merchant obtains the ECCN and order information from the customer's computer, and processes ECCN the way standard credit card numbers are currently processed.
The ECCN is checked by the current credit card checking system/agent for credit limit and validity after which it issues the usual authorization number to the merchant.
The Bank's system server will eventually correlate the amount charged to the ECCN with the actual customer account for usual billing.
'The merchant provides the goods to the customer in response to receiving the authorization number from the credit card checking system/agent.
In preferred embodiment, the method also comprises a limited time period of validity for any given transaction, which may also be purchase, merchant and/or user specific.
Once the transaction is completed, the ECCN becomes automatically void and useless, like non-valid or stolen card numbers. In some embodiments, the ECCN may remain attached to a specific transaction for a certain period of time for refund purposes only. Yet in other embodiments, refunds are processed with complementary ECCN that replace the one used in the initial transaction.
While embodiments of the present invention have been described with particular setup and initialization procedures, other setup and/or initialization procedures can be used.
Further, while some of the system's element may have been said to be performed in a particular order, one skilled in the art would realize that other orders are possible and are considered to be within the scope of the invention.
Thus, a secure electronic credit card payment system preventing access to vital information is provided.
Introduction The purpose of this document is to present the overall architecture of Twin for secure transactions in e-business, B2B, B2C, and also C2C.
TwinGate is an Internet Portal for secure transactions implemented o~i~ a fry end server for Customers and Merchants.
TwinGate is also an information routing device. This aspect wil~~'~c~escrWd.~~n a sub-- ,~ - _:
TwinGate implements Profiles for Users (Merchant, Custor~ei ~' ~..__.
a Profile is a list of Services a User can access. ~-_ The features of the TwinGate system include (amoners):
No use of a holder's Credit Card number==~___ Secured Transactions with standard Dh~,S encryp>~~on -_ .n_ Scalability Document is orgA~'~ze~ as ~,~ws v Description of the acG~~l C2B system oftransactions using Credit Cards ~ Description of the form~,hsr~i used ~ Architecture of the 'I~v~yGate EGN sytem (centralized) _ : ...
- _,~ -Payment ~ C~dNo authorisation ~rC_ardNo ' Merchant _ Invoice ;~ _ ~ Customer - ~'_._~der_ ;- _ F
CA 02309013 2000-OS-23 ~ -Formal Description To achieve the validation of the systems that are proposed, the agents are vie w ,~ ~~ com-municating processes (the data at this point has no importance because it is x ~rvate information) In the sequel, the formalism chosen for describing concurrent commucatigi,~ce~s~s is the Arnold-Nivat model(2J, implemented in the tool MEC.(3~ T,_ mam f~urr~' of Model is its simplicity: it is general enough to describe many formalisms. and y~~.:,:poerful to concretely verify properties. MEC has been successfully used for ink. yn t)~~:~ification and design of a simple call-processing system (4J, as well a~_,forT~leri~' _methods for the design of a switching program ~5). The tool MEC allows s_er to ge ~-- y ormation on the behavior of a transition system. In particular, it can corri'pu ° '-- s of~s~ates (or sets of transitions) having a property expressed in some langua~s~ the :scan be used as a _..
._ model checker. -~ ~~
The communicating processes are Cutomer, Merchant, I, TwmT . They are described as transitions systems having given states and perforn-~ons.
.:.__ r_~_ --Customer The Customer is an agent that has twca..s~~~es: Active, Sleeping. It can perform actions like the following 1. SendOrder 2. GetInvoice 3. SendCCN
Merchant The Customer is an agent that has two states: Active, Sleeping. It can perform actions like the following 1. GetOrder "-'~ .
2. SendInvotc ".. -:::~~, -... ° _.;_=-~:_ 3. CCNRe~est _ __ 5. GetAuthori~ationNr 1. GetECCNRequest 2. SendAuthorizationNr 3. SendRefusedTrxn Synchronization . . . . .~:;-.:.;,~~::: .:: -v:.:,:..-.-Payment P°%
_ .... _ . _.....:_~~ Payment req.
-~ ECCN_ ;
~ ., _Invo~ce ; ~ ~stomer ___ '- ______.
tation, the ECCN is created by the TwinGate Server. It should be Bank} may be willing to manage these actions, leading to a different (U
CCN Request L.ogin + Amount _~r__' Autfiori~i~f ~- .: _=:
Payment Request Authorization #
End Trxn :w Refused Trxn Remarks 1. The specificatio ven ab'"a~~es not take into account the TimeOuts, inherited from the Bank's spe~.,_ion, ani'~9 that can occur in the processes. Yhese timeouts are inherited from the ~t~~Bauk).
___:~_ ~; __...-2. It is also sume~,t when a Customer logs in he can access an administrationmodule eallowing . me admii~~strative tasks such as password changes etc..
.4_'~~ _ . '".
.:.~.~:~z_~:~- - y _-~~ In this imp . .lion, the ECCN is created by the TwinGate Server. It should be 'noted that ~ CCI(or Bank) may be willing to manage these actions. In that case the External Specification is modified accordingly: ECCN is provided by the bank with -........ the Authori,tion number.
j...' .y _.. _ _: : .- ~ ..::'- : J/
't TyvinGate Server Internal Specification ..
~09~ + Amount +ECCN Storage quest o9rn + Amount +E~ - _ _ _ _ _ ~':PI Z2t)On ~
Authorization # Storage Request Q _________ __ Cel Authorization #
Forward Refused rretused Trxn Refused Ttxn _:.;:',:., _ '_.. ::__. . p .
~~~T'~~~uTe 4. ~_wmGate.. .Internal S ecification.
1~. The Tim~Outs that"=ccui in the system and generated 17y the accessed CCI(Banl;) will ~cxllow the~~rocessing of etceptions_ v'~a In this impI~i~tt~ation; the ECCN is created by the ECCN Generator. In.
the case where a CC~(or Bank) manages these actions; the htterrnal Syecification is modified accordingly: I;CC~ is provided by the bank with the Authorization number. and the . ECCN_G~t%I module is rerno~red with the In and Out transitions.