EP1214696A1 - Procede de transfert de paiements securise - Google Patents

Procede de transfert de paiements securise

Info

Publication number
EP1214696A1
EP1214696A1 EP00958954A EP00958954A EP1214696A1 EP 1214696 A1 EP1214696 A1 EP 1214696A1 EP 00958954 A EP00958954 A EP 00958954A EP 00958954 A EP00958954 A EP 00958954A EP 1214696 A1 EP1214696 A1 EP 1214696A1
Authority
EP
European Patent Office
Prior art keywords
computer
card
payment
merchant
card holder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00958954A
Other languages
German (de)
English (en)
Inventor
Christopher John Hamilton
Lisa Kay Wells
Bhagwat Brahmbhatt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Trintech Ltd
Original Assignee
Trintech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP99650088A external-priority patent/EP1087350A1/fr
Application filed by Trintech Ltd filed Critical Trintech Ltd
Priority to EP00958954A priority Critical patent/EP1214696A1/fr
Publication of EP1214696A1 publication Critical patent/EP1214696A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user

Definitions

  • the present invention relates to a method and sales system for the secure transfer of payment and related purchase information over a network sales system for a payment card-not-present transaction, including a plurality of card holder computers, a card issuer computer, merchant computers and a merchant payment acquirer computer, all interconnected by a communications network.
  • the term "payment card” is used to encompass not alone what is considered generally as being a credit card, but also debit cards and any other issued cards and payment accounts which comprise a standard payment account number, but without the provision of a conventional physical plastics imprint card which can be used by consumers, or corporate purchasers, for the payment for goods and services.
  • a "payment card transaction” as used in this specification refers to the use of any such payment card in a transaction.
  • the payment card holder be able to use the payment card for electronic commerce in substantially the same way as the payment card holder uses a payment card for card-present transactions, in card present transactions the card holder proffers a payment card in an establishment, the payment card slip is printed for the payment card holder, who then signs the payment card slip, obtains a receipt, and is secure in the knowledge that the receipt corresponds to what they have paid.
  • the card holder sends a payment message to the payment computer which message includes sufficient information to identify the product and then the payment computer is programmed to receive this payment message, to authenticate it in the usual way and then to send an access message to the merchant computer which is programmed to receive and authenticate the message and then to cause the product to be sent to the user.
  • the payment computer which message includes sufficient information to identify the product and then the payment computer is programmed to receive this payment message, to authenticate it in the usual way and then to send an access message to the merchant computer which is programmed to receive and authenticate the message and then to cause the product to be sent to the user.
  • This invention addresses some security concerns but its reliance on temporary transaction numbers substantially modifies the cardholder experience and it may not be compatible with existing merchant behavior. In particular, it is not compatible with merchants who offer rewards to repeat card holder customers by recording the number or value of multiple purchases made with a specific payment card number. This invention may generate confusion when cardholders communicate with merchants to resolve problems or disputes, as there will be two payment numbers associated with the transaction, namely the permanent account number and the temporary transaction number. Finally, this invention does not work seamlessly with merchants who offer 'one-click' buying by maintaining their own database of cardholder payment-card numbers. Thus, while this invention may substantially reduce fraud, it does not satisfy the market need for a payment system that requires minimal change to cardholder and merchant behavior. What the card holder wants is to use his or her payment card as if it had been handed to the merchant in a card present transaction i.e. it must be used in a clear and seamless fashion without the card holder having to make any decisions other than the normal purchase decisions.
  • the financial institutions are well aware of the need to maintain brand awareness with their customers. There is a recognised need for the card issuer to transmit advertisements to the card holders when purchase transactions are taking place, especially ideally when the card issuer's payment card is being used.
  • the card issuer has a strong need to reinforce the card issuer's corporate and brand identity, and Trade Marks.
  • the present invention is directed towards overcoming these problems.
  • a payment card is directed towards allowing a payment card to have all the attributes of an electronic wallet such as allowing the payment card to be used securely for electronic commerce, and further to providing a system and method so that the consumer can use the same process he or she is familiar with when using a payment card in a card-present transaction.
  • the invention is directed towards providing a method and system allowing the card issuer to maintain close client contact with the card holder, providing a marketing channel of communication and other opportunities for the card issuer.
  • the invention is directed towards removing the need to have a physical payment card particularly for card not present transactions but not exclusively so.
  • a method for the secure transfer of payment and related purchase information over a network sales system for a payment card transaction including a communications network and at least a card holder computer operated by a card holder, a card issuer computer, a merchant computer and a merchant payment acquirer computer comprising:
  • a payment request is sent from the merchant computer to the card holder computer;
  • the card holder computer contacts the card issuer computer and opens a direct communications link with the card issuer computer; the identity of the card holder is authenticated to the card issuer computer;
  • the card holder computer sends merchant and purchase information to the card issuer computer;
  • the card issuer computer sends card payment information to the card holder computer
  • the card holder reviews the card payment information displayed on the card holder computer;
  • the card holder computer causes the card payment information to be sent to the merchant computer thereby authorising the payment
  • the merchant computer confirms the transaction to the card holder computer.
  • the advantage of this is two-fold: the issuer carries out the payment tasks usually performed by the card holder, and a direct and unobstructed channel of communication is established between the card holder at the time of the payment transaction.
  • An additional advantage is that all of the information for payment and purchase is displayed on the screen and the user can alter this prior to final transmission or submission to the merchant computer to complete the payment authorisation request.
  • the identity of the card holder is authenticated by a password, a digital certificate, a shared secret key or by a separate party authentication computer connected to the communications network. All of these will lead to increased security.
  • the method comprises the steps of:
  • the card holder computer transmits authentication information to the party authentication computer and requests the party authentication computer to provide authentication;
  • the party authentication computer transmits an authenticatior file to the card holder computer
  • the card holder computer transmits the authentication file to the card issuer computer.
  • the authentication file is deactivated after a pre-set time.
  • the card holder changes the card payment information before causing it to be sent to the merchant computer. This allows the user or card holder a final review before actually making the purchase.
  • the card holder computer instructs the card issuer computer to send the card payment information to the merchant computer;
  • the card issuer computer sends the card payment information to the merchant computer.
  • the merchant computer obtains confirmation that the payment will be made from the merchant payment acquirer computer and this may be obtained in real time rather than in batches from the merchant computer as is usually the situation.
  • the advantage is that in the event of errors or omissions in the information they can be rectified in real time and not at a subsequent date which can be difficult, particularly when batch payment requests are sent by the merchant computer to the merchant payment acquirer computer.
  • the card holder computer confirms the transaction will take place to the card issuer computer.
  • the merchant computer places a payment card authorisation request with the merchant payment acquirer computer
  • the merchant payment acquirer computer contacts the card issuer computer
  • the card issuer computer causes payment authorisation to be established
  • the card issuer computer confirms the payment authorisation to the merchant payment acquirer computer
  • the merchant payment acquirer computer confirms the payment authorisation to the merchant computer.
  • the card issuer computer may additionally open a direct communications link with the merchant computer and on the card holder computer causing the card payment information to be sent to merchant computer thereby authorising the payment, the card issuer computer confirms payment authorisation to the merchant computer.
  • the card issuer computer stores sufficient transaction identification information to identify the transaction
  • the card issuer computer consults the transaction identification information to confirm that the payment may be made;
  • the card issuer computer causes appropriate payment to be made to the merchant payment acquirer computer.
  • the card issuer computer stores all the payment card information and the card holder computer may store communications and other protocols which other protocols can include an authentication protocol for initiating the use of the method.
  • the card issuer computer stores necessary merchant information to complete the transactions with the merchant computer.
  • the payment request is sent by the merchant computer in the form of a merchant payment form and the card issuer computer downloads all relevant payment card and card holder information onto the merchant payment form to provide the card payment information for subsequent transmission to the merchant computer as a completed merchant payment form.
  • the card issuer computer causes the complete merchant payment form to be displayed on the card holder computer as a completed card issuer payment slip, or causes the completed merchant payment form and the card issuer payment slip to be displayed side by side on the card holder computer.
  • the card issuer computer downloads to the card holder computer the card issuer payment slip which card issuer payment slip ideally conforms to the format of a card payment slip conventionally used for a card present transaction.
  • all data transmitted may be encrypted.
  • the card holders payment card number is not transmitted to the merchant computer and a purchase payment authorisation number is used when transmitting payment authorisation to the merchant computer, the payment card number being only issued to the payment acquirer computer
  • the sensitive card holder information is stored on the card holder computer in encrypted form, a key transmitted from the card issuer being necessary to decrypt the information by the card holder computer and ideally the commands are inputted by using a command icon on the screen of the card holder computer .
  • the card holder computer displays messages from the card issuer computer during the transaction said messages being additional to those required for the operation of the transaction.
  • the invention provides a method for a card issuer to control the flow of information to a card holder during a sales transactions in a network sales system for a payment card transaction, the system including a communications network and at least a card holder computer, a card issuer computer, a merchant computer and a merchant payment acquirer computer using a payment card comprising:
  • the card issuer (6) opens a direct communications link with the card holder computer
  • the card issuer computer receives from the card holder computer merchant and purchase information
  • the card issuer computer downloads card information for display on the card holder computer with the merchant and purchase information
  • the card issuer computer downloads additional messages for display on the card holder computer.
  • the additional messages may be displayed on the card holder computer simultaneously with the payment card, merchant and purchase information, such messages being additional to those required for the operation of the transaction. They may also be displayed during time intervals when the display of transaction information is not required.
  • Such messages may be linked to merchant information stored in the card issuer computer, or to card holder information on the card issuer computer, or to purchase information sent to the card issuer computer in the current or previous payment card transactions.
  • This provides the card issuer with a marketing opportunity.
  • the card issuer is aware that somebody is, for example, purchasing automobile parts, it is relatively easy for the card issuer to target that person with advertisements on automobile finance.
  • the level of purchase and the type of purchase will also alert the card issuer to advertisements that the card holder might be interested in.
  • the advertisements do not necessarily have to be services provided by the card issuer.
  • the card issuer could, for example, agree to take advertisements for others knowing that a card holder is purchasing goods, for example, from a book supplier such as AMAZON. It would then be possible for the card issuer to download advertisements for book clubs or other literary matters with the issuer being compensated for performing the advertising service.
  • the invention provides a method based sales system for payment cards comprising:
  • At least one card issuer computer at least one card issuer computer
  • At least one merchant computer At least one merchant computer
  • At least one merchant acquirer computer At least one merchant acquirer computer
  • said card holder computer being programmed to receive and store initiation data from the card issuer computer including an authentication protocol for initiation of the sales system;
  • said card issuer computer being programmed to store card payment information and to receive merchant and purchase information from the card holder computer and to transmit card payment information to the card holder computer to enable a payment card transaction to be completed by the card holder computer with the merchant computer; said card issuer computer being further programmed to deliver messages to the card holder computer during the transaction;
  • said merchant computer being programmed to deliver a payment request to the card holder computer and to carry out the transaction with the card holder computer.
  • said party authentication computer is programmed to prepare an authentication file and to transmit it to the card holder computer;
  • said card holder computer is programmed to transmit authentication information to the party authentication computer for authentication and to transmit authentication files to the party authentication computer.
  • the party authentication computer is programmed to de-activate the authentication file after a pre-set time.
  • the card holder computer can be a mobile phone and in this case then a card present transaction without physically proffering a credit card to a merchant computer can be carried out comprising using the method based sales system described above in which the mobile phone is used instead of a credit card. In this way, the card holder maintains his or her credit card number secret, in effect, keeping a credit card in a wallet.
  • the invention provides a computerised method for secure transfer of payment and related purchase information for a payment card transaction in which there is at least one card holder computer operated by a card holder, at least one card issuer computer operated by a card issuer, at least one merchant computer and at least one merchant acquirer computer and a communications network interconnecting the computers (3, 4, 6 and 11) comprising:
  • the step of transmitting the card holder information including the card holder payment card information to the merchant computer is performed.
  • this computerised method for secure payments and related purchase information that there is also included sending targeted advertising messages from the card issuer computer to the card holder computer based on at least one of the card holder data, the merchant data and purchase data based on the current or previous payment card transaction.
  • the authentication of payment further includes receiving authentication information from a third party which is transmitted to the card issuer computer and also may further includes receiving a request for payment settlement from the merchant computer. It may further include transmitting payment card information and sending the card payment information to the card holder computer which is subsequently forwarded to the merchant computer.
  • authenticating the payment includes receiving authorization of payment to the merchant computer from the card holder computer and ideally the purchase information includes at least one of purchase data, payment request data, merchant URL, card holder data, merchant data, or merchant acquirer data and the method may also include transmitting pre- authorization to the merchant computer, and receiving confirmation from the acquirer computer at the card issuer computer.
  • the method may further include sending a payment authorization message to the merchant computer.
  • the invention provides a computerized method for secure transfer of payment and related purchase information for a payment card transaction in a system having at least one card holder computer operated by a card holder and a card issuer computer comprising:
  • populating the payment page includes transmitting a drag and drop metaphor for use by the card holder to automatically fill out the merchant payment page and may preferably include displaying the merchant payment page to the card holder for review and editing.
  • This computerised method may also include storing a merchant profile at the card issuer computer for use in populating the merchant page and additionally for further updating the merchant profile by the card issuer computer based upon editing activity of the card holder or indeed generating a merchant profile.
  • the card holder computer is a mobile phone.
  • the invention provides a computerized method for secure transfer of payment and related purchase information for a payment card transaction, comprising:
  • receiving card holder provided authentication information including at least one of a username, password, a digital certificate, a shared secret key, a separate party authentication computer, or a card holder profile;
  • the invention provides a system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising:
  • a memory device having embodied therein data relating to a card holder profile and a merchant profile
  • a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer at a card issuer computer, authenticate a payment request from the card holder, and transmit card payment information of the card holder to the card holder computer ;
  • the invention comprises a system for providing secure transfer of payment and related purchase information for a payment card transaction, comprising:
  • a memory device having embodied therein data relating to a card holder profile and a merchant profile
  • a processor in communication with the memory device and configured to receive information related to at least one purchase from a card holder computer at a card issuer computer, authenticate a payment request from the card holder, and transmit card payment information of the card holder to a merchant computer; and a communications link (2) connecting the memory device to the merchant computer.
  • the communications link (2) also connects the memory device to the card holder computer.
  • the authentication of the request is by authenticating the identify of the card holder.
  • the invention provides a system for secure transfer of payment and related purchase information of a payment card transaction, comprising:
  • the invention also provides another system for secure transfer of payment and related purchase information of a payment card transaction, comprising:
  • means for sending card holder and payment card information to a merchant computer In this latter system it may comprise means for populating a merchant payment page.
  • the invention provides a computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction, comprising:
  • the invention provides a computer readable medium for use in secure transfer of payment and related purchase information for a payment card transaction, comprising:
  • the computer readable medium comprises an instruction code for populating a merchant payment page.
  • Fig. 1 is a broad outline of the eCommerce Network
  • FIGs. 2 to 4 are flow diagrams of a typical purchase of goods or services using the present invention.
  • Fig. 5 is a functional diagram of how the invention operates in practice for the parties;
  • Fig. 6 is a view similar to Fig. 1 of an alternative arrangement of the Network.
  • Figs. 7 and 8 are flow diagrams of an alternative method according to the present invention.
  • ezCard Since effectively the present invention produces an electronic version of a card holder's existing card or payment card, it has been for convenience in this specification referred to sometimes as an eCard or an ezCard, which are proprietary names we have chosen for them. In this specification it is represented in the distinctive form ezCard. The reason for this is that ezCards are simply virtual versions of an existing payment or debit card, which enables card holders to conveniently and securely buy on-line. The distribution and activation of the ezCard mirror the established process for physical cards since both are issued by the same source, namely the card issuer. The ezCard is never embodied physically.
  • ezCards will be issued for established debit or payment card accounts and therefore billing address, card holder name, payment card number and expiration date are not configurable by card holders. However, this information will correspond directly to the card issuer's account information on which the ezCard is issued.
  • the ezCard mirrors the familiar and well understood distribution, and activation process of a physical payment card, often hereinafter referred to simply as a payment card, thus the ezCard mirrors the existing physical payment cards for virtual use on the Internet.
  • a credit or payment card as understood by most consumers consists of two separate features, firstly the payment account with the issuing financial institution and secondly a physically present plastics card with optional magnetic stripe which can be used to provide an imprint of the card information or provide an electronically-readable version of the same.
  • the card can be used simply as a permanent means to store the number of the account for card-not- present transactions. It is envisaged that some card issuers may. prefer to issue what are effectively virtual payment cards and never produce a physical embodiment of the card. This could have several advantages for the financial institution. Firstly, it obviates the need to manufacture and distribute such physical cards. Secondly since virtual cards have no physical presence they cannot be used to make fraudulent purchases in card-present transaction situations.
  • the authorization request that is sent to the issuing bank by the merchant acquirer bank can indicate whether or not the purchase is eCommerce or mail order.
  • the card holder knows that the fraud must have taken place on the Internet because it obviously wasn't stolen in for example a restaurant or a store and secondly the card holder can cancel the virtual card without affecting his or her ability to continue card-present transactions, which presumably could be tied to other non-virtual cards, i.e. to conventional credit or payment cards.
  • the present invention allows maximum flexibility for both the card holder, card issuer and the card issuer bank.
  • the organization operating the invention may provide service to holders of pre-existing credit cards who do not have any prior relationship with it.
  • a registration process would occur through which the card holder would provide all necessary information to the organization including the credit card number, said information being subsequently stored in the organization's database.
  • Such card holders would not be authenticated to the same degree as users who were known to the organization prior to their registration, but they would still benefit from the seamless merchant form-filling capabilities of the invention, and the operators of the invention would still benefit from the valuable commercial information which they derive from participating in the card holder's purchase transactions.
  • the organization operating the invention may provide service to persons wishing to establish a new credit card account by opening a communications link to a card issuer or a credit-rating institution during the registration process.
  • a transaction having a monetary value above a certain amount may require the merchant and its acquirer bank to initiate a more rigorous authorisation protocol.
  • the reference to information or data by a general term such as "merchant payment information” or “merchant payment data” may not always mean that the information transmitted or obtained is identical at least in detail, such a definition, description or label on the definition must be qualified by the phrase "as is appropriate for the requirements of the recipient".
  • all a card holder may require as "merchant payment information” is a completed merchant form - while the card issuer computer may require more information to complete its part of the transaction.
  • the term “profiling” is used to qualify information such as for example "merchant profiling information” to describe information about the merchant as described in more detail below.
  • the term 'computer' is used in the broadest way and in many instances more appropriate wordings would be organisation; database; etc. However, as in most instances a computer, mobile phone, or some other instrument, device, or machine will be the contact device used. Equally the term processor could be used.
  • the term computer encompasses such an information processor which may include databases, wireless devices, image storage and retrieval systems, or could be part of a network of even a website.
  • the term computer when used for a card holders use can be quite different to the same term when used for a merchant for the former it could be a PC and for the latter a website.
  • the term computer is used as it appeared to be the one most likely to be used and thus the most appropriate term.
  • the present invention conveniently and automatically fills out merchant payment pages using a "drag and drop” metaphor.
  • a further feature of the present invention as will be apparent from the following description is that it allows a wide variety of messages, including marketing information and advertising, to be transmitted by the card issuer to the card holder every time a purchase is made.
  • a key capability of the invention is that when the ezCard is invoked; and the issuer's computer is contacted, a clear and unobstructed channel of communication is established between the issuer and the card holder. This channel of communication enables the issuer to reinforce its corporate and brand identity at every such instance. Even more importantly, any involved intermediaries such as Internet portals, Internet service providers (ISP's) and other advertisers are automatically subordinated. This is a key consideration for issuers who otherwise are at the mercy of such intermediaries. In summary, the invention provides protection from brand disintermediation from any such intermediaries.
  • ISP's Internet service providers
  • FIG. 1 there is illustrated an Internet service provider (ISP) 1 connected by communication links or network 2 to a plurality of merchant computers 3 and card holder computers 4, which card holder computers 4 will be used by the card holder to make necessary purchases ot goods and services from the merchant computers 3.
  • ISP Internet service provider
  • the card holder is identified in Fig. 1 separately by the reference numeral 4a since, strictly speaking, a card holder is not limited to using one, let alone the same card holder computer 4, each time to carry out the invention. All the other parties in the transaction do not need to be separately identified and can be referred to as being, for example, the merchant computer 3.
  • a card issuer 5 Connected to the Internet service provider 1 is a card issuer 5, which card issuer will include and have or have the services of a card issuer computer 6, a payment card information database 7, a message database 8 and a merchant database 9.
  • the merchant database 9 is linked to a merchant profile server 10 which stores relevant merchant information for a number of Internet service providers and card issuers. All of these may in fact be contained in the one card issuer computer, however, for convenience it is easier to separate them. Alternatively they may be contained on a separate Net Issuer computer as explained above.
  • the merchant computers 3 are in turn linked to merchant payment acquirer computers 11.
  • the communications link between merchant computer and its payment acquirer computer could be as shown by direct link, but could be via the ISP. All other communications links which could be or are established are not shown.
  • the first is the customer, namely the card holder having access to a card holder computer downloaded onto which is sufficient data from the card issuer to allow the card holder to contact the card issuer and display information as required.
  • the one card holder computer could service a number of card holders.
  • the card issuer computer is the second element in the transaction.
  • the card issuer computer carries all the payment card details, together with merchant information sufficient to allow a full transaction to be carried out.
  • the merchant then carries out the necessary payment request and purchase confirmation while the fourth party namely the merchant payment acquirer receives any funds that the merchant should receive for the delivery of the goods from the card issuer.
  • Figs. 2 to 4 inclusive it is presumed that the system has already been set up and that the card holder computer has sufficient information to allow the card holder to contact the card issuer and the card issuer already has merchant information and also merchant payment acquirer information sufficient to contact the merchant payment acquirer computer i.e. the ezCard is operative.
  • OPT has been used in the flowcharts in some of the boxes to indicate that an optional operation, step or procedure could be carried out. In certain cases the fact that they are optional will be immediately understood. For example, the card holder could immediately consider authorization of a particular request from a merchant, or alternative could wish to alter the request received from the merchant, before giving payment authorization, for example, changing shipping address and so on. To avoid unnecessary complications the term OPT has been used to indicate this.
  • step 20 the card holder computer has been in contact with the merchant computer and the card holder has filled out a shopping cart and transmits this to the merchant in step 21.
  • the merchant then downloads a payment form as a payment request in step 22 to the card holder computer for payment.
  • step 23 the card holder activates the ezCard usually by simply clicking an icon on the computer screen. This initiates a direct Internet-based communications session in step 24 between the card holder computer and the card issuer computer, so disintermediation is prevented.
  • the card holder's identity is authenticated to the card issuer by means of a username-password protocol or other conventional cryptographic authentication protocol, or by presentation of a digital "cookie" obtained from a third party as is described later.
  • step 25 the card holder sends purchase and merchant URL to the card issuer which now has available to it certain information. Simultaneously the card issuer starts to send messages to the card holder in step 26 and these messages continue to be sent to the card holder computer.
  • These messages can be various advertisements, dependent on the information already downloaded in relation to the merchant, they can be linked in some way to information already contained in the card issuer's computer about the card holder, they can be linked to the specific purchase of goods and services being initiated and so on.
  • step 27 the card issuer consults the merchant and cardholder databases and in step 28 the card issuer downloads the card holder data and merchant profiling information that is needed by ezCard to write the card holder data onto the appropriate data fields in the merchant form.
  • the data will now be displayed on the card holder's computer as a merchant form including such information as shipping address and credit card number in step 29.
  • any of the information downloaded from the card issuer can be altered by the card holder simply by typing new data into the appropriate data field on the merchant form, for example a different shipping address.
  • step 30 the card holder who now has the total data displayed considers authorisation of purchase to the merchant and may immediately proceed in step 31 to authorise payment with the merchant.
  • step 32 the card holder changes the purchase by altering the payment data that has previously been displayed in step 29, or, may alternatively decline the purchase in step 33.
  • the cardholder's decision to proceed with the transaction that it is to say carrying out step 31 is again communicated to the Merchant after step 32.
  • the merchant now wishes to obtain a payment authorization from the Card Issuer.
  • the conventional method for obtaining such payment authorization requires that the Merchant contact the Merchant acquirer computer in step 34 which computer contacts the Card issuer computer in step 35, usually by means of payment-card-association networks.
  • the Card issuer computer evaluates the authorization request using standard credit-risk data.
  • the card issuer in step 36 contacts the merchant payment acquirer to confirm the order and agrees to the payment terms and the acquirer bank confirms payment to the merchant.
  • the card issuer computer additionally issues a direct authorization confirmation message to the Merchant in step 37.
  • the card holder's decision to proceed with the purchase transaction in step 34 is also communicated to the Card Issuer in step 37.
  • the Card Issuer has all the information it requires to evaluate the authorization of the transaction including the payment card number and the purchase amount.
  • the Card Issuer knows the internet address (URL) of the merchant.
  • the card issuer computer can therefore generate and transmit an authorization decision to the Merchant directly in step 39, using a message protocol previously agreed upon, without the involvement of payment card-association computer networks.
  • Payment card associations typically assess a per-transaction fee for use of their networks in processing the authorization request and response corresponding to steps 34 and 35.
  • the optional method comprising steps 38 and 39 thereby provides a means for merchants to avoid such fees.
  • Step 40 is when the merchant confirms to the card holder that the transaction is accepted, see below. However, in some circumstances the merchant may wish to receive an authorization both from the card issuer directly, in step 37, and in addition an authorization indirectly, by proceeding to step 34 following step 39.
  • the card holder can optionally confirm the purchase to the card issuer in step 37 even if the merchant intends to utilize the conventional method of obtaining payment authorization, namely by submitting a payment request to its merchant acquirer computer in step 34.
  • the card issuer will be able to confirm that the card holder has indeed confirmed a purchase before the card issuer will confirm to the acquirer bank that the payment will be made.
  • step 40 the merchant confirms to the card holder that the necessary transaction has been accepted.
  • step 41 the card holder receives a final card payment form.
  • This final card payment form can be in any suitable format but will generally mirror the standard credit card payment slip and ideally one appropriate to the particular credit card.
  • This step completes the communication between the card holder and card issuer, and so at this time in step 44 the messages end to the card holder computer.
  • step 43 the card issuer completes the payment to the merchant payment acquirer following dispatch of the goods in step 42 by the merchant. It should be noted that the relative timing of steps 41 to 44 is affected by the type of product being delivered. If the purchase involves immediate delivery of goods such as electronic download of software or music then step 42 may precede steps 41 and 44, but if the purchase involves physical delivery of a product, then the usual warehouse, packing and shipping cycles typically dictate that step 42 follows step 41 by as much as several days.
  • the payment slip or document that is displayed by the card holder can be stored, can be delivered afterwards as a payment receipt and so on.
  • Typical merchant forms used in eCommerce comprise a set of field names (e.g. Street Address; PaymentCardNumber) and their corresponding values (e.g. 123 Park Street; 4650345626445678).
  • ECML Electronic Commerce Markup Language
  • the present situation is that every internet merchant uses different field names.
  • the invention requires a list specific to each merchant, known as a merchant 'profile', which list defines the association between the merchant field names and their corresponding entries in the card holder database.
  • the merchant profile contains in addition all other merchant-specific data that is required to populate the merchant form and to extract particular data values such as the total purchase amount from merchant-supplied web pages.
  • the merchant profile database comprises the set of all merchant profiles which are known to the card issuer computer.
  • the card issuer computer can instead attempt to guess the meaning of various field names on the merchant form based on a set of rules derived from previous experience. For example, the logic could search for character strings "St”, “Street” or "Addr” on the merchant form and tentatively associate them with the Street Address. These approaches can be combined to provide 100%-accurate profiles for some merchants and a reasonably accurate profile for all merchants.
  • the system can 'learn' the profile for a previously-unknown merchant by observing the cardholder type data inputted into the merchant fields and comparing said data to entries in the card holder database.
  • the system can continuously update its merchant profiles and look for changes to them by recording how often card holders alter the data on the merchant form that is automatically populated by the ezCard.
  • the merchant profile database may be started with a reasonably small number of merchants which is extended over time.
  • the separate merchant profile service (10 in Fig. 1) retains a master database of known merchant profiles, which are continuously updated and this will ensure that the merchant database (9 in Fig. 1) will be continuously updated. This means that when, for example, there is any change in a merchant profile this is sent to all card issuers connected in the particular network to that Internet service provider, or indeed connected to other Internet service providers.
  • Fig. 5 there is illustrated the functional operation of the invention insofar as the parties to the transaction view it and in this drawing the electronic element of the card issuers' operations are separated from the normal card issuer's operations which are identified as the card issuer's back office and the former is identified by the term net issuer.
  • Card issuer installs the system on a secure server at their site, or the site of an outside service provider.
  • a target group of cardholders is identified who would be active users of electronic cards, based on purchases previously charged to card accounts (such as recurring ISP charges, computer and software purchases, or purchases at Internet merchants such as amazon.com or peapod.com).
  • a cardholder extract file is built of card account details and is exported to the system.
  • the system is customized for appearance, ezCard security features, and the advertising server to deliver targeted messages to cardholders when they use their ezCards.
  • a promotional mailer is made to card-holders in the target market group announcing ezCard to cardholders including instructions, initial password, and Issuer's unique resource locator (URL).
  • the system accesses the associated account and asks for personal information such as "Mother's Maiden Name” or PIN to confirm her identity. Cardholder selects a button “Click to Activate your Electronic Card”. The system then downloads, installs, and launches ezCard. The minimal information to subsequently initiate ezCard is all that is stored on the card holder computer. Cardholder chooses a personal password, or has one assigned depending on the policies imposed by the issuer bank and enters shipping address, e-mail address, and phone number. ezCard is then ready for use.
  • the system issues tracking certs, or other tracking mechanisms, for license control and audit trails.
  • CA Certificate Authorisation
  • a cardholder could also apply on-line for a card 9. If approved, ezCard could be issued in real-time and a physical card mailed.
  • Cardholder goes shopping at an Internet merchant, finds what he wants, and places it in his shopping cart. When he is ready to buy, the merchant web site asks for address and payment information.
  • ezCard launches in another window, which displays card issuer logo and advertising, shows the name and graphical representation of associated physical details of the card (not the number or expiry), and requests a password.
  • the password may be checked by the Netlssuer, or it may be checked by a third party as described below, which upon successful authentication, transmits a digital file to the card holder computer that is subsequently presented to Netlssuer to validate the cardholder's identity. Following authentication, the Cardholder then drags ezCard to merchant's payment page to auto-fill the form.
  • EzCard sends merchant's URL to the system to see if it is in the merchant profile database
  • ezCard sends cookie (if available for use) to the system, and receives targeted advertising message from a database
  • payment page is auto- populated, with ezCard automatically filling out the necessary information on the merchant site (cardholder name, address, e-mail, card details, etc)
  • New profiles are then distributed to all the system merchant profile databases on a recurring basis, resulting in all the system customers benefiting from the sum total of all cardholder purchase activity.
  • payment information manually entered by a cardholder can serve as the basis for preliminary profiling on a previously unknown merchant page.
  • the system can also connect to a fraud detection service for fraud screening. Fraud screening could extend to authenticating the merchant in question, or identifying fraudulent use (e.g. theft) of the physical card associated with an ezCard that is valid.
  • the cardholder After payment is authorized, the cardholder receives a graphical representation of a charge slip that psychologically reinforces the fact that a payment transaction was completed - a key factor to cardholder comfort level and ease of mind
  • This sales receipt can be sent via e-mail, stored within the system, or on the card-holder's PC and can be used as any payment slip in a card-present transaction.
  • Fig. 6 there is illustrated in broad outline another arrangement of an eCommerce network for carrying out the invention which is substantially similar to the eCommerce network illustrated in Fig. 1 and thus the same reference numerals are used to identify similar parties and parts.
  • a party authenticator namely, party authentication computer 15, which facilitates an alternative method of authentication whereby the card holder authenticates himself or herself not to the card issuer computer 6 directly, but to the separate party authentication computer 15 operated by a party authentication server.
  • party authentication operated by a party authentication server.
  • the authentication will be done in the usual way using a user name and password combination entered by the card holder and verified against a database maintained by the authentication server. While the details of how the authentication is performed are unimportant, what is important to note is that a web server other than the card issuer computer authenticates the card holder computer.
  • the party authentication computer 15 downloads back to the card holder computer a small standard file known as a "cookie" which contains the information that will authenticate the card holder to the card issuer computer and in one embodiment the cookie contains the payment card account number in encrypted form and an expiration date for the cookie.
  • a cookie contains the payment card account number in encrypted form and an expiration date for the cookie.
  • Figs. 7 and 8 illustrate in flowchart form, in a slightly simpler way, the principal features of the invention.
  • This flowchart illustrates the principal steps in a method of carrying out the invention as laid out in Fig. 6. However, it illustrates very clearly the operation of the present invention eliminating many of the optional and extraneous steps.
  • step 120 the card holder fills out a shopping cart and in step 121 , a purchase request is sent to a merchant.
  • the merchant will then download a payment form to the card holder computer in step 122.
  • the card holder then activates ezCard on the card holder computer in step 123.
  • step 124 the card holder computer opens direct communication with the card issuer computer and thus there is now direct communication between the card holder and the card issuer. This allows the card issuer to send messages to the card holder computer and hence to the card holder in step 125. As explained above, these messages will only be sent at appropriate times.
  • the card holder computer will immediately send merchant URL to the card issuer in step 126.
  • the card holder authenticates his or her identity to the card issuer with a password. This is absolutely essential because it is not sufficient for the card issuer to identify the message coming from what would appear to be an appropriate card holder computer but the card issuer must identify the particular card holder as more than one card holder could use the same computer or indeed a card holder could, for example, at certain times, use a mobile phone and at other times, a computer. This authentication is described below.
  • the card issuer reads card holder and merchant profile information from the database.
  • the card issuer may record the successful authentication of the card holder in the database. In many instances, this would be desirable.
  • step 130 the card issuer downloads card holder data and merchant profile data to the card holder computer.
  • step 131 the card holder data is entered automatically onto the merchant payment form in the sense that the card holder does not have to do anything as it is done simply following step 130.
  • step 132 there is the optional step of the card holder modifying some information on the card merchant payment form. This would often happen at the last moment.
  • step 133 the card holder considers payment authorization and can then either abort the transaction in step 134 or effectively accept the transaction by sending the completed payment form to the merchant computer in step 135. This illustrates the invention relatively simply without additional complications.
  • step 140 the card holder activates the method according to the present invention by opening the direct communication with the card issuer computer 6, namely step 124. Also at some point in the purchase transaction the card holder computer in step 140 contacts the separate party authentication computer 15 which is operated by a separate web server. Step 140 is shown in Fig. 7 as typically following step 124, but it is not necessary that step 140 be initiated by the ezCard in step 124 indeed some card issuers would like their card holders to establish a web connection to an authentication party computer independently. Logically, step 140 can be carried out anytime before steps 125 and 126.
  • step 141 the party authentication computer 15 requests authentication information from the card holder computer such as, for example, user name and password.
  • the server checks this information against a user database and if this information matches a valid record in its user database, the server looks up the corresponding payment card number.
  • the web server generates in step 143 a cookie with this number plus the cookie's expiration date which is determined from the local time, plus a defined validity period. These would normally be transmitted in encrypted form.
  • step 144 the cookie is downloaded automatically to the card holder computer. Then in step 145 at some suitable time the card holder computer uploads to the card issuer computer 6 the cookie.
  • this cookie is checked by the card issuer computer in step 146, and if the cookie is deemed valid then the card holder's identity has been authenticated and the logic proceeds to steps 128 and 129 just as if the card holder ' s identity had been verified directly by the card issuer.
  • Authentication could also be by a digital certificate, a shared secret key, or some other means.
  • the cryptographic details of how this authentication is performed are unimportant for purposes of this invention; what is important is that there are two alternate paths to the authentication: either directly with the card issuer computer or indirectly, with a party authentication computer that communicates with the card issuer computer with a cookie.
  • the way in which the card holder computer authorizes a transaction or payment to the card issuer computer can be carried out in many ways and will be based on the authorization procedures or protocols previously established between the card holder computer and the card issuer computer. For example, these could be credit risk data previously established. It could mean that before the card issuer computer would authorize a payment, the card holder computer would have to positively confirm that payment was to be made by authorizing it. Alternatively, these rules could be based on values of transactions. Thus, for example, once a transaction was below a certain monetary sum, then the card issuer computer on being satisfied in accordance with whatever rules it has established in regard to the identity of the card holder computer, then the authorization could be made.
  • the card issuer would not require any further authorization from the card holder to authenticate the payment. Again, this could be controlled by various rules which would obviate the possibility of fraud.
  • authorisation could be established based on authorisation protocols previously agreed between the merchant payment acquirer and both the card issuer and the merchant, or between the card issuer and the acquirer. There is strictly speaking no limit to such protocols and any desired protocol may be accommodated by the invention. Again it may be obtained if desired in real time.
  • the information and data is downloaded directly onto the card users computer all the card user requires, presuming that the computer has the normal mouse control, is to simply point at various command icons, click once and the information is downloaded.
  • the advantage of this is that all the information is entered onto the merchant payment page as if it was entered manually by the card holder it is envisaged that the information will be transmitted by encryption and, for example, it is envisaged that various suitable encryption systems may be used, such as Secure Sockets Layer (SSL), this encryption system which is widely used over the Internet provides up to 128 bit data encryption support. It is envisaged that the encryption can also be by secure electronic transmission (SET), Cert-Less Set, Merchant-Originated set (MOSET), or indeed any other encryption system.
  • SSL Secure Sockets Layer
  • the invention provides a method for a card issuer to control the flow of information to a card holder sales transaction. Further it provides a method based sales system for payment cards and as already mentioned, this is essentially a computerised method.
  • the invention particularly provides a method for the secure transfer of payment and related purchase information and in particular computer messages for the secure transfer of payment.
  • a computer readable medium for use in the secure transfer of payment and related purchase payment information for a credit card transaction which will comprise various instruction codes, such as an instruction code for receiving information relating to a purchase form a card holder computer at a card issuer computer, some instruction code for authenticating a payment required, instruction code for transmitting card holder and payment card information to the card holder computer and in general instruction code for carrying out the method according to the invention.
  • instruction codes such as an instruction code for receiving information relating to a purchase form a card holder computer at a card issuer computer, some instruction code for authenticating a payment required, instruction code for transmitting card holder and payment card information to the card holder computer and in general instruction code for carrying out the method according to the invention.
  • a further advantage of the present invention is that it will allow card issuers to target their card holders with very specifically designed advertising. They already have a considerable amount of information on their card holders by virtue of an analysis of previous purchases from which they always build up card holder profiles. Using these card holder profiles and in particular the specific information given to them at each purchase, whether it be information in relation to the merchant being purchased from, or the actual items being purchased, the card issuer has a unique opportunity to very clearly target the advertising messages to the card holder. Further, in many situations during a purchase operation there will be time lags, indeed in the actual operation itself which can be utilised and further the card issuer can determine the length of these time lags.
  • Another major advantage of the present invention is that minimal card holder information needs to be stored on the card holders computer, while the bulk of the card holder information can be stored on the card issuers computer, or secure server.
  • the completed merchant payment form can be supplemented by a new format identical to that of a completed card issuer payment slip which the card holder will be familiar with.
  • a mobile phone could be easily configured to carry out the functions described above.
  • Using a mobile phone as the communication device for a card holder offers several advantages including more reliable authentication of the card holder's identity, since a mobile phone is typically supplied with built-in electronic hardware that identifies itself to the phone network.
  • there is a market advantage owing to the fact that there are currently four times as many mobile phones in service compared to personal computers.

Abstract

L'invention concerne un procédé permettant des transferts de paiement sécurisés sur un système de vente en réseau. Le système comporte plusieurs ordinateurs (4) détenteurs de cartes, un ordinateur émetteur de cartes (6), des ordinateurs vendeurs (3) et au moins un ordinateur acquéreur de paiements des ventes (11). Des détails de compte de détenteurs de cartes sont stockés dans une base de données sécurisée (7) par l'ordinateur émetteur de cartes (6). Lorsqu'un détenteur de carte (4a) souhaite effectuer une transaction avec un ordinateur vendeur (3), l'ordinateur détenteur de cartes établit une communication avec l'ordinateur émetteur de cartes (6), puis le détenteur de la carte (4a) doit saisir son mot de passe ou le NIP de son compte. La transaction est autorisée par l'ordinateur émetteur de cartes (5), autorisation ensuite transmise soit directement à l'ordinateur vendeur (3) soit indirectement par l'intermédiaire de la compagnie bénéficiaire du paiement des ventes (11). L'invention se caractérise par les aspects importants suivants : a) le numéro de compte du détenteur de carte relatif au paiement est permanent et utilisé à maintes reprises au cours de nombreuses transactions et b) chaque transaction se voit allouer un canal de communications consacré entre l'ordinateur détenteur de cartes (4) et l'ordinateur vendeur (3) dans lequel l'ordinateur émetteur de cartes (5) peut inscrire des informations relatives au compte.
EP00958954A 1999-09-22 2000-09-07 Procede de transfert de paiements securise Withdrawn EP1214696A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP00958954A EP1214696A1 (fr) 1999-09-22 2000-09-07 Procede de transfert de paiements securise

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US567975 1995-12-06
EP99650088A EP1087350A1 (fr) 1999-09-22 1999-09-22 Méthode pour transferts de paiement sécurisés
EP99650088 1999-09-22
US20067200P 2000-04-28 2000-04-28
US200672P 2000-04-28
US56797500A 2000-05-10 2000-05-10
PCT/IE2000/000101 WO2001022374A1 (fr) 1999-09-22 2000-09-07 Procede de transfert de paiements securise
EP00958954A EP1214696A1 (fr) 1999-09-22 2000-09-07 Procede de transfert de paiements securise

Publications (1)

Publication Number Publication Date
EP1214696A1 true EP1214696A1 (fr) 2002-06-19

Family

ID=56290054

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00958954A Withdrawn EP1214696A1 (fr) 1999-09-22 2000-09-07 Procede de transfert de paiements securise

Country Status (3)

Country Link
EP (1) EP1214696A1 (fr)
AU (1) AU7035700A (fr)
WO (1) WO2001022374A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10943216B2 (en) 2015-10-27 2021-03-09 Mastercard International Incorporated Systems and methods for updating stored cardholder account data

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2400960B (en) 2001-05-02 2004-12-29 Virtual Access Ltd Secure payment method and system
AU2002256770A1 (en) * 2001-05-02 2002-11-11 Virtual Access Limited Secure payment method and system
CA2741437C (fr) 2008-10-24 2018-02-13 Cardlytics, Inc. Systeme et procede pour presenter des offres de commercialisation ciblees aux consommateurs via un portail en ligne
US11348150B2 (en) * 2010-06-21 2022-05-31 Paypal, Inc. Systems and methods for facilitating card verification over a network
US8335921B2 (en) 2010-12-17 2012-12-18 Google, Inc. Writing application data to a secure element
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
US9008616B2 (en) 2011-08-19 2015-04-14 Google Inc. Point of sale processing initiated by a single tap
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8255687B1 (en) 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US9390414B2 (en) 2011-09-18 2016-07-12 Google Inc. One-click offline buying
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
US8774721B2 (en) 2012-04-10 2014-07-08 Google Inc. Detecting a communication tap via signal monitoring
WO2015175033A1 (fr) 2014-05-16 2015-11-19 Cardlytics, Inc. Système et appareil de mise en correspondance d'identifiants et de gestion
US11526881B1 (en) 2016-12-12 2022-12-13 Dosh Holdings, Inc. System for generating and tracking offers chain of titles
US11488190B1 (en) 2016-12-12 2022-11-01 Dosh, Llc System for sharing and transferring currency
US11538052B1 (en) 2016-12-12 2022-12-27 Dosh Holdings, Inc. System for generating and tracking offers chain of titles
US10992738B1 (en) 2019-12-31 2021-04-27 Cardlytics, Inc. Transmitting interactive content for rendering by an application

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995016971A1 (fr) 1993-12-16 1995-06-22 Open Market, Inc. Publicite numerique active
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5715314A (en) 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
JP3133243B2 (ja) * 1995-12-15 2001-02-05 株式会社エヌケーインベストメント オンラインショッピングシステム
US5822737A (en) * 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
WO1999003076A1 (fr) * 1997-07-09 1999-01-21 Countrywide Business Alliance, Inc. Systeme et procede de paiement automatise
EP1010149A1 (fr) * 1997-08-26 2000-06-21 The Chase Manhattan Bank Appareil et procede de traitement automatise d'achats de produits et de validations de transactions d'achats
EP1021802A2 (fr) * 1997-09-17 2000-07-26 Akos Andrasev Procede de controle de l'utilisation legitime d'une carte de debit ou d'un moyen similaire donnant droit a disposer d'un compte bancaire
US5883810A (en) 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
NL1008372C2 (nl) * 1998-02-20 1999-08-24 Snoek Holding Zoetermeer B V Werkwijze voor betalen via Internet.

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0122374A1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10943216B2 (en) 2015-10-27 2021-03-09 Mastercard International Incorporated Systems and methods for updating stored cardholder account data
US11687893B2 (en) 2015-10-27 2023-06-27 Mastercard International Incorporated Systems and methods for updating stored cardholder account data

Also Published As

Publication number Publication date
AU7035700A (en) 2001-04-24
WO2001022374A1 (fr) 2001-03-29

Similar Documents

Publication Publication Date Title
US10872343B2 (en) Secure and efficient payment processing system
US9123039B2 (en) System and method of a passphrase account identifier for use in a network environment
TW544605B (en) System for facilitating a transaction
US10825016B2 (en) Electronic bearer bond online transaction and card system and method thereof
US20020016749A1 (en) Methods and systems for network based electronic purchasing system
US20040148254A1 (en) Method for performing a secure cash-free payment transaction and a cash-free payment system
US20070185781A1 (en) Method for anonymous purchase of goods by providing a plurality of account numbers
EP1214696A1 (fr) Procede de transfert de paiements securise
US20060242058A1 (en) Transaction system
US20080306877A1 (en) Secure Internet E-Commerce
JP2004507842A (ja) 電子商取引による電子領収書管理システム及びその方法
AU775065B2 (en) Payment method and system for online commerce
JP2002150195A (ja) 電子決済システム、電子決済方法
KR20020064473A (ko) 전자지갑과 통합된 전자 지불 보증 서비스 시스템 및 그방법
KR100509027B1 (ko) 사이버 분할 카드 제공 방법 및 시스템
WO2002058018A2 (fr) Procede et systeme de paiement, et carte de paiement utilisee avec ledit systeme
EP1087350A1 (fr) Méthode pour transferts de paiement sécurisés
KR20040055752A (ko) 분할 카드 제공 및 결제처리 방법
KR20040047761A (ko) 사이버 분할 카드 제공 및 결제처리 방법
WO2002086650A2 (fr) Systeme facilitant les transactions
JP2001229223A (ja) 商品の販売・決裁方法、電子商取引組織、及び電子商取引機構
KR20040047763A (ko) 분할 카드 제공 및 결제처리 방법
AU2002255206A1 (en) A transaction facilitation system
KR20040047762A (ko) 분할 카드 제공 및 결제처리 방법
KR20040047764A (ko) 분할 카드 제공 및 결제처리 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020412

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20020812

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20021224