EP1446778A2

EP1446778A2 - Payment protocol and data transmission method and data transmission device for conducting payment transactions

Info

Publication number: EP1446778A2
Application number: EP02791681A
Authority: EP
Inventors: Dirk Ammermann; Gero Offer; Andreas Marra; Stephan Kruppa; Denis Bouceka; Andreas Schulze; Damian Hackett; Bernd Biechele; Manfred Männle; Holger Zimmermann; Ove Blumert; Michael Weber; Lysann Most; Frank Köhntopp
Original assignee: Encorus Technologies GmbH
Current assignee: Encorus Technologies GmbH
Priority date: 2001-11-14
Filing date: 2002-11-14
Publication date: 2004-08-18
Also published as: WO2003042938A3; WO2003042938A2; US20050256802A1; AU2002358013A1

Abstract

The invention relates to a method for conducting a transaction on a system, which comprises at least one central processor platform, at least one wallet server, and at least one payment server. The central processor platform, in turn, comprises a routing engine that is coupled to the wallet server and to the payment server via a communications connection. The inventive method involves the following steps: receiving a transaction request at the payment server or at the wallet server; routing the request from the payment server or from the wallet server to the central processor platform, and; operating the central processor platform in order to conduct the transaction.

Description

Payment protocol as well as data transfer procedure and arrangement for payment processes

description

This invention relates primarily to payment systems and, more particularly, to a protocol for handling messages between multiple wallet servers and payment servers from many different providers.

Dealers and service providers are increasingly involved in business processes that are carried out via several channels. In the conventional context, e.g. a customer visits a department store, selects items to be bought and exits (checks out), i.e. purchases the items at the retailer's cash register. The customer typically pays for the items in cash, with a credit card or check.

However, a retailer may be able to increase sales by improving customer friendliness when shopping for goods and services. As an example, customers who purchase items over the Internet may also wish to complete the actual transaction over the Internet. The fact that customers can buy goods over the Internet without physically entering a department store enables a retailer to increase sales and find more goodwill. However, if the transaction is not carried out correctly and on time, the trader can actually lose sales and good will lose.

Another customer friendliness available to merchants is to enable customers to make purchases even when the customer does not carry cash, credit card, or check. For example, known systems allow a customer to make purchases using wireless devices (for example a cell phone, a PDA (Personal Digital Assistant)). As with the Internet, providing such convenience to customers can increase sales and good will, but if the transaction is not done properly and on time, sales and good will may be lost. Retailers therefore typically want to provide customers with multiple payment options and multiple accesses through which goods and services can be purchased. However, these traders are reluctant to offer such flexibility until the transaction can be carried out correctly and on time.

In addition, legacy systems exist to carry out transactions and significant investments have been made to build the legacy system infrastructure.

Traders are typically reluctant to invest in systems that require the replacement of such legacy systems if the time it takes to get a return of such investments is too long. This means that if a merchant needs to replace an existing legacy system with a completely new system to make payments through a wireless device, the merchant will not be willing to make such an investment.

The invention is therefore based on the object of specifying a method and an arrangement for the simplified processing of payment transactions using a telecommunication network which takes account of the legal regulations existing in various countries and established and proven procedural procedures for monetary transactions.

To a considerable extent, private payment transactions that are processed through a commercial service provider must also follow these established rules. The processing of such private payment transactions using the most modern technical means - in particular, via the Internet or the telecommunications networks - exists especially in connection with the further enforcement of electronic money transactions and in connection with the non-commercial sale of products or services (including information) Private individuals increasing need. The data transmission methods that have been proposed so far and are now also available in practice, which are dedicated to this purpose, are due to inadequate reliability and security safety and / or uncomfortable handling not yet suitable for satisfying a corresponding mass requirement.

The invention is therefore also based on the object of specifying a method and an arrangement for the simplified handling of private payment transactions ("P2P = person-to-person) using a telecommunications network which complies with the legal regulations existing in various countries and established and proven procedures of the Takes account of monetary transactions.

In one aspect, the present invention relates to a protocol for performing transactions between multiple customers and merchants. The protocol controls the flow of messages and the execution of instructions contained in these messages across a payment system that enables conventional and non-conventional payment methodologies. The protocol offers a variety of advantages including that complex transactions can be completed in a reasonable time and with an acceptable customer experience.

In particular and in a specific embodiment, the protocol comprises various sub-protocols. Each sub-protocol has its own defined scope with a clear distinction from other sub-protocols. In an exemplary embodiment, the protocol contains two sub-protocols. A sub-protocol is the wallet server, central processor platform and payment server protocol, sometimes referred to as the interoperable mobile payment protocol (IMPP). The other sub-protocol is the payment server and merchant server protocol, sometimes referred to as the open payment protocol (OPP). The OPP controls the exchange of information between a wallet server, a merchant system and a payment server. Alternatively, in the exemplary embodiment, a merchant system can access a payment server via the merchant API rather than the OPP.

The IMPP is supported by a central processor platform (CPP), which is a central instance for forwarding (routes) messages and other uses payment-related processing. The CPP manages central offer data and, in certain scenarios, finds out a customer's wallet server during payment initiation. The CPP also provides the forwarding of payment reports in both directions between a wallet server and a payment server.

The wallet server contains core customer data, which is required for authentication and payment as well as a transaction history. In accordance with the IMPP, the wallet server is triggered during the payment initiation phase and subsequently sends payment reports to the payment server through the CPP. When the transaction status of an acquirer changes, the payment server sends notification messages to the wallet server through the CPP. In addition, each party can send demand reports to update and review the status of a transaction.

The payment server keeps the core customer data on payment and transaction history data. The payment server also receives payment reports from the CPP and processes the reports. In particular, the payment server sends a message to the authorized person on the buyer side in accordance with the IMPP and triggers a result report to the CPP and the merchant system. The payment server sends and receives the required information to / from the merchant system during the various phases of the payment process.

All transaction-related messages and message attributes are not stored in each of the three servers, i.e. the wallet server, the payment server and the CPP. For example, generation data for the OfferlD are only saved in the CPP.

The term "merchant system" refers to a purchasing system (for example a commercially available commerce server) and payment plug-in components which are available in a local merchant domain of an SD model-compliant payment system. In accordance with the OPP, the dealer system sends and receives the required information to / from the Payment server during the different phases of the payment process. The transmission of messages between the CPP and the payment server is handled via the IMPP.

The IMPP makes it easier for merchants to give customers the option to make payments using mobile devices in a reliable, correct and timely manner. In addition, integration with existing legacy systems is made possible by providing a gateway through which standardized, open protocols (e.g. the IUTP protocol) can be used to communicate with the system. For example, the gateway uses the IUTP protocol to translate IUTP messages into IMPP messages and data streams. Retailers therefore do not need to replace old systems and simply connect to the platform (plug-in) on which the IMPP is implemented.

In a further aspect, the invention includes the essential idea of specifying a largely universal payment method based on a conventional bank account ("postpaid") or electronic credit ("prepaid"), which is particularly suitable for payment processing in so-called B2C (business-to- Consumer) area as well as in the P2P (person-to-person) area is applicable, that means shopping in real and virtual shops, payment in gastronomic or cultural institutions etc. and the "sending" of money amounts in the private area.

It also includes the idea of using the possibilities of a telecommunications network for this, in particular the possibility of extensive processing in almost real time (real time). The invention also includes the central idea of providing and using a unique identifier - the context identifier - for the cross-transactional identification of goods or services offered by a provider (in particular an entire “shopping cart”) for handling all data transmission associated with offering and paying - and processing operations, in particular the reliable authorization of payment.

In a first embodiment variant of the invention, no period of validity is established when the context identifier is generated, so that it is potentially is valid for a limited period. The term "static offer" can be used for this. It will be used in particular for the payment of goods or services offered via television channels ("TV Shopping") and for the products offered on vending machines (VM) via a telecommunications network using a telecommunications device.

In an alternative embodiment of the invention, when the context identifier is generated, a period of validity is defined and is automatically invalidated when it expires. Here one can speak of a "dynamic offer". It will be used for various other shopping and payment processes, in particular for individual shopping campaigns in virtual shops or real shops or department stores.

In both cases, the context identifier can be deleted or destroyed at the request of the provider of the goods or services. To invalidate the context identifier, an elimination signal is sent to the provider upon expiry of the period of validity or at the request of the provider, in order to inform the provider of the invalidation of the identifier in question.

The information transfer of the context identifier to the - potential - customer or customer takes place in a first variant as an invariant optical display, in particular lettering on a shop window display or automatic dispenser or printing on a brochure or catalog or the like. In other variants, the context identifier is transmitted to potential customers as a variable optical display on an electro-optical display device or by voice output or an acoustic signal. These different types of transmission take into account the specific shopping situations of industrial society, where, in addition to traditional shop purchases and the vending machines that are particularly well-established as drinks, cigarette and candy vending machines, Internet shopping and TV shopping have long since emerged.

For the majority of existing sales channels, it is advantageous if the context identifier is used in a broadcast procedure outside the telecommunications network, in particular by radio or television transmission or sales sand or distribution of printed matter or e-mail broadcast, during the period of validity is transmitted to a large number of potential customers. In recent times, however, the possibilities for purchasing goods or services (information!) Offered directly via a telecommunications network have become significantly more important. A variant is advantageous for this, in which the context identifier, in particular in a broadcast process, in a short message or via WAP, is transmitted to the customer's telecommunications terminal via the telecommunications network and displayed there.

The steps of requesting a context identifier by the provider and sending such to the provider or dealer (merchant) preferably run as essentially automated data transmissions between the system administration server and a dealer server or provider data terminal via a data and / or telecommunications network, especially the Internet. This applies both to Internet shopping and to the use of the proposed system by "classic" retail establishments.

In a typical scenario, after the step of transmitting the context identifier to the customer, the context identifier is transmitted by the customer via the telecommunications network to a customer server of the network operator or a service provider in the telecommunications network, by the customer server, service server or dealer Server sent a request message to the provider for a binding offer, the provider sent an offer data record to the customer server and the offer data record was transmitted from the customer server to the telecommunications terminal of the potential customer and there for menu navigation Confirmation of the transaction displayed. The data transmission is carried out in the steps of the request for a binding offer and the transmission of the offer data via the system administration server, which in particular carries out search and routing functions between network operator or service provider and provider.

The context identifier (OfferID) can be generated entirely by a suitable generator at a system management server of the proposed system. However, it can alternatively also be generated entirely externally and transmitted to the system management server for confirmation by the provider as part of the request. A variant is particularly advantageous for “catalog providers”, in which the context identifier has a first and a second section, the first section being a provider identifier generated or managed by the system management server and the second section being a provider identifier generated or managed by the provider Is goods or goods group identifier and the method comprises a transmission of the second section to the system administration server, the linking of the first and second section in the system administration server and the sending or confirmation of the entire context identifier to the customer or to the customer ,

To a certain extent, the provider can be assigned "number ranges", whereby he continues to use his own catalog number behind a section ("prefix") that represents his identity as a provider. This makes it much easier to use context identifiers in catalog scenarios. The combination of the first section (prefix) with the second section (catalog number) - after the prefix has been assigned by the system administrator - can also be done by the provider himself, whereby the responsibility for the uniqueness of the context identifier lies naturally with the provider.

Usually, the customer who is informed of the context identifier will enter it himself on his telecommunications terminal or, if necessary, also by voice input. However, the above-mentioned options for issuing the identifier to the customer can result in an automatic entry process, which is of course more error-resistant than manual entry. For this purpose, the identifier is converted in or on a telecommunications terminal, in particular by a camera or a scanner connected to it, from an optical or acoustic signal to an electrical signal.

The essential aspects of the device according to the invention and their advantageous further developments largely result from the above-described processes. aspects in their mapping to a system structure, so that they are not explained again in detail here.

From an organizational point of view, the proposed system can be implemented in a number of different configurations, whereby it is technically fundamentally centered around a system management server to which a customer server (hereinafter also referred to as a valid server) and a merchant server (payment server) are assigned and with which these are connected by communication channels. If "a" dealer or customer server is used in this context, this also means a plurality of servers from different service providers, financial institutions, etc., which have a corresponding function in the overall system.

In a first system design, all of the servers mentioned are located at a telecommunications company or customer-oriented service provider, which connects both providers and customers to the system. In a second system configuration, the telecommunications company (hereinafter also abbreviated as Telco) or the customer service provider operates Customer and dealer server, but the system administration server is operated by a separate company (hereinafter also referred to as Opco) and is essentially only required for the generation of the context identifier and the ongoing determination of the responsible dealer server. The relevant information for the assignment of the dealer and customer servers responsible for a specific transaction is in this case in particular the system administration server.

In a third configuration, there are separate customer and dealer service providers, each of which only operates the associated server, while the system operating company (Opco) operates the system management server. Here, a first scenario is conceivable in which (as in the aforementioned variant) the system management server essentially only generates or confirms the context identifier and is used to find the dealer server later. In a second scenario, the system administration server essentially carries the transaction in terms of processing and transmission technology. Finally, it makes sense to configure the system in which the operating company management server as well as the dealer server, while only customer servers are operated by Telco or the customer service provider.

The second and third of the system configurations mentioned above, where there is an independent system management company and thus a so-called "opco domain", are advantageous for the implementation of a very large, in particular global, system with a connection of a large number of providers and customers. They enable the central data storage of the relevant data (OfferlD and server addresses) for a large number of users who process electronic transactions via a large number of dealer servers and / or customer servers.

To implement one of its most important functions, the system management server has a code generator unit for generating the context identifier in response to a received request and a code transmission device for transmitting the generated context identifier directly or indirectly to the requesting provider terminal. In a modification to a special procedure (“catalog provider”) already mentioned, the code generator unit only serves to generate a first identifier section that identifies a provider, and in a further modification, instead of the code generator unit, means for receiving and for checking the uniqueness are provided externally generated codes and to issue a confirmation signal to confirm the uniqueness (and thus usability) of an externally generated offer.

Specifically for the generation and handling of the above-mentioned dynamic offer, the system management server has timer means assigned to the code generator unit and time storage means for assigning and storing a validity period to each context identifier, and a time comparator unit connected to the timer and time storage means for monitoring the process a specified period of validity and for the output of an elimination signal for invalidating the context identifier when expired. It is understood that in the case of the use of static remote IDs, these components are replaced by a deletion unit which responds to a deletion request received from the outside and eliminates the identifier. An essential functional component of the proposed system architecture is furthermore a data storage system (OfferlD Repository) for storing and managing all valid context identifiers and information associated with them in the system, in particular data relevant to payment transactions and identifications of data transmission processes that have taken place. With the help of this, for example, for every transaction the responsible customer or Find the dealer server. The components for managing dynamic OfferlDs mentioned in the previous paragraph and assigned to the system management server there can also be assigned to the repository; According to a further essential aspect of the invention, on the one hand the TK network devices of the customers or customers using the network and on the other hand at least one customer server of the operator of the TK network or a customer-oriented service provider are connected to the TK network. The invention also includes the idea of providing a system administration server for the administration and routing of the transaction-related data in relation to the customer as well as the provider side, which is network-connected to at least one dealer server of a dealer-oriented service provider. This will typically involve data network connections that can be linked to the telecommunications network to connect customers, but do not necessarily have to. Finally, the invention includes the idea of providing suitable data traffic routing means for routing the data records to be exchanged between the parties involved in the course of offer and payment processes.

The main component of the proposed system thus forms a system management server which, in a practical practical implementation, is essentially permanently connected to a plurality of customer servers in a number of telecommunication networks, in particular mobile radio networks. In addition, in a practical system configuration, the system management server can be connected to a plurality of dealer servers, each dealer server in turn being connected or connectable to a plurality of provider terminals, and it has a dealer memory for storing identification and Address data of the connected providers. In a further preferred embodiment, the system management server and / or the dealer server (s) are arranged in a telecommunications network, in particular a mobile radio network, and one or more of these form a functional unit with the customer server or customer servers.

From an organizational point of view, the proposed system can also be implemented in a number of different configurations, although technically it is basically centered around a system management server, which is normally a customer server (hereinafter also called a valid server) and a merchant server (payment server). assigned and with which they are connected by message transmission channels. If "a" dealer or customer server is used in this context, this is also to be understood in the following as a plurality of servers from different service providers, financial institutions etc., which have a corresponding function in the overall system.

In a first system design, all of the servers mentioned are located at a telecommunications company or customer-oriented service provider, which connects both providers and customers to the system. In a second system configuration, the telecommunications company (hereinafter also abbreviated as Telco) or the customer service provider operates customer and dealer servers, but the system management server is operated by a separate company (hereinafter also referred to as Opco) and essentially only for the generation of the context identifier and the ongoing determination of the responsible dealer server is required. The relevant information for assigning the dealer and customer servers responsible for a particular transaction is in particular with the system administration server.

In a third configuration, there are separate customer and dealer service providers, each of which also operates only the associated server, while the system operating company (Opco) operates the system administration server. Here, a first scenario is conceivable in which (as in the aforementioned variant) the system management server essentially only generates or confirms the context identifier and is used to find the dealer server later. In a second scenario, the system management server carries processing and transmission From a technical point of view, essentially the transaction. Finally, a system configuration also makes sense in which the operating company operates both the system management server and the dealer server, while only customer servers are operated by the Telco or the customer service provider.

The second and third of the system configurations mentioned above, where there is an independent system management company and thus a so-called "opco-domain", are advantageous for the implementation of a very large, in particular global, system with a connection of a large number of providers and customers. They enable central data storage of the relevant data (OfferlD and server addresses) for a large number of users who process electronic transactions via a large number of dealer servers and / or customer servers.

To implement one of its most important functions, the system administration server has a code generator unit for generating the context identifier in response to a received request and a code transmission device for sending the generated context identifier directly or indirectly to the requesting provider terminal. In a modification to a special procedure (“catalog provider”) already mentioned, the code generator unit only serves to generate a first identifier section that identifies a provider, and in a further modification, instead of the code generator unit, there are means for receiving and for checking the uniqueness externally generated codes and to issue a confirmation signal to confirm the uniqueness (and thus usability) of an externally generated offer.

Specifically for the generation and handling of the above-mentioned dynamic offers, the system management server has timer means and time storage means assigned to the code generating unit for assigning and storing a validity period to each context identifier, and a time comparator unit connected to the timer and time storage means for monitoring the expiry of a specified period of validity and for the output of an elimination signal to invalidate the context identifier on expiry. It is understood that if static information is used, these components are replaced by a deletion unit that is based on one of these components are replaced by a deletion unit which responds to an externally received deletion request and eliminates the identifier.

An essential functional component of the proposed system architecture is furthermore a data storage system (OfferlD Repository) for storing and managing all valid context identifiers and information associated with them in the system, in particular data relevant to payment transactions and identifications of data transmission processes that have taken place. With the help of this, for example, for every transaction determine the responsible customer or dealer server. The components for managing dynamic OfferIDs mentioned in the previous paragraph and assigned to the system management server there can also be assigned to the repository.

For the expedient and timely execution of the actual financial transaction, in particular at least one account management server is directly assigned to the or a telecommunications network, and this works with the system administration server and / or with the customer server to carry out a payment, in particular with access to a prepaid credit , together. On the other hand, the or at least one account management server can be arranged outside the network-internal control area of the or each telecommunications network and in particular can be connected directly to the customer's telecommunications terminal.

To ensure system-autonomous control of all transactions (independent of external triggers, which could easily lead to disruptions in the case of a very large number of concurrent transactions), the system administration server has a sequence program memory for storing at least one transaction sequence program for data communication between the or each customer. Server and the provider end devices or the or each dealer server.

Essential aspects of the most important procedural sequences in the proposed system can already be derived from the above explanations of the system structure, so that the corresponding procedural aspects are not described again exhaustively in the following. In the following, some formative processes rens thoughts of the invention and its preferred embodiments discussed in more detail.

In a particularly advantageous system design, the provision and use of a unique identifier - the context identifier - for the cross-transactional identification of goods or services offered by a provider (in particular an entire “shopping cart”) for handling all the offers and Payment related data transmission and processing operations, in particular the reliable authorization of payment, provided.

In a first embodiment of the invention, no period of validity is established when the context identifier is generated, so that it is potentially valid indefinitely. The term "static offer" can be used for this. It will be used in particular for the payment of goods or services offered via television channels ("TV Shopping") and for the products offered on vending machines (VM) via a telecommunications network using a telecommunications device.

In an alternative embodiment of the invention, the generation of the

Context identifier defines a period of validity and it is automatically invalidated when it expires. Here one can speak of a "dynamic offer". It will be used for various other shopping and payment processes, in particular for individual shopping campaigns in virtual shops or real countries or department stores.

In both cases, the context identifier can be deleted or destroyed at the request of the provider of the goods or services. To invalidate the context identifier, an elimination signal is sent to the provider upon expiry of the period of validity or at the request of the provider to indicate to the provider that the identifier in question has become invalid.

In a first variant, the context identifier is transmitted to the - potential - customer or customer as an invariant optical display, in particular lettering on a shop window display or Vending machines or printed on a prospectus or catalog or the like. In other variants, the context identifier is transmitted to potential customers as a variable optical display on an electro-optical display device or by voice output or an acoustic signal. With these different types of transmission, the specific shopping situations of industrial society are taken into account, where in addition to traditional shop shopping and the vending machines, which are particularly well-established as beverage, cigarette and candy vending machines, internet shopping and TV shopping have long since emerged.

For the majority of existing sales channels, it is advantageous if the context identifier in a broadcast process outside the telecommunications network / in particular by radio or television transmission or sending or distributing printed matter or e-mail broadcast, during the period of validity is transmitted to a large number of potential customers. In recent times, however, the possibilities for purchasing goods or services (information!) Offered directly via a telecommunications network have become significantly more important. A variant is advantageous for this, in which the context identifier, in particular in a broadcast process, in a short message or via WAP, is transmitted to the customer's telecommunications terminal via the telecommunications network and displayed there.

The steps of requesting a context identifier by the provider and sending such to the provider or dealer (merchant) preferably run as essentially automated data transmissions between the system administration server and a dealer server or provider data terminal via a data and / or telecommunications network, especially the Internet. This applies both to Internet shopping and when the proposed system is used by "classic" retail establishments.

In a typical scenario, after the step of transmitting the context identifier to the customer, the context identifier is transmitted by the customer via the telecommunication network to a customer server of the network operator or a service provider in the telecommunication network, through which Customer server, service server or dealer server sent a request message to obtain a binding offer to the provider, the provider sends an offer data record to the customer server and the offer data record is transmitted from the customer server to the telecommunications terminal of the potential customer and displayed there as part of a menu to confirm the transaction. In this case, the data transmission is carried out in the steps of requesting a binding offer and sending the offer data via the system administration server, which in particular carries out search and routing functions between network operator or service provider and provider.

The context identifier (OfferID) can be generated entirely by a suitable generator at a system management server of the proposed system, but alternatively it can also be generated entirely externally and transmitted to the system management server for confirmation by the provider. A variant is particularly advantageous for "catalog providers", in which the context identifier has a first and a second section, the first section being a provider identifier generated or managed by the system management server and the second section being one generated by the provider or managed goods or goods group identifier and the method comprises transmitting the second section to the system administration server, linking the first and second sections in the system administration server and sending or confirming the entire context identifier to the customer or to the customer ,

To a certain extent, the provider can be assigned "number ranges", whereby he continues to use his own catalog number behind a section ("prefix") that represents his identity as a provider. This makes it much easier to use context identifiers in catalog scenarios. The combination of the first section (prefix) with the second section (catalog number) can - after the prefix has been assigned by the system administration - also be carried out by the provider himself, whereby the responsibility for the uniqueness of the context identifier lies naturally with the provider. Usually, the customer who is informed about the context identifier will enter it himself on his telecommunications terminal or, if necessary, also by voice input. However, the above-mentioned options for issuing the identifier to the customer can result in an automatic entry process, which is of course more error-resistant than manual entry. For this purpose, the identifier is converted in or on a telecommunication terminal, in particular by a camera or a scanner connected to it, from an optical or acoustic signal into an electrical signal.

In a further respect, the invention includes the essential idea of specifying a largely universal system for processing financial transactions on the basis of a conventional bank account ("postpaid") or electronic credit ("prepaid"), which is particularly suitable for payment processing in the P2P area is applicable, that is, the "transmission" of amounts of money allowed in the private sector.

It also includes the idea of primarily using a telecommunications network for this purpose, in particular the possibility of extensive processing in almost real time (real time). On the one hand, the telecommunications terminals of the subscribers using the network and, on the other hand, at least one transaction server of the operator of the telecommunications network or a customer-oriented service provider are connected to the telecommunications network.

A person-to-person payment in the sense of the present invention presupposes the existence of an account “wallet account” suitable for electronic credit transfer on the part of both the payer and the payee. The implementation can be done on the one hand in a two-step process by (1) paying to a "merchant" (P2P engine) and (2) crediting to a payee account on the part of the "merchant" or on the other hand - more user-friendly - by integrating the P2P engine implemented at a payer's account management server. The German term "transaction server" essentially stands for the P2P engine, while the account management server, which was also mentioned above, also means "payment instrument". (PI) can be called. The process sequence of the two variants is described in more detail in the figures.

To initiate the P2P payment process, the payer contacts the transaction server or the P2P engine via his telecommunications terminal via a telecommunications network (in particular a mobile network) or via his data terminal via a data network (especially the Internet) and specifies an address or another Identifier of the recipient and the payment amount. Optionally - in international payments - the payment currency and a text message (e.g. for the purpose of payment) can be entered. In the case of the transaction server addressed by the payer or a further transaction server connected to the payer, a second payment instruction record, which is ultimately used to credit the payee, is formed from a first payment instruction record created from the payer entry. In this case (unless already entered when entering) the specification of an account identifier of the payee takes place.

If the electronically managed accounts of the payer and the payee are kept on different account management servers, the transformation between the first and second payment instruction data records typically includes the determination of the server address of the (second) account management server of the payee and a request to the payee's account identifier , After they have been answered, the payment amount can be credited.

Authentication of the payer with access to subscriber data identifying him as a subscriber of a telecommunications network is provided in the payment process in any case. If the payment process is triggered by its TK terminal (mobile terminal), the authentication uses its MSISDN for an ab initio authentication. If, on the other hand, the payment process is initiated from a data terminal, a confirmation step with access to the telecommunications network, the subscriber of which is the payer, is provided. A confirmation request is also optionally provided as an additional step in the first-mentioned method. In international payment transactions, the first payment instruction record has a first currency code and the second payment instruction record has a second, different currency code, and when the second payment instruction record is created, a conversion from the amount information of the first payment instruction record into an amount information of the second payment instruction record performed due to a pre-stored exchange ratio. The hardware and software equipment required for this is provided by the system operator or service provider, and it can be thought of as being implemented in a conversion server or as an additional functionality of one of the account management servers involved. The exchange ratio to be applied is provided by the system operator's transaction server, or the latter also performs the conversion as an additional functionality.

The data transmissions are carried out by and to the payer's telecommunications terminal for a payment, all by short message in accordance with SMS, data file transmission in accordance with WAP or via IVR voice communication. Here, the SMS variant - especially without additional confirmation - is more useful for low amounts (including "micropayments"). In the WAP variant, the P2P engine is implemented in the manner of a "WAP shop" that is now known. In any case, it is advantageous to avoid changes in the access medium during the sub-steps of triggering the payment, authenticating and confirming the transfer of credit.

In addition to the already mentioned authentication of the payer, in the case of larger amounts of money, one of the payee is preferably provided on the basis of user data stored in the system (in particular the transaction server or second account management server). This represents an important measure against the misdirection of substantial payments. In addition, a procedure is also advantageous in which the payer triggers a deletion process regarding the payment data transfer via a suitable execution of the first transaction server - or also a special interface to his account management server who can cancel the payment. In a further option, a notification of the payee about the proposed credit transfer is provided, and in a special further training the latter can also specify a special payment instrument (an account management server) to which the electronic payment is to be directed. In this sense, current interventions in the payment process by the recipient are also possible.

Furthermore, the realization of a commercial operation for the system operator or service provider involves the implementation of transaction fees on the message or data side (hereinafter referred to as "settlement amount information"). The transaction costs can be borne by the payer or payee or split between the two Together with the settlement amount information, a corresponding identification is added to the second payment instruction data record as to whether the payer account or the payee account or both are to be debited proportionately.

To ensure an economically viable execution of international payment transactions between currencies for which there is no fixed conversion ratio, a so-called spread must be implemented in the data transfer process. For this purpose, corresponding spread information is included in the conversion of the amount information of the first payment instruction record (in the first currency) into that of the second payment instruction record (in the second currency). This is stored in particular in a database assigned to the transaction server or system management server.

Essential aspects of the proposed system already result from the procedural aspects highlighted above, so that repetitions are not necessary in this respect. It goes without saying that transaction servers represent an essential component of the proposed system and - depending on the specific system design - with telecommunications terminals and optionally additional data terminals from the payer and - directly or indirectly via further transaction servers - with account management servers on payer and Communicate the payee side. In a preferred embodiment, the centerpiece of the system is a system administration server, which is connected to several transaction servers in the is essentially permanently connected and can also form a functional unit with a transaction server. The system administration server is assigned to a telecommunications network or to several telecommunications networks (in particular mobile radio network (s)). In a preferred system version, this assignment also applies to the (or at least one) account management server.

The system management server typically has a sequence program memory for storing at least one transaction sequence program for data communication between a payer's telecommunications terminal and the account management server or the transaction server or the transaction servers, and it is expediently a dedicated data storage system for storing and managing all valid user data and, in particular of data-relevant data and identifications of data transfer processes that have taken place.

Figure 1 shows a block diagram of a publisher and buyer system.

Figure 2 illustrates a payment flow in the system shown in Figure.

Figure 3 illustrates an embodiment of the interoperable mobile payment protocol (IMPP).

FIG. 4 shows an exemplary architecture of an IMPP sub-protocol.

Figure 5 illustrates WOPP message processing.

FIG. 6 shows processing for a web WAP macro payment (macro payment).

FIG. 7 shows processing for a Web WAP micropayment.

FIG. 8 shows processing for a WAP-WAP macro payment (macro payment). Figure 9 illustrates processing for a web WAP address transfer without payment.

FIG. 10 shows processing for an automatic macro payment.

FIG. 11 shows processing for a static OfferID generation.

Figure 12 shows an IMPP status model for direct macro payments.

FIG. 13 shows an IMPP status model for macro payment credits.

FIG. 14 shows an IMPP status model for delayed macro payments.

FIG. 15 represents an IMPP status model for partial macro payments.

FIG. 16 shows an IMPP status model for direct micropayments.

FIG. 17 shows an IMPP status model for delayed micropayments.

FIG. 18 shows an IMPP status model for micropayment credits.

Figure 19 shows an IMPP message structure.

FIG. 20 shows processing for version agreement in the context of IMPP.

FIG. 21 shows an OfferID status diagram.

FIG. 22 shows processing for an example currency conversion.

FIG. 23 shows processing for micropayment clearing and settlement.

Figure 24 illustrates a balancing data status diagram. Figure 25 illustrates processing for fee distribution.

Figure 26 illustrates processing for billing.

FIG. 27 represents background processing (back-office processing).

28 shows a schematic overview representation of essential components or layers as well as process sequences of a system according to the invention.

29A to 29C show a schematic flow diagram (sequence diagram) and a list of the step sequence of an embodiment of the method according to the invention (web WAP scenario).

30A to 30C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (WAP-WAP scenario).

31A to 31C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (push-fall-back scenario).

32A and 32B show a schematic sequence diagram and a list of the sequence of steps in the generation of a static open ID in the context of an automatic dispenser / TV shopping scenario.

33A and 33B show a schematic sequence diagram and a list of the sequence of steps in the deletion of a static OfferID in the same context.

34A to 34C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (automatic dispenser / TV shopping scenario). 35A and 35B show a schematic flowchart (sequence diagram) and a list of steps in the execution of a clearing procedure in the transaction of larger amounts of money (macro payment).

36A to 36C show a schematic flow diagram (sequence diagram) and a list of the sequence of steps of a further embodiment of the method according to the invention (micro-payment scenario with "stored value accounts").

37 shows a schematic synoptic representation of the system structure and method steps in a first method variant.

38 shows a list of the method steps in this first variant.

39 shows a schematic synoptic representation of the system structure and method steps in a second method variant and

40 shows a list of the method steps in this second variant.

In the present case, an interoperable mobile payment protocol (IMPP) is described in connection with a system which provides for message transmission between a publisher domain and an acquirer domain. Both mobile devices and non-mobile devices can be used in conjunction with the IMPP. The IMPP is not limited to use in connection with the specific system described here and can be used in other systems with architectures that differ from the system architecture described here.

The term "interoperable" refers to the interoperations that are performed between the publisher domain and the acquirer domain. The term "publisher domain" (sometimes referred to herein as "publisher"), as used herein, refers to wallet issues. Means of payment are authorized by, for example, banks or are value storage cards. An editor declares a customer valid and the customer has payment methods in his wallet. In some transactions, such as micro payments, a telco or ISP can be a publisher. The term "acquisition berdomäne "(sometimes referred to here as an" acquirer "), as used here, refers to institutions that acquire transaction-related data from merchants and send this data to a compensation network for authorization.

The terms "customer" and "buyer" used here refer to the owners of means of payment (e.g. credit cards) who make purchases from a retailer. The term "dealer" refers to those who offer goods for sale and / or provide services to a customer against payment by the customer. The term "wallet server" refers to a secure repository for payment credentials from cardholders that allow a customer to complete a remote payment transaction from any of the multiple devices. The term "payment server" refers to a server that accepts payment requests from the issuer domain (e.g. a customer or wallet server) to merchants. A payment server may also have merchant deployment capabilities.

A general overview is given below in the form of a description of a system that enables electronic transactions, including transactions performed using devices such as computers coupled to networks (e.g. wide area networks such as the Internet) and wireless devices (e.g. mobile telephones). Following the overview of the system, details regarding the IMPP are described. In addition, a detailed description of the processing that occurs under control of the IMPP in the exemplary system is provided.

The system requires that a publisher has contracts with consumers and that their accounts (account) handle information. The account information includes payment and security information. The retailer (buyer domain) has contracts with retailers and provides payment services. A central processor platform (interop domain) manages interoperability and offers central services such as transaction settlement and billing. This architecture maintains traditional merchant and merchant acquirer workflows and extends the existing payment infrastructure with mobile payments. With particular reference to Figure 1, the system includes a central processor platform (CPP) which communicates with a wallet server and a payment server. The CPP carries out both real time and non-real time processing. For example, the CPP performs routing, OfferlD, search (look-up), currency conversion and transaction management functions in real time. Non-real-time processing includes, for example, micro payment billing and settlement, fee processing and invoicing, and asset distribution.

The CPP includes a routing engine for routing transaction related messages between wallet servers and payment servers in accordance with the IMPP. In particular, the forwarding machine interrupts the IMPP and forwards requests that include payment transactions as well as responses between external parties. Transactions (macro and micro payments) are therefore carried out by the forwarding machine.

The CPP also includes a currency conversion server, which is coupled to an exchange rate file, an offer identification (OfferID) server, which is connected to an OfferlD repository (repository), a search (look-up) server, which is connected to a wallet server (WS) / Payment server (PS) directory and a negative file server, which is connected to a customer and merchant negative file. The CPP also includes back end processing functionality such as micro-payment settlement and billing, and billing and management. In particular, the CPP comprises a billing and administration server and a micro payment server, which are coupled to a transaction protocol (lock). The billing and administration server is coupled to a new company rule database, which contains rules for the billing and distribution of investments to companies that are new to the system. The billing and management server is also coupled to a database which contains billing data. The CPP forwarding engine listens to IMPP messages, allowing multiple wallet servers to communicate with multiple payment servers through a single entity. By forwarding payment transactions through the CPP, adding additional participants has no impact on the existing installation and simplifies adding additional participants.

Mobile payments, requests and responses are forwarded between wallet server and payment server instances. Other CPP components that perform centralized tasks such as the OfferID generator, search service and FX server are used by the forwarding machine to support the payment processes. The transaction log entries are generated in such a way that they meet the legal requirements and enable coupled (offline mode) processes such as billing. The CPP also processes address change requests, age verification requests and requests to change the payment instrument. Quality identifiers are transmitted together with inquiries / answers, which indicate the quality level of the underlying data.

The CPP forwarding engine receives external notifications of macro payment entitlements and completes the transaction logs and exchanges notifications of any status changes between the other involved parties to keep the WS, MS and Encorus processor platform transaction logs consistent.

With micro payments, the authorization between WI and providers of micro payment means is carried out. The authorizations are therefore transferred to the payment server with the payment message flows. When a payment transaction is in progress, the forwarding machine maintains transaction records and stores all information about a transaction together with a unique transaction ID (transaction ID).

The search for the payment server and merchants involved in a transaction is carried out on the basis of an OfferlD (OID) or RangelD. By Carrying out the search based on an OfferlD, the BasketlD is dissolved and transferred to the MC together with the OID in order to inquire about the shopping basket. The specific retailer determines whether the OID or the BasketlD are used to identify the shopping basket. By performing the search based on a RangelD, the combination of RangelD and dealer catalog number is transferred to the MC to inquire about the shopping basket.

The participant list contains all MSISDNs and pseudonyms (aliases) of the customers, which are registered for mobile payment. The home wallet server ID (home wallet server ID) is also saved for each MSISDN / pseudonym. The MSISDNs / pseudonyms, which are not entered, can be rejected early by the CPP during processing.

The OfferlD identifies a shopping basket. In order to identify the basket information in a comprehensive (cross) WI / MA scenario, the OfferlD is generated centrally. The OfferlD can be used for the mobile payment scenarios for both micro and macro payments. In most cases, OfferlDs are entered via a mobile device with limited capabilities regarding the size of the display and usability of the keyboard.

The OfferlD generator generates an OfferlD on request and the OfferlD repository stores generated OfferlDs together with additional data for search purposes and manages the OfferlD lifespan. Subsequent payment transactions can use the same offer for payment transactions (e.g. VM, TV purchase (shopping)). Static OfferlDs can be "rented" by dealers on a monthly or yearly basis. Dynamic OfferlDs mark a temporary offer, have a certain lifespan and are used by a single customer. A dynamic offer is automatically deleted as soon as a transaction is completed or the maximum lifespan is exceeded.

The OfferlD repository stores information about a requested OfferlD. If age checks, address changes or GI data transfer are requested, the relevant identifiers are set in the OfferlD repository data record. The OfferlD repository also monitors the issued OfferlDs and sets one OfferlD status to "locked" (black-out) as soon as the associated service life expires. The OfferlD repository also supports manual deletion requests. The search services use the OfferlD repository to find the associated payment server.

The merchant negative file either prevents registered merchants from signing up for mobile payment with any merchant acquirer or initiating any transaction in the registered state. In the dealer negative file, the ID, the URL and the dealer name are saved together with a time.

The buyer negative file either prevents registered buyers from signing up for mobile payment on any wallet server or initiating any transaction in the registered state. In the negative buyer file, the ID, name, name, date of birth and MSISDN are saved together with a time.

Since international transactions are handled by CPP, CPP provides a central foreign exchange (FX) rate acquisition, spread management and a currency conversion service. The CPP calculates amounts in customer currency (if they are different from the merchant transaction currency). The FX server stores foreign currency exchange rates and performs currency conversions to settle international micropayments and fee statements.

The wallet server (WS) communicates with buyer devices e.g. via device-specific gateways such as WAP and SMS gateways and stores buyer and transaction-related data such as MSISDN, billing and shipping address, credit card numbers. The wallet server provides customer support functionalities and handles payment protocol processing. The wallet server sends authorization requests to a micro payment instrument (μPI).

Each wallet publisher provides at least one micro-payment means, which is either operated by the publisher or is accepted on the wallet server of a third party. The μPI can be different Type, for example a dedicated value storage account system, a Telco prepaid account or a Telco telephone exchange.

The payment server PS processes the IMPP protocol between the CPP and the merchant and processes an open payment protocol (OPP (open payment protocol)) in the direction of a merchant component. The PS is connected to macro payment officers (e.g. credit card payment officers) via a payment gateway in order to forward authorization requests. The merchant component (MC) is integrated in the merchant's purchasing system to enable an OPP.

Typically, and before the payment transaction, a buyer accesses a merchant's shop, e.g. via a specific purchasing channel (e.g. WEB, WAP, IVR, TV) or reads information and product offers on a vending machine. To confirm the payments, the buyer uses his mobile phone to connect to a wallet server (access scenario (pull scenario)) or is called by a wallet server (push scenario). The authorization is provided by the mobile phone network and the authorization to pay for any type of payment means (e.g. micro-payment means, credit card, debit card) can be carried out.

In particular and with reference to FIG. 2, a 3-domain model defines a process for electronic payments. The term "issuer domain" refers to the issuer and owner of bank cards or other means of payment (e.g. publishers and customers) and to those who act on behalf of the issuer (e.g. the wallet server). The term "acquirer domain" refers to those who acquire payments from a publisher domain. The term "interoperability domain" refers to the interface between the publisher and acquirer domains to enable interoperations (i.e., processes between the publisher domain and the acquirer domain) for electronic payments.

The usual payment flow is described below as a sequence of steps and with reference to FIG. 2. The payment flow described below is based on a a purchase that was carried out via a network such as a wide area network (e.g. the Internet). Of course, other payment flows are also possible and the description continued below is only an example.

Step 0. Shopping. A customer browses (buys) an offer of a merchant's goods / services. As a result, an order is stored in the retailer's purchasing system.

Step 1. Initiate payment. At the end of the purchase, the customer clicks on a link in the shop, which forwards the customer to the wallet server. The URL contains information that enables the wallet server to determine the context of the payment (e.g. merchant URL and order identification). The customer provides the trader with the URL of the wallet server (e.g. the customer can select the URL from a drop-down list) so that the trader can compile the correct URL for the reference. As a result, the wallet server can at least identify the trader and the order.

Step 2. Authorization. The customer logs into the wallet server. The authorization is carried out by the wallet server (which in many cases is the same as the publisher). Once the customer is authorized, the customer retains access to the customer data.

Step 3. Obtain the order information. The wallet server retrieves the order information (order description, payment amount) from the trader. The merchant also returns the URL of his payment server and the accepted payment methods. The wallet server shows the customer the order data.

Step 4. Choosing the payment method. The wallet server represents a list of available payment methods / means from which the buyer can choose, based on the list of payment types accepted by the merchant and the stored payment means of the buyer. The wallet server retrieves the order details and the accepted payment methods. Step 5. Check the payment method. The wallet server first contacts the publisher to verify that the selected form of payment is valid. The publisher can return further data (in addition to a simple yes / no answer) at this point (eg for a one-time token, which is used specifically for the upcoming payment).

Step 6. Payment. The wallet server sends a payment request to the payment server on behalf of the customer.

Step 7. Review the job. The payment server connects to the merchant's shopping system to verify that the order data received from the wallet server is authentic. The payment server receives all the data needed to process the payment.

Step 8. Capture. The payment server forwards the payment data to the acquirer. The acquisition step can be performed asynchronously if a postponed delivery is used.

Step 9. Compensation. The acquirer makes a physical payment, i.e. the acquirer executes the payment request through a financial institution in a backend operation. The compensation can take place asynchronously (e.g. in stacks (batches)). The clearing network processes the transaction and the money is transferred to the merchant's account.

Step 10. Notification. The payment server notifies the merchant of the success of the transaction. The notification can also be done asynchronously.

Step 11. Delivery request. The wallet server provides the merchant with the delivery address. This step can be carried out at other points in the message sequence, e.g. before payment or later, asynchronously.

Many messages can carry elements similar to authorization. For example, in the case of a SET capture request, the SET gateway checks the Signature of the cardholder. Current payment systems may also omit some of these messages, or the way certain information is processed may vary, for example, the buyer notification may be returned to the merchant or, in some cases, omitted entirely. The steps can also be intertwined or further split.

protocol

The protocol includes various sub-protocols. Each sub-protocol has its own defined scope with clear boundaries to other sub-protocols.

In an exemplary embodiment, a sub-protocol is referred to as the interoperable mobile payment protocol (IMPP) and is used for messages between and via the wallet server OpCo and the payment server protocol. The other sub-protocol is the open payment protocol for the exchange of information between the payment server and the merchant system.

The IMPP determines the communication between the following components through the OpCo domain.

Wallet server OpCo payment server merchant system

An exemplary embodiment of the IMPP is described in a model shown in FIG. 3. The IMPP introduces a central instance for forwarding messages and other payment-related processing, which are sometimes referred to here as the OpCo domain. The OpCo keeps the central offer data and in certain scenarios finds out the customer's wallet server during the payment initiation. Furthermore, the OpCo (via the CPP) provides the forwarding of payment reports in both directions between a wallet server and a payment server. Referring to Figure 3, the wallet server contains core customer data that is primary to authorization and payment, as well as a transaction history.

The wallet server is driven during the payment initiation phase (triggered) and subsequently sends payment messages to the Bezahlungsser _^ ver on the OpCo. The wallet server is notified by the OpCo when the status of a payment transaction has changed and can query the status of a particular transaction to update the transaction history.

The payment server keeps the merchant core data for the payment and the transaction history. The payment server also receives payment reports from the OpCo and processes the reports. In particular, the payment server sends messages to the authorized person on the part of the acquirer and triggers result notifications to the OpCo and the dealer system. The payment server sends and receives the required information to / from the merchant system during the various phases of the payment process.

The term “merchant system” relates to a purchasing system and payment plug (p! Ug-in) components, which are provided on the local domain of a 3D system II-compliant payment system of the merchant. The merchant system sends and receives the required information to / from the payment server during the various phases of the payment process. The merchant system provides a local technical indication of the payment system in the merchant's purchasing system, often supplemented by a shopping plug-in.

A description of the method or protocol which is used in connection with the messages between the wallet server and the payment server in connection with a transaction follows, as shown in FIG. 3. Step 1. Shopping. A customer searches (buys) goods / services and an order is stored in the retailer's purchasing system.

Step 2 and 3. Initialize the offer context. At the end of the purchase, the customer clicks on a reference in the shop, which triggers the sending of the offer context from the purchasing system to the payment server. The request is forwarded to the OpCo by the payment server. The offer context is saved and the related OfferlD is sent back to the payment server and the merchant system in the response. The offer context includes information which indicates whether an age check should be carried out and whether a delivery address is required by the dealer.

Step 4. View the OfferlD. The buyer is either shown the OfferID to continue the interaction via the (different) payment channel, or the buyer is forwarded to his wallet server via the OpCo (with the same payment channel, not shown). Finding the wallet / payment server URL is done within OpCo and URL if necessary. The URL is not required if the wallet server does not need the payment server address. With the IMPP, the payment channel can be different from the purchasing channel. Sufficient information is provided to the buyer to identify the order and to enable the CPP to generate a payment call.

Step 5. Enter the OfferlD. The buyer is asked to enter the OfferID received from the store in their wallet. The buyer is identified and authorized on the wallet server by the MSISDN of the buyer's cell phone in the payment channel.

Step 6. Payment call. The wallet server forwards the OfferlD to the OpCo and receives the payment request information back. This includes whether an age check should be carried out and whether a delivery address is required from the dealer. The buyer is authorized and receives access to his data. Step 7. Submit the offer. The wallet server looks up the order information (e.g. order description, final payment amount).

Step 8. The data is forwarded by the OpCo to the associated payment server.

Step 9. The payment server queries order details from the merchant. The merchant system also returns the accepted payment methods. The wallet server then shows the customer the final order data. The message exchange takes place through the OpCo, but not directly to the dealer as in the 3D model. The wallet server therefore does not need to know the retailer's network address. The wallet server also forwards the delivery address to the merchant to recalculate the final payment amount and the result of an age check that may be desired by the merchant. The wallet server receives the order details and the accepted payment methods. The means of payment to be used are selected and declared valid.

Step 10. Select the payment method. The wallet server represents a list of available payment methods / means, from which the customer can choose, based on the list of accepted payment methods of the merchant and stored means of payment of the customer.

Step 11. Pre-authorization. The wallet server contacts the authorizing officer on the publisher's side to check whether the selected means of payment are valid, to carry out limit checks and to pre-authorize payment in the case of a new company scheme that conforms to interoperable micropayments.

Steps 12 and 13. Authorize payment. The wallet server sends a payment request to the OpCo on behalf of the customer. This can include the result of pre-authorization in the case of schema-compliant micropayments. The OpCo forwards the request to the associated payment server. The payment server receives all the data required to process the payment. Step 14. Cross-check the offer. The payment server connects to the merchant's purchasing system to check whether the order data received from the wallet server is authentic.

Step 15. Eligibility. The wallet server forwards the payment data in the case of macro payments to the payment authorized person on the part of the acquirer or checks the result of the pre-authorization in the case of schema-compliant micro payments. Both steps 11 or 16 are carried out mutually exclusive in order to authorize payment by OpCo. The clearing network processes the transaction.

Step 16. Billing. The payment officer on the part of the acquirer makes the physical payment, i.e. processes the request in the financial end components (financial back-ends). Equalization can be carried out asynchronously (e.g. in batches). The wallet server notifies the merchant of the success of the transaction. Such notification can also take place asynchronously. The trader therefore knows whether the payment was successful and is able to start delivering the goods.

Step 17. Delivery. The result of the payment is displayed to the customer. Once the ongoing payment is complete, the customer can continue to interact with the store. A payment slip is typically important for the customer, especially to start accessing the digital content immediately after payment. The goods are delivered in the shopping channel or asynchronously. The wallet server receives a payment receipt on behalf of the buyer.

Step 18 through 19. Capture. Depending on the payment system on the part of the acquirer, deferred or split amounts can be recorded and the payment is (partially) refunded or a credit is given asynchronously by the dealer. This action can be triggered by retailers in the purchasing systems and is forwarded to the payment server. The payment request is sent by the payment server to the authorized payment officer forwarded on the part of the acquirer. The money is booked to the dealer and transferred after settlement.

Steps 20 through 23. Status notifications and request status.

Referring now to Figure 4, the OPP manages the exchange of information between the wallet server, the merchant system and the payment server. The IMPP manages the communication between these components and the OpCo domain. The OPP specifies additional messages for information exchange via IMPP and the OPP manages the information exchange via the OpCo domain, which depends on the specific purchase and a payment channel or a combination of both. The OPP depends in part on the supported payment and purchasing scenario. The OPP determines the exchange of information between the components involved via the OpCo domain by using the IMPP. The OPP does not manage communication within the publisher and acquirer domains. The OPP message flow is described in the "Payment initiation" phase and the "Post-payment" phase of the 3D model.

The "initiation of payment" phase of the model describes the location of the wallet server and the wake-up message. The "postpay" phase describes the notification and delivery process. The OPP does not manage the communication between the customer and the dealer system, since this communication is determined by the dealer or the purchasing system. The OPP hides the payment, the shopping and scenario-specific data so that the underlying IMPP does not have to take this data into account.

The OPP uses the underlying protocol to exchange messages between the wallet server and the payment server. This means that the wallet server and the payment server do not support direct network communication. All communication between the wallet server and the payment server is managed by the same IMPP, which manages the entire communication between the three components wallet server, process platform and payment server. Therefore, message pairs must be encapsulated by the OPP in additional messages in order to use the to transfer the underlying sub-protocol. Two new pairs of messages are required for the exchange server (WS Transfer (WSTransfer)) and the payment server (PS Transfer (PSTransfer)). The message pairs are described below.

Wake-up call request and response message: The wake-up call request is issued by the merchant system in order to initiate a wallet attempt in certain payment scenarios. This request is sent to the processor platform, which initiates payment through the customer's corresponding home wallet server. The wake-up call process depends on the combination of the purchasing and payment channels.

Delivery request and response message: The delivery request is submitted by the wallet server in order to inform the merchant system of a completed payment transaction. The dealer system can use this notification to initiate the delivery process. The delivery process depends on the payment and purchasing scenario.

Resume Request and Response Message: The Resume Request is issued by the Wallet Server to complete an interrupted delivery of online content.

The IMPP manages the payment-specific communication between the wallet server, the dealer system of the processor platform and the payment server. The OPP manages the exchange of information via the OpCo domain, which depends on a special purchasing and payment channel or a combination of both. The IMPP is independent of the supported payment and purchasing scenario.

The IMPP performs the following functions: It provides a brand transfer between customer and dealer, recalculation of amounts through the dealer system; it provides job information exchange; it provides age testing skills; it provides address exchange with and without payment; it provides an extension mechanism for the exchange of additional information in the defined message flow. supply; it provides payment entitlements including "capture now" facilities for macro and micro payments; it provides an OfferlD administration; and it provides an extension mechanism for the exchange of additional messages through the CPP. The integration and communication between a customer and the customer

Wallet server and between a merchant and the payment server is independent of the IMPP. The IMPP takes no account of the combination of different purchasing and payment channels. Problems resulting from the combination of different purchasing and payment channels are managed by the OPP part of the protocol stack. The IMPP provides a protocol layer to manage global communication between wallet servers and payment servers through a single processor platform.

The OPP and IMPP take account of payment, purchasing, customers, dealers or telco-specific requirements. The IMPP provides a mechanism for the transmission of messages from higher protocol layers via the CPP. Different wallet servers or payment server providers are able to extend the function to a higher protocol layer without direct communication between the wallet server and payment server outside the IMPP. Providers of wallet servers or payment servers implement the IMPP for communication via the CPP.

The IMPP processes messages between all components involved via the OpCo domain. It does not cover communication within the publisher or the domain of the acquirer. The IMPP processes the message flows described in the "order exchange" phase and "payment" phases of an SD payment phase model.

IMPP reports are classified according to different areas. In particular, all message pairs in a payment area are interpreted as OpCo. Typically, these messages are issued by the wallet server to perform a payment transaction. The OpCo receives the message and interprets its content for transaction logging or fee management. Usually, the messages to the payment forwarded for special processing. The corresponding message response is sent to the wallet server via the CPP. In some special scenarios, the CPP picks up the incoming request and sends a response back to the wallet server. The CPP interprets all messages within this area. Other areas include an extension area, a notification area and an offer area.

Figure 5 shows IMPP messages and each message type would be explained below.

In particular, the PayPurchase request is submitted by the wallet server in order to initiate a purchase via IMPP. This request is sent to the payment server via the CPP. The CPP acts as a proxy for this pair of messages.

The Paylnquire request is given by the wallet server to initiate a request via IMPP. This request is sent to the payment server via the CPP. The CPP acts as a proxy for this pair of messages.

The PayStateUpdate request is submitted by the payment server to update the transaction status on the wallet server. This request is sent to the wallet server via the CPP.

The WSTransfer request is submitted by the wallet server to initiate a transfer of additional information via IMPP. This request is sent to the payment server via the CPP. The CPP acts as a proxy for this pair of messages. The WSTransfer message pair can be used to transfer messages from a higher protocol layer via IMPP. The content of this pair of messages is processed as an anonymous date by the CPP.

The PSTransfer request is issued by the wallet server to initiate a transfer of additional information via IMPP. This request is sent to the payment server via the CPP. The CPP acts as a proxy for this pair of messages. This PSTransfer message pair can be used to transfer messages from a higher protocol layer via IMPP. The content of this pair of messages is processed as an anonymous date by the CPP. The WSNotify request is made by the wallet server to notify the CPP of additional information. The CPP processes the request and replies with an appropriate response. For example, this request is used to inform the CPP about the interruption of the message flow by the customer. In this way, the CPP is able to handle the situation within the CPP, for example deleting the dynamic OfferlD in the context repository.

The PSNotify request is made by the payment server to notify the CPP of additional information. The CPP processes the request and replies with an appropriate response. For example, this request is used to inform the CPP of an interruption in the message flow.

The OfferCreateContext request is submitted by the payment server to create a new OfferlD in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.

The OfferDestroyContext request is submitted by the payment server to delete an OfferID entry in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.

The OfferModifyContext request is given by the payment server to change an OfferID entry in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.

FIG. 6 shows a valid message sequence for the protocol. FIG. 7 shows an OfferID message sequence. The currency conversion is on the side of the Wallet servers performed. FIG. 8 shows a WAP-WAP micro payment sequence. In FIG. 8 there are two redirects, in particular a redirection to the CPP, which was initiated by the trader, and one to the home wallet server, which is initiated by the CPP was initiated. FIG. 9 shows a WAP-WAP address transmission without a payment sequence and FIG. 10 shows a vending machine macro payment sequence. FIG. 11 shows a static OfferID generation sequence.

The OfferlD has the following status.

Start status (SS (Start State)):

Registered State (RS):

Generated Static State (CSS):

Generated Dynamic State (CDS):

Disabled State (DS):

The following actions can be taken to change the OfferlD status.

Register (R):

Do not register (UR (Unregister)):

Create static (CS):

Dynamic creation (CD (Create dynamic)):

Change (M (Modify)):

Delete (D (Destroy)):

Enable (EA):

Deactivate (DA): The dynamic transaction models for macro payment have in common that the owner of the transaction status is the payment server. In the status model shown in FIG. 12, the transaction states and transitions are used for an immediate macro payment, often referred to as “sales” transactions. No separate step to finance the payment is carried out on the part of the dealer / acquirer.

The status model shown in FIG. 13 describes the transaction states and transitions which are used for a macro payment credit. It is used by traders to issue a credit on a macro cash. This is done by merchants to refund payment after the actual transaction has been cleared.

The status model shown in FIG. 14 describes the transaction states and transitions which are used when the macro payment is delayed. This is used when the merchant makes an authorized payment with some delay, e.g. when the goods are shipped. If only partial dispatch is possible, the partial entry can be used once or continuously. The customer can track the detailed payment status in his wallet. One state machine is provided for the life of the initial transaction and another state machine is provided for the life of partial transactions.

FIG. 15 represents a status model for partial macro payment. A partial macro payment transaction has its own lifespan and the buyer's wallet is notified of all events relevant to partial payment.

canceled Notify: WSNotifyReqO Notify: PSNotifyReqO Set: internal triggered

Ackn .: WSNotifyRes () Ackn .: PSNotifyRes ()

The dynamic micro-payment transaction models have in common that the owner of the transaction status is the wallet server, due to the fact that the customer's billing system maintains payment until billing.

Figure 16 illustrates the status model for the transaction states and transitions which are used for immediate micropayment, e.g. a low value transaction is used, which was initiated at a vending machine.

Figure 17 illustrates a status model for the transaction states and transitions used in delayed micropayments. This is used if the trader only partially or several times with an authorized schema-compliant micropayment with very low entry amounts ("Sofort (Instant)" payment, eg "Pay per time" or "Pay per extent (pay per volume) "transactions).

Figure 18 illustrates a status model for transaction states and transitions, which is used to execute a micro-payment credit. This is used by merchants to transfer a credit to a customer microbe payment medium. Merchants need this to refund payment after the actual transaction has been cleared.

The IMPP message structure consists of a two-layer structure, namely a message wrapper and (an HTTP request or response) and a message (an XML unit (entity)). An IMPP message is processed synchronously and has an XML message element (request / response pair), which is contained in the corresponding HTTP request and response (wrapped). This request / response pair represents a complete protocol conversation unit. If an IMPP message is simply forwarded to another unit by a specific technical function, only the message envelope is processed by the forwarding unit. The message itself can remain unprocessed in order to avoid additional processing above XML syntax analysis (parsing) and writing (writing).

The message envelope depends on the protocol used

Is HTTP / 1.0. As a result, the transport wrapper is a valid one HTTP / 1.0 request header / response header according to RFC822. The HTTP request procedure (verb) used is POST.

inquiry

answer

Figure 19 shows an IMPP message structure. The request and the response to a message are both shown as a serialized XML structure. The XML basic element (root element) <ImppMessage> contains an XML 'element only' element <Header> and exactly one request or response XML 'element only' element. The <Header> element contains the sub-elements Id (for message idepotency) and version.

Document type agreement Element definition <! ELEMENT ImppMessage (Header, (...))> Element definition <! ELEMENT Header (id, Version)>

A generic example message is the following: <ImppMessage>

</Header> <PayPurchaseRequest>

<! -...-->

</PayPurchaseRequest> </ImppMessage>.

As a result of the message structure, a connection that has been established can be reused after the exchange of a complete protocol conversion unit in order to exclude a TCP connect / accept / close overhead and to increase the efficiency. The HTTP keep-alive protocol is used to coordinate the technical functions involved at the application level. A connection that has already been established can be reused in the same direction, i.e. within the same client / server role allocation.

The applications of the wallet server and payment server process recognition (non-repudiation). Either corresponding attributes in the protocol elements or extended elements / attributes can be used. The VPN processes the encryption of all communication between wallet servers and OpCo as well as between payment servers and OpCo. The VPN only establishes connections between two parties that have successfully mutually authorized. The sending of application data requires the authorization process to be ended.

The protocol also specifies a version negotiation mechanism between the technical functions, but is independent of the specific version compatibility rules applied. The protocol includes sending the protocol version used in the message header.

Only one version is used in a log message sequence. The version agreement flow is symmetrical and it does not matter whether the wallet server, the payment server or the OpCo itself initiates a consequence. tet. A corresponding error code is also set to indicate a version incompatibility. If the OpCo cannot forward a message to the recipient as a result of a version mismatch, this is treated as a technical error.

The version agreement process is shown in FIG. 20 and described further below.

Step 1. A payment component sends an IMPP request to the OpCo using the highest IMPP version that is supported by the sender.

Step 2. The OpCo checks the version and processes the result.

Step 3. a) Check OK: The request is forwarded to the recipient.

b) Check not OK: The OpCo sends back an error message containing the IMPP versions supported by the OpCo.

c) Resending: The payment component sends the IMPP request again using the highest common version or stops with an error.

Step 4. The payment component checks the version and processes the result.

Step 5. a) Check OK: The answer is sent back to the OpCo.

b) Check not OK: An error message is sent back to the OpCo, which contains the IMPP versions supported by the recipient.

Step 6. a) The OpCo creates an average between own and by versions supported by the recipient and sends cisa error messages back to the sender, which contains this information.

b) The OpCo sends the normal response back to the sender.

From the perspective of an IMPP participant, IMPP flows occur in pairs. Every message sent by a requesting participant is replied to by a responding participant. The flow of errors (in contrast to other flows) is determined with regard to the inquirer and respondent, since this is used when the respondent cannot reliably identify the incoming message. An error indicates that a respondent rejects a message because of a format error or content verification tests have failed. The responder sends an error (rather a negative response code) if the responder cannot trust any of the fields in the incoming message. Typically, an error is used to respond directly to the sender of a message if it is not possible to clearly limit the error to an incorrect value of a field. The error message is not used to display normal business results such as a denied authorization. Business results are displayed using explicit codes in standardized response messages.

Errors in the IMPP system can result from a number of different sources. For example, IMPP messages may be grammatically determinable (parseable) but malformed by not following the protocol requirements, values may be incorrect, or messages may be corrupted, usually as a result of transmission errors.

With regard to duplicate messages, enough information appears in the plain text of the message cover so that it can be found out whether a message is a retransmission or not. The response of the recipient to a double Message depends on the indemotency property (described in detail below) of the message type, the number of doubled messages, the source of the double messages and the observed frequency between subsequent double messages. If a system is suspected of being exposed to flooding or ad fraud, duplicate messages can be ignored.

A damaged message is a message that cannot be parsed. Typically, a possibly corrupted message should not be received because the message transport mechanisms cause corrupted data to be returned. However, if a damaged message is received, a corresponding error message is returned, which indicates that a damaged message has been received and provides a request / response pair identifier of the message if it is available. It is accepted to ignore the message completely if insufficient data has been extracted to be able to respond to it. With regard to malformed messages, a corresponding error message is returned by the sender if a message can be determined grammatically but is otherwise incorrect due to values outside of a range or inconsistent options.

An application does not generate an error message in response to another error message. All IMPP components send an error message if a low-level processing error occurs on an IMPP response avoidance. Any message that is not recognized as an IMPP message is ignored. The IMPP components usually avoid sending error messages on the same channel as request messages.

The following fields are set for errors.

ErrorCode: Numbered code that defines the error condition. ErrorDescription: A free description of the cause of the error. ErrorObjectID: The object identifier of an unsupported critical extension that triggered the error. ErrorMessage: The message that generated the error.

The IMPP protocol is based on request / response pairs throughout the protocol. The error message does not conform to this paradigm because it can be an answer to either a request or an answer. The former case is not a problem. In the later case, however, difficulties can arise if the underlying transport is based on a request / response paradigm, as in a World Wide Web browser. In this case, the error message can be sent as a request message and the protocol will not request a response message (the underlying protocol can be time out). User permission may be required for an error message sent as a result of the operational limitations of a World Wide Web browser.

The HTTP message header contains a status code which indicates the processing status of the corresponding message unit as a whole. Each business error is indicated by the components regardless of the notification status. The following status codes are defined as a specific message, which the 5xx status code areas of the HTTP standard use to display application-specific errors.

In the case of a status code other than 200, the XML body of the HTTP response is omitted. In addition, the application-independent status codes as defined by HTTP are used for all HTTP-specific outputs (eg 400 bad requests).

If an operation can be performed any number of times without causing damage, it is said to be idempotent. From the perspective of the IMPP, idempotency is a property of how a recipient replies to a message. Every request in the IMPP that does not receive a response is sent again because the sender does not know whether the request or response was lost. The transmitted message is bitwise identical to the original request message. Usually a double message is not an error condition.

The IMPP protocol works in environments where reporting is not guaranteed. If an IMPP application does not receive a response in a reasonable amount of time (determined by the application or possibly in response to a user question), it sends the message again. If the received IMPP application determines that it has previously processed the same message, it retrieves the previous response and sends the previous response again. If the sender of a message does not receive the response, it is usually not possible to determine whether the request or response has been lost. To further complicate this condition, the original request may simply have been delayed anywhere in the network and then possibly processed shortly before the retransmitted request arrives. Therefore, the protocol allows the sender to repeat the request with the guarantee that the result will be the same regardless of whether the request or response was lost. Not all IMPP reports require Idempotency. The IMPP contains messages that are designed so that they can be sent at any time, so that it is not necessary for a recipient to save every request to determine whether a duplicate has been received. The IMPP products guarantee the identity of the protocol by checking a transaction ID and generating a time stamp in the message header. For example, a payment server refuses attempts to repeat pay authorization requests from a wallet server. The payment server recognizes these attempts by checking the message header of the Authorization request. If an IMPP component detects that it is exposed to malicious flooding or adware attacks that involve no or more idempotent IMPP message types, it is not necessary to respond to these messages in this situation.

The IMPP component can use any method to identify idempotent requests. One possible method is to store the SHA-1 hash of the message header for all messages. If a duplicate is recognized, the hash of the message header can be generated and used to look up a stored Idempot entry. In this approach, the IMPP component must keep a full copy of every incoming request, but can produce a bit-by-bit identical response. A bit-wise response is generated here as a new response with the same information. If multiple responses to an idempotent request are received, the recipient can ignore all such responses after the first.

An IMPP component is not required to respond to messages if it detects that it is exposed to malicious flood or adware attacks that involve one or more types of IMPP messages. The IMPP components can build their own criteria for detecting such attacks.

In the following, description or similar scenarios, which include idempotent message flows, are dealt with. These scenarios describe two transmissions of the same request, but depending on the conditions at the time of failure, the request can be repeated several times. Combinations of these scenarios are also possible. Delayed request or response: An idempotent request is sent, but delivery of either the request or response is delayed, so the recipient does not receive a timely response. The request is retransmitted, the received IMPP component processes the first request and retransmits the response when it receives the second response. Lost requests: An idempotent request is sent, but the report is not submitted due to a network failure. The request will be transmitted again.

Lost answer: An idempotent request is sent and answered, but the answer is not given due to a network failure. The request will be transmitted again. The received IMPP component processes the first request and then retransmits the response when it receives a second request.

It is necessary to provide a mechanism that extends IMPP payment reports. Since there is no space in the IMPP message to accommodate this information, a protocol extension is used. The mechanism used to extend IMPP messages is the same as how X.509 certificates are extended. In particular, an extension field is made available which contains a sequence of extension data. The extension data indicate the type of extension and the criticality of the extension.

An extension has three components. In particular, an object identifier that uniquely identifies the extension. This identifier allows IMPP components to recognize an extension and to process data. A criticality indicator indicates whether the recipient understands the extension to process the message that contains the extension. The data provide the additional business information, which makes it necessary to define the extension. The interpretation of the data is determined by the organization that created the extension.

The criticality indicator is a boolean value. An extension is considered critical if this value is True. Otherwise the extension is classified as uncritical. The default value is False. If an extension is critical, recipients of the report recognize and process the extension. If an extension is not critical, recipients who cannot process the extension can safely ignore the data. A set of information objects was created for each data structure, which can contain an extension. These records define the extensions that are allowed in the data structure for processing.

IMPP applications fall into one of two categories. In particular, in an application that does not support message extensions and in an application that supports some selected sets of message extensions. An IMPP component that does not support message extensions detects the presence of an extension in a message and checks the criticality indicator. If the extension is critical, the IMPP component does not process the message and rejects it with an error code unrecognizedExtension. If the extension is not critical, the application can ignore the data in the extension and process the rest of the message. An application that supports message extensions detects the presence of an extension in a message and processes the extension as follows.

1. If the application supports the object identifier for this message, the data is processed in the enhancement.

2. If the application does not support the object identifier for this avoidance and the extension is critical, the application does not process the message and rejects it with an unrecognizedExtension error code.

3. If the application does not support the object identifier for this message and the extension is not critical, the application can ignore the data in the extension and process the rest of the message.

The OpCo is the ultimate decision-making body as to whether a given data element is encrypted within a message. The OpCo can do that

Refuse to use any extension that contains data that may affect the integrity of the IMPP. Each extension is identified by its extension name, owner name, and a unique extension identifier. An IMPP component can decide to add a critical extension to carry additional information in the normal IMPP message flow to use. If the receiving IMPP component does not understand the data without the extension and therefore cannot process it, the message should be rejected.

With regard to transactions, transaction management is distributed, i.e. a wallet server and payment server involved in a transaction communicate using IMPP messages. Both servers contain a status mechanism, e.g. Waiting for replies, checking for interruptions (time-out) and sending query and recovery messages in the event of errors. The CPP also maintains status information because IMPP messages are forwarded by the CPP. The "owner" of a transaction is the party responsible for the primary status transitions during the life of a particular transaction. The synchronization mechanism used depends on the technical ownership of the transaction. There are different possible ownerships for different payment models supported by IMPP, as described below.

The IMPP provides the corresponding messages or message sequences to support the payment model. There are at least two different ways to synchronize transactions using IMPP.

1. Notify: the distribution of information about a status transition is carried out by the owner of the transaction. 2. Synchronize: The distribution of information about a status transition is triggered by a remote participant of the transaction.

Notify / Confirm is available if it is supported in the corresponding protocol flow. If available, only one notification is made per transition. As a result, unacknowledged notifications from the owner are not considered. The synchronization is available for remote participants in order to query transitions to a final status several times. The statuses and their transitions are described in detail from the protocol perspective, which means an abstraction from the implementation in the payment components. If a component needs the "history" of a status, i.e. the transition that leads to a status, the component can instead maintain a 'composite state'. In addition, each payment component defines its own way to delete transactions, i.e. to convert a particular transaction from an ultimate business status to an ultimate technical status. This is done asynchronously and is not covered by IMPP protocol messages.

The transition phases are described below.

Bezahlunosverarbeitunq

A detailed description of processes performed by the exemplary embodiment of the CPP is provided below. In particular, the usual processing is described as well as the processing associated with OfferlDs, negative files, money conversion, transaction logging, micro-payment settlement and billing and fee management.

For mobile payments, all inquiries and answers are forwarded between the wallet server and the payment server instances. Other CPP components that perform centralized tasks, such as the OfferID generator, the search (look-up) service and the FX server, are used by the forwarding engine to support the payment process. Transaction log entries are created to meet legal requirements and to enable decoupled (offline) mode processes such as billing. Address change inquiries, age verification inquiries and inquiries about changing the means of payment are also supported together with regular payment inquiries. Quality marks are transmitted together with these inquiries / answers and indicate the level of quality of the underlying data.

The forwarding engine receives external notifications of macro payment entitlements and acquisitions, completes the transaction logs and status change exchange notifications between the other involved parties to keep WS, MS and CPP transaction logs consistent.

With the micro payments, the authorization between WI and the provider of the micro payment means is carried out. Therefore, authorization tokens are transferred to the payment server with the payment message flow. For Transactions which are currently taking place are maintained by the forwarding machine transaction records in which all information about a transaction is stored together with a unique TransactionID (TX_ID).

In redirection scenarios, the redirection engine provides a redirection component which processes redirects ¹ in which the customer's browser moves from the merchant URL to his or her home wallet URL via a CPP URL and directly back to the merchant URL is redirected after the transaction is completed. The redirection component provides a central redirection URL, which traders can usually use to display the OfferlD. In addition, the buyer can enter MSISDN / pseudonym / alias in a familiar environment to enable push-back or fall-back scenarios (if MSISDN cannot be recognized). In order to support forward scenarios, the redirection component forwards the buyer's pseudonym to the wallet server. The WS then triggers an IVR call (WAP) to the buyer. The redirection component should not be used for non-mobile customer authorization (web-web scenario), for example with a pseudonym PIN, because customer authorization is the responsibility of the wallet server.

In WAP-WAP scenarios, the redirect engine supports redirects, in which the customer's browser redirects from the merchant URL to his home wallet URL via an OpCo URL and directly back to the merchant URL after the transaction is completed is redirected. The CPP provides a central URL to display the OfferlD. Therefore, the retailer does not need to integrate the OfferlD display into the purchase flow. In addition, this URL provides input fields for MSISDN / pseudonym to initiate a start.

Transactions between dealers and customers belonging to the same company, eg MNO, are referred to as "among us (on-us)" transactions to which special rules can be applied. If 'among us' transactions are carried out between a wallet server and an MA server, which are operated by the same company in a country, these transactions can be processed without being forwarded by the OpCo. The CPP identifies a 'among us' scenario and returns an appropriate response to the WS. At the end of the authorization phase, the CPP is notified by the PS to remove the OfferlD and to save the 'among us' relationships between WS and PS instances (affects both variants). Each transaction by the CPP is checked to see if the type of transaction is 'under us', in which case the 'under us' flag is set within the transaction record (affects both variants). When a 'among us' transaction is recognized, the initiated payment flow is ended by sending the PS search information to the WS.

All requests originating from either the wallet server or payment server are logged together with the ID of the corresponding wallet server or payment server. The logging of 'among us' transactions is done in the same way as for schema transactions, but the 'under us' indicator is set.

The search service performs searches for the wallet server and payment server on request. Based on an OfferlD, the search service determines the corresponding payment server by searching the OfferlD repository. In the opposite direction, the home wallet server can be accessed by accessing the subscriber list.

The search for the PS and retailer involved in a transaction is based on the OfferlD or RangelD. By performing the search based on an OfferlD, the BasketlD is resolved and transferred to the MC together with the OID in order to request the shopping basket. The retailer then decides whether the OID or the BasketlD is used to identify the shopping basket. By performing the search based on a RangelD, the combination of RangelD and dealer catalog number is transferred to the MC in order to query the shopping basket.

The participant list contains all MSISDNs and pseudonyms of the buyer who is registered for mobile payment. The HeimgeldbörsenserverlD is also saved for each MSISDN / pseudonym. The MSISDNs / pseudonyms, which Before not being entered, the CPP can also reject the process early.

The wallet server instances use online inquiries or generate a flat file that contains all new or changed participants and transfer the file to the OpCo to update the participant list. Pseudonyms are generated on the WS in accordance with the alias generation rules (3 digits identify the WI, 8 digits as the buyer ID and a checksum number).

OfferlDs

The OfferlD server component of the CPP comprises the OfferlD generator, which generates an OfferlD on request, and the OfferlD repository, which saves generated OfferlDs together with additional data for search purposes and manages their lifespan. The OfferID numbering system ensures, depending on the number of OfferIDs used at a certain time, that the number of digits used can vary in order to always provide the smallest possible number. For some mobile payment scenarios, the size of the OfferlD is not critical at all (e.g. bank nodes). Depending on the requested service life, the following table shows the minimum length of an OID:

<= 1 hour shortest available (minimum 4 digits) 1 hour - 1 day [shortest available (minimum 4 digits)] + 2> 1 day [shortest available (minimum 4 digits)] + 4 diversion 16 digits

The length of the OfferlDs (table above) is configurable. Depending on the contract with a dealer, certain areas of OfferlDs can be reserved for a dealer. The dealer pays a usage fee for the area and can use any (catalog) number after the area code to map the ID for his offer. By using this mechanism, the dealer can reuse existing catalog numbers by simply adding up his specific dealer prefix. Checksum tests enable the wallet server to check an OfferlD immediately and to request additional user input without having to communicate with the CPP. The probability of accidentally identifying another active shopping basket by incorrectly entering an incorrect OfferID should be low enough to make the risk tolerable. At least a single wrong digit, additional / missing digits and mixed up digits can be recognized. The checksum digit is not available for RangelDs.

OfferlD / RangelD structure

Prefix n digit content Checksum prefix n digit RangelD M digit dealer content

The prefix (not necessarily a whole number) carries certain tax information, where it is important to call it up directly from the OfferlD without access to the OID repository. Usually there is no dealer ID that is encoded with the OID. The only exception concerns RangelDs, where the OID consists of an area code and a dealer-specific extension.

For installations in different regions, the CPP_ID is encoded in the OfferlD prefix to enable OID forwarding. The OfferlD generator generates OfferlDs on request. Static and dynamic OfferlDs can be generated. OfferlDs are issued once. Subsequent payment transactions can use the same offer for payment transactions (eg VM, TV purchase). Static OfferlDs are 'rented' by traders on a monthly or yearly basis. When the rental period expires, the OID switches to the 'black-out' status, from which the OID can be reactivated if the dealer continues the rental agreement. The trader must handle the parallel use of the static OID. OfferlDs identify a temporary offer with a certain lifespan and are used exclusively by a single customer. An offer is automatically deleted as soon as a transaction is ended or the maximum lifespan is exceeded. Bank node scenarios use, for example, a dynamic OfferlD with an extended lifespan. If a customer cancels a transaction after entering the OfferlD, the OID is not deleted. However, all OfferlDs can be explicitly deleted on request.

With regard to dynamic OfferlDs, an OfferlD is determined by the dealer upon request for dynamic OfferlDs. After the lifespan has expired, the status is set to 'lock (black-out)'. The maximum lifespan will be one month. OIDs cannot be reissued during the blocking period. The lockout period is configurable and depends on the lifespan of the OID:

completed 1 hour

0 to 10 minutes 1 hour 10 to 16 minutes 6 hours

1 hour to 24 hours 1 day 1 day to 7 days 1 week

1 week minus 4 weeks 2 weeks 1 month to 12 months 1 month

When requesting an OID, the merchant can set certain attributes to indicate the type of request (payment, age verification, address transfer, PI transfer of details). With an OID request, the retailer can issue a list of brands to support brand matching with PI detail transfers. The shopping basket can be connected to the offer.

To generate static OfferlDs, the OfferlD is determined by the dealer upon request for a static OfferlD. After the rental period has expired, the OfferlD status is switched to 'blocked'. The minimum rental period is 1 month. The rental period begins with the generation of the OID, not with activation. The request for a single OID can be made by the MC (same for dynamic OIDs). Because the shopping basket is transferred with the request, the static OID is automatically activated after the request. The trader can request batch generation of OfferIDs according to the CPP numbering scheme. This request is carried out by the dealer self-service and not directly by the dealer component. As a result, the dealer receives a file that contains all generated OIDs and the expiry date of the rental period.

With the RangelDs, the retailer has the opportunity to reuse existing catalog numbers with the mobile payment scheme. Upon request for a RangelD, the dealer specifies the number of sub-IDs that he wants to use. The dealer is identified during the search. The combination of RangelD and catalog number is forwarded to the retailer to receive the shopping basket.

The OfferlD repository contains all information about requested OfferlDs. If age checks, address exchange or PI data transfer is required, the relevant flags are set in the OfferlD repository record. The OfferlD repository monitors the issued OfferlDs and sets statuses to 'lock' as soon as an associated lifespan expires. The OfferlD repository also supports the manual deletion of inquiries. The search service uses the OfferlD repository to inquire about related payment servers.

In order to link the static OID with another basket or to change the request types, the OfferlD repository supports the deactivation of OIDs. The MC only allows deactivation for individual OIDs. This feature can also be used if an item is temporarily unavailable or the retailer wants to have an extended blocking period. The deactivation does not extend the rental period. If several OIDs have to be deactivated, the MSS is used.

The repository supports changing static OIDs (ie linking other BasketIDs, change request types or extending the rental period). The repository supports batch modification of static OIDs (ie linking of other BasketIDs, change request types or extension of the rental period). This request is carried out by the MSS.

A single OID can be activated. Multiple OIDs can also be activated by the MSS. In order to carry out such an activation, the dealer loads a list of BasketIDs together with all other request parameters. After the OID block has been generated, the dealer receives a location file.

The OfferlD repository automatically deletes OIDs when the lifespan expires or when a transaction is ended. A buyer's termination does not result in the OID being deleted. The OID repository also allows the deletion of OIDs in simple (single) and batch (batch) mode. With dynamic OIDs, deletion results in immediate removal, while with static OIDs, deletion sets the OID status to 'lock (black-out)'.

The MSS enables the trader to restore an OID with the status 'blocked'. Static OIDs must be blocked when the lease expires. During the blocking period, the dealer is able to reactivate the OID by asking the MSS to extend the rental period.

Neqativdateien

The negative file service provides a central and common (consolidated) database to block traders as well as customers. The wallet server and payment server instances can check against the database on the basis of a query, just as can synchronize their local negative file directories with the negative file service on the processor platform.

With the CPP, a single trader can be added to the negative file together with a time entry. In addition, the negative file can be checked to determine if a record exists for a single trader. A dealer-acquirer can trigger this check from outside. In addition, a single dealer can be removed from the negative file. A list of dealers can also be imported into a negative file. When a Dealer is already listed in the negative file, the associated data record is skipped. Merchant file records in the file can also be flagged for removal. These dealers are removed from the negative file during the import. A dealer negative file can also be exported. For example, a file can be downloaded (downloaded) or transferred to a dealer-acquirer to update a local negative file.

A single buyer can be added to the negative file along with a time entry in the record. The negative file can be checked to see if it contains a record of a single buyer. A purse issuer can trigger this check from outside. The CPP can also check every transaction against the internal negative file. A single buyer can be removed from the negative file. A list of buyers can also be imported into the negative file. If a buyer is already listed in the negative file, the associated data record of the file can be skipped. Buyer records in the file can also be flagged for removal. These buyers are removed from the negative file during the import. A file that contains all negative file records that have been generated after a certain time can be exported. This file can then be downloaded or transferred to a wallet issuer to update a local negative file.

All changes to the negative file are logged. The historical negative file data is saved and a status (e.g. entered (listed), blocked (blocked), inactive (inactive), deleted (deleted)) is retained. After a period (i.e. three years), deleted entries are physically removed from the negative file records.

currency translation

The system supports three different currencies: the currency on which the transaction is based; the registration currency of buyers at WI; and the currency that the MA settles with the CPP. For international micropayments, the amount of a transaction from the transaction currency to the WI settlement currency (domestic currency of the buyer) is calculated before the authorization of the Customers and deduction converted by the SVA. Since both currencies are displayed to the customer and the SVA is deducted based on the underlying exchange rate, there may be currency risks that are covered by additional exchange rates.

The OpCo contains a currency risk if a μPI is justified if the settlement with the MA cannot be carried out on the same day. In these cases, the OpCo can add a surcharge to the exchange rate.

The currency conversion table stores currency rates. A record is generated for each currency pair (EUR / GBP) and (GBP / EUR). The time stamp stores the information of the last update of the data record. Additional status information can be saved in the 'Status' field (e.g. expired). The currency conversion table is updated on a predetermined regular basis by contacting an exchange rate service provider and importing the updated exchange rates into the conversion tables. The timestamp and status are also updated.

The status field of the currency conversion table is set to 'expired' ¹ when the currency pair has been updated for a certain number of days (ie one day, configurable). Expired currency pairs have no influence on the currency conversion.

The conversion table can be exported to a file that can be downloaded by the wallet provider or the OpCo finance department. The courses include the OpCo surcharge. An example table is shown below.

Currency code dealer (ISO)

Currency code customer (ISO)

Format (decimal)

conversion factor

Timestamp status (current, expired) With regard to the spreadsheets, additional OpCo spreads are stored in an additional spreadsheet (ie a spreadsheet). A record is generated for each currency pair (EUR / GBP) and (GBP / EUR). The time stamp stores the information of the last update of the data record. Additional status information can be saved in the 'Status' field (eg expired). Administrators can update markup percentages for currency pairs by transferring a flat file to the FX server, which is then imported into the markup table. An example of a surcharge table is shown below:

Currency code dealer (ISO) Currency code customer (ISO) Surcharge percentage Surcharge amount

Typically, the CPP converts amounts based on exchange rates and CPP surcharge and transfers the amounts in TX currency, converted currency, and conversion rate. With this process, the exchange rate synchronization can be omitted because the most current exchange rate is used. Currency conversion is carried out in accordance with the rules of the European Central Bank (ECB European Central Bank)). When units of national currency are expressed in EUR, the amount includes six numbers before and / or after the decimal point. When converting the currencies into EUR, interim results are calculated to a minimum of 3 decimal places (after the decimal point). Currency amounts that are shown in EUR are rounded up or down to the nearest euro cent.

An interface to a provider of international currency conversion rates (i.e. Reuters, Bloomberg, Bridge or Telerate) has been introduced. The finance department of the WIs or OpCo's can download an exported exchange rate file.

Administrative facilities for OpCo administrators and the finance or securities department of OpCo are provided. This facility Examples include managing the process for getting exchange rates via the defined interface to the exchange rate provider, setting rules for updating the status, viewing and manual editing of exchange rates, viewing and manual editing of exchange rate surcharges and viewing the exchange log and historical data. In order to ensure that the responsible administrator is informed immediately, the administrator alerts certain event triggers. For example, the following event triggers trigger messages to the administrator:

Error: Import of currency rates failed. Error: Export of files failed. Warning: Exchange rate expired

Warning: Conversion carried out with the expired exchange rate according to the default

The administrator receives alarms as a message in the administrator GUI. In addition, he can choose to also receive alarms by email or SMS. The administrator uses the administrator service GUI to access detailed error lists / reports. Detailed error messages are not transmitted with a notification.

In addition, all changes in currency exchange rates are logged. Historical data is stored for legal purposes (10 years). For refunds, the FX is determined from the TX log and not from the historical data file. The transaction log serves as the basis for fee settlement and dispute settlement. Multiple log levels are supported on a per request basis. e.g .:

Log all events with all attributes

Log events only with key attributes Log events only Log errors only. The log files are stored for processing for up to three months. The transaction logs are then archived for 10 years. All operational processes comply with legal requirements, such as the Data Protection Act. A NewCo data protection strategy should be established and made binding for all NewCo participants in order to increase buyer confidence.

Micro-payment balancing and billing

The CPP Compensation and Billing (C8-S) service processes compensation requests initiated by dealer acquirers, collects amounts to be settled by the MA and settled with the μPI provider. Additional billing data records and information are generated in order to make billing details available to all μPI providers (WI and MAs). The transfer of funds is triggered on a general ledger system. For dealer acquirers, the clearing and billing service supports both single currency billing and multi-currency billing. With multi-currency billing, the MA is billed in different TX currencies. For each MA, the main data record shows all the accounting currencies of the MA and whether the MA was selected for single or multi-currency accounting.

The task of clearing and billing can be divided into the following steps, as shown in Figure 23 and described below:

1. Pre-processing (mediation and coordination)

2. Compensation with MA (collection regarding MA)

3. Compensation with μPI provider (collection regarding μPI provider)

4. Booking (initiation of settlement)

5. Rejection and return process (error processing) 6. Dispute processing

7. Deception detection

8. Administration

When a clearing record goes through the clearing and billing process, it assumes various states as shown in Figure 24. preprocessing (Mediation and coordination) is a linear process. Collecting PIs and MAs can be done in parallel. The result of the process is documented in a settlement report (including error codes) and a 'aggregation table', which is used for posting in the general ledger.

The dealer-acquirer initiates C-S by sending the compensation file containing the registration / authorization token to the CPP-C&S service. According to the clearing procedure, the C8ιS service reconciles the MA clearing file with the internally collected transaction logs. A settlement report is generated to inform the trader of all transactions that are being settled and of all rejected transactions.

A TX clearing data record contains the AcquisitionID, PaymentMediaD, TransactionID, amounts and the processing status as described below:

MA_ID μPI.ID TX_ID

Authorization time and date

Authorization (detection) token

Acquisition time and date

Transaction currency amount (in TX currency)

Buyer currency

Amount (in buyer currency)

FX rate

Indicator 'Receiving compensation file' + time stamp Indicator 'voting completed' + time stamp

Voting status (accepted / rejected), error code

Indicator 'collected regarding MA' + time stamp

Indicator 'collected with regard to PI' + time stamp

Indicator 'posted for MA settlement' + time stamp Indicator 'posted for PI settlement' + time stamp Indicator 'Report to MA' + time stamp Indicator 'Report to PI' + time stamp

Transaction data from the MAs are compared with the internal CPP-TX protocols belonging to the same time period for validation purposes. Data records that do not match are collected in an error file. The error file serves as the basis for error detection and the parts that are to be assigned to a special employee are copied into the employee's billing report. Four classes of matching results are possible.

TX match

TX incompatibility: incompatibility between data belonging to the same TX in the accounting file and in the EPP TX protocol.

Excess TX: The accounting file of the MA contains a record which has no counterpart in the EPP TX protocol.

Missing TX: The EPP TX protocol contains an entry that has a counterpart in the MA's accounting file. (The log record is marked with "missing TX" if a collection for compensation was not received within a certain time, e.g. a week; "garbage collection").

The compensation with the MA provider takes place according to the MA compensation process. Reconciled transaction records of the preprocessing procedure are collected for each merchant acquirer. The collection process leads to an MA billing report and provides the basis for the MA billing (aggregation table).

Transactions that are successfully reconciled are collected for each MA and each billing (transaction) currency. The collection table stores amounts that were collected over a certain accounting period. The format of the collection table is shown below:

MAID

Start of the accounting period (date and time) End of the accounting period (date and time) Table generation time stamp, accounting currency

Total number of transactions collected Absolute settlement amount (in TX currency) μPI_ID 1

Number of transactions for μPI 1 settlement amount for μPI 1 μPI_ID 2

Number of transactions for μPI 2 settlement amount for μPI 2

Indicator 'posted for MA billing' + time stamp Indicator 'reports to MA + time stamp

A separate collective table is calculated for each billing currency. The collective table forms the basis for the posting (instructions for billing) and part of the billing report is sent to the MA. The settlement report contains results of the reconciliation and collection steps (including error messages) with regard to a special dealer acquirer. According to the report process, the billing report is saved in the corresponding MA directory (probably daily).

The compensation with the μPI provider is done according to the PI compensation process.

Reconciled transaction records from the preprocessing procedure are collected for each payment method provider. The collection process leads to PI billing reports and provides the basis for the PI

Settlement (collective table) available. Reconciled records are collected for each PI. The collection table stores amounts that have been collected over a certain accounting period.

μPI_ID

Start of the accounting period (date and time)

End of the accounting period (date and time)

Table creation timestamp Total number of transactions collected Total settlement amount (in TX currency) indicator 'posted for PI settlement' + time stamp indicator 'reported to PI' + time stamp

The collective table is the basis for posting (initiation of settlement) and part of the settlement report is sent to the PI provider. The settlement report contains the results of the reconciliation and collection steps (including error messages) regarding a payment method provider. According to the reporting process, the accounting report is saved in the corresponding PI directory (probably daily). The CPP-C&S service triggers the G / L system to initiate the physical transfers of funds to the MA and from the μPI provider. The OpCo settles gross amounts with the PI provider (car payment). Fees are billed separately. The CPP scrolls through the PI collective table for PI posting and creates a flat file with posting data records (eg direct debit inquiries) for batch input to a G / L system (eg SAP FI) and sets the indicator for the associated log records and the collection table. When posting with the MA, the CPP scrolls through the MA collective table and creates a flat file with posting data records for batch input to a G / L system (e.g. SAP FI) and sets the indicator for the associated log data records and the collective table. In the event that MA requests a multi-currency settlement, a separate payment run is initiated for each settlement currency.

The G / L prints invoices and instructions and initiates transfers of funds. The transfer of funds can follow a different process than posting, for example, depending on the value to be settled. The reconciliation step identifies incorrect transactions which are stored in an error TX file. An attempt is made to correct errors manually. Results of this error correction step (eg 'corrected', 'rejected' ¹ ) are included in the corresponding MA billing report. Rejected data records are marked with error codes.

To detect insider deceptions, reports are generated to track the correct processing of billing-related data and to detect suspicious behavior (eg there ^* s Deleting collection tables, manual Buchun- gene, log file manipulation). At a later stage, intelligent deception detection algorithms can be used to update negative files, eg user profile checks: detection of unusual user behavior, suspicious increases in a user's turnover, payment location checks: checking whether payments came from distant locations within a short time.

A process mechanism triggers the switching, the coordination and MA and μPI compensation. Depending on a threshold for a minimum settlement amount, the booking step can be planned for each MA or μPI. The booking process and the threshold for the minimum settlement amount are stored in the main data record. The administrator monitors the correct process and manually triggers processing steps if this is necessary.

All mobile payment transactions are forwarded by the CPP, which results in a log entry in the log file. This log file is the basis for generating transaction fee invoices and reports. The resulting invoice reports are then posted in an account management system to initiate settlement. Various events such as an OfferlD request, authorization at the PI or registration are charged with various fees. The dealer acquirer charges the dealer with a mobile dealer service fee (mobile MSC). The mobile MSC minus an MA fee is claimed by the CPP and distributed further among the shareholders. Figure 25 shows the distribution of fees.

A batch process (e.g. daily, weekly, monthly) is carried out for billing transaction fees, since the number of transactions can be very high, i.e. in the range of several million a day. The task of fee processing can be split into the following steps, as shown in FIG. 26.

1. Mediation

2. Assessment 3. Invoicing 4. Reports (export files containing invoice details)

5. Posting (initiating accounts, issuing instructions / displaying invoices)

6. Rejection and return processes (error handling) 7. Dispute handling

8. Deception detection

9. Administration

At each step, data is kept in a special inventory and is referred to as "complete (piain)", "mediated", "assessed (rated)" or "billed". The rating catalog contains event definitions and pricing / rating information. Rules for special fees (e.g. monthly fee) and discounts are stored in the calculation catalog. Stored procedures define processing and billing periods and trigger the various processing steps. The invoice detail repository contains the cleared events and forms the basis for detailed reports such as EPA (electronic payment advice). Invoices are sent to the G / L to initiate billing (payment run).

A mediation module keeps track of the log files that are received from various log file sources. The main source is the daily log files from the processor platform routing module. Other sources include data that could not yet be processed, e.g. corrected records from the rejected and returned processes. The data is filtered and possibly reformatted.

The term "rating" means to assign a price to each event. A valuation table is used to set the prices for each event class. The evaluation table is generated before the evaluation process is started and remains unchanged during at least one billing period. An individual evaluation table can be used for each invoice or instruction recipient, depending on the individual business agreements between OpCo, NewCo, the MAs, PI providers and the WIs.

The fee structure is designed in such a way that it is generally sufficient to cover all fees that usually occur in transaction invoicing. Transaction pricing may depend on the actual number of transactions and the average value of the merchant or merchant acquisition payment transactions. A general approach to covering such a fee structure is to use a price table in matrix form.

Parameters that determine the price table are:

Event type (OfferlD request, address verification, recording, etc.) payment channel (WAP, IVR, SMS)

Shopping channel (web, WAP, IVR, TV, vending machine, etc.) Payment instrument (μPI, Visa, MasterCard, direct debit, etc.) Regional class (customer and retailer in the same / in different regions): among us (internal operator (intra-operator )), At home (domestic (national)), intra-regional (e.g. America, EMEA, ASPA), supra-regional risk class of the retailer / trader

The settlement currency (a separate price table for each currency can be used if an MA has been selected for multi-currency settlement).

Events that are evaluated include:

Static / dynamic generation of OfferlD (allocateOfferlD, initOfferlD)

Information requests (adressREQ, agecheckREQ, PIDetailREQ) payment authorization (AuthorizePaymentRequest)

Micropayment acquisition

Micropayment refund

Micropayment credit

IMPP expansion messages (volume-related, for example per message or per kilobyte) Other central services (tbd.) (Initiation of payment, ie PayPurchase request) (currency conversion) (WS and PS search) (error messages)

The billing process gathers all rated events related to an account (receivable or payable) in a single billing record. Recurring participation fees or special fees are added up and discounts are deducted. Special fees and discounts may vary for each instruction recipient. The evaluated events are compiled by invoice (receivable accounts / affordable accounts) and the fees are collected. A valued event that contains multiple sub-fees is part of multiple invoices. Discounts or other fees (e.g. participation fees) are added to each invoice. The invoices contain the total amount to be calculated (credited or collected).

The invoice detail reports contain the data records that are used to calculate an invoice for a special recipient. The files of the invoice detail reports are sent to the participant on request. The invoice instructions contain collected items in an invoice. Formatting and issuing instructions is subject to the general booking system.

The booking initiates the collection of charges and the distribution via the main booking system. Invoices are marked "booked" as soon as the booking has been initiated. At the end of the billing cycle, all invoices are transferred to the general ledger (payment run).

As soon as invoice details are marked "delivered" or invoices are marked "booked", the data is archived in a mass storage device. Archived transaction logs and invoice files form the basis for the settlement of disputes. The CPP provides an access interface to the logged transaction details and invoice details for the disputed managing authority available, such as a customer care center. Disputes regarding the collection and distribution of fees (transfers of funds) are managed by downstream services (back office). Deception detection reports should also be generated in order to track the correct processing of invoice-related data and to find suspicious behavior (eg deletion of invoice files, manual postings, manipulation of log files).

The Securities Department uses a General Ledger (G / L) system to manage fee collection and distribution bookings and micropayments. The clearing and billing service and the billing machine initiate bookings on the G / L system. Bookings can be made to reception customers and payment customers of OpCo, NewCo, all WIs, PI providers and MAs. Recurring bookings are made for each micro-payment billing cycle and for each billing period (daily, weekly or monthly). Instructions are printed for each booking (micro-booking billing or billing) and sent to each recipient. Physical transfers of funds to / from MA, to / from WI and to NewCo bank accounts are initiated. Micropayments with MAs should not be done until the μPIs receive payment. Irregularities in the flow of funds are tracked and reported, and calls are generated automatically when funds transfers are late. The G / L operator can request reports on cash flow and pending cash transfers (for cash management). In the event of incorrect postings, retransmissions can be be initiated manually due to incorrect fee calculations.

All operational activities are logged (in order to make independent invoice verification and deception detection possible). Information about shareholders (dealer acquirers, wallet issuers, payment providers, NewCo and OpCo) is stored centrally in the CPP. Various components request data in order to carry out their processing tasks. The administrator creates and changes main data entries and changes the status of the data (active / inactive). MA main data name

Connection data (address, telephone, email, etc.) ID payment server address (URL) Internal G / L booking account number Bank account number

Billing and billing processes (possibly multiple) Billing currencies status (registered, active, inactive, deleted)

WI main data

Surname

Connection data (address, telephone, email, etc.) ID

Wallet server address (URL)

Internal G / L booking account number

Bank account number

Billing and billing processes Billing currency

Status (registered, active, inactive, deleted)

PI provider main data

Name of connection data (address, telephone, email, etc.)

ID

Server address (URL)

Internal G / L booking account number

Bank account number billing and billing processes

billing currency

Status (registered, active, inactive, deleted)

NewCo main data name Connection data (address, telephone, email, etc.) Internal G / L booking account number Bank account number

OpCo main data

Name of connection data (address, telephone, email, etc.)

Internal G / L booking account number

Bank account number

Billing and billing processes

(possibly multiple) billing currencies status (registered, active, inactive, deleted)

The administration service encapsulates the diverse administration facilities of the various components, provides a single sign-on for the administration user and logs of all user activities. The following administration tasks are carried out centrally since they are valid for all CPP components.

Software updates, system restarts, hardware and network setup

Defining roles and rights, installing users (administrators, operators), assigning roles to users

The security manager has exclusive access to security and system logs to review system operations and detect inside delusions

The main data administrator creates and changes main data entries and changes the status of the shareholders (e.g. active / inactive), The customer care role assigns these access rights to the main data, transaction logs, billing details and settlement reports.

The customer and dealer validity check during the registration process is carried out centrally. The WS sends a test request to the CPP for each customer. The CPP carries out the validity check by checking information such as name, address and age. After completion, the test result is sent to the WS together with a quality indicator that indicates the service used for the validity check (this can be based on agreements between the CPP and WI / MA).

28 schematically shows the different layers of an interoperable mobile payment protocol IMPP, which runs between a merchant server (Merchant Server) and a customer server (Wallet Server) on a processing platform. Basically, the protocol has a core or base layer (IMPP Core Layer) and an extension layer (IMPP Extension Layer), whereby for the former the actual payment area (payment ranks), the context identifier area (OfferlD ranks) and the message area (Notification ranks) belong. The extension layer includes optional requests and responses between the customer and dealer server instances. It also enables a communicative connection to third customer servers. Communication between the customer and the customer server on the one hand and the provider and dealer server on the other is outside this protocol.

The flow diagrams and process step lists of FIGS. 29A to 29C, 30A to 30C, 31A to 31C, 34A to 34C and 36A to 36C for essential types of transactions or payment transactions are self-explanatory.

This also applies to the processes illustrated in FIGS. 32A and 32B and 33A and 33B during the generation and the deletion or destruction of a static offer. In this regard, reference is also made in particular to the general explanation given above for handling the context identifier. The steps and aspects of a clearing procedure illustrated in FIGS. 35A and 35B depend on whether a so-called merchant acquirer is involved or not. They follow the organizational practices of established clearing procedures in conventional money transactions.

Figures 37 to 40 are essentially self-explanatory due to their labeling, so that an additional verbal description is not necessary. The following abbreviations apply:

EPP Encorus Processing Platform (system management server)

FX Foreign Exchange

MA Merchant Acquirer (a service provider)

OpCo system operator

PI Payment Instrument PS Payment Server (with transaction server)

P2P person-to-person

SVA Stored Value Account

Telco telecommunications operator

TX transmission WI Wallet Issuer (a service provider)

WS Wallet Server (a transaction server)

Although the invention has been described in the scope of various embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the claims.

Claims

claims

1. A method for executing a transaction on a system which has at least one central processor platform, at least one wallet server and at least one payment server, the central processor platform having a forwarding machine which is coupled to the wallet server and the payment server via a communication connection, and the method comprises these Steps comprises: receiving a transaction request on the payment server or on the wallet server,

Forward the request from the payment server or from the wallet server to the central processor platform and

Operation of the central processor platform to complete the transaction.

2. The method of claim 1, wherein the transaction request on the payment server or on the wallet server is received by at least one of a mobile device and a non-mobile device.

3. The method of claim 1 or 2, wherein communications between the central processor platform and at least one of the payment server and the wallet server are in accordance with a protocol.

4. The method of claim 3, wherein the protocol comprises an interoperable mobile payment protocol.

5. The method of claim 4, wherein the interoperable mobile payment protocol is used in connection with performing at least one of a direct macro payment, macro payment credit, delayed macro payment, partial macro payment, direct micro payment, delayed micro payment, or micro payment credit.

6. The method according to any one of the preceding claims, wherein the central processor platform at least either a currency conversion, or a payment statement and a payment settlement, or a payment processing of charges and invoicing, or distributing funds.

7. The method according to any one of the preceding claims, wherein the wallet server has at least one of authorization data, payment data and transaction history data.

8. The method according to any one of the preceding claims, wherein the payment server has at least either merchant data or transaction history data.

9.Data transmission procedure for the transmission of information relevant to payment transactions for the payment of goods or services sold by a provider to a customer with access to a customer account electronically managed by an account manager using a telecommunications network, in particular a mobile network, to which the customer is connected with a telecommunications terminal , in particular for carrying out the method according to one of claims 1 to 8, characterized in that the provider requests a unique context identifier for the temporary or permanent, cross-transactional identification of a product or service offered by him, in particular a plurality of goods and / or services to one

System administration server directed, generated by the system administration server a context identifier or a confirmation of an externally generated context identifier and sent to the requesting provider, the context identifier transmitted to the customer and from the customer via the telecommunications network in association with the context identifier for authorization data Authorization of payment to be sent to the account manager.

10. The data transmission method as claimed in claim 9, so that when the context identifier is generated, no period of validity is established, so that it is potentially valid indefinitely.

11. The data transmission method as claimed in claim 9, so that when the context identifier is generated, a period of validity is defined and when it expires it is automatically invalidated when the context identifier is generated.

12. The data transmission method as claimed in claim 9, so that an elimination signal is sent to the provider to invalidate the context identifier when the period of validity has expired or at the request of the provider.

13. Data transmission method according to one of claims 9 to 12, so that the transmission of the context identifier to potential customers as an invariant optical display, in particular lettering on a shop window display or automatic dispenser or printing on a prospectus or catalog or the like.

14. Data transmission method according to one of claims 9 to 12, so that the context identifier is transmitted to potential customers as a variable optical display on an electro-optical display device or by voice output or an acoustic signal.

15. Data transmission method according to one of claims 9 to 14, so that the context identifier in a broadcast method outside the telecommunications network, in particular by radio or television transmission or transmission or distribution of printed matter or e -Mail- Broadcast, transmitted to a large number of potential customers during the period of validity.

16. Data transmission method according to one of claims 9 to 14, so that the context identifier, in particular in a broadcast method, in a short message or via WAP via the telecommunications network to the telecommunications terminal of the customer transmitted and displayed there.

17. Data transmission method according to one of claims 9 to 16, since you can see that the steps of requesting a context identifier by the provider and sending such a to the provider are essentially automated data transfers between the system administration server and a dealer server or provider data terminal via a data and / or telecommunications network, in particular the Internet.

18. Data transmission method according to one of claims 9 to 17, so that after the step of transmitting the context identifier to the customer, the context identifier by the customer via the telecommunication network to a customer The server of the network operator or a service provider in the telecommunications network transmits, sends a request message for a binding offer to the provider through the customer server, service server or dealer server, sends an offer data record to the customer server and the offer data record is sent by the customer Server is transmitted to the potential customer's telecommunications terminal and is displayed there as part of a menu to confirm the transaction.

19. The data transmission method as claimed in claim 18, so that the data transmission is carried out in the steps of requesting a binding offer and sending the offer data via the system administration server, which in particular search and routing Functions between network operator or service provider and provider performs.

20. Data transmission method according to one of claims 9 to 19, so that the context identifier is generated entirely externally and transmitted as part of the request by the provider to the system administration server for confirmation.

21. Data transmission method according to one of claims 9 to 19, so that the context identifier has a first and a second section, the first section being a provider identifier generated or managed by the system management server and the second section cut a goods or goods generated or managed by the provider

Is a group identifier and the method comprises a transmission of the second section to the system administration server, the linking of the first and second section in the system administration server and the sending or confirmation of the entire context identifier to the customer or to the customer.

22. Data transmission method according to one of claims 18 to 21, so that the context identifier in or on a telecommunication terminal, in particular by means of a camera or a scanner connected thereto, of the customer from an optical or acoustic signal an electrical signal is converted.

23. Arrangement for performing the method according to one of the preceding claims, with a system management server, which is designed to generate and send the context identifier in response to a request, a provider terminal connected to the system management server via a data and / or telecommunications network, in particular the Internet, for entering and sending the request for a context -

Identifier and for outputting a sent context identifier, display means for displaying the context identifier for the customer (s) and a telecommunication terminal, in particular a mobile radio terminal, for connecting the customer to a telecommunication network for access to his customer account.

24. Arrangement according to claim 23, g e k n n ze ic h net d u rch by a customer server that establishes a connection between the customer's telecommunications terminal and the provider terminal for the transmission of a binding offer, in particular via the system administration server.

25. Arrangement according to claim 23 or 24, so that the display means are designed as a print or a label on a support.

26. Arrangement according to claim 23 or 24, so that the display means as an electro-optical display device, in particular as

Display a telecommunications or data terminal, are formed.

27. The arrangement as claimed in claim 23 or 24, so that the display means are designed as a voice output or acoustic signaling device.

28. Arrangement according to claim 23 or 24, so that the display means are designed as television or radio receivers.

29. Arrangement according to one of claims 23 to 28, so that the customer's telecommunications terminal is assigned a camera or a scanner for the automatic detection of an optically displayed context identifier or that it is used for evaluating a one Acoustic signal representing the context identifier is formed.

30. Arrangement according to one of claims 23 to 29, so that the system administration server has a code generator unit for generating a context identifier for the temporary or permanent, cross-transaction unambiguous identification of goods or services offered by the providers , in particular in each case a plurality of goods and / or services, in response to a received request and a code transmission device for transmitting the generated context identifier directly or indirectly to the requesting person

Has provider terminal.

31. The arrangement as claimed in claim 30, so that the system management server of the code generator unit assigned timer means and time storage means for assigning and storing a validity period to each context identifier and one associated with the timer and time storage means Has duration comparator unit for monitoring the expiry of a specified period of validity and for outputting an elimination signal for invalidating the context identifier when expiry.

32. Arrangement according to one of claims 23 to 31, so that the system management server has a data storage system for storage and management of all valid context identifiers and of the information assigned to them in the system, in particular payment-relevant data and identifications of data transmission processes that have taken place.

33.Data transmission arrangement for the transmission of information relevant to payment transactions for the payment of goods or services sold by providers to customers with access to customer accounts electronically managed by at least one account manager, with at least one telecommunications network, in particular a mobile radio network, to which the customers are each connected with a telecommunications terminal , provider terminals connected or connectable to the telecommunication network, at least one account management server for managing the customer accounts, at least one customer server of the operator of the telecommunication network or a customer service provider, the customer server for managing identification data of the customers and for carrying out data communication is formed with the provider terminals and the or each account management server, and a system management server, which is via a bidirectional data connection is connected or connectable directly to the or each customer server as well as to the provider terminals or at least one intermediary dealer server of a dealer service provider and storage means for storing identification and address data of the provider terminals or the or each dealer server and Data traffic control means for routing data transmission processes between the or each customer server and the provider terminals or the or each dealer server.

34. Data transmission arrangement according to claim 33, characterized in that the system management server with a plurality of customer servers in several telecommunications networks, in particular mobile radio networks, are essentially permanently connected.

35. Data transmission arrangement according to claim 33, so that the system management server and / or the dealer server is arranged in a telecommunications network, in particular a mobile radio network, and forms a functional unit with the customer server.

36. Data transmission arrangement according to one of claims 33 to 35, so that the system management server can be connected to a plurality of dealer servers, each dealer server being connected or connectable to a plurality of provider terminals and a dealer memory for storing identification and address data of the connected

Provider.

37. Data transmission arrangement according to one of claims 33 to 36, so that the system administration server has a code generator unit for generating a context identifier for the temporary or permanent, cross-transactional unambiguous identification of goods or services offered by the providers , in particular in each case a plurality of goods and / or services, in response to a received request and a code sending device for sending the generated context identifier directly or indirectly to the requesting provider terminal.

38. Data transmission arrangement according to claim 37, so that the system management server of the code generator unit assigned timer means and time storage means for assigning and storing a validity period to each context identifier as well as a time period associated with the timer and time storage means -Comparison unit for monitoring the expiry of a defined validity- duration and for the output of an elimination signal to invalidate the context identifier when expired.

39. Data transmission arrangement according to one of claims 33 to 38, which also indicates that the or at least one account management server is directly assigned to the or a telecommunications network and to the system management server and / or to the customer server for executing a payment, especially when accessing a prepaid credit.

40. Data transmission arrangement according to one of claims 33 to 38, so that the or at least one account management server is arranged outside the internal control area of the or each telecommunications network and in particular can be connected directly to the telecommunications terminal of the customer ,

41. Data transmission arrangement according to one of claims 33 to 40, so that the system management server has a sequence program memory for storing at least one transaction sequence program for data communication between the or each customer server and the provider terminals or the or each dealer server has.

42. Data transmission arrangement according to one of claims 33 to 41, so that the system management server has a data storage system for storing and managing all valid context identifiers and information associated therewith in the system, in particular data relevant to payment transactions and identification of data transmission processes that have taken place , assigned.

43. Data transmission procedure for the transmission of information relevant to payment transactions for the payment of payments made by providers to customers. purchased goods or services with access to customer accounts electronically managed by at least one account manager, via at least one telecommunications network, in particular a mobile radio network, to which the customers are each connected with a telecommunications terminal, in particular for operating a data transmission arrangement according to one of claims 33 to 42 , dadu rc hge kze nce ic hn et that a system management server connects data between at least one customer server and a plurality of provider terminals or at least one intermediary dealer server on the basis of identification and address data stored in a database of the system management server Provider terminals or the or each dealer server and the or each customer server, in particular a plurality of data connections in parallel with one another, set up and in one

Transaction sequence program controlled data communication steps between them can be controlled.

44. Data transmission method according to claim 43, so that the provider makes a request for a unique context identifier for the temporary or permanent, cross-transactional identification of a product or service offered by him, in particular a plurality of goods and / or services directed to a system administration server, generated by the system administration server a context identifier or a confirmation of an externally generated context identifier and sent to the requesting provider, the context identifier transmitted to the customer and assigned by the customer via the telecommunication network authorization data for authorization of the payment are transmitted to the account manager for the context identifier.

45. Data transmission method according to claim 43 or 44, so that it is known the context identifier in a broadcast process outside the telecommunications network, in particular by radio or television transmission or sending or distributing printed matter or e-mail broadcast, during the period of validity being transmitted to a large number of potential customers.

46. Data transmission method according to claim 43 or 44, so that the context identifier, in particular in a broadcast method, is transmitted in a short message or via WAP to the telecommunications terminal of the provider and is displayed there.

47. Data transmission method according to one of claims 43 to 46, so that the steps of requesting a context identifier by the provider and sending such to the provider as essentially automated data transfers between the system administration server are performed and a dealer server or provider data terminal via a data and / or telecommunications network, in particular the Internet.

48. Data transmission method according to one of claims 43 to 47, so that, particularly in transactions with a monetary value above a predetermined threshold, after the step of transmitting the context identifier to the customer, the context identifier transmitted by the customer via the telecommunication network to a customer server of the network operator or a service provider in the telecommunication network, sent a request message by the customer server to obtain a binding offer to the provider, sent an offer data record to the customer server by the provider and the offer data record from the customer server to the telecommunications Terminal of the potential customer transmitted and displayed there as part of a menu to confirm the transaction.

49. Data transmission method according to claim 48, so that a request for the transmission of the context identifier and associated payment information is sent to the customer by the customer server.

50. Data transmission method according to claim 48 or 49, so that a step of transmitting a payment confirmation by the customer via his telecommunication terminal is connected directly or indirectly to the account management server.

51. Data transmission method according to claim 50, characterized in that the receipt of the payment confirmation at the account management server triggers the electronic debiting or reservation of a prepaid partial credit.

52. Data transmission method according to claim 50, so that the receipt of the payment confirmation signal at the account management server is a customary bank clearing electronic clearing procedure between the customer's account management server and an account management server and the provider terminal of the provider performing the transaction or the dealer server of the assigned dealer service provider starts.

53. Data transmission method according to claim 52, so that the clearing procedure takes place outside the data transmission arrangement according to one of claims 1 to 10.

54. Data transmission method for the transmission of information relevant to payment transactions for the execution of a payment by a payer to a payee with access to a payer account electronically managed by a first account management server using a telecommunications network, in particular a mobile radio network, to which the payer is connected with a telecommunications terminal, in particular for performing the method according to any one of claims 1 to 8, wherein - built up from the telecommunication terminal of the payer connects to a first transaction server of a system operator or service provider and a first payment instruction Da ^'record which at least one magnitude information and an address information of the Includes the payee, is transmitted to the first transaction server, - by the first transaction server from the address information a account identifier one by the first or a further K ontenverwaltungsserver electronically managed payee account is determined and - by the first transaction server a credit to the payee account by submitting a second payment instruction

Data record, which includes at least the amount information and the account identifier of the payee account, is triggered to the account management server of the payee account.

55. Data transmission method for transmitting payment-relevant information for executing a payment from a payer to a payee with access to a payer account electronically managed by a first account management server using a data network, in particular the Internet, to which the payer is connected with a data terminal, and a telecommunications network, in particular a mobile radio network, to which the payer is connected with a telecommunications terminal, in particular for carrying out the method according to one of claims 1 to 8, wherein a connection is established from the payer's data terminal to a first transaction server of a system operator or service provider and a first payment instruction record, which comprises at least amount information and address information of the payee, is transmitted to the first transaction server,

a connection to the payer's telecommunications terminal is established by the first transaction server and a data or voice communication process for authenticating the payer is initiated via the telecommunications network, in response to successful authentication by the first

Transaction server is determined from the address information, an account identifier of a payee account electronically managed by the first or a further account management server and

- The first transaction server initiates payment to the payee account by transmitting a second record of payment instructions, which includes at least the amount information and the account identifier of the payee account, to the account management server of the payee account.

56. Data transmission method according to claim 54 or 55, d a d u r c h g e k e n n z e i c h n e t that

- a server address of a second account management server is determined by the first transaction server from the address information, by means of which the payee account is managed electronically, - a request for an account identifier of the payee account is sent to the second account management server by the first transaction server, with the address information of the payee being transmitted and

- The account identifier of the payee account is determined by the second account management server and sent to the first transaction server.

57. Data transmission method for the transmission of information relevant to payment transactions for executing a payment from a payer to a payee with access to a data which is managed by a first account manager. tungsserver electronically managed payer account using a telecommunications network, in particular cellular network, to which the payer is connected with a telecommunications terminal, in particular for performing the method according to any one of claims 1 to 8, wherein

a connection is established from the payer's telecommunications terminal to a first transaction server of a system operator or service provider and a first payment instruction record, which includes at least amount information and address information of the payee, is transmitted to the first transaction server,

- The first payment instruction record is transmitted by the first transaction server to a second transaction server determined on the basis of part of the address information of the payee, - an account identifier of a payee account electronically managed by the first or a further account management server is determined from the address information and

- The second transaction server triggers a credit to the payee account by transmitting a second record of payment instructions, which at least includes the amount information and the account identifier of the payee account, to the account management server of the payee account.

58. Data transmission method for transmitting payment-relevant information for executing a payment from a payer to a payee with access to a payer account electronically managed by a first account management server using a data network, in particular the Internet, to which the payer is connected with a data terminal, and a telecommunications network, in particular a mobile radio network, to which the payer is connected with a telecommunications terminal, in particular for carrying out the method according to one of claims 1 to 8, wherein a connection is established from the payer's data terminal to the first transaction server of a system operator or service provider and a first payment instruction record, which includes at least amount information and address information of the payee, is transmitted to the first transaction server,

Transaction server, the first payment instruction record is transmitted by the first transaction server to a second transaction server determined on the basis of part of the address information of the payee, - an account identifier of a payee account electronically managed by the first or a further account management server is determined from the address information and

59. Data transmission method according to claim 57 or 58, d a d u r c h g e k e n n z e i c h n e t that

- a server address of a second account management server is determined from the address information by the second transaction server, by means of which the payee account is managed electronically, - a request for an account identifier of the payee account is sent to the second account management server by the second payee account, with the address information of the payee being transmitted and

- by the second account management server the account identifier of the Payee account is determined and sent to the second transaction server.

60. Data transmission method according to one of claims 54 to 56, so that the first or second transaction instruction record is determined by the first or second transaction server after determining the account identifier of the payee before triggering the payment together with a confirmation request transmitted to the payer's telecommunications terminal and the payment is only triggered in response to the receipt of a confirmation signal from the payer's telecommunications terminal.

61. Data transmission method according to one of claims 54 to 60, so that the first payment instruction record comprises a first currency code and the second payment instruction record comprises a second, different currency code and when the second payment instruction is created A data record is converted from the amount information of the first payment instruction record into amount information of the second payment instruction record on the basis of a previously stored exchange ratio.

62. Data transmission method according to claim 61, so that the conversion of the amount information is carried out at the first or second account management server using an exchange ratio transmitted from the transaction server of the system operator.

63. Data transmission method according to claim 61, so that the conversion of the amount information is carried out by the transaction server on the basis of an exchange ratio stored in an assigned database.

64. Data transmission method according to one of claims 54 to 63, so that the first and / or second payment instruction data record includes text information relating to the payment, which is essentially identical, in particular, for both payment instruction data records ,

65. Data transmission method according to one of claims 54 to 64, so that the data transmissions from and to the payer's telecommunications terminal for a payment are all made by short message according to SMS, data file transmission according to WAP or via IVR. Voice communication.

66. Data transmission method according to claim 65, so that a payment of an amount below a predetermined threshold value is initiated by the transmission of a first payment instruction data record by SMS to the telecommunications terminal without confirmation data transmission ,

67. Data transmission method according to one of claims 54 to 66, so that an authorization check of the payer is carried out by the first account management server and / or an authorization check of the payee is carried out by the second account management server on the basis of respectively stored user data.

68. Data transmission method according to one of claims 54 to 67, so that an authorization check of the payer and / or payee is carried out on the basis of stored user data by the first or second transaction server.

69. Data transmission method according to one of claims 54 to 68, so that the address information of the payee in the first payment instruction data record is designed as MSISDN, network address of an IP network, alias or co-identifier in the first payment instruction data record.

70. Data transmission method according to one of claims 54 to 69, so that settlement amount information is generated for each credit note by the first or second transaction server and is added to the second payment instruction record together with a predetermined identifier above it, whether the payer account or payee account or both are to be debited proportionately.

71. Data transmission method according to one of claims 61 to 70, so that when converting the amount information of the first payment instruction data record into that of the second payment instruction data record one, in particular in an assigned database of the transaction, Spread information stored on the server or system administration server.

72.Data transmission arrangement for transmitting information relevant to payment transactions for executing a payment from a payer to a payee with access to an electronically managed payer account with at least one telecommunications network, in particular a mobile radio network, to which the payer is connected with a telecommunications terminal, a first account management server for managing the Payer account, which can optionally be connected to the telecommunication terminal via the telecommunication network, a first transaction server of the operator of the telecommunication network or a service provider, the first transaction server being in particular, can be connected to the telecommunications terminal via the telecommunications network, a second account management server for managing a payee account, which can be connected directly or indirectly to the first transaction server and can be identical to the first account management server, the first transaction server for converting a first payment instruction Data record, which comprises at least amount information and address information of the payee, is formed in a second payment instruction record, which comprises at least the amount information and an account identifier of the payee account.

Data transmission arrangement for transmitting payment-relevant information for executing a payment from a payer to one

Payee with access to an electronically managed payer account with at least one telecommunication network, in particular a cellular network, to which the payer is connected with a telecommunication terminal, a first account management server for managing the payer account, which can optionally be connected to the telecommunication terminal via the telecommunication network, one first transaction server of the operator of the telecommunication network or of a service provider, the first transaction server being connectable to the telecommunication terminal in particular via the telecommunication network, a second account management server for managing a payee account which is indirectly connectable to the first transaction server and to the first Account management server can be identical, a second transaction server that can be connected to the first transaction server and the second account management server and for converting one Most payment instruction record, the at least amount information and address information of the payee includes, is formed in a second payment instruction record, which comprises at least the amount information and an account identifier of the payee account.

74. Data transmission arrangement according to claim 72 or 73, characterized by a data terminal device via which the payer is connected to a data network, in particular the Internet, and which can be connected to the first transaction server.

75. Data transmission arrangement according to one of claims 72 to 74, so that a system management server is essentially permanently connected to a plurality of first and / or second transaction servers in a plurality of telecommunication networks, in particular mobile radio networks.

76. Data transmission arrangement according to claim 75, so that the system administration server is arranged in a telecommunications network, in particular a mobile radio network, and a functional unit with a

Transaction server forms.

77. Data transmission arrangement according to one of claims 72 to 76, so that the or at least one account management server is directly assigned to the or a telecommunications network and with the system management server and / or with the transaction server for executing a payment, in particular with access to a prepaid credit.

78. Data transmission arrangement according to one of claims 72 to 77, so that the or at least one account management server is located outside the internal control area of the or each telecommunications network. arranges and in particular can be connected directly to the payer's telecommunications terminal.

79. Data transmission arrangement according to one of claims 72 to 78, so that the system management server has a sequence program memory for storing at least one transaction sequence program for data communication between a payer's telecommunications terminal and the account management server or the transaction server or the transaction servers.

80. Data transmission arrangement according to one of claims 72 to 79, so that the system administration server is assigned a data storage system for storing and managing all valid user data and, in particular, data transfer processes relevant to payment transaction data and identifications.