JP7359987B1 - Payment server, payment control method, and program - Google Patents

Abstract

The present invention provides a payment server, a payment control method, and a program that realize safer electronic payments. [Solution] In a configuration in which a payment server provides an electronic payment service by communicating with one or more user terminal devices and one or more store terminal devices via a network, the payment server stores payment information such as If information based on a one-time code is included, the one-time code is used to proceed with the electronic payment, and the payment information includes information obtained from an offline code image generated by the application program without using the one-time code. In the case where a payment processing unit is used, the payment processing unit is provided to proceed with electronic payment using information obtained from the offline code image. If the payment processing unit includes information obtained from an offline code image generated by the application program without using a one-time code, the payment processing unit will and set a lower upper limit on the payment amount. [Selection diagram] Figure 4

Description

The present invention relates to a payment server, a payment control method, and a program.

BACKGROUND ART Electronic payment is becoming widespread, in which a payment application running on a terminal device such as a smartphone displays a code image, and a store-side device reads information from the code image (Patent Document 1). In this mode of electronic payment, a one-time code issued by a payment server in association with a user's account is used as the original information displayed in the code image. By using a one-time code, there is no need to include personal information in the code image, resulting in improved security.

Patent No. 7237224

In the above-mentioned electronic payment, when electronic payment is to be performed, a request for a one-time code is sent from the payment application to the payment server, and a one-time code is issued in response. Therefore, in the conventional technology, in a situation where communication between the terminal device and the payment server is difficult at the time of electronic payment, there are cases where the electronic payment becomes impossible because a valid one-time code cannot be obtained. With conventional techniques, there may be concerns about a decrease in security when performing electronic payment using an alternative method in such a case.

The present invention has been made in consideration of such circumstances, and one of the objects is to provide a payment server, a payment control method, and a program that can realize safer electronic payments.

One aspect of the present invention is a payment server that provides an electronic payment service to the user in cooperation with an application program running on a user's terminal device, and which communicates with a store terminal device installed in a store, The store terminal device receives payment information including at least part of the information read from the code image displayed by the terminal device and the payment amount from the store terminal device, and a providing unit that provides a time code to the application program; and a payment processing unit that performs electronic payment based on the payment information, and if the payment information includes information based on the one-time code, If electronic payment is proceeded using a time code and the payment information includes information obtained from an offline code image generated by the application program without using the one-time code, the information obtained from the offline code image is a payment processing unit that proceeds with an electronic payment using the received information, and the payment processing unit includes a payment processing unit that uses an offline code image generated by the application program without using the one-time code in the payment information. When the payment information includes information based on the one-time code, the payment server sets the upper limit of the payment amount lower than when the payment information includes information based on the one-time code.

According to one aspect of the present invention, it is possible to provide a payment server, a payment control method, and a program that can realize safer electronic payments.

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 (online payment). FIG. 2 is a sequence diagram (Part 2) illustrating the general flow of electronic payment (online 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. 3 is a diagram showing an example of a top screen IM1 of the payment application 20. FIG. FIG. 2 is a sequence diagram illustrating the flow of processing performed for offline payment. 3 is a flowchart illustrating an example of the flow of processing related to screen control by the payment application 20. FIG. It is a figure which shows an example of standby screen IM2. It is a figure showing an example of half sheet IM3. It is a figure which shows an example of detailed explanation screen IMe. It is a diagram showing an example of a first offline mode screen IM4 on which a first offline code image is displayed. It is a diagram showing an example of a second offline mode screen IM5 on which a second offline code image is displayed. It is a figure showing an example of payment method selection screen IM6.

EMBODIMENT OF THE INVENTION Hereinafter, embodiments of providing an application program, a payment control method, a payment server, a program, and a payment system of the present invention will be described with reference to the drawings. The application program and the payment server work together to provide electronic payment services. In the following description, the application program will be referred to as a payment application. 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. The payment server 100 communicates with each of the one or more user terminal devices 10, the one or more first store terminal devices 50, and the one or more second store terminal devices 70, for example, via the 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.

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

2 and 3 are sequence diagrams illustrating the general flow of electronic payment (online 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). 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 (payment content providing unit 120 described later) generates a one-time code (S12) and sends it to the payment application 20 (S13). The payment application 20 displays a code image (online 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). In addition, in parallel with this, information notifying completion of payment is also transmitted to the first store terminal device 50.

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.

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

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. Usage amount, available amount for deferred payment, payment method settings, bank account, credit card number, issued one-time code, user identification token for offline payment described below, secret key (for charge balance), and secret key (for deferred payment). ), offline payment maximum amount, charge history information, payment history information, and other information 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". The payment method setting is setting information that indicates whether the user will perform electronic payment using the charge balance or payment by deferred payment at that time. The bank account and credit card number are 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. 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.

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 IDs 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.

[Electronic payment]
When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 refers to the user information 172 and acquires the "payment method setting" of the user. The payment processing unit 130 performs electronic payment as follows for a user whose "payment method setting" is set to "charge balance". The payment processing unit 130 performs electronic payment by, for example, 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.

The payment processing unit 130 performs electronic payment in the following manner for users whose "setting information" is set to "deferred payment." Deferred payment is set up separately from "credit payment" in collaboration with a credit card company, which is a separate entity from the operator of the electronic payment service, and the operator of the electronic payment service is the creditor. , which allows electronic payments that do not depend on the charge balance within the deferred payment limit. Note that in order to receive the deferred payment service, the user may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used for deferred payment is paid in one month's worth on the next month's payment date, for example, by debiting from a bank account. In this case, the payment processing unit 130 performs provisional payment by adding the payment amount to the deferred payment usage amount and subtracting the same amount from the available deferred payment amount, and on the closing date, the payment for the current month is transferred to the next month's payment date as described above. or request the operator of the credit card company to perform the processing. Note that if the payment amount exceeds the available deferred payment amount at the time of provisional payment, an error notification is sent back to the payment application 20.

[Switching between charge balance and deferred payment (when paying online)]
FIG. 7 is a diagram showing an example of the top screen IM1 of the payment application 20. Note that the illustrated state is assumed to be the first state (state where online payment is possible) in which communication between the payment application 20 and the payment server 100 is not difficult. In the first state, a valid one-time code is provided from the payment server 100 to the payment application 20. "Valid" means that it is in response to the most recently sent one-time code issuance request. A code image CD is displayed on the top screen IM1. The code image CD includes, for example, a barcode and a QR code. Further, along with the code image CD, a text ("Pay with balance" in the figure) indicating whether to perform electronic payment using the charge balance or electronic payment by deferred payment is displayed. This text is drawn by the payment application 20 based on information updated by the payment application 20 each time the changeover switch (toggle switch) SW is operated. Further, the top screen IM1 includes an operation area CA including a changeover switch SW, and a transition button TB1. Note that the "switch" and "button" are GUIs (Graphical User Interfaces) realized in cooperation with the touch panel. The changeover switch SW accepts an operation for switching between performing electronic payment using the charge balance or electronic payment using deferred payment. By default, the changeover switch SW is set to perform electronic payment using the charge balance, and each time the switch is operated by the user, it changes between the setting for electronic payment using the charge balance and the setting for electronic payment using deferred payment. The settings will change. In the diagram, the explanation "Balance payment" is displayed, which means that the setting is to perform electronic payment using the charge balance. The operation area CA is provided with buttons for instructing main operations in electronic payment, such as a button for instructing scan (start of user scan) and a button for instructing charging. When the transition button TB1 is operated, the screen transitions to a payment screen that displays a code image used for electronic payment and the available amount.

[Offline payment]
Hereinafter, electronic payment (offline payment) in the second state in which a valid one-time code is not acquired due to difficulty in communication between the payment application 20 and the payment server 100 will be described. The offline payment according to this embodiment can be carried out at the stores of the above-mentioned store scan.

The payment application 20 determines whether to perform online payment or offline payment depending on whether communication with the payment server 100 is in a first state where communication is normal or in a second state where communication is difficult. For example, the payment application 20 determines that the second state is present when an event in which a response to a one-time code issue request is not received within a predetermined time occurs n or more times (n is an integer of 1 or more). When the payment application 20 determines that the communication with the payment server 100 is in the second state, it generates an offline code using the time measured by the user terminal device 10 and the secret key, and uses the secret key to generate an offline code based on the offline code. An offline code image is generated, and the offline code image is displayed on the display unit of the user terminal device 10. In other words, the payment application 20 generates an offline code image based on an offline code that it generated itself without using a one-time code.

The secret key is acquired from the payment server 100 to the payment application 20 less frequently than the one-time code. For example, the running payment application 20 acquires the secret key approximately once a week. In this acquisition process, a secret key issue request may be sent from the payment application 20 to the payment server 100, or the payment server 100 may voluntarily provide the secret key to the payment application 20.

The payment application 20 may generate an offline code using a user identification token in addition to the time and secret key. The user identification token may be fixedly assigned to the user, or may be sent from the payment server 100 in conjunction with the secret key issuance request. Note that an example of an offline key is one that includes one or both of a secret key and a user identification token.

For example, the payment application 20 generates an offline code based on data obtained by inputting a secret key and time into a predetermined function and data obtained by combining a user identification token. This method is just an example, and the payment application 20 may generate the offline code using any decryptable method based on some or all of the secret key, time, and user identification token.

The payment application 20 also causes the user terminal device 10 to synchronize the time measured by the user terminal device 10 and the time measured by the payment server 100 at a predetermined timing (for example, every time a secret key issuance request is made). You can let it. At this time, the payment application 20 may perform a process of adjusting the time of a radio-controlled clock or the like at substantially the same time as the payment server 100.

When the offline code image is read by the first store terminal device 50 and payment information including at least a part of the read information and the payment amount is acquired (the offline code image generated by the payment application 20 using the time If the offline authentication condition is satisfied, the payment processing unit 130 of the payment server 100 proceeds with the electronic payment based on the payment information. In other words, proceed with offline payments. "At least a part of the read information" means "at least a part of the offline code", and hereinafter simply referred to as the offline code. The offline authentication condition is related to the offline code image generated by the payment application 20 based on the offline code. For example, the offline authentication condition includes that the time read from the offline code image (hereinafter referred to as application time) is within a predetermined range compared to the time measured by payment server 100 (hereinafter referred to as server time). The offline authentication condition may include that the offline key (one or both of the secret key and the user identification token) is held in the storage unit 170 as having been provided to the payment application 20. The time handled in offline payment is, for example, measured in minutes, but is not limited to this. Upon acquiring the payment information, the payment processing unit 130 identifies the secret key from the user identification token included in the offline code included in the payment information, and combines the identified secret key with the current time measured by the payment server 100. The offline code is generated using the same method as the payment application 20, and if the offline code acquired from the first store terminal device 50 and the code generated by the store itself match, it is determined that the offline code is valid. For example, in preparation for a case where the time deviates between the user terminal device 10 and the payment server 100, the payment processing unit 130 may perform a plurality of If any of the codes matches the offline code obtained from the store terminal, it is determined that the offline authentication conditions are satisfied, that is, the payment information is valid.

The payment processing unit 130 performs processing when performing offline payment (when payment information includes information obtained from an offline code image) and when performing online payment (when payment information includes information based on a one-time code). In comparison, the upper limit of the payment amount for one electronic payment may be set lower. The payment processing unit 130 may set the upper limit of the payment amount when performing offline payment as a fixed amount lower than that for online payment (in the example of FIG. 5, it is set to 5000 yen), or may set the upper limit of the payment amount when performing offline payment as a fixed amount (in the example of FIG. 5, it is set to 5000 yen), It may also be determined dynamically based on, etc. In the latter case, the payment processing unit 130 determines the upper limit amount based on the frequency of electronic payments made by the user in the past, the amount of payment per transaction, the tendency of the category of the payment object, and the like. When performing offline payment, if payment information for a payment amount exceeding the upper limit is obtained from the payment application 20, the payment processing unit 130 transmits an error message to the first store terminal device 50, and also sends an error message to the first store terminal device 50. After the communication is restored, an error message is also sent to the user terminal device 10.

FIG. 8 is a sequence diagram illustrating the flow of processing performed for offline payment. First, the payment application 20 transmits an offline key issuance request to the payment server 100 at a timing unrelated to electronic payment (S21). The payment server 100 generates an offline key (S22) and sends it to the payment application 20 (S23). The payment application 20 stores the received offline key in the memory of the user terminal device 10.

At another time, if the user starts the payment application 20 or performs a payment operation in the payment application 20 at a store where the store scan is performed, the payment application 20 requests the payment server 100 to issue a one-time code. Send (S31). If an event in which a response to the one-time code issuance request is not received within a predetermined time occurs n or more times, the payment application 20 generates an offline code and displays an offline code image generated based on the offline code (S32). . 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 acquires an offline key etc. S33).

Then, the first store terminal device 50 generates payment information including an offline key, payment amount, member store ID, store ID, etc., and transmits it to the payment server 100 (S33). The payment server 100 identifies the user corresponding to the user identification token based on the received information, determines whether the offline authentication condition is satisfied as described above (S34), and determines whether the offline authentication condition is satisfied. If so, proceed with electronic payment (S35). In this case, information notifying completion of payment is exclusively transmitted also to the first store terminal device 50.

According to such processing, electronic payments can be made even when communication between the payment application 20 and the payment server 100 is difficult, such as when the store where the store scan is performed is located in a place with weak radio waves, so electronic payments can be made more flexibly. Payment can be made feasible. Further, even in offline payment, by proceeding with electronic payment without including user identification information such as an account ID in the offline code, it is possible to prevent the degree of protection of the user's personal information from decreasing.

Furthermore, by generating an offline code image using both the time and the offline key and performing offline payment, it is possible to increase the probability that the payment is legitimate. If an offline code image is generated using only an offline key and an offline payment is made, it becomes impossible to know when the offline code image was generated, which reduces the legitimacy of the payment. Furthermore, if an offline code image is generated using only the time and an offline payment is made, anyone can generate an offline code image if the offline code image generation logic is exposed. By generating an offline code image using both of these, it is possible to know the generation timing of the offline code image, and since the offline key is included in the offline code image, the offline code image can be generated based on the information issued by the payment server 100. It is guaranteed that there will be. As a result, the probability that the payment is legitimate can be increased.

Additionally, by setting the upper limit for offline payments lower than for online payments, safer electronic payments can be achieved.

Screen control by the payment application 20 will be described below. FIG. 9 is a flowchart illustrating an example of the flow of processing related to screen control by the payment application 20. The processing of this flowchart is started in various situations where communication with the payment server 100 occurs.

First, the payment application 20 determines whether or not a notification is not received from the payment server 100 (S100). The notification is, for example, a one-time password sent in response to the above-mentioned one-time password issuance request. If a notification has been received from the payment server 100, the payment application 20 displays an online mode screen (for example, the one shown in FIG. 7) and continues normal operation (S102).

If the notification is not received from the payment server 100, the payment application 20 causes the user terminal device 10 to display a standby screen IM2 indicating that it is difficult to read information from the payment server 100 (S104). FIG. 10 is a diagram showing an example of the standby screen IM2. A valid code image is not displayed on the standby screen IM2, but text TX1 indicating the connection status with the payment server 100 to the user is displayed.

Next, the payment application 20 determines whether the second state is confirmed (S106). As described above, the condition for determining the second state is "when an event in which a notification such as a response to a one-time code issue request does not arrive within a predetermined time occurs n or more times." If the second state has not been determined, the process returns to S100.

When the second state is determined, the payment application 20 determines whether a valid offline key (secret key and user identification token) has been acquired and stored in the memory of the user terminal device 10 (S108). A valid offline key is, for example, an offline key for which the elapsed time from the acquisition time does not exceed the upper limit time (a time comparable to the issuing cycle of the offline key).

If a valid offline key has not been acquired, the payment application 20 displays an error screen on the user terminal device 10 (S110). The error screen includes text etc. explaining that it is difficult to connect to the Internet.

If a valid offline key has been acquired, the payment application 20 determines whether the counter value k is greater than or equal to the threshold Th (S112). The counter value k is, for example, a value that is set to zero when the payment application 20 is installed on the user terminal device 10, and is incremented by one each time the consent operation determined in S116 is performed. In other words, the determination process in S112 is to determine whether the consent operation has been performed a predetermined number of times (=threshold Th) or more. The threshold Th is, for example, a value of about 1 to 3.

If the counter value k is less than the threshold Th, the payment application 20 causes the user terminal device 10 to display the half sheet illustrated in FIG. 11 (S114). FIG. 11 is a diagram showing an example of the half sheet IM3. The half sheet IM3 is displayed in a smaller size than the screen on which the online code image is displayed, such as the top screen IM1. The half-sheet IM3 is an example of an "interface screen." A text TX2 explaining offline payment is displayed on the half sheet IM3. In addition, the half-sheet IM3 includes a first operating section B1 for instructing a transition to a detailed explanation screen regarding payment in offline mode, and a second operating section B2 for instructing to accept payment in offline mode. is provided. FIG. 12 is a diagram showing an example of the detailed explanation screen IMe. A text TXe explaining offline payment is displayed on the detailed explanation screen IMe. Further, the detailed explanation screen IMe is provided with a first operating section Be1 for instructing to transition to a help page regarding payment in offline mode, and a second operating section Be2 for instructing to return to half sheet IM3. ing. The help page is updated by the payment server 100 from time to time, and the payment application 20 downloads the help page at any timing when communication between the user terminal device 10 and the payment server 100 is normally performed, It is stored in the memory of the user terminal device 10 (cached). As a result, even in situations where communication with the payment server 100 is difficult, it is possible to provide the user with a help page containing detailed information regarding payment in offline mode. Note that, similarly to the half sheet IM3, the help page may also be displayed in a smaller size than the screen on which the online code image is displayed, such as the top screen IM1.

The payment application 20 determines whether or not an operation has been performed on the second operation unit B2 in the half sheet IM3, that is, an operation to approve the payment in offline mode (S116).

If an operation is performed to approve payment in offline mode, payment application 20 displays an offline mode screen on user terminal device 10 (S118). Also, if it is determined in S112 that the counter value k is equal to or greater than the threshold Th, the payment application 20 causes the user terminal device 10 to display an offline mode screen (S118). The offline mode screen is a screen on which an offline code image is displayed. In this way, the conditions for transitioning to the offline mode screen include, for example, that a valid offline key has been acquired from the payment server 100, and basically include that the consent operation has been performed. If this has been done a predetermined number of times or more, it is excluded that the consent operation has been performed.

By performing such processing, users can be smoothly guided to offline payment using an offline code image.

The offline mode screen will be explained below. The offline mode screen displays a first offline code image that allows offline payment using the first payment method, and a second offline code image that allows offline payment using the second payment method. There is also a second offline mode screen, and these may be mutually switchable by a user's operation. That is, in offline mode payment provided by the electronic payment system, the first payment method and the second payment method may be selectively implemented. For example, similar to online payment, the first payment method is a method of electronic payment based on the charge balance, and the second payment method is a method of electronic payment using deferred payment. Each of the first payment method and the second payment method may be a method different from these methods, such as a payment method using a debit card function, point payment, or credit card payment.

In this case, the payment application 20 acquires the first offline key for generating the first offline code image and the second offline key for generating the second offline code image less frequently than the one-time code. I'll keep it. Each of the first offline key and the second offline key includes the same information as the offline key described above, and is further provided with identification information indicating whether it is the first offline key or the second offline key. be. The payment application 20 generates a first offline code using the first offline key, generates a first offline code image based on the first offline code, and causes the user terminal device 10 to display the generated first offline code image. The payment application 20 also generates a second offline code using the second offline key, generates a second offline code image based on it, and displays it on the user terminal device 10. The user identification tokens included in the first offline key and the second offline key may be common or different (in FIG. 5, they are common).

FIG. 13 is a diagram showing an example of the first offline mode screen IM4 on which the first offline code image is displayed, and FIG. 14 is a diagram showing an example of the second offline mode screen IM5 on which the second offline code image is displayed. It is a diagram. The first code image CD#1 is displayed on the first offline mode screen IM4. The first offline mode screen IM4 is set with a third operation section B3 for displaying the current payment method and for instructing transition to the payment method selection screen IM6. Furthermore, a reload button B5 is provided on the first offline mode screen IM4. When the reload button B5 is operated, a communication request is sent to the payment server 100, and the process of the flowchart in FIG. 9 is started. On the other hand, the second code image CD#2 is displayed on the second offline mode screen IM5. The second offline mode screen IM5 is set with a fourth operation section B4 for displaying the current payment method and for instructing transition to the payment method selection screen IM6. Further, a reload button B5 is also provided on the second offline mode screen IM5.

FIG. 15 is a diagram showing an example of the payment method selection screen IM6. The payment method selection screen IM6 is set with a sixth operation section B6 to an eighth operation section B8 in which selectable payment methods (payment methods) are described. When the sixth operation section B6 is operated, the screen changes to the first offline mode screen IM4, and when the seventh operation section B7 is operated, the screen changes to the second offline mode screen IM5. The process to be performed when the eighth operation unit is selected may be arbitrarily determined.

The payment application 20 may take over the payment method setting for online payment as the initial setting for offline payment. For example, the payment application 20 determines whether the first offline mode screen IM4 or the second offline mode screen IM5 will be the first screen displayed when it is decided to perform offline payment, in the settings at the time of online payment. You may decide accordingly. In this case, the payment application 20 stores the payment method settings for online payment in the memory of the user terminal device 10.

If the payment information acquired in the offline payment includes the information obtained from the first offline code screen, that is, the first offline key, the payment server 100 allows the electronic payment to proceed with the first payment method, and sends the second offline code. If the information obtained from the screen, that is, the second offline key is included, electronic payment is performed using the second payment method.

By performing such processing, it is possible to widen the range of choices for users and improve convenience in offline payments using offline code images.

Note that what has been described above as offline processing may also be executed in the first state. In other words, the process described as the offline process may be executed at all times regardless of the communication state between the user terminal device 10 and the payment server 100.

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 100 Payment server 120 Payment content providing unit 130 Payment processing unit 140 Information management unit

Claims (5)

A payment server that provides an electronic payment service to the user in cooperation with an application program running on the user's terminal device,
Communicates with a store terminal device installed in a store, and the store terminal device receives from the store terminal device payment information including at least part of the information read from a code image displayed by the terminal device and a payment amount. Communication Department and
a providing unit that provides the one-time code to the application program via the communication unit and stores the one-time code in a storage unit together with information that can identify the user ;
A payment processing unit that performs electronic payment based on the payment information,
If the payment information includes information based on the one-time code obtained by referring to the storage unit , identify the user using the one-time code and proceed with electronic payment;
If the payment information includes a user identification token given to the user in advance and stored in the storage unit , and does not include information based on the one-time code obtained by referring to the storage unit, , a payment processing unit that identifies the user using the user identification token and proceeds with electronic payment;
Equipped with
When the payment information includes the user identification token and does not include information based on the one-time code obtained by referring to the storage unit, the payment processing unit includes the storage unit in the payment information . setting a lower upper limit for the payment amount in one electronic payment than when information based on the one-time code obtained by referring to the section is included ;
Payment server. The payment processing unit is configured to process a single electronic payment when the payment information includes the user identification token and does not include information based on the one-time code obtained by referring to the storage unit. The upper limit of the amount is set to a fixed amount lower than the upper limit of the payment amount in one electronic payment when the payment information includes information based on the one-time code obtained by referring to the storage unit .
The payment server according to claim 1. The payment processing unit is configured to process a single electronic payment when the payment information includes the user identification token and does not include information based on the one-time code obtained by referring to the storage unit. determining the upper limit of the amount based on the user's payment history;
The payment server according to claim 1. A payment server that provides electronic payment services to the user in cooperation with an application program running on the user's terminal device,
Communicating with a store terminal device installed in a store, the store terminal device receiving from the store terminal device payment information including at least a part of information read from a code image displayed by the terminal device and a payment amount. ,
providing the one-time code to the application program through communication , and storing the one-time code together with information that can identify the user in a storage unit ;
When making an electronic payment based on the payment information,
If the payment information includes information based on the one-time code obtained by referring to the storage unit , identify the user using the one-time code and proceed with electronic payment;
If the payment information includes a user identification token given to the user in advance and stored in the storage unit , and does not include information based on the one-time code obtained by referring to the storage unit, , identify the user using the user identification token and proceed with electronic payment;
When the payment information includes the user identification token and does not include information based on the one-time code obtained by referring to the storage unit, the payment information includes the one-time code obtained by referring to the storage unit . setting the upper limit of the payment amount in one electronic payment lower than when information based on the one-time code is included ;
Payment control method. a payment server that provides electronic payment services to the user in cooperation with an application program running on the user's terminal device;
Communicating with a store terminal device installed in a store, the store terminal device receiving from the store terminal device payment information including at least a part of information read from a code image displayed by the terminal device and a payment amount. ,
providing the one-time code to the application program through communication , and storing the one-time code together with information that can identify the user in a storage unit ;
When making an electronic payment based on the payment information,
If the payment information includes information based on the one-time code obtained by referring to the storage unit , identify the user using the one-time code and proceed with electronic payment;
If the payment information includes a user identification token given to the user in advance and stored in the storage unit , and does not include information based on the one-time code obtained by referring to the storage unit, , identify the user using the user identification token and proceed with electronic payment;
When the payment information includes the user identification token and does not include information based on the one-time code obtained by referring to the storage unit, the payment information includes the one-time code obtained by referring to the storage unit . setting the upper limit of the payment amount in one electronic payment lower than when information based on the one-time code is included ;
A program to perform processing.

Images