WO2013079793A1

WO2013079793A1 - Electronic payment system

Info

Publication number: WO2013079793A1
Application number: PCT/FI2012/051177
Authority: WO
Inventors: Simo Salminen; Tuomo Kajava; Hannu MATILAINEN
Original assignee: Onsun Oy
Priority date: 2011-12-02
Filing date: 2012-11-29
Publication date: 2013-06-06
Also published as: FI20116222A; EP2786327A1; EP2786327A4

Abstract

The invention relates to a system for money transfer, the system (10) comprising - a mobile terminal (112) of a user (112'), connected to a mobile communications network (130) for transmitting a payment request, - a network terminal (132) of the user (112'), for registration of the user (112'), and - a server (114) comprising a memory unit and an Internet server (126) with a web application (116), and in which system (10) the money transfer is configured to be performed in three steps, the first being the registration of the user (112'), the second being a request for mobile payment, and the third being the bank transfer. In the system, the server (114) comprises software tools configured - to manage a number of the system's own bank accounts, - to select at least one source bank account from the system's own bank accounts for the payment, by using an automatic algorithm, on the basis of the bank account data of the recipient (128) of the money, - to transmit a payment request for transferring the money.

Description

ELECTRONIC PAYMENT SYSTEM

Field of the invention The invention relates to methods, equipment and systems for electronic payment.

Background At the same time when the use of cash in society is reduced, various forms of payment based on computer systems are becoming more common. The best known of such systems utilize plastic debit or credit cards issued by a bank or a credit company. It is common knowledge that plastic debit and credit cards involve security risks if the card is stolen and the password relating to it simultaneously falls into the wrong hands.

An electronic monetary and banking system enabling electronic payment functions in a known way so that accounts of clients are maintained in the data systems of different banks. Information about the resources, such as money or book-entry securities, on the account is associated to these accounts. When, for example, money is transferred from one account to another, technical solutions must be applied to secure that the recipient's account is credited with the same sum as the remitter's account was debited, and that no credits or debits are generated, for which no corresponding debit or credit is found, respectively. In transactions between banks, the transfer must also take place from one bank to another, and for this there are systems, by which the equivalence of the credits and debits can be secured. Such technical systems, in which the reliability of monetary transactions is secured by information technology equipment, are the basis for electronic payment.

Electronic payment is also needed in shopping on the Internet, where the merchant has to be provided with information about the transfer of the money before the merchant can provide the goods to be delivered. At present, the Internet is mostly used on mobile terminals, such as mobile phones. Therefore, various payment systems have been developed for electronic payment, based on verifications by computer and the transfer of resources (money) even without any physical interaction. In various systems of electronic payment, there is still, for example, the risk that a third party impersonates the remitter. For this reason, the remitter has to be authenticated in the system.

In state-of-the-art systems, user authentication is based on data of the SIM card of a mobile phone. However, such a system is unreliable, because the mobile phone can fall into the hands of a stranger, for example if the user loses his/her mobile phone. Moreover, the maintenance of the systems requires a lot of labour, because the payment transactions in online banking are performed by employees. As a result, the operation of the system may also be slow, wherein it may be impossible to use the system, for example, for paying in a store or in the Internet. State of the art includes the publication US 7,729,989 B1 which presents a system relating to monetary transactions, wherein the user is registered in a service, via which the user can later make payments. Publications US 2007203836 A1 and US 7,324,976 B2 also disclose systems representing the state of the art. However, these systems involve the problem of weak data security.

Consequently, there is a need for systems for money transactions which systems are faster, more reliable and/or require less labour than the systems of state of the art.

Brief summary of the invention

The system may comprise, for example, the user's mobile terminal connected to a mobile communications network for the transmission of a pay- ment request, and the user's network terminal connected to the Internet for the registration of the user, and a server comprising a memory unit and an Internet server with a web application, the server being provided with means of communication with the Internet and with the mobile communications network. In the system, the money transfer can be arranged to be made in three steps, the first being the registration of the user in the system by using a web application, the second being a request for mobile payment, and the third being a transaction.

In the registration, the user can use his/her network terminal to log into the web application, enter the user specific data, and the data are transferred to the server which checks at least part of the data and transmits the user a request for confirmation. The user confirms the confirmation request to the server with his/her mobile terminal. After receiving the confirmation, the server generates register data and a trust card number of the user.

In the request for mobile payment, the user transmits a payment request to the server with the mobile terminal, the server checks the data of the pay- ment request on the basis of predetermined criteria, and either accepts or rejects the payment request on the basis of the checking, and the server transmits a confirmation request to the user. The user confirms the confirmation request to the server, and the server receives the confirmation. In a bank transfer, the server transmits a payment request to a bank, and the bank transfers the money to the recipient's account. In the system, the server comprises software means configured to manage the system's own numerous bank accounts, to select for payment at least one source bank account from said bank accounts of the system, by applying an automatic algorithm on the basis of the bank account data of the recipient of the money, and to transfer a payment request to the banking service of the bank defined in the selected source bank account, for transferring the money from the source bank account to the recipient's account. By the system according to the invention, the bank transfer can be made by using a minimum number of transactions, because the system selects the source bank account in such a way that it is in the same bank or in the same banking group as the recipient's account. In this way, the bank transfer occurs as fast as possible. The payment data may be verified without manual checking by employees, which requires labour. In view of data security, the system according to the invention may be more secure than the systems of the state of the art, because in the system according to the invention the money transaction is made without the user's sensitive bank account data, by only using the system's own bank account for making payments.

The money is transferred from the system's bank account to the recipient's account. The system grants a credit to the registered user and invoices for the credit later on.

Advantageously, the server is configured to carry out the steps of the money transfer as distinct software processes independent of each other. This increases the data security, because an error or a data security breach in one process will not spread to another process.

The user specific data may include at least data on the number of the user's mobile terminal, a user specific trust card number, and a user specific PIN code. By means of these data, the system can verify the user's identity in connection with a money transfer.

Advantageously, the data entered by the user are configured to be verified in three steps in connection with both the registration and the payment request. The three-step verification is used to make sure that the transmitter of the payment request is the authentic user and not, for example, a person who has stolen the mobile phone from the user, whereby the security of the system for the user is improved.

In the three-step verification, the server may be configured to automatically compare the user specific data stored in the memory of the server with the data confirmed by the user on the mobile terminal. The data to be verified may include the number of the user's mobile terminal, a user specific trust card number, and a user specific PIN code.

For accelerating the bank transfer, an automatic algorithm is advantageously configured to select, on the basis of the bank account data of the recipient of the money, at least one source bank account from said bank accounts of the system for the payment, said source bank account being in the same bank or banking group as the account of the recipient of the money.

Advantageously, the server is configured to make the bank transfer auto- matically. In this way, the system minimizes the need for manual work.

According to an embodiment, the server is configured to check the user's credit information in connection with each payment request by consulting a database of a third party. In this way, one can be sure of the acceptability of the user's credit information in connection with every money transfer.

Advantageously, the network terminal is the same device as the mobile terminal. Thus, both the network terminal and the mobile terminal are the same device which can be used for both the registration and the payment requests.

According to an embodiment, the system further comprises a server for payment transactions and a debiting server for automatic debiting.

In an embodiment, the system is configured to include a payment specific reference number in each SMS message. In this way, it is considerably easier to follow up the payments.

In an embodiment, the verifications to be sent both via the web application and the mobile terminal are configured to use a common interface.

In an embodiment, the system is configured to generate a corresponding virtual bar code on the basis of the user's money transaction, and to transmit the virtual bar code to the mobile terminal of the recipient of the money transaction. In this way, the recipient may use the virtual bar code in the form of a conventional bar code or a number sequence for payment for example in a store, wherein the money transaction can be made without the recipient's bank account.

By the system according to the invention, it is possible to make bank trans- fers and payments of bills conveniently on a mobile terminal. The invention is also characterized in that it is a system for money transfer independent of time, place and the Internet.

In the system according to the invention, all the steps can be taken automati- cally, wherein the transactions in the system do not require labour. Employees are only needed for maintaining the system.

The invention provides a server system for making payments, the server system comprising means for receiving a payment request from a user; means for generating payment data to be transmitted to a bank, comprising payment data for transferring money from the user's account to the recipient's account, where said user's account and recipient's account are in different banks; means for managing the bank accounts of the system, the bank accounts of the system being in different banks, and the bank accounts of the system being different accounts than the bank accounts of said user and said recipient; means for selecting a source bank account from said bank accounts of the system by using an automatic algorithm on the basis of the bank account data of the recipient of the money, where said selection is made for generating at least one item of payment data in the bank of the selected source bank account, for transferring money from said source bank account to the recipient's account.

The server system may comprise means for selecting said source bank account in such a way that said source bank account is in the same bank or banking group as said target bank account. The system may comprise means for tracking the durations of the bank transfers, and means for selecting said source bank account in a learning manner on the basis of said tracking. The invention also provides a method for making a payment, which method comprises receiving a payment request from a user, generating payment data to be transmitted to a bank, comprising payment data for transferring money from the user's account to the recipient's account, wherein said user's account and recipient's account are in different banks, characterized in that the method comprises automatic administration of the bank accounts of the system, which bank accounts of the system are in different banks, and which bank accounts of the system are accounts different from the bank accounts of said user and said recipient; selecting by an automatic algorithm the source bank account from said bank accounts of the system on the basis of the bank account data of the recipient of the money, wherein said selection is made for generating at least one item of payment data to the bank of the selected source bank account, for transferring money from said source bank account to the recipient's account.

Figures

In the following, the invention will be described in detail with reference to the appended drawings which illustrate some embodiments of the invention, in which Fig. 1a shows a simplified hardware presentation of a system according to the invention, illustrating a minimum set of equipment,

Fig. 1 b shows a simplified hardware presentation of system according to the invention, illustrating another, slightly larger set of equipment,

Fig. 2 shows a general representation of all the processes in the system according to the invention, in block charts,

Figs. 3a to 3b illustrate examples of data records relating to registration (in

Finland),

Figs. 4a to 4b illustrate data records defined in a text message for mobile payment, in general and as an example, Figs. 5a to 5b illustrate data records relating to a money transfer to be made in a web application, in general and as an example.

Detailed description of the embodiments In the following, money transfer refers to various money transactions, including various payments, payments of bills, bank transfers, transfers from one person to another, donations, and other corresponding applications of money transfer. Various terminals are connected to the system over commonly agreed interfaces. A terminal may refer to any device which comprises a display and by which a connection can be implemented either via SMS mes- sages or over the normal Internet, either connected by a network cable or in a wireless manner.

In this context, a bank service should be understood as a wider concept than conventional banking, comprising for example such an embodiment in which the server itself acts as a bank. Thus, the bank account of the user and the recipient of the money transaction may be an account belonging directly to the system. The crediting and debiting of the accounts have to correspond to each other in the money transactions, as described above, and for this reason, the bank system and the money transfer have to be understood as a technical system by which the transfer of resources from one account to another can be implemented in a reliable way.

The system 10 according to the invention, shown in Fig. 1a, comprises, as a minimum, user's mobile terminal 12 connected to a mobile communications network 130 for transmitting a money transfer request and connected to the Internet 134 for registration; and a server 114 comprising an Internet server 126, which server 114 is provided with a connection to the Internet 134 and the mobile communications network 130. In this context, the mobile communications network 130 advantageously refers to a cellular radio network, but it may also comprise a WLAN network, in which case the use of a cellular radio network is not necessary. Furthermore, the system advantageously comprises a database 120 of a third party, for checking the user's credit information, used by the server 114. In this context, the mobile terminal 112 advantageously refers to a smart mobile phone having a connection to both the mobile communications network 130 and the Internet 134, wherein the same mobile terminal 112 can be used for performing both the registration and the money transfer request. The mobile terminal 12 can also be an ordinary mobile phone for transmitting and receiving text messages. The database 120 of the third party may be, for example, a client data register which registers persons' credit information and issues relating to that in general. Figure 1 b shows an embodiment in which the user performs the registration by means of a network terminal 132. In this case, the network terminal 132 may be a computer which is equipped with an Internet connection and by which the user registers his/her information in the Internet server 126 of the system. In Figs. 1a and 1b, the server 114 and the Internet server 126 comprised by it are shown as separate units, but in practice they can be functionalities within the same server. According to Figs. 1a and 1b, the user can also transmit the payment request via the web application by using the Inter- net 134.

The mobile communications network 130 comprises a service provider which is advantageously a teleoperator. The teleoperator or SMS gateway service provider provides a text message service, by means of which the user trans- mits his/her payment request to the system, and by means of which the system transmits a confirmation request to the user's mobile terminal.

In an example embodiment, the system comprises a mobile phone for transmitting and receiving SMS messages. As the Internet server, it is possible to use a web hotel provided by a third party, having Linux as the operating system, 2 GB of disc space, Apache 2.2 software as the www server software, PHP S as the programming language, MySQL 5.0 as the database software, and an Internet connection rate of 10 Mbit/s. A suitable server for the system is a dedicated server that corresponds to an Internet server in view of the operating system, the www server software, the programming language, the database software, as well as the Internet connection, but whose disc space is 100 GB. Furthermore, the system comprises a service provider which is directly a mobile phone operator, or an SMS gateway service provider that provides duplex SMS messages (transmission + reception), for example Securycast. Third party services, i.e. the credit checking, the authentication of the person, the banking services, and the debiting, can be provided by, for example, the following service providers: the credit score checkings by Asiakastieto Oy, the reliable authentication of the user by TUPAS authentication, the automatic management of accounts by Opus Capita, and the debit- ing by Svea Rahoitus. Figure 2 shows overall presentations of all the processes to be carried out by the system according to the invention, in a schematic view. In the figure, all the steps under the heading "Automatic processes" are stand-alone and often independent of each other. The automatic procedures do not require staff. The recipient of a money transfer or an invoice may be any person (except for the user him/herself) or company. Moreover, the recipient does not need to be registered in the system. The transmitter and the recipient themselves do not need to have a bank account. The receiving account may also be an account in a payment office where the recipient can call for a received remittance. The trust card may be provided by a third party. The trust card may also be, for example, the number of a Facebook profile or a serial number for identifying a person in a corresponding service. In the figure, the server is called a finance server, the web application is called web, and the database of a third party is called a credit checking server. The pro- vider of the system is, in these embodiment examples, called by the imaginary name Onsun.

Figure 2 shows the registration of a user in a finance server, i.e. server 114, in a schematic view. The registration is thus always performed via a web application 116. Step 3 represents a start page, and step 4 represents a start button for registration. First of all, the user is identified, i.e. authenticated in step 5, for example by the TUPAS service (in Finland) of the user's own bank, where the user logs in the system, for example by using the credentials to the online services of his/her bank in the same way as in electronic bank- ing applications. The web application checks if the authentication was successful, and if the authentication fails, the system returns the user to step 5 for authentication. If the authentication was successful, the system of the bank 1 8 returns the user's personal identification code back to the web application 116 for the registration process in step 6, the registration process receives the user's personal identification code in step 7, and the user selects a PIN code for him/herself for the payment of invoices or money transfers in step 8.

In step 9, the user enters his/her own registration data, i.e. contact data, tele- phone number, email address, bank account number, and selects a PIN code that he/she wants to use in the system. Figure 3a illustrates some examples of data records relating to registration (in Finland). Figure 3b shows an example data record, in which the user has entered his/her data in the registration columns. After the user has entered his/her personal data in the web application 116, the user transmits the registration data to a server 114 for registration in step 9, and the server 114 stores the registration data in a memory. Herein- below, the finance server will be commonly called a server. In step 10, the server 114 receives the user's registration data, and in step 11 it generates an individual trust card number for the user, which number is needed for the payment of invoices or money transfers to another party. Furthermore, in step 12, the server 114 transmits a credit check request on the basis of the user's personal identification code to a credit checking server 120, the credit checking server 120 receives the credit check request on the basis of the user's personal identification code in step 13, performs the credit checking in step 14, and returns the credit information to the server 114 in step 15.

After this, the server transmits a confirmation request as a confirmation message to a mobile telephone number given by the user, i.e. the user's mobile terminal 112, in step 16. In step 17, the user receives the confirmation request, and in step 18 the user confirms the confirmation request with a confirmation message "CONFIRM pin_code", which he/she sends back to the server 114 on his/her own mobile terminal 112. The server 114 processes the confirmation and checks if the processing was successful. If an error occurs in the processing, the server transmits an error message to the user's mobile phone. An error may be caused, for example, if the PIN code entered by the user does not match the code transmitted in the confirmation message. An error may also be caused by an incorrect telephone number or by exceeding of a time limit. If the processing of the confirmation is success- ful, the server 114 registers the user in its memory in step 19. As a sign of a successful registration, the server 14 transmits a text message of the successful registration to the user's mobile terminal 112. In step 20, the server remains waiting for new operations. Next, we will discuss the various steps 21 to 31 of money transfer shown in Fig. 2. The money transfer is initiated already when the registered user sends a payment request on his/her mobile terminal 112 to the server 14 in step 22. The money transfer can be performed alternatively either by a mobile phone by using text messages, or by means of a mobile phone or another mobile terminal by using an Internet connection and a web applica- tion. When an Internet connection is used, the mobile phone can have a common mobile operating system, such as Meego, iPhone IOS, Android, or the like, for performing corresponding operations. In this embodiment, the payment request is thus sent as a text message or as a payment request of the web application. Advantageously, each message contains a payment reference number, wherein the message traffic of different payments can be easily followed up in the system. Furthermore, the payment application has to contain an individual trust card number generated for the user. In the text message, it is possible to define the data records according to Figs. 4a and 4b. The data records of the payment request in the web application are shown in Figs. 5a and 5b.

The server 1 4 receives the payment request in step 23 and checks the content of the request and, for example on the basis of the telephone number, from which user the message was received. Here, the checking of the content refers to the following basic checks: registration of the user in the system on the basis of the telephone number, verification of the user's trust card number, verification of the PIN code selected by the user, a credit check, number of unsettled invoices, the user's age, as well as the user's blocking list. In step 24, the server 114 checks that the trust card number matches the trust card number of the authentic user. On the basis of the checking result, the server 114 transmits an error notice to the user's mobile terminal 112, if the data in the request are deficient. If the data are sufficient, the server 114 transmits a request to confirm the payment order to the user's mobile terminal 112 in step 25, to which SMS or web application request the user has to reply within a given time window. In step 26, the user receives the confirmation request, and in step 27 the user confirms the confirmation request by transmitting a confirmation text message "CONFIRM pin_code" or a web application confirmation to the server 114. If a web application is used, it is possible to use double checking; that is, the confirmation request has to be confirmed both in the application and by an SMS. The server 114 receives the confirmation in step 28 and checks in step 29 from which user/telephone number the message was received. Furthermore, the server 114 checks that the PIN code matches the PIN code of the authentic user. After this, in step 30, the server 114 passes the invoice to a payment queue. In step 31 , the server 114 remains waiting for new orders.

In the following, some examples will be presented of different text message patterns for money transfer by text message. For example, if the user wants to transfer money to another party, for example from the user to the system, the user sends the following text message to the server: "transfer 04 05;100;222333^44555;Kalle Vaisanen;". The server may send the user the following confirmation request: "Confirm the bank transfer by sending the message 'transfer your pin code' to number 16174. SMS: 4323". For confirming the money transfer, the user can send his/her pin code to the server: "transfer 1234". The server can notify the user of the successful bank transfer by the following message: "Your bank transfer has now been confirmed. Delete the SMS messages relating to this transfer 543 transmitted by you. SMS: 4324". Furthermore, the user can pay an invoice (for example EUR 93.25) by sending the server a message:

^Minvoice041085;93.25;233443-447555; Electric Company;32458;".

The server can send the user the following confirmation request relating to the invoice: "Confirm payment of the invoice by sending the message 'INVOICE your pin code' to number 16174. SMS: 4325". For confirming the invoice, the user can transmit the server the message: "invoice 1234;". For notifying the user of a successful payment of an invoice, the server transmits a message: "Payment of the invoice is confirmed. Delete the SMS messages relating to this transfer 544 transmitted by you. SMS: 4326".

If a mobile payment is made to an online store, the first step is that the user selects "mobile payment" as the payment option at the online store which has made a contract with the system. After this, the online store displays, in its application, the payment data of the system, for example a reference number for the payment. After this, the steps correspond to the steps described above. A requirement for the online shopping is that the user has been registered in the system, has selected the items, and has started the payment of the items. When buying from an online store, the system can generate a vir- tual bar code which is the reference number upon making the payment. The bar code can also be generated by the system of the store.

Steps 32 to 40 describe how a mobile payment request is made in the sys- tern according to the invention. The system differs from the systems of state of the art in that bank accounts held by the actor are maintained in the server of the system. More precisely, in a number of financial institutions or banking groups, such as banks, the actor has bank accounts which the actor has opened for business or other suitable purposes. The actor's accounts are arranged in an efficient data structure. When a payment request from the user's mobile device is received by the actor's server, the account data of the recipient of the payment, for whom the user's payment is to be remitted, is extracted from said request. In a corresponding manner, the data structure that contains the actor's bank accounts and is maintained on the server, is searched by an efficient algorithm for a bank account in the same financial institution or banking group, which account is set as the payment source, i.e. the source bank account. From the actor's selected bank account and the account set as the target, as well as other data of the original payment request, a data record for the bank transfer is compiled and transmitted to the financial institution where the source and target accounts are located. By such an operation, the most advantageous possible transfer between the accounts is achieved, because the number of transactions required by it is minimal, the source and target accounts being advantageously in the same bank or banking group, irrespective of and uncommitted to where the account of the client that transmitted the original payment request is located.

The bank accounts managed by the server of the system are selected so that the system would have a bank account in as many banks as possible, in view of the users. Money transactions between accounts of the same bank take place almost instantaneously. However, because the system normally does not have a bank account in every bank in the world, it will suffice to have a bank account in such a bank that belongs to a given banking group. Money transactions between banks in the same banking group take place quickly, wherein it will suffice that the server of the system has at least one managed bank account in each banking group. Furthermore, there are connections between banking groups; that is, money transfers from a given bank of a banking group to a given bank of another banking group take place relatively quickly. In this way, it is possible to create a technically efficient network to cover almost all or all banks. The software means of the server of the system use an algorithm primarily to find, for the bank transfer, such a source bank account managed by the server that is in the same bank as the recipient's account. Secondarily, the algorithm attempts to find such a bank account managed by the server that is in the same banking group as the bank where the recipient's account is. If even such above-mentioned bank account is not found, the algorithm tries to find such a bank account managed by the server that is in a banking group which has connections to a second banking group where the bank that has the recipient's account is located. The whole payment operation is automated from the receipt of the payment request in the actor's server up to the transmission of the payment request to the bank. In the system, the accounts of the user and the recipient can be in different banking groups, wherein, for each recipient's account, the server selects the fastest account from its own accounts on the basis of predeter- mined criteria. In this way, the speed of the money transfer is not dependent on the accounts of the user and the recipient being in the same bank or banking group. In an embodiment, the system may be learning with respect to payment transfer speeds, wherein it gradually learns, on the basis of trial and error, from which accounts the money is transferred in the fastest way to the recipient's account in a given bank. For the learning system, the bank transfers and their durations are followed up and stored in a memory.

According to Fig. 2, the transaction is started in step 31 , in which the server 114 starts a new process. The server 1 4 retrieves and creates payment data on new accepted payments bank by bank at regular intervals in step 33 and transmits them in step 34 to a payment transaction server 122. The payment transaction server can be, for example, Opus Capita or the like. The server 114 of the system can collect several payments in a "bundle" and make the bank transfers of these collectively after a sufficient number of payment requests has accumulated. In step 35, the payment transaction server receives data on accepted payments, and in step 36 it transfers the payment data files to the bank 118. In step 37, the bank 118 receives the payment file, and in step 38 it remits the payments according to the payment file from the accounts of the system to the recipients 128 specified in the payment file. In step 39, the recipient 128 receives the payment in his/her own account, and the process ends in step 40. The bank 1 8 may inform the server 114 of the successful bank transfer, wherein the server 14 may send the user a text message or email on the successful transaction. Advantageously, the payment transaction takes place automatically. In the system according to the invention, the payment is made from a bank account which is not the bank account of the user or, more generally, the party that triggers the money transaction. In the transaction, the bank account is the account owned and managed by the actor that is the authenticating party. Thus, the user of the application does not need to enter any sensitive data (account data, smart card number) in the system. This increases the data security of the system considerably with regard to documents of state of the art. This is made possible by a solution on the technical software level, in which the request by the user to transfer money from the actor's "optimal" account (automatic algorithm) to the target account is for- warded to such a party that can make the transfer. More precisely, such a transaction becomes free from a strong two-way trust relationship, because the source of the transaction does not need to trust the actor's system strongly. In other solutions of state of the art this is not true, because the account data of the source of the transaction are part of the transaction, and the payment is made from the source account, wherein strong authentication of the actor is needed by the user of the system.

Furthermore, in the system according to the invention, the initiation of the transaction, i.e. the payment request by the user with the server, and the bank transfer are two separate processes with confined internal functionalities. This increases the security on the software level, because an error in one process will not spread to the other process and cause, for example, an incorrect bank transfer without managed and controlled automatic communication between the processes. Logging in the TUPAS service on a bank website can be an operation outside the web application. Figure 2 also shows a credit checking server 120, i.e. a database of a third party, by which the user's credit information is checked in connection with the registration. The system may also comprise a payment transaction server and a debiting server for automatic debiting. In the system, the user is granted a credit, wherein the collecting of the debt is performed in a separate process described in steps 41 to 52. In step 41 , the server 1 4 starts a new process, and in step 42 it creates invoice data on payments that have been remitted. In step 43, the server 114 transfers the invoice data to an invoicing server 124, and in step 44 it remains waiting for information on new payments that have been remitted. In step 45, the invoicing server 124 receives the invoicing data, in step 46 it creates invoices on the basis of the invoicing data, and in step 47 it sends the invoices to the user 112'. In step 48, the user 112' receives the invoice, and in step 49 he/she pays the invoice, for example by mobile payment. In step 50, the invoicing server 124 receives information on the user 112' that has paid the invoice, and on the basis of this, it generates an invoice data record on users 112' who have paid their invoices in step 51. After this, the invoicing server 124 sends the data on the paid users to the server 114 in step 52, and in step 53 the server 114 receives the data on the users 12^! who had paid their invoices. In step 54, the server 114 allocates the invoice data to the respective users on the basis of the reference number, and the process ends in step 55. As an alternative operation for the conventional transaction, the server can transfer the money to the recipient in the form of a virtual bar code. The virtual bar code is a number sequence or an image file corresponding to a conventional bar code and generated by the system, which code can be transmitted to the mobile phone of the user or recipient in the form of an SMS or multimedia message, or by data transmission to a smart phone. After receiving the message, the owner of the mobile phone can use the virtual bar code, for example in the same way as a bottle recycling receipt at the cash desk, where the cashier reads the bar code from the display of the mobile phone or enters by typing in the cash system. The bar code is for single use only. The virtual bar code can be used, for example, as a gift voucher, and its value may be, for example, EUR 100. The transmitter and the recipient of the vir- tual bar code do not necessarily need a bank account, and the recipient does not need to be registered in the system or connected to the system in any way. Transferring money to another in the form of a virtual bar code is performed, in other respects, in the same way as a conventional transaction, up to the step 31 in Fig. 2, but the transaction itself takes place in such a way that the server transmits a single-use virtual bar code to the recipient's mobile terminal, and the recipient receives the virtual bar code in his/her mobile phone. With the virtual bar code, the recipient can pay at a cash desk in a store, or withdraw money from a payment office or another company that has signed a contract with the provider of the system.

The system may also include a mobile payment application, i.e. a "money button" application. When the user who has registered in the system presses the "money button" software key on the smart phone, for example three but- tons, 1 = 100€, 2 = 200€, 3 = 300€, etc are displayed. When the user presses the software key, the program asks for an account number or a possible reference number, or the like. After the fields have been filled in, the trust card number is entered, and an "accept" button is pressed. The system asks for a confirmation, to which the PIN code is given as a reply. The princi- pie of operation of the money button makes it possible, for example, to buy a metro ticket quickly and simply. Thus, the sums displayed on the buttons are fees for travel tickets.

The prerequisites for using the "money button" is that the user has registered in the system, the user has loaded the mobile application in his/her mobile terminal, and has entered the required data (user identification, trust card number) in the mobile application. Even in this context, the mobile operating system used in the mobile phone can be one of the systems mentioned above. Furthermore, if the recipient is a company, the recipient of the money has to be registered as a company user in the system, and the user has to be logged in the application. For a normal user, money is transferred by entering the recipient's account number in the application. If the application is used for paying services, the recipient has to be registered as a company user in the service. In the server, the following steps are taken automatically.

Example embodiments of the money button may include: A money transfer for oneself or for a friend, as well as payment of an invoice. This will require a few pressings, and the payment transaction takes place.

Paying of a metro ticket. Here, a program is started, in which the trip is paid by pressing a button, and the server sends a payment identification to the mobile phone. By showing this, one can enter the metro.

A lunch voucher, a club ticket or another payment application in an analogous manner.

Payment for online shopping. When the client wants to buy an item, the web service provider sets, for example, "Onsun mobile payment" as a payment alternative. On the web site, the data of the payment, the account number and the reference will be displayed in a protected connection. This is paid by sending a message that contains the payment and the reference of the invoice on a mobile phone, and confirming the message. In this way, the payment is transmitted from the system directly to the service provider, and the payment has been made.

International money transfers. Nothing is transferred from the remitter to the recipient, but the system makes the requested transfer anywhere. The system debits the remitter, and the recipient can be in almost any country. - Offering or another corresponding donation for a fundraiser. The remitter gives, for example, EUR 5 as an offering by pressing the software key of the system. This is debited from the client once a month. After this, the donation is disbursed to the target. It is also possible to disburse the payment instantaneously when the client makes the transfer.

- Payment of a wage/remuneration for work of a small enterprise, in developing countries. The remitter of the wage/remuneration has been registered and allocated a credit rating. He/she transfers the remuneration to the worker, who receives it at once. The transfer is invoiced, and a receipt is issued to the employer. The transfer is remitted to a pay office for withdrawal.

In the system according to the invention, both in registration and in connection with money transfers, the data transmitted by the user to the server are automatically checked by means of an algorithm. The data are checked in connection with the registration and a money transfer. Furthermore, auto- matic data checking is also used for checking credit information in connection with money transfers. In connection with a money transfer, the algorithm of the server is advantageously configured to verify the telephone number of the mobile terminal that transmitted the payment request, the user specific PIN code relating to the transfer, as well as the trust card number; in addition, the server automatically requests for a confirmation for the money transfer, to which the user has to reply by a new message. In the automatic verification, it is possible to include any data entered by the registered user and other data which are essential for the money transfer. The aim of the verification is to avoid misuse of the system. Thanks to the automatic verification, considerably less labour is needed in the system according to the invention than in the systems of state of the art, because the checking of the payment request is performed automatically and by machine. Furthermore, the automatic verification is significantly faster than manual verification, and it is carried out without human errors.

In smart phones, it is possible to download an application of the system which is significantly more user friendly and more usable than a conventional system operating by means of SMS messages. In this context, a smart phone refers to a mobile phone which comprises, in addition to conventional mobile phone functions, also features resembling a personal digital assistant, such as an Internet connection and software expandability. The mobile operating system of the smart phone may be a common operating system, such as Meego, iPhone IOS, Android, or the like, for performing similar functions. The mobile terminal used in the system may also be another mobile device having a connection to the Internet and to a mobile communications network. Such a device may be, for example, a tablet computer or a portable computer. The server may be a server representing a known server technology. In this context, the mobile communications network advantageously refers to a mobile phone network, which may be a GPRS, 3G, or corresponding more advanced network.

In an embodiment, the user can set desired time limited withdrawal limits or a user-specific limit, for example EUR 200 per month, in the system. Thus, for example if the mobile phone is lost, a misuser cannot make unlimited bank transfers as the withdrawal limit will be met. In the system, it is possible to use double checking in the case of large sums of money; in other words, in the case of a large payment request, the server sends a confirmation request to, for example, the user's mobile phone and email. In this case, the large sum of money can be, for example, greater than EUR 200.

In another embodiment, on the basis of the position data of the mobile phone the system may recognize the currency used in the region of operation, wherein the user can make a payment request for exactly the correct sum in the correct currency.

Claims

1. A system for money transfer, the system (10) comprising

a mobile terminal (112) of a user (112'), connected to a mobile communications network ( 30) for transmitting a payment request,

a network terminal (132) of the user (1 2'), connected to the Internet (134) for registration of the user (112'), and

a server (114) comprising a memory unit and an Internet server (126) with a web application (116), the server (114) being provided with a connec- tion to the Internet (134) and to the mobile communications network (130), and in which system (10) the money transfer is configured to be made in three steps, the first being the registration of the user (112') in the system (10) via the web application (116), the second being a mobile payment request, and the third being a bank transfer, of which steps the registration is configured to be performed in the following steps:

the user (112') logs in said web application (116) on his/her network terminal (132) and enters the user-specific data,

said data are transmitted to the server (114) which checks at least part of the data and transmits a confirmation request to the user (112'),

- the user (112') confirms the confirmation request to the server (114) on his/her mobile terminal (112),

after receiving the confirmation, the server (114) generates the user's (112') register data and trust card number,

and of which steps the mobile payment request is configured to be made in the following steps:

the user (112') transmits a payment request on the mobile terminal (1 2) to the server ( 4),

the server (114) checks the data of the payment request on the basis of a predetermined criterion and either accepts or rejects the payment request on the basis of the checking,

the server (114) transmits a confirmation request to the user (112'), the user (112') confirms the confirmation request to the server (114), and

the server (114) receives the confirmation,

of which steps the bank transfer is configured to be performed in the following steps: the server (11 ) transmits the payment request to the bank ( 8), and the bank (118) transfers the money onto the account of the recipient

(128),

characterized in that in the system, the server (114) comprises software means configured

to manage a number of the system's own bank accounts,

to select at least one source bank account from the system's own bank accounts for the payment, by using an automatic algorithm, on the basis of the bank account data of the recipient (128) of the money,

- to transmit a payment request to the bank (118) determined by the selected source bank account, for transferring the money from said source bank account to the account of the recipient (128).

2. The system according to claim 1 , characterized in that said server (114) is configured to perform the steps of the money transfer as distinct software processes independent of each other.

3. The system according to claim 1 or 2, characterized in that said user-specific data include at least the number of the user's (112') mobile terminal ( 12), a user-specific trust card number, and a user-specific PIN code.

4. The system according to any of the claims 1 to 3, characterized in that the server (114) is configured to perform the checking of the data entered by the user in connection with the payment request, in three steps.

5. The system according to claim 4, characterized in that in the checking in three steps, the server (114) is configured to automatically compare the user specific data stored in the memory of the server (1 4), with the data confirmed by the user ( 12') on the mobile terminal (112).

6. The system according to claim 4 or 5, characterized in that said data to be confirmed include the number of the user's (112') mobile terminal ( 2), the user-specific trust card number, and the user-specific PIN code.

7. The system according to any of the claims 1 to 6, characterized in that said automatic algorithm is configured to select, on the basis of the bank account data of the recipient (128) of the money, at least one source bank account from the system's own bank accounts for the payment, said source bank account being in the same bank or banking group as the account of the recipient (128) of the money, to accelerate the bank transfer.

8. The system according to any of the claims 1 to 7, characterized in that the server (11 ) is configured to make the bank transfer automatically.

9. The system according to any of the claims 1 to 8, characterized in that the server (114) is configured to check the user's (112') credit information in connection with each payment request, by using a database (120) of a third party.

10. The system according to any of the claims 1 to 9, characterized in that the network terminal (132) is the same device as the mobile terminal (112).

11. A server system (114) for making payments, the server system (114) comprising:

- means for receiving a payment request from a user (112, 112'),

- means for generating payment data to be transmitted to a bank (118), comprising payment data for transferring money from the account of a user (112') to the account of a recipient (128), wherein said account of the user (112) and the account of the recipient (128) are in different banks,

characterized in that the server system (114) comprises:

- means for managing the bank accounts of the system, which bank accounts of the system are in different banks, and which bank accounts of the system are different accounts than the bank accounts of said user ( 2') and said recipient ( 28),

means for selecting a source bank account from said bank accounts of the system by using an automatic algorithm on the basis of the bank account data of the recipient (128) of the money, wherein said selection is made for generating at least one item of payment data to the bank (118) of the selected source bank account, for transferring money from said source bank account to the account of the recipient (128).

12. The server system according to claim 11 , comprising: - means for selecting said source bank account in such a way that said source bank account is in the same bank or banking group as said target bank account.

13. The system according to claim 11 or 12, comprising:

- means for tracking the durations of bank transfers,

- means for selecting said source bank account in a learning way on the basis of said tracking.

14. A method for making a payment, the method comprising:

- receiving a payment request from a user (112, 112'),

- generating payment data to be transmitted to a bank ( 18), comprising payment data for transferring money from the account of a user (112') to the account of a recipient (128), wherein said account of the user (112) and the account of the recipient (128) are in different banks,

characterized in that the method comprises:

managing the bank accounts of the system automatically, which bank accounts of the system are in different banks, and which bank accounts of the system are different accounts than the bank accounts of said user (112') and said recipient (128),

selecting a source bank account from said bank accounts of the system by means of an automatic algorithm on the basis of the bank account data of the recipient (128) of the money, wherein said selection is made for generating at least one item of payment data to the bank (118) of the selected source bank account, for transferring money from said source bank account to the account of the recipient (128).

15. The method according to claim 14, comprising:

- tracking the durations of the bank transfers,

- selecting said source bank account in a learning manner on the basis of said tracking.