AT13561U1 - APPENDIX FOR CARRYING OUT A PAYMENT PROCESS - Google Patents

Abstract

The invention relates to a system for processing a payment transaction by means of a mobile terminal and a method for processing a payment transaction by means of a mobile terminal.

Description

Austrian Patent Office AT 13 561 U1 2014-03-15

description

APPENDIX FOR CARRYING OUT A PAYMENT PROCESS

The invention relates to a system for handling a payment transaction by means of a mobile terminal and a method for processing a payment transaction by means of a mobile terminal.

Mobile payment method for the point-of-sale are known from the prior art. Such payment methods use methods such as quick response (QR) codes, bar codes, near field communication (NFC) to exchange payment information between the merchant's POS system and a payment application (app) on a mobile device.

In this case, the customer uses his mobile device to pay the purchase amount to the cashier of a dealer. The mobile terminal is typically a smartphone - but other forms of mobile devices (such as tablet PCs) are possible. The dealer checks out of his cash register system, whether the payment was successfully completed. If this is the case, the payment process is completed. The mobile payment system thus represents an alternative to conventional cashless payment methods (eg payment by means of a credit / debit card).

The payment apps known from the prior art communicate after transmission of the payment information with a central system on an external server, which is referred to below as a mobile payment service. The actual payment process takes place via card data of a payment card (typically a credit card) stored in the mobile payment service. The customer must therefore have a payment card and register it in the system. Finally, this payment card is used for billing.

However, the registration of the map data in the central system involves a security risk, since the map data must first be encrypted transmitted to the system and must be kept encrypted in sequence on the central system. This vulnerability should be avoided if possible.

The subject invention solves this problem by a payment system for handling a payment process according to claim 1 and a method for carrying out a payment process according to claim 6.

According to the invention, neither the payment app nor the mobile payment service stores the customer's card data. During the processing of the payment process, the customer exclusively discloses his online banking access data. Payment is made by online transfer from the customer's account to the merchant account. The system according to the invention comprises the mobile terminal, the payment app and the mobile payment service as well as an interface to an online banking application of the customer's bank.

In order for a customer to be able to use the system according to the invention, the following prerequisites must be met: The customer must have a mobile terminal (smartphone, tablet PC, etc.). This mobile device must have an Internet connection. In advance, the payment application (payment app) must have been installed on the mobile device. The state of the art in mobile devices are so-called. App stores, through which the customer can load and install the payment application independently.

To participate in the system, the customer must register for the first time. In this context, he receives an identification number (= user ID). He also assigns a password (= PIN) with which the payment function is secured. This prevents unauthorized users - such as those who have access to the mobile device - from making abusive payments. The customer can register directly in the payment app.

Furthermore, the customer must have an online banking access to a bank, the to the 1/13 Austrian Patent Office AT 13 561 U1 2014-03-15

System is connected. The customer must store the associated online banking access data in the system. The merchant must offer the payment method - that is, his cash register system must be extended accordingly to support the inventive system. Furthermore, the dealer must be registered in the system.

Features of the system and method of the invention are described in the description, the drawings and the claims.

The invention will now be described in more detail by means of embodiments in the following figures. FIG. 1 shows a first embodiment of the method according to the invention; FIG. FIG. 2 shows a second embodiment of the method according to the invention; FIG. Fig. 3: a third embodiment of the method according to the invention.

Fig. 1 shows variant 1 of the expiration of a payment. At the checkout (C) the dealer calculates the purchase amount. The customer informs the dealer that he wants to pay with the mobile payment system. The merchant initiates the mobile payment process, thereby causing the POS system (C) to send the purchase amount to the mobile payment service (D) (message 1). The mobile payment service (D) generates a clear transaction number for the payment process, which is returned to the POS system (message 2).

In parallel, the customer starts the payment app (B) on his mobile device (A). The previously generated transaction number will be transferred from the merchant's cash register (C) to the payment app (B) (message 3). This can be done in different ways. For example, the cash register system (C) displays a QR code in which the transaction number (and, if appropriate, further information) are stored. This can for example be done on a screen that faces the customer. Alternatively, the POS system (C) can also print the QR code on a receipt. It is in the decision of the dealer which method is more suitable or easier to implement for him.

The payment app (B) includes functions for scanning the QR code with the integrated camera and interpreting it. This will get the payment information in the payment app (B) on the mobile device (A) of the customer.

However, the transfer of data between POS system (C) and payment app (B) is not limited solely to the method using QR code. Alternative technologies for data exchange are possible. For example, NFC technology, which is also suitable, is becoming increasingly popular.

With the payment information - in particular the transaction number - the actual payment process is started. For this purpose, the payment app (B) in message 4 sends the following data to the mobile payment service (D): Transaction number (transaction ID): This was in the preceding step (message 3) from the POS system (C ) of the merchant into the payment app (B).

· Customer identification number (user ID): The user ID was generated in the course of registration for the customer and is stored in the payment app (B).

· Access data for online banking: This can be entered by the customer in the payment app (B). The payment app (B) encrypts the data and stores it only in encrypted form on the mobile device (A). Already saved access data are proposed by the payment app by default. This saves the customer from having to re-enter each payment process. Under certain circumstances, the access data in the subject message 4 can also be omitted, namely if the user agrees to a storage of access data at the mobile payment service (D). The access data are thus stored exclusively on the mobile payment service (D). A storage in the payment app (B) does not take place in this case. This also eliminates the transmission of the access data to the mobile payment service (D) in the course of each payment transaction.

PIN: This is a password with which the payment function is secured. This prevents unauthorized users - for example, persons who come under the control of the mobile terminal (A) - from making improper payments. The PIN must be entered by the customer during each payment process.

Based on the transaction ID from message 4, the mobile payment service (D) determines the data transmitted in message 1 from the merchant's cash register system (C). From this data, the purchase amount and also the associated dealer. Thus, the mobile payment service (D) can further determine the account data of the merchant (= recipient account for online transfer). The account details were announced by the dealer during registration. These are stored on the mobile payment service (D).

Based on the user ID checks the mobile payment service (D), if the customer is registered in the system. If so, the customer's PIN is checked. This check ensures that the payment process was initiated by the legitimate user and is not abused.

The mobile payment service (D) further determines the online banking access data of the customer. These are either stored directly on the mobile payment service (D) or were transmitted in message 4 from the payment app (B).

As a result, the mobile payment service (D) checks the user ID or the online banking access data and, if appropriate, further identification features of the customer against a revocation list.

If the checks are positive, the mobile payment service (D) logs on to the customer's bank (E) (message 5a). Also in this step examinations are provided - for example, if the account is sufficiently covered. These checks ensure a high level of certainty that the dealer will actually be paid the purchase amount in the sequence. If the checks are positive, the mobile payment service (D) creates the transfer in online banking (E) (message 5b). For this transfer to be actually carried out, it must still be authorized with a TAN. Banks usually support several TAN procedures (eg: mobile TAN, paper TAN, card TAN). The customer configures the TAN procedure to be used in the payment app (B).

If the customer selects mobile TAN as a TAN method, the mobile payment service (D) in the customer's online banking (E) requests the generation and sending of a mobile TAN (message 5c). In the background, the online banking system (E) sends the generated TAN to the mobile terminal (A) of the customer (message 6).

Ideally, this is the mobile device (A) on which the payment app (B) is installed and is paid with the straight at the cash register (C).

The mobile payment service (D) sends a message 7 on the status of the transfer to the payment app (B) back. The message contains all the payment information -there is the amount to pay - as well as data about the merchant. The customer can control the entire payment information. Afterwards, the customer can authorize payment via TAN in the payment app (B). If the TAN has arrived at the mobile terminal (A) via SMS (message 6), this can be automatically transferred from the payment app (B) to the corresponding input field. The customer does not have to enter the TAN manually. This presupposes that this is supported by the operating system of the mobile terminal (A). If this is not supported or other TAN procedures (eg card-TAN) are used, the customer must enter the TAN manually. Finally, the customer must confirm the execution of the payment. When the customer confirms the payment, the payment app (B) sends the TAN in message 8 to the mobile payment service (D).

The mobile payment service (D) sends the TAN message 9 to the online banking 3/13 Austrian Patent Office AT 13 561 U1 2014-03-15 (E) of the customer. If the TAN is correct, the transfer is authorized. The status of the transfer is stored by the mobile payment service (D) and returned in message 10 to the payment app (B). From the point of view of the customer, the payment process is completed.

The POS system (C) of the merchant also receives from the mobile payment service (D) the status of payment (message 11). This makes it clear to the trader whether he has been paid successfully or not.

Fig. 2 shows variant 2 of the process of a payment. The difference to variant 1 lies in the generation of the transaction number (transaction ID). While in variant 1 the transaction number is generated by the mobile payment service (D), in variant 2 the transaction number is generated by the POS system (C). This means that messages 1 and 2 run parallel to each other in terms of time. The further procedure is identical to variant 1.

At the cash register (C), the dealer calculates the purchase amount. The customer informs the dealer that he wants to pay with the mobile payment system. The merchant initiates the mobile payment process, thereby causing the POS system (C) to generate a transaction ID. This transaction ID sends the cash register system (C) in message 1 to the mobile payment service (D). At the same time, the customer starts the payment app (B) on his mobile device (A) and accepts the generated transaction ID in message 2 in the payment app (B). As already described in variant 1, this can be done in different ways. For example, the cash register system (C) displays a QR code in which the transaction number (and, if appropriate, further information) are stored. This can for example be done on a screen that faces the customer. Alternatively, the POS system (C) can also print the QR code on a receipt. It is in the decision of the dealer which method is more suitable or easier to implement for him.

The payment app (B) includes functions for scanning the QR code with the integrated camera and interpreting it. This will get the payment information in the payment app (B) on the mobile device (A) of the customer.

However, the transfer of data between POS system (C) and payment app (B) is not limited to the method using QR code. Alternative technologies for data exchange are possible. For example, NFC technology, which is also suitable, is becoming increasingly popular.

With the payment information - in particular the transaction number - the actual payment process is started. For this, the payment app (B) in message 3 sends the following data to the mobile payment service (D): Transaction number (transaction ID): This was in the preceding step (message 2) from the POS system (C ) of the merchant into the payment app (B).

· Customer identification number (user ID): The user ID was generated in the course of registration for the customer and is stored in the payment app (B).

· Access data for online banking: This can be entered by the customer in the payment app (B). The payment app (B) encrypts the data and stores it only in encrypted form on the mobile device (A). Already saved access data are proposed by the payment app by default. This saves the customer from having to re-enter each payment process. Under certain circumstances, the access data in the subject message 3 can also be omitted, namely if the user agrees to a storage of the access data at the mobile payment service (D). The access data are thus stored exclusively on the mobile payment service (D). A storage in the payment app (B) does not take place in this case. This also eliminates the transmission of access data to the mobile payment service (D) in the course of each payment process. 4/13 Austrian Patent Office AT 13 561 U1 2014-03-15 · PIN: This is a password with which the payment function is secured. This prevents unauthorized users - for example, persons who come under the control of the mobile terminal (A) - from making improper payments. The PIN must be entered by the customer during each payment process.

Based on the transaction ID from message 3, the mobile payment service (D) determines the data transmitted in message 1 from the merchant's cash register system (C). From this data, the purchase amount and also the associated dealer. Thus, the mobile payment service (D) can further determine the account data of the merchant (= recipient account for online transfer). The account details were announced by the dealer during registration. These are stored on the mobile payment service (D).

Based on the user ID, the mobile payment service (D) checks whether the customer is registered in the system. If so, the customer's PIN is checked. This check ensures that the payment process was initiated by the legitimate user and is not abused.

The mobile payment service (D) further determines the online banking access data of the customer. These are either stored directly on the mobile payment service (D) or were transmitted in the message 3 from the payment app (B).

As a result, the mobile payment service (D) checks the user ID or the online banking access data and possibly other identification features of the customer against a revocation list.

If the checks are positive, the mobile payment service (D) logs on to the customer's bank (E) (message 4a). Also in this step examinations are provided - for example, if the account is sufficiently covered. These checks ensure a high level of certainty that the dealer will actually be paid the purchase amount in the sequence. If the checks are positive, the mobile payment service (D) creates the transfer in online banking (E) (message 4b). For this transfer to be actually carried out, it must still be authorized with a TAN. Banks usually support several TAN procedures (eg: mobile TAN, paper TAN, card TAN). The customer configures the TAN procedure to be used in the payment app (B).

If the customer selects mobile TAN as a TAN method, the mobile payment service (D) in the customer's online banking (E) requests the generation and sending of a mobile TAN (message 4c). In the background, the online banking system (E) sends the generated TAN to the mobile terminal (A) of the customer (message 5). Ideally, this is the mobile device (A) on which the payment app (B) is installed and which is currently being paid at checkout (C).

The mobile payment service (D) sends a message 6 on the status of the transfer to the payment app (B) back. The message contains all the payment information -there is the amount to pay - as well as data about the merchant. The customer can control the entire payment information. Afterwards, the customer can authorize payment via TAN in the payment app (B). If the TAN has arrived at the mobile terminal (A) via SMS (message 5), it can be automatically transferred from the payment app (B) to the corresponding input field. The customer does not have to enter the TAN manually. This presupposes that this is supported by the operating system of the mobile terminal (A). If this is not supported or other TAN procedures (eg card-TAN) are used, the customer must enter the TAN manually. Finally, the customer must confirm the execution of the payment. When the customer confirms the payment, the payment app (B) sends the TAN in message 7 to the mobile payment service (D).

The mobile payment service (D) sends the TAN in message 8 to the customer's online banking (E). If the TAN is correct, the transfer is authorized. The status of the transfer is stored by the mobile payment service (D) and in message 9 to the Austrian Patent Office AT 13 561 U1 2014-03-15

Payment App (B) returned. From the point of view of the customer, the payment process is completed.

The POS system (C) of the merchant also receives from the mobile payment service (D) the status of payment (message 10). This makes it clear to the trader whether he has been paid successfully or not.

Fig. 3 shows variant 3 of the process of a payment. As already described in the prerequisites, the customer registers in advance with the mobile payment service (D) and thus receives an identification number (= user ID). This user ID configures the user in the payment app (B).

Starting point in this variant is the transmission of the user ID of the payment app (B) in the POS system (C). For this purpose, the payment app (B) displays the user ID in a machine-readable format on the display - for example as a barcode. In practice, the barcode formats are particularly suitable for this because they can be scanned by almost all POS systems (C) (eg: EAN code). However, other formats are possible (eg: QR code). Furthermore, in the future, an increasing spread of NFC technology is expected. Thus, this transfer possibility between payment app (B) and POS system (C) is conceivable.

However, it is equally possible for the customer to carry the user ID on another machine-readable medium. For example, a barcode printed on a sticker. He can stick this on the back of the mobile device or on any other medium he has with him. There are no restrictions in this regard. The identification number (user ID) coded on the carrier merely serves to identify the customer in the course of the sales process.

At the cash register (C), the customer informs the dealer that he wants to pay with the mobile payment system. The merchant initiates the mobile payment process and first reads the user ID of the customer (message 1). All described characteristics (display on the display of the mobile device, stickers, etc.) are possible. The user ID of the customer thus enters the cash register system (C) of the merchant.

The cash register system (C) sends the user ID together with the purchase amount in message 2 to the mobile payment service (D). The mobile payment service (D) stores the data.

The customer starts the payment process in the payment app (B). The payment app (B) sends the following data in message 3 to the mobile payment service (D): User ID: This is the customer's identification number stored in the payment app (B) and which has also been transmitted to the POS system (C) in the previous step (message 1).

· Access data for online banking: This can be entered by the customer in the payment app (B). The payment app (B) encrypts the data and stores it only in encrypted form on the mobile device (A). Already saved access data are proposed by the payment app by default. This saves the customer from having to re-enter each payment process. Under certain circumstances, the access data in the subject message 3 can also be omitted, namely if the user agrees to a storage of the access data at the mobile payment service (D). The access data are thus stored exclusively on the mobile payment service (D). A storage in the payment app (B) does not take place in this case. This also eliminates the transmission of the access data to the mobile payment service (D) in the course of each payment transaction.

PIN: This is a password with which the payment function is secured. This prevents unauthorized users - for example, people who have access to the mobile device - from making abusive payments. The customer must enter the PIN during each payment process. 6/13 Austrian Patent Office AT 13 561 U1 2014-03-15 With the user ID, the mobile payment service (D) searches for an active payment transaction. If such a transaction is found, this results in the purchase amount and also the associated dealer. Thus, the mobile payment service (D) can further determine the account data of the merchant (= recipient account for online transfer). The account details were announced by the dealer during registration. These are stored on the mobile payment service (D).

As a result, the mobile payment service (D) checks the PIN. This ensures that the payment function is not abused.

The mobile payment service (D) further determines the online banking access data of the customer. These are either stored directly on the mobile payment service (D) or were transmitted in the message 3 from the payment app (B).

As a result, the mobile payment service (D) checks the user ID or the online banking access data and possibly other identification features of the customer against a revocation list. If the checks are positive, the mobile payment service (D) performs a login at the customer's bank (E) (message 4a). The rest of the procedure is analogous to variant 1. First, the mobile payment service (D) performs checks - for example, whether the account is sufficiently covered. These checks ensure a high level of certainty that the dealer will actually be paid the purchase amount in the sequence. If the checks are positive, the mobile payment service (D) creates the transfer in online banking (E) (message 4b). For this transfer to be actually carried out, it must still be authorized with a TAN. Banks usually support several TAN procedures (eg: mobile TAN, paper TAN, card TAN). The customer configures the TAN procedure to be used in the payment app (B).

If the customer has configured mobile TAN as a TAN method, the mobile payment service (D) in the customer's online banking (E) requests the generation and transmission of a mobile TAN (message 4c). In the background, the online banking system (E) sends the generated TAN to the mobile terminal (A) of the customer (message 5). Ideally, this is the mobile device (A) on which the payment app (B) is installed and which is currently being paid at checkout (C).

The mobile payment service (D) sends a message 6 on the status of the transfer to the payment app (B) return. The message contains all the payment information -there is the amount to pay - as well as data about the merchant. The customer can control the entire payment information. Afterwards, the customer can authorize payment via TAN in the payment app (B).

If the TAN via SMS on the mobile device (A) has arrived (message 5) it can be automatically taken over by the payment app (B) in the associated input field. The customer does not have to enter the TAN manually. This presupposes that this is supported by the operating system of the mobile terminal (A). If this is not supported or other TAN procedures (eg card-TAN) are used, the customer must enter the TAN manually. Finally, the customer must confirm the execution of the payment. When the customer confirms the payment, the payment app (B) sends the TAN in message 7 to the mobile payment service (D).

The mobile payment service (D) sends the TAN in message 8 to the customer's online banking (E). If the TAN is correct, the transfer is authorized. The status of the transfer is stored by the mobile payment service (D) and returned in message 9 to the payment app (B). From the point of view of the customer, the payment process is completed.

The POS system (C) of the merchant also receives from the mobile payment service (D) the status of the payment (message 10). This makes it clear to the trader whether he has been paid successfully or not.

The present payment system may further functions to incentivize the Austrian Patent Office AT 13 561 U1 2014-03-15

Provide customers with incentives to use the payment method. For this purpose, in principle, all known incentivization methods in question - for example, so-called. Repayment procedures in which the customer gets a sales-based commission credited or the collection of bonus points, etc. 8/13

Claims (13)

Austrian Patent Office AT 13 561 U1 2014-03-15 Claims 1. An installation for processing a payment transaction, comprising a mobile terminal (A) with a payment app (B) and a server (F) with a mobile payment service (D ), characterized in that a. the payment app (B) with an external body, in particular a cash register (C), and with the mobile payment service (D) is bidirectionally connectable; b. the payment app (B) is designed for the creation, recording, interpretation and forwarding of payment information, c. the mobile payment service (D) is designed to access an online banking service (E) and initiate a payment process, d. wherein the access data to the online banking service (E) only at the mobile payment service (D) exist. 2. Plant according to claim 1, characterized in that the payment app (B) for receiving and interpreting payment information of an external body is formed, wherein the payment information by a QR code, a bar code, or by NFC technology from an external Job are transferable. 3. Plant according to claim 1 or 2, characterized in that the payment app (B) for receiving a customer identification number and one, the payment process hedging, to be entered by the user PIN is formed. 4. Installation according to one of the preceding claims, characterized in that the payment app (B) for generating the account data of the merchant and the amount to be paid from the received payment information is set up. 5. Installation according to one of the preceding claims, characterized in that the mobile payment service (D) is set up for holding a block list and for checking the payment information and the customer data on occurrences in the block list. 6. A method for processing a payment transaction by means of a mobile terminal (A) with a payment app (B) and a server (F) with a mobile payment service (D), characterized in that the method comprises the steps of: a , Transmission of payment information from an external agency, in particular a cash register (C), to the payment app (B); b. Transmitting at least the payment information from the payment app (B) to the mobile payment service (D); c. Checking payment information for validity and matching against an internal block list at the mobile payment service (D); d. Initiating the payment by accessing the mobile payment service (D) to an online banking service (E); e. Authorization of payment at the mobile terminal (A); f. Send a confirmation of successful payment from the mobile payment service (D) to the external agency and to the payment app (B). 7. The method according to claim 6, characterized in that the transfer of payment information in step a) is carried out by a barcode, a QR code or by NFC technology. 8. The method according to claim 6 or 7, characterized in that the information transmitted in step b) comprises the following information: a. a transaction number; b. a customer identification number stored in the payment app (B); c. a password of the user. 9/13 Austrian Patent Office AT 13 561 U1 2014-03-15 9. The method according to claim 8, characterized in that further access data to an online banking service (E) are transmitted. 10. The method according to any one of claims 6 to 9, characterized in that in step d) further checks whether the user account has sufficient coverage. 11. The method according to any one of claims 6 to 10, characterized in that in step d) the mobile payment service (D) in the online banking service (E) requests the generation and sending a mobile TAN. 12. The method according to any one of claims 6 to 11, characterized in that the payment information in step a) comprise a unique transaction number, which is transmitted from the mobile payment service (D) to the external body or generated directly from the external body. 13. The method according to any one of claims 6 to 12, characterized in that a customer identification number of the payment app (B) to the external body, in particular the cash register (C), in the form of an EAN code, a QR Codes, or using other technologies such as NFC. 3 sheets of drawings 10/13