Application program, settlement management apparatus, and method of controlling terminal device

The application program and payment management device enhance electronic payment systems by using charge and deferred payment methods with auto-charge functionality to prevent failures from insufficient balances, ensuring successful transactions.

JP2024179212AActive Publication Date: 2024-12-26PAYPAY CO LTD

Patent Information

Application Number
JP2023097875
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-06-14
Publication Date
2024-12-26
Estimated Expiration
2043-06-14

AI Technical Summary

Technical Problem

Conventional electronic payment systems fail to prevent higher priority payments from being executed when the account balance is insufficient, leading to unsuccessful transactions.

Method used

An application program and payment management device that utilize a first payment method with a charge balance and a second deferred payment method, along with auto-charge functionality to ensure sufficient funds for electronic payments.

Benefits of technology

Reduces the likelihood of electronic payment failures due to insufficient account balance by automatically charging the balance when necessary, ensuring successful transactions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2024179212000001_ABST
    Figure 2024179212000001_ABST
Patent Text Reader

Abstract

To reduce the possibility of errors in electronic settlement due to insufficient account balance in an electronic settlement service.SOLUTION: An application program which runs on a terminal device used by a user and provides an electronic settlement service to the user in cooperation with a settlement management apparatus, the application program being configured to: cause the terminal device to display a first screen which receives an operation to set priorities for a plurality of payment methods including a first payment method and a second payment method, as payment methods to be used in electronic settlement, the first payment method using a charge balance loaded in advance and managed by the settlement management apparatus, the second payment method using deferred payment, and cause the terminal device to display a second screen, which is a screen for setting an auto charing function that automatically executes charging to the charge balance without depending on user operation, when the priority of the first payment method of the plurality of payment methods is changed on the first screen.SELECTED DRAWING: Figure 14
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to an application program, a payment management device, and a control method for a terminal device. [Background technology]

[0002] Conventionally, in electronic payment services, technology has been proposed to prevent insufficient balances and to facilitate alternative payments when the balance is insufficient (Patent Document 1).For example, Patent Document 1 describes a system that displays a list of payments scheduled to be debited from the payer's account in order of the priority of each payment, and enables the priority of each payment to be changed by dragging and dropping the displayed scheduled payments. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2004-295302 A Summary of the Invention [Problem to be solved by the invention]

[0004] Conventional technology can prevent a lower-priority payment from preventing a higher-priority payment from being executed, but if the account balance is insufficient, the payment cannot be executed regardless of the priority, and electronic settlement may fail.

[0005] The present invention has been made in consideration of these circumstances, and one of its objectives is to provide an application program, a payment management device, and a control method for a terminal device that can reduce the possibility of electronic payment failing due to insufficient account balance in electronic payment services. [Means for solving the problem]

[0006] One aspect of the present invention is an application program that operates on a terminal device used by a user and works in cooperation with a payment management device to provide the user with an electronic payment service, the application program causing the terminal device to display a first screen that accepts a priority setting operation for multiple payment methods to be used when making an electronic payment, including a first payment method using a charge balance that is pre-charged and managed by the payment management device, and a second payment method using deferred payment, and causing the first screen to display a second screen that is a setting screen for an auto-charge function that automatically charges the charge balance without the user's operation if the priority of the first payment method among the multiple payment methods is changed. Effect of the Invention

[0007] According to one aspect of the present invention, it is possible to provide an application program, a payment management device, and a control method for a terminal device that can reduce the possibility of electronic payment failing due to insufficient account balance in an electronic payment service. [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] FIG. 2 is a diagram conceptually illustrating the processing of terminal payment and card payment. [Figure 8]FIG. 2 is a diagram showing an example of the contents of card payment setting information 210. [Figure 9] 1A and 1B are diagrams showing an example of a top screen IM1 and a payment method switching screen IM2 of a payment application 20. [Figure 10] 13 is a diagram showing an example of an auto-charge setting screen IM3 of a payment application 20. FIG. [Figure 11] FIG. 13 is a diagram showing an example of a priority setting screen IM4. [Figure 12] FIG. 11 is a first diagram showing an example of operation of the priority setting screen IM4. [Figure 13] FIG. 2 is a second diagram showing an example of operation of the priority setting screen IM4. [Figure 14] FIG. 13 is a diagram showing an example of a second auto-charge setting screen IM5. [Figure 15] 11 is a sequence diagram showing an example of a flow of processing executed in conjunction with a change in the priority order of payment methods; FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, with reference to the drawings, an embodiment of the application program, the payment management device, and the control method of the terminal device of the present invention will be described. The application program, the payment server, and the affiliated credit card company server work together to provide an electronic payment service. In the following description, the application program is referred to as a payment application. The combination of the payment server and the affiliated credit card company server is an example of a "payment management device." 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 the real world, 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.

[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 and an affiliated credit card company server 200. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more credit processing terminals 55, 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 credit processing terminal 55 is installed in the store, similarly to the first store terminal device 50. The credit processing terminal 55 includes, for example, a credit card settlement terminal (credit card reader) and a POS device. The credit card settlement terminal reads a PIN (Personal Identification Number) from an inserted or held credit card (including the affiliated card 57) and compares it with the PIN entered by the user, or transmits a BIN (Bank Identification Number) code, etc., read from the credit card to the affiliated credit card company server 200 via the POS device. The POS device cooperates with the credit card settlement terminal to transmit information such as the settlement amount to the affiliated credit card company server 200. An advance payment agent server (acquirer) may be interposed between the credit processing terminal 55 and the affiliated credit card company server 200. In the following, the description of the advance payment agent server will be omitted to simplify the explanation. The affiliated card 57 is, for example, of the same type as a commonly used credit card, with a communication chip embedded in the card substrate. The communication chip includes a storage medium that stores a PIN, and communicates with an external device via a contactor (or a wireless antenna). Alternatively, the affiliate card 57 may be a magnetic card.

[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] The affiliated credit card company server 200 manages affiliated credit card payments, which are part of the electronic payment service. The affiliated credit card company server 200 is operated, for example, by a group company (affiliated credit card company) of the payment server 100. The affiliated credit card company may be a separate entity from the external credit card company that provides the credit card as a funds source for charging the charge balance.

[0017] 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.

[0018] 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). At this time, if the charge balance of the electronic money is less than the payment amount and the user has already performed the auto-charge setting, the payment server 100 performs auto-charge to increase (charge) the charge balance and then performs electronic payment. The auto-charge setting will be described in detail later. Then, the payment server 100 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 by a display placed 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 procedure in which the user inputs the payment amount is omitted, and the first payment information is transmitted to the payment server 100 with the information on the payment amount included. The information on the affiliated store name and the store name may be included in the payment completion screen and displayed.

[0019] 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).

[0020] 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.

[0021] [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.

[0022] 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, and affiliated store / shop information 176.

[0023] 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.

[0024] 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.

[0025] 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. If the payment fails while the priority setting for multiple payment methods is enabled, the payment processing unit 130 automatically switches the payment method based on the priority and performs payment processing. The priority of the payment method can be changed by the user as appropriate, and details will be described later. Furthermore, the payment processing unit 130 performs auto-charge of electronic money based on the user's auto-charge setting when the charge balance meets a predetermined condition, such as when electronic payment is executed or when the charge balance falls below a predetermined amount.

[0026] 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 terminal payment method, a card payment method, an affiliated card number, a bank account, a credit card number, charge history information, payment history information, and an auto-charge 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.

[0027] The charge balance is information indicating the balance of electronic money that is set by a user by transferring money to the 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." Deferred payment refers to deducting the payment amount from a bank account or the like associated with the affiliated card 57 at a predetermined time such as a closing date, rather than immediately withdrawing from the charge balance. The deferred payment setting is flag information common to "terminal payment" and "card payment" described later. A user who can use deferred terminal payment is a user to whom the affiliated card 57 has been handed over. Alternatively, the deferred payment setting may be setting information that is set separately for "terminal payment" and "card payment." The terminal payment method is setting information indicating whether the user will perform electronic payment from the charge balance or deferred payment in "terminal payment." The card payment method is setting information indicating whether the user will make an electronic payment using the charge balance or a deferred payment in "card payment". The card payment method is synchronized in real time with the affiliated credit card company server 200. The affiliated card number is the number of the affiliated card 57 (e.g., PAN (Primary Account Number)). The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. This credit card number is the number of a credit card other than the affiliated card 57. The charge history information is a history of the user transferring money to the electronic payment service in advance to increase the charge balance. The payment history information is information indicating the details of the 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.).

[0028] The auto-charge setting is a setting that enables a so-called auto-charge function that automatically deposits funds from the user's fund source into the user's electronic payment account without user operation when the charge balance of electronic money meets certain conditions. If the user has already implemented the auto-charge setting and the charge balance of electronic money meets certain conditions, the automatic deposit process using the auto-charge function is executed. In this embodiment, the auto-charge setting is a common setting for charge balance payment in "terminal payment" and charge balance payment in "card payment", but different auto-charge settings may be provided for charge balance payment in "terminal payment" and charge balance payment in "card payment".

[0029] 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.

[0030] 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.

[0031] Here, terminal payment and card payment will be explained. Figure 7 is a diagram conceptually showing the processing of each of terminal payment and card payment. As described below, the electronic payment service allows four types of electronic payment: (1) terminal payment / payment with charge balance, (2) terminal payment / payment after delivery, (3) card payment / payment with charge balance, and (4) card payment / payment after delivery.

[0032] [Terminal payment] (1) When the payment server 100 (payment processing unit 130) acquires payment information from the user terminal device 10 or the first store terminal device 50, terminal payment is initiated. The payment server 100 acquires the "terminal payment method" of the user by referring to the user information 172. The payment server 100 performs electronic payment by its own processing for a user whose "terminal payment method" is set to "charge balance". In this case, 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.

[0033] (2) In terminal payment, the payment server 100 transfers the payment information to the affiliated credit card company server 200 together with the affiliated card number of the user obtained by referring to the user information 172 for the user who has set the "terminal payment method" to "deferred payment." The affiliated credit card company server 200 checks whether the cumulative payment amount indicated in the payment information does not exceed the upper limit for the current month, and if it does not exceed the upper limit, performs processing such as adding the obtained payment amount to the cumulative payment amount for the user. The cumulative payment amount for the month is settled, for example, by withdrawing the payment amount from a bank account all at once on the payment date of the following month.

[0034] [Credit card payment] (3) When the affiliated credit card company server 200 acquires the payment information from the credit processing terminal 55, electronic payment (card payment) using the affiliated card 57 is started. The affiliated credit card company server 200 refers to the card payment setting information 210 stored in a storage unit (not shown). FIG. 8 is a diagram showing an example of the contents of the card payment setting information 210. The card payment setting information 210 is information in which information unique to a user (e.g., PAN), a card payment method, and the account ID of the user are associated with each other. The card payment method and the account ID are the same information as those included in the user information 172 in FIG. 5, and are synchronized with the payment server 100. For a user whose "card payment method" is set to "charge balance", the affiliated credit card company server 200 transfers the payment information to the payment server 100 together with the account ID of the user obtained by referring to the card payment setting information 210. The payment server 100 performs the same process as when the "terminal payment method" is set to "charge balance" in the terminal payment based on the acquired payment information.

[0035] (4) In card payments, the affiliated credit card company server 200 performs electronic payments by its own processing for users whose "card payment method" is set to "deferred payment." In this case, the affiliated credit card company server 200 performs processing similar to that in terminal payments when the "terminal payment method" is set to "deferred payment."

[0036] Switching between "charge balance" and "deferred payment" in each of "terminal payment" and "card payment" is performed according to a user's operation on the payment application 20. The payment application 20 separately provides the user with an interface screen for selecting either the "charge balance" or "deferred payment" payment method (or other payment methods) in "terminal payment", and an interface screen for selecting either the "charge balance" or "deferred payment" payment method (or other payment methods) in "card payment".

[0037] In the following explanation, a method of making electronic payment based on a charge balance is an example of a first method, and a method of making electronic payment by deferred payment is an example of a second method, but this relationship may be reversed.

[0038] [Payment method setting user interface] Here, the switching between the first method and the second method, the switching of the auto-charge setting, and the change of the priority order of the multiple payment methods are performed in response to the user's operation on the payment application 20. FIG. 9 is a diagram showing an example of the top screen IM1 of the payment application 20 and the payment method switching screen IM2. As shown in the left diagram of FIG. 9, for example, the top screen IM1 of the payment application 20 includes an area A1 including code images such as barcodes and QR codes (registered trademarks) used in smartphone payment, an area A2 in which icons for instructing main operations in smartphone payment such as charging and scanning are set, and an area A3 in which various icons for instructing various service settings in electronic payment services are set. In the area A3, an icon IC1 for receiving an instruction to switch the payment method in card payment, an icon IC2 for receiving an instruction to switch the auto-charge setting, and an icon IC3 for receiving an instruction to change the priority order setting for the multiple payment methods are set.

[0039] When the user operates the icon IC1, the screen transitions to the payment method switching screen IM2 shown in the right diagram of FIG. 9. The payment method switching screen IM2 is provided with, for example, a notation "credit card payment" and a software switch SS1 that can be operated to either ON or OFF. By operating the software switch SS1 to either ON or OFF, the user can set the payment method for card payment to either a method of electronic payment based on the charge balance or a method of electronic payment by deferred payment. When the state of the software switch SS1 is switched, the payment server 100 linked with the payment application 20 notifies the affiliated credit card company server 200 of the state after the switch. For example, the information management unit 140 mainly performs this process, but it may be performed by another functional unit. When the software switch SS1 is switched from an off state to an on state, the payment server 100 instructs the affiliated credit card company server 200 to change the card payment method setting to "deferred payment", and when the software switch SS1 is switched from an on state to an off state, the payment server 100 instructs the affiliated credit card company server 200 to change the card payment method setting to "charge balance". At this time, the information management unit 140 also changes the card payment method setting in the user information 172. In the above, the payment method is selectively set from one of two methods on the payment method switching screen IM2, but the payment method may be selected from three or more methods. For example, one payment method may be selected from "charge balance", "debit card" and "deferred payment" described later. In that case, one of "charge balance", "debit card" and "deferred payment" may be treated as a third method that does not correspond to either the first method or the second method, or the first method or the second method may include multiple methods.

[0040] In this way, the affiliated credit card company server 200 acts as an interface to allocate the payment method for card payments, making it possible to realize two payment methods using the existing credit card information transmission network. This makes it possible to improve user convenience at low cost without building a new information transmission network.

[0041] [Auto-charge settings user interface] On the other hand, when the user operates the icon IC2, the screen transitions to the auto-charge setting screen IM3 shown in FIG. 10. The auto-charge setting screen IM3 has, for example, a notation "Enable auto-charge" and a software switch SS2 that can be operated to either ON or OFF. By the user operating the software switch SS2 to either ON or OFF, the auto-charge can be set to either an enabled state or an disabled state. When the software switch SS2 is switched from an OFF state to an ON state, the payment server 100 changes the value of the auto-charge setting in the user information 172 to "Done", and when the software switch SS2 is switched from an ON state to an OFF state, the payment server 100 changes the value of the auto-charge setting in the user information 172 to "None". In addition, the auto-charge setting screen IM3 has a first setting menu MN1 that accepts a setting operation of the minimum deposit amount (minimum charge amount) when depositing money by auto-charge, and a second setting menu MN2 that accepts a setting operation of the charge method. The charge method may be a withdrawal from a specified bank account, or the charge amount may be paid by post-payment (including credit card).

[0042] As described above, the auto-charge setting in this embodiment is common to both the charge balance payment in "terminal payment" and the charge balance payment in "card payment." That is, when the software switch SS2 is changed to the ON state on the auto-charge setting screen IM3, auto-charge is enabled for both the card payment and charge balance payment payment methods, and when the software switch SS2 is changed to the OFF state, auto-charge is disabled for both the card payment and charge balance payment payment methods.

[0043] As described above, the auto-charge setting may be provided for each of the charge balance payment in the "terminal payment" and the charge balance payment in the "card payment". In this case, for example, a software switch for terminal payment and a software switch for card payment may be provided in the auto-charge setting screen IM3. Also, for example, different auto-charge setting screens may be provided for the charge balance payment in the "terminal payment" and the charge balance payment in the "card payment". Also, for example, an icon for transitioning to a different auto-charge setting screen for the charge balance payment in the "terminal payment" and the charge balance payment in the "card payment" may be placed on the top screen. Note that, when the auto-charge setting screen is separated for the terminal payment and the card payment, the auto-charge setting screen for the card payment may be configured as a so-called mini-app that cooperates with the affiliated credit card company server 200. In this case, the payment application 20 is configured as a super application equipped with a mini-app.

[0044] [User interface for setting payment method preferences] On the other hand, when the user operates icon IC13, the screen transitions to a priority setting screen IM4 shown in Fig. 11. The priority setting screen IM4 includes, for example, a software switch SS3 for enabling or disabling the priority setting for a payment method, a first list area R1 displaying a list of payment methods with high priority, a second list area R2 displaying a list of other payment methods, and a setting save button B1. In the first list area R1 and the second list area R2, operation icons IC11 to IC14 are displayed in association with each payment method as a user interface for accepting an operation to change the priority.

[0045] The payment method with a high priority may be determined based on any criteria. The payment method with a high priority may be defined in advance by the payment service provider, or may be defined by the user. Here, it is assumed that the payment method with a high priority is defined in advance by the payment service provider. For example, in the following, it is assumed that the charge balance payment (first method) and deferred payment (second method) are defined as the payment methods with a high priority, and credit card payment is defined as the other payment method.

[0046] Fig. 11 shows a state where software switch SS3 is switched to the on side (right side in the example shown in the figure) and priority setting for payment methods is enabled. In this state, payment application 20 is in a state where a priority setting operation can be performed for the payment methods with high priority displayed in first list area R1. Fig. 11 shows a case where charge balance payment M11 and deferred payment M12 are registered as payment methods with high priority, and two credit card payments M21 and M22 are registered as other payment methods. In this case, payment application 20 accepts a priority setting operation for charge balance payment M11 and deferred payment M12.

[0047] [Basic operations for changing priority] 12 and 13 are diagrams showing specific examples of visual effects that are generated when the priority setting screen IM4 accepts an operation to change the priority of the payment method. Here, a case will be described in which the priority order set in the order of the balance payment M11 and the deferred payment M12 (the situation in FIG. 11) is changed to the order of the deferred payment M12 and the balance payment M11. First, when the payment application 20 accepts a selection operation of the operation icon IC11 corresponding to the balance payment M11, it generates a visual effect in which the display of the selected balance payment M11 moves to another priority order in response to the drag operation of the user, and the display of the deferred payment M12 moves to another priority order in response to the movement of the balance payment M11. Such a visual effect may be implemented, for example, as a so-called long press drag operation (a gesture in which one point is pressed and held, then moved and released). Note that the touch operation can be interpreted as a mouse operation corresponding to the appropriate operation. The long press time is arbitrary, but is typically assumed to be about 0.5 to 1 second.

[0048] The situation in FIG. 12 shows a situation in which the selected recharge balance payment M11 (first in priority order) is moved in the direction of the second in priority order, and accordingly the deferred payment M12, which has the second highest priority order, is moved to the first highest in priority order. In this situation, the visual effect of the change in priority order is still being displayed, and the destination of the recharge balance payment M11 is not yet determined. In this state, by canceling the selection of the recharge balance payment M11, the destination of the recharge balance payment M11 is determined to be the second highest in priority order (see FIG. 13). In the example of FIG. 13, this determination changes the display of the priority order of the recharge balance payment M11 to second place, and the display of the priority order of the deferred payment M12 to first place. Note that the determination here refers merely to the determination of the display position, and does not determine the change in the priority order setting. The change in the priority order setting is determined when the Save Settings button B1 is pressed. In response to the pressing of the Save Settings button B1, the payment application 20 notifies the payment server 100 of the setting contents at that time. The payment server 100 stores the notified setting contents in the user information 172 as, for example, a payment method setting.

[0049] In addition, the payment application 20 may generate a further visual effect at the timing when the long press is completed, in order to make it easier for the user to recognize that the payment method to be operated has been appropriately selected and is in a movable state. For example, the payment application 20 may generate a visual effect such that the display area of ​​the selected payment method appears to be floating. In addition, for example, the payment application 20 may change the color, size, shape, etc. of the selected payment method, or may display characters, figures, etc. indicating that the payment method is in a movable state in association with the target payment method. This visual effect may be released when the movement operation is completed (i.e., the finger is released).

[0050] [Behavior of the priority setting screen when auto-charge setting is enabled] In Fig. 12 and Fig. 13, the basic contents of the operation for changing the payment priority order have been described, but the payment application 20 of this embodiment further has a function of automatically displaying a second auto-charge setting screen that accepts an operation for changing the auto-charge setting in response to a change in the priority order of the first method (balance payment) on the priority order setting screen, without the user's operation. Fig. 14 is a diagram showing an example of the display of the second auto-charge setting screen. Fig. 14 shows a situation in which the second auto-charge setting screen IM5 is displayed in the form of a so-called half sheet in response to the change in priority order of the balance payment M11 on the priority order setting screen IM4 similar to Figs. 11 to 13.

[0051] A half sheet is a type of user interface used to temporarily suspend a user's operation, prompt some action, or display a notice such as an error. Generally, as shown in FIG. 14, a half sheet is often displayed superimposed on a part of a screen that was previously displayed (here, priority setting screen IM4). Also, as shown in FIG. 14, when a half sheet is displayed, the screen that was previously displayed may be low-lighted. A half sheet may be displayed modally or non-modally. Also, as shown in FIG. 14, a half sheet may be displayed with a visual effect of rising from outside the screen at the bottom of the screen, and may be hidden with a visual effect of sinking outside the screen at the bottom of the screen. Here, a case where the second auto-charge setting screen is configured as a half sheet is illustrated, but the auto-charge setting screen may be displayed in other ways (for example, a pop-up display or a transition to another screen).

[0052] The second auto-charge setting screen IM5 in Fig. 14 is an example in which an operation interface similar to that of the auto-charge setting screen IM3 illustrated in Fig. 10 is arranged. More specifically, in the example of Fig. 14, the second auto-charge setting screen IM5 has a software switch SS4 similar to the software switch SS2, a first setting menu MN3 similar to the first setting menu MN1, and a first setting menu MN4 similar to the second setting menu MN2. By displaying this type of second auto-charge setting screen in response to a change in the priority of the first method, the user can check the auto-charge setting contents at an appropriate time and can remember to make any necessary setting changes.

[0053] In the example of FIG. 14, the second auto-charge setting screen IM5 may be displayed after the changed priority order setting is confirmed, or may be displayed before the priority order setting change is confirmed, in a state in which the operation of moving the payment method is completed and each payment method is displayed with the changed priority order. In addition, the second auto-charge setting screen IM5 may be displayed with a performance of being pulled up (rising up) from the bottom of the screen in conjunction with an operation of changing the priority order of each payment method (for example, an operation of swiping the priority order of the first method to a higher order). In addition, the second auto-charge setting screen IM5 may be displayed by a predetermined operation after the operation of moving the payment method is completed. For example, the second auto-charge setting screen IM5 may be displayed in a manner accompanied by a performance of being raised up from the bottom end of the screen in response to an operation of swiping the bottom end of the screen upward.

[0054] [One-time code] FIG. 15 is a sequence diagram showing an example of a change in the priority order of payment methods in terminal payment and a flow of processing executed in association with the change. First, the payment application 20 displays a priority order setting screen IM4 by a predetermined operation of the user (S31). The priority order setting screen IM4 may be displayed by the user executing a specific command from the operation menu of the payment application 20, or may be displayed by the user accessing a deep link displayed on a web page or an application (including the payment application 20). The payment application 20 displays the priority order setting screen IM4 when multiple high-priority payment methods are set. For example, when the high-priority payment methods are the charge balance payment and the deferred payment, the payment application 20 displays the priority order setting screen IM4 when both of them are set for use. Generally, in electronic payment services, the charge balance payment is the default payment method, and the deferred payment is positioned as an optional payment method. In this case, the payment application 20 may be configured to display the priority order setting screen IM4 when the deferred payment is set to be available, and not to display the priority order setting screen IM4 when the deferred payment is not set to be available and only the charge balance payment is available. Furthermore, the payment application 20 may be configured to change whether or not to include a command for displaying the priority setting screen IM4 in the operation menu depending on whether or not deferred payment is set.

[0055] When the payment application 20 accepts the operation to change the priority order (S32), it sends a notification that the priority order of the payment method has been changed (change notification) and a request to issue a one-time code to the payment server 100 (S33). Note that the operation to change the priority order may include a first operation to enable the priority order setting for the payment method, in addition to a second operation to select the payment method and move it to a different position in the order from the current one. Note that the payment application 20 may be configured to accept the second operation when the priority order setting for the payment method is enabled.

[0056] The payment server 100 changes the "payment method setting" item of the user information 172 in response to the change notification (S34), generates a one-time code (S35), and transmits the one-time code to the payment application 20 (S36). The payment application 20 updates the code image using the received one-time code (S37), and transitions to the top screen to display the updated code image (S38).

[0057] In addition, in the payment application 20, the transition to the top screen after updating the code image may not be performed automatically, but may be performed by a user's operation. Also, the code image may be updated when it is necessary to display the code image. In this case, as described above, the payment application 20 sends a request to issue a one-time code to the payment server 100, the payment server 100 sends the one-time code to the payment application 20, and the payment application 20 updates the code image using the one-time code.

[0058] Here, the updated code image has the current payment method setting for electronic payment set to select a payment method based on priority, and information indicating the priority of multiple payment methods encoded therein. The payment processing unit 130 performs electronic payment by checking both the payment method setting read from the code image and transmitted from the first store terminal device 50 and the payment method setting registered in the user information 172. Alternatively, if information indicating the priority of multiple payment methods is not encoded in the code image, the payment processing unit 130 may perform electronic payment by checking only the payment method setting registered in the user information 172.

[0059] According to the embodiment described above, in an electronic payment service, it is possible to reduce the possibility that an electronic payment will fail due to insufficient account balance.

[0060] <Modification> In addition, the second auto-charge setting screen may be configured to be displayed when the priority of the first method (balance charge payment) is changed from the previous priority to a higher priority on the priority setting screen IM4.

[0061] In addition, the second auto-charge setting screen may be configured to be displayed when the priority of the first method (balance charge payment) is changed to a higher priority than the second method (postpaid) on the priority setting screen IM4.

[0062] The second auto-charge setting screen may be configured to be displayed when the priority of the first method (balance charge payment) is changed to first on the priority setting screen IM4.

[0063] The second auto-charge setting screen may be configured to be displayed when the priority of the first method is changed on the priority setting screen IM4 while the auto-charge setting is disabled. For example, a state in which the auto-charge setting is disabled is a state in which the software switch SS2 is set to OFF in advance on the auto-charge setting screen IM3 in the example of FIG.

[0064] In the above embodiment, the case where the payment method to be used in card payment is set on the payment method switching screen IM2 has been described, but the priority order of the payment method may be set for card payment as in the case of terminal payment. In this case, the payment server 100 may be configured to automatically switch the payment method based on the priority order and perform payment processing in the case where the payment fails in a state where the priority order setting for multiple payment methods is enabled, as in the case of terminal payment. Also, in this case, the priority order setting of the payment method may be a common setting for card payment and terminal payment. In this case, the payment server 100 can set the priority order setting information to a common setting by synchronizing the priority order setting information with the affiliated credit card company server 200.

[0065] On the other hand, the priority of the payment method may be set differently for card payment and terminal payment. In this case, the payment application 20 may be configured to provide a priority setting screen for card payment similar to the priority setting screen IM4 for terminal payment. In this case, the priority setting screen for card payment is configured as, for example, a mini-app, and the setting contents are registered and managed in the affiliated credit card company server 200. In addition, in this way, when the priority setting of the payment method is provided separately for card payment and terminal payment, the priority setting screen for card payment may also be configured to display a second auto-charge setting screen in response to a change in the priority of the first method, similar to the priority setting screen IM4 for terminal payment. In addition, a priority setting screen for card payment may be provided instead of the priority setting screen IM4 for terminal payment.

[0066] In addition, when a priority setting screen IM4 for terminal payment and a priority setting screen for card payment are provided, and separate auto-charge settings are provided for terminal payment and card payment, the payment application 20 may be configured to display a second auto-charge setting screen when the priority of the first method is changed on the priority setting screen for card payment while the auto-charge setting for card payment is set to OFF. In this case, the payment application 20 may be configured not to display the second auto-charge setting screen regardless of the state of the auto-charge setting for terminal payment when the priority of the first method is changed on the priority setting screen IM4 for terminal payment. That is, in this case, the payment application 20 may be configured to display a second auto-charge setting screen when the priority of the payment method is changed by the mini-app of the affiliated credit card company server 200 for electronic payment using the affiliated card 57.

[0067] In the above embodiment, the case where the display of the various setting screens is controlled by the payment application 20 has been described, but the display of the various setting screens may be controlled by the payment server 100 or the affiliated credit card company server 200. In this case, the various setting screens may be configured as WebViews, and some or all of the display contents may be provided by the payment server 100 or the affiliated credit card company server 200.

[0068] 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]

[0069] 10 User terminal device 20. Payment App 50 First store terminal device 55 Credit card processing terminal 57 Affiliated Cards 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 credit card company server 210 Card payment setting information

Claims

1. An application program that operates on a terminal device used by a user and provides an electronic payment service to the user in cooperation with a payment management device, The terminal device, displaying a first screen for accepting an operation for setting a priority order for a plurality of payment methods to be used in electronic payment, the payment methods including a first payment method based on a charge balance that is pre-charged and managed by the payment management device, and a second payment method based on deferred payment; displaying a second screen which is a setting screen for an auto-charge function for automatically charging the charge balance without the user's operation when the priority of the first payment method among the plurality of payment methods is changed on the first screen; Application program.

2. the application program displays the second screen when the priority of the first payment method is changed to a priority higher than before the change.

2. The application program according to claim 1.

3. the application program displays the second screen when the priority of the first payment method is changed to first priority.

2. The application program according to claim 1.

4. the application program displays the second screen when the priority of the first payment method is changed while the auto-charge function is disabled.

2. The application program according to claim 1.

5. The electronic payment service is A first payment method for performing electronic payment using the terminal device; A second payment method in which electronic payment is performed based on card information read from a card given to the user, the card being separate from the terminal device and recording card information for the user to use the electronic payment service; This is to provide users with The setting of the auto-charge function is managed as a common setting for the first payment method and the second payment method.

2. The application program according to claim 1.

6. The electronic payment service is A first payment method for performing electronic payment using the terminal device; A second payment method in which electronic payment is performed based on card information read from a card given to the user, the card being separate from the terminal device and recording card information for the user to use the electronic payment service; to users, The priority order of the payment method is set separately for the first payment method and the second payment method, The application program When the priority order of the payment method is changed with respect to the second payment method, the second screen is displayed; When the priority order of the payment method is changed with respect to the first payment method, the second screen is not displayed.

2. The application program according to claim 1.

7. A payment management device that provides an electronic payment service to a user in cooperation with an application program that runs on a terminal device used by the user, comprising: displaying in the application program a first screen for accepting an operation for setting a priority order for a plurality of payment methods to be used in electronic payment, the payment methods including a first payment method based on a charge balance that is pre-charged and managed by the payment management device, and a second payment method based on post-payment; said electronic payment being carried out based on the priority order of the payment methods set on said first screen; when the priority of the first payment method among the plurality of payment methods is changed on the first screen, displaying in the application program a second screen which is a setting screen for an auto-charge function for automatically charging the charge balance without the user's operation; Payment management device.

8. A method for controlling a terminal device used by a user by an application program that operates in the terminal device and provides an electronic payment service to the user in cooperation with a payment management device, comprising: The terminal device, displaying a first screen for accepting an operation for setting a priority order for a plurality of payment methods to be used in electronic payment, the payment methods including a first payment method based on a charge balance that is pre-charged and managed by the payment management device, and a second payment method based on deferred payment; displaying a second screen which is a setting screen for an auto-charge function for automatically charging the charge balance without the user's operation when the priority of the first payment method among the plurality of payment methods is changed on the first screen; A method for controlling a terminal device.

Citation Information

Patent Citations

  • Electronic wallet device and electronic wallet program

    JP2005352733A

  • Information processing system

    JP2019074983A

  • Cashless settlement integrated system

    JP2021086344A

  • Information processing device, information processing method and information processing program

    JP2022157746A

  • Payment management method, payment management device and payment management program

    JP2004295302A

Cited By

  • Payment management device, payment management method, program, and application program

    JP2026142113A

  • Information processing device, control method for information processing device, and program

    JP7826555B1

  • Payment management device, payment management method, program, and application program

    JP7835923B1

  • Information processing device, method for controlling the information processing device, and program

    JP7858953B1

  • Information processing device, method for controlling the information processing device, and program

    JP7866132B1