JP7022108B2 - Payment processing method and payment processing device - Google Patents

Description

The present invention relates to a payment processing method and a payment processing device.

Code payment using a two-dimensional bar code such as a QR code (registered trademark) has become widespread (see, for example, Patent Document 1 and Patent Document 2). In the code payment, the payment is made by reading the two-dimensional bar code displayed by the store side by the user terminal or by reading the two-dimensional bar code displayed by the user terminal by the store side.

Japanese Patent No. 6528160 Japanese Patent No. 6473539

In the conventional code payment, if it is determined that the balance of the account corresponding to the code payment is less than the payment amount after the two-dimensional bar code is read, an error message etc. is displayed and the payment is interrupted, so that the payment is completed. There was a problem that it took time to be interrupted.

Therefore, the present invention has been made in view of these points, and if it is determined that there is a high possibility that the balance of the account will be insufficient before the settlement is started, the settlement can be promptly interrupted. It is an object of the present invention to provide a processing method and a payment processing device.

In the payment processing method according to the first aspect of the present invention, user identification information for identifying a user who has made a request for issuance of the code in relation to a payment means using a code executed by a computer is transmitted from the terminal of the user. The step of acquiring, the step of determining whether or not the account associated with the payment means of the user corresponding to the acquired user identification information satisfies a predetermined condition indicating a state in which payment is possible, and the step that the account is said to be said. The present invention comprises a step of generating a token relating to the code corresponding to the user displayed on the terminal of the user when it is determined that a predetermined condition is satisfied.

The payment processing device according to the second aspect of the present invention includes an acquisition unit that acquires user identification information that identifies a user who has made a request for issuance of the code in relation to a payment means using the code from the terminal of the user. A determination unit for determining whether or not the account associated with the payment means of the user corresponding to the user identification information acquired by the acquisition unit satisfies a predetermined condition indicating a state in which payment is possible, and the account. It includes a token generation unit that generates a token related to the code corresponding to the user displayed on the terminal of the user when the determination unit determines that a predetermined condition is satisfied.

According to the present invention, there is an effect that the settlement can be promptly interrupted when there is a high possibility that the balance of the account will be insufficient at the time of settlement.

It is a figure which shows the outline of the payment processing apparatus. It is a figure which shows the functional structure of the payment processing apparatus. It is a figure which shows the functional structure of a user terminal. It is a figure which shows the functional structure of a store terminal. It is a diagram showing the relationship between the account balance when the balance of the user's account in code payment is insufficient, the payment amount, the payment limit of the second payment method, the deposit amount to the account, and the billing amount of the second payment method. be. It is a flowchart which shows the flow of processing until the payment processing apparatus makes a payment. It is a flowchart which shows the flow of processing when the balance of the account associated with the code payment is insufficient in the payment processing apparatus. It is a figure explaining the flow of processing when a user terminal sends a payment request to a payment processing device.

[Overview of payment processing device 1]
FIG. 1 is a diagram showing an outline of the payment processing device 1. The payment processing device 1 is a computer that makes a payment when a user purchases a product, in response to receiving a payment code corresponding to the payment amount of the product from the user terminal 2 or the store terminal 3. The payment code is a text or an image that can be read by the user terminal 2 or the store terminal 3, and is a code used at the time of payment.

The payment processing device 1 is connected to the user terminal 2 and the store terminal 3 via a communication network such as a mobile phone network and the Internet. The user terminal 2 is a mobile terminal used by the user, for example, a smartphone, a wearable device, a tablet, or a personal computer. The store terminal 3 is, for example, a POS terminal.

Hereinafter, the flow until the payment of the product price is made will be described with reference to an example in which the payment is made by the code payment. FIG. 1 shows an example in which payment is performed according to the fact that the store terminal 3 has read the payment code and is specified by the payment processing device 1. In the present embodiment, the code payment as the first payment means is associated with the payment means for paying the amount in the payment processing device 1. In the present embodiment, it is assumed that the payment method associated with the first payment method is associated with a prepaid account payment method in which the balance is managed in a prepaid account and the payment amount is paid from the balance. The prepaid account may be associated with a prepaid card held by the user.

First, the user performs an operation for displaying the payment code on the user terminal 2 when purchasing a product at a store. The user terminal 2 transmits a payment code acquisition request and a user ID to the payment processing device 1 ((1) in FIG. 1).

When the payment processing device 1 receives the payment code acquisition request and the user ID from the user terminal 2, the user's account associated with the code payment as the first payment means associated with the user ID. Determines whether or not the first condition (predetermined condition) indicating the state in which settlement is possible is satisfied. Here, the first condition is that the balance of the account is equal to or greater than the predetermined amount. That is, the payment processing device 1 determines whether or not the balance of the user's account is equal to or greater than a predetermined amount ((2) in FIG. 1).

When the payment processing device 1 determines that the balance of the user's account is equal to or greater than a predetermined amount, the payment processing device 1 generates a payment token ((3) in FIG. 1). Here, the predetermined amount is, for example, 0 yen. The payment token is a data string that is issued one-time in response to a code acquisition request and is used when the user terminal 2 generates a payment code presented by the user to the store. The payment processing device 1 stores the generated payment token in association with the user ID in the storage medium. The payment token may include at least one of payment business information that identifies the payment business operator that owns the payment processing device 1 and expiration date information that indicates the expiration date of the payment token. Further, the payment processing device 1 may store the time when the payment token is generated in association with the payment token.

The payment processing device 1 transmits the generated payment token to the user terminal 2 ((4) in FIG. 1). The payment processing device 1 may transmit the encrypted payment token to the user terminal 2 after encrypting the payment token.

The user terminal 2 generates and displays a payment code based on the received payment token ((5) in FIG. 1).
The store terminal 3 reads the payment code displayed on the user terminal 2 by, for example, an image pickup operation of a store clerk ((6) in FIG. 1). The store terminal 3 transmits a payment request including a store ID, payment information including a payment amount paid by the user, and a payment token indicated by the read payment code to the payment processing device 1 ((7) in FIG. 1). ). The payment information may include information about the product to be paid. Further, the store ID may be information that can identify individual terminals installed in the store. Further, the store ID may include store brand information that identifies the store name and brand.

When the payment processing device 1 acquires a payment request from the store terminal 3, the store identified by the store ID included in the received payment request is settled as a store that can use code payment (a member store of code payment). It is determined whether or not the device 1 is registered, and if it is determined that the device 1 is registered, the balance of the user's account corresponding to the code payment as the first payment means associated with the payment token is specified. do. Then, the payment processing device 1 determines whether the balance of the user's account corresponding to the code payment as the first payment means associated with the payment token included in the payment request is equal to or greater than the payment amount (). (8) in FIG. The payment processing device 1 uses the payment amount indicated by the payment information included in the received payment request as the payment amount used for this determination.

The payment processing device 1 settles the payment amount when the balance of the user's account corresponding to the code payment is equal to or greater than the payment amount, and when the balance of the account is less than the payment amount, the payment processing device 1 is associated with the user. It is determined whether the second payment means satisfies the second condition ((9) in FIG. 1).

When the payment processing device 1 determines that the second payment means satisfies the second condition, the payment processing device 1 allows the balance of the user's account in the code payment to be insufficient, and setstle the payment amount by the code payment (FIG. 1 (10)). Here, the payment processing device 1 does not deposit money into the user's account when executing payment. As a result, the balance of the user's account becomes less than 0 yen. In this embodiment, an example in which the balance of the user's account is less than 0 yen will be described, but the present invention is not limited to this. The balance of the user's account may be set to 0 yen, the balance of the user's debt may be managed, and information indicating that the user has debt may be associated.

After that, when the product is purchased with the balance of the user's account being less than 0 yen and the user performs an operation for displaying the payment code on the user terminal 2, the user terminal 2 requests acquisition of the payment code. And the user ID are transmitted to the payment processing device 1 ((1) in FIG. 1).

When the payment processing device 1 receives the payment code acquisition request and the user ID from the user terminal 2, the user's account associated with the code payment as the first payment means associated with the user ID. It is determined whether or not the balance of is equal to or greater than the predetermined amount ((2) in FIG. 1). Here, since the balance of the user's account is less than 0 yen, the payment processing device 1 sends an error message indicating that the payment code cannot be displayed to the user terminal 2 without generating the payment token. .. The user terminal 2 displays the received error message.

By operating as described above, the payment processing device 1 can promptly suspend the payment when there is a high possibility that the balance of the account will be insufficient at the time of payment. As a result, the user can promptly take measures such as switching to cash payment or depositing money in the account.

In addition, since auto-charging, which is generally performed, is automatically credited to the account when the balance is insufficient, it is difficult for the user to grasp how much money has been consumed, and the upper limit of money consumption is set. It may not be suitable for users who want to manage it. On the other hand, the payment processing device 1 allows the balance to be insufficient without automatically depositing to the account even if the balance is insufficient at the time of payment, and the payment amount is settled by code payment, and the payment amount is settled from the next time onward. At the time of payment, an error message indicating that the payment code cannot be displayed is displayed. This makes it possible for a user who uses a prepaid account that seeks management of money consumption to recognize that the balance of the account is insufficient. This makes it easier for the user to manage money consumption.
Hereinafter, the details of the configuration of the payment processing device 1, the user terminal 2, and the store terminal 3 will be described.

[Functional configuration of payment processing device 1]
FIG. 2 is a diagram showing a functional configuration of the payment processing device 1. The payment processing device 1 has a communication unit 11, a storage unit 12, and a control unit 13.

The communication unit 11 is a communication interface for transmitting and receiving data to and from the user terminal 2 and the store terminal 3 via a network such as the Internet.

The storage unit 12 is a storage medium for storing various types of data, and includes a ROM (Read Only Memory), a RAM (Random Access Memory), a hard disk, and the like. The storage unit 12 stores a program executed by the control unit 13. The storage unit 12 has the control unit 13, the setting unit 131, the issuance request acquisition unit 132, the first determination unit 133, the token generation unit 134, the transmission unit 135, the settlement request acquisition unit 136, the second determination unit 137, and the settlement unit 138. , And a payment processing program that functions as a notification unit 139.

Further, the storage unit 12 stores the account information associated with the user ID of the user and the prepaid account of the user associated with the code payment. Further, the storage unit 12 stores the user ID of the user in association with the information for specifying the second payment means of the user.

The second payment method is, for example, carrier payment, credit card payment, etc., which is a payment method in which a business operator providing a communication service charges a usage fee for various services together with a communication fee related to the use of a mobile phone network. It is a postpaid settlement. Here, the business operator that receives the payment request for code payment and the business operator that provides a service different from the code payment (the business operator that provides the communication service, the business operator that provides the second payment method) are the same business. Is a person.

The information for specifying the second payment means is, for example, a contract ID for identifying a contract related to carrier payment, and a credit card card number. The information for specifying the second payment means is arbitrarily registered in the payment processing device 1 by the user, and the information for specifying the second payment means is associated with the user. It is assumed that there is a user who has not been.

The control unit 13 is, for example, a CPU (Central Processing Unit). By executing the payment processing program stored in the storage unit 12, the control unit 13 executes the setting unit 131, the issuance request acquisition unit 132, the first determination unit 133, the token generation unit 134, the transmission unit 135, and the payment request acquisition. It functions as a unit 136, a second determination unit 137, a settlement unit 138, and a notification unit 139. The details of the operation of each part of the control unit 13 will be described later.

[Functional configuration of user terminal 2]
FIG. 3 is a diagram showing a functional configuration of the user terminal 2. The user terminal 2 has an operation unit 21, a communication unit 22, a display unit 23, a storage unit 24, and a control unit 25. The control unit 25 includes an operation reception unit 251, a request transmission unit 252, and a code generation unit 253.

The operation unit 21 is an operation device that accepts user operations, and is, for example, a touch panel provided on the surface of the display unit 23. The operation unit 21 notifies the operation reception unit 251 of a signal indicating the position touched by the user.

The communication unit 22 is, for example, a wireless communication interface for transmitting / receiving data to / from a base station of a mobile phone network. The communication unit 22 inputs the payment token or the like received from the payment processing device 1 into the code generation unit 253.

The display unit 23 is a display that displays various types of information. The display unit 23 displays the payment code based on the control of the code generation unit 253.

The storage unit 24 is a storage medium including a ROM, RAM, and the like. The storage unit 24 stores a program executed by the control unit 25. The storage unit 24 stores a program that causes the control unit 25 to function as an operation reception unit 251, a request transmission unit 252, and a code generation unit 253. Further, the storage unit 24 stores the payment token received from the payment processing device 1, the payment code generated based on the payment token, and the like.

The control unit 25 is, for example, a CPU, and functions as an operation reception unit 251, a request transmission unit 252, and a code generation unit 253 by executing a program stored in the storage unit 24.

The operation reception unit 251 specifies the operation content of the user based on the signal input from the operation unit 21. When the specified operation content is an operation for displaying the payment code on the user terminal 2, the operation reception unit 251 notifies the request transmission unit 252 of the operation content. When the operation reception unit 251 receives an operation for displaying the payment code on the user terminal 2, the request transmission unit 252 receives the user ID and the payment code acquisition request via the communication unit 22. It is transmitted to the payment processing device 1.

Upon receiving the payment token transmitted by the payment processing device 1, the code generation unit 253 generates a payment code based on the payment token. The code generation unit 253 generates, for example, a payment code based on a predetermined rule. The code generation unit 253 causes the display unit 23 to display the generated payment code.

[Functional configuration of store terminal 3]
FIG. 4 is a diagram showing a functional configuration of the store terminal 3. The store terminal 3 is, for example, a POS terminal, and has an operation unit 31, a reading unit 32, a communication unit 33, a display unit 34, a storage unit 35, and a control unit 36.

The operation unit 31 is an operation device that accepts the user's operation, for example, a button for selecting a product to be purchased by the user, or a touch panel provided on the surface of the display unit 34.

The reading unit 32 is, for example, a bar code reader and a camera, and reads a bar code attached to a product purchased by the user or a payment code displayed by the user terminal 2. The reading unit 32 outputs the information indicated by the read barcode and the payment code to the control unit 36.

The communication unit 33 is, for example, a communication interface for transmitting / receiving data to / from the payment processing device 1. The communication unit 33 transmits a payment request including a payment token, payment information, and a store ID to the payment processing device 1 under the control of the control unit 36.

The display unit 34 is a display that displays various types of information. The display unit 34 displays, for example, the settlement amount.

The storage unit 35 is a storage medium including a ROM, RAM, and the like. The storage unit 35 stores a program executed by the control unit 36. The storage unit 35 stores a program that causes the control unit 36 to function as a payment information generation unit 361, a token acquisition unit 362, and a payment information transmission unit 363. Further, the storage unit 35 stores a product DB in which the product ID and the price of the product are associated with each other.

The control unit 36 is, for example, a CPU, and functions as a payment information generation unit 361, a token acquisition unit 362, and a payment information transmission unit 363 by executing a program stored in the storage unit 35.

The payment information generation unit 361 identifies one or more products to be settled and generates payment information. Specifically, the payment information generation unit 361 acquires the product ID input by the clerk in the operation unit 31 or the product ID read from the bar code attached to the product by the reading unit 32, so that the acquired product ID can be obtained. Identify the product as the product to be settled. The payment information generation unit 361 refers to the product DB stored in the storage unit 35, and specifies the price of the product associated with the acquired product ID. The payment information generation unit 361 acquires one or more product IDs input by the clerk in the operation unit 31 or the product ID read from the barcode attached to the product by the reading unit 32, and obtains the price of the product specified from the product ID. Tally. When the settlement information generation unit 361 receives the settlement operation in the operation unit 31, the settlement information generation unit 361 determines the total price of the product as the settlement amount. The payment information generation unit 361 generates payment information including the determined payment amount. The payment information may include information about the product specified by the product ID, for example, the attribute, name, manufacturer, and seller of the product.

The token acquisition unit 362 acquires the information extracted from the payment code as a payment token by the reading unit 32 reading the payment code displayed on the user terminal 2.

In the payment information transmission unit 363, when the payment information generation unit 361 generates payment information and the token acquisition unit 362 acquires the payment token, the payment token, the payment information, and the store ID are displayed via the communication unit 33. Is transmitted to the payment processing device 1.

[Operation of each part of control unit 13]
Subsequently, the operation of each unit of the control unit 13 will be described.
The setting unit 131 sets a predetermined amount of money to be used for determining whether or not to display the payment code for code payment on the user terminal 2. For example, the setting unit 131 acquires information for setting a predetermined amount from a business operator that provides a service related to code payment, and sets a predetermined amount based on the information. The setting unit 131 stores information indicating a predetermined amount of money in the storage unit 12.

The setting unit 131 may set a predetermined amount up to a predetermined amount. By doing so, the payment processing device 1 can suppress that the payment code cannot be displayed even though the balance of the account exceeds the payment amount.

Further, the predetermined amount is common to a plurality of users, but is not limited to this, and may be different for each of the plurality of users. In this case, the setting unit 131 may acquire the user ID and the information for setting the predetermined amount from the user terminal 2 via the communication unit 11 and set the predetermined amount based on the information. Then, when the setting unit 131 acquires the user ID and the information for setting the predetermined amount of money, the user ID and the information indicating the predetermined amount of money may be associated with each other and stored in the storage unit 12. In this case, the setting unit 131 may set a predetermined amount corresponding to a user who has not set a predetermined amount as a predetermined amount set by a business operator providing a service related to code payment.

The issuance request acquisition unit 132 acquires a user ID that identifies a user who has made a payment code issuance request in connection with code payment from the user terminal 2. Specifically, the issuance request acquisition unit 132 acquires a user ID by acquiring an issuance request for a payment code including a user ID from the user terminal 2.

The first determination unit 133 determines whether or not the first determination condition indicating the state in which the account associated with the code payment of the user corresponding to the user ID acquired by the issuance request acquisition unit 132 can be settled is satisfied. The first condition is that the balance of the account is equal to or greater than the predetermined amount set by the setting unit 131. The first determination unit 133 determines whether or not the balance of the account associated with the user's code payment corresponding to the user ID acquired by the issuance request acquisition unit 132 is equal to or greater than the predetermined amount set by the setting unit 131.

Specifically, first, the first determination unit 133 identifies the balance of the user's account stored in the storage unit 12 in association with the user ID acquired by the issuance request acquisition unit 132. Further, the first determination unit 133 specifies a predetermined amount of money corresponding to the user ID acquired by the issuance request acquisition unit 132. For example, the first determination unit 133 determines whether or not the information indicating the predetermined amount of money associated with the user ID acquired by the issuance request acquisition unit 132 is stored in the storage unit 12. When the information indicating the predetermined amount of money associated with the user ID is stored in the storage unit 12, the first determination unit 133 specifies the predetermined amount of money based on the information. When the information indicating the predetermined amount of money associated with the user ID is not stored in the storage unit 12, the first determination unit 133 specifies the predetermined amount of money set by the business operator providing the service related to the code payment. Then, the first determination unit 133 determines whether or not the balance of the specified account is equal to or greater than the specified predetermined amount.

When the first determination unit 133 determines that the user's account does not satisfy the first condition, the token generation unit 134 does not generate a payment token related to the code corresponding to the user displayed on the user terminal 2. When the first determination unit 133 determines that the user's account satisfies the first condition, a settlement token is generated. Specifically, when the first determination unit 133 determines that the balance of the user's account is less than the predetermined amount, the token generation unit 134 does not display the payment code corresponding to the user on the user terminal 2 and determines the predetermined amount. When it is determined as above, the user terminal 2 is made to display the payment code corresponding to the user. Further, the token generation unit 134 and the transmission unit 135 function as a notification unit, and when the first determination unit 133 determines that the balance of the user's account is less than a predetermined amount, the token generation unit 134 and the transmission unit 135 notify the user that the balance is insufficient. do.

More specifically, first, the token generation unit 134 generates a payment token for generating a payment code when it is determined that the balance of the user's account is equal to or more than a predetermined amount. Then, the token generation unit 134 associates the generated payment token with the user ID and stores it in the storage unit 12. When the token generation unit 134 generates a payment token, the transmission unit 135 transmits the payment token to the user terminal 2 that has transmitted the payment code issuance request, and causes the user terminal 2 to display the payment code.

Further, the token generation unit 134 generates balance shortage information indicating that the balance is insufficient when it is determined that the balance of the user's account is less than the predetermined amount. The balance shortage information includes the balance of the current account and a message indicating that the payment code is not displayed due to the balance shortage.

When the token generation unit 134 generates the balance shortage information, the transmission unit 135 causes the user terminal 2 to display the payment code by transmitting the balance shortage information to the user terminal 2 that has sent the payment code issuance request. Instead, display the balance shortage information. By doing so, the user recognizes that the payment code is not displayed due to insufficient balance, and makes payment by other payment means such as cash, deposits money into the account, etc. You can take action.

The token generation unit 134 and the transmission unit 135 notify the user that the balance is insufficient when the first determination unit 133 determines that the balance of the user's account is less than the predetermined amount, but this is not limited to this. do not have. When the first determination unit 133 determines that the balance of the user's account is less than the predetermined amount, the token generation unit 134 and the transmission unit 135 may notify the user of information prompting the user to deposit money into the account. In this case, the token generation unit 134 includes the information for prompting the payment to the account in the balance shortage information, and the transmission unit 135 transmits the balance shortage information to the user terminal 2.

Further, the token generation unit 134 and the transmission unit 135 do not display the payment code corresponding to the user on the user terminal 2 when the first determination unit 133 determines that the balance of the user's account is less than the predetermined amount. However, it is not limited to this. When the user is set to automatically deposit money into the account when the balance of the account becomes a set amount lower than the predetermined amount, the token generation unit 134 and the transmission unit 135 are set to the user terminal 2. May display the payment code corresponding to the user.

For example, if the user has set the predetermined amount to 2000 yen and has set the auto charge to automatically deposit when the balance of the account is less than 1000 yen, the token generation unit 134 , Generate payment tokens even if the balance of the account is lower than the specified amount. Then, when the token generation unit 134 generates the payment token, the transmission unit 135 transmits the payment token to the user terminal 2 and displays the payment code. By doing so, the payment processing device 1 displays the payment code when the user has set the auto charge, even though there is a high possibility that the shortage of the balance will be solved by the auto charge. It is possible to prevent the code payment from becoming impossible.

The payment request acquisition unit 136 indicates the store ID, payment information including the payment amount paid by the user, and the payment code from the store terminal 3 that reads the payment code displayed by the user terminal 2 based on the payment token. A payment request including a payment token and corresponding to a code payment as a first payment means is acquired.

The second determination unit 137 determines whether or not the balance of the user's account corresponding to the code payment, which is associated with the payment token included in the payment request and is stored in the storage unit 12, is less than the payment amount. .. Specifically, the second determination unit 137 determines whether or not the store ID included in the payment request acquired by the payment request acquisition unit 136 is registered as the store ID of the member store of the code payment. For example, the storage unit 12 stores a store where code payment can be used, that is, a store ID of a member store of code payment. The second determination unit 137 refers to the storage unit 12 and determines whether or not the store ID included in the payment request is registered as the store ID of the member store of the code payment. When the second determination unit 137 determines that the store ID of the member store is registered, the user corresponding to the code payment, which is stored in the storage unit 12 in association with the payment token included in the payment request. Identify the balance of your account. Then, the second determination unit 137 determines whether or not the second payment means associated with the user satisfies the second condition when the balance of the user's account is less than the payment amount.

The second condition is that, for example, the difference between the payment amount and the balance of the user's account can be settled by the second payment means. That is, the second determination unit 137 requests the determination device for determining whether or not the second payment means can be used when the balance of the user's account associated with the code payment is less than the payment amount. (Authorization request). When the determination device receives the payment limit allocation request, it determines the effectiveness of the second payment method and whether or not the usage limit is reached, and when it determines that the payment frame allocation is possible, the payment limit allocation request. The approval information indicating the approval (authorization approval) is transmitted to the payment processing device 1. The second determination unit 137 can settle the difference between the payment amount and the balance of the user's account by the second payment means associated with the user by determining whether or not the approval information has been acquired from the determination device. It is determined whether or not it is.

The second condition is that the difference between the payment amount and the balance of the user's account can be settled by the second payment means, but the present invention is not limited to this. The second condition may be that the user is associated with a second payment instrument.

The settlement unit 138 setstles the payment amount based on the settlement request. Specifically, when the balance of the user's account is equal to or greater than the payment amount, the settlement unit 138 subtracts the payment amount indicated by the payment information included in the payment request from the balance of the user's account corresponding to the code payment. And make a payment.

Further, when the payment unit 138 determines that the second payment means satisfies the second condition when the balance of the user's account is less than the payment amount, the second determination unit 137 determines that the user's account in the code payment Allow the balance to run short and settle the payment amount by code payment.

Specifically, when the second determination unit 137 acquires the approval information indicating the approval of the allocation request of the settlement frame (authorization approval) from the determination device, the settlement unit 138 receives the settlement request acquired by the settlement request acquisition unit 136. The payment amount indicated by the payment information included in the payment request is subtracted from the balance of the user's account with the user ID stored in the storage unit 12 associated with the included payment token. Since the balance of the account is less than the payment amount, the balance of the account after subtracting the payment amount is less than 0 yen. Further, since the settlement unit 138 subtracts the payment amount in response to the settlement processing device 1 obtaining the approval of the settlement slot allocation request from the determination device, the business operator who operates the code settlement allocates the payment amount. It is possible to allow the user's account to run out of balance, using the payment limit that was made as collateral.

After that, the settlement unit 138 executes a process of depositing the payment amount into the account of the store specified by the store ID included in the settlement request. Here, the settlement unit 138 may deposit an amount obtained by subtracting the settlement fee in the settlement processing device 1 from the payment amount into the store account.

When the settlement of the settlement amount is completed, the notification unit 139 notifies the store terminal 3 of the settlement completion information indicating that the settlement is completed. Further, when the payment of the payment amount is completed, the notification unit 139 notifies the user terminal 2 of the payment completion information indicating that the payment is completed.

When the balance of the user's account corresponding to the code payment is insufficient, the notification unit 139 has insufficient the balance of the user's account corresponding to the code payment after the payment amount is settled by the payment unit 138. Notify the user of payment completion information, including information indicating that they are present. For example, the notification unit 139 sends payment completion information including information indicating that the balance of the user's account corresponding to the code payment is insufficient to the user terminal 2 that is the sender of the payment token. Notify the user of the information.

When the balance of the user's account associated with the code payment is less than the payment amount, the notification unit 139 uses the second payment method associated with the user to determine the difference between the payment amount and the balance of the user's account. When it is determined that payment is possible, the user may be notified of information prompting the setting of the second payment means as the payment means corresponding to the first payment means. By doing so, the user can switch the payment means corresponding to the first payment means to the payment means of the payment means that can be settled, and proceed with the payment without delay.

The notification unit 139, as information indicating that the balance of the user's account corresponding to the code payment is insufficient, for example, the difference between the balance before the payment of the payment amount is made and the payment amount, that is, the payment amount Notify the user of the shortfall in making payments. Further, the notification unit 139 notifies the user of the information indicating that the balance of the user's account corresponding to the code payment is insufficient and the information prompting the user to make a payment to the user's account associated with the code payment. By doing so, the user can recognize that the balance of the user's account is insufficient and the insufficient amount, and can make a deposit to the account.

The settlement unit 138 requests the second settlement means to allocate a settlement slot corresponding to the difference between the balance before subtracting the payment amount and the payment amount, and then the account of the user associated with the code settlement. When an amount equal to or greater than the difference between the balance and the payment amount is deposited, the second payment means is requested to cancel the allocation of the payment limit. Here, the deposit of the amount may be the deposit of the amount converted from the points that can be used as the payment consideration at the time of purchasing the product.

Further, the settlement unit 138 requests the second settlement means to allocate a settlement slot corresponding to the difference between the balance before subtracting the payment amount and the payment amount, and then the account of the user associated with the code settlement. If the balance of the above is insufficient for a predetermined period, the second payment means is charged with the amount corresponding to the payment limit. In this case, the settlement unit 138 charges the user the amount corresponding to the payment limit together with the billing of the usage amount of the service used by the user whose second payment means is the payment means, and charges the balance of the account. By setting it to 0 yen, the shortage of the balance of the account will be resolved.

Here, the notification unit 139 may notify the user that the amount corresponding to the payment limit has been charged to the user together with the request for the usage amount of the service. Further, the notification unit 139 may notify the user that the shortage of the account balance has been resolved as the amount corresponding to the payment limit has been charged to the user.

FIG. 5 shows the relationship between the account balance, the payment amount, the payment limit of the second payment method, the deposit amount to the account, and the billing amount of the second payment method when the balance of the user's account in the code payment is insufficient. It is a figure which shows. FIG. 5 (a) shows an example in which the balance of the user's account in the code payment is insufficient and the payment is made to the account within a predetermined period, and FIG. 5 (b) shows the example of the user's account in the code payment. It shows an example in which payment to the account was not made within a predetermined period after the balance was insufficient. The unit of the amount shown in FIG. 5 is assumed to be yen.

For example, as shown in FIGS. 5A and 5B, it is assumed that the balance of the user's account in the code payment before the user purchases the product is 300 yen, and the payment amount at the time of purchasing the product is 700. It is assumed that it was a circle. In this case, the settlement unit 138 allows the balance of the user's account in the code settlement to be insufficient, setstles the payment amount by the code settlement, and before subtracting the payment amount to the second settlement means. Request the allocation of a settlement limit of the amount corresponding to the difference between the balance and the payment amount. As a result, the balance of the account becomes -400 yen, and 400 yen is allocated as a settlement limit.

After that, as shown in FIG. 5A, if the user's account for code payment has a deposit of 1000 yen within a predetermined period, the balance of the account becomes 600 yen, the shortage state is resolved, and the payment limit is set. The allocation will be canceled and the amount of the allocated settlement limit will be 0 yen.

On the other hand, as shown in FIG. 5 (b), if there is no deposit in the user's account in the code payment within a predetermined period, the shortage amount (400 yen) in the balance of the account is charged to the second payment means. .. In addition, the balance of the account is changed to 0 yen in response to the request to the second payment means.

[Processing flow in payment processing device 1]
Subsequently, the flow of processing in the payment processing device 1 will be described. First, the flow of processing until the payment processing device 1 makes a payment will be described. FIG. 6 is a flowchart showing a processing flow until the payment processing device 1 makes a payment.

First, the issuance request acquisition unit 132 acquires a payment code issuance request from the user terminal 2 (S1). The issuance request includes the user ID of the user of the user terminal 2.
Subsequently, in the first determination unit 133, the balance of the account associated with the code payment of the user corresponding to the user ID included in the issuance request acquired by the issuance request acquisition unit 132 is set by the setting unit 131. It is determined whether or not the amount is equal to or more than the predetermined amount (S2). When the first determination unit 133 determines that the balance of the account is equal to or greater than the predetermined amount, the process is transferred to S3, and when it is determined that the balance of the account is less than the predetermined amount, the process is transferred to S6.

In S3, the token generation unit 134 generates a settlement token. Then, the token generation unit 134 associates the generated payment token with the user ID included in the issuance request and stores it in the storage unit 12 (S4).
The transmission unit 135 transmits a payment token to the user terminal 2 that has sent the payment code issuance request (S5). As a result, the payment code is displayed on the user terminal 2.

In S6, the token generation unit 134 generates balance shortage information indicating that the balance of the user's account is short.
The transmission unit 135 transmits the balance shortage information to the user terminal 2 that has transmitted the payment code issuance request (S7).

After the payment token is transmitted in S5, the payment request acquisition unit 136 determines whether or not the payment request including the payment information, the store ID, and the payment token has been acquired from the store terminal 3 (S8). .. When the settlement request acquisition unit 136 determines that the settlement request has been acquired, the process is transferred to S9, and when it is determined that the settlement request has not been acquired, the settlement request acquisition unit 136 re-executes S8.

In S9, the second determination unit 137 determines whether or not the balance of the account in the code payment of the user with the user ID associated with the payment token included in the payment request is equal to or greater than the payment amount. When the second determination unit 137 determines that the balance of the account is equal to or greater than the payment amount, the process is transferred to S11, and when the balance of the account is determined to be less than the payment amount, the process is transferred to S10.

In S10, the second determination unit 137 requests the determination device for determining the availability of the second payment means to allocate the payment limit corresponding to the difference between the payment amount and the balance of the user's account. It is determined whether or not the difference can be settled by the second settlement means associated with. When the second determination unit 137 determines that the difference can be settled by the second settlement means, the process is transferred to S11, and when it is determined that the difference cannot be settled by the second settlement means, the process is transferred to S14. ..

In S11, the settlement unit 138 settles the payment amount by code settlement. Here, the settlement unit 138 allows the balance of the user's account in the code payment to be insufficient when it is determined in S9 that the balance of the account associated with the code payment is less than the payment amount. And subtract the payment amount from the balance of the account.
Subsequently, the settlement unit 138 executes a process of depositing the payment amount into the account of the store specified by the store ID included in the settlement request (S12).

Subsequently, the notification unit 139 notifies the user terminal 2 of the payment completion information indicating that the payment has been completed (S13). Here, when the balance of the user's account corresponding to the code payment is insufficient, the notification unit 139 sends the payment completion information including the information indicating that the balance of the account is insufficient to the user terminal 2. Notice.

On the other hand, when it is determined in S10 that the difference cannot be settled by the second payment means, the notification unit 139 notifies the user terminal 2 of error information indicating that the payment amount cannot be settled by the code payment. (S14).

Next, the flow of processing in the payment processing device 1 when the balance of the account associated with the code payment is insufficient will be described. FIG. 7 is a flowchart showing a processing flow in the payment processing device 1 when the balance of the account associated with the code payment is in a shortage state. In addition, this flowchart shall be executed every predetermined time (for example, one day).

The settlement unit 138 determines whether or not the insufficient balance of the account has been resolved by charging the account whose balance is insufficient (S21). When the settlement unit 138 determines that the shortage state has been resolved, the process is transferred to S22, and when it is determined that the shortage state has not been resolved, the process is transferred to S23.

In S22, the settlement unit 138 requests the second settlement means to cancel the allocation of the settlement slots allocated in S10 of FIG.
In S23, the settlement unit 138 determines whether or not the balance of the account associated with the code settlement is insufficient for a predetermined period. When the settlement unit 138 determines that the balance of the account is insufficient for a predetermined period, the process is transferred to S24, and when it is determined that the balance of the account is not insufficient for the predetermined period, the process according to this flowchart is terminated.

In S24, the settlement unit 138 charges the second settlement means for the amount corresponding to the settlement slot allocated in S10 of FIG.
Subsequently, the settlement unit 138 resolves the shortage of the balance of the account (S25).

[Modification 1]
In the above description, the user terminal 2 displays the payment code, the store terminal 3 reads the payment code displayed on the user terminal 2, and sends the payment request to the payment processing device 1, but the present invention is not limited to this. .. For example, the store terminal 3 may display the payment code, the user terminal 2 may read the payment code, and the payment request may be transmitted to the payment processing device 1.

FIG. 8 is a diagram illustrating a processing flow when the user terminal 2 transmits a payment request to the payment processing device 1. First, the clerk at the store reads the barcode attached to the product purchased by the user on the store terminal 3 when the user makes an account at the store, and causes the store terminal 3 to generate payment information indicating the payment amount of the user. .. Further, the store clerk performs an operation for displaying the payment code on the store terminal 3 on the store terminal 3. The store terminal 3 transmits a payment code acquisition request, payment information, and a store ID to the payment processing device 1 ((1) in FIG. 8).

When the payment processing device 1 receives the payment code acquisition request, the payment information, and the store ID from the store terminal 3, the payment processing device 1 generates a payment token. The payment processing device 1 stores the generated payment token in association with the store ID in the storage medium. The payment processing device 1 transmits the generated payment token to the store terminal 3 ((2) in FIG. 8).

The store terminal 3 generates and displays a payment code based on the received payment token ((3) in FIG. 8).
The user terminal 2 reads the payment code displayed on the store terminal 3 by, for example, the user's operation ((4) in FIG. 8). The user terminal 2 transmits a payment request including a user ID and a payment token indicated by the read payment code to the payment processing device 1 ((5) in FIG. 8).

When the payment processing device 1 acquires a payment request from the user terminal 2, it determines whether the balance of the user's account associated with the code payment is equal to or greater than a predetermined amount ((6) in FIG. 8). When the balance of the user's account is less than the predetermined amount, the payment processing device 1 generates balance shortage information and notifies the user terminal 2 as described above. Here, the payment processing device 1 may notify the user of information prompting the payment to the account. By doing so, the payment processing device 1 can prevent the code payment from being performed when the balance of the account is less than the predetermined amount and the shortage of the balance of the account from increasing.

When the payment processing device 1 determines that the balance of the account is equal to or greater than the predetermined amount, it determines whether the balance of the user's account associated with the code payment is equal to or greater than the payment amount ((7 in FIG. 8). )).

The payment processing device 1 setstles the payment amount when the balance of the user's account associated with the code payment is equal to or greater than the payment amount, and associates it with the user when the balance of the account is less than the payment amount. It is determined whether or not the second payment means is satisfied with the second condition ((8) in FIG. 8).

When the payment processing device 1 determines that the second payment means satisfies the second condition, the payment processing device 1 allows the balance of the user's account in the code payment to be insufficient, and setstle the payment amount by the code payment (FIG. 8 (9)).

[Modification 2]
Further, in the above description, the first payment means is code payment, but the present invention is not limited to this. The first payment method may be a prepaid payment method that manages the balance on the server side such as the payment processing device 1, or a payment method that debits the payment amount from the bank account (debit method). In this case, the settlement unit 138 may allow the balance of the account corresponding to the first settlement means to be insufficient and settle the payment amount by the first settlement means.

[Modification 3]
Further, in the above description, when the predetermined amount is 0 yen and the payment processing device 1 determines that the balance of the user's account is less than 0 yen, the payment code is not generated and the payment code is not generated. An error message indicating that the message cannot be displayed is sent to the user terminal 2, but the present invention is not limited to this. The predetermined amount may be an amount of 1 yen or more, for example, 10 yen. Since the number of products that can be purchased for less than 10 yen is limited, if it is determined that the balance of the user's account is less than 10 yen, by not generating a payment token, the balance of the account at the time of payment Payment can be interrupted promptly as there is a high possibility that there will be a shortage.

[Effect of payment system S]
As described above, when the payment processing device 1 acquires the user ID that identifies the user who has requested the issuance of the payment code in connection with the code payment from the user terminal 2, the code of the user corresponding to the user ID is obtained. It is determined whether or not the account associated with the payment satisfies a predetermined condition indicating the state in which the payment can be made. The payment processing device 1 does not generate a payment token for the payment code corresponding to the user on the user terminal 2 when it is determined that the predetermined condition of the account is not satisfied, and when it is determined that the predetermined condition is satisfied, the payment processing device 1 is used for payment. Generate a token. By doing so, the payment processing device 1 can promptly suspend the payment when there is a high possibility that the balance of the account will be insufficient at the time of payment.

Although the present invention has been described above using the embodiments, the technical scope of the present invention is not limited to the scope described in the above embodiments, and various modifications and changes can be made within the scope of the gist. be. For example, the specific embodiment of the distribution / integration of the device is not limited to the above embodiment, and all or a part thereof may be functionally or physically distributed / integrated in any unit. Can be done. Also included in the embodiments of the present invention are new embodiments resulting from any combination of the plurality of embodiments. The effect of the new embodiment produced by the combination has the effect of the original embodiment together.

1 Payment processing device 2 User terminal 3 Store terminal 11 Communication unit 12 Storage unit 13 Control unit 21 Operation unit 22 Communication unit 23 Display unit 24 Storage unit 25 Control unit 31 Operation unit 32 Reading unit 33 Communication unit 34 Display unit 35 Storage unit 36 Control unit 131 Setting unit 132 Issuance request acquisition unit 133 First judgment unit 134 Token generation unit 135 Transmission unit 136 Payment request acquisition unit 137 Second judgment unit 138 Payment unit 139 Notification unit 251 Operation reception unit 252 Request transmission unit 253 Code generation unit 361 Payment information generation unit 362 Token acquisition unit 363 Payment information transmission unit

Claims (14)

Computer runs,
A step of acquiring user identification information that identifies a user who has made a request for issuing the code in relation to a payment method using the code from the terminal of the user, and a step of acquiring the user identification information.
Whether or not the account associated with the payment means of the user corresponding to the acquired user identification information satisfies a predetermined condition that the balance of the account indicating a paymentable state is a predetermined amount or more. A step of determining by comparing the balance of the account with the predetermined amount without using the payment amount paid by the user using the payment means.
When it is determined that the account satisfies the predetermined condition, a step of generating a token related to the code corresponding to the user displayed on the terminal of the user, and a step of generating a token.
The step of transmitting the generated token to the terminal,
A step of acquiring a payment request including the token and the payment amount paid by the user from a terminal different from the terminal that has read the code displayed by the terminal based on the token transmitted to the terminal.
A step of making a payment based on the token included in the acquired payment request and the payment amount, and
Payment processing method with. Further having a step of setting the predetermined amount performed by the computer,
In the determination step, it is determined whether or not the balance of the account is equal to or greater than the predetermined amount set in the setting step.
The payment processing method according to claim 1 . In the setting step, information for setting the predetermined amount is acquired from the user, and the predetermined amount is set based on the information.
The payment processing method according to claim 2 . In the setting step, information for setting the predetermined amount is acquired from the business operator that provides the payment means, and the predetermined amount is set based on the information.
The payment processing method according to claim 2 . In the setting step, the predetermined amount is set up to a predetermined amount.
The payment processing method according to any one of claims 2 to 4 . Further, the computer has a step of notifying the user of information regarding the balance when the determination amount is determined to be less than the predetermined amount in the determination step.
The payment processing method according to any one of claims 1 to 5 . In the notification step, the user is notified of information prompting the payment to the account.
The payment processing method according to claim 6 . The predetermined amount is 0 yen.
The payment processing method according to any one of claims 1 to 7 . The predetermined amount is an amount of 1 yen or more.
The payment processing method according to any one of claims 1 to 7 . Even if it is determined that the amount is less than the predetermined amount in the step of generating the code, if the balance of the account becomes a set amount lower than the predetermined amount, the money is automatically deposited in the account. When is set to, the terminal of the user is displayed with the code corresponding to the user.
The payment processing method according to claim 9 . The computer runs,
A step of associating the user identification information with the generated token and storing it in a storage unit.
The balance of the account corresponding to the user identification information stored in the storage unit associated with the token included in the received payment request is higher than the payment amount included in the received payment request. Steps to determine if there are few,
Have more
In the payment step, when the computer determines that the balance of the account is larger than the payment amount included in the received payment request, the computer uses the payment means of the user corresponding to the user identification information. To make a payment,
The payment processing method according to any one of claims 1 to 10 . An acquisition unit that acquires user identification information that identifies a user who has made a request to issue the code in relation to a payment method using the code from the terminal of the user.
Whether or not the account associated with the payment means of the user corresponding to the user identification information acquired by the acquisition unit satisfies a predetermined condition that the balance of the account indicating a paymentable state is a predetermined amount or more . With a determination unit that determines by comparing the balance of the account with the predetermined amount without using the payment amount paid by the user using the payment means.
When the determination unit determines that the account satisfies the predetermined condition, the token generation unit that generates a token related to the code corresponding to the user displayed on the terminal of the user, and a token generation unit.
A transmitter that transmits the generated token to the terminal,
Acquisition of a payment request including the token and the payment amount paid by the user from a terminal different from the terminal that has read the code displayed by the terminal based on the token transmitted to the terminal. Department and
A payment unit that makes a payment based on the token included in the acquired payment request and the payment amount.
Payment processing device. The determination unit further includes a notification unit for notifying the user of information regarding the balance when the determination unit determines that the balance of the account is less than the predetermined amount.
The payment processing device according to claim 12 . It further includes a setting unit that acquires the information for setting the predetermined amount from the user and sets the predetermined amount based on the information.
The payment processing device according to claim 12 or 13 .

Images