Settlement management device, settlement management method and program

Abstract

To provide a settlement management device improving convenience of users who receive salary in a form of electronic money, when using the received electronic money for electronic settlement.SOLUTION: Provided is a settlement management device for providing an electronic settlement service in cooperation with an application program operating on a terminal device of a user. The settlement management device includes a settlement processing unit for realizing the service, and a management unit for managing a balance usable as electronic money in the service by dividing it into a first type and a second type, and managing a fee to be charged for remittance of the first type or the second type of the electronic money, where the management unit manages, for every user, a privilege to be applied to a user who satisfies prescribed conditions, the privilege being a preferential treatment on the fee for remittance using the first type of electronic money, and where the settlement processing unit causes the application to display a remittance screen for creating a transaction of remitting the electronic money to a bank account designated by the user, and causes the remittance screen to display the fee for the remittance.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a payment management device, a payment management method, and a program. [Background technology]

[0002] In recent years, digital payroll (digital payroll payment), in which wages (salaries) are paid by transferring electronic money between the accounts of a company and an employee at a money transfer service provider, has been institutionalized. In response to this, methods of providing digital payroll services to users are being considered (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7330412 Summary of the Invention [Problem to be solved by the invention]

[0004] With conventional technology, it may be difficult for users who receive their salary in the form of electronic money to use the received electronic money for electronic payments.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objectives is to provide a payment management device, a payment management method, and a program that can improve the convenience of users who receive their salary as electronic money when using the received electronic money for electronic payments. [Means for solving the problem]

[0006] One aspect of the present invention is a payment management device that provides an electronic payment service to a user in cooperation with an application program running on the user's terminal device, the payment management device comprising: a payment processing unit that realizes the electronic payment service; and a management unit that manages the balance that a user can use as electronic money in the electronic payment service, divided into a first balance type and a second balance type, and manages the fees to be charged to the user for remittances using electronic money of the first balance type or the second balance type, wherein the management unit manages, for each user, a benefit that is applied to users who meet specified conditions, the benefit offering preferential fees for remittances using electronic money of the first balance type, and the payment processing unit causes the application program to display a remittance screen for creating a transaction to remit electronic money to a bank account specified by the user, and causes the remittance screen to display the fees for the remittance. Effect of the Invention

[0007] According to one aspect of the present invention, a payment management device, a payment management method, and a program can be provided that can improve the convenience of a user who receives a salary as electronic money when using the received electronic money for electronic payments. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. [Diagram 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Diagram 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] 1 is a configuration diagram of a payment server 100 according to a first embodiment. [Diagram 5] FIG. 13 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 13 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] 13 is a diagram showing an example of the contents of privilege management information 178. FIG. [Figure 8] 11 is a sequence chart showing an example of the process flow for transferring electronic money to a bank account of a user who has set up digital payroll. [Figure 9] FIG. 13 is a diagram showing an example of settings for a remittance transaction. [Figure 10] FIG. 13 illustrates an example of a remittance transaction creation screen. [Figure 11] 10 is a flowchart showing an example of the flow of processing executed by the settlement server 100 regarding a remittance transaction. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, with reference to the drawings, an embodiment of the payment management device, the payment management method, and the program of the present invention will be described. Various devices for providing services to users and performing internal analysis, such as the "server", "management device", and "information providing device" that will appear below, may be realized by a group of distributed devices, and each device may be operated by a different business operator. Furthermore, the owner of the hardware of the device (the cloud server provider) and the business operator that actually operates the device may also be different. The application program and the payment server work together to provide the electronic payment service. In the following description, the application program is referred to as a payment application. The electronic payment service is a service that supports payments related to the purchase of goods and services at a store. The store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for electronic commerce. The virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when making a payment for shopping at the virtual store, the screen is controlled to transition to an interface screen of the electronic payment service. In the electronic payment service, the store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at the store is mainly performed between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Fig. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment application 20, thereby operating to provide an electronic payment service to a user in cooperation with a payment server 100. The payment application 20 is installed in the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store, and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. An interface 72 for affiliated stores runs on the second store terminal device 70. The interface 72 for affiliated stores may be an app for affiliated stores or a browser. The interface 72 for affiliated stores accepts coupon settings and the like made by the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading a code image displayed by the user terminal device 10 by executing the app for affiliated stores.

[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case the payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, no distinction is made between these two and it is assumed that the payment information is sent from the first store terminal device 50.

[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns of electronic payment: pattern 1 and pattern 2.

[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10 with the payment application 20 activated decodes the store code image 60 by the optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is an electronic payment service domain to which store-identifying information is added, and is associated with an affiliated store ID, a store ID, etc. in the payment server 100 (described later). The payment application 20 transmits the first payment information including the store URL and the account ID to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the affiliated store ID and the store ID corresponding to the store URL, acquires the affiliated store name and the store name information (S3), and transmits it to the payment application 20 (S4). The user inputs the payment amount into the user terminal device 10 on the screen on which the affiliated store name and the store name are displayed (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount, and transmits it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then transmits a payment completion notice (information for displaying a payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include not only the store URL but also information on the payment amount. In this case, the step of the user inputting the payment amount is omitted, and the information on the payment amount is included in the first payment information and transmitted to the payment server 100. Information on the affiliated store name and the store name may be included in the payment completion screen and displayed.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, when the payment application 20 is started, when a payment operation is performed in the payment application 20, when an automatic update timing (e.g., every minute) occurs, and at other timings, the payment application 20 transmits a request for issuing a one-time code to the payment server 100 (S11). The payment server 100 generates a one-time code (S12) and transmits it to the payment application 20 (S13). The payment application 20 displays a code image such as a QR code or a barcode generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first store terminal device 50, and the first store terminal device 50 decodes the code image by an optical reading function and obtains the one-time code, etc. (S15). The first store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and transmits it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode or manually entering it. The payment server 100 identifies the user corresponding to the one-time code based on the received information and performs electronic payment (S17). The payment server 100 then transmits a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

[0018] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuance of a one-time code may be omitted in the store scan, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0019] [Digital salary payment] In addition to the basic functions of the electronic payment service described above, the payment server 100 has a function of providing a digital salary payment service (hereinafter referred to as "digital salary service") in which a part or all of a salary is received as electronic money that can be used in the electronic payment service. The payment server 100 manages the balance that can be used as electronic money for a user who has registered to use the digital salary service, in first to fourth balance types. Here, the balance that can be used as electronic money means a balance of a value that can be used as a cash equivalent, and includes the value of points, etc. In the following, for simplicity, the balance that can be used as electronic money is collectively referred to as the "electronic money balance." Note that the first to fourth balance types are examples of balance types provided to manage the balance of electronic money, and are not limited to those described below. The balance types may be classified arbitrarily based on the use or purpose, the deposit route, the law, etc., and the number of types is not limited to four.

[0020] The first balance type is a salary-derived balance. The salary-derived balance is a balance that is managed when a user receives a salary from an employer or the like in the form of electronic money. The second balance type is a non-salary-derived balance that can be transferred to a bank. The third balance type is a non-salary-derived balance that is restricted so that it cannot be transferred to a bank. The fourth balance type is a balance of points that are given / refunded to a user in an electronic payment service. The first balance type and the second balance type can be used by a user who has verified his / her identity in the electronic payment service. The first balance type is a balance that can be transferred to a bank, similar to the second balance type. A user can use the first balance type by applying to use the digital salary service in the electronic payment service. On the other hand, a user who has not registered to use the digital salary service can use the second to fourth balance types. The salary-derived balance is an example of the first balance type, and the first balance type may be an electronic money balance that can be used by a user by applying to use the service.

[0021] The affiliated bank server 200 is a computer system of a bank (hereinafter referred to as the "affiliated bank") that provides a digital payroll service to users of the electronic payment service in partnership with the operator of the electronic payment service. The affiliated bank may be operated by the operator of the electronic payment service. The affiliated bank server 200 is composed of one or more computers, and can communicate with the payment server 100 and the payment source server 300 via the network NW. The affiliated bank server 200 may have only the functions necessary to realize the digital payroll service, or may have, in addition to those functions, functions for providing general banking services such as deposits and withdrawals, transfers, and remittances.

[0022] More specifically, the associate bank server 200 transfers a predetermined amount of the user's salary to the payment server 100 based on an instruction from the payment source server 300. The payment server 100 manages the salary-derived funds transferred from the associate bank server 200 in the form of electronic money. The associate bank server 200 transfers the amount of the user's salary minus the amount transferred to the payment server 100 to a bank account designated in advance by the user.

[0023] The payment source server 300 is a computer system of a bank where a business entity that pays a salary to a user has an account for managing funds for paying the salary to the user. The payment source server 300 is composed of one or more computers, and can communicate with the affiliated bank server 200 via a network NW. The bank that operates the payment source server 300 may be an affiliated bank, or may be a bank other than an affiliated bank.

[0024] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by cooperation between software and hardware. The program may be stored in advance in a storage device (storage device having a non-transient storage medium) such as an HDD (Hard Disk Drive) or a flash memory, or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or a CD-ROM, and may be installed in the storage device by mounting the storage medium in a drive device.

[0025] The storage unit 170 is a HDD, a flash memory, a RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, payment content information 174, affiliated store / shop information 176, and benefit management information 178.

[0026] The communication unit 110 is a communication interface for connecting to the network NW. The communication unit 110 is, for example, a network interface card.

[0027] The payment content providing unit 120 has, for example, a function of a Web server, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The payment content providing unit 120 appropriately reads necessary content from the payment content information 174 and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs by the user while the content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.

[0028] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172 and the benefit management information 178. The benefit management information 178 is information for managing benefits applied to users of the electronic payment service.

[0029] FIG. 5 is a diagram showing an example of the contents of the user information 172. The user information 172 is an example of the registration information of a user. The user information 172 is, for example, a user URL, an account ID, a telephone number, a password, as well as information associated with an email address, a user ID, a name, an address, a date of birth, a registration date, a charge balance, a post-payment setting, a post-payment limit, a post-payment usage amount, a post-payment available amount, a payment method setting, a bank account, a credit card number, charge history information, payment history information, and a digital salary setting. The user URL is used for a remittance process between users. When registering for the electronic payment service, it is necessary to register a telephone number and a password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that can be set by the user at will (does not have to be set). Similarly, the email address, and the name, address, and date of birth are information that can be set by the user at will (does not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0030] The charge balance is information indicating the balance of electronic money that is set by a user by transferring money to an account in advance. The means of transfer include transfer from an ATM (Automatic Teller Machine) of a designated company (bank) and transfer from a registered bank account. The deferred payment setting is information indicating whether or not the setting for enabling electronic payment by deferred payment has been completed, and is set to either "completed" or "not completed." The deferred payment limit is the limit of deferred payment that can be used each month, the deferred payment usage amount is the amount of deferred payment that has already been used in the current month, and the deferred payment available amount is the amount of deferred payment that can be used in the current month, which is calculated by subtracting the deferred payment usage amount from the deferred payment limit. Although only one deferred payment limit is shown in the figure, in reality, there is also a daily upper limit, and the lower of these may be set as the deferred payment limit. Further details of deferred payment will be described later. The payment method setting is setting information indicating whether the user will perform electronic payment using the charge balance or payment by deferred payment at that time. The bank account and credit card number are information on a bank account or credit card number (account number, card number) that can be used to deposit funds into an electronic payment service. Charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. Payment history information is information that indicates the details of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0031] The digital salary setting is information indicating whether or not the setting for receiving salary through the digital salary service has been completed, and is set to either "Completed" or "Not yet." As described above, the electronic money of a user who has completed the digital salary setting is managed by the first to fourth balance types, and among these, the electronic money of the first and second balance types is managed as electronic money that can be withdrawn to a bank account.

[0032] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store name and sales amount (described above) are associated with an affiliated store ID, and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the category of the affiliated store or store, the location of the store, and payment patterns.

[0033] The information management unit 140 manages user information 172 and affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, and deletes the user information 172, affiliated store / store information 176, and benefit management information 178.

[0034] [Electronic payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 refers to the user information 172 to acquire the "payment method setting" of the user. For a user whose "payment method setting" is set to "charge balance", the payment processing unit 130 performs electronic payment as follows. For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales. The item value of the affiliated store's sales is not used as electronic money itself, for example, and an amount corresponding to the item value of the sales is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0035] The payment processing unit 130 performs electronic payment for users whose "setting information" is set to "deferred payment" as follows. Deferred payment is set separately from "credit payment" in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service, and the operator of the electronic payment service acts as a creditor and allows electronic payment that is not dependent on the charge balance within the deferred payment limit. In order to receive the deferred payment service, a credit card provided by the operator of the electronic payment service may be required. The amount used for deferred payment is settled on the payment date of the following month, for example, by debiting from a bank account, for one month. In this case, the payment processing unit 130 performs provisional payment by adding the payment amount to the deferred payment amount and subtracting the same amount from the available deferred payment amount, and when the closing date comes, it performs processing to debit the payment for the current month on the payment date of the following month as described above, or requests the operator of the credit card company to perform such processing. In addition, if the payment amount exceeds the available deferred payment amount at the time of provisional payment, an error notification is returned to the payment application 20.

[0036] [Transfer fee] In the case of a transfer of funds between accounts managed by different entities, the financial institution from which the transfer is made generally collects a fee from the user. In addition, some financial institutions may, as part of their services, reduce or waive the fees for transfers to other institutions to a certain extent for users who have designated their institution as the account to receive their salary. For example, some financial institutions may waive the fees for transfers to another financial institution account once a month for users who have traditionally received their salary by transferring money to a financial institution account, or waive the fees for withdrawals via ATMs once a month. In this case, users can transfer their entire salary to another account or obtain it as cash without paying fees. In light of this, it is desirable for the fees charged for transfers and withdrawals to be treated in the same way as before even in the digital salary payment system.

[0037] Therefore, the payment server 100 of this embodiment has a function of providing a user with a privilege of making the fee waived once a month when transferring electronic money of the first balance type (derived from salary) to an account of another financial institution (hereinafter, assumed to be a bank). This makes it possible to provide users of the digital salary service with the same convenience as receiving salary by conventional bank account transfer. For example, the payment server 100 can manage privileges applied to users based on the privilege management information 178. The remittance process will be described in detail below, but in the following, the remittance process will include a process in which a user withdraws electronic money from an electronic settlement account to a bank account in his / her own name (own account) and a process in which the user transfers money to a bank account in another person's name (different name account).

[0038] FIG. 7 is a diagram showing an example of the contents of benefit management information 178. Benefit management information 178 is information for managing, for each user, benefits that are applied to the user in the electronic payment service. Benefit management information 178 is managed, for example, in the form of table 178T in which a user ID, benefit content, and application conditions are associated with each other. The user ID is identification information for a user in the electronic payment service and corresponds to the user ID in FIG. 5. Benefit content is the content of the benefit that is applied to the user. Application conditions are the conditions under which the benefit of the benefit content is applied to the user. In this embodiment, free remittance fees (up to once per month) is shown as an example of the content of the benefit that is applied to the user.

[0039] In this case, the application condition may be set as a combination of the balance type used and the remittance destination account, as shown in FIG. 7, for example. The balance type used is a condition related to the balance type of electronic money used for remittance. The remittance destination account is a condition related to the account specified as the remittance destination. FIG. 7 shows an example in which the condition is whether the remittance destination account is the user's own account or an account under a different name. The user's own account is a bank account in which the remittance originator user is the account holder, and the account under a different name is a bank account in which the account holder is a person other than the remittance originator user. The example in FIG. 7 shows a setting example for applying a benefit of exempting remittance fees when a remittance made by a user identified by user ID "AAA" includes a first balance type (derived from salary) in the balance types used for the remittance and the remittance destination account is the user's own account.

[0040] The contents shown in FIG. 7 are merely examples and are not limited thereto. For example, the number of times the benefit can be applied may be one or more, and the balance type used in the benefit application conditions may be set to a balance type other than the first balance type. For example, as part of a campaign, a benefit may be set to waive remittance fees a predetermined number of times for users who meet certain conditions, regardless of whether the destination account is the user's own account or an account under a different name. For example, a benefit that discounts remittance fees, a benefit in which the business bears part of the remittance fees, a benefit that cashes back remittance fees, a benefit that gives points for the implementation of remittance, and the like may be set. In addition to the information exemplified in FIG. 7, any information necessary for managing the benefit may be managed for each user. For example, as in the example of FIG. 7, when a limit is set on the number of times the benefit can be applied, the number of times the benefit can be applied needs to be appropriately managed for each user. In this case, for example, the number of times the benefit can be applied can be managed in association with a user ID in the user information 172 or the benefit management information 178.

[0041] Furthermore, for example, the conditions for applying the benefit may include that the user has made a predetermined number of remittances in the current month, or that the total amount of remittances made by the user in the current month is equal to or greater than a predetermined amount. Conversely, the benefit may be applied to all remittances. The conditions for applying the benefit may also include the use of a specific service other than remittance. The specific service may be unrelated to transactions using electronic money, or may be any service (e.g., a financial service) that can be provided by an electronic payment service.

[0042] In addition, the condition for the use balance type in the conditions for applying the privilege may be that the target balance type covers the entire amount of the remittance amount, or that the target balance type covers a part of the remittance amount. For example, in the example of Fig. 7, the payment server 100 may determine that the conditions for applying the privilege are satisfied when the user uses 1 yen or more of the salary-derived electronic money balance (first balance type) as the source of the remittance amount when remitting money to his / her own account.

[0043] [Transfer of electronic money to a designated bank account] As described above, among the electronic money of a user who has set up digital salary, electronic money of the first and second balance types can be transferred to a bank account. FIG. 8 is a sequence chart showing an example of a process flow for transferring electronic money to a bank account of a user who has set up digital salary. First, the user operates the user terminal device 10 to start the payment application 20, and operates the started payment application 20 to log in to the electronic payment service (S310). For example, the payment application 20 accepts input of account information (e.g., account ID and password) of the electronic payment service, and transmits a login request to the electronic payment service to the payment server 100 together with the input account information (S311). The payment server 100 performs authentication processing based on the received account information and user information 172 (S312), and returns the authentication result to the payment application 20 (S313).

[0044] Next, assume that a remittance transaction occurs that should be settled by using the electronic money balance of the first balance type or the second balance type. Here, a remittance transaction settled by using the electronic money balance is a transaction that can be created using the payment application 20, and is a transaction for moving (transferring) electronic money in an electronic payment account to another bank account. The user operates the payment application 20 to display a screen for creating a remittance transaction to be settled by using the electronic money balance (hereinafter referred to as a "remittance transaction creation screen") (S320). The remittance transaction creation screen displayed here includes a first user interface (S321) that accepts a setting operation of the transaction details, and a second user interface (S322) that displays the fee required for the remittance. The user can understand the fee required for the remittance by checking the display contents of the second user interface, and can create a transaction to remit a specified amount from a specified balance type by operating the first user interface (S321 and S322).

[0045] Thereafter, the settlement server 100 waits for the timing set in S321 to execute the remittance transaction, and when the timing arrives, executes the settlement process to complete the remittance transaction (S330). More specifically, the settlement server 100 instructs the associate bank server 200 to execute a process to deposit a specified amount of funds into a bank account specified as the remittance destination (hereinafter referred to as the "remittance process") (S331). In response to this instruction, the associate bank server 200 executes the remittance process (S340), and the specified amount is deposited into the remittance destination bank account (S341), completing the remittance transaction.

[0046] FIG. 9 is a diagram showing an example of the setting contents of a remittance transaction. For example, the setting contents of the remittance transaction are managed as a remittance transaction management table T1 in which information such as a transaction ID, a remaining balance type, a scheduled remittance date, an amount used, and a remittance destination financial institution is associated with a user ID. The user ID is identification information of a user of the electronic payment service. The user ID may correspond to the user ID in FIG. 5, or may correspond to other identification information such as an account ID or a telephone number. The transaction ID is identification information of the remittance transaction set by the user, and is assigned each time the user creates a new remittance transaction. The remaining balance type is the remaining balance type of the electronic money used for the remittance. Either one or both of the first remaining balance type (derived from salary) and the second remaining balance type (remaining balance of electronic money that can be remitted by bank transfer other than that derived from salary) can be selected as the remaining balance type. The scheduled remittance date is the scheduled execution date of the remittance specified by the user. The amount used is the remittance amount specified by the user for the electronic money of the remaining balance type. The amount used can be set for each remaining balance type selected as the remaining balance type. Either the amount itself or a ratio to the total remittance amount may be set as the amount used. The remittance destination financial institution is the financial institution specified by the user as the remittance destination.

[0047] FIG. 10 is a diagram showing an example of a remittance transaction creation screen. For example, the remittance transaction creation screen G10 illustrated in FIG. 10 includes a first setting unit G111, a second setting unit G112, and a third setting unit G113 as a first user interface G110, a second user interface G120, and a button B130 for determining the setting contents of the remittance transaction. The first setting unit G111 accepts setting operations for the remaining balance type and the amount used. The second setting unit G112 accepts a setting operation for the scheduled remittance date. The third setting unit G113 accepts a setting operation for the remittance destination financial institution. FIG. 10 shows an example in which the first remaining balance type and the second remaining balance type are selected as the remaining balance type, and 10,000 yen and 20,000 yen are set for the respective amounts used.

[0048] In the example of FIG. 10, the display of the second user interface G120 indicates that there is no fee for remittance from electronic money of the first balance type (derived from salary) at that time. If the number of times that the benefit can be used in the current month has already been consumed, the second user interface G120 may be configured to display that the number of times that the benefit can be used is 0, or to display that a fee will be charged for the remittance transaction to be created (or the amount of the fee). Alternatively, in this case, the remittance transaction creation screen G10 may be configured not to display the second user interface G120. Furthermore, the second user interface G120 may be configured to display the contents and application conditions of the benefits that are applicable to the remittance transaction among those set in the benefit management information 178.

[0049] Also, the display or display contents of the second user interface G120 may be configured to switch depending on the input setting contents of the remittance transaction. For example, the second user interface G120 may be configured to be displayed when the first balance type (derived from salary) is selected as the balance type to be used, and not to be displayed when the first balance type (derived from salary) is not selected as the balance type to be used. Also, for example, the second user interface G120 may be configured to display that no fee is charged for the remittance transaction when the first balance type (derived from salary) is selected as the balance type to be used, and to display that a fee is charged for the remittance transaction (or the amount of the fee) when the first balance type (derived from salary) is not selected as the balance type to be used.

[0050] In this way, when creating a remittance transaction, the user can check the display content of the second user interface G120 to confirm whether or not a remittance fee will be charged, and then create (reserve) the remittance transaction.

[0051] The remittance transaction creation screen may be composed of one screen as in the example of Fig. 10, or may be composed of multiple screens with screen transitions. The first user interface and the second user interface may be displayed on one screen, or may be distributed and arranged on multiple screens that make up the remittance transaction creation screen. Links for calling up the first user interface and the second user interface may be arranged on the multiple screens that make up the remittance transaction creation screen.

[0052] After inputting various setting information for the remittance transaction to be created, the user can confirm the details of the remittance transaction by operating the Confirm button B130. The confirmed details of the transaction are stored, for example, in the remittance transaction management table T1, and the remittance transaction is executed when the scheduled remittance date arrives.

[0053] FIG. 11 is a flowchart showing an example of the flow of processing executed by the settlement server 100 for a remittance transaction. The processing flow of FIG. 11 is started in response to a new remittance transaction being created and an operation to confirm the setting contents being performed. First, as described above, the settlement server 100 acquires the setting contents of the confirmed remittance transaction from the settlement application 20 and stores them in the remittance transaction management table T1 (S41). In response to this, the settlement server 100 secures the funds of the planned remittance amount by subtracting the planned remittance amount from the current electronic money balance based on the setting contents of the confirmed remittance transaction, and then suspends the payment of the planned remittance amount until the remittance transaction is actually executed (S42). Here, the securing of the planned remittance amount and the suspension of the payment are performed for each balance type selected as the balance type to be used. By securing the planned remittance amount in advance in this way, it is possible to avoid a shortage of balance at the timing of the remittance process. If the current balance of electronic money is less than the planned remittance amount, the settlement server 100 may store the setting contents, and if the current balance of electronic money is less than the planned remittance amount, the settlement server 100 may return an error to the operation to confirm the setting contents. After S42, the settlement server 100 waits for the arrival of the specified planned remittance date.

[0054] Next, when the designated scheduled remittance date arrives, the settlement server 100 executes the remittance transaction set for the user (S43). More specifically, the settlement server 100 transfers the funds of the scheduled payment amount secured in S42 to a dedicated account of the associate bank server 200, and instructs the associate bank server 200 to execute the remittance process. The dedicated account here is an account set up for the transfer of funds between the settlement server 100 and the associate bank server 200 in order to provide the digital payroll service in the associate bank server 200. The associate bank server 200 executes the remittance process upon receiving the execution request of S43. More specifically, the associate bank server 200 creates a bank transfer request form for requesting the transfer of a designated amount from the dedicated account to a designated account of the bank (remittance destination financial institution) designated as the remittance destination, and transmits the bank of the remittance destination to the remittance destination bank. When the remittance destination bank receives the bank transfer request form from the associate bank server 200, it executes the transfer process based on the contents of the request form, and returns the processing result to the associate bank server 200. The affiliated bank server 200 determines whether the remittance process has been successful or not based on the returned processing result, and returns the determination result to the settlement server 100.

[0055] The payment server 100 judges whether the remittance transaction is successful or not based on the judgment result returned from the associated bank server 200 (S44). When the payment server 100 is notified of the success of the remittance process from the associated bank server 200, it finalizes the payment of the reserved planned remittance amount and completes the remittance transaction (S45: transaction successful). On the other hand, when the payment server 100 is notified of the failure of the remittance process from the associated bank server 200, it notifies the user's payment application 20 of the failure, cancels the payment of the reserved planned remittance amount (S46), and returns the planned remittance amount to the electronic money balance of the corresponding balance type (S47: transaction failed). That is, the payment server 100 returns the amount secured from the first balance type as the planned remittance amount to the electronic money balance of the first balance type, and returns the amount secured from the second balance type to the electronic money balance of the second balance type.

[0056] According to the embodiment described above, it is possible to improve the convenience of users of electronic payment services compatible with digital salary payment when using electronic money received as salary for electronic payment. More specifically, when remitting electronic money from their own electronic payment account, users of digital salary services can specify the balance type of the electronic money of the remitter. Furthermore, when the remitter has both a first balance type (derived from salary) and a second balance type (other than derived from salary), the user can specify the remittance amount for each. Furthermore, users of digital salary services can remit their salary received as electronic money at least once a month without paying a fee, similar to receiving salary by conventional bank transfer.

[0057] In addition, in the digital salary payment system, funds transfer businesses that provide digital salary services (in this embodiment, they are electronic payment service providers) are required to strictly separate and manage electronic money derived from salary and other sources in order to safely store users' salaries. The payment server 100 of this embodiment meets this requirement by separating electronic money balances into a first balance type and a second balance type, and furthermore, by securing and managing the planned remittance amount separately into the first balance type and the second balance type, users can flexibly and safely use the salary received as electronic money.

[0058] <Modification> In the above embodiment, a method has been described in which a user can specify a balance type and perform a "transfer" to a designated bank account in an electronic payment service that supports digital salary payment, but "transfer" is an example of an electronic payment function of an electronic payment service, and is not limited to this. For example, the designation of the type of balance used may be applied to the function of payment by electronic payment (e.g., the user scan method in FIG. 2 or the store scan method in FIG. 3), or may be applied to transfer between electronic payment accounts.

[0059] In the above embodiment, it is assumed that the financial institution of the remittance destination is a bank other than the affiliated bank, but the financial institution of the remittance destination may be the affiliated bank. In this case, the affiliated bank server 200 may be configured to process the bank transfer request generated upon receiving a request to execute a remittance transaction from the settlement server 100 using its own bank transfer function.

[0060] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]

[0061] 10 User terminal device 20. Payment App 50 First store terminal device 60 Store Code Image 70 Second store terminal device 72 Merchant Interface 100 Payment Server 110 Communications Department 120 Payment Contents Provider 130 Payment processing unit 140 Information Management Department 170 Storage section 172 User information 174 Payment Content Information 176 Store Information 200 Affiliated bank server 300 Payment server

Claims

1. A payment management device that provides an electronic payment service to a user in cooperation with an application program running on a terminal device of the user, comprising: a payment processing unit for implementing the electronic payment service; a management unit that manages a balance that a user can use as electronic money in the electronic payment service by dividing it into a first balance type and a second balance type, and that manages a fee to be charged to the user for remittance using electronic money of the first balance type or the second balance type; Equipped with the management unit manages, for each user, a benefit that is applied to a user who satisfies a predetermined condition, the benefit being a preferential treatment on a fee for remittance using the electronic money of the first balance type; the settlement processing unit causes the application program to display a remittance screen for creating a transaction for remittance of electronic money to a bank account designated by the user, and causes the remittance screen to display a fee for the remittance; Payment management device.

2. the first balance type is a salary-derived electronic money balance in which a part or all of a salary deposited in the bank account of the user is transferred as electronic money to the electronic payment account of the user in the electronic payment service; the second balance type is a balance of electronic money other than that derived from the salary, the electronic money of the first balance type and the electronic money of the second balance type are remittable electronic money; The payment management device according to claim 1 .

3. the management unit applies the privilege when a user who has set up receipt of salary in electronic money remits electronic money, and when the user remits electronic money using the electronic money of the first balance type; The payment management device according to claim 2.

4. The privilege is applied when a user who has set up receipt of salary by electronic money remits electronic money and the balance type of the electronic money used for the remittance includes a first balance type, and is not applied when the balance type of the electronic money used for the remittance includes only a second balance type. The payment management device according to claim 1 .

5. the remittance screen accepts an operation of selecting one or both of a first balance type and a second balance type as a balance type of electronic money to be used for the remittance; The payment management device according to claim 1 .

6. the management unit, in response to the creation of the transaction, subtracts the planned remittance amount from the balance of the electronic money used for the remittance, and holds the settlement of the planned remittance amount until the transaction is executed, and if the transaction is successful, finalizes the settlement of the planned remittance amount, and if the transaction is unsuccessful, adds the planned remittance amount to the balance of the electronic money, and cancels the held settlement. The payment management device according to claim 1 .

7. the management unit manages whether to suspend, confirm, or cancel the settlement of the planned remittance amount for each balance type of electronic money selected to be used for the remittance; The payment management device according to claim 6.

8. a payment management device for providing an electronic payment service to a user in cooperation with an application program running on a terminal device of the user, Executing a payment process to realize the electronic payment service; a balance that a user can use as electronic money in the electronic payment service is managed by dividing it into a first balance type and a second balance type, and a fee to be charged to the user for remittance using electronic money of the first balance type or the second balance type is managed; 1. A payment management method, comprising: The payment management device, managing, for each user, a benefit that is applied to a user who satisfies a predetermined condition, the benefit being a preferential treatment on a fee for remittance using the electronic money of the first balance type; causing the application program to display a remittance screen for creating a transaction for remittance of electronic money to a bank account designated by the user, the remittance screen including an indication of a fee for the remittance; Payment management methods.

9. A payment management device that provides an electronic payment service to a user in cooperation with an application program running on the user's terminal device, Executing a payment process that realizes the electronic payment service; a balance that can be used by a user as electronic money in the electronic payment service is managed separately into a first balance type and a second balance type, and a fee to be charged to the user for remittance using electronic money of the first balance type or the second balance type is managed; A program for: The payment management device, a privilege that is applied to a user who satisfies a predetermined condition, the privilege being a preferential treatment on a fee for remittance using the electronic money of the first balance type, is managed for each user; causing the application program to display a remittance screen for creating a transaction for remittance of electronic money to a bank account designated by the user, the remittance screen including an indication of a fee for the remittance; Program for.

Images