Payment management device, payment management method, and program

Abstract

To reduce the effort required to remove a usage restriction in a fraud detection system that imposes a certain usage restriction on a user for whom fraudulent use of electronic payment is detected. [Solution] A payment management device that provides electronic payment services in cooperation with a payment app, comprising: a payment processing unit that executes payment processing in response to a payment request received from the payment app; a fraudulent use detection unit that, when the payment request is received from the payment app, determines whether the payment request is for the purpose of fraudulent use; a function restriction unit that restricts the functions of the user's payment app in response to a suspected request, which is a payment request determined by the fraudulent use detection unit to be for the purpose of fraudulent use; and a restriction removal unit that obtains the user's declared information regarding the suspected request from the payment app, performs identity verification on the user, and lifts the function restrictions based on the declared information and the results of the identity verification.

Description

[Technical Field]

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

[0002] Conventionally, there is known a technology for detecting fraudulent use of a credit card by using authorization data (authorization data; data transmitted from a store or the like, such as the credit card owner and the amount requested for payment) when a credit card is used. For example, Patent Document 1 discloses a technology for determining whether a payment request by credit card is the result of fraudulent use by using history information added to the authorization data (see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2004-348536 Summary of the Invention [Problem to be solved by the invention]

[0004] On the other hand, even if a user is legitimate, there are cases where the credit card usage is restricted because the credit card payment circumstances happen to match the fraudulent conditions. In this case, the legitimate user can have the usage restriction lifted by contacting the credit card company to verify their identity and explaining that the credit card payment in question was made by them.

[0005] However, it can take a long time (for example, several days) for the credit card usage restrictions to be lifted. Also, it is known that on e-commerce sites, if a credit card payment is determined to be fraudulent, the user is likely to leave the site without completing the purchase (abandoned shopping cart).

[0006] As such, when using conventional technology to determine whether credit card payments are fraudulent, it can be time-consuming to remove usage restrictions, which can result in lost opportunities for both the user and the product seller.

[0007] The present invention has been made taking these circumstances into consideration, and one of its objectives is to provide a payment management device, payment management method, and program that can reduce the effort involved in lifting usage restrictions in a fraud detection system that imposes certain usage restrictions on users who have been detected to be committing fraudulent use of electronic payments. [Means for solving the problem]

[0008] One aspect of the present invention is a payment management device that provides electronic payment services to a user in cooperation with a payment app running on the user's terminal device, and includes: a payment processing unit that executes payment processing in response to a payment request received from the payment app; a fraudulent use detection unit that, when the payment request is received from the payment app, determines whether the payment request is for the purpose of fraudulent use; a function restriction unit that restricts functions of the user's payment app in response to a suspected request, which is a payment request determined by the fraudulent use detection unit to be for the purpose of fraudulent use; and a restriction release unit that obtains the user's declared information regarding the suspected request from the payment app, performs identity verification on the user, and releases the function restrictions based on the declared information and the results of the identity verification. [Effects of the Invention]

[0009] According to one aspect of the present invention, in a fraud detection system that imposes certain usage restrictions on users who have been detected as committing fraudulent electronic payments, the effort required to lift those usage restrictions can be reduced. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] 1 is a sequence chart (part 1) showing an example of the flow of processing that the settlement server 100 executes in cooperation with the credit card company server 200 at the time of credit card payment. [Figure 8] 10 is a sequence chart (part 2) showing an example of the flow of processing that the settlement server 100 executes in cooperation with the credit card company server 200 at the time of credit card payment. [Figure 9] 10 is a flowchart showing an example of the flow of processing that the payment server 100 performs regarding function restriction following fraudulent use detection. [Figure 10] FIG. 10 is a diagram showing an example of the flow of releasing function restrictions using payment application 20. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, with reference to the drawings, embodiments of a payment management device, a payment management method, and a program of the present invention will be described. Various devices, such as a "server," a "management device," and an "information providing device," that provide services to users and perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a "payment app." An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real-world store) that exists in the real world, but may also include a virtual store for e-commerce transactions. Virtual stores may also include stores operated by entities other than the operator of the electronic payment service. In such cases, a transition to an interface screen for the electronic payment service may be performed when making a payment for a purchase at the virtual store. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at the store is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

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

[0013] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or 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 acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

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

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

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

[0017] The credit card company server 200 is a server operated by the issuer (credit card company) of the credit card owned by the user of the payment app 20, and is a server that performs processing (credit card payment processing) to realize electronic payment (credit card payment) using the credit card. More specifically, the credit card company server 200 performs credit card payment processing based on the contents of an authorization message received when an electronic payment using a credit card is made. The authorization message is a message sent to the credit card company server 200 when a credit card is used to confirm the validity of the card (authorization), and includes information necessary for payment (payment information) such as the store to which the payment is made, the payment amount, and the user's identification information. In the case of payment using a physical credit card, a dedicated terminal installed in a store or the like reads the card information and generates an authorization message, and sends the generated authorization message to the credit card company server 200. On the other hand, in the case of credit card payment via the payment app 20, the payment server 100 receives a payment request from the payment app 20 and generates an authorization message and sends it to the credit card company server 200.

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

[0019] 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 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends 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 below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

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

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

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

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

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

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

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

[0027] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as associated information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, charge history information, payment history information, and usage limit information. The user URL is used for remittance processing between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0028] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the breakdown of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0029] The usage restriction information is setting information for restricting the use of the payment application 20 for a user for whom fraudulent use of the payment application 20 has been detected. The usage restriction information includes, for example, information such as whether or not there is a usage restriction (restriction or no restriction), the range of functions for which use is restricted (restriction range), and the period for which the usage restriction is implemented (restriction period). The usage restriction information is updated to content appropriate to the situation at necessary times, such as when fraudulent use is detected or when the conditions for removing the usage restriction are met.

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

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

[0032] [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 references the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0033] The payment processing unit 130 performs electronic payments for users whose "setting information" is set to "credit card payment" as follows. Credit card payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, allowing electronic payments within the credit card payment limit and independent of the remaining balance. To receive the credit card payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The monthly amount used for credit card payment is settled on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit card payment amount and subtracting the same amount from the available credit card balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card company operator to perform this process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, an error notification is returned to the payment app 20.

[0034] [Detecting fraudulent use of payment apps] As described above, the electronic payment service of this embodiment allows payment methods using payment app 20, such as balance payment using a charge balance and credit card payment. While such electronic payment services are highly convenient for users because they can be easily used from payment app 20, they may be subject to fraudulent use through phishing, skimming, and other methods. Therefore, the electronic payment service of this embodiment has a function (fraudulent use detection function) that monitors use of payment app 20 and detects fraudulent use of the electronic payment service. The fraudulent use detection function is realized by information processing unit 150.

[0035] Information processing unit 150 is a functional unit that detects fraudulent use of payment application 20 and executes various processes related to a user for whom fraudulent use has been detected. More specifically, information processing unit 150 includes, for example, fraud detection unit 151, function restriction unit 152, and restriction removal unit 153.

[0036] When a payment request is made by the payment application 20, the fraud detection unit 151 determines whether the payment request is intended for fraudulent use by comparing the circumstances under which the payment request was made with the fraud detection rules 178 stored in advance in the memory unit 170.

[0037] The function restriction unit 152 performs processing to restrict the use of the payment app 20 for a user of the payment app 20 for which fraudulent use has been detected by the fraud detection unit 151. The function restriction unit 152 may be configured to change the scope of functions to be restricted and the restriction period, etc., depending on the circumstances under which fraudulent use of the payment app 20 is detected. For example, the function restriction unit 152 may restrict functions such as remittance using the charge balance in addition to the function of payment using the charge balance (charge balance payment). Furthermore, for example, the function restriction unit 152 may restrict functions such as recharge and remittance using a credit card in addition to the function of payment using a credit card (credit payment). Note that in this embodiment, the payment, recharge, remittance, and other functions provided by the payment app 20 are examples of "payment functions" that can be used by users in electronic payment services.

[0038] When it is confirmed that a payment request determined to be fraudulent use is made by the user himself / herself, restriction lifting unit 153 performs processing to lift the function restriction on the user whose use of payment app 20 has been restricted due to the detection of fraudulent use. More specifically, restriction lifting unit 153 lifts the function restriction on the user when the user declares that the payment request to be confirmed is not fraudulent use and when the identity of the user is successfully verified.

[0039] Figures 7 and 8 are sequence charts showing an example of the flow of processing that the payment server 100 of this embodiment performs in cooperation with the credit card company server 200 when it receives a payment request for credit card payment. Figure 7 shows the flow for user scanning, and Figure 8 shows the flow for store scanning. In both cases, the only difference is that electronic payment is performed in cooperation with the credit card company server 200, but other parts are the same as in Figures 2 and 3.

[0040] [If no fraud detection occurs] 7, when the payment application 20 transmits the second payment information to the payment server 100 (S6), the payment server 100 executes the electronic payment based on the second payment information (S7). Here, if the payment method setting is set to "credit card payment," the payment server 100 executes the credit card payment process in cooperation with the credit card company server 200 (S71 to S75).

[0041] More specifically, in the payment server 100, the fraud detection unit 151 first attempts to detect fraudulent use of a request for payment using a credit card (hereinafter referred to as a "credit payment request") (S71). Here, the fraud detection unit 151 first refers to the user information 172 to recognize the payment method to be applied to the generated payment request. Here, if it is recognized that the payment method to be applied is credit payment, the fraud detection unit 151 then determines whether the target credit payment request corresponds to a suspicious request based on the fraud detection rules 178. A suspicious request is a credit payment request suspected of being intended for the fraudulent use of a credit card. Here, if it is determined that the target credit payment request is not a suspicious request, the payment processing unit 130 sends a normal authorization message (hereinafter referred to as a "first authorization message") to the credit card company server 200 to notify payment information related to the credit payment (S72).

[0042] The credit card company server 200 executes authorization processing based on the first authorization message received in step S72 (S73). The authorization processing is a process for confirming the availability of credit card payment, and includes processes for confirming the validity of the credit card, detecting fraudulent use, and confirming the available balance. The fraudulent use detection in the authorization processing may be performed using a method similar to that used by the fraud detection unit 151 of the payment server 100, or may be performed using a method unique to the credit card company. If the authorization processing confirms that credit card payment is available for the target credit card payment request, the credit card company server 200 executes credit card payment processing based on the payment information included in the first authorization message (S74) and responds with the processing result to the payment server 100 (S75).

[0043] [If fraud detection is detected] In the store scan flow of Fig. 8, when the first store terminal device 50 transmits payment information to the payment server 100 (S16), the payment server 100 executes electronic payment based on the payment information received in step S16 (S17). Here, if the payment method setting is set to "credit card payment," the payment server 100 executes credit card payment processing in cooperation with the credit card company server 200, but the payment is stopped due to the detection of fraudulent use (S171 to S176).

[0044] More specifically, in the payment server 100, the fraud detection unit 151 first attempts to detect fraudulent use of the generated credit card payment request, similar to S71 (S171). If the credit card payment request is determined to be suspicious, the payment processing unit 130 notifies the payment application 20 of a payment error (S172) and cancels the electronic payment. In this case, the payment application 20 displays a payment error (S173).

[0045] At this time, the function restriction unit 152 restricts some or all of the functions available to the target user in the electronic payment service (S174), while the fraud detection unit 151 generates a dedicated authorization message (second authorization message) to notify the result of the fraudulent use determination and sends it to the credit card company server 200 (S175).

[0046] Generally, an authorization message is used to instruct the credit card company server 200 to settle a predetermined amount. On the other hand, a second authorization message is an authorization message used only for notification. For this reason, the function restriction unit 152 sends, as a second authorization message, an authorization message that instructs the settlement of a predetermined amount without imposing a burden on the user. For example, the predetermined amount may be 0 yen or 1 yen.

[0047] The credit card company server 200 can recognize the determination result of the fraudulent use detection on the payment server 100 side from the second authorization message received in step S175 (S176). The credit card company server 200 may be configured to perform processing according to the recognized determination result in step S176. For example, the credit card company server 200 may be configured to impose credit card usage restrictions based on the determination result. Furthermore, if the credit card company performs its own fraudulent use detection, the credit card company server 200 may be configured to incorporate the determination result on the payment server 100 side into the fraud detection rules on the credit card company server 200 side to perform fraudulent use detection.

[0048] For convenience of explanation, the flow when no fraudulent use is detected in the case of Fig. 7 (user scan) is described here, and the flow when fraudulent use is detected in the case of Fig. 8 (store scan) is described here. However, the electronic payment (credit card payment) process itself is common regardless of the scanning method. That is, when fraudulent use is detected in the user scan (Fig. 7), the detection of fraudulent use may be notified to the credit card company server 200 by a second authorization message similar to Fig. 8 in addition to or instead of sending a first authorization message (S72). Also, when fraudulent use is not detected in the store scan (Fig. 8), payment information may be notified to the credit card company server 200 by a first authorization message similar to Fig. 7 instead of sending a second authorization message (S175).

[0049] For the sake of convenience, the processing flow when the payment method setting is set to "credit card payment" has been described here, but the process of notifying the credit card company server 200 of the detection of fraudulent use by using the second authorization message may be performed regardless of the content of the payment method setting or the purpose of payment. For example, the detection of fraudulent use and the transmission of the second authorization message may be performed when the payment method setting is "charge balance payment," or when the purpose of payment is other than payment (for example, charging or remittance).

[0050] For example, if fraudulent use is detected based on the second payment information in step S6 in the user scan of FIG. 2, the payment server 100 may send a second authorization message to the credit card company server 200 instead of the electronic payment in S7. Also, for example, if fraudulent use is detected based on the payment information in step S16 in the store scan of FIG. 3, the payment server 100 may send a second authorization message to the credit card company server 200 instead of the electronic payment in S17. This allows the credit card company server 200 to recognize users whose use of the payment app 20 is restricted, and thus allows the credit card company server 200 to perform predetermined processing for such users. For example, the credit card company server 200 may restrict the use of credit cards by users whose use of the payment app 20 is restricted.

[0051] Generally, credit card companies often have their own systems for detecting fraudulent use of credit cards issued by the company. In such cases, the details of fraudulent use of payment app 20 detected by payment server 100 are notified to credit card company server 200, allowing the credit card company to adapt its own fraud detection system to the system on payment server 100. For example, if the credit card company imposes further usage restrictions on a user whose use of payment app 20 is restricted, the timing and conditions for lifting the restrictions may differ, which may unnecessarily hinder the convenience of legitimate users. Based on this idea, for example, the credit card company may take measures such as not imposing restrictions on users notified by payment server 100 using its own system. In this way, the results of fraudulent use detection on payment server 100 are notified to credit card company server 200 regardless of the type of payment method, allowing credit card companies and payment service providers to work together to promote fraud prevention efforts.

[0052] [Removing function restrictions using a payment app] 9 is a flowchart showing an example of the flow of processing that the payment server 100 performs regarding function restriction due to fraudulent use detection. The flow in FIG. 9 starts when the payment server 100 receives a new payment request from the payment application 20. First, the fraud detection unit 151 determines whether the newly received payment request corresponds to a suspicious request based on the fraud detection rules 178 (S201). If the payment request is determined to be a suspicious request, the payment processing unit 130 performs normal processing (for example, S71 to S75 in FIG. 7) to perform the requested electronic payment (S202).

[0053] On the other hand, if it is determined in S201 that the newly received payment request is a suspicious request, the fraud detection unit 151 notifies the requestor of a payment error (S203), and the function restriction unit 152 restricts the functions of the payment application 20 for the user of the payment application 20 (S204).

[0054] Next, the restriction removal unit 152 determines whether the fraudulent usage situation of the payment request determined to be a suspicious request in S201 corresponds to a situation where the restriction should be removed using the payment application 20 (application cancellation target) (S205). The conditions for determining whether an application is a cancellation target (application cancellation condition) may be set arbitrarily by the electronic payment service provider. For example, the application cancellation condition may be such that all suspicious requests are cancellation targets, or such that suspicious requests occurring under specific circumstances are cancellation targets. If the suspicious request detected in S201 does not correspond to the application cancellation condition, the restriction removal unit 152 sends the suspicious request to a personnel screening process for review (S206). The personnel screening process is a process in which a person reviews the validity of the result of the fraudulent usage determination for the suspicious request.

[0055] On the other hand, if the suspicious request detected in S201 satisfies the application cancellation condition, the restriction removal unit 153 inquires of the user whether the suspicious request was made by the user's own operation (S207). As described above, the suspicious request may be a payment request related to credit payment or a payment request related to the remaining charge balance. For example, the restriction removal unit 153 displays a screen (declaration screen) that accepts input of a response to the inquiry.

[0056] FIG. 10 is a diagram showing an example of the flow of releasing function restrictions using payment application 20. In the example of FIG. 10, first, when fraud detection unit 151 detects a suspicious request, restriction release unit 153 transmits a notification to user terminal device 10 of the target user that the suspicious request has been detected and that function restrictions have been implemented. This notification causes notification screen D1 to be displayed on user terminal device 10. For example, notification screen D1 includes a message notifying that function restrictions have been implemented and link information IF1 to a declaration screen. Link information IF1 may be displayed as, for example, a button interface. When the user operates button interface IF1, notification screen D1 transitions to declaration screen D2.

[0057] The declaration screen D2 may display information according to the type of transaction request. FIG. 10 illustrates an example of a declaration screen D21 for a payment request and a declaration screen D22 for a remittance request. The declaration screen D21 displays the transaction date and time, the name of the store, and the amount used for the payment request. The declaration screen D22 displays the transaction date and time and the remittance amount for the remittance request. The user responds to the inquiry by pressing the "Yes" button if the transaction request being confirmed is the result of the user's operation, or by pressing "No" if the transaction request is not the result of the user's operation. The restriction removal unit 153 notifies the credit card company server 200 of the response displayed on the declaration screen D22 using a notification-only authorization message (third authorization message) that is different from the first authorization message for payment (S208). Similar to the second authorization message, the third authorization message may be an authorization message that instructs the user to settle a specified amount without imposing a burden on the user.

[0058] Returning to FIG. 9, the restriction removal unit 153 then performs identity verification on the target user (S209). For example, authentication by outgoing call (outgoing call authentication) can be cited as an example of a method of identity verification. Outgoing call authentication is an authentication method in which an authentication requester is instructed to make an outgoing call to an authentication phone number, and the requester is authenticated when the recipient of the authentication phone number confirms that the call is coming from the phone number of the requester. Another example of identity verification processing is SMS (Short Message Service) authentication. SMS authentication is a method in which predetermined information is sent to the authentication requester by SMS and the requester is authenticated by having the sent information returned. In addition to these, the restriction removal unit 153 may perform identity verification using any other method.

[0059] Next, the restriction lifting unit 153 determines whether the user identity verification performed in step S209 was successful (S210). If it is determined that the user identity verification was successful, the restriction lifting unit 153 lifts the function restriction imposed due to the suspicious request (S211). In addition to lifting the function restriction for the target user, the restriction lifting unit 153 may be configured to disable the rule (target rule) that detected the suspicious request among the fraud detection rules 178 for a certain period of time. This makes it possible to prevent the user's payment request from being detected as a suspicious request again due to the same operation as when the suspicious request was detected.

[0060] 10, if the answer on the declaration screen D1 is "Yes" and the identity verification by the call origination authentication is successful, the payment server 100 releases the function restriction for the target user and disables the target rule for a certain period of time. Also, for example, if the answer on the declaration screen D1 is "No" and the identity verification by the call origination authentication is successful, the payment server 100 continues the function restriction for the target user and sends the review of the suspicious request to the personnel review process (S206).

[0061] In this case (when the answer is "No" and the call origination authentication is successful), the payment server 100 may be configured to monitor (monitor) the usage of the payment app 20, with the target user as a subject requiring monitoring. In this case, if a specific operation is detected during monitoring, the payment server 100 may be configured to perform processing on the target user according to the specific operation. For example, if an inappropriate operation is detected during monitoring, the payment server 100 may be configured to impose further functional restrictions on the target user. Furthermore, if no inappropriate operation is detected during monitoring for a certain period of time, the payment server 100 may be configured to release the functional restrictions on the target user.

[0062] On the other hand, in the example of FIG. 10, if identity verification by call origination authentication fails, the payment server 100 may be configured to restrict all transactions using the payment application 10 for the target user.

[0063] According to the embodiment described above, in a fraud detection system that imposes certain usage restrictions on users who have been detected as fraudulent in electronic payments, it is possible to reduce the effort required to lift the usage restrictions.

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

[0065] 10 User terminal device 20. Payment App 100, 100A payment server 120, 120A Payment Contents Department 122A Display control unit 130 Payment processing unit 140 Information Management Department

Claims

1. A payment management device that provides an electronic payment service to a user in cooperation with a payment application that runs on the user's terminal device, a payment processing unit that executes payment processing in response to a payment request received from the payment application; a fraud detection unit that, when the payment request is received from the payment application, determines whether the payment request is for the purpose of fraudulent use; a function restriction unit that restricts functions of the payment application of the user in response to a suspected payment request that is determined to be fraudulent by the fraud detection unit; a restriction removal unit that obtains from the payment application the user's declared information, which is an answer as to whether the suspicious requested transaction was the result of the user's own operation, performs identity verification on the user, and releases the function restriction in accordance with the declared information and the result of the identity verification, and prompts the user to re-execute the transaction; A payment management device comprising:

2. the restriction removal unit transmits the user's reported information acquired regarding the suspicious request to a credit card company server that executes payment processing using a credit card registered in the payment app as a payment method related to the electronic payment service; The payment management device according to claim 1 .

3. When the payment processing unit receives the payment request, it transmits an authorization message to a credit card company server that executes payment processing using the credit card, instructing credit card payment of a specified amount, The restriction lifting unit transmits the reporting information to the credit card company server using a second authorization message that is different from the authorization message for payment. The payment management device according to claim 2 .

4. The second authorization message is an authorization message instructing the credit card company server to settle a predetermined amount without the user having to pay it. The payment management device according to claim 3 .

5. The fraud detection unit Detecting suspicious requests based on predetermined fraud detection rules, When the function restriction is lifted by the restriction lifting unit, the rule that detected the suspicious request related to the function restriction among the fraud detection rules is disabled for a certain period of time. The payment management device according to claim 1 .

6. a payment management device that provides an electronic payment service to a user in cooperation with a payment application that runs on the user's terminal device, a payment processing step of executing a payment process in response to a payment request received from the payment application; a fraudulent use detection step of determining whether a payment request for the user to use a payment function of the electronic payment service is intended for fraudulent use when the payment request is received from the payment application; a function restriction step of restricting functions of the payment application of the user in response to a suspected payment request that is determined to be fraudulent in the fraud detection step; a restriction lifting step of obtaining, from the payment application, declared information that is a response as to whether the suspicious requested transaction was the result of the user's own operation, and performing identity verification on the user, and lifting the function restriction in accordance with the declared information and the results of the identity verification, and prompting the user to re-execute the transaction; A payment management method comprising:

7. A payment management device that provides an electronic payment service to a user in cooperation with a payment application that runs on the user's terminal device, a payment processing step of executing a payment process in response to a payment request received from the payment application; a fraudulent use detection step of determining whether a payment request for the user to use a payment function of the electronic payment service is intended for fraudulent use when the payment request is received from the payment application; a function restriction step of restricting functions of the payment application of the user in response to a suspected payment request that is determined to be fraudulent in the fraud detection step; a restriction lifting step of obtaining, from the payment application, declared information that is a response as to whether the suspicious requested transaction was the result of the user's own operation, and performing identity verification on the user, and lifting the function restriction in accordance with the declared information and the results of the identity verification, and prompting the user to re-execute the transaction; A program to execute.

Images