DE202013007090U1 - Server based payment system - Google Patents

Abstract

A server-based payment system (10) comprising at least one host computer (11), an executable server application for managing a plurality of payment service user accounts, and a data store (12) for storing user account data in the form of records; wherein the server application is programmed to, when running on at least one host computer (11), perform the following actions: upon receipt of an access token containing information about an identity and privileges associated with a social network user account in a web-based communication platform (20, 20 '), retrieving a contact list stored at the web-based communication platform (20, 20') for the social network user account using the access token; Processing the contact list to determine whether there are corresponding payment system service user accounts for entries of the contact list at the server-based payment system (10); - transmitting a processed contact list containing information about entries for which there is a corresponding payment service user account, from the server-based payment system (10) to a user terminal (18, 19); After receiving a payment order generated at the user terminal (18, 19) by selecting an entry from the processed contact list and indicating an amount to be paid, generating a transaction and storing the transaction in the data store, the transaction being the amount to be paid , a principal of the transaction and a payee of the transaction as specified by the payment order, in the form of a record.

Description

Field of the invention

The present invention relates to the field of network service applications, and more particularly to a server-based payment system and programmable user terminal programmed to communicate with a server-based payment system.

Background of the invention

In addition to traditional cash transactions, virtual transactions of electronic money associated with modern telecommunications networks, particularly the Internet, are becoming increasingly important. There are online payment systems where registered users can exchange cashless payments; d. H. receive or transfer electronic cash payments from other registered users. To make an electronic payment, a user must specify a recipient of the payment and a monetary amount to be transferred. The recipient can typically be specified via his e-mail address. The amount is then either debited from a prepayment account of the user managed by the payment service provider, or debited from a bank account of the user with which he registered with the online payment system. However, to make such payments, the user must know if the specified recipient is also a registered user of the same online payment system and therefore has a user account with them.

Summary of the invention

It is an object of the present invention to provide a server based payment system which is easier to use and particularly well suited for electronic money transfer among friends or for other cash payments.

These and other tasks appearing below are solved by a server-based payment system and corresponding user terminal for communicating with the server-based payment system, where a user can transfer electronic money (often referred to as e-money) to recipients selected from contact lists he has with one or more web-based communication platforms, often referred to as social networks.

According to one embodiment, there is provided a server-based payment system including at least one host computer, an executable server application for managing a plurality of payment service user accounts, and a data store for storing user account data in the form of records. The server application is programmed, when running on the at least one host computer, to perform the following actions: upon receipt of an access token containing identity information and privileges associated with a social network user account associated with a web-based communication platform , the host computer uses the access token to retrieve a contact list stored in the web-based communication network for the social network user account. The host computer also processes the contact list to determine whether the payment card user accounts exist for the contact list list server-based payment system. Then, the host computer transmits to a user terminal a processed contact list containing information indicating the entries for which a corresponding payment service user account exists. Upon receipt of a payment order generated at the user terminal by selecting an entry from the processed contact list and indicating an amount of money to be transferred, the host computer generates a transaction and stores the transaction in the data store. The transaction contains in the form of a record the amount to be paid as well as the payer and the payee specified by the payment order.

Preferably, to generate the access token, the server-based payment system redirects an existing connection from the user terminal to an authorization link of the web-based communication platform, access data is transmitted from the user terminal to the authorization link, and the web-based communication platform generates the access token.

In addition to using a contact list from a web-based communication platform, a local contact list, ie a list taken from the local address book, may also be transmitted from the user terminal to the server-based payment system where the lists are merged, and a processed contact list may be returned to the user terminal, which list includes merged entries from the retrieved contact list and from the local contact list.

According to another variant, the server-based payment system may retrieve contact lists of two or more different web-based communication platforms using different access tokens generated at the respective communication platforms that merge two or more contact lists and one processed contact list containing merged entries from the two or more retrieved to the user terminal.

In the event that no payment service user account exists for the payee, the server-based payment system generates a temporary user account entry, assigns the entry a pending registration status, and transmits an invitation message to the payee using the contact information contained in the payment order. The invitation message contains a unique registration identifier and a link to a registration page. After registering the payee with the registration link, the server-based payment system validates the user entry by creating a new payment service user account for the payee and assigns the transaction to the newly created account.

If a payment service user account of the payee exists, the server-based payment system assigns the pending acceptance status to the transaction and transmits a notification message to the payee. The message message contains information about the pending transaction.

After the payee contacts the server-based payment system to accept the pending transaction, the transaction is executed, account balances of the payee's and payee's account are changed accordingly, and the transaction is given an assumed status.

In another embodiment, a programmable user terminal is provided that includes an application program for communicating with a server-based payment system. The application program is programmed, when executed by the programmable user terminal, to perform the following actions: the programmable user terminal initiates the generation of an access token containing information about an identity and privileges associated with a social network user account, which is a web-based communication platform, by transmitting access data entered by a user into an input mask displayed to the user by the terminal. The user terminal receives from the server-based payment system a processed contact list containing entries taken from a contact list associated with the social network user account at the web-based communication platform as well as information indicating corresponding payment service user accounts in the server-based payment system consist. The user terminal displays to the user a menu for selecting a payee from the processed contact list and entering an amount to be transferred to the payee. The user terminal also transmits a payment order to the server-based payment system containing information indicating an entry selected from the processed contact list and the amount to be transferred.

In yet another embodiment, a programmable user terminal is provided that includes an application program for communicating with a server-based payment system. The application program is programmed, when executed by the programmable user terminal, to perform the following actions: The terminal logs in to a web-based communication platform by transmitting credentials entered by a user into an input mask displayed to the user by the terminal were. The terminal then retrieves from the web-based communication platform a contact list associated with a social network user account, which account preferably belongs to the same user using the terminal. Then the user is presented with a menu for selecting a payee from the contact list. In addition, the terminal transmits a payment order to the server-based payment system, which contains information indicating an entry selected from the contact list, information indicating the web-based communication platform, and an amount to be paid.

By allowing the user to access contact lists from his social network accounts, the present invention provides a very convenient manner in which the user can select a recipient for e-money transfer. On the other side, a user experiences through Pre-processing the contact lists on the server of the payment system and by marking appropriate entries for users who already have a payment service user account at the payment system, to which of his contacts he can easily and securely transfer electronic payments. The present invention is therefore ideally suited for payments between friends on social networks.

Brief description of the drawings

Embodiments of the present invention will now be described with reference to the accompanying drawings. It shows:

1 communication between user terminals, a server-based payment system, and social network servers;

2 a flow chart for the generation of an access token;

3 a message flow between a user terminal, a server of the payment system and a server of the communication platform for obtaining an access token;

4a , b is a flow chart for the generation of a transaction at a payment system;

5a , b is a flow chart for processing a transaction at the payment system;

6 the menu structure of an app installed on a user's smartphone;

7 a message flow for a login from a user terminal on Facebook via a web portal of the payment system; and

8th a message flow for a direct login of the application installed on a user terminal to Facebook.

Detailed description of preferred embodiments

The embodiments described below relate to an on-line service provided over a communication network, such as the Internet. To access this online service, a dedicated application program, usually called an app, must be installed on a user terminal, such as a smartphone, a tablet PC, or the like, that communicates with the service provider's servers. Alternatively, the service may also be implemented as a web portal that can be accessed by a user terminal using a conventional web browser.

The service provider's system includes a server platform on which a server application is installed and running that manages user-related records stored in the data store. The server platform includes at least one, but preferably a plurality of interconnected server computers, also referred to as server hosts, having the conventional design well known to those skilled in the art. In particular, the server platform may be a server farm or a server cluster, i. H. a collection of computer servers of similar construction, interconnected to distribute computational power and provide redundancy to form a connected virtual system.

The data store may be connected to the server platform or integrated into one or more of the server hosts. The data store may also be implemented as a distributed storage system and may also be structured as a database.

The service as such is an electronic payment service that includes the management of user accounts for electronic money, the management of user deposits as well as the transmission and reception of electronic payments among registered users of the payment service.

User accounts are maintained on the basis of deposit accounts, which means that the user can fill up his user account with money from a credit card or regular bank account and then use that money for electronic payment transactions. However, transactions can only maximum up to the available balance. There may also be an additional limit on transactions below the available balance in order to limit the risk of fraudulent use.

In addition, the user may also withdraw his balance from the user account and return it to his normal bank account or credit card account. To perform an electronic money transfer, a user only needs a registered user to whom the money to be transferred, hereinafter referred to as the payee, and an amount to be transferred, are required. The corresponding amount is then debited to the user account of the initiating user, hereafter referred to as the principal, and credited to the user account of the payee.

For each transaction, a record is stored on the data store and assigned to the respective user accounts of the principal or payee. The term record, as used hereinafter, is intended to refer to a set of data fields related to each other in content. For example, a record may include an execution date, an amount to be transferred, a payee (or recipient) of the payment, and a payer. In addition, the record may include the previous and current account balance of the user accounts to which it refers. Data records are preferably stored in the form of a database, in particular a relational database.

1 shows the communication between user terminals 18 . 19 and a server-based payment system 10 , The payment system 10 contains a server platform 11 of the above type and a data memory 12 that with the server platform 11 connected is. The server platform 11 is via a data interface with an access node 15 a telecommunications network 14 connected. The telecommunications network 14 has further access points 16 . 17 for mobile user terminals 18 . 19 , such as smartphones or tablet PCs, provides wireless access. The air interface between user terminals 18 . 19 and access points 16 . 17 may be any mobile radio interface, such as, but not limited to, HSDPA (High Speed Downlink Package Access), ie the UMTS (Universal Mobile Telecommunications System) mobile radio standard interface, the air interface of the LTE (Long Term Evolution ) or the GPRS interface (General Package Radio Service) of the mobile radio standard GSM, as well as a wireless Internet access, which is also referred to as WLAN.

The telecommunications network 15 is not necessarily a consistently homogeneous network, but may also include a plurality of interconnected subnets or different network layers or protocols potentially operated by different network operators. Telecommunication networks of this type are well known to those skilled in the art and therefore need not be described in greater detail. In the context of the present invention, it should be assumed only that a data connection between a user terminal 18 . 19 and the server platform 11 over the telecommunications network 14 can be produced. Preferably, the data connection is a packet-switched connection that can be established using a packet protocol, such as the Internet Protocol (IP).

To a user terminal, such as a user terminal 18 , Access to the payment system 10 gets it over the communication network 15 a data connection to the server platform 11 ago. For security reasons, the data connection is preferably established using an encryption protocol, such as TSL (Transport Layer Security), the previous version SSL (Secure Sockets Layer) or the IPsec protocol (Internet Protocol Security).

About the telecommunications network 14 Other Internet services, such as, but not limited to, web-based communication platforms, commonly referred to as social networks, may also be accessed. Such communication platforms may include social networks such as Facebook, Twitter, Google+ or tumblr, just to name a few. Such social networks are hosted by network servers. To indicate this only by way of example, are in 1 two server platforms 20 . 20 ' via an access or gateway node 13 with a telecommunications network 14 connected. The server platforms 20 . 20 ' For the purposes of the description given below, two different social networks of the type described above, e.g. B. Facebook and Twitter as social networks, host.

To use or access Internet services, such as social networks, or the payment system of 1 Typically, a user typically must first authenticate to a server of the corresponding service provider by entering previously assigned access data, such as a username and password. Sometimes such credentials are already stored on the user terminal and are automatically transmitted to the service provider, so that the user does not have to manually reenter his credentials each time he uses the service.

As is well known in the art, social network services stores contact lists of so-called "friends" or "followers" with whom a user has communicated on the communication platform of the corresponding social network. In accordance with one aspect of the present invention, the payment system makes 10 Such contact lists are available to a user for the selection of the recipient of an electronic money transfer. As will be seen below, the payment system communicates 10 with a dedicated application program running on a user terminal 18 . 19 is installed. Such mobile user terminal application programs are commonly referred to as "apps."

For the purposes of the following description, the payment service will be called "Cashcloud", the payment system 10 as a cashcloud backend or briefly as a backend and on the user terminal 18 . 19 installed application called Cashcloud App or Cashcloud Frontend. Moreover, in the following description, by way of example, not by way of limitation, reference will be made to the social networking services Facebook and Twitter. It should be understood, however, that the present invention is not limited to particular social network services, but may be applied to any type of communication platforms that provide Application Programming Interfaces (APIs) for external access.

Integrating friend lists from social networks such as Facebook and Twitter allows the Cashcloud user to send money to any friend without having to know their bank details, such as account number, bank sort code or IBAN and BIC numbers , Basically, the Cashcloud user selects a recipient only by his or her friend's name, which is listed on the selected social networks. Upon receipt of this transaction information, the recipient may confirm or reject the transaction within their Cashcloud Mobile App on their smartphone or through the use of the internet browser associated with the Cashcloud website. The amount of money is then moved from the cashcloud user "principal" to the cashcloud user "recipient."

As will be seen in more detail below, this is the cash cloud backend 10 Contact lists of social networks Facebook and Twitter for those on the user terminals 18 . 19 installed Cashcloud app available. The cashcloud backend must therefore be on the server 20 . 20 ' access from Facebook and Twitter on behalf of the user and with their privileges. This is achieved via Facebook and Twitter APIs using so-called access tokens.

An access token is a protected object that contains information about an identity and privileges associated with a user account. Access tokens may be temporarily valid for a specified period of time after which the token becomes invalid, or may be permanently valid. 2 Figure 4 illustrates a workflow of steps and communication between Cashcloud App, Cashcloud Backend and a Social Network Server for generating an access token that can be used by the Cashcloud backend to retrieve contact lists from the corresponding Social Network Server.

In 2 The actions shown on the left-hand side refer to actions that take place on the Cashcloud app in the middle of 2 shown actions on actions of the cash cloud backend and on the right side of 2 actions shown to interact with a social network server.

In a first step 21 In the Cashcloud app installed on their mobile user terminal, a user activates a login function to activate a login in a social network. The Cashcloud app sends an appropriate request to the Cashcloud server, whereupon the Cashcloud server in step 22 requests a temporary request token from the social network server. The temporary request token is issued by the social network server only to enable the generation of an authorization request page for the user and to associate the corresponding return message returned by the user with the initial request by the cash cloud server. to identify and correlate the external service that the user has allowed to act in his (or her) name. The request token expires when the user response arrives at the social network server.

In step 24 The cash cloud server receives the temporary request token and an authorization link from the social network server and uses this to build an authorization frame and send it to the user terminal. At the user terminal, the user is presented with a login screen in which the user enters his credentials and acknowledges the privileges granted to the cash cloud server within a frame embedded in the cash cloud app. A login function implemented in the embedded frame generates a request for an access token from the access data and the temporary request token and sends the request to the cashcloud server. In step 26 The cashcloud server redirects the user request for an access token to the social network server. In step 27 the social network server verifies the credentials and the temporary access token and responds by sending an access token to the cashcloud server. The cashcloud server secures in step 28 the access token in a database 28 ' and forwards the access token to the Facebook app running on the user terminal. In step 29 the Facebook app displays a message to the user terminal informing the user that the login to the social network has been successful.

The access token is issued by the social network server and represents the authorization given by the user at the cash cloud server to obtain specific data from and act on behalf of a social network account. By redirecting the user to the server of the social network for the login it is achieved that the authentication is done solely under the responsibility of the social network server, while the cash cloud server does not need to know the access data and also has no way of accessing it access what is useful in terms of security, data privacy and trustworthiness.

3 shows as an example the login process at the social network Twitter. This login process is used to grant the Cashcloud server an authorization to retrieve data on behalf of a user from the Twitter network. Communication between the Cashcloud server and the Twitter server is performed using an API provided by Twitter via the HTTPS (Hypertext Transfer Protocol Secure) protocol. Authentication uses the OAuth protocol, which is an open standard for authorization, that is, a mechanism by which clients can access server resources on behalf of the owner of a resource. Request and response parameters are in 3 illustrated.

When a user is in step 31 from the Cashcloud app running on their mobile device and, for example, taps a "sign in to Twitter" button, the mobile device sends a GET / <1 ^st social network URL> request message to the Cashcloud server to send the Twitter Login page and display for the user. In process 32 The cashcloud server must request a temporary request token from the Twitter server to build the link for the Twitter login page, to which the user is then routed to access the actions and actions taken by the cashcloud system on its behalf authenticate and authorize. The cash cloud server provides a callback URL in the request, where it can call verification in a later step. The Twitter server answers in step 33 with a request token, token secret and an acknowledgment. The cash cloud backend then builds in step 34 a link to the authorization page and directs the user to this link.

In step 35 If the user has not yet logged in to Twitter, he must provide his access data on the authorization page rendered by the Twitter server, or merely authorize the actions of the application if he is already logged in. The Twitter server directs the user in step 36 to the callback URL and handed over a verifier (oauth_verifier). The verifier has a similar function to a PIN: if returned correctly along with the request token, it allows the application to swap the request token for a pair of a valid access token and a token secret. If the user then in step 37 When the callback URL ("GET / <2 ^nd social network URL>") is visited, the received request token ("oauth_token") and the verifier are also included in the GET request.

The Cashcloud server parses in step 38 the received response to filter out the verifier and send in step 39 a response with the verifier and the request token to the Twitter server, requesting to obtain a pair of an access token and a token secret that can be used to act on behalf of the user.

The Twitter server checks in step 40 whether the request token is accompanied by the correct verifier, and if so, returns a pair of valid access token and token secret back to the cashcloud server. The response of the Twitter server also includes a User_ID, ie the user's internal ID on Twitter and a Screen_Name that represents the user's name on Twitter. Response values are stored in the database of the backend for later use, and the user is taken to step 41 headed to a Twitter page on which he stepped in 42 sees a user interface (UI) that informs him about the successful login attempt.

This or a similar process can be used for any social network that is enabled and connected to the Cashcloud Mobile application. The access token generated through the process described above can now be used by the cash cloud server to retrieve a contact list from the user account on the appropriate social network on behalf of the user. For example, an access token generated by the Twitter server is a persistent token that does not expire while a token generated by the Facebook server is a temporary token that expires after one hour. After the token has expired, a Facebook login must be performed again, after which the token is renewed.

After the Cashcloud server has collected a contact list from a social network, it analyzes the contact list and identifies contacts who are already registered users with the Cashcloud service. To inform the user which of their contacts can send money through the Cashcloud service, the Cashcloud server marks contacts that are already registered with Cashcloud in the list accordingly.

The Cashcloud application allows a user to select an electronic money transfer recipient either from the local address book or from contact lists of those social networks that have been unlocked by the user. To merge the local address book with the contact lists from any social networks, the cashcloud application retrieves the local contact list from the local address book stored on the user terminal and sends the local contact list to the cashcloud server. For example, the local contact list in the payload area of an HTML POST request may be sent to the backend. The Cashcloud server, on behalf of the user, retrieves contact lists from any unlocked social network using the appropriate access tokens to authenticate to the corresponding social network server.

The Cashcloud server then merges and sorts the contact lists and checks for each of the contacts to see if they already exist in the Cashcloud database. Contacts who are registered Cashcloud users are marked accordingly. The Cashcloud server then returns the processed contact list. For privacy reasons, the contact lists are not stored at the cash cloud backend, but only processed by the backend and then sent back to the user terminal where the processed list is then stored.

An example of the message exchange between the application on the user terminal and the cash cloud server is shown below:

The Cashcloud application sends the list of contacts from the local address book to the Cashcloud server in the payload area of an HTML POST request. The list contains a parameter "source" and a parameter "value" for each entry. The source parameter determines the origin of the contact, which in this example is the user's local e-mail address book Email. The corresponding parameter "value" indicates the corresponding e-mail address. Multiple e-mail addresses are possible for the same contact. Optionally, first and last parameter can be specified for each entry in addition to the source and value parameters. In addition, the request message for the social networks that have been unlocked by the user includes corresponding access tokens that authorize the cash cloud server to retrieve contact lists on behalf of the user from the corresponding social network servers.

It should be understood that the specification of access tokens in the request message is optional since, as explained above, it may be that the cash cloud server has already stored corresponding access tokens. However, in an alternative implementation, as will be seen below, access tokens may also be requested by the user terminal and generated by the social network server without the cash cloud server being involved. In this way, by explicitly including access tokens in the request message, it is ensured that the cash cloud server always has a valid and no expired access token for retrieving a contact list from the corresponding social network.

The Cashcloud server checks for each of the contacts whether it already exists in the Cashcloud database. For all social networks for which the user has access to their data, the Cashcloud server updates the contact list and sorts the contact list alphabetically by last name. The processed contact list is then sent back to the Cashcloud application running on the user terminal. An example of such a response message is given below:

Apart from the fact that the returned list is a list made up of the local contacts and the social network contacts, the parameter "newUser" indicates whether the corresponding contact is already a registered cashcloud user (ie wrong) or whether he is for the Cashcloud service a new user would be (ie true). In addition, if a Facebook or Twitter ID is known for a particular entry, then that information is also included to enable the Cashcloud app to prepare a connection between any Cashcloud user account and corresponding Facebook or Twitter accounts , If such a connection exists, this visualizes the Cashcloud app to the user by displaying a corresponding icon next to the contact entry in a selection menu.

This processed contact list is now used by the Cashcloud application to generate a drop-down menu from which the user can select a recipient for an electronic money transfer. Entries in this drop-down menu are graphically marked for contacts who are already Cashcloud users, so that the user knows to which of his friends he can transfer money directly.

In addition, the user is allowed to select as a recipient a contact that is not yet registered as a Cashcloud user. In this case, however, the cash cloud backend then informs the recipient of the proposed transaction via the social network communication system on behalf of the user or via a direct e-mail. This message invites the recipient to register with Cashcloud to receive the payment. The message sent to such a not yet registered recipient then contains an identifier and a Uniform Resource Locator (URL) which leads it to a registration page containing the identifier in the URL parameters. When the recipient of this invitation clicks on the link, they will automatically be directed to a registration application page, where they can fill out a registration form to register with Cashcloud.

The process for creating a transaction in the cashcloud system is as a flowchart in the 4a and 4b shown. In this flow chart, the column on the left contains user interactions, the column in the middle, steps performed by the application installed on the user terminal, and the column on the right, steps that occur at the cash cloud server.

The application has a main menu that contains a button for a money-sending function. If in one step 61 the user clicks on this "send money" button, the application shows in step 62 a form for the money-sending function. In step 63 the user must complete the form to indicate a recipient and an amount to transfer and a reason for the transaction.

In step 64 the application sends the entered data to the Cashcloud server for validation. A corresponding request message sent in the payload area of an HTML POST request is shown below:

The request message contains the entries "credit_user", "amount" and "reason_id". The entry "credit_user" contains the parameters "source", which indicates the way by which the recipient can be informed about the financial transaction, e.g. E-mail, Facebook or Twitter, as well as a parameter "value" that identifies the recipient either by his e-mail address, his Facebook name or his Twitter ID, depending on the value of "source". The entry "amount" contains the amount to be transferred in euro cents. The entry "reason_id" contains an identifier of a reason selected from a predefined list.

In step 65 the Cashcloud server checks the level of the client's membership, whether it has an available credit on its user account and whether optional daily, weekly or monthly transfer limits based on the membership level have not already been exceeded. A further check can be made as to whether the contracting entity or the consignee is on a blacklist. If the validation fails, the Cashcloud server sends in step 66 a corresponding error message to the cashcloud application, which is then displayed on the screen of the user terminal. For example, if the recipient's e-mail address or contact information is not valid or missing, the application displays a warning message. If the amount exceeds the available balance, the application also displays a warning.

If the validation succeeds, the server sends in step 67 a corresponding response message back to the application. The answer may also include a fee depending on the user's membership and the fee model. An example of a response message is given below:

When the application receives the response message indicating that the amount and the recipient details meet the formal requirements, a money-sending screen will be opened at step 68 to the user who will again show him the details of the transaction and prompt for a password or PIN for the Cashcloud service. Then the user in step 69 either revoke the transaction or confirm by entering his password or PIN. After the user enters his password or PIN and presses a confirmation button, the application returns the request below to the Cashcloud server to validate the entered password or PIN.

The parameter PIN represents a double hash value, which is generated according to the following formula:

In this formula, $ userEmail denotes the user's e-mail address used as a user name in the CashCloud, and $ pin is the pin code entered by the user. The $ pinSalt parameter is a random parameter consisting of 32 random symbols from the following group:
"ABCDEFZHIKLMNOPQRSTVXabcdefzhiklmnopqrstvx1234567890"

Finally, the $ hash hash value is encoded with the base64_encode () function to convert the 8-bit binary value into a $ page-independent ASCII sequence of $ pinHash.

The server then checks in step 71 the entered PIN or password to validate the request. If the entered PIN or password was incorrect, in step 72 a validation failed message is sent to the application, which then displays a corresponding error message on the screen of the user terminal. On the other hand, if the validation was successful, the process comes along 4b continued.

As a next step, the cash cloud server then checks to see if the recipient is already a registered Cashcloud user, e.g. For example, if the specified email address matches a user in the Cashcloud database. If the user is not (yet) registered with the Cashcloud system, it will be in step for him 74 create a user record, which then gets the status "pending registration"("PENDING_REGISTRATION"). The user record will be in step 75 stored in the Cashcloud database, and the workflow goes to step 76 further. If the user already exists in the Cashcloud database, the workflow goes straight to step 76 Next, a transaction is generated and set to the PENDING_ACCEPT state.

In step 77 the transaction is stored in a form of a record in the Cashcloud database. In addition to the status display, the record contains at least the amount to be paid, the Cashcloud user sending the electronic payment (ie, the payer), and the recipient or payee of the payment.

In step 78 a reply is sent back to the Cashcloud app to indicate that the transaction has been generated. The answer is in the format shown below. It contains the HTTP status code 200 indicating a successful generation of the transaction:

Finally, in step 79 sent a message to the recipient. This message is sent either as an e-mail directly to the recipient or, if the recipient was selected from a social network contact list, via their inbox at the appropriate social network. Alternatively, to avoid problems with spam filtering on the social network server, a message can be sent to the recipient via the social network platform, also named and on behalf of the client. This may require the user to re-enter their social network account credentials to allow the cash cloud backend to act on its behalf.

After a transaction has been successfully generated and the recipient in step 79 The process of execution of the transaction, as described in the workflow of the 5a . 5b is shown. In the 5a . 5b If the first column refers to user interactions by the recipient, the second column refers to actions performed by the cashcloud application running on a recipient's terminal, the third column refers to actions performed on the cashcloud server and the fourth column refers to interaction with a licensed e-money institution, such as TUNZ.

In step 80 the status of the record in the Cashcloud database relating to the recipient is checked. If the corresponding user record has the status "pending registration", meaning that the recipient is not a registered Cashcloud user, then the Cashcloud system notifies the pending transaction with an e-mail either directly or through the inbox of a social network. As already mentioned, the email then contains an identifier and a URL link leading to a registration page where the user can then register to receive the electronic payment. In step 82 the user then receives the invitation message, and then, by following the contained link, he can visit the registration page and go to step 83 register as a new Cashcloud user.

If the status check in step 80 turns out that the recipient is already a registered Cashcloud user, or if the recipient has successfully registered as a new Cashcloud user 84 send a message requesting the recipient to accept the transaction. In step 85 the user receives a message about the pending transaction, and he can then in step 86 follow a link in the message that leads him to the Cashcloud application, either in the form of a web portal or in the form of the Cashcloud app running on his mobile device. In step 87 The Cashcloud application will then show him a screen with all pending transactions assigned to his user account.

In step 88 The user can select a transaction from the selection shown to him by the application, and then he gets in step 89 Details of the selected transaction shown. In step 90 For example, the user can tap an accept button that is displayed to him for the selected transaction. If he taps the accept button, the workflow goes into 5b further.

Then the application prompts the user in step 91 to enter his credentials, eg. B. his user PIN. In step 92 the user must enter his PIN, and then the application sends in step 93 a request with the hashed PIN to the cashcloud server. In step 94 The cashcloud server validates the PIN. If the PIN is invalid, a corresponding error message will be sent in step 95 returned to the application and displayed to the user. In addition, the number of invalid attempts to enter the PIN can also be stored in the Cashcloud system in order to block the user account after a predetermined number of invalid attempts.

If the PIN is successfully validated, the Cashcloud server initiates in step 96 the actual money transfer. This is done in the embodiment via a licensed e-money institution, in this case TUNZ, by calling a money transfer function available in the E-money institution's API. In step 97 At the e-money institution, the actual money transfer is carried out and a confirmation is sent back to the Cashcloud server. In step 98 The Cashcloud server changes the account balance for the customer and recipient accounts stored in the Cashcloud database. In step 99 the status of the transaction is changed to "ACCEPTED". Finally, in step 100 sent a notice of successful transfer of funds to both the principal and the payee of the transfer.

6 shows the menu structure and graphical user interface of the Cashcloud App installed and running on a mobile user terminal. Screen view A shows the main menu used by the Cashcloud application after successful authentication. Main menu A has several buttons for various functions, such as retrieving account balance, refilling the account from a credit card, checking open transactions, and others. The button 102 is used to send money to other Cashcloud users. When the button 102 is pressed, the money sending screen B is opened. With the Back button 104 the user can return to the previous screen. To initiate an electronic payment, the user must complete the required fields. In box 106 the user can either manually enter an e-mail address of a recipient, or he can select a recipient from a selection list. In box 108 he must enter an amount to be transferred. In box 110 He may choose a reason for payment from a drop-down menu. In box 112 he can, if he so wishes, enter a comment. At the top of menu B, the Cashcloud user will see his available account balance. The amount that can be transferred can not be higher than this available balance.

To select the recipient from a selection list, the user can select the friend icon 114 Press, whereupon the application will proceed to screen C, which will display a menu of contacts originating from the local address book and from one or more social networks sent by the Users have been unlocked to use for Cashcloud services. Such contacts in the selection list, who have already been registered as Cashcloud users themselves, are marked with an icon 116 marked. The Cashcloud user knows in this way which of his friends and contacts can already receive electronic payments via the electronic payment service Cashcloud. In addition, a Facebook or Twitter icon indicates whether the contacts are also included in or from Facebook or Twitter contact lists. When the user selects an entry from the selection list of contacts on screen C, the information is transmitted on the money sending screen B and the address field 106 pre-filled.

Back on screen B, the user can select an amount that he wants to send by clicking on the Amount field 108 navigated. This then automatically opens an amount screen D which displays a numeric keypad to enter the amount. By pressing the "done" button, the amount entered is then entered in the amount field 108 of the screen B transferred.

Back on the screen B, the user can enter a reason for payment by going to the box 110 navigated. This will bring up a screen E with a selection list of predefined reasons from which the user can select an entry, which then enters the field 110 is transmitted. If the user does not want to select any of the reasons so offered from the list, the field may 110 be left blank or the user can select an entry "others".

in The Field 112 the user can enter a free text message as a comment, which is then transmitted to the recipient along with the transaction. After completing the form on screen B, the user can click the "send money" button 113 The Cashcloud application pushes and sends the data to the Cashcloud server for validation, as described above. After successful validation of the entries by the Cashcloud server, the Cashcloud app then proceeds to screen F, prompting the user to enter his PIN in the box 122 to confirm and authorize the transaction.

On screen F, the application then displays the selected payment amount and the electronic money transfer fee charged by the cash cloud server. The undo button 118 then brings the user back to screen B. When the user is to field 122 navigates, the keyboard will appear to enter its PIN. When entering the PIN, the application displays only hidden characters. If the PIN has been entered, the user must use the button 124 then the application sends a request with the hashed PIN code to the cashcloud server for validation as described above.

If the transaction generation on the Cashcloud server was successful and confirmed, the user will be presented with the screen G informing him of the successful creation. The "done" button then takes the user to the "H" screen, where he can optionally share his experience with the Cashcloud service on any social network he has activated for cash cloud services.

As an alternative to allowing the cashcloud backend to retrieve contact lists from the user's social network accounts, the cashcloud frontend can directly contact individual social networks and then a contact list from the corresponding social network Load user account.

The Cashcloud app then displays a screen view I where the user can select a social network, such as Facebook or Twitter. When the user selects one of them, he is prompted to enter his credentials for the corresponding social network. After a successful login to the social network, the Cashcloud App will then call the contact list directly from the Social Network user account and display the list in a K for Twitter or J for Facebook Friends screen. A selection from one of these lists J, K is then transferred to the money sending screen B and into the field 106 as a recipient of a transaction pre-filled.

For example, it may be that the cashcloud user, for example, wants to select a friend from Facebook on the Facebook screen J. If the Cashcloud user has not yet unlocked and connected the Facebook social network, the application will display Facebook's "login" social graph application in the form of an embedded web page frame, where the Cashcloud user will type his E -Mail address and password must be entered to connect to Facebook. Then he can confirm access to his Facebook data through the Cashcloud application and all Facebook friends will be displayed on the J screen. The application sends data about the friends of that Facebook profile to the backend and save it in the database to prepare a connection between the Cashcloud user account and this Facebook ID.

The 7 and 8th show two alternative login methods that can be used to log in to Facebook. This in 7 The login method shown is used when the cashcloud service is implemented as a web portal. The user accesses with his web browser 50 on a web portal 51 at Cashcloud web server and shows a corresponding web page of the portal in his browser 50 at. The website includes a Facebook login button which when activated activates a JavaScript login function FB.login () of the Facebook API 52 triggers. The JavaScript function FB.login () displays a login dialog in a pop-up window in which the user enters his access data. The Facebook API 52 uses the OAuth2.0 authorization framework implemented in JavaScript to confirm login and successful session creation and returns an access token. The web portal 51 shows a login-completed message on the user's browser.

The second login procedure, which is schematically in 8th is shown by a mobile user terminal 53 on which a cash cloud app is installed rather than accessing a remote web portal from a user terminal using a traditional web browser. The Cashcloud app 54 shows the user a button for logging in to Facebook in a similar way as on the screen I of 6 , When this login button is pressed by a user, the app calls 54 the Software Development Kit (SDK) login procedure available in the Facebook API. In particular, the app sends 54 a request for authorization to the Facebook server 55 containing a unique application ID that identifies the application to the Facebook server. The request for authorization also includes a callback URL to which the Facebook server 55 to redirect the answer.

Below the callback URL is the Facebook server 55 in the form of an embedded web page frame, a login screen that is part of the Facebook SDK on which the user - if he has not already logged in to Facebook - must enter his credentials and then grant those to the Cashcloud app Access rights to access his Facebook data confirmed. The Facebook SDK then returns with a validation code and a callback URL 54 back.

The application 54 can then redial the Facebook SDK on the Facebook server at the callback URL 55 invokes and authorizes with its unique application ID and the validation code provided by the Facebook SDK in the previous step. The Facebook server confirms the successful login and returns an access token that the Cashcloud app can use to access the friend list of the user's Facebook account.

The Cashcloud user can also select a friend from other social networks. For example, for Twitter, the application displays the Twitter "Login" Social Graph application of the Twitter API as an embedded web page frame in which the Cashcloud user enters their email address and password to log in with Twitter to connect. He can then confirm the access to his Twitter data through the Cashcloud application, whereupon all Twitter friends (which are typically referred to as "followers" on Twitter) display him on the K screen of 6 are displayed. The application sends data through friends of the Twitter profile to the Cashcloud backend and backs them up in a database to prepare a connection between the Cashcloud user account and its Twitter ID.

The description and drawings merely illustrate the principles of the present invention. It is therefore to be understood that those skilled in the art will be able to make various arrangements which, while not expressly described herein, embody the principles of the invention and are within their spirit and scope. Furthermore, all examples herein are intended in principle to serve educational purposes only, and to assist the reader in understanding the principles of the invention and the concepts contributed by the inventors to advancing this art and are to be understood without limitation to such specific examples and conditions. In addition, all statements indicating principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to include their equivalents.

One skilled in the art will readily recognize that steps of various methods described above may be performed by programmed computers. Some embodiments are also intended to include program memory devices, e.g. Digital data storage media, which are machine- or computer-readable and encoded machine-executable or computer-executable programs of instructions, which instructions perform some or all steps of the above described methods. The program memory devices may, for. As digital storage, magnetic storage media such as magnetic storage disks and magnetic tapes, hard disk drives or optically readable digital data storage media. The embodiments are also intended to cover computers that have been programmed to perform the steps of the methods described above.

Claims (11)

Server based payment system ( 10 ) comprising at least one host computer ( 11 ), an executable server application for managing a plurality of payment service user accounts, and a data store ( 12 ) for storing user account data in the form of records; wherein the server application is programmed to run on at least one host computer ( 11 ) receives the following actions: - upon receipt of an access token containing information on an identity and privileges associated with a social network user account used in a web-based communication platform ( 20 . 20 ' ), retrieving a contact list used in the web-based communication platform ( 20 . 20 ' ) for the social network user account using the access token; Processing the contact list for determining whether entries of the contact list in the server-based payment system ( 10 ) corresponding payment system service user accounts exist; Transferring a processed contact list which contains information about entries for which there is a corresponding payment service user account, from the server-based payment system ( 10 ) to a user terminal ( 18 . 19 ); Upon receipt of a payment order which is at the user terminal ( 18 . 19 ) was generated by selecting an entry from the processed contact list and indicating an amount to be paid, generating a transaction and storing the transaction in the data store, wherein the transaction is the amount to be paid, a payer of the transaction, and a payee of the transaction as defined by the payment order, in the form of a record. Server based payment system ( 10 ) according to claim 1, wherein the server application is programmed to generate the access token by redirecting a connection from the user terminal ( 18 . 19 ) to an authorization link of the web-based communication platform ( 20 . 20 ' ). Server based payment system ( 10 ) according to claim 1 or 2, wherein the server application is programmed to receive from the user terminal ( 18 . 19 ) to receive a local contact list; from the web-based communication platform ( 20 . 20 ' ) to bring together the contact list retrieved with the local contact list; and the processed contact list containing merged entries from the retrieved contact list and the local contact list, to the user terminal ( 18 . 19 ) return. Server based payment system ( 10 ) according to any one of the preceding claims, wherein the server application is programmed to use different access tokens provided in respective communication platforms ( 20 . 20 ' ), contact lists of two or more of the various web-based communication platforms ( 20 . 20 ' ) to recieve; to merge the two or more contact lists; and the processed contact list containing merged entries from the two or more retrieved contact lists to the user terminal ( 18 . 19 ) return. Server based payment system ( 10 ) according to any one of the preceding claims, wherein the server application is programmed to, in the case in which the payee previously used in the server-based payment system ( 10 ) no payment service user account exists to generate a temporary user account entry for the payee, assign a pending registration status for the temporary user entry, transmit an invitation message to the payee using the contact information contained in the payment order, the invitation message having a unique registration identifier and a Contains a link to a registration page; and upon registration of the payee with the registration link, validating the temporary user entry by generating a new payment service user account for the payee and assigning the transaction to the new payment service user account. Server based payment system ( 10 ) according to any one of the preceding claims, wherein the server application is programmed to, in the case where the payee of the server-based payment system ( 10 ) already has a payment service user account, assign the transaction a pending acceptance status, and transmit a notification message to the payee, the notification message containing information about the pending transaction. Server based payment system ( 10 ) according to claim 6, wherein the server application is programmed after the payee acquires the server-based payment system ( 10 ), to accept the pending transaction, initiate execution of the transaction, change account balance of the account of the payer and the payee, and assign an acceptance status to the transaction. Programmable user terminal ( 18 . 19 ) comprising an application program for communicating with a server-based payment system ( 10 ), the application program being programmed to be executed by the programmable user terminal ( 18 . 19 ), perform the following actions: - causing the generation of an access token containing information about an identity and privileges associated with a social network user account used in a web-based communication platform ( 20 . 20 ' ) by transferring access data transmitted by a user to one of the terminal ( 18 . 19 ) have been input to the user input screen; Receiving a processed contact list from the server-based payment system ( 10 ), the entries that originate from a contact list that goes to the social network user account at the web-based communication platform ( 20 . 20 ' ), as well as information indicating whether the server-based payment system ( 10 ) corresponding payment service user accounts exist; - displaying a menu (C) for selecting a payee from the processed contact list for the user; and - transmitting a payment order containing information indicating an entry selected from the processed contact list and an amount to be paid to the server-based payment system ( 10 ). Computer-readable storage medium containing an application program for use on a user terminal ( 18 . 19 ) for communicating with a server-based payment system ( 10 ), wherein the application program is programmed to be executed by the programmable user terminal ( 18 . 19 ), perform the following actions: - causing the generation of an access token containing information about an identity and privileges associated with a social network user account used in a web-based communication platform ( 20 . 20 ' ) by transmitting access data entered by a user into an input mask displayed by the user to the user; Receiving a processed contact list from the server-based payment system ( 10 ) for entries, for the corresponding payment service user accounts in the server-based payment system ( 10 ), contains information about them; - displaying a menu (C) for selecting a payee from the processed contact list for the user; and - transmitting to the server-based payment system a payment order containing information indicating an entry selected from the processed contact list and an amount to be paid ( 10 ). Programmable user terminal ( 18 . 19 ), preferably according to claim 8, comprising an application program for communicating with a server-based payment system ( 10 ), wherein the application program is programmed to be executed by the programmable user terminal ( 18 . 19 ) to do the following: - Execute a login with a web-based communication platform ( 20 . 20 ' ) by transferring access data transmitted by a user to one of the terminal ( 18 . 19 ) Input form displayed to the user; - retrieve a contact list belonging to a social network user account from the web-based communication platform ( 20 . 20 ' ); - displaying a menu (K, J) for the user to select a payee from the contact list; and - transmitting a payment order indicating information indicative of an entry selected from the processed contact list, the web based communication platform ( 20 . 20 ' ) and the amount to be paid to the server-based payment system ( 10 ). Computer-readable storage medium, preferably according to claim 9, comprising an application program for use on a user terminal ( 18 . 19 ) for communicating with a server-based payment system ( 10 ), wherein the application program is programmed to be executed by the programmable user terminal ( 18 . 19 ) performs the following actions: - performing a login on a web-based communication platform ( 20 . 20 ' ) by transferring access data transmitted by a user to one of the terminal ( 18 . 19 ) Input form displayed to the user; - retrieve a contact list belonging to a social network user account from the web-based communication platform ( 20 . 20 ' ); - displaying a menu (K, J) for the user to select a payee from the contact list; and - transmitting a payment order indicating information indicative of an entry selected from the processed contact list, the web based communication platform ( 20 . 20 ' ) and the amount to be paid to the server-based payment system ( 10 ).

Images