Payment management device, payment management method, and application program
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- PAYPAY CO LTD
- Filing Date
- 2023-10-18
- Publication Date
- 2026-07-03
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a payment management device, a payment management method, and an application program. [Background technology]
[0002] Conventionally, electronic payment systems have been put into practical use in which a user terminal device or a store terminal device generates payment information based on information read from a two-dimensional code and transmits it to a payment server, and the payment server then executes payment processing based on the payment information received from the user terminal device or the store terminal device (see, for example, Patent Document 1). [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2023-005816 A Summary of the Invention [Problem to be solved by the invention]
[0004] With conventional technology, users (such as children) who do not have a fund source other than cash, such as a credit card or bank account, had to use an ATM to deposit cash into their electronic payment account, which was a time-consuming process.
[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 an application program that can improve the convenience of electronic payment services. [Means for solving the problem]
[0006] One aspect of the present invention is a payment management device that works in cooperation with an application program running on a user's terminal device to provide an electronic payment service to the user, the payment management device comprising: a memory unit that stores correspondence information between a first user's fund source, which is any one or more fund sources registered as payment methods in the electronic payment service, and one or more second users; and a payment processing unit that executes payment processing to realize the electronic payment service, wherein the second user is a user who is authorized to use the first user's fund source in payments using the electronic payment service, and the payment processing unit increases the balance of the second user's electronic payment account from the first user's fund source in response to receiving a notification from the second user's terminal device that the second user has agreed to use the first user's fund source, and executes electronic payment using the balance of the second user's electronic payment account in response to a payment request from the second user's terminal device.
[0007] One aspect of the present invention is an application program that operates on a user's terminal device and cooperates with the payment management device to provide electronic payment services to the user, obtaining from the payment management device, for each of the one or more second users, the total amount paid by the second user from the balance added from the fund source, and displaying the total amount on the terminal device of the first user. Effect of the Invention
[0008] According to one aspect of the present invention, it is possible to provide a payment management device, a payment management method, and an application program that can improve the convenience of electronic payment services. [Brief description of the drawings]
[0009] [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] FIG. 2 is a configuration diagram of a payment server 100. [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] FIG. 13 is a diagram showing an example of the contents of family information 178. [Figure 8] FIG. 11 is a sequence diagram showing an example of a flow of processes executed by the payment application 20 and the payment server 100 in cooperation with each other regarding the setting of family payment. [Figure 9] FIG. 13 is a diagram showing an example of a display of a payment method management screen. [Figure 10] FIG. 13 is a diagram showing an example of a wallet screen display of an administrator. [Figure 11] FIG. 13 is a diagram showing a display example of a family setting screen. [Figure 12] FIG. 13 is a diagram showing an example of a wallet screen display for a family member. [Figure 13] FIG. 13 is a diagram showing an example of a family balance screen display. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0010] Hereinafter, with reference to the drawings, an embodiment of a payment management device, a payment management method, and an application program control method of the present invention will be described. The application program and a payment server work together to provide an 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) existing in real space, but may also include a virtual store of electronic commerce. The virtual store may include a store 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 performed between the user and the store.
[0011] [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.
[0012] 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.
[0013] 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).
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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).
[0019] 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.
[0020] [Payment server] FIG. 4 is a configuration diagram of the payment server 100. 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 such as an HDD (Hard Disk Drive) or a flash memory (a storage device having a non-transient storage medium), or may be stored in a removable storage medium such as a DVD or a CD-ROM (a non-transient storage medium), and may be installed in the storage device by mounting the storage medium in a drive device.
[0021] 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 family information 178.
[0022] 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.
[0023] 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.
[0024] 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, family information 178, etc.
[0025] 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, a family payment setting, and a family payment balance. 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.
[0026] 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.).
[0027] Family payment settings are information on various parameters that can be set for each user regarding family payment. Here, "family payment" is a payment method that enables a user who is the owner of a fund source (hereinafter referred to as the "administrator") to make electronic payments using his or her own fund source with other users who have been pre-authorized. With family payment, other users can charge the balance of their own electronic payment account (hereinafter sometimes referred to as the "wallet") within the range set by the administrator. Although the method of charging the balance with family payment differs from that of regular balance payment, the processing of the part of the payment made from the charged balance may be realized in the same way as regular balance payment that does not use family payment.
[0028] Hereinafter, a group of users set to enable family payment is referred to as a "family", and users belonging to a family are referred to as "family members". A family may be a group of users (family members) who are permitted by the administrator to use his / her payment method, and does not necessarily correspond to an actual family structure. For example, a family may be configured as a group of friends or colleagues, or may be composed of members of a specific group (e.g., room sharing, study group, online salon, project, etc.). The administrator may set up multiple families. The administrator may also define a family in which some or all of the family members overlap among multiple families. The administrator may also set up a family in which some or all of the payment methods overlap among multiple families. The administrator is an example of a "first user", and a family member is an example of a "second user".
[0029] For example, the family payment settings include information such as the family payment settings status, the family to which the user belongs, the type of user in the family (e.g., either administrator or family member), and the family payment limit. The family payment limit is a limit on the total amount that the user can use for family payment payments. The family payment balance is the remaining amount that the user can use for family payment payments.
[0030] The family payment upper limit is set in advance by the administrator for each family member in each family, and is set as the total available amount for a specified set period (e.g., one month). The length and scope of the set period may be fixed values, or may be variable values that can be set by the administrator. The family payment balance is reset to the family payment upper limit for each set period. Any family payment balance remaining at the time of resetting may be carried over to the balance for the next set period, or may be reset to 0. In addition, the administrator may be able to change the settings to allow or disallow carryover at the time of resetting.
[0031] The family payment balance is appropriately updated by the information management unit 140 when a family member makes a payment using family payment. In addition, when a family member of a family selects family payment as the payment method at the time of payment, the payment processing unit 130 refers to the family payment balance of the family member at that time, and executes the payment if the family payment balance is sufficient for the payment amount, and returns an error to the payment application 20 if it is insufficient.
[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 ID. 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] FIG. 7 is a diagram showing an example of the contents of the family information 178. The family information 178 is managed, for example, by a table in which a family ID is associated with a family name, a family member, a payment method, and an administrator ID. The family ID is identification information for each family. The family ID is uniquely assigned, for example, when the family is created. The family name is a name that is arbitrarily given to the family. The family name may be specified, for example, by the administrator when creating the family, or may be changed when changing the settings of the family. The family members represent the family members that belong to the family. The family members are selected by the administrator when creating the family. The family members may be changed (added or deleted) by the administrator as appropriate. The payment method is a payment method set to be used in family payments related to the family. The payment method is selected from among payment methods that use the administrator's fund source. The administrator ID is identification information for a user (administrator) who has management authority over the family. Note that while Figure 7 shows an example in which family member and administrator IDs are managed by the account ID exemplified in Figure 5, this is just one example and they may also be managed by other identification information (such as a user ID).
[0034] 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 and affiliated store / store information 176.
[0035] [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.
[0036] 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 that 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 deferred payment available 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. In addition, if the payment amount exceeds the deferred payment available amount at the time of provisional payment, an error notification is returned to the payment application 20.
[0037] [Family payment settings] FIG. 8 is a sequence diagram showing an example of the flow of processing executed by the payment application 20 and the payment server 100 in cooperation with each other with respect to the setting of family payment. Also, FIG. 9 to FIG. 11 show examples of screen display of the payment application 20 in the user terminal device 10 of the administrator, and FIG. 12 shows an example of screen display of the payment application 20 in the user terminal device 10 of the family member. Hereinafter, the flow of processing of FIG. 8 will be described with reference to the screen display examples of FIG. 9 to FIG. 12 as appropriate. In the following, in order to distinguish between the user terminal device 10 of the administrator and the user terminal device 10 of the family member, the former will be described as the user terminal device 10A, and the latter will be described as the user terminal device 10B. Similarly, in order to distinguish between the payment application 20 operating on the user terminal device 10A and the payment application 20 operating on the user terminal device 10B, the former will be described as the payment application 20A, and the latter will be described as the payment application 20B.
[0038] First, in the user terminal device 10A, the payment application 20A accepts the selection operation of the payment method management by the administrator (S101). In response to accepting the selection operation of the payment method management, the payment application 20A makes a content distribution request to the payment server 100 to display a payment method management screen (S102). The payment server 100 generates content data according to the content distribution request of S102 and distributes it to the user terminal device 10A (S103). The payment application 20A displays the payment method management screen based on the received content data (S104). Here, the payment method management screen includes a link to a screen that accepts setting operations related to family payment (family payment setting screen), and the payment application 20A accepts the selection operation of this link (S105) and makes a content distribution request to the payment server 100 to display the family payment setting screen (S106).
[0039] FIG. 9 is a diagram showing a display example of a payment method management screen. For example, the payment method management screen G10 shown in FIG. 9 displays information INF11 on the available amount (charge balance and point balance) and menu information INF12 on the settings of various payment methods. In this example, each setting menu M11 to M16 for post-payment, family payment, adding a bank account for charging, auto-charge, adding a credit card, or importing from a wallet is displayed as menu information INF12. The display of each setting menu may include information indicating the setting status. The example of FIG. 9 shows a situation in which post-payment and family payment are "not set" and auto-charge is "disabled". In this case, when post-payment or family payment is set, the payment application 20A may change the display of "not set" to a display of "set" or "edit", etc.
[0040] In the example of FIG. 9, payment application 20A requests content delivery of a family payment setting screen in response to an operation of selecting family payment setting menu M12 on payment method management screen G10. Here, a case where the family payment setting screen is called from the payment method management screen is described, but this is only an example, and the family payment setting screen may be called from a screen other than the payment method management screen. In addition, the payment method management screen may also be called from any screen of payment application 20A. For example, the payment method management screen may be called from the administrator's wallet screen.
[0041] FIG. 10 is a diagram showing an example of the display of an administrator's wallet screen. The wallet screen is a screen for managing the wallet of a user (here, the administrator). A wallet is a function that plays the role of a user's wallet in electronic payment services. The wallet screen displays information about the charge balance as basic information, as well as information about payment methods other than the charge balance and information such as transaction history. For example, the wallet screen G20 shown in FIG. 10 displays information INF21 to INF23 about various payment methods and information INF24 about transaction history. For example, information INF21 is information about the charge balance of the wallet.
[0042] The information INF22 is, for example, information about credit cards (XX cards) and post-payment. The example of FIG. 10 shows a situation where a message is displayed to a user (administrator) who has not applied for credit cards and post-payment, encouraging the user to apply for the use. The information INF23 is, for example, information about family payment. The example of FIG. 10 shows a situation where a message is displayed to a user (administrator) who has not applied for family payment, encouraging the user to apply for the use. The transaction history of the information INF24 includes at least the transaction history of each family member. This allows the administrator to share information about who used how much for each family member. The transaction history of the information INF24 may include the transaction history of the administrator. In addition, in order to protect the privacy of the family members, the payment application 20 of the administrator may be configured not to acquire or display detailed information about the transaction history (such as where and what was purchased). In addition, whether or not such detailed information is displayed may be managed so as to be changeable depending on the relationship between the member and the administrator, the attributes of the family, and the like. For example, if the administrator and the family members are in a parent-child relationship, the administrator may be able to view detailed information about each family member. In addition, if a family is a group for controlling spending among a specific group, all family members may be able to view detailed information of other family members. The wallet screen 20 is an example of a "secondary content."
[0043] The wallet screen G20 may be configured to arrange UIs such as buttons for accepting execution operations of actions related to the corresponding payment methods in association with information on various payment methods. For example, the wallet screen G20 may arrange a button BT11 for displaying information on the breakdown of the charge balance in association with information INF21. The wallet screen G20 may also arrange a button BT12 for making a use application in association with information INF22. The wallet screen G20 may also arrange a button BT13 for making a use setting of family payment in association with information INF23. In this case, when the button BT13 is pressed, the payment application 20A may, for example, display a family payment setting screen G30 shown in the following FIG. 11, or may display a payment method management screen G10 including a family payment setting menu M12.
[0044] Regarding the display of the wallet screen G20, the payment server 100 can recognize the charge balance and transaction history of the administrator by referring to the user information 172. Furthermore, the payment server 100 can recognize the status of application for use of other payment methods, the status of the usage settings of family payment, and the like by referring to the user information 172, and can notify the user of information according to those situations. The payment server 100 may change the notification content according to the situation, or may not display the information on the wallet screen G20.
[0045] FIG. 11 is a diagram showing a display example of a family payment setting screen. For example, the family payment setting screen G30 shown in FIG. 11 displays setting information INF31 of the family name, setting information INF32 of the payment method used for the family payment, setting information INF33 of the family members, and a button BT21 for deleting the setting of the family payment being displayed. For example, the setting information INF31 displays the current setting contents of the family name ("My Family" in the example of FIG. 11) as well as an edit button BT22 that allows the setting contents to be changed. In addition, the setting information INF32 of the payment method displays, for example, a list of fund sources that can be used in the family payment as well as check boxes CB23 to CB25 that accept a selection operation for each fund source. In addition, the family member information INF33 displays, for example, a list of registered family members and their respective upper limit amounts, as well as edit buttons BT26 to BT28 that allow the upper limit amounts of family members other than the administrator to be changed, and a button BT29 for adding a new family member. The family payment setting screen G30 is an example of the "third content".
[0046] The payment server 100 generates content data according to the content distribution request of S106 and distributes it to the user terminal device 10A (S107). The payment application 20A displays a family payment setting screen based on the received content data (S108). Next, the payment application 20A accepts a family payment setting operation (S109) and transmits the input setting contents to the payment server 100 (S110). The payment server 100 saves the setting contents received from the payment application 20A (S111). For example, the payment server 100 saves the upper limit amount of each family member in the user information 172, and saves the family setting contents in the family information 178.
[0047] Through the processing up to this point, the administrator completes the setting of the family payment. When the setting of the family payment is completed, the payment application 20B of the family member is notified that payment by the family payment is now possible.
[0048] FIG. 12 is a diagram showing a display example of a wallet screen of a family member. For example, the wallet screen G40 shown in FIG. 12 displays information INF41 of the charge balance, information INF42 of the transaction history, information INF43 of an application to use another payment method, and notification information INF44 that the administrator has permitted the use of family payment. As in the case of the administrator's wallet screen, the payment server 100 can recognize these pieces of information INF41 to INF44 by referring to the user information 172 of the family member. For example, the notification information INF44 shown in FIG. 12 notifies that the administrator (Uncle Sam in this case) is recommending (inviting) the use of family payment, and displays the family payment upper limit amount set by the administrator for the family member. Also, as in the example of FIG. 12, the payment application 20B may display a button BT31 for the family member to accept the notified content and start using family payment together with the notification information INF44. For example, when button BT31 is pressed, the payment application 20 cooperates with the payment server 100 to automatically charge the family member's wallet from the administrator's fund source, and transitions to a state in which family payment is available, without the family member having to perform a balance charge operation.
[0049] The charge balance of a family member may be displayed as the sum of the amount charged using the family payment and the amount charged using other methods, or may be displayed separately. The balance charge using the family payment may be performed any number of times as long as the cumulative amount of the charge during the set period does not exceed the family payment upper limit. The balance charge using the family payment may be performed automatically as long as the total charge amount is within the family payment upper limit, as set. Such an automatic balance charge may be performed when the charge balance falls below a threshold, or when the balance is insufficient at the time of payment. The payment server 100 may be configured to charge the full amount of the family payment upper limit at the start of the set period.
[0050] Returning to FIG. 8, the flow of processing when a family member of the family charges the balance by family payment after the setting of family payment (S101 to S111) is completed will be described. First, in the user terminal device 10B of the family member, the payment application 20B accepts an operation to execute the balance charge by family payment (S201). In response to accepting the operation to execute the balance charge, the payment application 20B withdraws a designated amount from the fund source of the administrator to the payment server 100 and adds it to the charge balance of the family member (S202). The payment server 100 notifies the payment application 20B that the balance charge is completed (S203). Upon receiving this charge completion notification, the payment application 20B updates the display of the charge balance (S204). Note that, as also described in FIG. 12, the balance charge for family payment may be automatically performed in response to an acceptance operation by the family member.
[0051] Through the above process, the family member's wallet is charged with an amount that can be used within the family payment upper limit from the fund source of the administrator. This allows the family member to make payments within the family payment upper limit within the set period.
[0052] FIG. 13 is a diagram showing a display example of a breakdown screen showing the breakdown of the charge balance of the administrator. For example, the breakdown screen G50 shown in FIG. 13 is displayed when the button BT11 is pressed on the wallet screen G20 of the administrator. The breakdown screen G50 includes, for example, information INF51 showing the total amount of the available charge balance, information INF52 on the charge balance available for family payment, and information INF53 showing the usage status of family payment by each family member. In addition, the information INF53 includes, for example, the upper limit amount of family payment set for each family member and the total amount paid by each family member with family payment. The payment server 100 can recognize these pieces of information by referring to the user information 172 of the administrator and the family members. For example, the payment server 100 can recognize the information INF52 by adding up the family payment balances of all family members. In addition, for example, the payment server 100 can recognize the total amount paid by the family members with family payment by referring to the payment history of the family members and adding up the payment amounts made within the corresponding set period. The breakdown information of the charge balance may be displayed as the breakdown screen G50, or may be additionally displayed within the wallet screen G20 in response to pressing of the button BT11. The breakdown screen G50 is an example of the "first content".
[0053] According to the embodiment described above, an administrator can set up a family and allow family members to make payments using family payment. This enables users who do not have any funding sources other than cash, such as children, to more easily use electronic payment services, thereby improving the convenience of electronic payment services.
[0054] Furthermore, according to the above embodiment, the administrator can set an upper limit on the amount that can be used for family payments for each family member, so that the family members can make appropriate payments within an allowable range.
[0055] Furthermore, according to the above embodiment, the administrator can check the usage status of family payments for each family member, and therefore can appropriately manage the purchasing behavior of family members.
[0056] In addition, the display control of various screens described in the above embodiment may be performed by either the payment server 100 or the user terminal device 10. For example, if the payment application 20 includes a web browser or a web view, the payment server 100 may distribute HTML data for displaying various screens to the user terminal device 10 as content data. In this case, since the substantial display control is performed on the payment server 100 side, for example, a web server or a web application operating on the payment server 100 plays the role of a display control unit. Also, for example, if the payment application 20 incorporates variable information into the format of various screens to perform screen display, the payment server 100 may distribute the necessary variable information to the user terminal device 10 as content data. In this case, since the substantial display control is performed on the payment application 20 side, the payment application 20 plays the role of a display control unit. The payment application 20 and the payment server 100 may be configured to appropriately distribute and execute such display control.
[0057] 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]
[0058] 10...user terminal device, 20...payment application, 50...first store terminal device, 60...store code image, 70...second store terminal device, 72...interface for affiliated stores, 100...payment server, 110...communication unit, 120...payment content providing unit, 130...payment processing unit, 140...information management unit, 170...storage unit, 172...user information, 174...payment content information, 176...store information, 178...family information, G10...payment method management screen, G20...wallet screen, G30...family payment setting screen, G40...wallet screen, G50...details screen
Claims
1. A payment management device that provides electronic payment services to a user in cooperation with an application program running on the user's terminal device, A storage unit that stores correspondence information between one or more fund sources owned by a first user and registered as payment methods in the electronic payment service, and one or more second users. A settlement processing unit that executes settlement processing to realize the aforementioned electronic payment service, Equipped with, The second user is a user who is permitted to use the first user's fund source when making a payment using the electronic payment service. The aforementioned settlement processing unit, When a payment is made in response to a payment request from the second user's terminal device, if the balance in the second user's electronic payment account is insufficient, the system will automatically charge the second user's electronic payment account from the first user's fund source based on the corresponding information to complete the payment. Payment management device.
2. The corresponding information includes, for each second user, information on the maximum amount that can be added from the fund source within a predetermined set period, The payment processing unit executes the automatic charge within the range of the upper limit amount. The payment management device according to claim 1.
3. When the settlement processing unit performs the automatic charge, it charges only the amount of the deficit in the settlement. The payment management device according to claim 1.
4. The payment processing unit notifies the first user in real time when the payment by the second user is completed. The payment management device according to claim 1.
5. A payment management method by a payment management device that provides electronic payment services to a user in cooperation with an application program running on the user's terminal device, The aforementioned payment management device The system stores correspondence information between one or more fund sources owned by the first user that are registered as payment methods in the electronic payment service, and one or more second users. This performs payment processing to realize the aforementioned electronic payment service. The second user is a user who is permitted to use the first user's fund source when making a payment using the electronic payment service. When a payment is made in response to a payment request from the second user's terminal device, if the balance in the second user's electronic payment account is insufficient, the system will automatically charge the second user's electronic payment account from the first user's fund source based on the corresponding information to complete the payment. Payment management methods.
6. An application program that operates on a user's terminal device and cooperates with the payment management device described in claim 1 to provide electronic payment services to the user, For each of the one or more second users, the total amount paid by the second user from the balance added from the fund source is obtained from the settlement management device and displayed on the terminal device of the first user. Application program.