JP2020170472A - Settlement management device, settlement management method, and terminal - Google Patents

Abstract

To provide a settlement management device, a settlement management method, and a terminal that achieve cashless settlement with a balance between maintaining and improving user convenience and suppressing fraud risk.SOLUTION: In a settlement system, a settlement management device (settlement server) includes: means for acquiring a settlement request indicating a transaction amount and a transaction status; means for determining whether to request settlement approval from a payment side according to the transaction amount and the transaction status indicated by the acquired settlement request; means for requesting approval from a terminal on the payment side via a network if it is determined to request; and means for processing the settlement when settlement is approved at the terminal on the payment side.SELECTED DRAWING: Figure 3

Description

The present invention relates to a payment management device, a payment management method and a terminal.

Electronic money, which used to be like reading a magnetic card such as a telephone card with a dedicated device until several decades ago, has recently become an era in which payment can be completed simply by bringing a wristwatch closer to the ticket gate. Although it has contributed to the development of technology, the spread of high-performance mobile devices such as smartphones and tablet terminals seems to be strongly supporting the spread of cashless payments.

Currently, various cashless payment systems have been proposed (see, for example, Patent Document 1).

Japanese Unexamined Patent Publication No. 2011-043983

One of the issues related to payment is the trade-off between user convenience and fraud risk. In the current system as described in Patent Document 1, it cannot be said that these elements are well-balanced.

The present invention has been made in view of these problems, and an object of the present invention is to provide a technique capable of realizing cashless payment in which maintenance / improvement of user convenience and suppression of fraud risk are balanced.

One aspect of the present invention relates to a payment management device. This payment management device approves the payment to the payer according to the means for acquiring the payment request indicating the transaction amount and the transaction status, and the transaction amount and the transaction status indicated by the acquired payment request. A means of determining whether or not to request, a means of requesting approval from the paying terminal via the network when it is determined to request, and a means of requesting approval at the paying terminal, the payment is executed when the payment is approved. Means to do so.

It should be noted that any combination of the above components and those in which the components and expressions of the present invention are mutually replaced between devices, methods, systems, computer programs, recording media storing computer programs, etc. are also the present invention. It is effective as an aspect of.

According to the present invention, it is possible to realize cashless payment in which the maintenance / improvement of user convenience and the suppression of fraud risk are balanced.

It is a schematic diagram which shows the structure of the payment system which concerns on embodiment. It is a hardware configuration diagram of the payment server of FIG. It is a block diagram which shows the function and structure of the payment server of FIG. It is a data structure diagram which shows an example of a settlement request. It is a data structure diagram which shows an example of the member store management table of FIG. It is a data structure diagram which shows an example of the user management table of FIG. It is a data structure diagram which shows an example of the threshold value setting table of FIG. It is a data structure diagram which shows an example of the transaction management table of FIG. It is a chart which shows the processing and signal flow in the payment system of FIG. It is a representative screen view of the store terminal standby screen displayed on the display of a store terminal. It is a representative screen diagram of the QR code display screen displayed on the display of a user terminal. It is a representative screen view of the settlement approval waiting screen displayed on the display of a store terminal. It is a representative screen diagram of the payment approval screen displayed on the display of the user terminal. It is a representative screen view of the transaction result screen displayed on the display of a store terminal. It is a representative screen diagram of the transaction result screen displayed on the display of the user terminal. It is a representative screen diagram of another form of transaction result screen displayed on the display of a user terminal. It is a representative screen view of the transaction result screen displayed on the display of a store terminal. It is a representative screen diagram of the transaction result screen displayed on the display of the user terminal. It is a representative screen diagram of another transaction result screen displayed on the display of the user terminal. It is a representative screen view of the settlement approval screen which concerns on the 1st modification displayed on the display of a store terminal. It is a representative screen view of the settlement approval waiting screen which concerns on the 1st modification which is displayed on the display of a user terminal. It is a representative screen view of the store terminal standby screen which concerns on the 3rd modification displayed on the display of a store terminal.

Hereinafter, the same or equivalent components, members, processes, and signals shown in the drawings shall be designated by the same reference numerals, and redundant description will be omitted as appropriate. In addition, some of the members that are not important for explanation are omitted in each drawing.

(Embodiment)
FIG. 1 is a schematic diagram showing a configuration of a payment system 1 according to an embodiment. The payment system 1 includes a payment server 10, a user terminal 20, and a store terminal 30. The payment server 10, the user terminal 20, and the store terminal 30 are each connected to a network 40 such as the Internet, and are configured to be able to communicate with each other via the network 40. The configuration shown in FIG. 1 is an example, and the number of user terminals 20 and store terminals 30 is not limited. The payment server 10 may include a plurality of servers.

The payment system 1 is a system that enables cashless payment between the user 22 and the member store. The payment server 10 is managed by an entity that provides a cashless payment service. Both the user 22 and the member store register to use the service in advance, provide the terminal and account information to the service, and receive an ID and password. The user 22 informs the member store clerk 32 that he / she desires cashless payment when conducting a transaction at the member store, for example, when paying for a product or service. In this cashless payment, the user ID that identifies the user 22 from the user terminal 20 to the store terminal 30 communicates (for example, NFC (Near Field Communication), Bluetooth, WiFi, IR (Infrared), etc.) or an image. It is transmitted by (for example, bar code, QR code, etc.). The store terminal 30 adds the transaction amount and the transaction status to the acquired user ID to generate a payment request, and transmits the payment request to the payment server 10 via the network 40. Upon receiving the payment request, the payment server 10 determines whether or not to request the payment side, that is, the user 22 to approve the payment, depending on the transaction amount and the transaction status. If the payment server 10 determines that the request is made, the payment server 10 transmits an approval request to the user terminal 20 via the network 40, and the user terminal 20 determines whether or not to approve the user 22 in response to the received approval request. Inquire. The user terminal 20 returns the result of the inquiry to the payment server 10 via the network 40. When the payment is approved by the user terminal 20, the payment server 10 executes the payment, and if the payment is not approved, the payment server 10 cancels the execution of the payment. The payment server 10 transmits the result of the payment if the payment is executed, and the notification that the payment was not performed if the payment is not executed, to the user terminal 20 and the store terminal 30.

The payment system 1 requests the user 22 to approve the payment when the payment exceeds the threshold value of the set transaction amount. This threshold value is different depending on the payment method and the credit rating rank of the member store. As a result, it is possible to maintain convenience while reducing the risk of fraud, and it is possible to provide a cashless payment service that maintains a balance between the two.

The user terminal 20 which is the paying terminal and the store terminal 30 which is the paying terminal are both mobile terminals (for example, a smartphone, a tablet terminal, a laptop PC, etc.), and both mobile terminals are located between antennas. It is configured to be compatible with both the method of transmitting information by communication and the method of transmitting information by imaging. In particular, the user terminal 20 has a function of transmitting and receiving a user ID to another terminal by NFC, a function of displaying a QR code indicating the user ID in an encoded form on a display, and a QR displayed on the other terminal. It has a function to read the code by an imaging means such as a camera. The store terminal 30 also has a similar function. Communication by NFC may be realized by using a known technique. Information transmission by QR code may be realized by using a known technique.

The user 22 who is a user of the user terminal 20 downloads and installs a payment application program (hereinafter referred to as a payment application) from the download site to the user terminal 20 via the network 40. Alternatively, the payment application may be pre-installed on the user terminal 20. The payment application is provided by a cashless payment service entity. When the payment application is executed by the user terminal 20, the user terminal 20 realizes various functions. Similarly, for the store terminal 30, the member store clerk 32 of the member store downloads and installs the payment application for the member store on the store terminal 30.

FIG. 2 is a hardware configuration diagram of the payment server 10 of FIG. The payment server 10 includes a memory 102, a processor 104, a communication interface 106, a display 108, and an input interface 110. Each of these elements is connected to bus 112 and communicates with each other via bus 112.

The memory 102 is a storage area for storing data and programs. The data or program may be permanently stored in the memory 102 or may be temporarily stored. The processor 104 realizes various functions of the payment server 10 by executing a program stored in the memory 102. The communication interface 106 is an interface for transmitting and receiving data to and from the outside of the payment server 10. The communication interface 106 is connected to the network 40 and exchanges data with the user terminal 20 and the store terminal 30 via the network 40. The display 108 is a device for displaying various information. The input interface 110 is a device for receiving input from the administrator of the payment system 1.

FIG. 3 is a block diagram showing the functions and configurations of the payment server 10 of FIG. Each block shown here can be realized by elements such as the CPU of a computer or a mechanical device in terms of hardware, and can be realized by a computer program or the like in terms of software, but here, it is realized by cooperation between them. It depicts a functional block to be done. Therefore, it will be understood by those skilled in the art who have referred to this specification that these functional blocks can be realized in various forms by combining hardware and software.

The payment server 10 includes a payment request acquisition unit 114, an approval request presence / absence determination unit 116, an approval request unit 118, a payment processing unit 120, a member store management table 122, a user management table 126, and a threshold value setting. Includes table 128 and transaction management table 130.

The settlement request acquisition unit 114 acquires a settlement request indicating the amount of the transaction between the user 22 and the member store and the status of the transaction from the store terminal 30 via the network 40. When the user 22 purchases the product at the member store, the transaction amount is the price of the product, and when the user 22 receives the service provided at the member store, the transaction amount is the consideration for the service. The transaction amount may be acquired by the member store clerk 32 directly inputting to the store terminal 30, or may be acquired from a store device such as a POS wirelessly connected to the store terminal 30. Alternatively, the transaction amount may be input by the store terminal 30 reading the IC tag or barcode of the product. Alternatively, when the user 22 self-reports the price, the transaction amount may be transmitted from the user terminal 20 to the store terminal 30 together with the user ID.

The status of the transaction is the status of the transaction between the user 22 and the member store, for example, how the information was exchanged between the user terminal 20 and the store terminal 30, and which member store. Including whether the transaction was made in. The settlement request includes, as the status of the transaction, the method information that specifies the method of exchanging information between the user terminal 20 and the store terminal 30 in the transaction, and the member store ID that specifies the member store in the transaction. Including. The method information is information indicating whether, for example, information is exchanged between the user terminal 20 and the store terminal 30 via the NFC or the QR code.

FIG. 4 is a data structure diagram showing an example of a payment request. The settlement request includes a member store ID, a transaction amount, a user ID, a transaction ID that identifies the transaction, method information, and other information. The method information is "QR" when the user ID is transmitted from the user terminal 20 to the store terminal 30 by the QR code, and "NFC" when the user ID is transmitted by NFC.

Returning to FIG. 3, the approval request presence / absence determination unit 116 requests the user 22 to approve the settlement according to the transaction amount and the transaction status indicated by the settlement request acquired by the settlement request acquisition unit 114. Is determined. This determination is made according to the magnitude relationship between the threshold value corresponding to the transaction situation and the transaction amount. The details of this determination process will be described later.

When the approval request unit 118 determines that the approval request is requested by the approval request presence / absence determination unit 116, the approval request unit 118 requests the user terminal 20 for approval via the network 40. The approval request unit 118 generates an approval request for requesting approval, and transmits the generated approval request to the user terminal 20 via the network 40. At the same time, when it is determined that approval is requested, the approval requesting unit 118 transmits a response indicating that approval is awaited to the store terminal 30 in response to the payment request from the store terminal 30.

When the payment processing unit 120 determines that the approval request presence / absence determination unit 116 does not request approval, the payment processing unit 120 executes the payment and transmits the execution result (payment amount, etc.) to the user terminal 20 and the store terminal 30 via the network 40. Send. When the payment processing unit 120 determines that the approval request presence / absence determination unit 116 requests approval and the payment is approved by the user terminal 20, the payment processing unit 120 executes the payment and transmits the execution result to the user terminal 20 and the store terminal 30. Send. When the payment processing unit 120 determines that the approval request presence / absence determination unit 116 requests approval and the payment is not approved by the user terminal 20, the payment processing unit 120 cancels the execution of the payment and indicates that the payment has not been performed. Notify the terminal 20 and the store terminal 30.

The payment process in the payment processing unit 120 is a process for electronically moving the transaction amount from the payment account of the user 22 to the payment account of the member store, and is realized by using a known electronic payment technology. You may. The payment may be a prepaid method or a postpaid method. The notification that the payment has been executed to the user terminal 20 or the store terminal 30 may be before, at the same time, or after the actual transfer of funds.

FIG. 5 is a data structure diagram showing an example of the member store management table 122 of FIG. The member store management table 122 specifies the member store ID, the member store name, the credit rating rank of the member store, the IP address of the store terminal 30 which is information for identifying the store terminal 30 of the member store, and the settlement account of the member store. The settlement account ID, which is the information to be used, is associated with and held. The IP address of the store terminal 30 may be other information as long as it is information that can identify the store terminal 30 when transmitting information to the store terminal 30 via the network 40. The member store name, the IP address of the store terminal 30, and the settlement account ID can be obtained by acquiring the one entered by the member store when the member store registers for the service, or by automatically extracting from the store terminal 30. It is registered in the member store management table 122.

The credit rating rank is information indicating the degree of credit of the member store. In this example, it is represented by two values of "high" and "low", and the rank "high" indicates that the credit rating is higher than the rank "low". .. The credit rating is set by the examination of a financial institution such as a bank, and is registered in the member store management table 122 by the service manager. Alternatively, if the financial institution has already determined the creditworthiness of the merchant for other purposes such as financing and registered it in its own system, the credit rating of the merchant management table 122 is automatically calculated by fetching the creditworthiness from that system. May be set.

FIG. 6 is a data structure diagram showing an example of the user management table 126 of FIG. The user management table 126 contains a user ID, a password, a user name, an IP address of the user terminal 20 which is information for identifying the user terminal 20 of the user 22, and a payment account of the user 22. The settlement account ID, which is the specified information, is stored in association with each other. The IP address of the user terminal 20 may be other information as long as it is information that can identify the user terminal 20 when transmitting information to the user terminal 20 via the network 40. The user name, the IP address of the user terminal 20, and the payment account ID are those input by the user 22 when the user 22 registers for the service, or are automatically obtained from the user terminal 20. By extracting, it is registered in the user management table 126.

FIG. 7 is a data structure diagram showing an example of the threshold value setting table 128 of FIG. The threshold value setting table 128 holds the combination of the payment method (QR code / NFC), the credit rating rank (high / low) of the member store, and the threshold value of the amount in association with each other. The threshold value registered in the threshold value setting table 128 may be set and input by the service administrator.

The approval request presence / absence determination unit 116 refers to the member store management table 122, and identifies the credit rating rank corresponding to the member store ID included in the payment request acquired by the payment request acquisition unit 114. The approval request presence / absence determination unit 116 refers to the threshold value setting table 128, and determines the threshold value corresponding to the combination of the payment method indicated by the method information included in the payment request and the specified credit rating rank. The approval request presence / absence determination unit 116 determines that approval is requested when the transaction amount indicated by the settlement request exceeds the determined threshold value, and determines that approval is not requested otherwise.

For example, if a member store's credit rating rank = "low" and a payment of 10,000 yen is executed, if the payment method = "NFC" is executed, payment approval is required, and the payment method = "QR". When executed with "code", approval of payment is not required.

In the example of FIG. 7, the threshold value is set so that the QR code method is larger than the NFC method and the credit rating rank of the member store is higher. In the present embodiment, since the payment request is transmitted from the store terminal 30, it is more important to deal with fraud (falsification, etc.) in the store terminal 30. Therefore, the lower the creditworthiness of a member store, the smaller the threshold value is set to balance the risk of fraud and convenience. In addition, since the NFC method requires less effort, it is easier for the member store to make a payment without obtaining the consent of the user 22 than the QR code method. Therefore, by setting the threshold value of the NFC method smaller, After all, it balances the risk of fraud and convenience.

FIG. 8 is a data structure diagram showing an example of the transaction management table 130 of FIG. The transaction management table 130 shows the transaction ID of the transaction, the member store ID of the member store in the transaction, the user ID of the user in the transaction, the amount of the transaction, the date and time of the transaction, the settlement method in the transaction, and the transaction. Whether or not approval is requested and, if so, whether or not the approval has been obtained are held in association with each other.

The operation of the payment server 10 with the above configuration will be described.
FIG. 9 is a chart showing the processing and signal flow in the payment system 1 of FIG. When the user 22 decides to purchase the product at the member store, the member store clerk 32 inputs the payment amount, that is, the price of the product to the store terminal 30 (S902). The store terminal 30 issues a transaction ID that identifies the transaction (S904), displays the settlement amount and the QR reader screen on the display of the store terminal 30 (S906), and activates the NFC function.

FIG. 10 is a representative screen view of the store terminal standby screen 502 displayed on the display 34 of the store terminal 30. The store terminal 30 causes the display 34 to display the store terminal standby screen 502 in step S906 of FIG. The store terminal standby screen 502 has an amount display area 504 on which the payment amount is displayed and a QR reader screen 506. When the user 22 chooses to make a payment with the QR code, the QR code in which the user ID is encoded is displayed on the display of the user terminal 20. The member store clerk 32 captures the display of the user terminal 20 with the camera of the store terminal 30 to read this QR code into the store terminal 30. Alternatively, when the user 22 chooses to make a payment by NFC, the user ID by NFC from the user terminal 20 to the store terminal 30 as soon as the store terminal 30 and the user terminal 20 enter the NFC possible range. Is transmitted.

FIG. 11 is a representative screen view of the QR code display screen displayed on the display 24 of the user terminal 20. When the user 22 chooses to make a payment with a QR code using a selection interface (not shown) or the like, a QR code display screen is displayed on the display 24. The QR code 508 displayed on the QR code display screen includes information in which the user ID of the user 22 is encoded. Instead of the configuration in which the QR code or the NFC is selected by the selection interface, the payment application may be started when the QR code is used, and the NFC may be used for communication when the payment application is not started.

Returning to FIG. 9, the user information including the user ID is transmitted from the user terminal 20 to the store terminal 30 (S910) by holding the QR code over or by NFC communication (S908). The store terminal 30 contains the received user ID, the member store ID of the member store, the payment amount entered in step S902, the transaction ID issued in step S904, and the method information indicating whether it is an NFC or a QR code. Is generated and transmitted to the payment server 10 via the network 40 (S912).

Upon receiving the payment request, the payment server 10 determines whether or not to request the user 22 for approval by checking the payment method, checking the credit rating of the member store, and checking the payment amount threshold value (). S914). The payment server 10 refers to the member store management table 122, and identifies the credit rating rank of the member store from the member store ID indicated by the payment request. The payment server 10 refers to the threshold value setting table 128, and specifies a threshold value corresponding to the combination of the payment method indicated by the payment request and the specified credit rating rank as the payment amount threshold value. The payment server 10 compares the payment amount indicated by the payment request with the specified payment amount threshold value, and if the former is larger than the latter, it determines that approval is requested, and if not, it determines that approval is not requested. To do.

If it is determined in step S914 that the approval is requested, the payment server 10 suspends the payment until the approval of the payment is received (S916). The payment server 10 also generates a payment response including information indicating that the product is waiting for approval, a message, and the content of the transaction, and transmits the payment response to the store terminal 30 via the network 40 (S918). At this time, the payment server 10 identifies the address of the store terminal 30 by referring to the member store management table 122, and transmits a payment response to the specified address. When the store terminal 30 receives the payment response in step S918, the store terminal 30 displays the payment approval waiting screen on the display 34 (S920).

The payment server 10 generates a transaction result response including information indicating that it is awaiting approval, a message, and the contents of the transaction in accordance with the hold process in step S916, and sends the user terminal 20 via the network 40. Transmit (S922). At this time, the payment server 10 specifies the address of the user terminal 20 by referring to the user management table 126, and transmits a transaction result response to the specified address. Upon receiving the transaction result response in step S922, the user terminal 20 causes the display 24 to display a payment approval screen for approving the payment or inquiring about the user 22 (S924). When communication is performed by NFC without starting the payment application in step S910, the payment application is started in this step S924.

FIG. 12 is a representative screen view of the payment approval waiting screen displayed on the display 34 of the store terminal 30. The message included in the payment response in step S918 is displayed on the payment approval waiting screen. In the example of FIG. 12, the message includes the payment amount threshold specified in step S914, but may not be included in another example.

FIG. 13 is a representative screen view of the payment approval screen 510 displayed on the display 24 of the user terminal 20. The payment approval screen 510 includes a message 512 indicating that approval by the user 22 is required, a rejection button 514 for accepting a manifestation of intention not to approve, and an approval button 516 for accepting a manifestation of intention to approve. Has.

Returning to FIG. 9, the user 22 pushes down (for example, taps or clicks) either the rejection button 514 or the approval button 516 on the payment approval screen 510 (S926). The user terminal 20 generates a payment approval request including approval result information indicating "denial" when the refusal button 514 is specified and "approval" when the approval button 516 is specified, and connects the network 40. It is transmitted to the payment server 10 via (S928).

When the received approval result information indicates "denial", the payment server 10 cancels the execution of payment. When the received approval result information indicates "approval", the payment server 10 releases the hold of payment (S930). The payment server 10 generates a payment approval response indicating whether to execute or cancel the payment in response to the payment approval request received in step S928, and transmits the payment approval response to the user terminal 20 via the network 40 (S932).

When it is determined in step S914 that the approval is not requested, or when the hold is released in step S930, the payment server 10 processes the payment (S932). For example, the payment server 10 refers to the member store management table 122 and identifies the payment account of the member store corresponding to the member store ID included in the payment request received in step S912. The payment server 10 refers to the user management table 126 and identifies the payment account of the user 22 corresponding to the user ID included in the payment request received in step S912. The payment server 10 performs processing for realizing the transfer of money for the payment amount from the payment account of the specified user 22 to the payment account of the specified member store. This process may be, for example, a transfer or transfer request, or may be a transfer or transfer process itself. Alternatively, it may be an arbitrary process that realizes the movement. The settlement server 10 also registers the contents of the executed transaction in the transaction management table 130.

The payment server 10 generates a payment response including information indicating whether or not payment has been executed, a message, and the content of the transaction, and transmits the payment response to the store terminal 30 via the network 40 (S934). When the store terminal 30 receives the payment response in step S934, the store terminal 30 displays the transaction result screen on the display 34 (S936).

The payment server 10 generates a transaction result response including information indicating whether or not payment has been executed, a message, and the content of the transaction, and transmits the transaction result response to the user terminal 20 via the network 40 (S938). When the user terminal 20 receives the transaction result response in step S938, the user terminal 20 displays the transaction result screen on the display 24 (S940).

FIG. 14 is a representative screen view of the transaction result screen displayed on the display 34 of the store terminal 30. This transaction result screen is displayed when the payment response in step S934 indicates that the payment has been executed, and includes a message indicating that the transaction has been completed and a payment amount.

FIG. 15 is a representative screen view of the transaction result screen displayed on the display 24 of the user terminal 20. This transaction result screen is displayed when the payment response in step S938 indicates that the payment has been executed, and includes a message indicating that the transaction has been completed and a payment amount.

FIG. 16 is a representative screen view of another form of transaction result screen displayed on the display 24 of the user terminal 20. In the example of FIG. 16, the completion of the transaction is displayed in the form of a push notification. In particular, a message indicating that the transaction has been completed is displayed in the push notification area 518 of the display 24 of the user terminal 20. In this case, the payment application does not need to be running, so this aspect is suitable when NFC is used in step S910.

FIG. 17 is a representative screen view of the transaction result screen displayed on the display 34 of the store terminal 30. This transaction result screen is displayed when the settlement response in step S934 indicates that the settlement was not executed, and includes a message indicating that the settlement was not executed because the settlement was not approved.

FIG. 18 is a representative screen view of the transaction result screen displayed on the display 24 of the user terminal 20. This transaction result screen is displayed when the settlement response in step S938 indicates that the settlement has not been executed, and includes a message indicating that the settlement has not been executed.

FIG. 19 is a representative screen view of another transaction result screen displayed on the display 24 of the user terminal 20. FIG. 19 is an example of display in the form of a push notification corresponding to FIG.

In the above-described embodiment, examples of the holding unit are a hard disk and a semiconductor memory. In addition, based on the description of this specification, each part is provided by a CPU (not shown), an installed application program module, a system program module, a semiconductor memory that temporarily stores the contents of data read from the hard disk, and the like. What can be achieved is understood by those skilled in the art who have referred to this specification.

According to the payment system 1 according to the present embodiment, when payment of an amount exceeding the threshold value determined by the transaction status is requested, the payer is requested to approve. Also, if the settlement amount does not reach the threshold, such approval is not required and the settlement is executed immediately. As a result, the risk of fraud can be suppressed while maintaining the convenience of cashless payment.

Further, in the payment system 1 according to the present embodiment, the threshold value is set so low that the payment method is simple and does not require time and effort. Therefore, it is possible to optimize convenience and risk control. Further, in the payment system 1, the lower the credit rating of the member store, the lower the threshold value is set. Therefore, it is possible to optimize convenience and risk control.

Further, in the payment system 1 according to the present embodiment, when the NFC is used, the user 22 does not have to start the payment application in advance, so that the payment can be made more smoothly. When the QR code is used, the user 22 can make a smoother payment. Higher payments are possible. This enhances user convenience.

The configuration and operation of the payment system 1 according to the embodiment have been described above. This embodiment is an example, and it will be understood by those skilled in the art that various modifications are possible for each component and each combination of processes, and that such modifications are also within the scope of the present invention.

(First modification)
In the embodiment, the case of inquiring whether or not to approve the user 22 via the user terminal 20 has been described, but the present invention is not limited to this. For example, when it is determined that the payment server 10 requests approval, the payment approval screen may be displayed on the display 34 of the store terminal 30, and the payment approval waiting screen may be displayed on the display 24 of the user terminal 20.

FIG. 20 is a representative screen view of the payment approval screen 520 according to the first modification displayed on the display 34 of the store terminal 30. The payment approval screen 520 has the same configuration as the payment approval screen 510 of FIG. The member store clerk 32 presents the payment approval screen 520 displayed on the display 34 of the store terminal 30 to the user 22, and the user 22 taps any button to approve or deny the payment.

FIG. 21 is a representative screen view of the payment approval waiting screen according to the first modification displayed on the display 24 of the user terminal 20. By seeing this payment approval waiting screen, the user 22 understands that he / she needs to perform the approval process.

(Second modification)
In the embodiment, the case where the user terminal 20 directly transmits the information on whether or not the user 22 approves the payment to the payment server 10 via the network 40 has been described, but the present invention is not limited to this. For example, when the user 22 approves or denies the payment, the user terminal 20 transmits the approval result to the store terminal 30 via NFC, and the store terminal 30 transmits the approval result to the payment server 10 via the network 40. You may send it. This is suitable, for example, when the user terminal 20 is not connected to the network 40 but has an NFC function.

(Third modification example)
In the embodiment, the case where the store terminal 30 transmits the payment request to the payment server 10 has been described, but the present invention is not limited to this. For example, the user terminal 20 generates the payment request and sends the payment request to the payment server 10 via the network 40. You may send it. In this case, the store terminal 30 causes the display 34 to display the store terminal standby screen including the payment amount and the QR code display screen instead of step S906 in FIG.

FIG. 22 is a representative screen view of the store terminal standby screen 522 according to the third modification displayed on the display 34 of the store terminal 30. The store terminal standby screen 522 has an amount display area 504 on which the payment amount is displayed and a QR code display screen 524 on which the QR code is displayed. The QR code displayed on the QR code display screen 524 includes information in which the member store ID of the member store, the payment amount, and the transaction ID are encoded.

When the QR code is used, the user 22 captures the display 34 of the store terminal 30 with the camera of the user terminal 20 to read the QR code into the user terminal 20. The user terminal 20 acquires the member store ID, the payment amount, and the transaction ID of the member store by decoding the captured QR code, and adds the user ID and the payment method (= "QR code") to the acquisition ID. Generate a payment request.

When using NFC, the user 22 brings the user terminal 20 closer to the store terminal 30 without activating the payment application. When the user terminal 20 enters the NFC possible range with the store terminal 30, communication is automatically performed, and the member store ID, the settlement amount, and the transaction ID of the member store are transmitted from the store terminal 30 to the user terminal 20. Will be done.

(Fourth modification)
In the embodiment, the case where the response to the approval request is transmitted from the user terminal 20 to the payment server 10 has been described, but the present invention is not limited to this. For example, in order to further reduce the risk of fraud, information for transaction authentication such as a user ID may be transmitted from the user terminal 20 to the payment server 10 at any stage of the payment process. The payment server 10 executes transaction authentication by matching the information directly received from the user terminal 20 with the information included in the payment request received from the store terminal 30. The payment server 10 may return an error without executing payment if they are different.

For example, when NFC is used in step S910 of FIG. 9, at least one of the member store ID, the payment amount, and the transaction ID may be transmitted from the store terminal 30 to the user terminal 20. The user terminal 20 adds a user ID and a payment method (= "NFC") to the information to generate information for transaction authentication, and transmits the information to the payment server 10 via the network 40. The payment server 10 corresponds to the member store ID, the payment amount, the transaction ID (at least one of them), the user ID, the payment method received from the user terminal 20, and the payment request received from the store terminal 30. Compare with the information. If they all match, the payment server 10 proceeds with the subsequent payment processing such as checking the payment amount, but if any of them is different, the payment is canceled and the user terminal 20 and the store terminal 30 are used. Returns an error to.
Information for transaction authentication may be included in the settlement approval request transmitted in step S928 of FIG.

(Other variants)
In the embodiment, the case where the settlement amount threshold value is set by the combination of the payment method and the credit rating rank of the member store has been described, but the present invention is not limited to this, and for example, it depends on either the payment method or the credit rating rank of the member store. A settlement amount threshold may be set.

In the embodiment, a method based on communication between antennas (for example, NFC) and a method based on imaging (for example, QR code) are adopted as the payment method, but the method is not limited thereto. For example, even in the communication method, the user terminal 20 may be separately subdivided into cases where the user 22 is authenticated by biological information such as voiceprints, glows, veins, and fingerprints, and cases where the user 22 is not authenticated. For example, three types of payment methods may be provided: "biometric authentication completed, NFC", "no biometric authentication, NFC", and "QR code". In this case, the threshold value for the combination of "Biometrically authenticated, NFC" and "Credit rank: High" is set to the highest value, and the threshold value for the combination of "QR code" and "Credit rank: High" is set as follows. May be set high.

In the embodiment, the case of inquiring whether or not to approve the user 22 using the payment approval screen has been described, but the present invention is not limited to this, and for example, the inquiry may be made by voice instead of or in addition to the screen display. In this case, approval or disapproval is also accepted by voice. Similarly, the payment approval standby screen may be notified by voice instead of or in addition to the screen display. This modification is suitable, for example, when either or both of the user terminal 20 and the store terminal 30 are speaker-type terminals having no display.

10 payment servers, 20 user terminals, 30 store terminals, 40 networks.

Claims (13)

A means of obtaining a settlement request indicating the transaction amount and transaction status,
A means of determining whether or not to request payment approval from the payer according to the transaction amount and transaction status indicated by the acquired payment request.
If it is determined to request, a means to request approval from the paying terminal via the network,
A payment management device including means for executing the payment when the payment is approved by the payment terminal. The settlement management device according to claim 1, wherein the determination means determines whether or not approval is requested according to the magnitude relationship between the threshold value corresponding to the transaction situation and the transaction amount. The payment management device according to claim 1 or 2, wherein the payment request includes information that specifies a method of exchanging information between a paying terminal and a paying terminal in the transaction as a transaction status. The payment management device according to any one of claims 1 to 3, wherein the payment request includes information that identifies the payer in the transaction as the status of the transaction. The settlement request is the first information that specifies the method of exchanging information between the paying terminal and the paying terminal in the transaction and the second that specifies the paying side in the transaction. Including information,
The determination means sets a threshold value determined by the method of exchange specified by the first information of the payment request and the degree of credit of the payer specified by the second information of the payment request. The payment management device according to claim 1, wherein it is determined that approval is requested when the transaction amount indicated by the request is exceeded. The method of communication includes a method of communication between antennas and a method of imaging.
A claim in which the threshold value in the determination means is set so that the method based on imaging is larger than the method based on communication between antennas, and the higher the degree of credit on the payer side, the larger the threshold value. The payment management device according to 5. The payment management device according to claim 6, wherein both the paying terminal and the paying terminal are mobile terminals, and both mobile terminals can support both the method of communication between antennas and the method of imaging. Obtaining a settlement request indicating the transaction amount and transaction status,
Determining whether or not to request payment approval from the payer according to the transaction amount and transaction status indicated by the acquired payment request.
If it is determined to request, request approval from the paying terminal via the network,
A payment management method including executing the payment when the payment is approved by the payment terminal. A function to acquire a settlement request indicating the transaction amount and transaction status,
A function to determine whether or not to request payment approval from the payer according to the transaction amount and transaction status indicated by the acquired payment request,
A function to request approval from the paying terminal via the network when it is determined to request,
A computer program for realizing a function of executing the payment when the payment is approved at the terminal on the payment side in the payment management device. On the paying terminal in the transaction,
A function to convey information that identifies the payer to the payer's terminal by communication or image,
A function of receiving a request for approval of payment related to a transaction from the payment management device according to any one of claims 1 to 7 via a network.
A function to ask the payer whether to approve the payment related to the received request by voice or image, and
A computer program for realizing a function of transmitting a response indicating the result of an inquiry to the payment management device via a network. It is the terminal on the paying side in the transaction
A means of communicating information that identifies the payer to the payer's terminal by communication or image,
A means for receiving a request for approval of payment related to a transaction from the payment management device according to any one of claims 1 to 7 via a network.
A means of asking the payer whether to approve the payment for the received request by voice or image,
A terminal including a means for transmitting a response indicating the result of an inquiry to the payment management device via a network. To the paying terminal in the transaction,
A function to acquire information that identifies the payer by communication or image,
A function of transmitting a payment request indicating the transaction amount and the transaction status to the payment management device according to any one of claims 1 to 7 via a network.
A computer program for realizing a function of notifying the payer of awaiting approval by voice or image when the payer is requested to approve the settlement related to the transaction. The payee's terminal in the transaction
A means of obtaining information that identifies the payer by communication or image,
A means for transmitting a payment request indicating the transaction amount and the transaction status to the payment management device according to any one of claims 1 to 7 via a network.
A terminal provided with a means for notifying the payer of awaiting approval by voice or image when the payer is requested to approve the settlement related to the transaction.

Images