MXPA00012708A - Verified payment system - Google Patents

Abstract

A distributed verified trusted third-party system (VPS) (10) and method enable electronic/digital transactions through real-time verification and authentication, with improved privacy and security, encompassing the wholepayment range from very large to very small. The VPS (10) includes hubs (16-20) storing client data and connecting clients (22) to vendors (24) to mediate secure electronic transactions. Date may be pre-registered by banks (30) and other owners, controllers, and issuers of payment systems (32). 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 authority. A central account authority (12) provides registration services indicating which hub services which client. The VPS (10) implements a dual key transaction system, in which verified instructions must come separately and completely independently from both client (22) and vendor (24) before transaction completion via methods accepted by both parties. The VPS (10) allows the client (22), the vendor (24), and associated payment methods and systems (30-32) to be known, with fixed quantities and pre-registered within an authorization manager. The client (22) and vendor (24) may choose the payment method and currency used at each end of any transaction, and payment is always made within a closed system without either party having access to or knowing the details of the other's payment system. Real-time audit trails for all parties concerned are implemented, in which client (22), vendors (24), and banks (30) may trace transactions, generate reports, and initiate refunds for such secure transactions. The VPS (10) is also software and/or hardware independent, implemented by any known networking configuration for any known electronic or digital transaction, using mobile phones (28), palm-tops and digital television for purchases and credit/debit payment arrangements for any form of commerce using electronic transactions.

Description

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.

THE GLOBAL INTERNET The Internet, in its broadest sense, is becoming the central nervous system of the globe, and is increasingly the medium for all kinds of transactions, from personal to multinational. However, it is unsafe and impractical to have to exchange primary data, such as data from various payment systems, each time an electronic transaction takes place. At the same time, data owners and controllers, including corporate, banking and private entities, must be able to preserve their privacy and control the mechanisms used to identify themselves securely, in order to: have access to their own data; verify their identity with one another; 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.

ELECTRONIC COMMERCE Electronic commerce is becoming more persuasive as the Internet and other communications networks are used to facilitate consumer / vendor interactions. Beyond the networks that connect banks and credit card companies with sellers for use in electronic fund transfers and in the authorization and authentication of point of sale payment (EFTPOS), payment systems and authentication systems of transactions for diverse and relatively secure electronic commerce (E-commerce) are being implemented globally, including through the Internet. However, these E-commerce and payment systems typically rely on subsequent verification; For example, the user of a credit card must verify a credit card account days or weeks after a transaction by examining a credit card account status. It is not possible to do real-time verification on networks using known E-commerce systems without requiring high amounts of network and bandwidth capabilities to authenticate and verify a customer in a contemporary manner with a commercial transaction. -E given.

Verification and authentication in real time can be implemented up to a degree using a smart card and / or other payment systems, such as debit card payment systems, where customers verify transactions using their personal debit card in the moment and location of the transaction. However, these debit cards usually require a previous charge of the funds in the debit card, which implies financial resources on debit cards that do not carry interest, and which reduces the client's liquidity. In addition, the loss or theft of a debit card can be a significant problem for the unfortunate customer. In the alternative, by minimizing the amount of pre-loaded financial amounts on a debit card to counter these concerns, the client is restricted with respect to the size and number of transactions between the additional money charges. This is unsuitable for any commercial transaction above, for example, U.S. $ 500 dollars. Pays et al .: "An Intermediation and Payment System Technology" Computer Networks and ISDN Systems, volume 28, 1996, pages 1197-1206, describe a payment authorization system verified as stipulated in the preamble of claim 1. Tygar: " Atomicity in Electronic Commerce "Proceedings of the Fifteenth Annual Acm Symposium on Principles of Distributed Computing, May 23-26, 1996, pages 8-26, provides background information on electronic commerce, and in particular on "Atomicity", which is the link of logical operations, in such a way that all or none are executed. Accordingly, there is a need to provide the parties to a transaction, including both customers and vendors, with flexibility as well as security, using real-time authentication and verification, as well as non-repudiated services. In addition, known e-commerce systems are unable to easily handle micropayments; that is, payments below a specified threshold, such as less than ten dollars or ten pounds. Micropayments are becoming more persuasive, for example, in downloading fragments of data about the Internet, such as image files and icons, as well as service rights to access online resources, such as rights of use to access to a website for information and / or software. In addition to these concerns regarding verification and authentication, there is an E-commerce requirement to manage micropayments, and to charge the customer the micropayments due in a single macro-compensation. There is also a need for an E-commerce system that provides secure and authenticated micro-payments. In addition, many business transactions rely on a degree of trust and identification built after costly deals. When this level of trust has not been established through a prior relationship, which is increasingly common in the competitive and mobile market, there is a need to make a transaction possible through the provision of identification, verification, non-repudiation and payment services. parts of the transaction. There is also a need for an E-commerce system that provides secure and authenticated micro-payments. In addition, E-commerce through interfaces of the World Wide Web (WWW), such as browsers, is becoming more popular. However, these browser-based implementations are relatively insecure, for example, by requiring the use of "cookies"; that is, it is known that the browser information stored on the client's Internet-accessible computer compromises the privacy and security of the client. There is a need for an E-commerce system, including Internet-based systems, that does not rely on a browser, and thus does not present these safety and privacy concerns reduced for customers.

COMPENDIUM OF THE INVENTION A trusted third-party system and method is disclosed, which enables secure electronic transactions throughout the range of transactions, from very small to very large sums, accessed from all machines and devices. with telecommunications capacity, both for immediate or delayed payment compensation, and for transactions without compensation. A system and method of distributed verified payment (VPS), such as the trusted third party system, are disclosed that facilitate E-commerce through authenticated electronic transactions in real time with better security capabilities, evidence of no repudiation, micropayment, etc. The disclosed VPS implements a dual-key identification authorization system, where the verified instructions must come separately and in a completely independent manner from the customer and the seller, before a transaction can be initiated. This is not only safer than taking instructions from a source only, as in the standard EFTPOS transaction, but it also makes it possible to combine flexibility with controlled payment systems. Accordingly, the system acts as a switching system of change of track, in which the customer, the seller and their associated payment methods are known and fixed quantities, and previously registered within the authorization manager. The customer can choose the method of payment or approval from within these methods of payment or approval offered by him and accepted by the seller, after agreeing on the amount and the currencies specified by the seller. Then, approval and / or payment are 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 / purchasing cards, may authorize use by third parties within specified limits, thus enabling them to monitor and control delegated authority. In addition, real-time audit trails are implemented for all parties concerned through the system disclosed, where the client, vendors, and banks have access to transaction records, and can track transactions and generate reports for these secure transactions. The disclosed system is also independent of software and / or hardware, in that the system disclosed can be implemented by any known network configuration for any known electronic transaction, such as using mobile phones, palm-tops, and implementations digital television for purchases and credit / debit payment arrangements for any form of commerce using electronic transactions. In addition, the system supports the previous registration of payment systems by financial institutions to improve the security of the process.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates the verified payment system disclosed. Figure 2 illustrates a center of Figure 1 in greater detail. Figure 3 illustrates a simplified flow diagram of the operation of the verified payment system. Figure 4 illustrates a more detailed flow diagram of the verified payment system operation. Figures 5 and 6 illustrate state diagrams for the processing of a transaction. Figure 7 illustrates a state diagram for processing to await customer details. Figures 8 and 9 illustrate state diagrams for processing to attempt authorization of a transaction.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now to Figure 1, a verified payment system (VPS) 10, and a method of operation are disclosed, which include an account authority 12 connected through a network 14 with a plurality of plants distributed 16-20, which function as authorization processors. All customers 22 and vendors 24 are connected to, and through, an electronic network 26, for example, the Internet, to allow for approvals and / or payments between customers 22 and vendor 24 on an individual basis per transaction. through network 14, in a safe, efficient and economical way. In the exchanges 16-20, the customer information and the vendor information are stored, as shown in Figure 1, corresponding to the respective customers 22 and vendors 24. In the alternative and / or additional modalities, some clients 22 and vendors 24 are respectively connected to the exchanges 16-20 through a telephone or other communications system 28 connected to the exchanges 16-20, through a gate capable of process telephone or other communications, such as cellular telephony. In addition, different entities, such as banks 30 and payment systems 32, such as credit and / or debit card issuing companies, local authentication servers 34 and / or gates for exchanges 16- can be connected. 20, either directly, or through the network 14. The network 14 can be a wide area network (WAN), a portion of the Internet, or other mechanisms of electronic network communications. Each of the exchanges 16-20 can also include or can be operatively connected with one or more authentication systems, such as a local authentication server 34, to authenticate the electronic transaction requests registered by each client and each vendor for a transaction given electronics. Each of the exchanges 16-20 can be incorporated, for example, as shown in Figure 2, where communications from the Internet 26 are passed through at least one firewall 36 to a secure internal network of the exchange 38 that has a web farm 40; that is, a plurality of web servers, such as servers based on "WINDOWS NT", to process Internet communications, such as HTML and HTTP data packets that incorporate, for example, electronic transactions, such that the web farm 40 support transaction requests and authentication services from other exchanges 16-20. The authentication servers 34 can authenticate the details of the payment system associated with an electronic transaction, such as valid credit card information, and then transmit the data of the electronic transactions to a bank 30 or other payment systems 32 for another authorization, compensation and processing. The VPS 10 includes one or more databases maintained, for example, in a SQL database server "WOLFPACK" 42, which contains the details about the vendors 24, the clients 22, and the payment systems. Electronic transactions are transmitted through an inter-central private WAN 14 and WAN 14, to other exchanges, for communications between a customer in a central and a seller in another exchange, or vice versa, and / or, for communications with the authority of the account 12, in order to identify the exchange that supports a given customer or vendor, indicating to which service center to which client, and to initiate the exchange of data between the exchanges. Each of the 16-20 power plants provides services to their own vendors and respective clients, and also supports service requests from other exchanges for their own customers and sellers; for example, requests for identification and authority. The configuration and administration of the services performed by each of the plants 16-20 can be implemented using the technology of "MICROSOFT LOAD BALANCING SERVICES". Figure 3 shows the general operation of the VPS 10 disclosed, to be used by customers 22. As used herein, the term "customer" can refer to any customer, buyer, consumer, or other entity that initiates and / or engage in transactions from sellers, which may include merchants, sales representatives, wholesalers, retailers, etc. The clients 22 use a computing device 48, and / or any device 50 with communications capability to connect to the Internet 26, the telephone system 28, or other communication mechanisms, and from there to make contact with a merchant and / or vendor 24 electronically for the purposes of establishing an electronic transaction, and / or to select goods, services, information or other available materials or electronic goods and information, such as archived data, online games, video clips, physical goods, etc. . The selected materials can be delivered immediately, as in the case of software and / or music loaded on the consumer computing device 48, such as a palm-top or digital TV, or a telephone 50, or can be delivered by other methods , including physical delivery. In addition, the selected materials may be games or online data that are accessible with rights of use charged in a manner concurrent with the use. The VPS 10 does not rely on any particular method of pre-selection of goods, which is always based on some communication directly between the seller and the customer. In summary, VPS 10 makes it possible to pay for goods and services accessed through electronic mechanisms, including the Internet, mobile / cell phones, digital TV, etc., following the same basic procedure, without requiring any direct communication between the customer and the seller. Once a client has selected and agreed to pay for these goods or services, the vendor 24 identifies himself before the system 10, references the transaction, and gives the amount and currency of the transaction. The client also identifies himself before the system 10, choose one of your previously registered payment systems, and agree to pay. The identities of both parties are verified, and the selected payment data is surely married off line. The transaction is authenticated in real time by means of the bank gate or other appropriate credit gate, and instructions are sent, if appropriate, for immediate or delayed compensation by the bank or vendor payment acfent. The vendor is automatically updated with the result of the authentication, and an audit trail available for all parts of the transaction is updated. Each transaction is linked to vendor and VPS reference numbers, which facilitate verification and reimbursements. A plurality of exchanges provides elasticity and scalability, each central providing authorization services to certain vendors, and verification and information services on behalf of the clients. A central account authority provides registration services, indicating which exchange serves which customer. The vendor 24 requests the authorization of the transaction from its respective exchange, such as the exchange 16. The customer 22 also requests authorization to pay from the vendor's exchange. After authentication of both the client 22 and the vendor 24, the corresponding exchange associated with one or both of the clients 22 and the vendor 24 acts as the authorization processor to authorize the transaction, and / or makes it possible to make a payment to the vendor 24 by means of the payment system 32, such as card issuers, banks or other payment systems, such as telephone or electricity companies, which finally charge the customer 22 for the transaction. The VPS 10 can also authorize a transaction without having a payment made directly. This double-key transaction to verify the payment information and the customer's authenticity information, provides greater security, in that both sets of information must come separately and in a completely independent way before it starts and / or ends the transaction. Figure 4 shows the transaction process of Figure 3 in greater detail, wherein a vendor 24 generates and sends, in step 56, a request to the authorization processor 52, which is a specific central 16-20 associated with the vendor , to authorize the transaction (Tx). This may have been the request of a client 22 to initiate a transaction in step 54 with a vendor 24. The authorization processor 52 then creates a transaction entry, and looks for information about the vendor 24 in step 58, for example, to determine whether 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 for payment of the transaction, and returns a message or code, such as a key, which may include a secret, to the seller who identifies the transaction Tx. The client 22 is informed of the key of the transaction, although he is not informed of the secret, and uses the key of the transaction to identify the transaction before the authorization processor 52 in step 64. The VPS 10 provides a transaction identification and a value, such as a "check sum", or a secret key to the vendor 24, and the customer 22 can use the transaction identification to identify the transaction, but the VPS 10 and the vendor 24 never inform the customer 22 about the secret key, which the VPS 10 includes in any communications with the vendor 24. This reduces the risk of fraud by the client 24. In an example mode, the client 22 may be using a 48 computer, and may be having access to a website of the vendor 24 to select goods or services to buy the vendor 24, and so, in step 62, the vendor 24 redirects the client's browser 22 to the screens of verification and selection of payment with the transaction key as a parameter of the redirection of the client 22. The interface of the vendor 24, which is provided to customers 22, may include a website and / or other user graphical interface (GUI) environments, such as a browser that uses plug-ins and / or writings to support, for example, page technology Server Assets and / or Commercial Order Processing Lines technology of the Server associated with "INTEL" and "MICROSOFT WINDOWS", as well as Perl writings for Unix and / or Apache environments. Alternatively, using a telephone 50, the customer 22 may select goods or services from an automated telephone service of the vendor 24, for example, using a tone telephone and a series of automated audio menus. In accordance with the foregoing, in step 62, the vendor 24 redirects the customer to a selection and payment authorization menu via telephone 50, or the authorization processor 52 calls back to the customer 22 to allow it to continue the transaction. In this way, the client 22 sends a request for payment authorization and / or selection in step 64, to the authorization processor 52. Then the authorization processor 52 verifies the authenticity of the client 22, and obtains the payment information corresponding to the selection by the customer of a payment system in step 66. From step 66, the customer's 68 detiles are obtained and verified, possibly requesting this service from another central, and then used to authorize the payment. After receiving both the details of the vendor 60 and the details of the client 68, and of verifying both the vendor 24 and the client 22, the authorization processor 52 sends an authorization message 70 to an installation receiving authorizations from the payment system 72 , and the payment system in turn authorizes the transaction, and in some cases, pays the seller 24 for the authorized electronic transaction. The authorization processor 52 then informs the vendor 24, in step 74, and informs the customer 22 in step 76, that the authorization has been made, and thus the payment was initiated, and then the vendor 24 completes the transaction sending the selected goods or services. Figure 5 illustrates a master diagram of the states of a transaction by the overall processing performed by the authorization processor 52 from step 58 of Figure 4, to obtain and verify the intended vendor as an authorized vendor, and to create an entry of transaction, wherein the authorization processor 52 generates a temporary transaction entry, and then waits for the details of the client 68, as they are authenticated, to arrive to perform the authorization of the payment system (PS) in step 72, and the notification of the respective customer 22 and vendor 24. Figure 6 is an alternative state diagram of Figure 5, illustrating the states of the transaction table in a vendor exchange, where the transaction status is communicated to vendor 24 before vendor 24 completes the transaction with the authorized customer 22 intended. If the client 22 can not be authenticated, the reasons are reported to the vendor 24, and thus, the transaction authorization request can be rejected in step 56. Otherwise, the vendor 24 'can perform a transaction of compliance or a normal transaction to complete the authorized transaction for an authenticated client 22. Other conditions, such as refunds, can also be handled. Figure 7 illustrates the processing of Figure 5, in the Wait for Customer Details state, by the authorization processor 52 in step 66 of Figure 4, to verify and authenticate a intended client, wherein the authorization processor 52 wait to receive the registration information from the intended client. Each authorized client has been previously registered, so that the authorization processor, upon receiving the customer's details, tries to match the intended client with one of the authorized clients, and after a match, obtains the details of the client 68. Figure 8 illustrates the processing of Figure 5 in the status of Attempt Authorization, performed by the processor authorizations 52 in steps 64, 66 and 70 of Figure 4, to authorize a payment request from the client 22 of Figure 4, to present payment choices to the customer 22, and to process the payment selection, which may be a Normal payment system, that is, the full amount of the transaction is applied to the payment system associated with the customer; or that it can be a Micropay payment system, that is, transaction charges are accumulated less than a previously determined amount, and subsequently applied to the client 22 after the accumulated amount exceeds a previously determined threshold, or to reduce a floating slope that is at the top when the float reaches, for example, zero. In the case where the details of the client 68 are stored in a different exchange of the authorization processor, the state of a transaction is partially mirrored in the client's exchange, in order to provide elasticity and a complete record of the transaction. available for the customer. Figure 9 shows the states of the transaction table of a client exchange during the processing of a request for the details of the client. This processing includes determining if the customer's account limits 22 are exceeded by the customer's choice, or if the Micropayment transaction is authenticated and is an acceptable payment option between the customer 22 and their authorized payment systems. The authority of the account 12 is used by the Verify Client process, to identify which central can provide the required details of the client. As discussed herein, a vendor 24 is defined as an organization receiving payments through VPS 10. A customer 22 is defined as an individual or a corporate entity registered with VPS 10 for the purpose of making transactions possible, and / or to pay for goods or services through an electronic network, such as, but not limited to, the Internet. A payment system, such as the payment systems 32, includes any system for making a payment or otherwise authorizing a transaction, such as by means of a credit / debit card, a direct debit card system, a bank account, or access to a particular bank transfer system, a service account or a billing account, etc. A receiving system is broadly defined as a system for accepting payments, and may include details, such as a bank account or merchant numbers. An owner of a payment system is a customer who owns the payment system. An authorized customer is an authorized customer to use the payment system by its owner. A customer account is defined as the customer record in the VPS system 10. A plant operator is defined as an organization that operates a VPS 16-20 exchange as an almost independent provider of VPS 10. A financial compensation service is defined as an institution responsible for the actual transfer of funds, such as a bank acquiring credit cards, but may include other financial institutions. Normally, the owner of the payment system is the 5 individual holder of a credit card, but the owner of a payment system can also be an official of a company that has a corporate credit card or a purchase card, or really , the account manager who controls an account payment system billing As described herein, a self-payment feature is defined as a feature that allows a customer to enter an exclusively assigned username and / or a personal identification number (PIN) only once during a session, instead to enter this data for each purchase. The owner of the payment system can be any individual holder of a payment method, such as a credit card owned by a customer, the holder being an official of the company responsible for the payment method, such as an official, a account manager, and / or a procurement officer of a company, for example, a corporate credit card and / or other billing accounts associated with use by the payment method. Using the VPS 10 released, customers 22 can make payments to VPS 24 sellers by means of * a * J & amp; kutSSi? lli,? i & i Internet 26 or other communication networks. The information and details about each customer 22 associated with a credit card or other payment system 32, are never transmitted freely over the Internet 26 or other communication network, but instead are only transmitted in one place. cryptically encoded form, to allow a client 22 to add or amend his account. Alternatively, modification of the Internet-based account can be avoided by allowing the customer 22 to provide credit card details or other details of the payment system by facsimile or other secure data transmission mechanisms. In addition, the details of the payment system can be pre-registered by banks or other credit issuers / account holders, allowing greater security in terms of verifying delivery addresses against the correct addresses known, for example, from the bank , and minimizing the data transmitted through communication channels, such as the Internet. The vendor 24 is never informed of the details of the credit card or other payment system 32 of the customer, unless this payment system is administered by the vendor, such as a telephone account. Payments are generally made directly to a given vendor 24 committed by the customer 22, and the customer 22 can choose to re anonymous to the vendor. Alternatively, the customer can choose to allow the seller to capture at least or at most the name and address information from a VPS database, to minimize the introduction and transmission of data from the client, as well as minimizing the exposure of customer information to unsecured systems. In an alternative embodiment, the vendor 24 may send the name, address, and / or other details with the payment request, to minimize the entry of data required for a new user. The convenience to the customer through this option may require the seller to know when a customer is a new user. In some VPS modalities, the Micropayment feature can be implemented, where very small payments can be made, such as pesetas or cents, without incurring the upper limit of a credit card transaction. These are two variants of Micropayment: first, when the seller accepts the risk of a bad debt, and second, when the VPS takes an initial deposit, and credits against the initial deposit using an automatic credit and / or debit payment mechanism. authorized. A key feature of the Micropayment VPS implementation is to make payments in multiple currencies possible by providing an automatic conversion to a common currency in the authorization processor.

Optionally, an Autopayment feature can be implemented where, with the explicit agreement of the client, the identification process can be established to be transparent after an initial identification during a session involving a client with a specific vendor. This transparent transaction processing provides a simpler process for a sequence of transactions, while maintaining an affordable security. The access and use of a given payment system 32, such as a credit card system, can be granted by the owner of the payment system to other VPS 22 clients. The owner specifies the credit restrictions for the authorized customer, and You can see all the transactions. The authorized customer can only see the transactions that customer has instigated. Customers 22 can be "pre-loaded" through financial compensation services, vendors or companies, so that the pre-load process creates a set of inactive accounts that the designated customer can activate through the use of a personal identification number. (PIN) sent separately by the customer. Previously loaded accounts can be sub-added to an existing VPS account by the customer, or can be used to create a new account.

Vendors 24 can issue refunds through VPS 10, and customers 22 and vendors 24 can authorize payments to other customers, such that VPS 10 provides flexibility and adaptability for different market and sales methods. Sellers 24 may choose to provide account facilities to specific clients or groups of customers. These account systems can seek payment through a financial compensation service when the account exceeds a certain limit, in a Micropayment form, or can submit invoices directly to the client. In the latter case, VPS 10 is acting primarily as a trust accounting system. Account statements to customers 22 and sellers 24 may be available online. Other reports may also be available for banks 30, payment systems 32, and agents, and for managing the accounts of the organization. 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, customers 22, the owners of the payment system and / or vendors 24, may stipulate certain minimum levels of security. For example, vendors 24 and / or customers 22 may insist on a validation beyond the PIN level of security details before allowing purchases above a certain amount. In addition, the VPS 10 may be able to export the accounting information, for example, out of the system 10, to an external accounting facility. The accounting information may include the number of normal transactions involved according to the type of payment system, and the movement of Micropayments, to allow an external accounting system to invoice the vendors. It is intended that VPS 10 be as open as possible, for example, that it be adapted to meet the great potential of Internet-based and E-commerce payments. The architecture of the VPS 10 allows as many future options as possible. For example, VPS 10 and the associated payment systems 32 may include credit / debit cards, direct debit, in-store accounts, service accounts, and any other form or method of moving money from one place to another. The VPS 10 also performs customer identification, for example, by receiving and accepting a simple username and password in a secure web connection. Alternatively, any other form of identification and verification may be used, including smart cards, certificates and digital signatures, and / or biophysics / biometric identification methods. Payment systems 32 and / or customer data can be saved by other organizations external to VPS 10.

FEATURES OF THE VERIFIED PAYMENT SYSTEM The VPS 10 is a value-added authentication and compensation system that is convenient to use, and offers unprecedented levels of security. The VPS is a trusted third party system that contains details of payment systems belonging to buyers, sellers and credit providers, in a secure environment, to provide the link between the parties involved in the transfer of electronic funds or in the transactions of credit accounts, such as banks and other credit providers, buyers and sellers. VPS 10 allows these parties to authorize transactions and / or exchange funds in a fast and efficient manner, without disclosing or exposing sensitive data to risk, and automating their processes. Also, VPS 10 provides a real-time, impartial audit trail for all parties - customers, vendors, banks, etc. - of all transactions for which VPS 10 enables the service. When a customer opens a VPS account on the Internet for the first time, the customer enters the details of the credit card or other details of the payment system, including the bank and the credit accounts, through a secure interface to the VPS 10, such as the secure website, or other mechanisms for the introduction of secure data. The relevant information is passed safely and protected, for example, by cryptic SSL encryption, through a VPS 10 web server, or other secure cryptic encoding methods appropriate for the initiating device, to the return office thereof, where the information is kept protected, cryptically encoded and offline, far from the web server. Payment systems can be registered with VPS 10, either offline or directly by the card issuer or credit provider, such as a telephone account, a retail store card, a credit account of a company, etc. VPS account holders, as customers using VPS 10, can register as many payment systems as they wish in a virtual account, all accessed and controlled by customers through the same unique ID. Once the account is opened, the holder of the VPS account will never be required to enter or transmit details of the payment or personal card on the Internet or any other means, but instead the VPS account holder will be identifies, for example, through a unique username and password, such as a personal identification number (PIN), plus optional additional security checks. The transactions are mediated by means of a unique double-key system: the codes that identify the merchant, the transaction, and the quantity, are sent from the merchant, while the customer identifies himself, chooses the payment system that he wishes to use for the transaction, and confirms the client's desire and his assent to pay for the selected transaction. These two streams of information, both from the merchant and from the customer, are coupled together in the authorization server 52, and are sent to the Payment System Authorization 72, and if appropriate, through a telecommunications link fast, up to the payment system selected by the merchant, such as a bank. Information about the success or failure of the transaction back to the Authorization Processor 52 is then passed, where the success / failure information is recorded and passed to both the VPS web server and the merchant server in step 74, of such that the customer and the merchant can be quickly informed about the result within, for example, three to seven seconds. Each transaction can be uniquely identified by codes assigned by the merchant and by VPS 10, thereby facilitating reference checks, monetary credits, and refunds. A self-payment feature allows the customer 22 to identify himself only once for all transactions within a single session with a vendor 24, for example, on the vendor's respective website. Very small payments can be specially processed, where all payments below a predetermined minimum amount agreed upon by each merchant, are classified as micropayments and are treated separately. Micropayments are part of a seamless service offered to merchants and account holders who use VPS 10, whereby these micropayments are accumulated and totaled until the account holder makes a transaction that causes the sum accumulated due to reach the threshold of the minimum quantity. Then VPS 10 automatically looks for the payment of the total pending micropayments plus the new transaction. Merchants who use the VPS 10, in this way can choose from two payment options. Using the first option, merchants who use the VPS 10 can choose to receive the payment directly, and allow their customers to buy goods and services on credit without a prior payment until they reach an agreed threshold. No payment is owed to the customer until the threshold established by that merchant is reached, and then the merchant receives payment for all micropayment transactions as a consolidated sum. This allows customers to purchase small goods and services incrementally, such as downloading small information files or / 31 programs, such as applets, as well as data, such as search engine questionnaires. Using the second option, merchants participate in the general VPS micropayment system, which requires account holders to pay an initial opening deposit, with merchants receiving a consolidated payment, less card and handling fees, monthly due. The first time an account holder makes a micropayment transaction with any merchant participating in the general VPS micropayment arrangement, it is owed with a pre-payment of the threshold amount, which may be, for example, a minimum of U.S. $ 15 dollars. Then you can buy goods and services through the entire range of merchants who participate in the micropayment arrangement. The customer is not charged again, until the payment threshold is reached. The United States dollars are normally used as a uniform unit of currency for all micropayment transactions globally. Initial floats, such as deposits, are taken from the credit card of account holders or any other authorized payment system in dollars. Any payments in currencies other than United States of America dollars are converted to United States of America dollars, before being deducted from the remaining floating funds, showing the converted value to the client together with the amount in the original currencies before your acceptance. The consolidated funds owed to the merchants are assessed in United States dollars, although these funds can be converted to the traders' choice currencies before their transfer. The cards and other payment systems, and also the personal details, are recorded in the VPS 10 in a secure database VPS 42 in a central 16 that performs the function of an authorization processor 52, and these details are surely kept out line, far from the interface with the vendors 24, and in such a way that details are never used or available online. Account holders can register as many cards and other payment systems as they wish in a virtual wallet, such as payment systems that include commercial and personal accounts paid monthly at expiration, accounts paid by direct debit, etc. These registered payment systems of an account holder are accessed by means of identity checks, and the details of these cards and other payment systems can be previously registered by the issuer, in such a way that the holders of the cards never have to put your card or your personal details online. This collection and retention of information offline ensures that addresses are true billing addresses, and so that it is possible for VPS 10 to perform accurate address checks on behalf of merchants, without disclosing any information of the account holder. to the merchants. According to the standard initial operation of VPS 10, the account holder chooses a unique combination of alphanumeric username and password as a PIN, and records the additional security information in VPS 10, used as an identity verification in any time later. Random questions based on additional security information are mandatory for all changes to a customer's account, and these questions are optional for transactions and query of audit trails. The PINs and additional security introduced by the account holder should always be disguised as asterisks or blank spaces on the screen. A question mechanism can be provided to help people with low memory. Other forms of identification and verification may be accommodated as deemed appropriate by banks, financial systems, and older users. The account holder can also choose spending limits at self-limited expense. Online audit trails are provided that have, for example, a resolution for time intervals down to the second, including for micropayments, for users and vendors. The accounts can be controlled online by the user, so that the details of the purchases can be checked and printed; and personal security limits can be altered as desired. In this way the account holder is in control of all electronic spending, through different banks, cards and websites, from a single online account. Additionally, an owner of a payment system, such as the registered holder of a similar payment card or mechanism, may grant rights to use that payment system to other account holders in VPS 10, which can be operated through the ideication of the holder of the granted account, with the change to the payment system of the owner. The spending limits are specified for the owner of the payment system and each granted. Sub-accounts may also be limited to use with certain vendors or vendor categories. The spending limits can 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 can change the details about an account. All currency conversion is done through the normal operation of credit cards, banks, and financial systems. Therefore, the account holder can always be allowed to pay his invoice in selected or preferred currencies, such as the currencies of the account holder's country, plus any conversion charges incurred in purchasing items in different currencies , thus automating and providing security for electronic monetary transactions, while providing the advantages of monetary conversion and use in the physical world. If the authority of the account 12 detects, for example, three errors in the security responses in an attempted transaction, the account can be frozen, and the VPS 10 records each presentation of a security error. In addition, for example, if account authority 12 detects six errors in different transactions in a twenty-four hour period, the account can also be frozen. The VPS 10 initially uses a combination of user name, password and security checks, as in banking based on known phone, to idey account holders, such as the use of random questions based on two words and a date. However, VPS 10 can also be configured to accept other forms of ideication and verification, such as certificates and digital signatures, speech recognition, iris recognition, fingerprint recognition, and other known methods for autheating a user who has access to VPS 10 as a supposedly authorized user. For example, ideication by means of smart cards can be included in the authorization processor 52, and thus, the VPS 10 can work well accordingly with the smart card-based systems, by providing direct links in the credit card accounts / debit of the account holder, micropayments without prior payments, online audit trails, etc. For merchants and sellers, VPS 10 provides all participating merchants with a secure and cost-effective method to collect payments. Payment can be made directly to merchants through their known banks and merchant numbers. The VPS 10 is designed to make it possible for merchants to build customer loyalty and brand recognition, for example, by guaranteeing customers security and privacy, both for the customer and for the merchant who participates in VPS 10. Due to that VPS 10 supports credit and debit operations, VPS 10 also facilitates customer incee schemes based on cash and various kinds of loyalty-generating promotions conducted by merchants. The VPS 10 can also provide a particular merchant with marketing and customer intelligence about the merchant's own customers, sales patterns, and global reporting, without disclosing the customer's details.

To use VPS 10, a merchant is linked to VPS 10 by means of a selection of enabling and simple or complex configuration of communications software that provides the majority of conventional web platforms and servers. Merchants use an installation and setup configuration of VPS 10 that may be appropriate for their trading platform and server. For example, the VPS 10 can be integrated with the software "MICROSOFT COMMERCE SERVER SUITE" ("MICROSOFT BUSINESS SERVER SUITE"), and with any other widely available trading enabler software. The VPS 10 is a very flexible system, designed to adapt to the individual requirements of the merchants, and to open new areas of E-commerce and web commerce, and in this way, the VPS 10 works with customers to produce solutions that adapt to the commercial needs of each client. The VPS 10 also fits well in normal banking software and procedures, where real-time validation is directly integrated with the merchant's own transaction processes, allowing full automation, and thus, VPS 10 can be easy to integrate with a merchant's site, and it must be simple and easy for customers to use. Merchants receive payment for all conventional credit or debit card transactions directly by their own merchant numbers. VPS 10 charges merchants fees, for example, based on a flat rate per transaction, and monthly at expiration. Merchants can choose to receive consolidated micropayments by bank transfer, directly to their merchant numbers, or through the general micropayment system of VPS. In the latter case, merchants receive monthly payment at expiration minus card fees and VPS handling fees. Merchants receive an immediate notification of payment for each order, integrating this notification as part of the transaction sequence of the merchant, thus allowing automation and control over the security of the validation process. Full integration with existing systems owned by merchants and vendors also enables seamless integration with order, accounting and other software products. To participate in VPS 10 as acceptors of payment by credit or debit card, merchants who use credit cards obtain merchant numbers enabled by the E-commerce of their acquiring banks., VPS 10 can assign Terminal ID numbers (TID) to the merchants from the range set aside for each bank, and then the VPS 10 informs the bank, so that the compensation can be made directly to the merchant.

The VPS 10 uses a distributed PBX configuration in order to provide full scalability and optimal performance as a universal and global system. The regional centers 16-20, either alone or grouped, guarantee fast and reliable global access and redundancy. The plants are operated directly by VPS 10, or as a series of jointly secured risks between VPS 10 and a central operator, such as a bank, a group of banks, or other brokerage houses or financial institutions. Merchants and account holders have a "home exchange", as shown in Figure 1, but VPS accounts can be used around the world. Conventional transactions are authenticated and cleared through links between the merchant's exchange and the merchant's bank, while micropayment transactions can be processed through the account holder's exchange. Secure international direct debits are made, so that the global banking system can be used to send sums from an account in a bank in a currency area, to an account in a bank in another currency area. Businesses, merchants and sellers can purchase funds; that is, receive payment in the designated bank accounts, at least a nuclear number of major international currencies, and bank customers can pay at their end in the full range of currencies. The merchant and seller's companies are informed in a substantially instantaneous manner that there are expected funds available, and they will be automatically received within a set number of days, as specified by the acquiring bank and / or by the regulatory mandates. , for example, normally three business days. VPS 10 supports this functionality to interact globally with vendors, customers, and exchanges internationally, using, for example, credit cards or corporate purchases, and other established banking systems and relationships as the medium of exchange. Accordingly, the VPS provides an automated managed facility for electronic payment / transfer of funds, a real-time online audit trail for all parties, controlled payment routes, and a system for supporting multiple currencies. VPS 10 offers these services integrating substantially or completely with the database server of each vendor. Also, vendors who operate within VPS 10 and receive funds, for example, through merchant numbers, must be approved by banks that support VPS 10, and thus, VPS 10 is self-regulating. Payment systems are securely registered within VPS 10, VPS 10 acting as a third party in trust, and are accessed through the use of identification numbers or transaction reference. The shared payment system provided by VPS 10 offers a secure and simple method for establishing international direct debit arrangements. VPS 10 also links directly to the global banking system through individual banks 30, to provide real-time authentication and compensation directly to merchants' accounts. However, the sellers are never given the details of the payment systems, and therefore can not abuse them, because the payment systems can only be used to transfer sums to the accounts of the merchant numbers held by vendors within 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 VPS 10, and can be secured for their exclusive use, thereby providing an entirely secure closed circuit. Although VPS 10 can operate through the Internet 26, VPS 10 does not depend on the Internet 26, because all the key processes performed by VPS 10 are presented offline. Major customers, who manage large cash flows, can choose to communicate with VPS 10 through dedicated leased lines. In the case of direct debits and closed circuit use, information is never exchanged sensitive through the Internet 26, thus eliminating the need for high-level cryptic encoding, digital certificates, etc., used by VPS 10, which increases the complexity and cost of using VPS 10. In accordance With the above, VPS 10 provides an extremely simple and secure method for transferring inter-currency business sums. VPS 10 also provides a universally expandable system for E-commerce, which is a truly distributed system, where an ID allows users and vendors to mediate all transactions through the same globally accessible system, providing the design from the plant a fast service and backup facilities. In addition, previously registered credit cards can be used, so that new online records and address checks and personal information for each customer are not required for each credit card. In addition, card issuers can open latent VPS accounts in the name of their card holders, by registering the details of the card plus names and addresses, as well as temporary PINs, and a temporary username for each account, which can also be generated for this purpose by means of VPS 10. The card holders can then be given the temporary user name and ID needed to access their VPS account, following the usual security procedures. Once the client gives his username and ID, which can be temporary, and verifies his identity, through a secure VPS interface, he can activate the account and can choose a new username and PIN, extra ID checks , and a custom spending limit, and optionally record other details, including other payment systems and personal data. Clients can group all their payment cards together in one account, accessed, for example, by the same security checks. Because the basic VPS account information comes directly from the card issuer, this information includes the billing address of the card, which allows the VPS 10 to initiate and verify an accurate address at the same time as the authentication of the transaction. These address checks allow merchants to verify that the delivery address given in an order form corresponds to the billing address for the card. The VPS 10 also operates with clients, so that personal identification can be done without additional hardware or software; that is, a client does not require special hardware or software to use the VPS 10. A customer's entries to identify themselves and build a transaction with a vendor are not transferred through a web browser, and thus, there are no electronic wallets, software, such as "JAVA", or navigation applets or cookies required for the operation of VPS 10. Therefore, VPS 10 can be compatible and can be interconnected with all machines with a communications capability . By not disclosing customer information, sub-secure accounts can be implemented, so that a parent can authorize their children to use their credit card up to a fixed amount; A company can authorize a department or individual to use a corporate purchasing card within a budget and within the parameters of purchase, for example, the use of the account can be linked to goods, services and / or sellers and specific customers . A provider can authorize a customer's company to use a credit account, which in turn can be subdivided between departments and individuals. The account holder can monitor and control all transactions using their payment system through an online VPS audit trail. Users are never given the details of the payment system, such as the card numbers used, or the given VPS ID, used by the account holder. Customers may have registered payment systems that they do not own, but that they have permission to use and associate with their virtual VPS portfolios, with their other payment systems. Using VPS virtual wallets, customers can pay for goods and services, and monitor spending, through their own VPS ID. This very flexible system is also the basis for establishing store card accounts and direct debits, including the payment of services, and monthly credit accounts. In this case, the account holder gives the seller permission to use his payment system, such as a credit card account, to take the regular payment for agreed goods and services.

OPERATION OF THE VERIFIED PAYMENT SYSTEM Normally, the VPS 10 uses the following main data for each client: name; address and contact details; Email address; security information, such as user name, PIN; security questions, and authorization PIN for accounts loaded by volume; confirmation code, such as a code by which a client informs the transferred of potential funds to confirm that a user's ID is typed correctly; available payment systems, such as credit card details, which may be limited to an arbitrary limit of twenty payment systems per user, possibly at the level of the user interface (Ul); a group name, such as the name of a company or family; the type of account, such as "corporate" or "private"; status information, such as "super" user, account disabled, etc .; customer preferences, such as anonymous, allow self-payment, security levels, preferred payment system, etc .; credit limits for the payment system; specific account information of the seller; and a minimum level of security. A customer can be added to VPS 10 by appearing with VPS 10 as a payment option during or before an online purchase. However, for groups, the group owner or group manager can add clients. For groups, some payment systems may be hard-coded and may be inaccessible to unauthorized customers. Customers or customer groups can also be added through a "batch update" process, and can be subsequently activated by the customer using, for example, an authorization PIN supplied separately. Customers can make changes to their VPS accounts at any time, including the user's name, PIN, security details, personal credit limits, and type and identification of payment systems. Authorized customers can change their limits by going down from a maximum set by the owner of the account, or they can change their security levels from the minimum established by the owner of the account. Customers can also generate and view different reports on their use of the system. Once an account is deleted, or a user name is changed, the VPS account remains dormant for a previously determined period of, say, six months, before the previous user name can be reused within the VPS. 10. To manage customer accounts, the account administrator can add a new account, disable or enable an account, delete an existing account, change and / or view the personal, security and / or customer payment system details. associated with the account, and change and / or view the customer's preferences. The pre-charge of accounts is an operation that can be made to measure, because the data format for the account information can be different for each payment system. The accounts can be preloaded in a reference table, and the owner of the corresponding account is notified about the reference table and the status of the previous charge, for example, by means of a letter written to the owner. This notification can include an access code, so that the owner of the account 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. With respect to vendors 24, VPS 10 may retain the following principal information about each vendor: name; address; security username; Security PIN; authorization of payment system; bank information, such as TID, classification code, and account number for payments; Account, customer and transaction details for vendor-specific micro-payment or billing accounts; security / payment preferences; commission details, contacts; Internet Protocol (IP) domain; and business category. Each of the vendors is operatively connected to at least one of the central 16-20, which supports the seller, and manages all transactions with the seller and customers who initiate transactions. To establish itself, a seller fills a contract, and provides bank authorization to VPS 10 for third-party TID payments and for a payment system, such as direct payments, or debit or credit cards, that allow fees to be extracted. These payment systems are accounts where payment is not made immediately, and the seller accepts the financial risk. These payment systems, such as deferred payment accounts, are a set of normal billing accounts, for example, for blue chips, or for a type of micropayments account accumulations, where payment is only made when the account reaches a certain level. level, or alternatively, after a previously determined period of time, such as one month.

At least initially, vendor accounts can be created by VPS personnel or VPS agents, although the initial details can be entered by the vendor through the Internet and / or the World Wide Web. The seller specifies a payment system to allow rights to be extracted. A bank contract must be provided to configure the vendor's IDs and TIDs or other payment systems. The customer and / or the vendor can be provided with an annex or installation kit to perform acceptance tests with the VPS 10. The vendor is then ready to operate with the VPS 10. The vendors can be administered in basic terms of name and details of address, payment preferences, billing accounts based on the customer, etc. For sensitive or secure issues, such as banking information, where an error can cause the VPS 10 to stop the work or put it in the wrong account, the details are communicated directly to, and are directly modified by, the VPS staff. . The specific functionality performed in the systems of each vendor may include: changing / viewing the business name or address, personal security information, payment system authorization, bank and / or TID information, preferences, and credit information. client of the billing account.

To use VPS 10, a form of vendor-specific payment method may include a type of micropayment facility where the customer's payment system is only owed when a certain total transaction value is reached. Accordingly, the customer may have purchased, for example, four or five items during a couple of weeks before his card is debited, and / or when he reaches the total, for example, of U.S. $ 20 dollars. A second form is a "normal" billing account between the seller and potentially a large customer, where the VPS 10 mediates the transactions and provides billing information to the seller, but the seller invoices the customer directly. The seller establishes a credit limit on the billing account, and it can be considered that this payment system is owned by the seller and granted to customers, for example, through the authorized customer agency. The seller may choose to pay money to a customer, for example, as a reward for loyalty, as a refund, or as a payment of profits or promotional activities of the seller. The payment can be in support of a transaction made previously, in such a way that the seller does not need to know the details of the clients, as it is enforced through the VPS 10. A seller's transaction code is used to identify the customer, the credit card or payment system information, and the refund is made appropriately. If the credit card is no longer valid, the cash equivalent is transferred to a proprietary account, and the customer can be notified, for example, by email. Then the customer can use an interface associated with the vendor and / or VPS 10 to specify which payment system will be accredited. If the customer of the credit card or other specified payment system is no longer in the authority of account 12 of VPS 10, the seller is notified, and VPS 10 sends by mail, facsimile, or via email, a Notification to the client, to allow the issue to be resolved directly, but VPS 10 does not disclose the personal details of the clients. For the daily compensation, the authorization processor 52 has approved the transaction, but the funds will not be transferred until the next batch compensation with the payment system. For deferred compliance, the payment has been authorized, but the goods are not ready to be shipped. Compensation is only sought when the seller informs VPS 10 that the goods are ready for shipment. Complexities arise if authorization is delayed, in which case, it must be reconfirmed. For monthly invoicing, the seller is informed of purchases made through the payment system in question on demand. This information and / or your own records are used to create an invoice for that customer. For the payment on the accumulation of sufficient debt, as in the Micropayments arrangements, the transactions accumulate until they pass a specific threshold. At this point, authorization / compensation of the payment system is attempted for the unpaid amount. These transactions can be through a general micropayment account, or other accounts held with or through an account held by the specific seller of that customer, where the seller takes a financial risk on the transaction. To initiate an authorized payment, the seller sends the following information directly to the payment system to allow the purchase request to be corroborated: a transaction code, the amount of the transaction, the type or transaction preference, such as deferred, immediate , account, Micropayment, etc.; and additional security information, such as a zip code or other confirmation information. A transaction payment can also be divided through several payment systems of a particular customer, such as U.S. $ 500 on a credit card, and U.S. $ 400 on another credit card, for a total charge of U.S. $ 900 for the transaction. If the customer has a preferred payment system, then a preferred payment system is automatically selected, unless the transaction is Micropay, and the preferred payment system does not support the Micropayment, or the preferred payment system is not supported by the seller. Normally, the user selects which payment system to use, from a list of available payment systems that are compatible with the payment systems supported by a particular vendor. After the success or failure of a transaction, the client is returned to an appropriate point, such as the website where the client was present before initiating the transaction. Self-payment is a feature that can also be supported by VPS 10. Self-payment is a process by which a customer merely confirms their personal VPS ID once they are in a transaction session. After the first payment in a session, a series of data transfers are used, which can optionally include browser-oriented cookies for Internet-based E-commerce, to confirm the identity of the customer. These cookies do not include secure information, they are deleted when entering a new session, and they have a limited life time. Self-payment can also be time-out if there are too large gaps in time between individual transactions. VPS 10 can also generate many different reports for different purposes, as described in Table 1. In general, reports and reports include dates, seller and transaction codes, and the amounts involved. These reports only include the methods that allow the client to be identified, if both a vendor and a client agree on the identification of this client according to their preferences.

TABLE 1 SECURITY OF THE VERIFIED PAYMENT SYSTEM The security of the customer, the seller and the transaction is provided by having all secure data communications, such as user IDs, PINs, quantities, etc., which, for example, are cryptically encoded to a 40-bit SSL level. Credit card transfers and other details of the payment system occur only once from the Client to VPS 10, and are protected by at least, for example, a 40-bit SSL. Additionally, the customer has the option of communicating these details separately by facsimile or telephone. Internet security in VPS 10 can be done by tracing IP addresses for all transactions. IP addresses for sellers are checked against their domain names. IP addresses for clients are recorded to allow tracking in the event of fraud. If the same client tries two transactions at the same time, the customer can be alerted or informed by e-mail, for example, if the customer's details have been stolen. An intra-central security is implemented in a number of levels. At the top level, a supervisor controls the access rights of the operators, but they themselves can not have rights beyond this administrative function. / | ^^^ gg ^ At least two passwords can be held by different individuals, and they are registered with the fiduciary third parties to cover emergency conditions. The details of the cryptic encoding methods will be known by the Chief Technology Officer (CTO) of VPS 10, as well as by any necessary delegates. These details can be registered externally securely. All the source code that supports security is also protected with a password. The purpose of this higher level of security is to access and manage the inherent security of VPS 10. In general, users at this higher level are restricted to limited areas of VPS 10. The second level of security allows the administration of internal users of the VPS 10. VPS 10. Users at this level and their properties and access privileges can only be changed by security people at the top level, but second level users have the ability to grant access to VPS 10 operators. In addition, these second level users are able to examine and / or generate audit trails, as required. The audit trail for an acquiring bank can include all the details of a customer's credit card. The third level of security includes normal users and VPS 10 staff who have access to client and vendor accounts, usually to amend details, enter credit card information received by fax, and confirm transactions to customers and sellers with proper identification. All sensitive data, such as the details of the payment system, are kept in the database 42 cryptically encoded to a high level of security. The inter-central security is provided in such a way that all communications between the exchanges 16-20 with each other and with the account authority 12, are cryptically encoded up to the most practicable level. You can use the cryptic encoding features of the operating system, such as PPTP. Mixed functions and other one-way functions can be used to increase mixing and security.

AUDIT TRACES Audit traces are provided for transactions within a plant, and transactions are duplicated when a vendor exchange and a customer exchange are different, because a transaction is in the audit trail in each exchange. . Audit traces are usually filtered to preserve the privacy of clients 22. However, an acquiring bank may have the right to audit certain data of the VPS 10 client, but only with respect to transactions concerning bank authorizations.

THE AUTHORITY OF THE ACCOUNT The authority of account 12 works to prevent duplication of customer IDs after adding new clients. The list of authorized customers and their customer IDs are replicated from the authority of account 12 to all exchanges 16-20 for performance and elasticity purposes. At each step of the operation using the authority of account 12 and / or exchanges 12-20, the electronic transaction, from the request for compensation and consolidation, is treated as a series of "microtransactions". Any system failure provides that the VPS 12 is returned, and transactions in a dangerous state can be identified and resolved manually. For example, in a failure during authorization, issues passed to the bank for authorization can be determined and verified with respect to those received. In a similar way, you can also identify the sending of acceptances or rejections to a vendor in the event of a system failure. For this operational performance, the Microsoft Message Queuing (MSMQ) system can be used for communications between the 16-20 power stations, which can guarantee the status of all communications. Typically, in one mode, you can support about 8 transactions per second per node on a single ISDN channel, up to 128 transactions per second (tps) on a 1 MB link, which is approximately 11 million transactions per day. At this speed, the costs of 1 tube of 1 MB are negligible, compared to the benefits of providing this high-speed transaction processing.

MESSAGE FORMATS A preferred mode of VPS 10 uses the HTTP "POST" protocol, to dispatch service requests, to receive service results, and to allow interaction with vendors and customers. Other modalities would include message enfilamiento services, DCOM, etc. in the e-commerce user according to claim 1, wherein the formats of a number of example messages and responses are described for interconnecting with the components of VPS 10, which form the seed of the operational side of the VPS 10. In a based mode On the Internet, the data is encoded in the Universal Resource Locator (URL), and can be sent as if the data were sent by a button or SOMETER icon in a GUI form. The message of Authorize Transaction can be purely intra-central, while other messages, such as V e r i f i c a r L i m i t e s and O b t e n e r D e t e 11 e s D e P S, - & - »« '* * Verify Limits And Authorize Micro Pay, VoIP Notification, and Abandoned Transaction, can be inter-central, or can be intra-central if a client and a vendor are in the same exchange. The AuthorizeTransaction message is a packet that is sent in an authentication server row, where an application packet is sent as follows: In response, the returned data packet includes the following: The message Verify Limits and Get-Details of P's is sent from the central of a vendor to the central of a client, for the purpose of acquiring the information of the Payment System (PS) for authentication. The customer's central office, using the message of Requests for the Service Payment System, verifies that the limits of the account and the payment system are not exceeded, and returns an error or the information of the payment system. The request package for the VerifyItList and GetDetailsDePs message includes: ^ fa & a »$ ^ á ^ * .- ^" ^ - ss 10 fifteen twenty The corresponding response package is: And * ?? í.y The message Verify Limits and authorize Micropayment is dispatched from the central of a vendor to the central of a client, for the purpose of authorizing a micropayment. The expected answers are authorized or not. The application package sent is: aüfelel - »The corresponding response package is: The Volume Notification message includes any number of batch notifications that indicate that a transaction has been cleared, that deferred compliance has been canceled, or that the compensated transaction has been charged back, and the cancellation is made after the compensation. In this way, the package has a heading indicating the 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 application package is: -? í.

The format of TX Compensated is: The Deferred Compliance Cancellation format is: The Return Charge format is: An Abandoned Transaction package is used to indicate that a transaction has been abandoned. If the authentication server of the vendor's exchange rejects a transaction, the customer can try another payment system, which implicitly informs the customer's central about the failure, or the exchange can abort the transaction. If aborted, this package is sent to synchronize the customer's exchange, which only applies if the customer and seller's exchanges are different. If the exchanges are the same, the vendor component performs all the writing, and the client server components remain passive. The application package is: The interconnections with the external world, such as the requests of clients and sellers, as well as notifications to the sellers, are conducted through HTTP messages using SSL. The following requests are supported: Start of the Seller Transaction, Notification of the Seller's Compliance, Seller's Credit against the Transaction, and Customer's Transaction Payment Request. The following notifications are supported to sellers: Complete Transaction (Aborted, Rejected, Approved), Compliance Expiration Notification, and Exception Notification. Each subsection of the present identifies the message variables that are required, and the possible details of the format of the return values. The return codes will be plain text, one field per line with a "Name = Value" format. For example: OurTx = A23452-1234-232 IP = 255.200.2 You can also use messages in XML format. You can also perform cryptic encoding of the message content.

The Seller's Transaction Start message is sent by the seller to indicate that the customer wants to make a purchase. VPS 10 records a transaction in a transaction table, and returns the transaction code and IP address for future communication with the customer. The parameters can be: : ^^ | £? Then the message returns: A message of Seller's Compliance Notification is sent when the seller wishes to fulfill a deferred compliance transaction. The parameters are :: The message returns: A Seller Credit Against Transaction message is sent to instigate a credit against a transaction. The credit can be simply for the purpose of repayment, or it can be claimed to pay profits, etc :. The parameters are: The message returns: A Transaction Payment Request is generated from the Customer when the seller has informed VPS 10 of an outstanding request, and the seller redirects the customer, such as the customer's browser, to redirect to the respective customer's exchange. The URL used is specifically the one returned from the Seller's Transaction Start message. The parameters of the Customer Transaction Payment Request are: The message has no specific return, which depends on the processing that occurs to respond to the request. The Complete Transaction message is sent to the vendor's website, which is specific, either through a default URL, or that specified in the initial Transaction Request message, when an active transaction is completed normally. The parameters are: The message returns: 15 A Compliance Expiration Notification (or expiration) message is sent to the seller when a deferred compliance transaction passes a sale date of the ¿^^^ ¿^^^^ 3 ^^^. ^^ transaction. This message is for information, and is sent again until a response is received, such as "OK", or "UNKNOWN TX". The parameters are: The message returns: A Status Request message allows the vendor to interrogate VPS 10 regarding the exact status of a transaction. The parameters include an ID d & seller's transaction or VPS 10, a seller's code, and other information pertaining to the transaction. The message returns the status of the transaction, the amount, the start time, and the time and nature of the last action. By means of the foregoing, the system and method of payment verified by means of the preferred embodiment have been disclosed, however, numerous modifications and substitutions can be made without departing from the spirit of the invention. For example, although the preferred embodiment discusses an Internet-based configuration, it is entirely within the scope of the invention to contemplate primarily telephone-based configurations in the manner stipulated above, such that the system disclosed can be implemented by any configuration of known network 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 currencies used by VPS 10 can be British pounds sterling, the Euro, the Eurodollar, or any other previously determined currency or monetary / financial denomination. In accordance with the foregoing, the invention has been described by way of illustration rather than limitation.

Claims (11)

1. A verified payment enablement system (VPS) (10) to enable all parts of an electronic / digital transaction, including a customer (22) and a seller (24), to mediate secure electronic / digital transactions, comprising the VPS : a) a third-party trust registration system that enables the secure and private registration of identification, verification and payment data by customers, vendors, and payment systems, including banks; and b) an audit trail generator to generate an audit trail of a respective electronic / digital transaction, with the audit trail available to all parts of the electronic / digital transaction; and characterized by: c) a plurality of exchanges (16-20), connected by a private network (14), and connected to the vendor, the customer, and a payment system (32), having the central elements (56, 60; 64, 68) so that the seller and the customer communicate separately with the VPS system; and d) an account authority that provides registration services that detail which central supports which client; whereby, these secure transactions are mediated without direct communications between the parties.

2. A VPS (10) as claimed in claim 1, wherein the VPS (10) implements a self-payment feature that allows a client (22) to identify itself only once for all transactions within a single session with a seller (24).

3. The VPS (10) of the claim > n 1 or 2, wherein the instructions verified from the vendor (24) to the customer (22) in an electronic transaction / respective, are received separately by a central.

The VPS (10) of claim 1 or 2, wherein the exchanges (16-20) store the customer and seller data, including user names, digital certificates and payment system data, and where the exchanges (16-20) prevent private data from being transmitted to the parties of a respective electronic / digital transaction during the processing and completion of the electronic / digital transaction as an assured electronic / digital transaction.

The VPS (10) of claim 3, wherein each of the plurality of exchanges (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.

The VPS (10) of claim 1 or 2, wherein an owner of the respective payment system grants a set of rights of use of a respective payment system, including a credit card system to the VPS customers ( 10).

The VPS (10) of claim 1 or 2, wherein the vendor (24) in response to the electronic / digital transaction authorization directs the client (22) to the authorization processor (12).

The VPS (10) of claim 7, wherein the client (22) and the vendor (24) connect to the plurality of exchanges (16-20) through at least one network (26), to initiate and enable the electronic / digital transaction.

The VPS (10) of claim 8, wherein the network (26) is one or more telecommunications systems, such as at least one of the Internet, satellite, cable, cellular, and infrared communication systems; and wherein the customer (22) makes a transaction with the vendor (24) through an electronic interface.

The VPS (10) of claim 1 or 2, wherein the payment systems, including credit and / or debit card systems, can be previously registered within a secure universal system by card issuers or other shippers of the payment or credit system.

11. The VPS (10) of the claim > n 1 or 2, wherein the payment for the electronic / digital transaction is made using a micropayment arrangement, where purchases below a previously determined value are debited against a previously paid amount of credit, based on the US dollar of the United States of America, belonging to the customer, which is automatically filled due to a previously arranged payment system.