Payment management device, payment management method, and program

Abstract

To reduce the effort required to lift usage restrictions in a fraud detection system that imposes certain usage restrictions on users whose fraudulent use of electronic payments has been detected. [Solution] A payment management device comprising: a payment processing unit that executes payment processing in response to a payment request received from a user's payment application; a fraud detection unit that determines whether the payment request is intended for fraudulent use; a function restriction unit that restricts the functions of the user's payment application in response to a suspected payment request which is determined to be fraudulent by the fraud detection unit; and a display control unit that, when the function restriction unit restricts the functions of the user's payment application, displays a declaration screen on the display unit of the terminal device that allows the user to declare whether the suspected payment request was made by the user themselves.

Description

[[Technical Field]]

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

[0002] Conventionally, there has been 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 information of the credit card holder and the amount for which payment is requested) when the credit card is used. For example, Patent Document 1 discloses a technology for determining whether a credit card payment request is caused by fraudulent use by using history information added to authorization data. (See Patent Document 1). [[Prior Art Documents]] [[Patent Documents]]

[0003] [[Patent Document 1]] Japanese Unexamined Patent Application Publication No. 2004-348536 [[Summary of the Invention]] [[Problems to be Solved by the Invention]]

[0004] On the other hand, even for an authorized user, there are cases where the credit card payment situation happens to match the fraud conditions, and thus the use of the credit card is restricted. In this case, the authorized user can have the usage restriction lifted by making an inquiry to the credit card company to complete identity verification, or by explaining that the credit card payment is made by himself / herself.

[0005] However, in such a process, it sometimes takes a long time (for example, several days) before the usage restriction on the credit card is lifted. In addition, it is known that on an e-commerce website, if a credit card payment is determined to be fraudulent, the user is highly likely to leave the website without completing the product purchase (so-called cart abandonment).

[0006] Thus, conventional credit card fraud detection methods can be time-consuming to lift usage restrictions, potentially resulting in lost opportunities for both users and product sellers.

[0007] This invention has been made in consideration of these circumstances, and one of its objectives is to provide a payment management device, a payment management method, and a program that can reduce the effort required to lift usage restrictions in a fraud detection system that imposes certain usage restrictions on users whose fraudulent use of electronic payments has been detected. [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 application operating on the user's terminal device, comprising: a payment processing unit that executes payment processing related to a payment request in response to a payment request received from the payment application; a fraud detection unit that determines whether the payment request is intended for fraudulent use; a function restriction unit that restricts the functions of the user's payment application in response to a suspected request, which is a payment request determined by the fraud detection unit to be due to fraudulent use; and a display control unit that, when the function restriction unit restricts the functions of the user's payment application, causes the terminal device's display unit to display a declaration screen on the display unit that allows the user to declare whether the suspected request was made by the user's own operation. [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 whose fraudulent use of electronic payments has been detected, the effort required to lift such usage restrictions can be reduced. [Brief explanation of the drawing]

[0010] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payments. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments. [Figure 4] This is a configuration diagram of the payment server 100 according to the first embodiment. [Figure 5] This figure shows an example of the contents of user information 172. [Figure 6] This figure shows an example of the contents of merchant / store information 176. [Figure 7] This is a sequence chart (part 1) illustrating an example of the processing flow that the payment server 100 performs in cooperation with the credit card company server 200 when a credit card payment is made. [Figure 8] This is a sequence chart (part 2) illustrating an example of the processing flow that the payment server 100 performs in cooperation with the credit card company server 200 when a credit card payment is made. [Figure 9] This flowchart shows an example of the processing flow that the payment server 100 implements regarding functional restrictions in response to fraud detection. [Figure 10] This diagram shows an example of the process for removing function restrictions using payment app 20. [Modes for carrying out the invention]

[0011] The embodiments of the payment management device, payment management method, and program of the present invention will be described below with reference to the drawings. Various devices such as "server," "management device," and "information providing device" that appear below and are used to provide services to users or perform internal analysis may be implemented by a distributed group of devices, and the operators of each device may be different. Furthermore, the owner of the hardware of the devices (the provider of the cloud server) and the operator that actually operates them may also be different. 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 the payment app. The electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at a virtual store, the user may be directed to the interface screen of the electronic payment service. In the electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and processing such as payment when a purchase is made at a store is mainly carried out between the user and the merchant. Alternatively, payment and other processing may be conducted between the user and the store.

[0012] [Electronic payment service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized with a payment server 100 at its center. 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 a network NW. The network NW includes, for example, the internet, a LAN (Local Area Network), a wireless base station, and provider equipment.

[0013] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device having at least optical reading function, communication function, display function, input reception function, and program execution function. In the following description, the components for realizing these functions will be referred to as a camera, communication device, touch panel, CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as the CPU, and it 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, for example, from 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 may include a so-called POS (Point of Sale) device, and the product price acquisition function and 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 paper or plastic media. The store code image 60 may also 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 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 interface 72 for member stores may be a member store application or a browser. The interface 72 for member stores accepts coupon settings and the like by the operator of the member store, and transmits the same to the payment server 100. The second store terminal device 70, which is a smartphone, has functions of displaying a code image corresponding to a store code image and reading a code image displayed by the user terminal device 10 by executing the member store application.

[0016] The payment server 100 implements electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and a member store server. In this case, payment information is transmitted from the POS device to the payment server 100 via the member store server. In the following description, this is not particularly distinguished, and it is assumed that payment information is transmitted from the first store terminal device 50.

[0017] The credit card company server 200 is a server operated by the issuing company (credit card company) of the credit card owned by the user of the payment application 20, and is a server that performs processing (credit card payment processing) for realizing 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 content of an authorization message received during electronic payment using a credit card. The authorization message is a message transmitted to the credit card company server 200 for card validity confirmation (Authorization) when the credit card is used, and contains information (payment information) necessary for payment such as the payee store, payment amount, and user identification information. In the case of payment using a physical credit card, a dedicated terminal installed in a store or the like reads card information, generates an authorization message, and transmits 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 application 20, the payment server 100 that has received a payment request from the payment application 20 generates an authorization message and transmits it to the credit card company server 200.

[0018] FIG. 2 and FIG. 3 are sequence diagrams illustrating an outline flow of electronic payment. There may be two patterns of electronic payment, Pattern 1 and Pattern 2.

[0019] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), 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 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the 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 merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then sends 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). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0020] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (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 that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is obtained in advance by barcode scanning or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

[0021] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 will identify the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0022] [Payment Server] Figure 4 is a configuration diagram of a payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content provision unit 120, a payment processing unit 130, an information management unit 140, an information processing unit 150, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by 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 LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into the drive device.

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

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

[0025] The payment content provision unit 120, for example, has the functionality 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 provision unit 120 reads the 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 aforementioned payment information and other data to the payment server 100.

[0026] The payment processing unit 130 performs payment processing based on 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] Figure 5 shows 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, user URL, account ID, telephone number, password, as well as information such as email address, user ID, name, address, date of birth, registration date, charge balance, credit payment settings, credit payment limit, credit payment amount, available credit payment amount, payment method settings, bank account, credit card number, charge history information, payment history information, and usage restriction information. The user URL is used for money transfer processing between users. When registering for a new electronic payment service, registration of a telephone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can set at will (or does not have to set). Similarly, the email address and name, address, and date of birth are also information that the user can set at will (or does not have to set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

[0028] The charge balance is information indicating the balance of electronic money set by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank) and sending from a registered bank account. The credit payment setting indicates whether or not the user has completed the settings to enable electronic payments by credit card, and is set to either "Completed" or "Not Completed". The credit payment limit is the monthly limit for credit payments, the credit payment amount is the amount already used for credit payments in the current month, and the available credit payment amount is the amount available for credit payments in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the diagram shows only one credit payment limit, in reality there are also daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be described later. The payment method setting indicates whether the user will use electronic payment with the charge balance or payment by credit card at that time. The bank account and credit card number information, respectively, refers to the bank account or credit card number (account number, card number) to which funds can be deposited into the electronic payment service. The charge history information is a record of when the user has previously sent money to the electronic payment service to increase the charge balance. The payment history information shows the details of each payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0029] Usage restriction information is configuration information used to restrict the use of payment app 20 for users who have been detected to be engaging in fraudulent use of payment app 20. Usage restriction information includes, for example, whether or not usage restrictions are in place, the scope of functions that will be restricted, and the duration for which the restrictions will be in effect. Usage restriction information is updated as needed, such as when fraudulent use is detected or when the conditions for lifting the restrictions are met, to reflect the current situation.

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

[0031] The Information Management Unit 140 manages user information 172 and affiliated store / store information 176 based on information obtained from the user terminal device 10 and the second store terminal device 70. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and affiliated store / store information 176.

[0032] [Electronic payment] When the payment processing unit 130 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 172 to obtain the user's "payment method setting". 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, which is managed in association with the user ID, and increasing the value of the merchant's sales proceeds item. For example, the value of the merchant's sales proceeds item is not used as electronic money itself, but rather the amount corresponding to the value of the sales proceeds item is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0033] The payment processing unit 130 performs electronic payment as follows for users whose "settings information" is set to "credit payment". Credit payment is a payment method in cooperation with a credit card company, which is a separate entity from the electronic payment service operator. The electronic payment service operator acts as the donor and allows electronic payment within the credit limit, without relying on the charge balance. In order to use the credit payment service, users may be required to obtain a credit card provided by the electronic payment service operator. The amount used by credit payment is settled in a lump sum for the month on the payment date of the following month, for example, by withdrawal from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the amount used by credit payment and subtracting the same amount from the available credit payment limit. When the closing date arrives, it processes the payment for the current month to be withdrawn on the payment date of the following month as described above, or requests the credit card company operator to perform the said process. If the settlement amount exceeds the available credit payment limit at the time of provisional settlement, an error notification is sent back to the payment app 20.

[0034] [Fraud detection in payment apps] As described above, the electronic payment service of this embodiment allows users to pay using their balance via the payment app 20, or by credit card. While such an electronic payment service is convenient for users because it can be easily accessed from the payment app 20, it is susceptible to fraudulent use through methods such as phishing and skimming. Therefore, the electronic payment service of this embodiment has a function (fraud detection function) that monitors the use of the payment app 20 and detects fraudulent use of the electronic payment service. The fraud detection function is implemented by the information processing unit 150.

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

[0036] When a payment request is made by the payment application 20, the fraud detection unit 151 compares the circumstances of the payment request with the fraud detection rules 178 that are stored in the storage unit 170 in advance to determine whether or not the payment request is intended for fraudulent use.

[0037] The function restriction unit 152 restricts the use of the payment application 20 by users of the payment application 20 whose 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 depending on the circumstances under which fraudulent use of the payment application 20 has been detected. For example, the function restriction unit 152 may restrict not only the function of payment using the charge balance (charge balance payment), but also functions such as remittance using the charge balance. Alternatively, for example, the function restriction unit 152 may restrict not only the function of payment using a credit card (credit payment), but also functions such as charging and remittance using a credit card. In this embodiment, the payment, charging, and remittance functions provided by the payment application 20 are examples of "payment functions" that can be used by users in an electronic payment service.

[0038] The restriction removal unit 153 performs a process to remove the functional restrictions for a user whose use of the payment app 20 has been restricted due to the detection of fraudulent use, if it is confirmed that the payment request determined to be fraudulent was made by the user themselves. More specifically, the restriction removal unit 153 removes the functional restrictions if the user declares that the payment request in question is not fraudulent and the user's identity has been successfully verified.

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

[0040] [If no fraud detection is performed] In the user scan flow shown in Figure 7, when the payment app 20 sends 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). If the payment method setting is set to "credit card payment", the payment server 100 works in cooperation with the credit card company server 200 to execute the credit card payment process (S71-S75).

[0041] More specifically, first, the fraud detection unit 151 in the payment server 100 attempts to detect fraudulent use of a credit card payment request (hereinafter referred to as "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. If it is recognized that the payment method to be applied is credit card payment, the fraud detection unit 151 then determines, based on the fraud detection rule 178, whether or not the target credit payment request is a suspected request. A suspected request is a credit payment request that is suspected to be intended for the fraudulent use of a credit card. If it is determined that the target credit payment request is not a suspected request, the payment processing unit 130 sends a normal authorization message (hereinafter referred to as "first authorization message") to the credit card company server 200 to notify payment information regarding 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). Authorization processing is a process to confirm the availability of credit card payment, and includes processes to confirm the validity of the credit card, processes to detect fraudulent use, and processes to confirm the available balance. Fraudulent use detection in authorization processing may be performed in the same way as the fraud detection unit 151 of the payment server 100, or it may be performed using a method unique to the credit card company. If the credit card company server 200 confirms that credit card payment is available for the target credit card payment request through authorization processing, it executes credit card payment processing based on the payment information contained 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 shown in Figure 8, when the first store terminal device 50 sends 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 payment", the payment server 100 works with the credit card company server 200 to execute the credit payment process, but the payment is stopped due to fraud detection (S171~S176).

[0044] More specifically, first, in the payment server 100, the fraud detection unit 151 attempts to detect fraudulent use in the generated credit card payment request, similar to S71 (S171). If the target credit card payment request is determined to be a suspicious request, 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] In this case, the function restriction unit 152 restricts some or all of the functions available to the user in question using the electronic payment service (S174), while the fraud detection unit 151 generates a special authorization message (second authorization message) to notify the credit card company server 200 of the fraud detection result (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, the second authorization message is an authorization message solely for notification. Therefore, the function restriction unit 152 sends an authorization message as the second authorization message that instructs the user to settle a predetermined amount without imposing any 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 result of the fraud detection on the payment server 100 side based on 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 result in step S176. For example, the credit card company server 200 may be configured to restrict credit card use based on the result. Alternatively, if the credit card company performs its own fraud detection, the result of the payment server 100 may be incorporated into the fraud detection rules on the credit card company server 200 side to perform fraud detection.

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

[0049] Furthermore, for the sake of explanation, the processing flow described here is for the case where the payment method setting is set to "credit card payment." However, the process of notifying the credit card company server 200 of the detection of fraudulent use via a second authorization message may be performed regardless of the content of the payment method setting or the purpose of the payment. For example, fraudulent use detection 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 the payment is something other than payment (e.g., charging or remittance).

[0050] For example, if fraudulent use is detected in the user scan in Figure 2 based on the second payment information in step S6, 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 in the store scan in Figure 3 based on the payment information in step S16, 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 has been restricted, and to perform predetermined processing for such users. For example, the credit card company server 200 may restrict the use of credit cards for users whose use of the payment app 20 has been restricted.

[0051] Generally, credit card companies often have their own systems to detect fraudulent use of the credit cards they issue. In such cases, when the details of fraudulent use of the payment app 20 detected by the payment server 100 are notified to the credit card company server 200, the credit card company can adapt its own fraud detection mechanism to the system on the payment server 100. For example, if the credit card company imposes further restrictions on users whose use of the payment app 20 has been restricted, the timing and conditions for lifting the restrictions may differ, potentially hindering the convenience of legitimate users more than necessary. Based on this consideration, for example, a credit card company can choose not to impose restrictions using its own system on users notified by the payment server 100. In this way, by notifying the credit card company server 200 of the fraud detection results from the payment server 100, regardless of the type of payment method, it becomes possible for credit card companies and payment service providers to cooperate in promoting efforts to prevent fraudulent use.

[0052] [Removing restrictions using payment apps] Figure 9 is a flowchart showing an example of the processing flow performed by the payment server 100 regarding functional restrictions associated with fraud detection. The flow in Figure 9 is initiated 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 is a suspected request based on the fraud detection rule 178 (S201). If the payment request is determined to be a suspected request, the payment processing unit 130 performs the normal processing (for example, S71 to S75 in Figure 7) to carry out the requested electronic payment (S202).

[0053] On the other hand, if in S201 a newly received payment request is determined to be a suspicious request, the fraud detection unit 151 notifies the requester 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 circumstances of the fraudulent use of the payment request determined to be a suspected request in S201 fall under the category of items eligible for restriction removal using the payment app 20 (app removal target) (S205). The conditions for determining whether or not an item is eligible for app removal (app removal conditions) can be arbitrarily set by the provider of the electronic payment service. For example, the app removal conditions may be to make all suspected requests eligible for app removal, or to make suspected requests that occur under specific circumstances eligible for app removal. If the suspected request detected in S201 does not fall under the app removal conditions, the restriction removal unit 152 sends the review of the suspected request to the personnel review process (S206). The personnel review process is a process in which a person reviews the validity of the result of the fraudulent use determination for the suspected request.

[0055] On the other hand, if the suspected request detected in S201 falls under the app unlocking conditions, the restriction removal unit 153 asks the user whether the suspected request was made by the user themselves (S207). As mentioned above, the suspected request may be a payment request related to credit card payment or a payment request related to charge balance payment. For example, the restriction removal unit 153 displays a screen (declaration screen) that accepts input of the answer to the above inquiry.

[0056] Figure 10 shows an example of the process for removing function restrictions using the payment application 20. In the example in Figure 10, first, when the restriction removal unit 153 detects a suspicious request by the fraud detection unit 151, it sends a notification to the user terminal device 10 of the target user stating that a suspicious request has been detected and that function restrictions have been implemented. Upon receiving this notification, a notification screen D1 is displayed on the user terminal device 10. For example, the notification screen D1 includes a message notifying that function restrictions have been implemented and link information IF1 to the declaration screen. The link information IF1 may be displayed as a button interface, for example. When the user operates the button interface IF1, the notification screen D1 transitions to the declaration screen D2.

[0057] The declaration screen D2 may display information corresponding to the type of transaction request. Figure 10 shows examples of the declaration screen D21 for a payment request and the declaration screen D22 for a remittance request. The declaration screen D21 displays the transaction date and time, the name of the store used, and the amount used for the payment request. The declaration screen D22 displays the transaction date and time and the amount to be remitted for the remittance request. The user answers the inquiry by pressing the "Yes" button if the transaction request to be confirmed was performed by their own operation, and by pressing "No" if it was not performed by their own operation. The restriction release unit 153 notifies the credit card company server 200 of the content answered 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). The third authorization message can be any authorization message that instructs the payment of a predetermined amount in a manner that does not burden the user, similar to the second authorization message.

[0058] Returning to Figure 9, the restriction removal unit 153 then verifies the identity of the target user (S209). For example, one method of identity verification is authentication by making a phone call (phone call authentication). Phone call authentication is an authentication method in which the authentication requester is instructed to make a call to an authentication phone number, and the requester is authenticated when the receiving end of the authentication phone number confirms that a call has been received from the requester's phone number. Another example of identity verification is SMS (Short Message Service) authentication. SMS authentication is a method in which predetermined information is sent to the authentication requester via SMS, and the requester is authenticated by having the requester reply with the information that was sent. In addition to these, the restriction removal unit 153 may perform identity verification by any other method.

[0059] Next, the restriction removal unit 153 determines whether the user identity verification performed in step S209 was successful (S210). If it determines that the user identity verification was successful, the restriction removal unit 153 removes the functional restrictions that were implemented due to the suspected request (S211). Here, in addition to removing the functional restrictions for the target user, the restriction removal unit 153 may be configured to disable the rule (target rule) among the fraud detection rules 178 that detected the suspected request for a certain period of time. This prevents the user's payment request from being detected as a suspected request again through the same operation as when the suspected request was detected.

[0060] For example, as shown in Figure 10, if the answer on the declaration screen D1 is "yes" and identity verification by call authentication is successful, the payment server 100 lifts the functional restrictions for the user and disables the relevant rule for a certain period of time. Also, for example, if the answer on the declaration screen D1 is "no" and identity verification by call authentication is successful, the payment server 100 continues to restrict the user's functionality and sends the review of the suspected request to the personnel review process (S206).

[0061] In this case (when the answer is "no" and call authentication is successful), the payment server 100 may be configured to monitor the usage of the payment application 20, designating the target user as a user requiring monitoring. In this case, the payment server 100 may be configured to perform processing corresponding to a specific operation if such operation is detected during monitoring. 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. Alternatively, the payment server 100 may be configured to lift functional restrictions on the target user if no inappropriate operation is detected during monitoring for a certain period of time.

[0062] On the other hand, in the example shown in Figure 10, if identity verification by call-based authentication fails, the payment server 100 may be configured to restrict all transactions using the payment app 10 for the user in question.

[0063] According to the embodiments described above, in a fraud detection system that imposes certain usage restrictions on users whose fraudulent use of electronic payments has been detected, the effort required to lift such usage restrictions can be reduced.

[0064] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of Symbols]

[0065] 10. User terminal device 20 Payment Apps 100, 100A payment server 120, 120A Payment Content Provision Department 122A Display Control Unit 130 Payment Processing Unit 140 Information Management Department

Claims

1. A payment management device that provides electronic payment services to a user in cooperation with a payment application running on the user's terminal device, A payment processing unit that executes payment processing related to a payment request in response to a payment request received from the aforementioned payment application, A fraud detection unit that determines whether the payment request is intended for fraudulent use, A function restriction unit that restricts the functionality of the user's payment application in response to a suspected request, which is a payment request determined to be fraudulent by the fraud detection unit, When the function restriction unit restricts the user's payment application, the display control unit causes the terminal device's display unit to display a declaration screen on the terminal device's display unit that allows the user to declare whether the suspected request was made by the user themselves, A payment management device equipped with the following features.

2. If it is reported via the aforementioned reporting screen that the suspected request was made by the user themselves, the function restriction unit will lift the function restriction on the user's payment application. The display control unit causes the user's payment application to display a screen that provides the functions of the electronic payment service. The payment management device according to claim 1.

3. If it is reported via the aforementioned reporting screen that the alleged request was not made by the user themselves, the function restriction unit will continue the function restriction on the user's payment application. The display control unit causes the user's payment app to display a screen indicating that the function restriction is still in effect. The payment management device according to claim 1.

4. The aforementioned declaration screen includes a display indicating that it is necessary to confirm whether the payment request related to the suspected request was made by the user themselves. The payment management device according to claim 1.

5. The aforementioned declaration screen includes a display indicating that it is necessary to confirm whether the remittance request related to the suspected request was made by the user themselves. The payment management device according to claim 1.

6. When the suspected request is detected, the display control unit causes the user's payment app to display a screen notifying the user that the transaction related to the suspected request has been restricted. The aforementioned screen includes an input interface that accepts a transition to the aforementioned declaration screen. The payment management device according to claim 1.

7. A payment management device that provides electronic payment services to a user in cooperation with a payment application running on the user's terminal device, A payment processing step which executes payment processing related to a payment request in response to a payment request received from the payment application, A fraud detection step that determines whether the payment request is intended for fraudulent use, In response to a suspected payment request, which is determined to be a fraudulent transaction by the fraud detection step, a function restriction step is performed to restrict the functionality of the user's payment application. If the user's payment application is restricted in the function restriction step, a display control step is performed to display a declaration screen on the terminal device's display unit that allows the user to declare whether the suspected request was made by the user themselves, A payment management method that includes [specific features / features].

8. A payment management device that provides electronic payment services to a user in cooperation with a payment application running on the user's terminal device, A payment processing step that executes payment processing related to a payment request in response to a payment request received from the payment application, A fraud detection step that determines whether the payment request is intended for fraudulent use, In response to a suspected payment request, which is determined to be a fraudulent transaction by the fraud detection step, a function restriction step is performed to restrict the functionality of the user's payment application. If the user's payment application is restricted in the function restriction step, a display control step is performed to display a declaration screen on the terminal device's display unit that allows the user to declare whether the suspected request was made by the user themselves, A program to execute.

Images