JP7361979B1 - Application program, payment management device, and terminal device control method - Google Patents

Abstract

[Problem] To reduce the possibility of electronic payment failure due to insufficient account balance in an electronic payment service. [Solution] An application program that operates on a terminal device used by a user and cooperates with a payment management device to provide an electronic payment service to the user; accept priority setting operations for a plurality of payment methods, including a first payment method using a charge balance that has been charged in advance and is managed by the payment management device, and a second payment method that uses deferred payment; A first screen is displayed, and if the priority of the first payment method among the plurality of payment methods is changed on the first screen, the user operates to charge the balance to the charge balance. An application program that displays a second screen that is a setting screen for an auto charge function that is automatically executed without depending on the system. [Selection diagram] Figure 14

Description

The present invention relates to an application program, a payment management device, and a method of controlling a terminal device.

BACKGROUND ART Conventionally, in electronic payment services, techniques have been proposed to prevent insufficient balances and to facilitate alternative payments when balances are insufficient (Patent Document 1). For example, Patent Document 1 discloses that a list of payments scheduled to be debited from a payer's account is displayed in order of priority of each payment, and the priority of each payment can be changed by dragging and dropping the displayed payment schedule. It is stated that it should be done.

Japanese Patent Application Publication No. 2004-295302

With conventional technology, it is possible to prevent a higher priority payment from being unable to be executed due to the execution of a lower priority payment, but if the account balance is insufficient, the payment can be executed regardless of the priority. In some cases, electronic payments failed.

The present invention has been made in consideration of such circumstances, and provides an application program, a payment management device, and a terminal that can reduce the possibility that electronic payments will fail due to insufficient account balance in electronic payment services. One of the purposes is to provide a method for controlling the device.

One aspect of the present invention is an application program that operates on a terminal device used by a user and cooperates with a payment management device to provide an electronic payment service to the user, the application program providing an electronic payment service to the terminal device. Setting priorities for a plurality of payment methods, including a first payment method using a charge balance that is charged in advance and managed by the payment management device, and a second payment method using deferred payment. displaying a first screen for accepting operations, and when the priority of the first payment method among the plurality of payment methods is changed on the first screen, charging the balance to the charge balance using the charge method; This is an application program that displays a second screen that is a setting screen for an auto-charge function that is automatically executed without any human operation.

According to one aspect of the present invention, it is possible to provide an application program, a payment management device, and a terminal device control method that can reduce the possibility that electronic payments will fail due to insufficient account balance in electronic payment services. can.

1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. FIG. 1 is a sequence diagram (Part 1) illustrating the general flow of electronic payment. FIG. 2 is a sequence diagram (Part 2) illustrating the general flow of electronic payment. FIG. 1 is a configuration diagram of a payment server 100 according to a first embodiment. 3 is a diagram showing an example of the contents of user information 172. FIG. It is a diagram showing an example of the contents of member store/store information 176. FIG. 3 is a diagram conceptually illustrating each process of terminal payment and card payment. 2 is a diagram showing an example of the contents of card payment setting information 210. FIG. It is a diagram showing an example of a top screen IM1 and a payment method switching screen IM2 of the payment application 20. It is a diagram showing an example of an auto charge setting screen IM3 of the payment application 20. It is a figure which shows an example of priority setting screen IM4. FIG. 4 is a first diagram showing an example of how the priority setting screen IM4 is operated. It is a 2nd diagram showing an example of operation of priority setting screen IM4. It is a figure which shows an example of 2nd auto charge setting screen IM5. FIG. 2 is a sequence diagram illustrating an example of a change in the priority order of payment methods and a flow of processing executed accordingly.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of an application program, a payment management device, and a method for controlling a terminal device according to the present invention will be described below with reference to the drawings. The application program, the payment server, and the affiliated credit card company server cooperate to provide electronic payment services. In the following description, the application program will be referred to as a payment application. Furthermore, a combination of a payment server and an affiliated credit card company server is an example of a "payment management device." An electronic payment service is a service that supports payments for purchases of products and services at stores. A store is, for example, a physical store (actual store) that exists in real space, but may also include a virtual store for electronic commerce. Virtual stores may include those provided by entities different from the operator of the electronic payment service. In this case, when paying for shopping at the virtual store, the screen is controlled to transition to an interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to a member store (brand), for example, and processing such as payment when a purchase is made at a store is mainly performed between a user and the member store. Alternatively, processing such as payment may be performed between the user and the store.

[Electronic payment service]
FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by the payment server 100 and the affiliated credit card company server 200. The payment server 100, for example, communicates with each of 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 the network NW. to communicate. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like.

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, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), and the like. In the user terminal device 10, the payment application 20 is executed by a processor such as a CPU, so that the payment application 20 operates in cooperation with the payment server 100 to provide electronic payment services to the user. The payment application 20 is installed on the user terminal device 10 from an application store, for example, and controls a camera, a communication device, a touch panel, and the like.

The first store terminal device 50 is installed in a store, for example. 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 POS device may realize a product price acquisition function and an optical reading function. The store code image 60 is placed in a store, and a code image such as a QR code (registered trademark) is printed on a paper or plastic medium. Note that the store code image 60 may be displayed on a display (or a display of a terminal device such as a smartphone) placed in the store.

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 payment terminal (credit card reader) and a POS device. The credit card payment terminal reads the PIN (Personal Identification Number) from the inserted or held credit card (including the affiliated card 57) and compares it with the PIN input by the user, or reads the BIN (Bank identification number) code, etc., to the affiliated credit card company server 200 via the POS device. The POS device cooperates with the credit card payment terminal to transmit information such as the payment 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, to simplify the explanation, description of the advance payment agency server will be omitted. The affiliated card 57 is, for example, similar to a commonly used credit card, and has a communication chip embedded in the card base material. The communication chip has a built-in storage medium that stores a PIN, and communicates with an external device via a contactor (or wireless antenna). Alternatively, the affiliated card 57 may be a magnetic card.

The second store terminal device 70 is used by an operator of a member store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. In the second store terminal device 70, an interface 72 for member stores operates. The member store interface 72 may be an application for member stores or may be a browser. The member store interface 72 receives coupon settings and the like from the member store operator 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 the store code image and reading the code image displayed by the user terminal device 10 by executing an application for member stores. have

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 a member store server, in which case payment information is transmitted from the POS device to the payment server 100 via the member store server. In the following description, it is assumed that payment information is transmitted from the first store terminal device 50 without making any particular distinction.

The affiliated credit card company server 200 manages affiliated credit card payments that are part of the electronic payment service. The affiliated credit card company server 200 is operated by, for example, 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 fund source for charging the charge balance.

2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns, pattern 1 and pattern 2, in electronic payment.

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 using an optical reading function (S1). The store code image 60 includes information on a store URL (Uniform Resource Locator). This store URL is the domain of the electronic payment service added with information that can identify the store, and is associated with member store IDs, store IDs, etc. in the payment server 100 (described later). The payment application 20 transmits first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the member store ID and store ID corresponding to the store URL, obtains the member store name and store name information (S3), and sends the information to the payment application 20 (S4). . The user inputs the payment amount into the user terminal device 10 on the screen on which the member store name and 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 electronic money charge balance is less than the payment amount and the user has already configured the auto jersey settings, the payment server 100 executes auto charge to increase the charge balance ( Charge) and then make an electronic payment. Details of the auto charge setting will be described later. Then, the payment server 100 transmits a payment completion notification (information for displaying the 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 placed in a 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 for the user to input the payment amount is omitted, and the first payment information includes information on the payment amount and is sent to the payment server 100. Information on the member store name and store name may be included and displayed on the payment completion screen.

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 on the payment application 20, and when the automatic update timing (for example, every minute) is reached. , and at other timings, the payment application 20 transmits a one-time code issuance request to the payment server 100 (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment application 20 (S13). The payment application 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds up (presents) the display surface of the user terminal device 10 to the first store terminal device 50, and the first store terminal device 50 decodes the code image using an optical reading function and obtains a one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including a one-time code, payment amount, member store ID, store ID, etc., and transmits it to the payment server 100 (S16). Information on the payment amount is obtained in advance by barcode reading, manual input, etc. The payment server 100 identifies the user corresponding to the one-time code based on the received information and performs electronic payment (S17). Then, the payment server 100 transmits a payment completion notification to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

Note that electronic payment may be performed using only one of the above patterns. Moreover, the "account ID" explained in FIG. 2 may be other information (for example, a telephone number) that can be used as user identification information. Furthermore, the 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 that case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[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 section 110, a payment content providing section 120, a payment processing section 130, an information management section 140, and a storage section 170. 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 are hardware (circuit parts) such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit). (including circuitry), or may be realized by collaboration between software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transitory storage medium) such as an HDD (Hard Disk Drive) or flash memory, or may be stored in a removable storage device such as a DVD or CD-ROM. It may be stored in a medium (non-transitory storage medium), and installed in the storage device by loading the storage medium into a drive device.

The storage unit 170 is an HDD, flash memory, RAM (Random Access Memory), or the like. The storage unit 170 may be a NAS (Network Attached Storage) device that can be accessed by the payment server 100 via a network. The storage unit 170 stores information such as user information 172, payment content information 174, and member store/store information 176.

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

The payment content providing unit 120 has, for example, the function of a web server, and provides the user terminal device 10 with information (content) for displaying various screens of the electronic payment service. The payment content providing unit 120 reads necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 receives various inputs from 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.

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. In addition, if the payment processing unit 130 fails to make a payment in a state where priority setting is enabled for multiple payment methods, the payment processing unit 130 automatically switches the payment method based on the priority order and performs payment processing. . The priority order of payment methods can be changed by the user as appropriate, and details will be described later. In addition, the payment processing unit 130 performs automatic charging based on the user's auto-charging settings when the charging balance satisfies a predetermined condition, such as when performing electronic payment or when the charging balance becomes less than a predetermined amount. Carry out automatic charging of electronic money.

FIG. 5 is a diagram showing an example of the contents of the user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, user URL, account ID, phone number, password, email address, user ID, name/address/date of birth, registration date, charge balance, deferred payment setting, deferred payment limit, deferred payment. Information such as usage amount, available deferred payment amount, terminal payment method, card payment method, affiliated card number, bank account, credit card number, charge history information, payment history information, auto charge setting, etc. are associated with each other. The user URL is used for remittance processing between users. When registering for a new electronic payment service, it is mandatory to register a phone number and password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that can be arbitrarily set (or does not need to be set) by the user. Similarly, e-mail address, name, address, and date of birth are information that can (or does not need to be) set arbitrarily by the user. The registration date is the date the user registered with the electronic payment service (the date the account was created). Hereinafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

The charge balance is information indicating the balance of electronic money set by the user transferring money to the account in advance. Methods of remittance include remittance from an ATM (Automatic Teller Machine) of a designated business (bank), remittance from a registered bank account, etc. The deferred payment setting is information indicating whether the settings for enabling electronic payment by deferred payment have been completed, and is set to either "completed" or "not yet". Deferred payment refers to deducting the payment amount from the bank account associated with the affiliated card 57 at a predetermined time, such as the closing date, instead of immediately deducting the payment amount from the charge balance. The deferred payment setting is flag information common to "terminal payment" and "card payment" which will be described later. A user who can use deferred payment for terminal payment is a user who has been given an affiliate card 57. Note that instead of this, 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 that indicates whether the user performs electronic payment using the charge balance or deferred payment in "terminal payment." The card payment method is setting information that indicates whether the user performs electronic payment using the charge balance or 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 (for example, PAN (Primary Account Number)). The bank account and credit card number are each information about a bank account or credit card number (account number, card number) that can be used to deposit money into the electronic payment service. This credit card number is a number of a credit card different from the affiliated card 57. The charging history information is a history of the user increasing the charging balance by remitting money to the electronic payment service in advance. The payment history information is information that shows the details of the payments made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.) for each payment.

Auto charge setting is a so-called automatic charge setting that automatically deposits money from the user's fund source to the user's electronic payment account without any user operation when the electronic money charge balance meets predetermined conditions. This setting enables the auto charge function. If the user has set up auto-charge in advance and the electronic money charge balance satisfies a predetermined condition, automatic deposit processing using the auto-charge function is executed. In this embodiment, the auto charge setting is the same 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 and charge balance payment.

FIG. 6 is a diagram showing an example of the contents of the affiliated store/store information 176. The affiliated store/store information 176 includes, for example, a first table 176A in which affiliated store IDs and store IDs are associated with store URLs, and affiliated store names and sales proceeds (described above) are associated with affiliated store IDs. 176B, and a third table 176C in which store names are associated with store IDs. In addition to this information, the member store/store information 176 may include information such as the member store or store category, store location, payment pattern, and the like.

The information management unit 140 manages user information 172 and member 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, edits, deletes, etc. new records for the user information 172 and member store/store information 176.

Here, terminal payment and card payment will be explained. FIG. 7 is a diagram conceptually showing each process of terminal payment and card payment. As explained below, electronic payment services include (1) terminal payment/payment by charge balance, (2) terminal payment/payment by deferred payment, (3) card payment/payment by charge balance, (4) card payment/payment by charge balance. Four types of electronic payments can be made: deferred payment.

[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 started. The payment server 100 refers to the user information 172 and obtains the "terminal payment method" of the user. The payment server 100 performs electronic payment through its own processing for users 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 member store's sales proceeds. For example, the item value of the sales proceeds of a member store is not used as electronic money itself, but the amount corresponding to the item value of the sales proceeds is determined in a cycle according to the agreement between the member store and the electronic payment service. Money will be transferred to your bank account.

(2) In terminal payment, the payment server 100 provides payment information regarding the user whose "terminal payment method" is set to "deferred payment" together with the affiliated card number of the user obtained by referring to the user information 172. is transferred to the affiliated credit card company server 200. The affiliated credit card company server 200 checks whether the cumulative payment amount indicated by the payment information does not exceed the upper limit for the current month, and if it does not exceed the upper limit, the acquired payment amount is used as the cumulative payment amount for the user. Perform processing such as adding to . For example, the cumulative amount of payment for one month is paid by debiting a bank account on the next month's payment date.

[credit card payment]
(3) When the affiliated credit card company server 200 acquires payment information from the credit processing terminal 55, electronic payment (card payment) using the affiliated card 57 is started. Affiliated credit card company server 200 refers to 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 (for example, PAN), a card payment method, and an account ID of the user are associated with each other. The card payment method and account ID are the same information included in the user information 172 in FIG. 5, and are synchronously linked with the payment server 100. The affiliated credit card company server 200 sends payment information for a user whose "card payment method" is set to "charge balance" together with the user's account ID obtained by referring to the card payment setting information 210. Transfer to server 100. Based on the acquired payment information, the payment server 100 performs the same process as when the "terminal payment method" is set to "charge balance" in terminal payment.

(4) In card payment, the affiliated credit card company server 200 performs electronic payment through 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 the same process as when the "terminal payment method" is set to "deferred payment" in terminal payment.

Switching between "charge balance" and "deferred payment" in each of "terminal payment" and "card payment" is performed according to the user's operation on the payment application 20. The payment application 20 has an interface screen for selecting a payment method between "charge balance" and "deferred payment" (or other payment method) in "terminal payment" and a "charge balance" and "charge balance" in "card payment". An interface screen for selecting one of the payment methods for "deferred payment" (or other payment methods) is separately provided to the user.

In addition, in the following explanation, the method of making electronic payment using the charge balance is an example of the first method, and the method of making electronic payment using deferred payment is an example of the second method, but this relationship is reversed. Good too.

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

When the user operates the icon IC1, the screen changes to a payment method switching screen IM2 shown in the right diagram of FIG. The payment method switching screen IM2 includes, for example, the notation "credit payment" and a software switch SS1 that can be turned on or off. By turning the software switch SS1 on or off, the user sets the payment method for card payments to either electronic payment using the charge balance or electronic payment using deferred payment. be able to. When the state of the software switch SS1 is changed, the payment server 100 that cooperates with the payment application 20 notifies the affiliated credit card company server 200 of the changed state. For example, although the information management unit 140 mainly performs this processing, other functional units may perform the processing. When the software switch SS1 is turned on from the off 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 turned on. When the state changes from the state to the off state, the affiliated credit card company server 200 is instructed 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 description, 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, the user may be allowed to select one payment method from "charge balance", "debit card" (described later), and "deferred payment". In that case, one of "charge balance", "debit card", and "deferred payment" may be treated as a third method that does not fall under either the first method or the second method, or may be treated as a third method that does not fall under the first method or the second method. The method may include multiple methods.

In this way, the affiliated credit card company server 200 acts as an interface and allocates payment methods for card payments, making it possible to implement two payment methods using the existing credit card information transmission network. As a result, user convenience can be improved at low cost without constructing a new information transmission network.

[Auto charge setting user interface]
On the other hand, when the user operates the icon IC2, the screen changes to an auto-charge setting screen IM3 shown in FIG. 10. On the auto charge setting screen IM3, for example, a software switch SS2 that can be turned on or off is provided along with the notation "enable auto charge". By turning the software switch SS2 on or off, the user can set the automatic charging to be enabled or the autocharging to be disabled. When the software switch SS2 changes from the off state to the on state, the payment server 100 changes the value of the auto charge setting in the user information 172 to "completed", and changes the software switch SS2 from the on state to the off state. , the value of the auto charge setting in the user information 172 is changed to "none". In addition, the auto charge setting screen IM3 includes a first setting menu MN1 that accepts setting operations for the minimum deposit amount (minimum charge amount) when depositing with auto charge, and a second setting menu MN1 that accepts setting operations for the charging method. MN2 is provided. The charging method may be withdrawal from a designated bank account, or payment of the charging amount in arrears (including credit card).

As described above, the auto charge setting in this embodiment is common for charge balance payment in "terminal payment" and 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 payment methods of card payment and charge balance payment, and the software switch SS2 is changed to the OFF state. In this case, auto-charging will be disabled for both card payment and charge balance payment methods.

Further, as described above, the auto charge setting may be provided for each of the charge balance payment in "terminal payment" and the charge balance payment in "card payment". In this case, for example, on the auto-charge setting screen IM3, a software switch for terminal payment and a software switch for card payment may be provided. Further, for example, different auto charge setting screens may be provided for charge balance payment in "terminal payment" and charge balance payment in "card payment". Further, for example, an icon may be placed on the top screen for transitioning to different auto charge setting screens for charge balance payment in "terminal payment" and charge balance payment in "card payment". Note that when the auto charge setting screen is divided for terminal payment and card payment, the auto charge setting screen for 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 app 20 is configured as a super app that includes mini apps.

[User interface for setting payment method priority]
On the other hand, when the user operates the icon IC13, the screen changes 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 priority settings for payment methods, a first list area R1 for displaying a list of payment methods with high priority, and other payment methods. , and a settings 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 a priority change operation.

Note that the payment method with a high priority may be determined based on arbitrary criteria. Furthermore, the payment method with a high priority may be defined in advance by the payment 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 provider. For example, in the following, charge balance payment (first method) and deferred payment (second method) are defined as high priority payment methods, and credit card payment is defined as another payment method.

FIG. 11 shows a state in which the software switch SS3 is switched to the on side (on the right side in the example shown), and the priority order setting for the payment method is enabled. In this state, the payment application 20 makes it possible to perform a priority setting operation for the high-priority payment methods displayed in the first list area R1. FIG. 11 shows a case where charge balance payment M11 and deferred payment M12 are registered as high-priority payment methods, and two credit card payments M21 and M22 are registered as other payment methods. In this case, the payment application 20 accepts a priority order setting operation for charge balance payment M11 and deferred payment M12.

[Basic operations for changing priorities]
FIGS. 12 and 13 are diagrams showing specific examples of visual effects generated when the priority setting screen IM4 receives an operation to change the priority order regarding the payment method. Here, a case will be described in which the priority order (situation in FIG. 11), which is set in the order of charge balance payment M11 and deferred payment M12, is changed to deferred payment M12 and charge balance payment M11 in that order. First, when the payment application 20 receives a selection operation of the operation icon IC11 corresponding to the charge balance payment M11, the display of the selected charge balance payment M11 is moved to another priority order according to the user's drag operation. At the same time, a visual effect is generated in which the display of deferred payment M12 moves to another priority level in accordance with the movement of charge balance payment M11. Such a visual effect may be implemented, for example, as a so-called long press drag operation (a gesture of pressing and holding a point, then moving and releasing). Note that the touch operation can be replaced with the corresponding mouse operation as appropriate. The duration of the long press is arbitrary, but typically it is assumed to be about 0.5 to 1 second.

In the situation shown in FIG. 12, in response to the selected charge balance payment M11 (first priority) being moved toward the second priority, the second priority deferred payment M12 is moved to the first priority. This shows the situation where the person has been moved to the second position. In this situation, the visual effect of the ranking change is continuing, and the destination of the charge balance payment M11 is undetermined. By canceling the selection of the charge balance payment M11 in this state, the destination of the charge balance payment M11 is determined to be the second priority position (see FIG. 13). In the example of FIG. 13, as a result of this confirmation, the display of the priority order of charge balance payment M11 is changed to second place, and the display of the priority order of deferred payment M12 is changed to first place. Note that the confirmation here only refers to the confirmation of the display position, and does not confirm the details of the change in the priority order setting. The changes to the priority settings are finalized when the save settings button B1 is pressed. The payment application 20 notifies the payment server 100 of the settings at that time in response to the press of the settings save button B1. The payment server 100 stores the notified setting contents in the user information 172 as, for example, payment method settings.

In addition, the payment application 20 generates an additional visual effect at the timing when the long press is completed in order to help the user recognize that the payment method to be operated has been appropriately selected and can be moved. You can do it like this. For example, the payment application 20 may generate a visual effect such that the display area of the selected payment method appears raised. Further, for example, the payment application 20 may change the color, size, shape, etc. of the selected payment method, or add text, graphics, etc. to the selected payment method to indicate that it is in a movable state. It may also be displayed. This visual effect may be canceled when the movement operation is completed (ie, the finger is released).

[Behavior of the priority setting screen when auto charge setting is enabled]
12 and 13, the basic contents of the payment priority changing operation have been explained. In the payment application 20 of this embodiment, the priority of the first method (charge balance payment) is changed on the priority setting screen. The present invention further has a function of automatically displaying a second auto-charge setting screen that accepts an operation to change the auto-charge setting in response to a user's operation. FIG. 14 is a diagram showing a display example of the second auto charge setting screen. FIG. 14 shows that in response to the charge balance payment M11 being changed to the first priority on the priority setting screen IM4 similar to FIGS. 11 to 13, the second auto charge setting screen IM5 is changed to the so-called This shows a situation displayed in a half-sheet format.

A half-sheet is a type of user interface used to temporarily suspend a user's operation, prompt a certain action, or display notifications such as errors. Generally, as shown in FIG. 14, the half sheet is often displayed superimposed on a part of the screen that was being displayed (here, the priority setting screen IM4). Furthermore, as shown in FIG. 14, when a half sheet is displayed, the screen that was being displayed up to that point may be low-lit. The half sheet may be displayed modally or non-modally. In addition, as shown in Figure 14, the half sheet is displayed with a visual effect that appears to rise from outside the screen at the bottom of the screen, and a visual effect that appears to sink into the outside of the screen at the bottom of the screen. may be hidden by. Although the case where the second auto charge setting screen is configured as a half sheet is illustrated here, the auto charge setting screen may be displayed in other formats (for example, pop-up display or transition to another screen). .

The second auto charge setting screen IM5 in FIG. 14 is an example in which the same operation interface as 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 includes a software switch SS4 similar to the software switch SS2, a first setting menu MN3 similar to the first setting menu MN1, It has a second setting menu MN2 and a similar first setting menu MN4. By displaying such a second auto charge setting screen in response to changes in the priority of the first method, users will be able to check the auto charge settings at an appropriate time, and also make necessary changes. You can change settings without forgetting to change them.

In the example of FIG. 14, the second auto charge setting screen IM5 may be displayed after the changed priority setting is confirmed, or may be displayed before the priority setting change is confirmed and the payment method is displayed. The movement operation may be completed and each payment method may be displayed in the changed priority order. In addition, the second auto charge setting screen IM5 has a screen that is pulled up from the bottom of the screen ( It may also be displayed with an effect (such as rising). Further, the second auto-charge setting screen IM5 may be displayed by a predetermined operation after the payment method movement operation is completed. For example, the second auto charge setting screen IM5 is displayed in such a manner that in response to an operation of swiping the screen edge at the bottom of the screen upwards, the second auto charge setting screen IM5 rises up into the screen from the bottom edge of the screen. Good too.

[One-time code]
FIG. 15 is a sequence diagram illustrating an example of changing the priority order of payment methods in terminal payment and the flow of processing executed accordingly. First, the payment application 20 displays the priority setting screen IM4 in response to a predetermined operation by the user (S31). The priority setting screen IM4 may be displayed when the user executes a specific command from the operation menu of the payment application 20, or when the user executes a specific command from the operation menu of the payment application 20, or when the priority setting screen IM4 is displayed on a web page or application (including the payment application 20). It may also be displayed by an operation that accesses a deep link. Note that the payment application 20 displays the priority order setting screen IM4 when a plurality of payment methods with high priority are set. For example, if the high-priority payment methods are charge balance payment and deferred payment, the payment application 20 displays the priority setting screen IM4 when the usage settings for both are made. Generally, in electronic payment services, charge balance payment is a default payment method, and deferred payment is positioned as an optional payment method. In this case, the payment application 20 displays the priority setting screen IM4 when deferred payment is set to be available, and when there is no setting for deferred payment and only charge balance payment is available, the priority setting screen IM4 is displayed. may be configured so as not to be displayed. Further, 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 deferred payment is set.

Upon receiving the priority change operation (S32), the payment application 20 sends a notification that the priority of the payment method has been changed (change notification) and a one-time code issuance request to the payment server 100 (S33). ). Note that the operation for changing the priority order may include a first operation for enabling the priority setting for the payment method, in addition to a second operation for selecting a payment method and moving it to a different order position than the current one. . Note that the payment application 20 may be configured to accept the second operation when the priority setting for the payment method is enabled.

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 sends the one-time code to the payment application 20 (S34). 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).

Note that in the payment application 20, the transition to the top screen after the code image has been updated may not be performed automatically, but may be performed by a user's operation. Further, the code image may be updated when the code image needs to be displayed. In this case as well, the payment application 20 sends a one-time code issuance request to the payment server 100 as described above, the payment server 100 sends the one-time code to the payment application 20, and the payment application 20 uses the one-time code. and update the code image.

Here, in the updated code image, the current electronic payment payment method setting is a setting to select payment methods based on priority, and information indicating the priority of multiple payment methods is encoded. . The payment processing unit 130 checks both the payment method settings read from the code image and transmitted from the first store terminal device 50 and the payment method settings registered in the user information 172, and performs electronic payment. Alternatively, if information indicating the priority order of multiple payment methods is not encoded in the code image, the payment processing unit 130 exclusively checks the payment method settings registered in the user information 172 and Payment may be made.

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

<Modified example>
The second auto charge setting screen is configured to be displayed when the priority of the first method (charge balance payment) is changed from the previous order to a higher order on the priority order setting screen IM4. may be done.

In addition, the second auto charge setting screen is displayed when the priority of the first method (charging balance payment) is changed to a higher priority than the second method (deferred payment) on the priority setting screen IM4. It may be configured so that

Further, the second auto charge setting screen may be configured to be displayed when the priority of the first method (charging balance payment) is changed to first on the priority setting screen IM4. .

Further, the second auto charge setting screen is 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. Good too. For example, the 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.

In the above embodiment, a case has been described in which a payment method to be used for card payment is set using the payment method switching screen IM2, but the priority order of payment methods may be set for card payment as well as for terminal payment. In this case, as in the case of terminal payment, in card payment as well, if the payment fails with the priority setting enabled for multiple payment methods, the payment server 100 It may be configured to automatically switch payment methods and perform payment processing. Further, in this case, the priority setting of the payment method may be the same setting for card payment and terminal payment. In this case, the payment server 100 synchronizes the priority setting information with the affiliated credit card company server 200, so that common settings can be achieved.

On the other hand, the priority order of payment methods 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 payments similar to the priority setting screen IM4 for terminal payments. In this case, the priority order 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 priority settings for payment methods are provided separately for card payments and terminal payments, the priority setting screen for card payments also has the same settings as the priority setting screen IM4 for terminal payments. The second auto charge setting screen may be configured to be displayed in response to the change in the priority of the first method. Further, instead of the priority setting screen IM4 for terminal payment, a priority setting screen for card payment may be provided.

Further, if 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: The second auto charge setting screen will now be displayed when the priority of the first method is changed on the priority setting screen for card payments when the auto charge setting for card payments is set to OFF. may be configured. In this case, if the priority of the first method is changed on the priority setting screen IM4 for terminal payment, the payment application 20 will automatically charge the second method regardless of the state of the automatic charge setting for terminal payment. The configuration may be such that the settings screen is not displayed. That is, in this case, the payment application 20 displays the 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 regarding electronic payment using the affiliated card 57. It may be configured to display.

In the above embodiment, a case has been described in which the display of various setting screens is controlled by the payment application 20, but the display of 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 part or all of the display contents may be provided by the payment server 100 or the affiliated credit card company server 200.

Although the mode for implementing the present invention has been described above using embodiments, the present invention is not limited to these embodiments in any way, and various modifications and substitutions can be made without departing from the gist of the present invention. can be added.

10 User terminal device 20 Payment application 50 First store terminal device 55 Credit processing terminal 57 Affiliated card 60 Store code image 70 Second store terminal device 72 Interface for affiliated stores 100 Payment server 110 Communication department 120 Payment content providing section 130 Payment processing Section 140 Information management section 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 (8)

An application program that operates on a terminal device used by a user and cooperates with a payment management device to provide electronic payment services to the user,
to the terminal device,
As the payment method used for electronic payment, priority is given to a plurality of payment methods including a first payment method using a charge balance that is charged in advance and managed by the payment management device, and a second payment method using deferred payment. Display the first screen that accepts the ranking setting operation,
On the first screen, when the priority of the first payment method among the plurality of payment methods is changed, the balance is automatically charged to the charge balance without any operation by the user. Display the second screen, which is the setting screen for the auto charge function to be executed.
application program. The application program displays the second screen when the priority of the first payment method is changed to a higher priority than before the change.
The application program according to claim 1. The application program displays the second screen when the priority of the first payment method is changed to first priority.
The application program according to claim 1. The application program displays the second screen when the priority of the first payment method is changed while the auto charge function is disabled.
The application program according to claim 1. The electronic payment service is
a first payment method for performing electronic payment using the terminal device;
The card is read from a card that is provided to the user and is separate from the terminal device, and has card information recorded thereon that is information for the user to use the electronic payment service. a second payment method that performs electronic payment based on the information;
is provided to users,
The auto charge function settings are managed as common settings for the first payment method and the second payment method,
The application program according to claim 1. The electronic payment service is
a first payment method for performing electronic payment using the terminal device;
The card is read from a card that is provided to the user and is separate from the terminal device, and has card information recorded thereon that is information for the user to use the electronic payment service. a second payment method that performs electronic payment based on the information;
provide users with
The priority order of the payment methods is set separately for the first payment method and the second payment method,
The application program is
Displaying the second screen when the priority order of the payment method is changed regarding the second payment method;
not displaying the second screen when the priority order of the payment method is changed for the first payment method;
The application program according to claim 1. A payment management device that provides an electronic payment service to the user in cooperation with an application program running on a terminal device used by the user,
As the payment method used for electronic payment, priority is given to a plurality of payment methods including a first payment method using a charge balance that is charged in advance and managed by the payment management device, and a second payment method using deferred payment. causing the application program to display a first screen that accepts a ranking setting operation;
The electronic payment is performed based on the priority order of payment methods set on the first screen,
On the first screen, when the priority of the first payment method among the plurality of payment methods is changed, the balance is automatically charged to the charge balance without any operation by the user. causing the application program to display a second screen that is a setting screen for the auto charge function to be executed;
Payment management device. A method for controlling the terminal device by an application program that operates on the terminal device used by the user and cooperates with a payment management device to provide the user with an electronic payment service, the method comprising:
to the terminal device,
As the payment method used for electronic payment, priority is given to a plurality of payment methods including a first payment method using a charge balance that is charged in advance and managed by the payment management device, and a second payment method using deferred payment. Display the first screen that accepts the ranking setting operation,
On the first screen, when the priority of the first payment method among the plurality of payment methods is changed, the balance is automatically charged to the charge balance without any operation by the user. Display the second screen, which is the setting screen for the auto charge function to be executed.
A method of controlling a terminal device.

Images