HUP0103385A2 - Verified payment system - Google Patents

Abstract

The intermediary payment authorization system of the invention for conducting secure, electronic/digital transactions between client and service provider, which system includes a) a trusted, third-party registration system that stores clients' and service providers' IDs, verification codes, payment data and bank data, b) by any participant of the electronic/digital transaction an audit list generator that can be used, and which c) is connected between the individual participants of the private network (14) and the payment authorization system (10), and also between the private network (14) and the payment system (32), enabling the establishment of a selective connection with the payment authorization system (10) has hubs (16, 18, 20), d) has a VPS bookkeeping body (12) that registers the assignment of the hubs (16, 18, 20) and clients, mediates the execution of the transaction without direct contact between the responsible parties. HE

Description

^of.OTGoP01Ο 3 5 8 5

-RGT/GBOW! 886

Representative:

PUBLICATION COPY

DANUBIA Patent and Trademark Office Ltd., Budapest

INTERMEDIATE PAYMENT AUTHORIZATION SYSTEM

The invention relates to an intermediary payment authorization system for conducting a secure electronic/digital transaction between a client and a service provider, which system includes a) an authorized third-party registration system storing the identifiers, verification codes, payment data and bank details of clients and service providers, b) an audit trail generator that can be used by any participant in the electronic/digital transaction.

The Internet is increasingly becoming a global, central nervous system through which international transactions between individuals and institutions take place. However, the Internet is not secure in terms of data protection if primary data, such as payment system data, is transmitted over it in every electronic transaction. The holders of primary data and the persons and institutions that control them, such as banks in particular, need to preserve the confidentiality and privacy of their data, and therefore they need systems capable of preventing data theft and transmitting data securely. The holders of primary data need to access their own data in order to identify themselves to others and to authorize transactions. Each party involved in a transaction needs a factual record of the transaction that is suitable for evaluation, automation, and reconciliation.

The objective of our invention is to provide a device capable of satisfying this need.

Electronic commerce (E-commerce) has become a common possibility with the use of the Internet and other telecommunications networks in the relationship between the client and the service provider. Networks connect banks and card issuers, other service providers, through which electronic money transfers and the identification of the cardholder at the point of purchase and the authorization of card payments (EFTPOS) are carried out, and global, relatively secure electronic commerce can be implemented, among other things, using the Internet. Such electronic transaction transactions usually include a post-verification operation, in which the bank cardholder subsequently checks the balance of his card account, which is sometimes only possible weeks after the transaction is completed, when the balance is communicated. Real-time verification is theoretically possible, but it involves a high network load, requires a lot of bandwidth, and is therefore generally not feasible.

Real-time verification and payment authorization is achieved to a certain extent in the use of smart cards and other payment systems, such as credit card payment systems, where the client uses his own bank card for payment and identifies himself with a code at the place and time of purchase. However, the credit card must be previously topped up with a credit line, a deposit, which does not bear interest, is disadvantageous for the cardholder, and this limits the use of the payment method. Moreover, the loss of the bank card is a direct financial loss for the injured client. On the other hand, if there is a small deposit on the wallet-type card, it disadvantageously limits the client's current solvency. This limit is typically, for example, USD 500, between two top-ups of the card.

Pays et al: “An Intermediation and Payment System Technology” Computer Networks and ISDN Systems, vol.28, 1996, pages 1197-1206 describes an intermediary payment authorization system. Tygar: “Atomicity in Electronic Commerce” Proceedings Of The Fifteenth Annual Acm Symposium On Principles Of Distributed Computing, 23-26 May 1996, pages 8-26 provides background information on electronic commerce and especially on the “atomicity” of logical operations, which ensures that either all operations are executed or none of them are executed.

In the transactional relationship between client and service provider, flexibility is needed on the one hand, and security on the other, including real-time monitoring and the possibility of refusing payment.

Electronic commerce payment systems are practically not suitable for handling micropayments (aggregate) of small amounts (e.g. amounts less than 10 USD). Such payment requests are becoming more and more common, for example when downloading small amounts of data via the Internet, or for small amounts to be paid for information or software services. According to current practice, in such cases, payment is made by individual transfer, which requires the transfer of the payer's identification and card details and payment authorization.

In electronic commerce, there is a need for a usable, secure and controlled solution for satisfying small-amount payment requests (Micropayment) through a collection system.

Business transactions are built on a certain level of trust and subsequent identification. If this trust is not established by a prior relationship, which is increasingly common in the competitive and mobile markets, the transaction is subject to identification, verification, the possibility of refusing payment, and the payment service providers between which the transfer is made.

Payment to a service provider accessed via the World Wide Web (www) using a search engine (browser) is becoming increasingly common. However, the data security of such a connection via a search engine is very low. For example, the client marks the search information with a "cookie" and stores it on his computer, which can be easily hacked when connected to the Internet.

It follows from the above that there is a need and demand for a secure and selective payment system that can be used on the Internet but is not based on search engines.

Our aim with the invention is to eliminate the aforementioned shortcomings of known solutions by developing an intermediary payment authorization system that enables secure transactions in the full, usual range of transactions, from very small to very large amounts, using any telecommunications-capable device, with immediate and subsequent payments, with respect to payments according to agreement and without prior transaction.

The solution to the problem according to the invention is an intermediary payment authorization system for conducting a secure electronic/digital transaction between a client and a service provider, which system comprises:

a) a third-party registration system that stores the identifiers, verification codes, payment data and bank details of clients and service providers, b) an audit trail generator that can be used by any participant in the electronic/digital transaction, which payment authorization system has hubs connected between the private network and the mentioned individual participants of the payment authorization system, as well as between the private network and the payment system, enabling the establishment of a selective connection with the payment authorization system, d) a VPS accounting body that registers the association of hubs and clients and mediates the processing of the transaction without direct contact between the parties responsible.

Preferably, the payment authorization system has an Autopay system that allows the client to be identified for all transactions within the same relationship between the client and the service provider.

Preferably, the payment authorization system has a hub that separately receives verified instructions from the electronic/digital transaction service provider to the client.

Preferably, the payment authorization system has hubs that store user names, digital certificates, and payment system data between the client and service provider data and do not share them with the user during the execution of the electronic/digital transaction.

Preferably, each hub includes a processor for evaluating and/or authorizing electronic/digital transactions and/or authorizing payment through a financial institution.

Preferably, the client of the payment authorization system is authorized to use a bank card payment system.

It is advisable that the payment authorization system has a means for the service provider to direct the client through a hub during an electronic/digital transaction to a VPS accounting body that mediates the processing of the transaction without direct contact between the parties involved.

Preferably, the client and the service provider are connected via an electronic network.

Preferably, the electronic network comprises at least one of the Internet, a cable network, a cellular network and/or infrared telecommunications devices, to which the client and the service provider are connected via an electronic interface.

Preferably, the bank card or other payment or credit system is a registered member of a secure, general system.

Ideally, a payment of less than a specified value that completes an electronic/digital transaction is made using the so-called Micropayment system, debited from the client's U.S. Dollar-based deposit.

The intermediary payment authorization system according to the invention enables secure payment through the mediation of an authorized third party, with real-time verification and the possibility of refusing payment, without the electronic transaction parties (client and service provider) knowing and storing each other's confidential data. Both the paying client and the service provider receiving the payment contact the third party independently and identify themselves with two types of keys. The transaction has a unique identifier, based on which the third party matches the two connections. This solution is much safer than if only one party were to give instructions, as is common in current practice, and also provides greater flexibility in the verification and execution of the transaction, and in possible intervention. The third party therefore plays the role of a switchboard between the service provider, the client and their payment systems. To this end, the participants register themselves in advance with the third party.

The client can choose a payment and approval method from those offered to him and accepted by the service provider, if he has accepted the amount and currency indicated by the service provider. Acceptance and payment take place in a closed system, in which neither party participates, neither party knows the detailed data of the other's payment system. It is also possible to use a corporate bank card by others, up to a specified amount, where the cardholder can check and determine the delegated right of use.

All participants receive real-time information (audit) during the transaction, so they can track it and intervene if necessary. The system is software-independent and hardware-independent, so it can be implemented using any method of electronic information communication. Pre-registration eliminates the need to communicate confidential data between the transaction parties, which is beneficial in terms of financial security.

The essence of the invention will be described in detail below, based on the drawing of an exemplary embodiment. In the drawing,

Figure 1. Schematic of an intermediary payment authorization system, the

Figure 2 is a detail of the system according to Figure 1,

Figure 3 is a generous flow chart of the system's operation,

Figure 4 is a more detailed flow chart of the system operation,

Figure 5. transaction flow chart, the

Figure 6 is a continuation of the flow chart of Figure 5,

Figure 7. Flowchart of waiting for client data, the

Figure 8. Transaction authorization flow chart, the

Figure 9 is a continuation of the flow chart of Figure 8.

An essential part of the intermediary payment authorization and payment system according to Figure 1 is a transaction-supervising VPS accounting entity 12, which is connected to a network 14 forming part of the payment authorization system 10. Furthermore, locally separated hubs 16, 18, 20 equipped with a transaction and/or payment authorization processor are connected to the network 14, which hubs 16, 18, 20 are in contact with a client 22 and/or a service provider 24 via an electronic network, for example the Internet, in a timely, secure, efficient and cost-effective manner for the execution of a transaction.

Client and service provider information is stored in the hubs 16, 18, 20. In an alternative solution, some clients 22 and some service providers 24 communicate with the hubs 16, 18, 20 equipped with the appropriate modems via telephone, cellular (mobile) telephone or other telecommunications system 28. Various institutions may also connect to the network 14 via the local authorization servers 34 of the hubs 16, 18, 20, such as typically one or more banks 30 and credit card issuers or other payment systems 32, connected directly or via an internal network to the payment authorization system 10.

The network 14 may be a wide area network (WAN), a portion of the Internet, or other electronic communications network. Each of the hubs 16, 18, 20 may be in operative communication with one or more authorization systems, such as a local authorization server 34, which authorizes electronic transactions between a client and a service provider.

The connections of the hubs 16, 18, 20 are shown in Figure 2, by way of example. The message coming from the wide area electronic network 26 (Internet) passes through at least one firewall 36 to a secure, inter-hub internal network 38, to which internal network 38 a group of web servers 40 is connected. The web servers 40 are, for example, WINDOWS NT-based servers that process the data packets of the Internet in HTML and HTTP format, which carry, for example, electronic transaction information. The web servers 40 therefore support the processing of transaction requests and customer identification from other hubs by the hubs 18, 20. The authorization servers 34 accept the payment system details associated with the electronic transaction, such as valid bank card information, and then forward the accepted information to a bank 30 or other payment system 32 for further acceptance and execution.

The VPS 10 payment authorization system also includes one or more databases, such as a “WOLFPACK” SQL database server 42, which database contains detailed data of the service providers 24, detailed data of the clients 22, and detailed data of the payment systems. The data transmission path of the electronic transaction leads via a data selector 44 and a secure, internal network 38 between the hubs or a private WAN 14 network to the hubs 16, 18, 20 of the clients 22 and the service providers 24 conducting the transaction with each other, and/or to the VPS accounting entity 12 supervising the transaction, which VPS accounting server 12 identifies the hubs supporting the given client or service provider, indicates which hub supports which participant (client, service provider) and initiates the data exchange between the hubs. Each hub 16, 18, 20 serves its own client 22 or service provider 24 and also supports service requests from other hubs to its client 22 or service provider 24, such as authentication and authorization requests. The services implemented by the hubs 16, 18, 20 can be managed and configured, for example, using the “MICROSOFT LOAD BALANCING SERVICES” technology.

A high-level flow chart of the operation of a VPS 10 payment authorization system used by a client 22 is shown in Figure 3. The term client 22 is used in a general sense, i.e. a client may be a buyer, consumer, or other person who initiates or participates in a transaction with a service provider 24, the service provider 24 may be a merchant, agent, wholesaler, etc.

Clients 22 using client computers 48 connect to the electronic network 26 (mostly the Internet) via a landline telephone or other transmission technology terminal, such as a mobile terminal 50, and contact a service provider 24 for the purpose of purchasing goods, services or information. Such purchasable information may be, for example, stored data, online games, video clips, etc. The selected material may be software and/or music that can be downloaded immediately, or it may be goods that are delivered by traditional physical means. There are also selectable online games that require a fee to use. The VPS 10 payment authorization system is not tied to a single goods pre-selection method, which would always assume a direct connection between the client 22 and the service provider 24.

The VPS 10 payment authorization system thus enables electronic payment for a good or service, using the Internet or other 26 electronic networks, telephone or digital TV, according to a single basic procedure, without using a direct connection between the client 22 and the service provider 24. If the client 22 has selected a good or service and has decided to pay its price, the service provider 24 identifies itself in the VPS 10 payment authorization system, provides reference data (transaction identifier) uniquely characteristic of the transaction, and provides the amount/currency data to be paid. The client 22 also identifies itself in the VPS 10 payment authorization system, provides the transaction identifier, the data of the payment system 32 chosen by him and his intention to pay. The VPS 10 payment authorization system verifies the identification and payment data of both parties and collates them in a secure off-line manner, establishes a real-time connection with the designated bank 30 or other payment system 32 and instructs it to transfer the funds to the service bank 24 immediately or on a deferred basis as specified by the service provider 24. The service provider 24 is immediately notified of the completion by the VPS 10 payment authorization system and each party's transaction audit trail is updated. Each transaction is associated with a reference number of the service provider and the VPS 10 payment authorization system, which reference number can be used to identify the transaction in the event of an audit or refund. The use of multiple hubs provides flexibility and scalability. The hubs 16, 18, 20 provide an authorization service to specific service providers 24 and an evaluation and information service to clients 22. The central VPS registry 12 registers the services and keeps track of which hub 16, 18, 20 belongs to which client 22 or service provider 24.

The service provider 24 requests authorization from its hub 16 to initiate a transaction. The client 22 requests authorization from the service provider 24's hub 16 to initiate a payment. The hub that has both authorizations (the service provider 24's hub or the client 22's hub) acts as an authorized processor to authorize the transaction and/or payment that a payment system 32 (card issuer, bank, telephone company, electricity provider, etc.) is processing from the client 22's account to the service provider 24's account. The VPS payment authorization system 10 may authorize the transaction without a direct payment obligation.

This two-key transaction method, in which payment information and client information are evaluated, provides greater security than traditional methods, thanks to the fact that the two parties provide information independently of each other before the transaction is executed.

In Figure 4, the process of Figure 3 is illustrated in more detail. In step 56, the service provider 24 generates and sends a transaction authorization request to the associated hub 16, 18, 20 authorization processor 52, which request may be preceded by an initiation by a client 22 to the service provider 24 in step 54. The authorization processor 52 creates a record of the requested transaction in step 58, including the data and information of the service provider 24 in the record, after checking whether the service provider 24 is a registered member of the VPS 10 payment authorization system. The data of the registered service provider 24 is retrieved by the authorization processor 52 in step 60 during the preparation of the payment process and sends a message back to the service provider 24, including a transaction (Tx) identification code or secret key. The client 22 receives the transaction ID, but does not receive its encryption key. With the transaction ID, the client 22 identifies the transaction in question in the authorization processor 52, in a step 64. The VPS payment authorization system 10 generates a transaction ID and a check value or encryption key and sends it to the service provider 24, which transaction ID the client 22 can use to identify the transaction, however, the service provider 24 does not inform the client 22 of the encryption key that the VPS payment authorization system 10 uses in its connection with the service provider 24. This reduces the possibility of fraud by the client 22.

For example, the client 22 selects goods or services from the offer of a service provider 24 on the Internet using the client computer 48. The service provider 24 redirects the search engine of the client 22 to the payment page of its website in step 62, where the client 22 accepts the price and orders the goods or services, where the transaction identifier is one of the parameters that the client 22 receives. The service provider 24 may also provide a graphical user interface (GUI) on the website where the search engine can find plug-ins and/or scripts for support, for example, Active Server Pages and/or Commerce Server Order Processing Pipeline for INTEL and MICROSOFT WINDOWS or Perl scripts for UNIX/Apache environments.

The client 22 may also order goods or services from a payphone service provider 24 using, for example, a mobile phone capable terminal 50, using voice menus and a keyboard. In this case, in step 62, the service provider 24 redirects the client 22 to a payment sector, or the authorization processor 52 calls the client 22 back to finalize the transaction.

After this, the client 22 contacts the authorization processor 52 in a step 64 to authorize and/or select a payment, specifies the payment system 32 of its choice, whereupon the authorization processor 52 verifies the authenticity of the client 22 in a step 66, registers the client 22's data in a step 68, and, if necessary, contacts another hub to request the execution of the service, and then authorizes the payment.

After entering the service provider data in step 64 and the client data in step 68, the authorization processor 52 sends an authorization message in step 70 to the designated payment system 32, which authorizes the transaction in step 72 and, depending on the selected payment method, executes the electronic payment to the account of the service provider 24. After this, the authorization processor 52 notifies the service provider 24 in step 74 that the payment has been made and that the order has been completed, after which the service provider 24 provides the service ordered by the client 22.

Figure 5 shows a flow chart of the steps of the authorization processor 52, starting at step 58 in Figure 4. In the process, the authorization processor 52 changes the status of the requesting service provider 24 to the status of the service provider designated for the transaction 24, creates a temporary transaction record, waits for the data of the client 22 at step 68, verifies the data, authorizes the payment system (PS) to make the payment (step 72), and then notifies the client 22 and service provider 24 of the results of the steps.

Figure 6 illustrates a variation of the process of Figure 5, in which the states of the connection established between the service hub 24 and the service provider 24 are indicated until the transaction initiated by the client 22 is completed. If the client 22's identifier is not acceptable, the service provider 24 is notified of the reason for this, and thus the transaction authorization requested in step 56 is denied by the authorization processor 52. Otherwise, the service provider 24 fulfills the order requested by the client 22, in the regular identification and authorization process. The fulfillment of various conditions is also included in the process, such as. handling of refunds.

Figure 7 details the part of the process of Figure 5 in which the identification of the client applying or an attempt to do so is made. The authorization processor 52 waits for the client 22 to log in. Each client 22 has previously registered itself in the VPS 10 payment authorization system, so that the data of the client 22 applying can be compared with the identification data previously stored about it. If the comparison is successful, the authorization processor 52 enters the identification data of the client 22 into the transaction record in step 68.

Figure 8 details the part of the process of Figure 5 in which the payment method is selected. This part includes steps 64, 66 and 70 of Figure 4, where the client 22 requests authorization of the payment instruction from the authorization processor 52 and wishes to designate a payment system from the options offered by the authorization processor 52. The payment method may be a normal payment, which means that the full amount of the service price is paid by the client 22 without delay, or it may be a payment collecting small payment obligations (Micropay), where the provision of the service is separated from the payment in time. This is used for payments of amounts where the transaction cost of the money transfer is comparable to the amount of the items to be paid. In such cases, the payables are collected until a certain amount is reached or over a certain period, and several items are called and paid at once, in advance (as a deposit) or later.

In the event that the registered data of the client 22 is not stored in the hub of the authorized authorization processor 52, but in another hub, the transaction processes are partially run on both hubs, in a mirrored manner, for the sake of flexibility and traceability of the entire transaction process.

Figure 9 details the part of the process in which the authorization processor 52 requests the details of the client 22's request. This sub-process includes whether the client 22 has the funds required for the payment in its account, whether a Micropayment payment method is requested, and if so, whether the conditions for this are met (deposit amount?).

In the client identification process, the VPS registry 12 identifies the hub that contains the client's registered data.

As previously described, the service provider 24 receives the payment amount through the VPS 10 payment authorization system. The client 22 may be a natural or legal person or body that has registered with the VPS 10 payment authorization system in order to electronically process payments during customer transactions using its reliable system. A wide variety of payment systems 32 may be used in the VPS 10 payment authorization system. The payment system 32 may be a credit/debit card issuer and account manager, a bank account, or access to a specific deposit, fund, etc. The method of receiving payment is usually a payment to a bank account or a payment to the service provider. The operator of the payment system 32 is also a client in the VPS 10 payment authorization system.

An authorized client is one who is authorized by the owner to use the VPS 10 payment authorization system. A client account is made up of entries kept in the VPS ledger of the 22 client VPS 10 payment authorization system. A hub operator is an organization operating the VPS 16, 18, 20 hubs, which is a quasi-independent supplier of the VPS 10 payment authorization system. A payment processing service is an organization responsible for the actual transfers, a card issuer or a financial institution.

The owner (owner) of a payment system can be considered the user of a payment method, i.e. the bank card owned by the client, who is responsible for the use of the payment method.

The user of the VPS 10 payment authorization system can be an individual bank card holder, or a senior officer or chief accountant of a company or institution with a corporate bank card account, who approves the invoices.

In the Autopay payment method, the user provides the joint cardholder name and/or their own PIN code as card user data, but only once in a relationship, even if they make multiple orders and payments.

Using the VPS 10 payment authorization system, the 22 client can make payments to service providers 24 over the Internet or other 26 electronic networks. No bank card or payment system identification data is ever transmitted over the Internet without encryption; only the data that is relevant to the transfer and modifies the balance of bank accounts is transmitted over the network (in coded form). This data can also be sent as a fax or other secure data transmission instead of the Internet. The applicable payment method can also be registered with banks or other account management bodies, so that even less data needs to be transferred during the execution of a transaction.

The service provider 24 participating in the transaction as a party may not learn the details of the client's bank card or other payment system, unless the service provider itself operates the payment system, such as a telephone service provider that bills for telephone service. Payments initiated by the client 22 usually arrive directly at the service provider 24, but the paying client may remain anonymous to the service provider. If necessary, the ordering client may allow the system to provide only his name and address, in which case the service provider may retrieve these details from the database. In an alternative solution, the service provider 24 may provide the name, address and/or other details of his client together with the payment request, for which the service provider must know that the client is new to the system.

In the VPS 10 payment authorization system, it is possible to process small-value payments in a collected manner, using the so-called Micropay payment method. There are two versions of the Micropay payment method, in the first version the service provider 24 bears the burden and risk of collection, and in the second version the client 22 bears the burden and risk of collection. In the second version the client 22 deposits a specific amount and authorizes the service provider 24 to automatically debit the deposit. An important feature of the application of the Micropay payment method in the VPS 10 payment authorization system is that payments can be made in more than one currency, the conversion between currencies is automatic and is performed by the authorizing processor 52.

If the client 22 agrees, the so-called Autopay payment method can also be used in the VPS 10 payment authorization system, in which, within the same connection between the client and the service provider, after an initial identification, the identification process becomes transparent, i.e. a series of transactions can be carried out after a single identification process, in the opened connection.

The holder of a payment system 32, for example a corporate bank card holder, can grant another client 22 the right to use the payment system. The holder of the payment system 32 sets limits on the use of the client 22 who has acquired the right and has visibility into all transactions. However, the client 22 who has acquired the right can only see the details of his own transaction.

Service providers, companies, financial institutions can pre-load a client's payment system, which can result in a series of dormant accounts. Dormant accounts can be activated by entering the 22 client's personal identification PIN code. Pre-loaded accounts can be assigned to an existing VPS account or can have new account numbers.

The service providers 24 occasionally make refunds in the VPS 10 payment authorization system, and both the clients 22 and the service providers 24 can initiate payments for other clients 22. The VPS 10 payment authorization system is therefore flexible and can be easily adapted to different commercial and payment methods.

The service providers 24 may provide account management services to specific clients or a group of clients. In such account systems, a financial settlement service requests payment when the account exceeds a specified limit in the Micropay payment system, possibly in the form of an invoice issued to the client 22. In the latter case, the VPS 10 payment authorization system acts as a delegated account management system.

Statements to be sent to clients 22 and service providers 24 may be available online. Other reports, such as reports from banks 30, payment system agents 32 and account managers of organizations, may also be available.

The VPS 10 payment authorization system is highly secure, both physically and procedurally, with respect to access to information. The 22 clients, payment system owners and/or 24 service providers may specify a minimum level of security. For example, the VPS 10 payment authorization system may require certain 24 service providers and/or clients to provide additional identifiers in addition to the PIN identifier, typically for transactions above a specified threshold.

The VPS 10 payment authorization system also allows data to be output from the system to other accounting or bookkeeping systems. The invoice information can include the number of normal transactions, the payment method used, and Micropay turnover, allowing the external accounting system to issue invoices to the 24 service providers for the use of the VPS 10 payment authorization system.

The VPS 10 payment authorization system is an open system that is suitable for a wide range of needs, and is therefore also suitable for Internet-based payments and electronic commerce. The structure of the VPS 10 payment authorization system allows for the integration of new and new options. The VPS 10 payment authorization system and its associated 32 payment systems are suitable for the management of credit/debit bank cards, direct debit, store customer accounts, type accounts and other money transfer instruments and methods.

The VPS 10 payment authorization system performs client authentication, such as a simple username and password, over a secure web connection. The VPS 10 payment authorization system may also perform client authentication for transaction authorization using other methods, such as smart cards, digital certificates and signatures, and/or biophysical/biometric identification methods. The 32 payment systems and/or client data may be stored at other organizations outside the VPS 10 payment authorization system.

Features of the intermediary payment authorization system:

The VPS 10 payment authorization system is a value-adding, transaction authorization and payment processing system that is convenient to use and secure to an unprecedented degree. The VPS 10 payment authorization system is an authorized third party in the transaction, which third party contains the detailed data of 24 service providers, 22 clients and 32 payment systems registered in the system, including banks and lenders, necessary for identification and payment processing, and in a secure environment, bilateral, selective payment processing.

It establishes pipelines with these, thus mediating between the 22 clients, 24 service providers and 32 payment systems, without their sensitive data becoming known to the other party. The VPS 10 payment authorization system also sends real-time, objective reports to the parties involved (clients, service providers, banks, etc.) during each transaction.

When a 22 client opens a VPS account via the Internet, he enters his credit card or other payment system data, bank account data through a secure interface (using an encrypted web site or other data entry device) into the VPS 10 payment authorization system. The information is protected on the web server of the VPS 10 payment authorization system, by SSL encryption or otherwise, while being transferred to a back-end storage, where it is stored in encrypted form, separate from the web server, off-line. Registration of payment systems can also be done off-line, or directly by the operator or user of the payment system, such as a card issuer, a credit line provider (e.g., a telephone company, a consumer card issuer, a corporate credit issuer, etc.). VPS account holders, as clients, can register as many payment systems as they wish to use, assigned to a virtual account that has a unique ID.

Once an account is opened, the VPS account holder is never asked to provide their card details or other sensitive information over the Internet or other public networks, instead the VPS account holder identifies themselves with their unique PIN number and username, and possibly an additional security code. The parties involved in the transaction identify themselves in a unique, two-key system: the merchant (24 service provider) provides identification codes, transaction identifier and amount to be paid, the client 22 identifies themselves, selects a payment service to be used in the transaction, and expresses their agreement with the terms of the transaction and the execution of the payment. These two information streams, which are transmitted independently to the VPS payment authorization system 10, are combined by the authorization processor 52 and passed on in step 72, authorizing execution over a fast telecommunications connection to the payment system selected by the merchant, such as a bank.

Information about the successful or unsuccessful completion of the transaction is returned to the authorization processor 52, where the information is recorded, and then in step 74 the information is received by both the VPS web server and the merchant's server, so both the client and the merchant are quickly informed of the result (within 3-7 seconds).

Each transaction is assigned an identification number by the service provider 24 and the VPS 10 payment authorization system. This allows the transaction to be identified, verified, and payments and refunds to be assigned. The Autopay payment method allows the client 22 to identify himself only once in his relationship with the service provider 24, for example on the service provider's website 24.

Very small payments, i.e. payments below a limit set by the service provider (micropayments) can also be made in a collected manner. This service is provided by the VPS 10 payment authorization system to the 24 service providers and the 22 clients. In the case of collected payments (Micropayment), the order fulfillment and the payment are separated in time. The payables related to the small purchases of a given 22 client are accumulated on one account during a given calendar period or up to a given amount limit, when they are settled automatically by the VPS 10 payment authorization system. The merchant using the VPS 10 payment authorization system can choose between two options:

In one case, the service provider (merchant) 24 itself keeps track of the debt of the regular customer 22, and when it reaches the limit set by the merchant, it bills it in one amount, and the customer 22 settles this bill. This allows the customer 22 to make sporadic purchases.

ΛΟ !>

for small amounts (e.g. downloading small pieces of information or program files, data research).

In the other case, the service provider 24 uses the Micropayment service of the VPS 10 payment authorization system, in which the client 22 can make purchases from any service provider registered in the system against the debit of his/her collective account maintained in the λ/PS 10 payment authorization system. In the latter case, when the client 22 first initiates a small-value purchase from any service provider 24, the VPS 10 payment authorization system requests a deposit (e.g., USD 15) to the client's collective account, and the service provider 24 receives the consideration for the service after deducting the fee for using the service and the fees related to card use. The VPS 10 payment authorization system requests the client 22 to top up the collective account when the deposit is exhausted. The account can be topped up using a bank card or using another authorized payment system. The pool account is preferably maintained in one currency, for example USD, and the conversion between different currencies is performed by the authorization processor 52. The amount to be paid is converted to USD before being posted to the pool account, the original and converted value is displayed by the VPS 10 payment authorization system and approved by the client. The service provider 24 usually receives the amount due in USD, but it is also possible to make a payment in the currency of its choice.

The VPS 10 payment authorization system stores the data of bank cards, other payment systems and other persons on a secure database server 42. The database 42 is conveniently arranged in a hub 16, which hub also performs the function of the authorization processor 52. The database is an off-line system, i.e. it is not accessible on the interface of the clients 22 or service providers 24.

Each client 22 can register multiple cards and other payment systems in the VPS 10 payment authorization system, which forms a virtual wallet for them. These payment systems can be business or personal accounts, ,S .·* ,..... .

_M -ψ with monthly subsequent payment, direct debit accounts, etc. Such accounts of the account holder can be accessed after verification of identification, and if the account holder has registered the data required for access in advance, there is no need to provide detailed data on-line during a transaction. During the off-line information collection and registration, the VPS 10 payment authorization system has a way to verify the correctness of the data, so that it can later verify and identify the data received from a 22 client 24 service provider based on its own stored data, so that there is no need for the account holder to ask the client about their identity.

During the general initial operations of the VPS 10 payment authorization system, the account holder selects a unique combination of a username and alphanumeric password as a unique PIN identifier and provides it with security information to the VPS 10 payment authorization system. The VPS 10 payment authorization system then requests the PIN identifier for login upon each connection initiation. Additional security measures may also be specified as a condition for login or as a condition for performing certain actions (e.g., ID or account changes). Such additional security measures may include, for example, randomly asking questions. Such PIN identifiers may be hidden on displays, e.g., by displaying * characters instead of the characters. Prompt mechanisms may be used to assist individuals with short memories. Other methods of identification may also be used, and the account holder may limit the amount that can be withdrawn from the account.

The VPS 10 payment authorization system periodically creates an audit trail of events for users and service providers, which allows for retrospective verification of events (including Micropayment events).

Other methods of identification and evaluation that have already been proven by banks, other financial institutions and large users can also be used.

The time resolution of the audit logs sent online to 22 clients and 24 service providers can be accurate to the second. Based on this, the account turnover and purchase transactions can be checked online by the account holder, the audit log can be printed. Thus, the account holder can detect security breaches, exceeding limits, etc., and can check all financial transactions, the participants of which can be different banks, bank cards and websites.

A payment system holder, for example a registered holder of a bank card, can grant another account holder the right to use the payment system within the VPS 10 payment authorization system. The authorized user can use this by entering the ID registered to his own account, debiting the bank account of the original authorized user. The bank account holder can specify limits as restrictions on the authorization or open a sub-account for him. However, an absolute limit is only the depletion of the bank account. Only the original authorized user can change the parameter instructions and restrictions related to the VPS account or sub-account.

All conversions between currencies are carried out according to banking regulations, so the holder of the payment system can make transfers in the currency of his choice, preferably in the currency of the country where the VPS account is operated, paying the conversion fees incurred, as well as the conversion fee to the 24 service provider in the event of payments in another currency. This automation results in a high level of security of electronic financial transactions and the worldwide usability of conversion options.

If the VPS accounting body 12 that oversees the execution detects three errors in a transaction, it freezes the accounting system, and the VPS payment authorization system 10 attaches a security error signal to each event. On the other hand, the VPS accounting body 12 also freezes the accounting system if it detects six security errors occurring in different transactions within twenty-four hours.

The VPS 10 payment authorization system generally uses a username and password to identify the customer, and in some cases also asks random questions regarding third-party data, as is common and proven in telephone banking services as a security measure. The VPS 10 payment authorization system can, however, be designed to be suitable for the application and acceptance of other identification features. Such features include, for example, digital certificates and signatures, voice recognition, iris recognition, fingerprint recognition and other means suitable for identifying the user. The user can also prove his/her authorization with a smart card presented to the authentication processor 52. The use of smart cards is also advantageous in the VPS 10 payment authorization system from other aspects, it allows direct connection with the card account, allows direct settlement of small-amount payments without a collective account, on-line query of the audit log, etc.

The VPS 10 payment authorization system is beneficial for 24 service providers and merchants because it is a cost-effective and secure way to collect payments. Payments to 24 service providers and merchants can be made directly to the merchant's bank account. The VPS 10 payment authorization system helps to retain customers and build brand loyalty by increasing the trust and sense of security of clients in conducting electronic transactions. The VPS 10 payment authorization system does not limit the use of different possible payment methods or the management of service provider discounts and temporary price reductions. Since the VPS 10 payment authorization system supports both cash payments and purchases on credit, it is also suitable for managing credit lines and credit accounts. The VPS 10 payment authorization system can increase the effectiveness of a merchant's promotional activities by managing various group or regular customer discounts, and the fact that, in addition to paying with cash, the possibility of purchasing on credit is also provided is an incentive for clients. With the help of the VPS 10 payment authorization system, the merchant can learn more about the purchasing habits of its customers, thus performing smarter, more effective marketing activities without having to ask questions from its customers.

To use the VPS 10 payment authorization system, the merchant establishes a connection with the VPS 10 payment authorization system, using a simple or complex authorization and configuration software that is suitable for cooperation with most standard platforms and web servers. The merchant uses a set-up installation and configuration that is suitable for his platform and commercial server. The VPS 10 payment authorization system can be integrated into the “MICROSOFT COMMERCE SERVER SUITE” software or other software suitable for commercial use. The VPS 10 payment authorization system is very flexible, able to adapt to the different requirements of different merchants and can open up new areas in e-commerce and web commerce, so the VPS 10 payment authorization system is suitable and open for cooperation with clients in further development according to the requirements of clients, in finding new solutions.

A merchant participating in the VPS 10 payment authorization system as an acceptor of payments and using a credit or debit card receives a merchant number from his bank authorizing electronic commerce (E-commerce). The VPS 10 payment authorization system can assign terminal ID (TID) identifiers to the merchant's terminals, which TID identifiers are selected from a set of numbers reserved by the bank for this purpose. With this in hand, the VPS 10 payment authorization system informs the bank, so that direct agreements can be made with the merchant.

The VPS 10 payment authorization system fits very well into the usual banking procedures and software, where real-time validation is directly integrated into the merchant's transaction process, allowing for its full automation. Thus, the VPS 10 payment authorization system can be installed at the merchant's premises and easily used by clients. The merchant can accept credit or debit card payments on his own merchant account. The VPS 10 payment authorization system bills the merchant for the service fee used, which can be a monthly flat rate or a fee charged per transaction. The merchant can choose, among others, micropayment by transfer, directly in the form of transfers to the merchant account, or by using the Micropayment service of the VPS 10 payment authorization system. In the latter case, the merchant receives a single monthly payment for the net value of the small-value services provided to a client during the month, i.e. the Micropayment service fee is deducted from this.

Merchants are instantly notified of the payment of an order, this notification is part of their transaction processes, allowing for automation and security checks of the transaction process. The integration into the existing systems of merchants and 24 service providers in the VPS 10 payment authorization system also allows for the integration of ordering, billing and other application software into the system.

The VPS 10 payment authorization system uses a distributed hub layout to scale to meet demand and provide optimal performance in a global, unified system. Individual or clustered, regional 16, 18, 20 hubs provide fast, globally reliable access and sufficient backup capacity. The 16, 18, 20 hubs can be maintained by the VPS 10 payment authorization system itself, or by intervening joint ventures such as banks, banking groups, clearing banks and other financial institutions. Merchants and account management institutions also have their own hubs (Figure 1), but the VPS 10 payment authorization system accounts can be used globally. Standard transactions are authorized and processed through the connection between the merchant's hub and the merchant's bank, while micropayments are processed through the hub of the institution holding the micro-account.

Direct payments between nations take place in a global banking system, where a transfer is made from a bank in one currency zone to an account held in a bank in another currency zone. Merchants, traders, and other service providers may have their designated bank accounts held in one or a few designated currencies, but clients may make payments in any currency of their choice. Merchants and other service providers are essentially informed immediately when their expected funds arrive at the bank, and the funds are automatically credited to their accounts within a specified number of business days, which number of days is set by the bank's policy, for example, three business days.

The VPS 10 payment authorization system supports global functional cooperation between 24 service providers and 22 clients, global use of hubs, payments by credit card or corporate bank card or other bank payment instruments, and currency conversion. The VPS 10 payment authorization system is therefore an automatically managed electronic payment transaction processing system that can inform the parties in real time about the transaction steps and their data, in the form of an audit trail, ensures the traceability of transaction routes, and supports currency conversion and payment in the currency of choice. The VPS 10 payment authorization system provides these services by integrating into the database server of the 24 service providers. The VPS 10 payment authorization system is a self-regulatory system that requires a bank to approve the membership of a merchant or other 24 service provider accepting payments by issuing a merchant number. Payment systems are securely registered with the VPS 10 payment authorization system as trusted third parties, which can be accessed using personal or transaction identification reference numbers.

The distributed payment authorization system provided by the VPS 10 payment authorization system provides a secure and simple method for processing international, direct payments. The VPS 10 payment authorization system also integrates directly into the international payment system, through some 30 banks, into the international banking system, and provides the possibility of real-time authorizations in the processing of payments to the merchant's account. In addition to this flexibility and speed, the VPS 10 payment authorization system also ensures that the 24 service provider does not have access to specific, detailed data of the payment systems, so the 24 service provider cannot manipulate them or misuse the information. The account of the 24 service providers, identified by their merchant number, is managed by the VPS 10 payment authorization system.

It is also possible for card systems and other 32 payment systems to register themselves in the VPS 10 payment authorization system for use exclusively in the VPS 10 payment authorization system, in which case the payment authorization system can be completely secure and closed. Although the VPS 10 payment authorization system can operate using the Internet, this is not a prerequisite for the use of the VPS 10 payment authorization system, because in the VPS 10 payment authorization system the key processes take place off-line. Larger clients with large cash flows can use a leased line to communicate with the VPS 10 payment authorization system. In the case of closed loop and direct payment, no sensitive information is sent to the public 26 electronic network (Internet), so there is no need to use high-level security encryption and digital certificates, thus significantly simplifying and making the use of the VPS 10 payment authorization system low-cost. Under these conditions, the VPS 10 payment authorization system is an exceptionally simple and secure system for conducting commercial payments and currency conversions.

In the VPS 10 payment authorization system, a transaction ID connects the participants of a global transaction - service provider and clients - and the system of hubs provides fast service and control (back-up). Pre-registered payment instruments, bank cards can be used for payment, so there is no need to enter or transfer security-sensitive personal and card identification data when making a payment. Card issuers can also open a dormant VPS account managed by the VPS 10 payment authorization system for the cardholder, where card data, names, addresses, temporary PIN codes, temporary usernames are registered, per account. Part of the data can be generated by the VPS 10 payment authorization system for this purpose. Cardholders receive the temporary username and ID (password) in a security process that is also common in other systems.

If the client already has a temporary username and ID, they can use them to log in to the VPS 10 payment authorization system via a secure VPS interface, activate their account, choose a new username and PIN code, extra ID verification, set a withdrawal limit, and possibly register other partial data, other payment systems, and personal data. The client can group several bank cards to one account, which can then be accessed with a common security check.

Since the basic information for a VPS account comes directly from the card issuer, such information includes a card account address, which allows the VPS 10 payment authorization system to perform accurate address verification and authorize the transaction. Address verification also allows the merchant to verify that the shipping address provided by the client on the order matches the cardholder's card account address.

The personal identification system used by the VPS 10 payment authorization system does not require any special hardware or software on the client side. The personal and transfer identification data entered by the client are not transmitted in a web browser, nor is an electronic wallet, JAVA application software or bookmark required to operate the VPS 10 payment authorization system. The VPS 10 payment authorization system can therefore be operated via any communication device, regardless of the data transmission method.

Since it is not necessary to disclose client information during the transaction, secure sub-accounts can be opened, so e.g. a father can authorize his children to use the bank card up to a fixed amount limit, a company can authorize a department or employee to use the company bank card up to a certain amount limit and within certain other parameters, for example, specific types of goods, purchases from specific service providers. A24 service provider can authorize a client company to make purchases on a credit account, which credit account can also be divided into sub-accounts. The account manager can monitor and verify transactions using his own payment system, using an online, VPS audit log. Users never have access to the detailed data of the payment system (card number used, VPS ID identifier) used by the account holder. Clients may also have a registered payment system that they do not own but are authorized to use, and that is associated with their virtual wallet and other payment systems. Using the AVPS virtual wallet, the client can pay for purchased services and goods and control their spending using their own VPS ID. This highly flexible VPS 10 payment authorization system can be the basis for store card accounts that the client recharges monthly. In such a case, the cardholder grants the service provider permission to use the payment system, which may be a credit card account, to charge fees for services they regularly use.

HOW THE INTERMEDIATE PAYMENT AUTHORIZATION SYSTEM WORKS:

The VPS 10 payment authorization system typically uses the following client data: name, address and contact details, email address, security information such as username and PIN, security prompts and PIN codes allowing access to collective accounts, confirmation codes, e.g. a code with which the client informs the potential transferor and confirms that the keyed-in ID code is correct, applicable payment systems, such as bank card details, their limits, a limit on the number of payment systems applicable at a user interface (UI) level, group name such as company name or family name, account type such as corporate or private, status information such as privileged user, account blocked, etc., client preferences such as anonymous, Autopay enabled, etc. credit limit in a payment system, provider-specific account information, and a minimum security level.

For example, a client connects to the VPS 10 payment authorization system when it is offered to him as a payment method during an electronic purchase. Group registration of clients can be arranged by the group manager. Within a group, some payment systems can be coded, allowing access only to authorized clients. Clients or groups of clients can also be added as a package to those registered in the system, and these clients are activated later, for example, upon first use, by using an authorization PIN entered separately in the system.

Clients can make changes to their VPS account at any time, changing their username, PIN, security details, personal credit limits, payment system type and identifier. Authorized clients can change their own credit limit within a maximum set by the account owner, or change the applied security level by choosing a higher minimum selected by the account owner. Clients can also query various information regarding account transactions and their use of the VPS 10 payment authorization system. If an account is deleted or a username is changed, the VPS 10 payment authorization system locks the discontinued items for a specified period of time, e.g. six months, before anyone else can use them again.

The 12 VPS bookkeeping bodies manage the VPS accounts, open new VPS accounts, close VPS accounts, and change the characteristics associated with the accounts based on client instructions or other considerations.

The process of loading invoices is customizable, the data format of the invoice information may differ from one payment system to another. Invoices may be pre-arranged in a table, and the table and the status of the invoices are communicated to the respective account holder, for example by letter. This letter may contain an access code that allows the client to open a new VPS account using a selected 32 payment system, or to associate a new 32 payment system with an existing VPS account.

The VPS 10 payment authorization system records and uses the following data from the 24 service providers: name, address, security username, security PIN, payment system authorization, bank information such as TID, assortment code, bank account number where incoming funds are deposited, account, client and transaction details, service provider-specific Micropay or pool accounts, security and payment preferences, commission details, contacts, Internet Protocol (IP) Domain, and store category. Each of the 24 service providers is operationally linked to at least one hub 16, 18, 20, which hub supports the service provider and manages its transactions, client transaction initiations. The service provider 24 has a contractual relationship with the VPS 10 payment authorization system, granting a bank authorization to process TID payments from third parties, in a payment system, direct payment, debit or credit card payment system that allows for withdrawal of funds. These payment systems are accounts in which payment is not made immediately and the risk associated with the payment is borne by the service provider. These payment systems, such as deferred payment accounts, for example a set of normal billing accounts, for example for blue chips, or Micropay accounts, which are topped up when the accumulated debt exceeds a certain level or has exceeded a certain period of time, for example, they are topped up monthly.

At least initially, the provider's invoice may be prepared by the VPS 10 payment authorization system staff or agent, although the initial data will in any case be provided by the provider and provided by the provider via the Internet or other means. The payment system suitable for receiving payments is also designated and specified by the provider. A bank agreement is required for the provider to have a merchant DD and a TID or other payment system. The provider and client entering the VPS 10 payment authorization system will receive an additional installation kit with which to perform acceptance tests to verify the correct operation of the VPS 10 payment authorization system.

There are data and settings that can be changed directly by service providers, and there are sensitive data that affect the functionality of the VPS 10 payment authorization system, which can only be changed by VPS 10 payment authorization system personnel, although according to the service provider's instructions. Data that can be changed directly include, for example, name, address, payment preferences, client-based collective accounts, etc. Only VPS 10 payment authorization system personnel can change, e.g. bank information and any data that may result in a transfer to the wrong account or other errors or disruptions in the operation of the system.

There are functions implemented in connection with each service provider, such as changing and viewing the merchant name and address, personal security information, payment authorization system, bank and/or TID information, preferences, and informing the client about a collective account.

One form of using the VPS 10 payment authorization system is the use of the Micropayment collection account payment system, in which money is withdrawn from the client's payment system only when the debt accumulated from small transactions on the VPS collection account has reached a certain amount. For example, the client has purchased five or six items in a few weeks before the VPS 10 payment authorization system withdraws the collected consideration from his bank account because it has exceeded the USD 20 threshold. Another form of using the VPS 10 payment authorization system is the use of a normal collection account in the relationship between a service provider and a potentially large-buying client. In this case, the VPS 10 payment authorization system mediates the transaction, provides the service provider with account information, but the service provider issues the invoice itself, directly to the client. The service provider sets a credit limit, the payment system can be considered owned by the service provider, who provides it to clients, for example through an authorized agency.

The service provider also has the option of making payments on behalf of the client. Such cases include refunds as a reward for the client's loyalty, payment of prizes, and payment of promotional discounts. The refund can be linked to a previous payment transaction, in which case the service provider does not need to know the detailed data of its client (personal identifiers, identifiers required for card use, etc.), they are known in the VPS 10 payment authorization system and can be retrieved within the VPS 10 payment authorization system based on the transaction identification code. If the bank card is no longer valid, the refund

The amount to be transferred is transferred to a holding account, and the client is notified of this by letter or email. The client can then specify the payment system to which the money should go, either on the service provider's interface or on another interface of the VPS 10 payment authorization system.

If the holder of a bank card or other payment system is no longer registered in the VPS 10 payment authorization system 12 accessible to the VPS accounting body, the service provider is notified by the system, and the VPS 10 payment authorization system notifies the client by letter, fax, or e-mail that the amount will be received directly from the service provider, but does not disclose the client's data to the service provider.

In the case of daily settlement, the authorization processor 52 has authorized the transaction, but does not execute the transfer immediately, but in daily batches. Delayed fulfillment is when the payment is authorized, but the ordered goods are not yet ready for delivery. The payment is made only after the service provider has indicated to the VPS 10 payment authorization system that the ordered goods are ready for delivery. The situation is more complicated if the payment authorization has become invalid in the meantime because its time gate has closed, in which case the payment authorization must be updated (confirmed). In the case of monthly settlement, the VPS 10 payment authorization system provides the service provider with information about the outstanding items, and the service provider issues an invoice to the client based on this, comparing it with its own records.

In the case of a Micropay payment arrangement, the debt arising from transactions accumulates until it exceeds a threshold. When this occurs, the authorization/settlement tool of the VPS 10 payment authorization system attempts to withdraw the missing amount from the VPS account. These transactions are carried out either on a general Micropay account or on another, provider-specific, holding account of the client, the risk being borne by the provider.

When an authorized payment is initiated, the service provider sends the following information directly to the payment system to be included in the transaction: transaction code, transaction amount, transaction type or preferences, delayed, instant or Micropay payment method, additional security information such as zip code or other confirmation information. The transaction path of the money may pass through multiple payment systems or be split between multiple payment systems of the client, so for example, the client may pay 500 USD with one bank card and another 400 USD with another bank card in a transaction worth 900 USD.

If the client has a preferred payment system, this preferred payment system will be automatically selected, unless the service provider does not accept this payment system or, in the case of the Micropay payment system, if it is not supported by the preferred payment system.

At the end of the transaction, whether successful or unsuccessful, the client's connection is returned to the starting point, for example, to the web page where the transaction was initiated.

The VPS 10 payment authorization system may also support the Autopay payment method. Autopay is a procedure in which the client uses only his personal identifier, VPS ID, to identify himself in a transaction relationship. After the first payment, the client may make a series of additional data transfers, and during further transactions in the relationship, the data transfers confirm the client's identity. This data may be search-oriented bookmarks (cookies), which are commonly used in Internet-based e-commerce, which do not contain information that needs to be protected for security reasons, and which have a limited lifespan. In an Autopay relationship, if the breaks between individual transactions are too long, the connection may be interrupted.

The VPS 10 payment authorization system can generate various reports for various purposes. These are described in Table 1. Typically, the reports contain provider and transaction codes and amounts. The reports are generally a means for the client to identify themselves when the provider and the client conduct business.

Table 1

Report Description Security service providers report on all transactions of the service provider service provider/ report in a given period hub owner service providers report on all transactions of the service provider service provider/ account- in a provider-specific payment system hub owner/ report payment system holder (client) client every transaction of the client, every client/hub report payment system, (not transactions of other clients with the same payment system!) owner hub aggregating the transactions of the hub for a given hub owner/VPS summary period, to calculate service fees.

SECURITY OF THE INTERMEDIATE PAYMENT AUTHORIZATION SYSTEM:

The basis for the security of the client, the service provider and the transaction is that the data requiring secure transmission (user ID, PIN, amount, etc.) is transmitted in SSL 40-bit level encrypted form. The client only needs to transmit the protected data of bank cards and other payment systems to the VPS 10 payment authorization system once, and this can be done, for example, in SSL 40-bit level encrypted form. The client can use various means to transmit this data, such as fax or telephone.

The security of the Internet application in the VPS 10 payment authorization system is based on the fact that the data to be protected, once communicated, is stored by the VPS 10 payment authorization system and then verified by comparing the data and tracking all transactions carried out under an IP address. The VPS 10 payment authorization system compares the IP addresses of the service providers with their domain names. The IP addresses of the clients are stored in the VPS 10 payment authorization system in order to be able to track the process in the event of fraud. If the same client initiates two transactions at the same time, the client is notified by email, for example, that their data may have fallen into unauthorized hands.

Hubs have a multi-level, internal security system (Inter-hub). At the top, first level, a supervisor controls the access rights of operators, but the supervisor usually has no rights beyond this. At least two passwords are installed for different people, and a third person is assigned to handle emergencies who knows the two passwords. Details of the encryption methods are known to a technology leader (CTO) and possibly other delegates. Details of the encryption methods may also be securely stored with an external body. All source code supporting security is also password protected. The upper level of the security system is responsible for managing the basic security system of the VPS 10 payment authorization system.

The second level of the security system implements the security management of internal users of the VPS 10 payment authorization system. The authorizations of users of this level can only be changed by the top security people, users of this second level grant access to operators. Users of the second level create and examine audit logs, trace the transaction path if necessary. The audit log of a bank that calls for payment may contain the bank card details of a client.

The third level of the security system includes the users of the λ/PS 10 payment authorization system and the personnel operating the VPS 10 payment authorization system, who can access the accounts of clients and service providers, modify their detailed data, enter data received from clients and service providers by telex or other means into the system, and confirm transactions for clients and service providers with the appropriate identifiers. All security-sensitive data is transferred to a 42 database server, where it is stored under the highest degree of security.

The internal security system of the hubs allows the communication of hubs 18, 20 among themselves and with 12 VPS-directories, while maintaining the highest level of security available. The encryption capabilities of the operating system, such as the PPTP encryption cipher system, can be used. Mixing functions and other one-way functions can also be used to enhance the security of the encryption.

AUDIT LIST:

Audit logs are generated for transactions within a hub. If two hubs are involved in a transaction because the client is connected to a different hub than the provider, both hubs generate an audit log. The audit logs are typically 22 client data filtered out to avoid disclosure, but a bank that is withdrawing funds may include specific client data stored in the VPS 10 payment authorization system in the audit log, but only in connection with transactions of the authorized bank.

THE VPS REGISTRATION ORGANIZATION:

The VPS registry 12 keeps track of the IDs of registered users and prevents duplication when a new user registers. The VPS registry 12 provides the hubs 16, 18, 20 with a list of clients and their IDs, which is necessary for the management of transactions. Each step of the operations performed by the VPS registry 12 and/or the hubs 16, 18, 20 (from the transaction request to the confirmation of the execution) consists of a series of micro-transactions. Any system error results in the cancellation of the operation of the VPS registry 12, in an emergency the transaction can be manually identified and executed. For example, if an error occurs during the authorization phase, it can be shown from the details sent to the bank to be authorized which of these was accepted and where. It is also possible to identify individual acceptance or rejection messages that the system sent to a service provider in error.

For example, the Microsoft Message Queuing (MSMQ) system is suitable for communicating such operations between hubs 16,18, 20, which makes all states of each connection detectable. A typical example is eight transactions per second per node on a single ISDN channel, with a maximum density of 128 transactions/sec., on a 1 MB/s connection. This means 11 million transactions per day. At such a speed, the cost per MB is insignificant compared to the benefits of high-speed transaction processing.

MESSAGE FORMATS:

In a preferred embodiment, the VPS 10 payment authorization system uses the HTTP "POST" protocol to transmit service requests, receive service results, and enable interactive communication between the service provider and the client. In another possible embodiment, the DCOM message queue service can be used for this purpose, etc. The following describes the format of several exemplary messages and response messages that affect the core of the VPS 10 payment authorization system and pass through the interfaces of the VPS 10 payment authorization system. In an Internet-based embodiment, data can be sent in a URL-encoded (URL=Universal Resource Locator) manner as if it were sent with a GUI (Graphical User Intrface) icon or SUBMIT button. The authorization transaction message can be a simple, intra-hub message, while other messages such as CheckLimitsAndGetPSDetails, CheckLimitsAndAutorizeMicropay, BulkNotification and TransitionAbandoned can be interhub or, if the client and provider are on the same hub, intra-hub messages.

The AuthorizeTransaction message is a packet sent by an authorization server 34, the request packet of which is sent with the following content:

Name Type Description size short package size (including this word!) version short package-version format, allowing transparent software updates. service provider long identifies the service provider, only needed for TxLog. client hub short hub based on client's residence client ID long client identification ID OurTxCode GUID VendorTx 20 characters ReceiptSystem Int TxType short transaction type, payment, refund, authorization start date/time transaction initiation time (log) Card No. 4 characters bank card number Expiry 4 characters MMYY (month/year) start 4 characters MMYY (month/year) emission 4 characters Amount currency

source ID of the machine that initiated the long request. (In IP version, for holding a socket, not for writing a response!)

The contents of a response message packet are as follows:

Name Type Description

size short package size version short package version format. ResultCode short transaction result (success, failure, error) OurTxCode GUID OurAuthCode long unique ID if the transaction was authorized ResultCode short result representing code ResultDetail 20 characters text (authorization code...) Time Stamp date/time date of authorization

The CheckLimitsAndGetPsDetails message is sent by the service provider hub to the client hub to obtain appropriate payment system (PS) information. The client hub checks whether the transaction would exceed the limits of the account and the payment system by sending the ServicePaymentSystemlnfoRequests message and either returns an error message or sends information to the payment system.

The content of the CheckLimitsAndGetPsDetails message packet is as follows:

Name type description size short package size (including this word!) version short package-version format, allowing transparent software updates. TxType short payment, refund, Micropay... VendorHub short hub by service provider location Vendor long identifies the service provider, only for TxLog ClientHub short client-based hub

OurTxCode GUID

VendorTxCode 20 character vendor transaction code

TransactionStartTime date/time the start time of the transaction

PaymentSystem long payment system that the service provider wants to access Previous PS long previous payment system, retry Amount money Currency 3 characters OriginalAmount money OriginalCurrency 3 characters Return IP IP service price requested currency service price in original currency original currency initiating machine identifier. Required for asynchronous operations AddressNo long address identification Index short first or multiple identification attempt indicator

The content of the response message packet is as follows:

name type size short description pack size (including this word!) version short OurTxCode GUID package version format ResponseCode short bounds exceeded, invalid system, invalid client, has PS details, has address

PaymentSystemDetails 100 characters (variable, can be empty) PaymentSystemID long payment system ID according to request Addressinfo ... characters

The CheckLimitsAndAuthorizeMicroPay message is sent by the provider hub to the client hub to obtain authorization for the Micropayment payment system application. The response can be authorization or denial.

The contents of the application package are as follows:

name type description size short package size (including this word!) version short package version format, software transparent allows you to update. VendorHub short hub by service provider location Vendor long identifies the service provider ClientHub short client-based hub ClientID long identifies client OurTxCode GUID VendorTxCode 20 characters service provider transaction code TransactionStartTime date/time the time the transaction started Payment System long payer that the service provider wants to access system Amount money service price Currency 3 characters currency on request OriginalAmount money service price in original currency OriginalCurrency 3 characters original currency ReturnQueue internal identifies the initiating machine. (the name of the returned stream is based on this) Address No. long Address identifier in case of irregular event Index short first or multiple authorization attempt indicator The response message packet contains the following: name type description size short package size (including this word!) version short package version format, software transparent

allows updating.

OurTxCode GUID ResponseCode short bounds exceeded, invalid system, invalid client, OK, no authorization OurAuthCode short when the hub authorizes something, it assigns it a unique identifier. The service provider's hub has its own

number if needed (and this is another hub), but this can be inserted into the OurAuthCodes table.

The BulkNotification message can contain a packet of any number of signals indicating that a transaction has been completed, delayed, or canceled, or that a completed transaction has been subsequently reversed and canceled. The packet header contains the version, total size, and number of entries, all in three sections, which detail the aforementioned characteristics.

The request package includes the following:

name type description size short package size (including this word!) version short package-version format, allowing transparent software updates. SourceHub long where the message comes from NoSettled- long number of entries for completed transactions Transactions in its section NoCancelled- long number of deleted transaction records in the past Deferred in the list of completed transactions NoChargeBacks long number of transactions completed incorrectly DATE data block of data for completed, deleted and

with refunded quantities.

The completed transaction format is as follows:

name type OurTxID GUID description transaction completed SettlementBatch long the batch number of the delivery SettlementTime date/time the date of performance.

The format of the delayed transaction is as follows:

name type description

OurTxID GUID deleted transaction

CancellationTime date/time is the time of cancellation.

Format of the refunded transaction:

The completed transaction format is as follows:

name type OurTxID GUID description transaction completed.

The TransactionAbandoned packet indicates that a transaction has failed. If a transaction is rejected by the provider hub's authorization server, this is an indirect error signal to the client hub, but the client can try to indicate another payment system available to it, or the hubs will abort the transaction. If the hubs abort the transaction, this packet is sent to a client club for synchronization, which only works if the client and provider are connected to different hubs. If the client and provider are on the same hub, the provider component performs all writes and the client component is passive.

The request packet is then:

name type size short description pack size (including this word!) short version package-version format, allowing transparent software updates.

OurTxCode

GUID

ReasonCode short interruption reason: client interrupts, not authorized, lack of time, etc.

The external interfaces of the VPS 10 payment authorization system use HTTP and SSL encryption for the connection between clients and service providers. The following requests are supported by the system: service provider transaction start, service provider completion notification, service provider credit against transaction, client transaction payment request. The following notifications to service providers are supported: transaction closed (cancelled, rejected, approved), completion deadline notification, exception notification. Within this, each subsection represents a required packet variable and also contains details of the format of possible responses. Response codes are plain text, with one field per line, in the name = value format. For example:

OurTx=A23452-1234-232

IP=255.255.200.2

XML formatted messages can also be used. Encryption of the content is also possible.

The service provider sends a transaction start message indicating that the client wishes to make a purchase. The VPS 10 payment authorization system registers the transaction in a transaction table and returns a transaction identification code and IP address for future communication with the client.

The parameters can be the following:

name target constraints MESSAGE message type indicates payment VendorTxCode identifies the transaction to the service provider with a maximum of 20 characters, unique Description Amount purchased product description, free text 64 characters total transaction value numeric string

Currency transaction currency (θΒΡ, USD) provider-specific, system-supported currency Deferred later delivery, payment at the initiative of the service provider "yes" or "no" usually "no" Micropay collective invoice payment requested yes or no by service provider or client) usually “no” small purchases below a certain amount Zip Zip code. for matching client identification (only with country code) max 20 characters name target constraints

SupplyAddress the service provider requests the client's name and address. yes, no, or

(automatic, if provider allows M=can choose on Authorization Pages), not fulfilled if client profile does not allow it. Client can choose: cancel transaction or provide address, if M=can choose flag.

NotificationURL URL for future messages. URL

service provider system management is improved by up to 100 characters.

The response message:

name target constraints status indicates that the transaction can be continued yes, try later, invalid request URL to redirect a client's browser to e.g. http://vps.com provider uses /continueTx.asp?

'*· ” -* · *·*

VPSTX=sadgsahjdghjas ICETX VPSCHECK VPS unique transaction identifier 32 characters internal code that is not received by the client, 4 characters verify that the message was generated by the client. Reason reason for incorrect request e.g. (no amount specified) error description in free form max 100 characters

Service provider message, before delayed fulfillment. Parameters:

name target constraints MESSAGE message type display "delivery completion" ICETX which transaction is being completed? 20 characters (possibly GUID) PostNotify in some cases, the status code (completed, dropped) can simply be returned. "yes", "no" In other cases, the authorization must be updated, usually not If possible, the status code is returned immediately, but it is easier for the service provider to only provide asynchronous responses.

NotificationURL URL for sending future notifications (active IP

transaction) It makes it easier for the service provider to manage the organization of their website.

Reply message:

name target constraints RESULT return code. indicates whether the transaction ACCEPT accepted, expired, unknown or taking EXPIRED time. In the latter case, UNKNOWN “transaction Complete” message will be sent. AUTHORIZING

A “Vendor Credit against Transaction” message is sent to encourage purchases on credit. The credit can be a simple payback or a prize game format.

The parameters:

name target constraints MESSAGE message type "CREDIT" ICETX transaction in which the service provider credits. 20 characters This transaction indirectly identifies the client and the payment system to be used, possibly GUID. AMOUNT the amount to be refunded is a numeric string max 2 decimal. max value 1,000,000.00 Usually the original price CURRENCY the currency used for payment (GDP, USD...) provider specific

fictitious, supported currency.

Usually the price

NotificationURL is the currency of the message sending URL.

URLs (max 100)

The response message:

name target constraints

RESULT Return code. indicates that the transaction is UNKNOWN in progress, is unknown, or CAN’T is no longer valid in the payment system PROCESS

AUTHORIZING A “Client Transaction Payment Request” request is generated when the service provider informs the VPS 10 payment authorization system of a pending request, and the service provider redirects the client connection to the

to the appropriate hub of the client. The URL is specifically the forwarding address for the response from the vendor to the “Vendor Transaction Start” message. The parameters of the “Client Transaction Payment Request” are as follows:

name target constraints ICETX identifies the transaction for VPS max 32 characters

There is no specific response to the message, it depends on the progress of the request.

The message "Transaction Complete" is displayed on the provider's website, which is either at a permanent URL or at an address specified in the transaction request message. The parameters are as follows:

name target constraints MESSAGE message type shows transaction complete, completed, loan disbursement complete VendorTxCode identifies the transaction to the service provider, max 20 If the transaction is a deferred settlement or character credit, this will be the original ICE Tx code. ICETX VPS_CHECK our transaction code is a 20 character secret code that must match the original secret code sent to the service provider. Status result of the transaction. Indicates authorization- accepted, rejected, client disappeared or rejected, system error. interrupted, incorrect TimeStamp transaction acceptance, rejection, date/time, etc.

Reply message:

name target constraints RESULT indicates that the service provider has received the signal. OK, in case of a system error, the transaction must be reversed. Time Stamp service provider's performance date/time

A Fulfillment Expiry Notification message is received by the service provider in a delayed fulfillment transaction when the deadline for fulfillment has expired. This message is informational and requires a response, such as “OK” or “unknown transaction”.

The parameters:

name target constraints MESSAGE indicates message type "expired" ICETX Vendor_TX transaction ID indicates that the delayed transaction time has expired, the reason for its failure is client's account deleted Time Stamp if this happened date/time

The response message:

name target constraints

RESULT OK or Unknown transaction OK, unknown Tx

The status request message allows the service provider to query the VPS 10 payment authorization system for the exact status of the transaction. The parameters include the VPS system or service provider transaction ID, the service provider identification code, and other information related to the transaction. The response message contains the transaction status, amount, start time, and the nature and time of the last step.

The solution according to the invention has been described so far in an example of a preferred embodiment. The solution according to the invention can be implemented in many places in a different way from the embodiment according to the example. It can be implemented, for example, by using telephone connections instead of the Internet. The VPS 10 payment authorization system can be implemented using practically any electronic data transmission method, such as a mobile telephone network suitable for e-commerce, or via digital TV. The common currency of the VPS accounts can be British pounds, Euro, Eurodollar or any other predetermined currency.

Claims (11)

*; :Σ ·** ’\t .54 - «· PATENT CLAIMS 1. An intermediary payment authorization system for conducting secure electronic/digital transactions between a client and a service provider, which system includes a) a trusted third-party registration system storing client and service provider identifiers, verification codes, payment details and bank details, b) an audit trail generator that can be used by any participant in the electronic/digital transaction, characterized by: c) there are hubs (16, 18, 20) connected between the private network (14, 46) and said individual participants of the payment authorization system (10), and between the private network (14, 46) and the payment system (32), enabling the establishment of a selective connection with the payment authorization system (10), d) there is a VPS registry (12) that registers the association of hubs (16, 18, 20) and clients and mediates the processing of transactions between the responsible parties without direct contact. 2. A payment authorization system according to claim 1, characterized in that it has an autopay system enabling the client (22) to be identified for all transactions within the same connection between the client (22) and the service provider (24). 3. A payment authorization system according to claim 1 or 2, characterized in that it has a hub (16, 18, 20) for separately receiving verified instructions from the electronic/digital transaction service provider (24) to the client (22). 4. A payment authorization system according to claim 1 or 2, characterized in that there are hubs (16, 18, 20) that store user names, digital certificates and payment system data between the client (22) and service provider (24) data and do not share them with the user during the execution of the electronic/digital transaction. 5. The payment authorization system of claim 3, wherein each hub (16, 18, 20) comprises a processor for evaluating and/or authorizing an electronic/digital transaction and/or authorizing payment through a financial institution. 6. Payment authorization system according to claim 1 or 2, characterized in that the client (22) of the payment authorization system (10) is authorized to use a bank card payment system (32). 7. A payment authorization system according to claim 1 or 2, characterized in that during the electronic/digital transaction, the service provider (24) has a means of directing the client (22) via a hub (16, 18, 20) to a VPS accounting entity (12) mediating the transaction without direct connection between the parties involved. 8. A payment authorization system according to claim 7, characterized in that the client (22) and the service provider (24) are connected to hubs (16, 18, 20) via an electronic network (26). 9. The payment authorization system according to claim 8, characterized in that the electronic network (26) comprises at least one of the Internet, a cable network, a cellular network and/or infrared telecommunications devices, to which electronic network (26) the client (22) and the service provider (24) are connected via an electronic interface. 10. A payment authorization system according to claim 1 or 2, characterized in that the bank card or other payment or credit system is a registered member of a secure, general system. 11. A payment authorization system according to claim 1 or 2, characterized in that the payment of a smaller amount than a specified value completing the electronic/digital transaction is a micropayment payment against the client's (22) U.S. Dollar-based deposit. Z Kei λ . Él· cl If DANUBIA^ ^Λ Patent and Trademark ündaKft Elemér Ysuhai Patent attorney