WO2000002150A1 - Procede d'autorisation de transaction - Google Patents

Procede d'autorisation de transaction Download PDF

Info

Publication number
WO2000002150A1
WO2000002150A1 PCT/AU1999/000536 AU9900536W WO0002150A1 WO 2000002150 A1 WO2000002150 A1 WO 2000002150A1 AU 9900536 W AU9900536 W AU 9900536W WO 0002150 A1 WO0002150 A1 WO 0002150A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
merchant
customer
code
address
Prior art date
Application number
PCT/AU1999/000536
Other languages
English (en)
Inventor
Julien Gaston Robert Renard
Original Assignee
Webcard Inc.
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 AUPP4439A external-priority patent/AUPP443998A0/en
Priority claimed from AUPP5211A external-priority patent/AUPP521198A0/en
Application filed by Webcard Inc. filed Critical Webcard Inc.
Priority to AU45926/99A priority Critical patent/AU4592699A/en
Publication of WO2000002150A1 publication Critical patent/WO2000002150A1/fr

Links

Classifications

    • 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/12—Payment architectures specially adapted for electronic shopping 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/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present invention relates to a system and method of conducting a transaction between a customer and a merchant located remotely from each other.
  • the present invention also relates to a method of validating a financial transaction between a customer and a merchant.
  • the present invention further provides a method for ensuring the delivery of goods or services to the correct address of the customer.
  • a customer uses a credit card or debit card or the like to provide funds to the merchant for the transaction.
  • the customer requires to initiate and complete a transaction remotely, for example, over the Internet or by telephone or by post, the customer is required to provide to the merchant their credit card number and its expiry date.
  • These details may be transmitted across insecure channels, particularly over the Internet which is an open communications network, where a third party may be able to access or alter the data in transit and fraudulently use the credit card number and expiry date for subsequent transactions for some time without the knowledge of the customer or cardholder.
  • unscrupulous merchants may store or hold credit card information for fraudulent use at a later time or this information may be stolen and used by criminals to make fraudulent purchases.
  • the merchant will access a database of known credit card numbers that are to be refused approval for transactions for one reason or another. Provided the credit card number is a valid number and is not on that database, the merchant will obtain authorisation of the transaction and deliver the goods to the address specified by the customer without actually receiving funds from the customer's bank into the merchant's bank account. Such a transfer of funds is generally performed after the goods have been distributed to the customer. Therefore there is much emphasis or onus placed on the merchant to actually obtain the funds from the customer.
  • SSL secure socket layer
  • the present invention desirably provides a system and method for conducting a transaction which does not require complex encryption technologies, requires the customer or account holder to be responsible for approving the transaction, requires a pre-arranged delivery address to be supplied by the customer and, most importantly, does not require the customer to transmit their card number or account information across an open and unsecured communications channel. Furthermore, the present invention desirably ensures delivery of goods of the customer and payment of funds from the correct account to the account of the intended merchant when the transaction is conducted using a communications network.
  • a method of conducting a financial transaction between a customer and a merchant wherein said customer is remotely located from said merchant and said customer having an account associated with a credit card or debit card or the like from which funds for said transaction will be drawn by said merchant, said merchant having a Merchant Code for use in said transaction, the method comprising the steps of: providing a Transaction Code to said customer for use in said transaction as a substitute for the account number of said customer; establishing an Address Code for said customer that represents a delivery location for goods and/or services provided by said merchant to said customer; wherein in order to authorise said transaction, said customer provides said merchant said Transaction Code such that the account number of said customer is not disclosed to said merchant.
  • the method may include linking the Address Code to a physical address location.
  • the Address Code may also be linked to an electronic address that is mapped to a physical address location.
  • a method of validating a financial transaction between a customer and a merchant comprising the steps of: establishing an Address Code for said customer, said Address Code representing a delivery location for goods and/or services provided by said merchant to said customer; matching said Address Code to a physical address of said customer; providing a data storage means for storing said Address Code and associated physical address; wherein use of said Address Code in said financial transaction ensures that delivery of said goods and/or services is to the address nominated by said customer and thereby validates said transaction.
  • the method may include linking the Address Code to an electronic address mapped to the physic ⁇ ⁇ e ⁇ in ⁇ g ⁇ n ⁇ ⁇ oods and/or services are transmitted electronically to the customer.
  • the customer may request a Transaction Code for use in the transaction as a substitute for a number of an account of the customer from which funds are drawn by the merchant.
  • a system for conducting a financial transaction between a customer and a merchant wherein said customer is remotely located from said merchant and said customer having an account associated with a credit card or debit card or the like from which funds for said transaction will be drawn by said merchant, said merchant having a Merchant Code for use in said transaction
  • the system comprising: a first storage means for storing a Transaction Code for use in said transaction, said Transaction Code being a substitute for the number of said account of said customer; means for transmitting said Transaction Code to said customer in response to a request by said customer for approval for said transaction; and a second storage means for storing an Address Code, said Address Code being linked to a delivery location nominated by said customer where goods and/or services provided by said merchant as part of said transaction are to be delivered; wherein in order to authorise said transaction, said customer provides said merchant said Transaction Code such that said account number of said customer is not disclosed to said merchant.
  • the delivery location may be a physical address or an electronic address mapped to a physical address.
  • a method of ensuring correct delivery of goods and/or services to a customer from a merchant as a result of a remote transaction between said customer and said merchant comprising the steps of: establishing a storage means for storing one or more Address Codes, wherein each stored Address Code represents a delivery location for receipt of said goods and/or services; matching said Address Codes to respective physical addresses in said storage means; and accessing said stc ⁇ TI r ⁇ e ⁇ ⁇ E ⁇ d ⁇ c t ⁇ e ⁇ e, a corresponding delivery location on entering an Address Code, or in order to retrieve an Address Code corresponding to an entered delivery location.
  • Figure 1 is a block diagram of a system used for conducting a financial transaction between a customer and a merchant in accordance with the invention
  • Figure 2 is a flow diagram depicting the process of a customer seeking remote transaction facilities
  • Figure 3 is a flow diagram depicting the process involved in conducting a transaction and the merchant making a claim for payment in accordance with the invention.
  • Figures 4(a), 4(b) and 4(c) are schematic diagrams showing examples of the contents of a second storage means in accordance with the present invention.
  • Figure 5 is a schematic diagram of the contents of an Issuer database
  • Figure 6 is a schematic diagram of the contents of a database controlled by a Transaction Authority or an Issuer
  • Figure 7 is a schematic diagram of the contents of a customer database.
  • the merchant's account may be held by an Acquiring Institution (hereinafter referred to as "Acquirer”) which may be a bank or other financial institution making remote transaction facilities available to merchants wishing to make sales to customers located remotely from the merchant and accepting funds from a customer's account for deposit to the merchant's account.
  • Acquirer Acquiring Institution
  • the Issuer may be a bank or other financial institution making remote transaction services available to a customer via an account held by the customer at the Issuer and making transfers of funds at the request of the customer from the customer's account to a merchant's account.
  • Issuer may have access to a Transaction Authority (hereinafter referred to as a
  • Transaction Services organisation or group of organisations entrusted by Issuers and Acquirers with the information necessary to approve transactions and route requests regarding transactions to the appropriate financial institutions.
  • the Issuer On receipt of a customer request for remote transaction facilities, the Issuer will go through the necessary checks to enable such facilities, including rigorous identification of the customer, and then issues to, or obtains from, the customer a password or other identifying information, such as a pass phrase, PIN, number, code, or biometric data (“Passcode”) that is known only to the customer and to the Issuer, for use when communicating with the Issuer.
  • the Passcode may be used by an Issuer to authenticate the identity of a customer requesting a Transaction Code (to be described hereinafter) for a remote transaction.
  • the procedures to be followed and identification to be used will typically vary from Issuer to Issuer and the modes of communication agreed between customer and Issuer will typically also vary to suit local conditions and banking, legal or social requirements.
  • the customer also provides to the Issuer at least one physical address, and, if desired, an electronic address with a corresponding physical address. This address will be used as a delivery location for delivery of goods or services by merchants.
  • the physical address including the physical address associated with the electronic address where applicable, will be converted into a unique numerical Address Code which is stored by the Issuer in a database 31 and is supplied to, or may already be known to the customer from a second storage means 27 storing Address Codes and matching them to delivery locations nominated by the customer.
  • the customer is then equipped to initiate remote transactions, that is transactions not involving the physical presence of a card or the customer.
  • remote transactions that is transactions not involving the physical presence of a card or the customer.
  • the customer will usually contact that merchant by post, e-mail, facsimile, telephone or through the Internet. 5, or their telephone 2, facsimile machine 4 or personal computer (PC) 6 to communicate with the merchant's telephone 8, facsimile 10 or PC 12 respectively.
  • the customer may use a communications network such as Public Switched Telephone Network (PSTN) 14 when contacting the merchant by either telephone or facsimile or electronic mail. In situations where a mobile telephone 3 is used, a corresponding mobile telecommunications network may be used.
  • PSTN Public Switched Telephone Network
  • the merchant may be contactable through mobile telephone 9.
  • Electronic mail may be transmitted between the customer's personal computer 6 via modem 16 over the PSTN 14 or Internet 20 and through modem 18 of the merchant and direct to the merchant's PC 12.
  • the customer may communicate with the merchant over the Internet 20 through their respective PCs 6 and 12 and respective modems 16 and 18 or through any other channel which is or will become available and is considered suitable for such communication.
  • the customer While communicating with the merchant, the customer will obtain an approximate price for the goods and/or services they require from the merchant together with a Merchant Code identifying the merchant.
  • a Merchant Code which is a publicly advertised number which may be assigned by a financial institution, such as the Acquirer, providing the remote transaction facilities to the merchant. This code could in principle be the existing merchant number as currently used for credit card transactions, however, an Address Code belonging to the merchant may be registered for use as the Merchant Code.
  • the customer will then contact their Issuer 22 usually by the telephone 2, facsimile 4, through the Internet 20, or even by using an automatic teller machine (ATM) and the customer will supply to the Issuer 22 the following information:
  • the items of information in (a), (d) and (e) may be conveniently stored in an Issuer database 31, an example of which is shown in Figure 5. It is to be noted that multiple Address Codes 32 may have been supplied by the customer when applying for the facility and in such case one will need to be selected, either explicitly or by reference. Details on the customer account status and balance are also stored in the database 31.
  • the database 31 is maintained by the Issuer in a secure and private manner.
  • the use of an Address Code belonging to the customer and corresponding to a pre-arranged delivery address (goods or services will be delivered only to the legitimate address of the customer) has the effect of making the system secure such that there is no essential requirement to encrypt information sent to the Issuer by the customer over an open channel, such as the Internet.
  • the customer when communicating with the Issuer via the Internet 20 may use an encryption protocol such as the SSL so that any account information or Passcode transmitted from the customer to the Issuer is secure.
  • an encryption protocol such as the SSL
  • the process could be quite transparent to the customer by using appropriate software in conjunction with the browser that the customer is using for the World Wide Web of the Internet.
  • a range of Passcodes could be used to cater for different methods of customer to Issuer communications.
  • the customer is communicating with the Issuer by telephone or electronically, instead of the Issuer requesting the entire Passcode from the customer, they may request only certain digits or characters out of the full digit string of the Passcode.
  • the particular digits requested out of the string may be determined by a randomising function of the Issuer's computer system so that the same digits are not requested by the Issuer on each occasion that a Transaction Code is requested by the customer.
  • the Issuer may on one occasion request only five out of sixteen digits that make up the entire Passcode, requesting the third, fourth, eighth, thirteenth and fifteenth digits and on another occasion may request six digits, say ⁇ u ⁇ 2 ⁇ ⁇ )/ ⁇ vj th and twelfth digits for another Transaction Code request.
  • the Transaction Code may be a number assigned by a TSC on request from a customer relayed by an Issuer, relating to a particular transaction between a merchant holding a valid Merchant Code and a customer having an account with an Issuer, and relating to a particular Address Code representing a delivery address for the customer and a particular amount or Limit Amount.
  • TSCs 24 may also have information stored in a database 26 relating to the available credit and status of the card or account together with other identifying information about the customer and selected merchant for a transaction. This information together with the Merchant Code may be transmitted from the TSCs 24 to the Issuer 22 over the PSTN 14 or by proprietary protocols internal to the Issuer and TSCs as currently used or that may be used in the future.
  • the Address Code is uniquely linked to a corresponding physical address, or an electronic address mapped to a physical address which uniquely identifies the location to which the goods or services will be delivered. Address Codes may be stored in a second storage means, such as a database 27 accessed publicly through the Internet 20.
  • the Address Code is a numerical code explicitly identifying a particular delivery location on the Earth, derivable by mathematical calculation from survey data and published when activated in the publicly readable database 27 which is securely maintained by, for example the Transaction Authority or other entrusted bodies.
  • the e- mail, Internet or other electronic address is linked to an Address Code representing a real physical address and this linked electronic address is also stored in the publicly readable database 27 thereby enabling protection against fraudulent use.
  • the code for the physical address (the "Address Code") may be constructed in a number of ways, but it is desirable that it be a numeric code of similar dimensions to current credit card numbers and capable of automatic processing by computer software. It is also essential that it have a one-to-one correspondence to actual points on the Earth, these points being actual or potential delivery points for customers. For example, every position on the Earth may be identified by a series of numbers.
  • the Earth has a circumference of approximately 40,000 kms (40,000,000,000 mm) which could be divided into points of longitude spaced 400 mm apart at the equator (less at other latitudes and declining to zero at either pole) and into points of latitude spaced 200 mm apart.
  • the points of latitude may tally 100,000,000 points also, spaced apart by 200 mm and represented by a further 8 digits.
  • An additional dimension, being altitude or virtual altitude, could be represented by a further 3 digits representing 1000 points at a certain position of latitude and longitude, more than enough for a high-rise apartment or points for post office boxes or other densely spaced addresses.
  • the virtual altitude could be represented by the numbers 1 to 20 indicative of the box number or part thereof.
  • a final digit may be used as a check sum giving a total of 20 digits for the complete Address Code.
  • a virtual grid covering the entire Earth and corresponding in an unambiguous mathematical way with established points of latitude and longitude could be constructed with each potential delivery point assigned a unique code.
  • the Address Codes may thus be derived by mathematical calculation from survey data of latitude and longitude. This particular method of constructing Address Codes is by way of example only and it will be apparent to those skilled in the art that other algorithms for uniquely reducing a latitude and longitude for a numerical code may equally serve.
  • An Address Code once established and if approp ⁇ ate, a particular apartment or post office box, etc. would typically be stored in a securely maintained (for example by TSCs) and publicly readable (for example via the Internet) database, with the database having a cross-correlation to the associated physical and (if applicable) electronic address, so that customers, Issuers, TSCs and merchants can check the Address Code supplied against the physical or electronic address of the customer or vice- versa.
  • Address Codes may have a myriad of other uses including routing for postal services and the like, delivery of and billing for, utilities such as electricity, water, telephone, etc., and any other commercial functions where the address for delivery is important.
  • the Address Code relates to a particular place and is recorded in the public database 27 the data of which may be independently verified (and is therefore not forgeable provided the database is securely maintained) while the link with a particular Address Code is made by a person on specific request and that link is stored in a secure, private database thus preserving privacy.
  • Figures 4(a) to 4(c) show examples of the database 27 that can be used for maintenance and operation of Address Codes.
  • a user will access the database and if the user knows the Address Code will input this code at 200 to obtain an output latitude and longitude corresponding to the input Address Code at 202.
  • a known latitude and longitude may be input at 204 to obtain a corresponding output Address Code at 206.
  • This database may be implemented using calculating software and links every unique geographical point on Earth to a unique numerical Address Code or range of Address Codes.
  • the Address Codes are derivable by calculation from longitude and latitude, as previously mentioned, and where the database is published it can be securely maintained by a suitable entrusted body.
  • FIG 4(b) a database linking all active Address Codes to a corresponding deliverySl a ⁇ afe ' g ⁇ TQ P5J ⁇ u ⁇ ef R 9 W ⁇ ss, P.O.Box number or apartment number or similar, is shown.
  • a user knowing the Address Code may input this at 208 to obtain as an output a corresponding street address at 210.
  • a user knowing the street address or delivery address may input this at 212 to obtain a corresponding output Address Code at 214.
  • the database can be publicly readable over the Internet 20, is securely maintained and is verifiable by calculation from survey data.
  • FIG. 4(c) there is shown a further example of a database 27 which links active Address Codes to corresponding electronic addresses for delivery of goods and/or services, for example, e-mail or various files.
  • a user knowing the Address Code may input this at 216 to receive a corresponding electronic address as an output at 218.
  • knowledge of the electronic address at 220 may be input to receive or check a corresponding Address Code as an output at 222.
  • this database may be publicly readable and securely maintained and amended only by an entrusted authority or body such as the TSCs 24. It is to be noted that personal data is not contained in any of the above public database examples.
  • a Person may have one or more Address Codes and one or more Persons may share an Address Code (corresponding to a delivery address) although in principle sufficient Address Codes exist for more than one to be assigned to the same street address, therefore making it possible for individuals sharing a delivery address to be assigned distinct Address Codes.
  • the Address Codes however, correspond to addresses rather than persons, at least publicly, and privacy is thereby maintained.
  • the TSCs 24 will obtain or generate from a first storage means, such as database 29 storing a multitude of useable, potential Transaction Codes a Transaction Code which relates only to a particular transaction involving a specific Merchant Code and specific Address Code as requested by the customer and corresponding to a delivery address specified by the customer when originally requesting the remote transaction facilities.
  • This Transaction Code is then transmitted to the Issuer and is also stored in the database 26 of the TSC together with Issuer details, customer account number.
  • Merchant Code, limit amount, time limit (if applicable) data stored in database 26 is shown in Figure 6.
  • the database 26 may be maintained by the one or more TSCs and/or the Issuer wherein various responsibilities may be shared or delegated between the TSCs and the Issuer
  • the database 26 is private and highly secure.
  • the Issuer will in turn transmit this Transaction Code to the customer over a transmitting means, such as the PSTN 14 or the Internet 20 or through ATM connections or other Issuer to customer communications systems.
  • a transmitting means such as the PSTN 14 or the Internet 20 or through ATM connections or other Issuer to customer communications systems.
  • the funds, up to the limit amount for the transaction specified can be paid only to the merchant specified by the Merchant Code and only from the account or card account that has been specified when setting up the remote transaction facility.
  • the transaction has been authorised by the TSCs 24 and the Issuer 22. If for some reason authorisation is denied then the customer must negotiate with their Issuer to come to some agreement as to how the transaction may be authorised.
  • the customer now having a Transaction Code, subsequently communicates with the merchant either by way of post, telephone, facsimile, e-mail or through the World Wide Web at the merchant's website.
  • the credit card or debit card number or account number and Passcode are not transmitted to the merchant.
  • the customer informs the merchant as to the Limit Amount and the Transaction Code.
  • These items represent the authorisation and payment for the transaction so that the merchant can be confident (after getting approval as hereinafter described) that they will receive funds from the customer pertaining to this transaction and the customer will be confident that delivery will be made to the correct address.
  • the merchant will then typically key the amount (up to but not exceeding the Limit Amount), the Transaction Code and the Merchant Code into a terminal which may be their PC 12 or a dedicated terminal (some or all of this may be done automatically by appropriate software), and transmit this information to the TSCs 24 over the PSTN 14 or Internet 20 to obtain approval for the charge.
  • the merchant may read this information over the telephone.
  • the TSC will transmit the nominated Address Code of the customer together with an approval code to the merchant.
  • t0 del ⁇ ver the ⁇ oods and/or services to the customer after consulting the database 27 to find the physical or electronic address corresponding to the Address Code.
  • the customer may transmit the nominated Address Code and/or delivery address (physical or electronic), in addition to the Transaction Code and amount, to the merchant. Then when obtaining approval from the TSC the merchant will transmit the Address Code as well as the previously mentioned information to the TSC which will check the Address Code as well as the Merchant Code and amount and will issue an Approval Code only if all supplied codes are correct. The merchant may also check that the supplied Address Code matches the physical or electronic delivery address requested by the customer by consulting the publicly available database 27 mentioned previously.
  • the merchant finds the Address Code supplied does not match the delivery address requested, or if in the alternative implementation the TSC rejects the Address Code as not matching one of the registered addresses for use with the account, the merchant will not make delivery until resolution of the mismatch is achieved. The transaction will not proceed and so delivery of goods will not be made to an incorrect address, perhaps requested by a fraudulent user, but only to the correct address of the genuine customer. This would require the cooperation of the merchant to make deliveries only to the legitimate and correct address as specified in the Address Code and it will be the responsibility of the merchant to check, by reference to the publicly accessible database 27 that the Address Code does indeed match the delivery address. Where electronic delivery is required, it is essential that delivery is performed by the merchant after approval for the transaction has occurred and in a separate communication to ensure delivery to a genuine electronic address.
  • the TSCs will be able to consult their secure database 26 and match the Transaction Code, amount, Merchant Code and (optionally) Address Code with those communicated by the merchant. Unless all the codes match, the charge will not be approved -and a message denying the charge and perhaps identifying the reason will be transmitted to the merchant. The merchant may then be forced to contact the customer and check that all items of information given by the customer ⁇ ] ir ⁇ . j c £ ⁇ e A ⁇ ⁇ age, the merchant has not supplied any goods or services to the customer and no funds have yet been transmitted so no losses have been incurred.
  • the TSCs 24 will inform the merchant either through the Internet or over the PSTN that the charge has been approved and that the transaction is valid and will issue an Approval Code (and in the preferred implementation also the Address Code) to the merchant.
  • the merchant is now in a position to supply the goods or services to the customer at the legitimate address nominated previously by the customer when requesting remote transaction facilities from the Issuer, and may be confident of receiving payment.
  • the merchant is subsequently able to deposit funds for the approved transaction into their Acquirer account either by written summary or electronically through their terminal, either PC 12 or a dedicated terminal.
  • the funds are then transferred from the Issuer (customer's bank) to the Acquirer (merchant's bank) as follows:
  • the merchant supplies the Transaction Code, amount and Merchant Code, together with the Address Code and the Approval Code issued by the TSC on approving the charge, to the Acquirer which supplies these to TSCs 24.
  • the TSCs 24 will supply this data to the Issuer which after checking its records on the Transaction Code, amount, Merchant Code and Address Code will transfer payment back to the Acquirer and the account of the merchant.
  • the details of internal funds and information transfer between financial institutions and TSCs may vary according to existing or future protocols.
  • the Transaction Code together with the Address Code authorise one transaction only and the Transaction Code is linked to a particular Merchant Code so that only the holder of that Merchant Code can obtain funds from the customer. Once processed the Transaction Code would cease to have further validity and after a suitable interval could be re-used for an entirely different transaction involving different customers and merchants. If the Transaction Code were formatted in 20 digits similar to an existing credit card number and expiry date it would be large enough to cater for sufficient transactions as well as allow for some basic routing information to assist TSCs in directing verification to the appropriate centres and a check sum to maintain data integrity.
  • the customer t0 take into account periodic payments to the merchant for goods or services.
  • periodic payments to the merchant for goods or services.
  • An example of such situation is where the customer may not have adequate funds at the time of initiating the transaction but is able to make a series of payments over a period of time.
  • one Transaction Code appropriately identified (for example by one digit having a particular value) may be used by the merchant each time a periodical payment is ordered by the customer.
  • Each periodic payment or instalment could be charged by the merchant using the one Transaction Code for all of the transaction up to an authorised limit, thus saving the customer from having to obtain a new Transaction Code for each instalment for the same goods or services.
  • Control of the process remains with the customer in that they would have to authorise the limits of amount and time when requesting the Transaction Code.
  • multiple transactions could be pre-authorised based on the one Transaction Code (again appropriately identified).
  • the merchant would then have the Transaction Code and, optionally, the customer's Address Code to use for making claims up to an authorised limit.
  • the procedure followed by the customer for obtaining this semi-permanent Transaction Code (SPTC) would be the same as described above except that this SPTC would be applicable up to an authorised limit and for an authorised time (which might, for example, be up to the expiry date of the card for card accounts) and for a number of transactions involving the same merchant.
  • SPTC semi-permanent Transaction Code
  • the trusted merchant therefore retains this SPTC and, optionally, the customer's Address Code and uses them to make any additional charges on request by the customer in the same way as merchants now can do this with credit or debit card numbers held on their files.
  • a particular example is where successive volumes in a series of books are published over a period of time and are supplied by the merchant pursuant to a standing order. The process of the merchant gaining approval for each individual transaction, would, as with existing systems, confirm the availability of funds from the customer's account.
  • the customer In the event that the customer wishes to cancel a transaction before presentation by the merchant, the customer contacts the Issuer and quotes the Transaction Code and Passcode and requests cancellation. The card or account number is not transmitted and the Issuer after making the appropriate checks would notify TSCs that the Transaction Code was no longer valid. However, if the merchant had already processed the transaction it would not be reversible by this means, but would require the customer to obtain a refund through normal commercial procedures. Any unreasonable level of customer dissatisfaction would result in cancellation of the merchant's facility and Merchant Code by the Acquirer 30 and TSCs 24.
  • FIG. 2 Shown in Figure 2 is a flow diagram 100 showing the steps involved when a customer applies to their Issuer for remote transaction facilities.
  • the customer already having a credit or debit card or suitable account with the issuing financial institution such as a bank will contact their Issuer to request remote transactions facilities and provide a physical address for delivery of goods as well as optionally an associated electronic address.
  • the Issuer will then issue the customer with, or cause the customer to select a Passcode at step 104 which may require on each occasion when a customer applies for a Transaction Code that they specify a combination of digits out of the total number of digits that make up the Passcode as previously described.
  • the Issuer also issues or records one or more Address Codes, after consulting database 27, wherein one of the Address Codes is required to be nominated by the customer each time they make a Transaction Code request. Subsequently at step card or account number, expiry date and Address Code, stored in the Issuer's database 31, to TSCs 24 to be stored in database 26 for later use in verifying and authorising transactions by the customer.
  • FIG. 3 there is shown a flow diagram 110 depicting the processes involved when a customer conducts transactions with a merchant and also depicting the processes involving the merchant when they make a claim for payment.
  • the customer initiates a remote transaction after contacting a merchant through one of the available channels (by post or mail order, telephone, facsimile, e-mail or World Wide Web) and having selected goods or services that they wish to purchase.
  • the customer will obtain from the merchant an approximate amount for the goods or services requested and their Merchant Code.
  • the customer contacts their Issuer and requests authorisation for payment for the goods or services.
  • the customer is then requested to transmit the limit amount of the transaction, expiry date of their card or facility, the number of their card or account or an agreed reference to it, the Merchant Code, their Passcode or a sub-set of the digits making up their Passcode and their nominated Address Code or an agreed reference to it if more than one Address Code has been registered at step 104.
  • This is usually performed over a relatively secure channel using the PSTN 14 or alternatively where the Internet 20 is used, a suitable protocol such as SSL may be used to encrypt the information that has to be transmitted although encryption of this transmission is not essential.
  • the Issuer confirms and validates the card or account number, Address Code and the Passcode, after consulting the Issuer database 31, and transmits the card or account number, Limit Amount, Address Code and the Merchant Code to the TSCs 24 for authorisation.
  • the Merchant Code is used and stored in database 26 so that at a later time when the merchant claims for payment for the transaction, it provides a check as to the identity of the rightful merchant.
  • the TSCs 24 may already have details on the card or account number so that they can make the appropriate checks and authorise the transaction at step 126.
  • the customer will be required to negotiate with the Issuer through alternative channels at step 128 For example, the customer may request a greater credit limit to enable them to purchase particular goods or services. The process will then revert back to step 122. If the transaction is authorised by the TSCs 24 , the TSCs 24 will transmit a Transaction Code to the Issuer, after accessing database 29 and storing the Transaction Code in the database 26, at step 130.
  • the Transaction Code may be used for one transaction only or may be a semi-permanent Transaction Code enabling several transactions where the customer has established a trustworthy relationship with a particular merchant, or the Transaction Code may be such as to allow for periodical payments as previously described.
  • the Issuer transmits the Transaction Code to the customer for the requested transaction.
  • the customer will contact the merchant and disclose to the merchant the Transaction Codes and the Limit Amount.
  • the Address Code (or the physical or electronic address) may at this stage also be transmitted by the customer to the merchant to validate a remote transaction request.
  • the merchant will then request approval of the particular transaction and transmit to the TSCs 24 an amount not exceeding the Limit Amount, Transaction Code, the Address Code, if supplied, and their Merchant Code. All of this information is stored with the TSCs, in database 26, so that they will be able to make a direct comparison and validate the transaction on that basis at step 137. Shown at Figure 6 is a database maintained by TSCs.
  • the information storage may be shared between Issuer and TSCs according to various protocols but the TSCs will have access to or can request via secure communication channels such information as is required to validate and approve Transaction Codes and the associated merchant and Address Codes. If for some reason the transaction is denied, the process moves to step 138 where the merchant contacts the customer and checks that all the information provided by the customer to the merchant is in fact correct and to rectify the transaction which will then return to step 134. When the transaction has been approved by the TSCs, the process moves to step 140 and the TSCs transmits to the merchant an approval code and the nominated Address Code.
  • the merchant is then in a position to supply the goods or services to the customer at step 142 after confirming the physical address or electronic address that is linked to the Address Code on the database to claim for the amount of the transaction and initiate the transfer of funds from the customer's account to the merchant's account in accordance with the method previously described.
  • Shown at figure 7 is information 33 required to be stored by the customer in order to use the system.
  • the information is typically stored in a customer database possibly maintained on a PC. Examples include the contact details of the Issuer, the customer identifier or account number and the customer's Passcode and Address Code(s) or references to them. Where computer transactions are used, communication between the customer and Issuer will be implemented using suitable software. Relatively low levels of security of this information are adequate.
  • the present invention provides a method of conducting financial transactions remotely where no credit or debit card numbers are transmitted between customer or card holder and a merchant. The only relatively secure channel required is that between the customer and the Issuer where the customer informs the Issuer of their credit card or account number, Passcode and delivery address (or Address Code).
  • the method provides the benefit of having a requirement for two codes to authorise a particular transaction, the Transaction Code and the Address Code, where the Address Code is used to ensure delivery of goods to the legitimate address.
  • the Address Code by virtue of its being a delivery address belonging only to the legitimate account holder is in effect, the signature of the customer that confirms the authority to approve a particular transaction.
  • An illegitimate user wishing to make any fraudulent transaction would need to know the card or account number and its associated Address Code, together with the customer's Passcode and would need to contact the Issuer through one of the pre-arranged channels at which point any suspicious activity would be more readily detected, could be easily investigated, and, if warranted, issuance of the the proceeds of such fraudulent transaction would only be delivered to the legitimate delivery address of the account holder and would therefore be of no value to the fraudulent user.
  • the system requires very little new technology to adapt from present systems, does not require encryption, and could take advantage of future improvements in secure communications, personal card readers and/or biometric devices attached to a customer's computer.
  • Address Codes as a proxy for customer identity as described, the security or otherwise of communications would be of little importance as the information is only of value to the legitimate user of the system.
  • the principles involved in the invention described are not reliant on technology of a particular kind and the identifiers employed are universal ones which are not susceptible to technological obsolescence, i.e. a customer will always have an address which, in encoded form, will reliably serve as a substitute for identity in the situation where the customer is not physically present. This independence from technology makes the invention future-proof.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système permettant la conduite d'une transaction financière à distance entre un client et un commerçant. Pour chaque transaction le client reçoit un code de transaction délivré par une autorité (24) responsable de la transaction, ce code pouvant être utilisé à la place du numéro de compte du client sur lequel les fonds seront retirés par le commerçant à l'exécution de cette transaction. Un code d'adresse est extrait de moyens (27) de mémorisation, ce code représentant le lieu de livraison auquel les biens et/ou les services fournis par le commerçant doivent être envoyés à l'attention du client. Le client autorise la transaction lorsqu'il fournit le code de transaction au commerçant. Pour exiger de fonds de la part du client, le commerçant transmet un montant ainsi qu'un code de commerçant à l'autorité (24) de transaction. Lorsque la transaction est validée par l'autorité (24) de transaction, le code d'adresse et un code d'acceptation sont envoyés au commerçant et lui permettent de faire transférer les fonds sur son compte. Le commerçant peut effectuer une contre-vérification des moyens (27) de mémorisation en entrant le code d'adresse pour obtenir une adresse physique ou électronique correspondante à laquelle les biens doivent être délivrés.
PCT/AU1999/000536 1998-07-01 1999-07-01 Procede d'autorisation de transaction WO2000002150A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU45926/99A AU4592699A (en) 1998-07-01 1999-07-01 Transaction authorisation method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AUPP4439 1998-07-01
AUPP4439A AUPP443998A0 (en) 1998-07-01 1998-07-01 Transaction authorisation method
AUPP5211 1998-08-12
AUPP5211A AUPP521198A0 (en) 1998-08-12 1998-08-12 Transaction authorisation method

Publications (1)

Publication Number Publication Date
WO2000002150A1 true WO2000002150A1 (fr) 2000-01-13

Family

ID=25645816

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU1999/000536 WO2000002150A1 (fr) 1998-07-01 1999-07-01 Procede d'autorisation de transaction

Country Status (1)

Country Link
WO (1) WO2000002150A1 (fr)

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU729758B3 (en) * 1999-11-12 2001-02-08 Nagel, Carlyle Electronic commerce system and method
WO2001065502A2 (fr) * 2000-02-29 2001-09-07 E-Scoring, Inc. Systemes et procedes permettant d'effectuer des transactions de credit anonymes
WO2002007116A1 (fr) * 2000-07-19 2002-01-24 D.T.E. Solutions B.V. Procédé d'achat en ligne à sécurité de fonctionnement élevée
WO2002019068A2 (fr) * 2000-09-01 2002-03-07 Otfried Rumberg Procede d'identification fonde sur un reseau de donnees
FR2817097A1 (fr) * 2000-11-17 2002-05-24 Jean Pierre Mollion Systeme de securisation et d'authentification de donnees
WO2002063432A2 (fr) * 2001-02-07 2002-08-15 I4 Commerce Inc. Procede et systeme servant a executer une transaction entre un client et un vendeur
WO2002089076A2 (fr) * 2000-12-22 2002-11-07 Cqr Technologies Limited Systeme de gestion integree de transaction et de logistique (talisman) pour paiement securise par carte de credit et remise de transaction verifiee
EP1312055A2 (fr) * 2000-06-30 2003-05-21 Tara Chand Singhai Procede et appareil destines a un systeme de carte de paiement
EP1372089A1 (fr) * 2001-03-13 2003-12-17 Fujitsu Limited Systeme de reglement par argent electronique a l'aide d'un terminal de communication mobile
EP1393233A2 (fr) * 2001-04-05 2004-03-03 Mastercard International, Inc. Procede et systeme permettant de detecter un code de commer ant errone utilise pour une transaction par carte de paiement
EP1189184A3 (fr) * 2000-08-25 2004-05-26 Fujitsu Limited Méthode et système d'authentification, système de paiement, dispositif de l'utilisateur et support d'enregistrement contenant un programme pour exécuter l'authentification
EP1428342A1 (fr) * 2001-08-29 2004-06-16 Nader Asghari-Kamrani Systeme et procede centralises d'identification et d'authentification
FR2867585A1 (fr) * 2004-03-15 2005-09-16 France Telecom Dispositif de transaction a efficacite amelioree
US7028052B2 (en) 2001-05-10 2006-04-11 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US7127427B1 (en) * 1999-10-05 2006-10-24 Andrew Casper Secure transaction processing system and method
EP1984877A2 (fr) * 2006-02-01 2008-10-29 Mastercard International, Inc. Techniques d'autorisation d'utilisation d'un dispositif de paiement
US7527195B2 (en) 2005-04-11 2009-05-05 Bill Me Later, Inc. Method and system for risk management in a transaction
US7542993B2 (en) 2001-05-10 2009-06-02 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
EP2165307A2 (fr) * 2007-05-25 2010-03-24 Metafos INC. Systèmes et procédés de paiement en ligne anonymes
US7720750B2 (en) 1999-12-15 2010-05-18 Equifax, Inc. Systems and methods for providing consumers anonymous pre-approved offers from a consumer-selected group of merchants
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
US8001040B2 (en) 2005-01-25 2011-08-16 Ebay Inc. Computer-implemented method and system for dynamic consumer rating in a transaction
WO2012012545A1 (fr) * 2010-07-20 2012-01-26 Wi-Mexx International Limited Système et procédés pour transférer de l'argent
US8433648B2 (en) 2007-02-26 2013-04-30 Bill Me Later, Inc. Method and system for engaging in a transaction between a consumer and a merchant
US8554669B2 (en) 2007-01-09 2013-10-08 Bill Me Later, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of sale
US8571972B2 (en) 2004-02-23 2013-10-29 Bill Me Later, Inc. Computer-implemented method, system and apparatus for the dynamic verification of a consumer engaged in a transaction with a merchant and authorization of the transaction
US8639623B2 (en) 2001-06-27 2014-01-28 Orbis Patents Ltd. Transaction processing
US8719164B2 (en) 2008-06-19 2014-05-06 Bill Me Later, Inc. Method and system for engaging in a transaction between a business entity and a merchant
US8756150B2 (en) 1998-03-25 2014-06-17 Orbis Patents Limited Credit card system and method
US8756099B2 (en) 2005-04-11 2014-06-17 Bill Me Later, Inc. Consumer processing system and method
US9508096B2 (en) 2013-03-08 2016-11-29 Orbis Patents Limited Method and system for creating and processing personalized gift cards
US9703938B2 (en) 2001-08-29 2017-07-11 Nader Asghari-Kamrani Direct authentication system and method via trusted authenticators
US9727864B2 (en) 2001-08-29 2017-08-08 Nader Asghari-Kamrani Centralized identification and authentication system and method
US9911154B2 (en) 2010-07-08 2018-03-06 Mastercard International Incorporated Apparatus and method for dynamic offline balance management for preauthorized smart cards
US10580070B2 (en) 2007-05-02 2020-03-03 Paypal, Inc. Distributed system for commerce
US10592901B2 (en) 2001-06-04 2020-03-17 Orbis Patents, Ltd. Business-to-business commerce using financial transaction numbers
US10692081B2 (en) 2010-12-31 2020-06-23 Mastercard International Incorporated Local management of payment transactions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5292004A (en) * 1988-02-03 1994-03-08 Roger Cesarini Process for addressing to a recipient
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5629982A (en) * 1995-03-21 1997-05-13 Micali; Silvio Simultaneous electronic transactions with visible trusted parties

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5292004A (en) * 1988-02-03 1994-03-08 Roger Cesarini Process for addressing to a recipient
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5629982A (en) * 1995-03-21 1997-05-13 Micali; Silvio Simultaneous electronic transactions with visible trusted parties

Cited By (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9898730B2 (en) 1998-03-25 2018-02-20 Orbit Patents Limited Credit card system and method
US9881298B2 (en) 1998-03-25 2018-01-30 Orbis Patents Limited Credit card system and method
US8756150B2 (en) 1998-03-25 2014-06-17 Orbis Patents Limited Credit card system and method
US7536353B2 (en) * 1999-10-05 2009-05-19 Andrew Casper Secure transaction processing system and method
US7127427B1 (en) * 1999-10-05 2006-10-24 Andrew Casper Secure transaction processing system and method
AU729758B3 (en) * 1999-11-12 2001-02-08 Nagel, Carlyle Electronic commerce system and method
US7720750B2 (en) 1999-12-15 2010-05-18 Equifax, Inc. Systems and methods for providing consumers anonymous pre-approved offers from a consumer-selected group of merchants
WO2001065502A3 (fr) * 2000-02-29 2002-02-14 Scoring Inc E Systemes et procedes permettant d'effectuer des transactions de credit anonymes
WO2001065502A2 (fr) * 2000-02-29 2001-09-07 E-Scoring, Inc. Systemes et procedes permettant d'effectuer des transactions de credit anonymes
US8195568B2 (en) 2000-06-30 2012-06-05 Tara Chand Singhal Method and apparatus for a payment card system
EP1312055A4 (fr) * 2000-06-30 2009-04-08 Tara Chand Singhai Procede et appareil destines a un systeme de carte de paiement
EP1312055A2 (fr) * 2000-06-30 2003-05-21 Tara Chand Singhai Procede et appareil destines a un systeme de carte de paiement
WO2002007116A1 (fr) * 2000-07-19 2002-01-24 D.T.E. Solutions B.V. Procédé d'achat en ligne à sécurité de fonctionnement élevée
EP1189184A3 (fr) * 2000-08-25 2004-05-26 Fujitsu Limited Méthode et système d'authentification, système de paiement, dispositif de l'utilisateur et support d'enregistrement contenant un programme pour exécuter l'authentification
US7310608B2 (en) 2000-08-25 2007-12-18 Fujitsu Limited Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
WO2002019068A3 (fr) * 2000-09-01 2002-11-07 Otfried Rumberg Procede d'identification fonde sur un reseau de donnees
WO2002019068A2 (fr) * 2000-09-01 2002-03-07 Otfried Rumberg Procede d'identification fonde sur un reseau de donnees
FR2817097A1 (fr) * 2000-11-17 2002-05-24 Jean Pierre Mollion Systeme de securisation et d'authentification de donnees
WO2002089076A3 (fr) * 2000-12-22 2003-12-24 Cqr Technologies Ltd Systeme de gestion integree de transaction et de logistique (talisman) pour paiement securise par carte de credit et remise de transaction verifiee
WO2002089076A2 (fr) * 2000-12-22 2002-11-07 Cqr Technologies Limited Systeme de gestion integree de transaction et de logistique (talisman) pour paiement securise par carte de credit et remise de transaction verifiee
EP1358609A2 (fr) * 2001-02-07 2003-11-05 I4 Commerce Inc. Procede et systeme servant a executer une transaction entre un client et un vendeur
AU2009200162B2 (en) * 2001-02-07 2011-06-02 I4 Commerce Inc Method and system for completing a transaction between a customer and a merchant
WO2002063432A2 (fr) * 2001-02-07 2002-08-15 I4 Commerce Inc. Procede et systeme servant a executer une transaction entre un client et un vendeur
WO2002063432A3 (fr) * 2001-02-07 2003-03-06 I4 Commerce Inc Procede et systeme servant a executer une transaction entre un client et un vendeur
EP1358609A4 (fr) * 2001-02-07 2007-11-28 I4 Commerce Inc Procede et systeme servant a executer une transaction entre un client et un vendeur
AU2002247093B2 (en) * 2001-02-07 2008-10-16 I4 Commerce Inc. Method and system for completing a transaction between a customer and a merchant
US7580885B2 (en) 2001-03-13 2009-08-25 Fujitsu Limited Electronic money settlement method using mobile communication terminal
US8271335B2 (en) 2001-03-13 2012-09-18 Fujitsu Limited Mobile communication terminal and method for electronic money settlement
EP1372089A4 (fr) * 2001-03-13 2006-06-07 Fujitsu Ltd Systeme de reglement par argent electronique a l'aide d'un terminal de communication mobile
EP1372089A1 (fr) * 2001-03-13 2003-12-17 Fujitsu Limited Systeme de reglement par argent electronique a l'aide d'un terminal de communication mobile
EP1393233A2 (fr) * 2001-04-05 2004-03-03 Mastercard International, Inc. Procede et systeme permettant de detecter un code de commer ant errone utilise pour une transaction par carte de paiement
EP1393233A4 (fr) * 2001-04-05 2004-07-28 Mastercard International Inc Procede et systeme permettant de detecter un code de commer ant errone utilise pour une transaction par carte de paiement
US7542993B2 (en) 2001-05-10 2009-06-02 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US7028052B2 (en) 2001-05-10 2006-04-11 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US10592901B2 (en) 2001-06-04 2020-03-17 Orbis Patents, Ltd. Business-to-business commerce using financial transaction numbers
US8639623B2 (en) 2001-06-27 2014-01-28 Orbis Patents Ltd. Transaction processing
US10089618B2 (en) 2001-06-27 2018-10-02 Orbis Patents Limited Transaction processing
US10769297B2 (en) 2001-08-29 2020-09-08 Nader Asghari-Kamrani Centralized identification and authentication system and method
US9870453B2 (en) 2001-08-29 2018-01-16 Nader Asghari-Kamrani Direct authentication system and method via trusted authenticators
US9727864B2 (en) 2001-08-29 2017-08-08 Nader Asghari-Kamrani Centralized identification and authentication system and method
US9703938B2 (en) 2001-08-29 2017-07-11 Nader Asghari-Kamrani Direct authentication system and method via trusted authenticators
US10083285B2 (en) 2001-08-29 2018-09-25 Nader Asghari-Kamrani Direct authentication system and method via trusted authenticators
EP1428342A4 (fr) * 2001-08-29 2004-12-15 Nader Asghari-Kamrani Systeme et procede centralises d'identification et d'authentification
EP1428342A1 (fr) * 2001-08-29 2004-06-16 Nader Asghari-Kamrani Systeme et procede centralises d'identification et d'authentification
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
US8095445B2 (en) 2003-07-23 2012-01-10 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
US8571972B2 (en) 2004-02-23 2013-10-29 Bill Me Later, Inc. Computer-implemented method, system and apparatus for the dynamic verification of a consumer engaged in a transaction with a merchant and authorization of the transaction
FR2867585A1 (fr) * 2004-03-15 2005-09-16 France Telecom Dispositif de transaction a efficacite amelioree
WO2005101336A1 (fr) * 2004-03-15 2005-10-27 France Telecom Dispositif de transaction a efficacite amelioree
US8001040B2 (en) 2005-01-25 2011-08-16 Ebay Inc. Computer-implemented method and system for dynamic consumer rating in a transaction
US7527195B2 (en) 2005-04-11 2009-05-05 Bill Me Later, Inc. Method and system for risk management in a transaction
US8756099B2 (en) 2005-04-11 2014-06-17 Bill Me Later, Inc. Consumer processing system and method
US8556170B2 (en) 2006-02-01 2013-10-15 Mastercard International Incorporated Techniques for authorization of usage of a payment device
US8584936B2 (en) 2006-02-01 2013-11-19 Mastercard International Incorporated Techniques for authorization of usage of a payment device
EP1984877A2 (fr) * 2006-02-01 2008-10-29 Mastercard International, Inc. Techniques d'autorisation d'utilisation d'un dispositif de paiement
EP1984877A4 (fr) * 2006-02-01 2012-01-04 Mastercard International Inc Techniques d'autorisation d'utilisation d'un dispositif de paiement
US10949920B2 (en) 2007-01-09 2021-03-16 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US9684931B2 (en) 2007-01-09 2017-06-20 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US9412132B2 (en) 2007-01-09 2016-08-09 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US11847692B2 (en) 2007-01-09 2023-12-19 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US11922494B2 (en) 2007-01-09 2024-03-05 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US10068289B2 (en) 2007-01-09 2018-09-04 Paypal, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of-sale
US8554669B2 (en) 2007-01-09 2013-10-08 Bill Me Later, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of sale
US8433648B2 (en) 2007-02-26 2013-04-30 Bill Me Later, Inc. Method and system for engaging in a transaction between a consumer and a merchant
US10580070B2 (en) 2007-05-02 2020-03-03 Paypal, Inc. Distributed system for commerce
EP2165307A4 (fr) * 2007-05-25 2011-10-05 Metafos Inc Systèmes et procédés de paiement en ligne anonymes
EP2165307A2 (fr) * 2007-05-25 2010-03-24 Metafos INC. Systèmes et procédés de paiement en ligne anonymes
US8666905B2 (en) 2007-05-25 2014-03-04 Robert Bourne Anonymous online payment systems and methods
US10424008B2 (en) 2008-06-19 2019-09-24 Paypal, Inc. Method and system for engaging in a transaction between a business entity and a merchant
US8719164B2 (en) 2008-06-19 2014-05-06 Bill Me Later, Inc. Method and system for engaging in a transaction between a business entity and a merchant
US10740836B2 (en) 2010-07-08 2020-08-11 Mastercard International Incorporated Apparatus and method for dynamic offline balance management for preauthorized smart cards
US9911154B2 (en) 2010-07-08 2018-03-06 Mastercard International Incorporated Apparatus and method for dynamic offline balance management for preauthorized smart cards
WO2012012545A1 (fr) * 2010-07-20 2012-01-26 Wi-Mexx International Limited Système et procédés pour transférer de l'argent
US10692081B2 (en) 2010-12-31 2020-06-23 Mastercard International Incorporated Local management of payment transactions
US9508096B2 (en) 2013-03-08 2016-11-29 Orbis Patents Limited Method and system for creating and processing personalized gift cards

Similar Documents

Publication Publication Date Title
WO2000002150A1 (fr) Procede d'autorisation de transaction
US6078902A (en) System for transaction over communication network
US7356505B2 (en) System and method for transferring funds
US5883810A (en) Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) Electronic online commerce card with customer generated transaction proxy number for online transactions
US7444676B1 (en) Direct authentication and authorization system and method for trusted network of financial institutions
US6868408B1 (en) Security systems and methods applicable to an electronic monetary system
US7089208B1 (en) System and method for electronically exchanging value among distributed users
AU697632B2 (en) Trusted agents for open distribution of electronic money
US20090150294A1 (en) Systems and methods for authenticating financial transactions involving financial cards
US20100179906A1 (en) Payment authorization method and apparatus
EP0662673A2 (fr) Transactions anonymes à cartes de crédit
CA2260533A1 (fr) Methode et appareil de commerce electronique
US20100043064A1 (en) Method and system for protecting sensitive information and preventing unauthorized use of identity information
US6742125B1 (en) Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol
US20040054624A1 (en) Procedure for the completion of an electronic payment
JP2004199534A (ja) Ｉｃカードを利用した決済システム
EP1134707A1 (fr) Procédé et dispositif d'authorisation de paiement
US20020123935A1 (en) Secure commerce system and method
KR102081836B1 (ko) 금융기관 서버의 계좌를 활용한 비대면 실명확인 방법
Pilioura Electronic payment systems on open computer networks: a survey
Pardhi et al. Electronic Cash Payment System
WO2002058018A2 (fr) Procede et systeme de paiement, et carte de paiement utilisee avec ledit systeme
GB2360383A (en) Payment authorisation
KR20220127696A (ko) 수신자의 지갑 주소가 노출되지 않는 암호 화폐의 전송 방법 및 시스템

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase