AU4517899A - Verified payment system - Google Patents

Verified payment system

Info

Publication number
AU4517899A
AU4517899A AU45178/99A AU4517899A AU4517899A AU 4517899 A AU4517899 A AU 4517899A AU 45178/99 A AU45178/99 A AU 45178/99A AU 4517899 A AU4517899 A AU 4517899A AU 4517899 A AU4517899 A AU 4517899A
Authority
AU
Australia
Prior art keywords
vps
client
payment
vendor
transaction
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.)
Abandoned
Application number
AU45178/99A
Inventor
Iain Downs
Candida Coralie Anne Slater
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.)
PROTX Ltd
Original Assignee
PROTX 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 to US8982598P priority Critical
Priority to US60089825 priority
Application filed by PROTX Ltd filed Critical PROTX Ltd
Priority to PCT/GB1999/001886 priority patent/WO1999066436A1/en
Publication of AU4517899A publication Critical patent/AU4517899A/en
Application status is Abandoned legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems

Description

WO 99/66436 PCT/GB99/01886 VERIFIED PAYMENT SYSTEM BACKGROUND OF THE INVENTION The present invention relates to electronic commerce and, more particularly, to a distributed payment system for implementing secure electronic commerce transactions. 5 THE GLOBAL INTERNET The Internet, in its widest sense, is becoming the global central nervous system, and is more and more often the medium for all kinds of transaction, from the personal to the multi-national. However, it is both insecure and impracticable to have to exchange 10 primary data, such as data of diverse payment systems, each time that an electronic transaction takes place. At the same time, owners and controllers of data, including corporate, banking, and private entities, must be able to preserve their privacy and to control the mechanisms used for securely identifying themselves in order to: access their own data; 15 verify their identity to each other; and authorize transactions. All parties to a transaction need an impartial record for the purposes of validation, automation, and reconciliation. The present invention solves these problems. 20 ELECTRONIC COMMERCE Electronic commerce is becoming more pervasive as the Internet and other communications networks are employed to facilitate consumer/vendor interactions. Beyond networks connecting banks and credit card companies to vendors for use in WO 99/66436 PCT/GB99/01886 electronic funds transfers and point of sale (EFTPOS) payment authorization and authentication, payments systems and transaction authentication systems for diverse and relatively secure electronic commerce (E-commerce) are being implemented globally, including through the Internet. However, such E-commerce and payment systems 5 typically rely on subsequent verification; for example, a credit card user must verify a credit card bill days or weeks after a transaction by examining a credit card statement. No real-time verification over networks is possible using known E-commerce systems without requiring high amounts of network and bandwidth capabilities to authenticate and verify a client contemporaneously with a given E-commerce transaction. 10 Real-time verification and authentication may be implemented to some degree using a smart card and/or other payment systems such as debit card payments systems, in which clients verify transactions by utilizing their personal debit card at the time and location of the transaction. However, such debit cards generally require pre-loading of funds onto the debit card, which ties up financial resources on non-interest bearing debit 15 cards and which reduces liquidity of the client. In addition, loss or theft of a debit card may be a significant problem for the unfortunate client. In the alternative, by minimizing the amount of pre-loaded financial amounts on a debit card to counter such concerns, the client is restricted as to the size and number of transactions between loading of additional money. This is unsuitable for any commercial transaction above, 20 for example, U.S. $ 500. Thus, there is a need to provide the parties to a transaction, including both clients and vendors, with flexibility as well as security using real-time verification and authentication, as well as non-repudiation services. -2- WO 99/66436 PCT/GB99/01886 In addition, known electronic commerce systems are unable to readily handle micropayments; that is, payments under a specified threshold, such as less than ten dollars or ten pounds. Micropayments are becoming more pervasive, for example, in downloading snippets of data over the Internet such as image files and icons, as well as 5 service fees for access to on-line resources such as usage fees for accessing a website for information and/or software. In addition to such concerns as verification and authentication, there is a requirement for E-commerce to handle micropayments, and to charge the client with accrued micropayments in a single macro-settlement. A need also exists for an E-commerce system which provides secure and 10 authenticated micropayments. In addition, many business transactions rely on a degree of trust and identification built up after extensive dealings. When this level of trust has not been established by a prior relationship, which is increasingly common in the competitive and mobile marketplace, a need exists for enabling a transaction by providing identification, 15 verification, non-repudiation, and payment services to the parties of the transaction. A need also exists for an E-commerce system which provides secure and authenticated micropayments. In addition, E-commerce through World Wide Web (WWW) interfaces such as browsers is becoming more popular. However, such browser-based implementations are 20 relatively insecure, for example, in requiring the use of "cookies"; that is, browser information stored on the client's Internet-accessible computer which is known to compromise the privacy and security of the client. A need exists for an E-commerce system, including Internet-based systems, -3- WO 99/66436 PCT/GB99/01886 which do not rely on a browser and so does not present such concerns of reduced security and privacy concerns for clients. SUMMARY OF THE INVENTION 5 A trusted third party system and method are disclosed which enable secure electronic transactions across the whole transaction range, from very small to very large sums, accessed from all machines and devices with telecommunications capability, both for immediate or delayed payment settlement and for non-settlement transactions. A distributed verified payment system (VPS) and method, as the trusted third 10 party system, are disclosed which facilitate E-commerce through real-time authenticated electronic transactions with improved security, non-repudiation evidence, micropayment capabilities, etc. The disclosed VPS implements a dual-key identification authorization system, in which verified instructions must come separately and completely independently from the client and from the vendor before a transaction 15 can be initiated. This is not only more secure than taking instructions from one source only, as in a standard EFTPOS transaction, but it also makes it possible to combine flexibility with controlled payment systems. Thus, the system acts like a tramtrack switching system, in that the client, the vendor, and their associated payment methods are known and fixed quantities and pre-registered within the 20 authorization manager. The client may choose the payment or approval method from within such payment or approval methods offered by him/her and accepted by the vendor, after agreeing to the amount and currency specified by the vendor. Approval and/or -4- WO 99/66436 PCT/GB99/01886 payment is then always made within a closed system without either party having access to or knowing the details of the other's payment system. Owners of payment systems, such as corporate/purchase cards, may authorize usage by third parties within specified limits, thus enabling them to monitor and control delegated 5 authority. In addition, real-time audit trails for all parties concerned are implemented by the disclosed system, in which client, vendors, and banks have access to transaction records and may trace transactions and generate reports for such secure transactions. The disclosed system is also software and/or hardware independent, in 10 that the disclosed system may be implemented by any known networking configuration for any known electronic transaction, such as using mobile phones, palm-tops and digital television implementations for purchases and credit/debit payment arrangements for any form of commerce using electronic transactions. In addition, the system supports pre-registration of payment systems by financial 15 institutions to improve the security of the process. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates the disclosed verified payment system; FIG. 2 illustrates a hub of FIG. 1 in greater detail; 20 FIG. 3 illustrates a simplified flow diagram of operation of the verified payment system; FIG. 4 illustrates a more detailed flow diagram of operation of the verified payment system; -5- WO 99/66436 PCT/GB99/01886 FIGS. 5-6 illustrate state diagrams for the processing of a transaction; FIG. 7 illustrates a state diagram for processing to wait for client details; and FIGS. 8-9 illustrate state diagrams for processing to attempt authorization of a transaction. 5 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now to FIG. 1, a verified payment system (VPS) 10 and method of operation are disclosed which include an account authority 12 connected through a network 14 to a plurality of distributed hubs 16-20, which function as authorization 10 processors. All clients 22 and vendors 24 are connected to and through an electronic network 26, for example, the Internet, for allowing approvals and/or payments to be made between clients 22 and vendor 24 on a individual, per transaction basis across the network 14 in a secure, efficient and inexpensive manner. 15 In the hubs 16-20, client information and vendor information are stored, as shown in FIG. 1, corresponding to respective clients 22 and vendors 24. In alternative and/or additional embodiments, some clients 22 and vendors 24 are respectively connected to the hubs 16-20 through a telephone or other communications system 28 connected to the hubs 16-20 through a gateway capable 20 of processing telephone or other communications, such as cellular telephony. In addition, various entities such as banks 30 and payment system 32 such as credit and/or debit card issuing companies may be connected to local authentication servers 34 and/or gateways to the hubs 16-20 either directly or through the network -6- WO 99/66436 PCT/GB99/01886 14. The network 14 may be a wide area network (WAN), a portion of the Internet, or other electronic network communications mechanisms. Each of the hubs 16-20 may also include or be operatively connected to one or more 5 authentication systems, such as a local authentication server 34, for authenticating the electronic transaction requests registered by each client and each vendor for a given electronic transaction. Each of the hubs 16-20 may be embodied, for example, as shown in FIG. 2, in which communications from the Internet 26 are passed through at least one 10 firewall 36 to a secure hub-internal network 38 having a web farm 40; that is, a plurality of web servers, such as "WINDOWS NT"-based servers, for processing Internet communications such as HTML and HTTP data packets embodying, for example, electronic transactions so that the web farm 40 supports transaction requests and authentication services from other hubs 16-20. The authentication 15 servers 34 may authenticate the payment system details associated with an electronic transaction, such as valid credit card information, and then transmit the electronic transactions data to a bank 30 or other payments systems 32 for further authorization, settlement, and processing. The VPS 10 includes one or more databases maintained, for example, in a 20 "WOLFPACK" SQL database server 42 which holds details on vendors 24, clients 22, and payment systems. The electronic transactions are transmitted through a router 44 and an inter-hub private WAN 14 to other hubs for communications between a client at one hub and a vendor at another hub, or vice versa, and/or for -7- WO 99/66436 PCT/GB99/01886 communications with the account authority 12 to identify the hub which supports a given client or vendor indicating which hub services which client, and to initiate the exchange of data between hubs. Each of the hubs 16-20 provides services to its own respective vendors and clients, and also supports service requests from other hubs 5 for its own clients and vendors; for example, requests for identification and authority. Configuration and management of the services performed by each of the hubs 16-20 may be implemented using the "MICROSOFT LOAD BALANCING SERVICES" technology. FIG. 3 shows the general operation of the disclosed VPS 10 for use by 10 clients 22. As used herein, the term "client" may refer to any client, customer, consumer, or other entity initiating and/or engaging in transactions from vendors, who may include merchants, sales representatives, wholesalers, retailers, etc. Clients 22 utilize a computing device 48, and/or any device 50 with a communications capability to connect to the Internet 26, the telephone system 28, or 15 other communications mechanisms, and thence to contact a merchant and/or vendor 24 electronically for the purposes of establishing an electronic transaction and/or for selecting goods, services, information, or other available materials or electronic goods and information such as archived data, on-line games, video clips, physical goods, etc. The selected materials may be delivered immediately, as in the case of 20 software and/or music uploaded to the consumer's computing device 48, such as a palmtop or digital TV or a telephone 50, or may be delivered by other methods including physical delivery. In addition, the selected materials may be on-line games or data which are accessible with usage fees charged concurrent with use. -8- WO 99/66436 PCT/GB99/01886 The VPS 10 does not rely on any particular method of pre-selection of goods, which is always based on some communication directly between vendor and client. In summary, the VPS 10 enables payment of goods and services accessed via electronic mechanisms, including the Internet, mobile/cellular phones, digital TV, 5 etc., following the same basic procedure, without any direct communication necessary between client and vendor. Once a client has selected and agreed to pay for such goods or services, the vendor 24 identifies himself/herself to the system 10, references the transaction, and gives the transaction amount and currency. The client also identifies himself/herself to the system 10, chooses one of his/her pre 10 registered payment systems, and agrees to pay. The identities of both parties are verified, and the selected payment data are married together securely off-line. The transaction is authenticated in real-time via the appropriate banking or other credit gateway, and instructions are sent, if appropriate, for immediate or delayed settlement by the vendor's bank or payment agent. The vendor is updated 15 automatically with the authentication result, and an audit trail available to all parties to the transaction is updated. Each transaction is attached to vendor and VPS reference numbers facilitating checking and refunds. A plurality of hubs provides resilience and scalability, with each hub providing authorization services to certain vendors and verification and information services on behalf of clients. A central 20 account authority provides registration services indicating which hub services which client. The vendor 24 requests transaction authorization from its respective hub, such as hub 16. The client 22 also requests payment authorization from the -9- WO 99/66436 PCT/GB99/01886 vendor's hub. Upon authentication of both the client 22 and the vendor 24, the corresponding hub associated with one or both of the clients 22 and the vendor 24 acts as the authorization processor to authorize the transaction and/or enables a payment to be made to the vendor 24 by the payment system 32, such as card 5 issuers, banks, or other payment systems such as telephone or electricity companies, which ultimately charge the client 22 for the transaction. The VPS 10 can also authorize a transaction without directly causing a payment to be made. This dual-key transaction for verifying the payment information and client authenticity information provides greater security, in that both sets of information 10 must come separately and completely independently before the transaction is initiated and/or completed. FIG. 4 shows the transaction process of FIG. 3 in greater detail, in which a vendor 24 generates and sends, in step 56, a request to the authorization processor 52, which is a specific hub 16-20 associated with the vendor to authorize the 15 transaction (Tx). This may have been at the request of a client 22 who initiates a transaction in step 54 with a vendor 24. The authorization processor 52 then creates a transaction entry and searches for information about the vendor 24 in step 58, for example, to determine if the vendor 24 is a participant in the VPS 10. If so, the authorization processor 52 obtains the details 60 about the vendor 24 in preparation 20 for payment of the transaction, and returns a message or code, such as a key, which may include a secret, to the vendor identifying the transaction Tx. The client 22 is informed of the transaction key, though not informed of the secret, and uses the transaction key to identify the transaction to the authorization -10- WO 99/66436 PCT/GB99/01886 processor 52 in step 64. The VPS 10 provides a transaction ID and a value such as a "checksum" or a secret key to the vendor 24, and the client 22 may use the transaction ID to identify the transaction, but the VPS 10 and the vendor 24 never inform the client 22 of the secret key, which the VPS 10 includes in any 5 communications with the vendor 24. This reduces the risk of fraud on the part of the client 24. In an exemplary embodiment, the client 22 may be using a computer 48 and accessing a website of the vendor 24 for selecting goods or services to purchase from the vendor 24, and so in step 62, the vendor 24 redirects the browser of the 10 client 22 to verification and payment selection screens with the transaction key as a parameter of the redirect of the client 22. The interface of the vendor 24 which is provided to the clients 22 may include a website and/or other graphic user interface (GUI) environments, such as a browser using plug-ins and/or scripts to support, for example, Active Server Pages technology and/or Commerce Server Order 15 Processing Pipeline technology associated with "INTEL" and "ICROSOFT WINDOWS", as well as Perl scripts for Unix and/or Apache environments. Alternatively, using a telephone 50, the client 22 may select goods or services from an automated telephone service of the vendor 24, for example, using a touch-tone telephone and a series of automated audio menus. Accordingly, in step 20 62, the vendor 24 redirects the client to a payment selection and authorization menu through the telephone 50, or the authorization processor 52 calls back the client 22 to allow the transaction to continue. The client 22 thus sends a request for payment authorization and/or selection -11- WO 99/66436 PCT/GB99/01886 in step 64 to the authorization processor 52. The authorization processor 52 then checks the authenticity of the client 22 and obtains the payment information corresponding to the client's selection of a payment system in step 66. From step 66, the client's details 68 are obtained and verified, possibly by requesting this 5 service from another hub, and then used for authorizing payment. Upon receiving both the vendor details 60 and client details 68 and verifying both vendor 24 and client 22, the authorization processor 52 sends an authorization message 70 to a payment system authorization receiving facility 72, and the payment system in turn authorizes the transaction and, in some cases, pays the 10 vendor 24 for the authorized electronic transaction. The authorization processor 52 then informs the vendor 24 in step 74 and informs the client 22 in step 76 that the authorization has been completed, and so payment was initiated, and the vendor 24 then completes the transaction by sending the selected goods or services. FIG. 5 illustrates a master diagram of the states of a transaction by the 15 overall processing performed by the authorization processor 52 from step 58 of FIG. 4 to get and check the purported vendor to be an authorized vendor and to create a transaction entry, in which the authorization processor 52 generates a temporary transaction entry and then waits for the client details 68 to arrive and to be authenticated, the payment system (PS) authorization to be performed in step 72, 20 and the notification of the respective client 22 and vendor 24. FIG. 6 is an alternative state diagram of FIG. 5 illustrating transaction table states in a vendor hub, in which the status of the transaction is communicated to the vendor 24 prior to the vendor 24 completing the transaction with the purported -12- WO 99/66436 PCT/GB99/01886 authorized client 22. If the client 22 cannot be authenticated, the vendor 24 is informed of the reasons, and so the request for transaction authorization in step 56 can be rejected. Otherwise, the vendor 24 may perform a fulfillment transaction or a normal transaction to complete the authorized transaction for an authenticated client 22. Other conditions 5 such as refunds may also be handled. FIG. 7 illustrates the processing in FIG. 5 in the Waiting for Client Details state by the authorization processor 52 in step 66 of FIG. 4 to check and authenticate a purported client, in which the authorization processor 52 waits to receive registration information from the purported client. Each authorized client has 10 registered previously, so the authorization processor, upon receiving the client details, attempts to match the purported client with one of the authorized clients, and upon a match, obtains the client details 68. FIG. 8 illustrates the processing in FIG. 5 in the Attempt Authorization state performed by the authorization processor 52 in steps 64, 66, and 70 of FIG. 4 to 15 authorize a request for payment from the client 22 of FIG. 4 to present payment choices to the client 22, and to process the payment selection, which may be a Normal payment system, that is, a full amount of the transaction is applied to the payment system associated with the client; or which may be a Micropay payment system, that is, transaction charges less than a predetermined amount are accrued 20 and applied latter to the client 22 after the accrued amount exceeds a predetermined threshold, or to reduce an outstanding float which is topped up when the float reaches, for example, zero. In the case where the client details 68 are stored in a different hub from the -13- WO 99/66436 PCT/GB99/01886 authorization processor, the status of a transaction is partially mirrored in the client hub in order to provide resiliency and a full transaction log available to the client. FIG. 9 shows the transaction table states of a client hub during the processing of a request for client details. Such processing includes determining if account limits of a client 22 are 5 exceeded by the client's choice, or if the Micropay transaction is authenticated and is an acceptable payment option between the client 22 and his/her authorized payment systems. The account authority 12 is used by the Check Client process to identify which hub can provide the required client details. 10 As discussed herein, a vendor 24 is defined as an organization which receives payments through the VPS 10. A client 22 is defined as an individual or corporate entity registered with the VPS 10 for the purpose of enabling transactions and/or paying for goods or services across an electronic network, such as, but not limited to, the Internet. A payment system, such as the payment systems 32, 15 includes any system for making a payment or otherwise authorizing a transaction, such as by a credit/debit card, a direct debit card system, a bank account or access to a particular fund-transfer banking system, a utilities bill or billing account, etc. A receipt system is broadly defined as a system for accepting payment and may include such details as bank account or merchant numbers. A payment system 20 owner is a client who owns or holds the payment system. An authorized client is a client authorized to use the payment system by its owner. A client account is defined as the record of the client on the VPS system 10. A hub operator is defined as an organization operating a VPS hub 16-20 as a quasi -14- WO 99/66436 PCT/GB99/01886 independent supplier of the VPS 10. A financial settlement service is defined as an institution responsible for the actual transfer of funds, such as an acquiring bank for credit cards, but may include other financial institutions. Typically, the payment system owner is the individual holder of a credit 5 card, but a payment system owner may also be an officer of a company holding a corporate credit card or purchase card, or, indeed, the accounts head who controls a billing account payment system. As described herein, an autopay feature is defined as a feature allowing a client to enter a uniquely assigned user name and/or a personal identification number (PIN) only once during a session rather than entering 10 such data for each purchase. The payment system owner may be any individual holder of a payment method, such as a credit card owned by a client, with the holder being a company officer responsible for the payment method, such as an officer, an accounts head, and/or a procurement official of a company holding, for example, a corporate credit card and/or other billing accounts associated with use by the 15 payment method. Using the disclosed VPS 10, clients 22 are able to make payments to VPS vendors 24 via the Internet 26 or other communications networks. The information and details about each client 22 associated with a credit card or other payment system 32 are never transmitted clear across the Internet 26 or other communication 20 network, but instead are only transmitted in encrypted form to allow a client 22 to add or amend his/her account. Alternatively, Internet-based account modification may be avoided by allowing the client 22 to provide credit card details or other payment system details by facsimile or other secure data transmission mechanisms. -15- WO 99/66436 PCT/GB99/01886 In addition, payment system details may be pre-registered by banks or other issues of credit/holders of accounts, allowing increased security in terms of checking delivery addresses against known correct addresses, for example, from the bank, and minimizing the data transmitted across communication channels such as the Internet. 5 The vendor 24 is never informed of the details of the credit card or other payment system 32 of the client unless such a payment system is managed by the vendor, such as a telephone account. Payments are generally made directly to a given vendor 24 engaged by the client 22 and the client 22 may choose to remain anonymous to the vendor. Alternatively, the client may choose to allow the vendor 10 to capture at least or at most the name and address information from a VPS database to minimize data entry and transmission from the client as well as minimizing exposure of the client's information to non-secure systems. In an alternative embodiment, the vendor 24 can send the name, address, and/or other details with the payment request to minimize the data entry required for a new user. The 15 convenience to the client by this option may require the vendor to know when a client is a new user. In some embodiments of the VPS, the Micropay feature may be implemented, in which very small payments, such as pence or cents may be made without incurring the overhead of a credit card transaction. There are two variants 20 of Micropay: first, when the vendor accepts the risk of a bad debt, and second when the VPS takes an initial deposit and credit against the initial deposit using a pre authorized automatic crediting and/or debiting payment mechanism. A key feature of the VPS implementation of Micropay is the enablement of multiple currency -16- WO 99/66436 PCT/GB99/01886 payments by providing an automatic conversion to a common currency in the authorization processor. Optionally, an Autopay feature may be implemented in which, with the client's explicit agreement, the identification process can be set to be transparent 5 after a initial identification during a session involving a client with a specific vendor. Such transparent transaction processing provides a simpler process for a sequence of transactions, while maintaining comparable security. Access and use of a given payment system 32, such as a credit card system, may be granted by the owner of the payment system to other VPS clients 22. The 10 owner specifies credit restrictions for the authorized client and is able to view all transactions. The authorized client is only able to see transactions which that client has instigated. Clients 22 may be "pre-loaded" by financial settlement services, vendors or companies, such that the pre-loading process creates a set of inactive accounts which 15 the designated client can activate through the use of a personal identification number (PIN) sent separately by the client. Pre-loaded accounts may be subsumed into an existing VPS account by the client, or may be used to create a new account. Vendors 24 may issue refunds through the VPS 10, and clients 22 and vendors 24 may authorize payments to other clients, such that the VPS 10 provides 20 flexibility and adaptability to different marketing and sales methods. Vendors 24 may choose to provide account facilities to specific clients or groups of clients. These account systems may seek payment through a financial settlement service when the account exceeds a certain limit, in a form of Micropay, -17- WO 99/66436 PCT/GB99/01886 or may submit invoices directly to the client. In the latter case, the VPS 10 is principally acting as a trusted accounting system. Statements to clients 22 and vendors 24 may be available on-line. Other reports for banks 30, payment systems 32, and agents, and for managing the 5 accounts of the organization may also be available. The VPS 10 is highly secure, both in terms of its basic purpose and in terms of physical, procedural and programmatic access to secure information. In particular, clients 22, payment system owners and/or vendors 24 may stipulate certain minimum levels of security. For example, vendors 24 and/or clients 22 may 10 insist on validation beyond the PIN level of security details before allowing the purchases above a certain amount. In addition, the VPS 10 may be able to export accounting information, for example, outside the system 10 to an external accounting facility. The accounting information may include the number of normal transactions tallied according to the 15 type of payment system and Micropay turnover to allow an external accounting system to bill the vendors. The VPS 10 is intended to be as open as possible, for example, to adapt to meet the large potential of such Internet-based payments and E-commerce. The architecture of the VPS 10 allows for as many future options as possible. For 20 example, the VPS 10 and associated payments systems 32 may encompass credit/debit cards, direct debit, in-store accounts, utilities bills and any other form or method for moving money from one place to another. The VPS 10 also performs client identification, for example, by receiving and accepting a simple user name -18- WO 99/66436 PCT/GB99/01886 and password on a secure web connection. Alternatively, any other form of identification and verification may be used, including smart cards, digital certificates and signatures, and/or biophysical/biometric-based identification methods. The payment systems 32 and/or the client data may be hosted by other 5 organizations external to the VPS 10. FEATURES OF THE VERIFIED PAYMENT SYSTEM The VPS 10 is a value-added authentication and settlement system which is convenient to use and offers unprecedented levels of security. The VPS is a trusted 10 third party system holding details of payment systems belonging to buyers, sellers and providers of credit, in a secure environment, to provide the link between the parties involved in electronic fund transfer or credit account transactions, such as banks and other providers of credit, buyers and sellers. The VPS 10 permits these parties to authorize transactions and/or to exchange funds rapidly and efficiently, 15 without disclosure or exposure to risk of sensitive data, and to automate their processes. Also, the VPS 10 provides an impartial, real-time audit trail to all parties - clients, vendors, banks, etc. - of all transactions for which the VPS 10 is the enabling service. When a client first opens a VPS account on the Internet, the client enters 20 credit card or other payment system details, including bank and credit accounts, through a secure interface to the VPS 10, such as a secure website or other secure data entry mechanisms. The relevant information is passed securely and protected, for example, by SSL encryption via a web server of the VPS 10, or other secure -19- WO 99/66436 PCT/GB99/01886 encryption methods appropriate to the initiating device, to the back office thereof, where the information is held protected, encrypted, and off-line away from the web server. Payment systems may be registered with the VPS 10 either off-line or directly by the card issuer or provider of credit, such as a telephone account, a retail 5 store card,-a company credit account, etc. VPS account -holders, as clients using the VPS 10, may register as many payment systems as they wish in one virtual account, all accessed and controlled by the clients via the same unique ID. Once the account is opened, the VPS account holder is never required to enter or convey payment card or personal details on the Internet or any other 10 medium, but instead the VPS account holder identifies himself/herself, for example, by a unique user name and password, such as a personal identification number (PIN) plus optional additional security checks. Transactions are mediated via a unique dual key system: codes identifying the merchant, the transaction and the amount are sent from the merchant, while the client identifies himself/herself, chooses the 15 payment system s/he wishes to use for the transaction, and confirms the client's willingness and assent to pay for a selected transaction. These two streams of information from both the merchant and the client are coupled together in the authorization server 52 and sent to Payment System Authorization 72 and, if appropriate, across a fast telecommunications link to the merchant's selected 20 payment system such as a bank. Information about the success or failure of the transaction is then passed back to the Authorization Processor 52, where the success/failure information is recorded and passed on to the both the VPS web server and the merchant's server in -20- WO 99/66436 PCT/GB99/01886 step 74, so that client and merchant can be quickly informed of the result within, for example, within three to seven seconds. Each transaction is uniquely identifiable via codes assigned by the merchant and by the VPS 10, thus facilitating reference checks, monetary credits, and refunds. 5 An autopay feature allows the clien-22 to= identify -himself/herself only once for alt transactions within a single session with a vendor 24, for example, on the respective vendor's website. Very small payments may be specially processed, in which all payments below a minimum predetermined amount agreed to by each merchant are classed as 10 micropayments and treated separately. Micropayments are part of a seamless service offered to merchants and account holders who use the VPS 10, by which such micropayments accrue and are totaled up until the account holder makes a transaction which causes the accrued sum owing above the threshold of the minimum amount. The VPS 10 then automatically seeks payment for the total of 15 outstanding micropayments plus the new transaction. Merchants using the VPS 10 may thus choose from two payment options. Using the first option, merchants using the VPS 10 may choose to receive payment directly and to allow their clients to purchase goods and services on credit without pre-payment up to an agreed threshold. No payment is debited to the client until the threshold set by that 20 merchant is reached, and the merchant then receives payment for all micro payment transactions as one consolidated sum. This allows the clients to purchase small goods and services incrementally, such as downloading small files of information or programs such as applets, as well as data such as search engine queries. -21- WO 99/66436 PCT/GB99/01886 Using the second option, merchants participate in the general VPS micropayment system, which requires account holders to pay one initial opening deposit, with merchants receiving a consolidated payment, minus card and handling fees, monthly in arrears. The first time that an account holder makes a micro 5 payment transaction from any merchant participating in the general VPS micropayment arrangement, s/he is debited with a pre-payment of the threshold amount, which may be, for example, a minimum of U.S. $ 15. She/he can then buy goods and services across the whole range of merchants participating in the micropayment arrangement. The client is not charged again until the payment 10 threshold is reached. The U.S. dollar is normally used as a uniform currency unit for all micro-payment transactions globally. Initial floats as the deposit are taken from an account holders' credit card or any other authorized payments system in dollars. Any payments in currencies other than the U.S. dollar are converted into U.S. dollars before deduction from remaining float funds, with the converted value 15 being displayed to the client along with the original currency amount prior to their acceptance. Consolidated funds owing to merchants are assessed in U.S. dollars although such funds may be converted into the merchant's currency of choice before transfer. Cards and other payment systems and also personal details are registered 20 with the VPS 10 on a VPS secure database 42 in a hub 16 which performs the function of an authorization processor 52, and such details are held securely offline, away from the interface with vendors 24, and so such details are never used or available on-line. Account holders can register as many cards and other payment -22- WO 99/66436 PCT/GB99/01886 systems as desired in one virtual wallet, such as payment systems including business and personal accounts paid monthly in arrears, accounts paid by direct debit etc. Such registered payment systems of an account holder are accessed via identity checks, and such card and other payment system details may be pre-registered by 5 the issuer, so that card holders never have to put their card or personal details on line. Such off-line information gathering and retention ensures that addresses are true billing addresses, and so the VPS 10 is enabled to run accurate address checks on behalf of merchants without divulging any account holder information to the merchants. 10 In accordance with the standard initial operation of the VPS 10, the account holder chooses a.unique combination of user name and alpha-numerical password as a PIN, and logs additional security information into the VPS 10 to be used as an identity check at any time thereafter. Random questions based on the additional security information are mandatory for all changes to a client's account, and such 15 questions are optional for transactions and consultation of audit trails. PINs and additional security inputted by an account holder may be always disguised as asterisks or blank spaces onscreen. A prompt mechanism may be provided to help people with short memories. Other forms of identification and verification can be accommodated as deemed appropriate by banks, financial systems, and major users. 20 The account holder also may choose spending limits to self-limit expenditure. On-line audit trails having, for example, a resolution for time intervals down to the second, including for micropayments, are provided for users and vendors. Accounts can be controlled on-line by the user, so that details of purchases can be -23- WO 99/66436 PCT/GB99/01886 checked and printed out; and personal, security and spending limits can be altered as desired. The account holder is thus in control of all electronic spending, across different banks, cards and websites, from a single online account. Additionally, an owner of a payment system such as the registered holder of 5 a card or such-like-payment mechanisms-may-grant rights to use that payment system to other account holders on the VPS 10, which can be operated via the granted account holder's ID, with the charge going to the owner's payment system. Spending limits are specified for the owner of the payment system and each grantee. Sub-accounts may also be limited to usage with certain vendors or categories of 10 vendors. Spending limits may be a purely operational safeguard for account holders, while the true limitation on the use of any card or payment system is the credit limit on that card or system. Only the owner of each registered VPS account and sub-account may change details on an account. All currency conversion is carried out by the normal operation of credit 15 cards, banks, and financial systems. The account holder may therefore be allowed to always pay his/her bill in a selected or preferred currency, such as the currency of the country of the account holder, plus any conversion charges incurred in purchasing goods in a different currency, thus automating and providing security for electronic monetary transactions while providing the advantages of monetary 20 conversion and use in the physical world. If the account authority 12 detects, for example, three errors in security responses in one attempted transaction, the account may be frozen, and the VPS 10 logs every occurrence of a security error. Furthermore, for example, if the account -24- WO 99/66436 PCT/GB99/01886 authority 12 detect six errors in different transactions in one period of twenty-four hours, the account may also frozen. The VPS 10 initially uses a combination of user name, password and security checks, as in known telephone-based banking, to identify account holders, 5 such as the use of random questions based on two words and one date. However, the VPS 10 may also be configured to accept other forms of identification and verification, such as digital certificates and signatures, voice recognition, iris recognition, thumb print recognition, and other known methods for authenticating a user accessing the VPS 10 as a purported authorized user. For example, 10 identification via smartcards may be included in the authorization processor 52, and so the VPS 10 can therefore work well with smart card-based systems, providing direct links into account holder credit/debit card accounts, micro payments without pre-payments, online audit trails, etc. For merchants and vendors, the VPS 10 provides all participating merchants 15 with a safe and cost-effective method for collecting payments. Payment may be made directly to merchants via their own banks and merchant numbers. The VPS 10 is designed to enable merchants to build client loyalty and brand recognition by, for example, assuring clients of security and privacy by both client and merchant participating in the VPS 10. Since the VPS 10 supports credit as well as debit 20 operations, the VPS 10 also facilitates cash-based client incentive schemes and diverse kinds of loyalty-generating promotions conducted by the merchants. The VPS 10 may also provide a particular merchant with marketing and client intelligence about the merchant's own clients, sales patterns, and global report, -25- WO 99/66436 PCT/GB99/01886 without divulging the client's details. To use the VPS 10, a merchant is linked into the VPS 10 via a selection of simple or complex enabling and configuring communications software which suit most standard platforms and web servers. Merchants use a set-up installation and 5 configuration of the VPS 10 which may be appropriate to their platform and commerce server. For example, the VPS 10 may be integrated with the "MICROSOFT COMMERCE SERVER SUITE" of software and with any other widely available commerce enabling software. The VPS 10 is a very flexible system, designed to suit individual merchants' requirements and to open up new 10 areas of E-commerce and web commerce, and so the VPS 10 works with clients to produce solutions to fit the commercial needs of each client. The VPS 10 also fits well into normal bank software and procedures, in which real-time validation is directly integrated with the merchant's own transaction processes, allowing full automation, and so the VPS 10 may be easy to integrate 15 with a merchant's site and should be simple and easy-to-use by clients. Merchants receive payment for all standard credit or debit card transactions direct via their own merchant numbers. The VPS 10 invoices the merchants for fees, for example, based on a flat fee per transaction, and monthly in arrears. Merchants may choose to receive consolidated micropayments by bank transfer, directly to their merchant 20 numbers or via the general VPS micropayment system. In the latter case, the merchants receive payment monthly in arrears minus card fees and VPS handling fees. Merchants receive immediate notice of payment for each order, with such -26- WO 99/66436 PCT/GB99/01886 notification being integrated as part of the merchant's transaction sequence, thus allowing automation and control over the security of the validation process. Full integration with existing systems owned by the merchants and vendors also enables seamless integration with ordering, accounting and other software products. 5 To participate in the VPS 10 as acceptors of payment by credit or debit card, merchants using credit cards obtain E-commerce-enabled merchant numbers from their acquiring banks. The VPS 10 may allocate Terminal ID (TID) numbers to merchants from the range set aside for each bank, and then the VPS 10 informs the bank so that settlement can be made directly to the merchant. 10 The VPS 10 uses a distributed hub arrangement in order to provide full scalability and optimum performance as a universal and global system. Regional hubs 16-20, either single or clustered, guarantee fast reliable worldwide access and redundancy. Hubs are either operated directly by the VPS 10 or as a series of inter locking joint ventures between the VPS 10 and a hub operator, such as a bank, a 15 group of banks or other clearing houses or financial institutions. Merchants and account holders have one "home hub", as shown in FIG. 1, but VPS accounts may be used worldwide. Standard transactions are authenticated and settled via links between the merchant's hub and the merchant's corresponding bank, while micro payment transactions may be processed via the account holder's hub. 20 Safe international direct debits are performed, such that the global banking system can be used to send sums from an account in a bank in one currency zone to an account in a bank in another currency zone. Businesses, merchants, and vendors may acquire funds; that is, receive payment into designated bank accounts, in at -27- WO 99/66436 PCT/GB99/01886 least a core number of major international currencies, and the clients of the banks are able to pay at their end in the full range of currencies. Merchant and vendor companies are informed substantially instantly that expected funds are available and are to be received automatically within a set number of days, as specified by the 5 acquiring bank and/or by regulatory mandates, for example, normally three business days. The VPS 10 supports such functionality to interact globally with vendors, clients, and hubs internationally using, for example credit or corporate purchase cards and other established banking systems and relationships as the medium of 10 exchange. Thus, the VPS provides an automated managed facility for electronic payment/fund transfer, a real-time online audit trail for all parties, controlled payment routes, and a system for supporting multiple currencies. The VPS 10 offers such services by substantially or fully integrating with each vendor's database server. Also, vendors operating within the VPS 10 and receiving funds, for 15 example, via merchant numbers must be approved by the banks which support the VPS 10, and so the VPS 10 is self regulating. Payment systems are registered securely within the VPS 10, with the VPS 10 acting as trusted third party, and are accessed by the use of identification or transaction reference numbers. The shared payment system provided by the VPS 10 offers a secure and 20 simple method of setting up international direct debit arrangements. The VPS 10 also links directly into the global banking system through individual banks 30 to provide real-time authentication and settlement direct to merchant accounts. However, vendors are never given the details of payment systems and thus cannot -28- WO 99/66436 PCT/GB99/01886 abuse them, since the payment systems can only be used to transter sums to merchant number accounts held by vendors within the VPS 10. Credit card systems and other payment systems used exclusively for the transfer of funds from one source to another can be registered within the VPS 10 5 and locked to this exclusive use, thus providing an entirely secure closed circuit. Although the VPS 10 may operate via the Internet 26, the VPS 10 is not dependent upon the Internet 26, as all key processes performed by the VPS 10 occur off-line. Major clients, managing large fund flows, may choose to communicate with the VPS 10 via dedicated leased lines. In the case of direct debits and closed circuit 10 usage, no sensitive information is ever exchanged via the Internet 26, thus avoiding the need for high level encryption, digital certificates etc. to be used by the VPS 10, which increases the complexity and cost of use of the VPS 10. Accordingly, the VPS 10 provides an extremely simple and safe method to transfer inter-currency commercial sums. 15 The VPS 10 also provides a universal and globally-expandable system for E commerce, being a truly distributed system in which one ID allows users and vendors to mediate all transactions via the same globally accessible system, with the hub design provides quick service and back-up facilities. In addition, pre-registered credit cards may be used, so that new on-line registrations and address and personal 20 information checks for each client for each credit card are not necessary. Furthermore, card issuers may open dormant VPS accounts on behalf of their card holders by registering card details plus names and address, as well as temporary PINs and a temporary user names for each account, which may also be generated for -29- WO 99/66436 PCT/GB99/01886 this purpose by the VPS 10. Cardholders may then be given the temporary user name and ID needed to access their VPS account, following usual security procedures. Once the client gives his/her user name and ID, which may be temporary, 5 and verifies his/her identity, through a secure VPS interface, s/he can activate the account and may elect to choose a new user name and PIN, extra ID checks, and a customized spending limit, and optionally to register other details including other payment systems and personal data. Clients may group all of their payment cards together in one account, accessed, for example, by the same security checks. 10 Since basic VPS account information comes directly from the card issuer, such information includes the card billing address, which permits the VPS 10 to initiate and verify an accurate address check at the same time as transaction authentication. Such address checks allow merchants to check that the delivery address given on an order form corresponds to the billing address for the card. 15 The VPS 10 also operates with clients such that personal identification may be performed without additional hardware or software; that is, no special hardware or software is required by a client to use the VPS 10. The inputs from a client to identify himself/herself and to conduct a transaction with a vendor are not transferred through a web browser, and so there are no electronic wallets, or 20 software such as "JAVA" applets or browser cookies required for operation of the VPS 10. Thus the VPS 10 may be compatible and may interface with all machines with a communications capability. By not disclosing client information, secure sub-accounts may be -30- WO 99/66436 PCT/GB99/01886 implemented, so that a father can authorize his children to use his credit card up to a fixed amount; a company can authorize a department or individual to use a corporate purchase card within a budget and within purchasing parameters, for example, the use of the account can be tied to specific goods, services, and/or 5 vendors and clients. A supplier can authorize a client company to use a credit account, which can in turn be subdivided among departments and individuals. The account holder can monitor and control all transactions using his/her payment system via an on-line VPS audit trail. Users are never given the details of the payment system, such as the card numbers used, or given VPS ID used by the 10 account holder. Clients may have registered payment systems which they do not own but have permission to use and associated with their VPS virtual wallets with their other payment systems. Using VPS virtual wallets, clients may pay for goods and services and to monitor spending, via their own VPS ID. This very flexible system is also the basis for setting up store card accounts and direct debits, including 15 payment of utilities and monthly credit accounts. In this case, the account holder gives the vendor permission to use his payment system, such as a credit card account, to take regular payment for agreed goods and services. OPERATION OF THE VERIFIED PAYMENT SYSTEM 20 Typically, the VPS 10 uses the following principal data for each client: name; address and contact details; E-mail address; security information such as user name, PIN, security prompts and authorization PIN for bulk loaded accounts; confirmation code such as a code by which a client informs potential fund -31- WO 99/66436 PCT/GB99/01886 transferees to confirm that a user ID is typed correctly; payment systems available, such as credit card details, which may be limited to an arbitrary limit of twenty payment systems per user may be placed, possibly at the user interface (UI) level; a group name, such as the name of a company or family; the account type such as 5 "corporate" or "private"; status information such as a "super" user, account disabled, etc.; client-preferences such as-anonymous, -allow autopay, security levels, preferred payment system, etc.; credit limits for the payment system; vendor specific account information; and a minimum security level. A client may add themselves to the VPS 10 upon being presented with the 10 VPS 10 as a payment option during or pre-emptive of an on-line purchase. However, for groups, clients may be added by the group owner or a group manager. For groups, some payment systems may be hard coded and inaccessible to non authorized clients. Clients or groups of clients may also be added through a "batch update" process and activated later by the client using, for example, an authorization 15 PIN delivered separately. Clients may make changes to their VPS accounts at any time, including user name, PIN, security details, personal credit limits, and type and identify of payment systems. Authorized clients may change their limits down from a maximum set by the account owner, or change their security levels up from the minimum set by the 20 account owner. Clients may also generate and view various reports on their usage of the system. Once an account is deleted, or a user name is changed, the VPS account lies dormant for a predetermined period of, for example, six months before the previous user name can be re-used within the VPS 10. -32- WO 99/66436 PCT/GB99/01886 To manage client accounts, the account administrator may add a new account, disable or enable an account, delete an existing accounting, change and/or view personal, security, and/or payment system details of the client associated with the account, and change and/or view client preferences. 5 The pre-loading of accounts is a customizable operation, since the data format for account information may be different for each payment system. The accounts may be pre-loaded into a holding table, and the corresponding account owner is notified of the holding table and the status of the pre-loading, for example, by a hardcopy letter to the owner. This notification may include an access code, so 10 that the account owner can access the VPS 10 and use the access code to create a new account using a selected payment system 32, or add a new payment system to the owner's existing VPS account. As to the vendors 24, the VPS 10 may retain the following principal data about each vendor: name; address; security user name; security PIN; authorizing 15 payment system; bank information such as TID, sort code, and account number for payments; account, client, and transaction details for vendor-specific micropay or billing accounts; security/payment preferences; commission details; contacts; Internet Protocol (IP) Domain; and category of business. Each of the vendors is operatively connected to at least one of the hubs 16-20, which supports the vendor 20 and manages all the transactions with the vendor and transaction-initiating clients. To be set-up, a vendor completes an agreement and provides bank authorization to the VPS 10 for third party TID payments and for a payment system, such as direct payments, or debit or credit cards, which allow fees to be extracted. These payment -33- WO 99/66436 PCT/GB99/01886 systems are accounts in which payment is not made immediately and the vendor accepts the financial risk. These payment systems, as deferred payment accounts, are either a set of normal billing accounts for, for example, blue chips or for an accruals-type of micropay account in which payment is only taken when the account 5 reaches a certain level or alternatively after a predetermined time period, such as a month. At least initially, vendor accounts may be created by VPS staff or agents thereof, although initial details may be entered by the vendor through the Internet and/or the World Wide Web. A payment system is specified by the vendor to allow 10 fees to be extracted. A bank agreement is to be provided to configure the vendor's merchant IDs and TIDs or other payment systems. An attachment or installation kit may be conveyed to the client and/or to the vendor to perform acceptance tests with the VPS 10. The vendor is then ready for operation with the VPS 10. Vendors may manage themselves in terms basic name and address details, 15 payment preferences, client-based billing accounts, etc. For sensitive or secure items such as bank information, an error in which may cause the VPS 10 to stop working or to post to the wrong account, details are communicated directly and are modified directly by VPS staff. Specific functionality performed at each vendor's systems may include: 20 change/view trading name or address, personal security information, authorizing payment system, bank and/or TID information, preferences, and billing account client information. For using the VPS 10, one form of vendor-specific payment methods may -34- WO 99/66436 PCT/GB99/01886 include a type of micropayment facility in which the client's payment system is only debited when a certain total value of transactions are reached. Thus the client may have purchased, for example, four or five items over a couple of weeks before his/her card is debited, and/or when the total reaches, for example, U.S. $20. A 5 second form is a "normal" billing account between the vendor and potentially a large client, in which the VPS 10 mediates the transactions and provides billing information to the vendor, but the vendor invoices the client directly. The vendor sets a credit limit on the billing account, and such a payment system may be considered to be owned by the vendor and granted to clients, for example, through 10 the agency of authorized clients. The vendor may choose to pay money to a client, for example, as a reward for loyalty, as a refund, or as a payment of winnings or promotional activities of the vendor. The payment may be on the back of a transaction made earlier, so that the vendor does not need to know the clients details, as enforced by the VPS 10. A 15 transaction code from the vendor is used to identify the client, the credit card or payment system information, and the refund as being performed appropriately. If the credit card is no longer valid, the money equivalent is transferred to an holding account and the client may be notified, for example, via E-mail. The client may then use an interface associated with the vendor and/or with the VPS 10 to specify 20 which payment system is to be credited. If the client of the credit card or other specified payment system is no longer on the account authority 12 of the VPS 10, the vendor is notified, and the VPS 10 undertakes to mail, send via facsimile, or send via E-mail a notification to the client -35- WO 99/66436 PCT/GB99/01886 and to allow the issue to be resolved directly, but the VPS 10 does not divulge the clients personal details. For daily settlement, the authorization processor 52 has approved the transaction, but funds are not be transferred until the next batch settlement with the 5 payment system. For deferred fulfillment, the payment has been authorized, but the goods are not ready to ship. Settlement is only sought when the vendor informs the VPS 10 that the goods are ready for shipment. Complexities arise if the authorization is lapsed, in which case it must be re-confirmed. For monthly billing, the vendor is informed of the purchases made through the payment system in 10 question on demand. This information and/or their own records, are used to create an invoice for that client. For payment on accumulation of enough debt, such as Micropay arrangements, transactions are accumulated until past a specific threshold. At this point a payment system authorization/settlement is attempted for the outstanding 15 amount. These transactions may either be through a general Micropay account or other accounts held with or through a vendor-specific holding account for that client in which the vendor takes a financial risk on the transaction. To initiate an authorized payment, the vendor sends the following information directly to the payment system to allow the purchase request to be 20 corroborated: a transaction code; the transaction amount; the transaction type or preference, such as deferred, immediate, account, Micropay, etc.; and additional security information such as a zip code or other confirmatory information. A transaction payment may also be split across several payment systems of a particular -36- WO 99/66436 PCT/GB99/01886 client, such as U.S. $ 500 on one credit card and U.S. $ 400 on another credit card to overall charge U.S. $ 900 for the single transaction. If the client has a preferred payment system, then the preferred payment system is chosen automatically unless the transaction is Micropay and the preferred 5 payment system does not support Micropay, or the preferred payment system is not supported by the vendor. Normally, tne user selects which payment system to be used from a list of available payment systems which are compatible with payment systems supported by a particular vendor. After either success or failure of a transaction, the client is returned to an 10 appropriate point such as the website where the client was present before initiating the transaction. Autopay is a feature which may also be supported by the VPS 10. Autopay is a process by which a client merely confirms his/her personal VPS ID once in a session of transaction. After the first payment in a session, a series of data transfers, 15 which may optionally include browser-oriented cookies for Internet-based E commerce, is used to confirm the identity of the client. Such cookies do not include secure information, are deleted on entry into a new session, and have a limited lifetime. Autopay may also time-out if there are too large gaps in time between individual 'transactions. 20 The VPS 10 may also generate many different reports for different purposes, as described in Table 1. In general, report and statements include dates, vendor and transaction codes, and the sums involved. Such reports only include methods that allow the client to be identified if both a vendor and a client agree to such client -37- WO 99/66436 PCT/GB99/01886 identification according to their preferences. TABLE I Report Description Security vendor A statement of all transactions with a vendor in vendor/hub statement a given period. This statement can be filtered owner by credits, payments, deferred fulfillments, etc. vendor-account A- statement-of-all-transactions with-a vendor on- -vendor/hub statement a vendor specific payment system. owner/payme nt system owner (client) client statement All transactions for a client on all payment client/hub systems. Transaction by other clients using owner those payment systems are not shown. hub summary A summary for a hub of the transactions in that hub period. The purpose of this summary is to aid owner/VPS calculation of commission and similar fees. SECURITY OF THE VERIFIED PAYMENT SYSTEM 5 Client, vendor and transaction security is provided by having all communications of secure data, such as user IDs, PIN amounts, etc., are, for example, encrypted to a SSL 40 bit level. Transfers of credit cards and other payment system details occur once only from the Client to the VPS 10, and are protected by at least, for example, 40 bit SSL. Additionally, the client has the 10 option of communicating these details separately by facsimile or phone. Internet security in the VPS 10 may be performed by tracking IP addresses for all transactions. IP addresses for vendors are checked against their domain names. IP addresses for clients are recorded to allow a backtrail in the event of a fraud. If two transactions are attempted by the same client at the same time, the 15 client may optionally be alerted or informed by E-mail, for example, in the event -38- WO 99/66436 PCT/GB99/01886 that the client's user details have been stolen. Intra-hub security is implemented in a number of levels. At the top level, a supervisor controls the access rights of operators but may not themselves have rights beyond this management function. At least two passwords may be held by different 5 individuals, and lodged with trusted third parties to cover emergency conditions. Details of encryption methods are to be known to the chief technology officer (CTO) of the VPS 10, as well as to any necessary delegates. Such details may be securely lodged externally. All source code supporting security is also password protected. The purpose of this top level of security is to access and manage the 10 inherent security of the VPS 10. In general, users at this top level are restricted to limited areas of the VPS 10. The second level of security allows management of internal users of the VPS 10. The users at this level and their properties and access privileges can only be changed by top level security people, but the second level users have the ability to 15 grant access to operators of the VPS 10. In addition, these second level users are able to examine and/or generate audit trails as required. The audit trail for an acquiring bank may include all of the credit card details of a client. The third level of security includes normal users and staff of the VPS 10 who have access to client and vendor accounts, typically to amend details, enter 20 credit card information received by fax, and confirm transactions to clients and vendors with appropriate identification. All sensitive data, such as payment system details, are held in the database 42 encrypted to a high level of security. Inter-hub security is provided such that all communications between the -39- WO 99/66436 PCT/GB99/01886 hubs 16-20 to each other and to the account authority 12 are encrypted to the highest level practicable. Operating system encryption features such as PPTP may be used. Hash functions and other one-way functions may be used to increase the scrambling and security. 5 AUDIT TRAILS Audit trails are provided for transactions within a hub, and transaction duplications occur when a vendor hub and a client hub are different, since a transaction is in the audit trail at each hub. Audit trails are generally filtered to preserve the privacy of the clients 22. However, an acquiring bank may have the 10 right to audit certain client data of the VPS 10, but only as to transactions concerning authorizations of the bank. THE ACCOUNT AUTHORITY The account authority 12 functions to prevent duplications of client IDs upon 15 the adding of new clients. The list of authorized clients and their client IDs are replicated from the account authority 12 to all hubs 16-20 for performance and resilience purposes. At each step of operation using the account authority 12 and/or the hubs 12-20, the electronic transaction, from request to settlement and consolidation, is treated as a series of "micro transactions". Any system failures 20 provide for the VPS 12 to be brought back up and transactions in a dangerous state can be identified and resolved manually. For example, in a failure during authorization, items passed to the bank for authorization can be determined and checked as to which were received. Similarly, the sending of acceptances or -40- WO 99/66436 PCT/GB99/01886 rejections to a vendor may also be identified in the event of system failure. For such operational performance, the Microsoft Message Queuing (MSMQ) system may be used for communications between the hubs 16-20, which may guarantee the state of all communications. Typically, in one embodiment, around 8 5 transactions per second per node can be supported on a single ISDN channel, up to 128 transaction per second (tps) on a 1 MB link, which is about 11 million transactions per day. At this rate, the costs of a 1 MB pipe are insignificant compared to the benefits in providing such high speed transaction processing. MESSAGE FORMATS 10 A preferred embodiment of the VPS 10 uses the HTTP "POST" protocol to dispatch service requests, to receive service results, and to permit interaction with vendors and clients. Other embodiments would include message queuing services, DCOM, and so on. The formats of a number of example messages and responses for interfacing with components of the VPS 10 are described herein which form the 15 kernel of the operational side of the VPS 10. In an Internet-based embodiment, post data is Universal Resource Locator (URL) encoded, and may be sent as if the post data were dispatched by a SUBMIT button or icon on a form of a GUI. The AuthorizeTransaction message may be purely intra-hub, while other messages such as CheckLimitsAndGetPSDetails, CheckLimitsAndAuthorizeMicropay, 20 BulkNotification, and TransactionAbandoned may be inter-hub, or may be intra-hub if a client and vendor are on the same hub. The AuthorizeTransaction message is a packet which is dispatched an authentication server queue, in which a request packet is sent as follows: -41- WO 99/66436 PCT/GB99/01886 Name Type Description Size Short Size of the packet (including this word) Version Short Version of packet format. This allows more transparent upgrades of software Vendor Long Identifies Vendor. Only needed for Tx Log. ClientHub Short Hub where the client lives ClientID Long ID of client OurTxCode GUID VendorTx Char[20] ReceiptSystem Int TxType Short Type of transaction. Payment, Refund, Authentication start Datetime When the tx was initiated (mainly for log) CardNo Char[20] CardNo Expiry Char[4] MMYY Start Char[4] MMN4YY Issue Char[4] Amount Currency Currency Char[3] Currency of Tx. Mainly for Txlog Source long ID of machine which initiated the request. In the IP version, used to hold the socket no for writing the response back. In response, the returned data packet includes the following: Name Type Description Size Short Size of packet Version short Version of format ResultCode Short Result of transaction (success, fail, error) OurTxCode GUID Our AuthCode Long A unique ID IF the transaction was authenticated. ResultCode short A code representing the result Resultdetail Char[20 Text returned (authentication code ... ] Tim stamp datetime When authenticated 5 The Check.LimitsAndGetPsDetails post is dispatched from a vendor hub to a client hub for the purpose of acquiring Payment System (PS) information for authentication. The client hub, using the ServicePaymentSystem.nfoRequeStS message, checks that the account and payment system limits are not exceeded and -42- WO 99/66436 PCT/GB99/01886 either returns an error or the payment system info. The request packet for the CheckLimitsAndGetPsDetails post includes: Name Type Description Size Short Size of the packet (including this word) Version Short Version of packet format. This allows for more transparent upgrades of software TxType short Payment, refund, micropay .... VendorHub Short Hub Where Vendor is Vendor Long Identifies Vendor. Only needed for Tx Log. ClientHub Short Hub where the client lives ClientID Long ID of client OurTxCode GUID VendorTxCode Char[20] Vendors transaction code TransactionStartTime Datetime When the transaction started PaymentSystem Long Payment System which the Vendor will attempt authorization on PreviousPS long Previous payment system if a repeat attempt Amount Money How much for Currency Char[3] Currency of request OriginalAmount Money What the request was for in original currency (mainly micropay) OriginalCurrency Char[3] Original currency Return IP IP Represents originating machine. This will principally be used when we move to asynchronous processing AddressNo Long Address Identification Index Short Indicates if this is the first attempt at authorization or greater. The corresponding response packet is: 5 Name Type Description Size Short Size of the packet (including this word) Version short Version of packet format. This allows more transparent upgrades of software OurTxCode GUID ResponseCode short ExceedsLimit(type), invalid system, invalid client, has PS details, has address PaymentSystemDetails Varchar[ 100] May be empty -43- WO 99/66436 PCT/GB99/01886 PaymentSystemID Long The same as requested AddressInfo Chars... The CheckLimitsAndAuthorizeMicroPay post is dispatched from a vendor hub to a client hub for the purpose of authorizing a micropayment. Expected responses are authorized or not. The request packet sent is: Name type_ Description Size Short Size of the packet (including this word) Version short Version of packet format. This allows more transparent upgrades of software VendorHub Short Hub Where Vendor is Vendor long Identifies Vendor. ClientHub Short Hub where the client lives ClientID long ID of client OurTxCode GUID VendorTxCode Char[20] Vendors transaction code TransactionStartTime datetime When the transaction started PaymentSystem Long Payment System which the Vendor will attempt authorization on Amount Money How much for Currency Char[3] Currency of request OriginalAmount Money How much was actually asked for OriginalCurrency Char[3] And in what currency Return Queue Int Represents originating machine (returning queue name will be based on this number) AddressNo Long Address Identification. Hopefully, this won't happen but if it does... Also may not be relevant for Micropay, but Index Short Indicates if this is the first attempt at authorization or greater. 5 The corresponding response packet is: Name Type Description Size Short Size of the packet (including this word) Version short Version of packet format. This allows more transparent upgrades of software OurTxCode GUID ResponseCode short ExceedsLimit(type), invalid system, invalid client, OK, NOT Authorized, OurAuthcode long If the hub authorizes something, it must uniquely identify it. The Vendor hub will -44- WO 99/66436 PCT/GB99/01886 have it's own number if appropriate (and a different hub), but can be reconciled in the OurAuthCodes table The BulkNotification post or put includes any number of batched notifications which indicate that a transaction has been settled, a deferred fulfillment has been cancelled, or the settled transaction has been charged back and post 5 settlement cancellation is performed. The packet thus has a header indicating version, total size and number of entries in each of the three sections, followed by three sections with details on the items mentioned above. The request packet is: Name Type Description Size Short Size of the packet (including this word) Version short Version of packet format. This allows more transparent upgrades of software SourceHub Long The hub the message comes from NoSettledTransactions Long Number of entries in the 'settled transactions' section NoCancelledDeferred long Number of deferred fulfillment Txs which have been cancelled NoChargeBacks Long Number of 'bad' settled transactions DATA DATA Block of data corresponding to the volumes of settled, cancelled and charged back respectively. The Settled TX format is: 10 Name Type Description OurTxId GUID Transaction that was settled SettlementBatch long BatchNumber of the settlement SettlementTime Datetime When it was settled The Deferred FulfilmentCancellation format is: Name Type Description OurTxId GUID Transaction that was cancelled CancellationTime Datetime When it was cancelled 15 The Charge Back format is: -45- WO 99/66436 PCT/GB99/01886 Name Type Description OurTxId GUID Transaction that was settled A TransactionAbandoned packet is used to indicate that a transaction has been abandoned. If a transaction is rejected by the vendor hub's authentication server, the client may try another payment system, which implicitly informs the -5 -client hub of the failure, or the hubs may abort the transaction. If they abort, this packet is sent to synchronize the client hub, which only applies if the client and vendor hubs are distinct. If the hubs are the same, the vendor components perform all the writing and the client server components are passive. The request packet is: Name Type Description Size Short Size of the packet (including this word) Version Short Version of packet format. This allows more transparent upgrades of software OurTxCode GUID ReasonCode Short Why we gave up (Client Abort, not authenticated, timeout.... 10 Interfaces to the external world, such as requests from clients and vendors as well as notifications to vendors, are conducted via HTTP posts using SSL. The following requests are supported: Vendor Transaction Start, Vendor Fulfillment Notification, Vendor Credit against Transaction, and Client Transaction Payment Request. The Following notifications to vendors are supported: transaction 15 complete (Aborted, Rejected, Approved), Fulfillment Expiration Notification, and Exception Notification. Each subsection herein identifies the post variables that are required and details the format of the return values possible. Return codes will be plain text, one field per line with a "Name = Value" format. For example: OurTx=A23452-1234-232 -46- WO 99/66436 PCT/GB99/01886 IP=255.255.200.2 XML formatted messages may also be used. Encryption of the contents of the message may also be performed. The Vendor Transaction Start message is sent by the vendor to indicate that 5 the client wishes to make a purchase. The VPS 10 registers a transaction in a transaction table and returns the transaction code and IP address for future client communication. The parameters may be: Name Purpose Constraints MESSAGE Indicates type of Message "PAYMENT" VendorTxCode This identifies the Transaction to 20 character max the Vendor length. Unique for a given Vendor Description Free text summary of the products 64 characters. bought Amount Total Value of Transaction Numeric string. Currency Currency of Transaction As used in APACS (GBP, USD ... ). Must be a 'supported' currency that may be vendor specific. Deferred Indicates that settlement is not to be "Y" or "N". sought until the vendor requests it Default is "N" if (normally due to goods not being in form variable not stock) present Micropay Indicates that a Micropayment "Y" or "N". Method is required (vendor or Default is "N" if client) form variable not present. Transactions below a certain Payment System Type defined level will ONLY be accepted as -47- WO 99/66436 PCT/GB99/01886 Micropay. Zip Zip Code. For use in reconciling 20 characters the identity of the client Max. If this field is present then 'Country' must also be present Name Purpose Constraints SupplyAddress Indicates that the vendor wishes to "Y", "N", "M" receive the name and address of the (Yes, No, client. This is performed Mandatory). automatically if the Vendor allows Default is "N' this (though with a note on of the Authorization Pages). It will be ignored if the Client profile demands privacy and the Client will be allowed a choice of canceling the Transaction or providing address details if the flag is "M" mandatory. Notification URL A URL to return future A URL (Max 100 notifications to (for this transaction chars) and while active). Allows the Vendor more control over the organization of their site The message then returns Name Purpose Constraints Status Indicates that the transaction can "OK", "TRY proceed or not. Try later indicates a LATER", transient system problem or planned "MALFORMED downtime... REQUEST" URL Universal Resource Locator (URL) For example, which the Vendor must use in "http://www.vps.co redirecting the Client Browser m/ContinueTx.asp? VPSTX=sadgsahjd ghjas" ICETX Unique transaction identifier provided 32 chars by the VPS 10 for referencing the transaction in later communications VPSCHECK A "secret" code not to be conveyed to 4 chars clients which checks that messages are not generated by the client Reason Only present if a request is malformed Text string. Max -48- WO 99/66436 PCT/GB99/01886 (No Amount, for example). A free 100 chars format string describing the error. A Vendor Fulfillment Notification message is sent when the vendor wishes to fulfil a deferred fulfillment transaction. The parameters are: Name Purpose Constraints MESSAGE Indicates type of Message "FULFILL TRANSACTION" ICETX Which transaction is to be fulfilled 20 chars (probably a GUID) PostNotify In some cases we can simply return "Y", "N". default a code that indicates the state of is "N" the transaction (done, dropped). In others, however we must re-seek authorization. By default we will provide an immediate return code where possible. However, it may be simpler for the Vendor to only process asynchronous responses. NotificationURL A URL to return future IP notifications to (for this transaction and while active). Allows the Vendor more control over the organization of their site 5 The message returns: Name Purpose Constraints RESULT The return code indicates that the "ACCEPT", transaction is accepted, has "EXPIRED", expired, is not known or will take a "UNKNOWN", little time to process. In this latter "AUTHORIZING case a Transaction Complete Notification will be sent. A Vendor Credit against Transaction message is sent to instigate a credit against a transaction. The credit may be simply for the purpose of refund or may be 10 intended to pay winnings etc. The parameter are: -49- WO 99/66436 PCT/GB99/01886 Name Purpose Constraints MESSAGE Indicates type of Message "CREDIT" ICETX The transaction against which the 20 chars credit must be made. This (probably a transaction will (indirectly) identify GUID) the Client and Payment System to use. AMOUNT The value of the refund Numeric string. Max 2 decimal places. Max Value 1,000,000.00. Default is the original Transaction amount CURRENCY Currency to be paid in As used in APACS (GBP, USD ... ). Must be a 'supported' currency that may be Vendor specific. Defaults to the original currency of Purchase Notification URL URL for notifications to be posted to URL (Max 100) The message returns: Name Purpose Constraints RESULT The return code indicates that the "UNKNOWN", transaction being processed, is "CAN'T unknown or that the payment system PROCESS", is no longer Valid "AUTHORIZING" 5 A Client Transaction Payment Request is generated when the vendor has informed the VPS 10 of a pending request, and the vendor redirects the client, such as the client's browser, to be redirected to the respective hub of the client. The URL address used is specifically the one returned from the Vendor Transaction Start message. The parameters of the Client Transaction Payment Request are: -50- WO 99/66436 PCT/GB99/01886 Name Purpose Constraints ICETX Identifies the transaction to the VPS 10 32 character max length. The message has no specific return, which depends on the processing which occurs to respond to the request. The Transaction Complete message is sent to the vendor website, which is 5 specific by either a default URL or the one specified in the initial Transaction Request message, when an active transaction completes normally. The parameters are: Name Purpose Constraints MESSAGE Indicates type of Message "TRANSACTION COMPLETE", "FULFILLMENT COMPLETE", "CREDIT COMPLETE" VendorTxCode This identifies the Transaction to the 20 character max Vendor. If the transaction is a length. deferred fulfillment or a credit against a transaction, this will be the original ICE Tx code. ICE TX Our transaction code 20 chars VPSCHECK A "secret" which must match the original "secret" sent to the vendor Status The result of the transaction. The "ACCEPT", status indicates authorization, "REJECT", rejection, client abort or system failure "ABORT", "FAIL" Timestamp Time at which Transaction was Date Time (?) accepted, rejected etc. The message returns 10 Name Purpose Constraints RESULT Indicates that the Vendor has received the "OK", "SYSTEM notification. In the case of a "SYSTEM ERROR" ERROR", the transaction must be backed out. Timestamp Date time when the Vendor completed Date Time -51- WO 99/66436 PCT/GB99/01886 processing. A Fulfillment Expiry (or expiration) Notification message is sent to the vendor when a deferred fulfillment transaction passes a sell-by date of the transaction. This message is informational and is resent until a response is received, 5 such as "OK" or "UNKNOWNTX". The parameters are: Name Purpose Constraints MESSAGE Indicates type of Message "FULFILLMENT EXPIRED" ICE TX Identifies the transaction Vendor TX Their code for the Tx Reason Indicates why the deferred transaction "TIMEOUT", has expired "USERACCOUNT CANCELLED" Timestamp When this happened The message returns: Name Purpose Constraints RESULT OK or unknown transaction. "OK", "UNKNOWN TX" 10 A Status Request message allows the vendor to interrogate the VPS 10 concerning the exact state of a transaction. The parameters include a transaction ID of the vendor or the VPS 10, a vendor code, and other information pertaining to the transaction. The message returns the status of the transaction, the amount, 15 commencement time, and the time and nature of last action. By the foregoing, the disclosed verified payment system and method has been disclosed by way of the preferred embodiment. However, numerous modifications and substitutions may be had without departing from the spirit of the invention. For example, while the preferred embodiment discusses an Internet-based configuration, it is 20 wholly within the purview of the invention to contemplate primarily telephone-based configurations in the manner as set forth above, such that the disclosed system may be -52- WO 99/66436 PCT/GB99/01886 implemented by any known networking configuration for any known electronic transaction, such as using mobile phones, palm-tops and digital television implementations for purchases and credit/debit payment arrangements for any form of commerce using electronic transactions. In addition, the uniform currency used 5 by the VPS 10 may be the British pound sterling, the Euro, the Eurodollar, or any other predetermined currency or monetary/financial denomination. Accordingly, the invention has been described by way of illustration rather than limitation. -53-

Claims (10)

1. A verified payment-enabling system (VPS) (10) comprising: a) a trusted third-party registration system enabling the secure, 5 private registration of identification, verification, and payment data by clients, vendors, and payment systems, including banks; b) a plurality of hubs (16-20), connected by a private network (14), enabling all parties to an electronic/digital transaction, including a client (22) and a vendor (24), to mediate secure electronic/digital transactions without direct 10 communications between the parties; c) an account authority providing registration services detailing which hub supports which client; and d) an audit trail generator for generating an audit trail of a respective electronic/digital transaction, with the audit trail being available to all parties 15 of the electronic/digital transaction; e) wherein the VPS (10) implements an autopay feature allowing a client (22) to identify himself/herself only once for all transactions within a single session with a vendor (24). 20
2. The VPS (10) of claim 1, wherein verified instructions from the vendor (24) to the client (22) in a respective electronic/digital transaction are separately received by a hub. -54- WO 99/66436 PCT/GB99/01886
3. The VPS (10) of claim 1, wherein the hubs (16-20) store client and vendor data, including user names, digital certificates, and payments system data, and wherein the hubs (16-20) prevent private data from being conveyed to the parties of a respective electronic/digital transaction during processing and completion of the 5 electronic/digital transaction as a secured electronic/digital transaction.
4. The VPS (10) of claim 2, wherein each of the plurality of hubs (16-20) includes a respective authorization processor capable of authorizing and/or verifying electronic/digital transactions and/or initiating a payment through a financial institution. 10
5. The VPS (10) of claim 1, wherein a set of rights-to-use a respective payment system, including a credit card system, are granted by an owner of the respective payment system to clients of the VPS (10). 15
6. The VPS (10) of claim 1, wherein the vendor (24), responsive to authorization of the electronic/digital transaction, directs the client (22) to the authorization processor (12).
7. The VPS (10) of claim 6, wherein the client (22) and the vendor (24) are 20 connected to the plurality of hubs (16-20) through at least one network (26) to initiate and enable the electronic/digital transaction.
8. The VPS (10) of claim 7, wherein the network (26) is one or more -55- WO 99/66436 PCT/GB99/01886 telecommunications system such as at least one of the Internet, satellite, cable, cellular, and infra-red communications systems; and wherein the client (22) makes a transaction with the vendor (24) through an electronic interface. 5
9. The VPS (10) of claim 1, wherein the payment systems, including credit and/or debit card systems, can be pre-registered within a secure, universal system by the card issuers or other payment or credit system issuers.
10 10. The VPS (10) of claim 1, wherein payment to complete the electronic/digital transaction is performed using a micropayment arrangement wherein purchases below a pre-determined value are debited against a pre-paid credit amount, based on the U.S. dollar, belonging to the customer which is automatically replenished by debiting a pre-arranged payment system. -56-
AU45178/99A 1998-06-19 1999-06-18 Verified payment system Abandoned AU4517899A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US8982598P true 1998-06-19 1998-06-19
US60089825 1998-06-19
PCT/GB1999/001886 WO1999066436A1 (en) 1998-06-19 1999-06-18 Verified payment system

Publications (1)

Publication Number Publication Date
AU4517899A true AU4517899A (en) 2000-01-05

Family

ID=22219761

Family Applications (1)

Application Number Title Priority Date Filing Date
AU45178/99A Abandoned AU4517899A (en) 1998-06-19 1999-06-18 Verified payment system

Country Status (12)

Country Link
EP (1) EP1097425A1 (en)
JP (1) JP2002518749A (en)
CN (1) CN1313973A (en)
AU (1) AU4517899A (en)
BR (1) BR9912173A (en)
CA (1) CA2335453C (en)
CZ (1) CZ20004781A3 (en)
HU (1) HU0103385A2 (en)
IL (1) IL140333D0 (en)
NO (1) NO20006449A (en)
PL (1) PL345032A1 (en)
WO (1) WO1999066436A1 (en)

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19926472C2 (en) 1999-06-10 2001-11-15 Call A Bike Mobilitaetssysteme A method for communicating a code
WO2001009806A1 (en) 1999-08-02 2001-02-08 E-Mark Systems Inc. Electronic settlement system, settlement device, and terminal
GB9925227D0 (en) * 1999-10-25 1999-12-22 Internet Limited Data storage retrieval and access system
SG89314A1 (en) * 2000-01-18 2002-06-18 Cazh Pte Ltd Secure network electronic transactions and payments system
US7177838B1 (en) * 2000-01-26 2007-02-13 Paybyclick Corporation Method and apparatus for conducting electronic commerce transactions using electronic tokens
JP2002247029A (en) * 2000-02-02 2002-08-30 Sony Corp Certification device, certification system and its method, communication device, communication controller, communication system and its method, information recording method and its device, information restoring method and its device, and recording medium
IES20010112A2 (en) * 2000-02-11 2001-09-19 Internet Payments Patents Ltd A network-based system
US7366695B1 (en) 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
FR2806185B1 (en) * 2000-03-07 2007-04-20 David Ifergan Secure Method of transaction between a buyer and a seller
KR101015341B1 (en) 2000-04-24 2011-02-16 비자 인터내셔날 써비스 어쏘시에이션 Online payment authentication services
NO314866B1 (en) 2000-05-08 2003-06-02 Ericsson Telefon Ab L M Mobile receipt system
SE0002039L (en) * 2000-05-31 2001-12-01 Dag Peter Ljungqvist Method for secure transmission of payment in relation to trade via a network
WO2001097146A1 (en) 2000-06-16 2001-12-20 Verisae Enterprise asset management system and method
US7440871B2 (en) 2002-12-09 2008-10-21 Verisae, Inc. Method and system for tracking and reporting emissions
US7369968B2 (en) 2000-06-16 2008-05-06 Verisae, Inc. Enterprise energy management system
US7512523B2 (en) 2000-06-16 2009-03-31 Verisae, Inc. Refrigerant loss tracking and repair
US7474218B2 (en) 2000-06-16 2009-01-06 Verisae, Inc. Method and system of asset identification and tracking for enterprise asset management
US7877235B2 (en) 2003-01-31 2011-01-25 Verisae, Inc. Method and system for tracking and managing various operating parameters of enterprise assets
US20050177437A1 (en) * 2000-06-29 2005-08-11 Jonathan Ferrier E-commerce system
GB2364482B (en) * 2000-06-30 2002-10-09 Motorola Inc Server-based electronic wallet system
CA2878813C (en) 2000-07-10 2017-10-24 Paypal, Inc. System and method for verifying a financial instrument
FR2811786B1 (en) * 2000-07-17 2006-07-07 Serge Benchimol Method for secures a transaction via a network of telecommunication, and method of implementation system
US7523067B1 (en) 2000-08-02 2009-04-21 Softbankbb Corporation Electronic settlement system, settlement apparatus, and terminal
US6957199B1 (en) * 2000-08-30 2005-10-18 Douglas Fisher Method, system and service for conducting authenticated business transactions
JP2003044708A (en) * 2000-10-02 2003-02-14 Omron Corp Information mediating system and information mediating method to be used in the system
US7418429B1 (en) * 2000-10-20 2008-08-26 Accenture Pte. Ltd. Method and system for facilitating a trusted on-line transaction between insurance businesses and networked consumers
US7499889B2 (en) 2000-10-23 2009-03-03 Cyota Inc. Transaction system
FR2815745B1 (en) 2000-10-25 2003-01-10 Cedric Remy Method of payment Secure telematics
WO2002042886A1 (en) * 2000-11-23 2002-05-30 Xu Xulin Electronic commerce system
AU2157502A (en) * 2000-12-18 2002-07-01 Michael Hetting Method for processing trade data, especially electronic trade
US7363248B2 (en) 2000-12-22 2008-04-22 Invenda Corporation Pre-filling order forms for transactions over a communications network
US7415429B2 (en) 2000-12-22 2008-08-19 Invenda Corporation Providing navigation objects for communications over a network
US7349867B2 (en) * 2000-12-22 2008-03-25 Invenda Corporation Tracking transactions by using addresses in a communications network
JP3585479B2 (en) * 2000-12-28 2004-11-04 保信 刀祢明 Work evaluation method of contest
NO313980B1 (en) * 2001-02-08 2003-01-06 Ericsson Telefon Ab L M A method and a module for mobile e-commerce
DE10107131C1 (en) * 2001-02-15 2002-04-25 Siemens Ag Micro-payment method e.g. for electronic services, has charges for service logged against initial payment credit with periodic request for further payments
EP1744518A3 (en) * 2001-03-08 2007-04-11 RSA Security, Inc. Transaction system
WO2002086779A1 (en) * 2001-03-16 2002-10-31 Sagacious Procurement Pty Limited Network-based procurement system and method
NL1017716C2 (en) * 2001-03-28 2002-10-01 Koninkl Kpn Nv Method and system for charging for playing a multimedia file.
JP3594187B2 (en) * 2001-05-16 2004-11-24 ソニー株式会社 Information processing apparatus and method, an information providing apparatus and method, recording medium, and program
KR20040002928A (en) * 2001-05-31 2004-01-07 인터내셔널 비지네스 머신즈 코포레이션 Micropayment system
JP4363800B2 (en) * 2001-06-11 2009-11-11 ソニー株式会社 E-commerce support device, e-commerce support method, and computer program
FR2826755A1 (en) * 2001-06-29 2003-01-03 Mucash High security Internet vendor-purchaser transactions, in which buyer, vendor and account managing third party correspond using identifiers for transaction and vendor
DE10138814A1 (en) * 2001-08-14 2003-03-06 Orga Kartensysteme Gmbh Computer system and method for cashless payment
JP2003067484A (en) * 2001-08-22 2003-03-07 Dc Card Co Ltd Payment system for medical expenses and the like
DE10151213B4 (en) * 2001-10-15 2006-03-16 Siemens Ag A method for authorizing payments in a communication network
US7184980B2 (en) 2001-11-15 2007-02-27 First Data Corporation Online incremental payment method
CA2364142A1 (en) * 2001-11-30 2003-05-30 Ibm Canada Limited-Ibm Canada Limitee Authorizing multiple categories of card based financial transactions
CN100433617C (en) 2001-12-04 2008-11-12 M概念有限公司 System and method for facilitating electronic financial transactions using a mobile telecommunications device
CZ301193B6 (en) * 2002-05-17 2009-12-02 TELEMATIX SERVICES, a.s. General-purpose communication, information, navigation and paying system
HU223885B1 (en) 2002-06-17 2005-03-29 András Vilmos Set of apparatuses for preparing and performing financial transactions between seller and customer
EP1378876A1 (en) * 2002-07-03 2004-01-07 Siemens Aktiengesellschaft Method and system for electronic payment of goods and services making use of a wireless network
US20060116938A1 (en) * 2002-07-03 2006-06-01 Siemens Aktiengesellschaft Method for the electronic payment of a merchandise or service by using a mobile radio network, and arrangement for carrying out said method
EP1413966A1 (en) * 2002-10-22 2004-04-28 Johannes Prof. Dr. Pichler Computer system and method for processing commercial transactions via data transmission lines
US20040139016A1 (en) 2002-11-01 2004-07-15 Modasolutions Corporation Internet payment systerm and method
US7257549B2 (en) 2002-12-11 2007-08-14 Broadcom Corporation Systems and circuits for providing support for user transactions on a media exchange network
AU2003902911A0 (en) 2003-06-11 2003-06-26 The Commonwealth Of Australia Credential communication device
US20050086163A1 (en) * 2003-08-20 2005-04-21 Johnson Daniel T. Electronic payment system
US7653602B2 (en) * 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
WO2005048152A1 (en) * 2003-11-10 2005-05-26 Ebay Inc. Facilitating micropayments between a plurality of parties
US20050111409A1 (en) 2003-11-25 2005-05-26 Spear Stephen L. Method and apparatus for mobile station registration in a cellular communication system
US7324976B2 (en) * 2004-07-19 2008-01-29 Amazon Technologies, Inc. Automatic authorization of programmatic transactions
US7739660B2 (en) 2006-03-31 2010-06-15 Sap Ag Code management in a distributed software development environment
CN101064031A (en) * 2006-04-24 2007-10-31 腾讯科技(深圳)有限公司 Recording forwarding method of digital information and recording forwarding method thereof
US8335745B2 (en) * 2006-10-11 2012-12-18 Visa International Service Association Method and system for processing micropayment transactions
US7933835B2 (en) 2007-01-17 2011-04-26 The Western Union Company Secure money transfer systems and methods using biometric keys associated therewith
US8818904B2 (en) 2007-01-17 2014-08-26 The Western Union Company Generation systems and methods for transaction identifiers having biometric keys associated therewith
US7810134B2 (en) 2007-01-22 2010-10-05 First Data Corporation Authentication system for financial transactions
US8504473B2 (en) 2007-03-28 2013-08-06 The Western Union Company Money transfer system and messaging system
US20100174649A1 (en) * 2007-06-04 2010-07-08 Bce Inc. Methods and systems for validating online transactions using location information
GR1006240B (en) * 2007-07-13 2009-01-28 Γεωργιοσ Τρασανιδησ Electronic system and procedures for financial transactions, promotional activities, e-tickets and electronic lottery allpications by the use of portable or fixed electronic devices connected to a telecommunication network.
CN101197953B (en) 2007-12-05 2010-09-29 深圳创维-Rgb电子有限公司 Household electric business TV set
CA2746760A1 (en) * 2009-01-13 2010-07-22 Michael Horie Secure protocol for transactions
EP2482242A4 (en) * 2009-09-24 2013-09-25 Nippon Telegraph & Telephone Electronic payment method, system, server and program for same
CN102376002A (en) * 2010-08-05 2012-03-14 统一超商股份有限公司 Commodity redemption carrier
US8645272B2 (en) 2011-06-24 2014-02-04 Western Union Financial Services, Inc. System and method for loading stored value accounts
CN103843028A (en) * 2011-08-01 2014-06-04 英特尔公司 Witnessed ad-hoc uservices
CN102999846A (en) * 2012-10-29 2013-03-27 北京京东世纪贸易有限公司 Method and device for handling commodity compensation information
GB2512613A (en) * 2013-04-03 2014-10-08 Cloudzync Ltd Secure communications system
SG11201509507WA (en) * 2013-05-23 2015-12-30 Sureshwara Inc A system for authorizing electronic transactions and a method thereof
KR20150033048A (en) * 2013-09-23 2015-04-01 주식회사 케이알파트너스 Server, terminal apparatus and method for providing a card information transmitting service

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing

Also Published As

Publication number Publication date
HU0103385A2 (en) 2002-01-28
EP1097425A1 (en) 2001-05-09
CA2335453A1 (en) 1999-12-23
PL345032A1 (en) 2001-11-19
CZ20004781A3 (en) 2001-08-15
CN1313973A (en) 2001-09-19
CA2335453C (en) 2007-11-06
JP2002518749A (en) 2002-06-25
BR9912173A (en) 2001-11-20
WO1999066436A1 (en) 1999-12-23
NO20006449A (en) 2001-01-17
NO20006449D0 (en) 2000-12-18
IL140333D0 (en) 2002-02-10

Similar Documents

Publication Publication Date Title
US8413896B2 (en) System and method for new execution and management of financial and data transactions
Sirbu et al. NetBill: An internet commerce system optimized for network-delivered services
US9830602B2 (en) Transaction processing with non-internet communication
AU2004319618B2 (en) Multiple party benefit from an online authentication service
US7962409B2 (en) Method and system for processing internet payments using the electronic funds transfer network
JP5130039B2 (en) Financial transaction with the transmission and reception fee
US7878393B2 (en) Method and apparatus for distribution of money transfers
US7509293B2 (en) Method for anonymous purchase of goods by not providing identifying information to a non-host entity
US8086530B2 (en) Electronic payment system utilizing intermediary account
EP1301912B1 (en) Transaction processing system
US7536353B2 (en) Secure transaction processing system and method
US6134533A (en) Multi-level marketing computer network server
US7319986B2 (en) Dynamic payment cards and related management systems and associated methods
US10185936B2 (en) Method and system for processing internet payments
JP5430701B2 (en) System and method for confirming the financial means
US8099329B2 (en) Systems and methods for determining taxes owed for financial transactions conducted over a network
US7328189B2 (en) Method and apparatus for conducting electronic commerce transactions using electronic tokens
AU2003218178B2 (en) A system and method for purchasing goods and services through data network access points over a point of sale network
US7742967B1 (en) Secure and efficient payment processing system
US9665863B2 (en) Conducting commerce between individuals
US6226624B1 (en) System and method for pre-authorization of individual account remote transactions
US8224753B2 (en) System and method for identity verification and management
US7177830B2 (en) On-line payment system
US7828206B2 (en) System and method for exchanging loyalty points for acquisitions
US8566237B2 (en) Internet payment system and method

Legal Events

Date Code Title Description
MK5 Application lapsed section 142(2)(e) - patent request and compl. specification not accepted