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

Abstract

To prevent repeated fraudulent transactions by performing highly accurate fraud detection while maintaining the customer experience when using credit cards. [Solution] An information processing device comprising: an acquisition unit that acquires credit payment information transmitted when a user makes a credit payment using a credit card at a credit card merchant, wherein the credit payment is authorized by a predetermined fraud detection function; and a determination unit that determines whether or not there is a possibility of fraud in the credit payment after a predetermined period following the acquisition of the credit payment information.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, a program, and a system.

Background Art

[0002] Conventionally, a technique for performing fraud determination of credit settlement using authorization data (authorization data; data transmitted from a store or the like such as the owner of a credit card and the amount for which settlement is requested) when using a credit card is known. For example, Patent Document 1 discloses a technique for performing fraud determination of credit settlement using history information added to authorization data. (See Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] On the other hand, in actual credit settlement, performing highly accurate fraud determination at the time of settlement may involve a great deal of processing load and processing time, which may damage the customer experience. Therefore, in the prior art, it may not be possible to perform highly accurate fraud determination while maintaining the customer experience. As a result, cases where damages caused by unauthorized use of credit cards continue may occur.

[0005] The present invention has been made in consideration of such circumstances, and one of its objects is to provide an information processing apparatus, an information processing method, a program, and a system that can prevent continuous damages caused by unauthorized use by performing highly accurate fraud determination while maintaining the customer experience when using a credit card.

Means for Solving the Problems

[0006] One aspect of the present invention is an information processing device comprising: an acquisition unit that acquires credit payment information transmitted in response to a user making a credit payment using a credit card at a credit card merchant, wherein the credit payment is authorized by a predetermined fraud detection function; and a determination unit that determines whether or not there is a possibility of fraud in the credit payment after a predetermined period following the acquisition of the credit payment information. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to prevent repeated fraudulent use by performing highly accurate fraud detection while maintaining the customer experience when using a credit card. [Brief explanation of the drawing]

[0008] [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 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 figure shows an example of credit card payment information 178. [Figure 8] This diagram shows an example of the functional configuration of the authorization server 300. [Figure 9] This figure shows an example of SMS authentication performed by the authorization server 300. [Figure 10] This figure shows an example of credit card payment information 180 for determination. [Figure 11] This figure shows an example of credit card payment history information 182. [Figure 12] This figure shows an example of credit card payment user information 184. [Figure 13] This is a diagram illustrating the determination method used by the determination unit 154. [Figure 14] This sequence diagram shows an example of the flow of an online credit payment service executed through the cooperation of a user terminal device 10, a payment server 100, a merchant shopping server 200, and an authorization server 300. [Figure 15] This flowchart shows an example of the processing flow executed by the information processing unit 150. [Modes for carrying out the invention]

[0009] The following describes embodiments of the information processing apparatus, information processing method, and program of the present invention with reference to the drawings. Various devices, such as the "server" mentioned below, which 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 an electronic payment service. 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, processing such as payment may be carried out between the user and the store.

[0010] [Electronic Payment Service] FIG. 1 is a diagram showing an example of the configuration of an electronic payment system in which an electronic payment service is realized. The electronic payment service is realized centering around a payment server 100. An electronic payment system for realizing the electronic payment service includes, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more second store terminal devices 70, a payment server 100, a franchise shopping server 200, and an authentication server 300. These devices communicate with each other via, for example, a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, a network of a payment system such as a credit card, and the like. Some or all of the functional configurations included in the electronic payment system may be distributed among a plurality of devices in an arbitrary form or integrated into an arbitrary device.

[0011] The electronic payment system or the payment server 100 is an example of an "information processing device". Some of the functional configurations of the payment server 100 may be included in the authentication server 300 described later. In this case, the combined functional configuration of the payment server 100 and the authentication server 300 is an example of an "information processing device". All of the functional configurations of the payment server 100 may be included in the authentication server 300. In this case, the authentication server 300 is an example of an "information processing device". Further, among the payment server 100, an information processing unit 150 described later may be separated from the payment server 100 and mounted on an independent server device. In this case, the information processing unit 150 is an example of an "information processing device".

[0012] [User Terminal Device] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, when the settlement application 20 is executed by a processor such as a CPU, it operates to provide an electronic payment service to the user in cooperation with the settlement server 100. The settlement application 20 is installed in the user terminal device 10 from, for example, an application store, and controls a camera, a communication device, a touch panel, etc. Further, in the user terminal device 10, when the browser application 22 is executed by a processor such as a CPU, it accesses the franchise shopping server 200 and operates to provide, for example, an online shopping service to the user.

[0013] [First store terminal device] The first store terminal device 50 is installed in a store, for example. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the 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. Note that the store code image 60 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone).

[0014] [Second store terminal device] 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, personal computer, etc. The affiliated store interface 72 operates on the second store terminal device 70. The affiliated store interface 72 may be an affiliated store application or a browser. The affiliated store interface 72 accepts coupon settings etc. from the affiliated store operator and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image by running the affiliated store application, and reading a code image displayed by the user terminal device 10. Although not explained in Figure 1, affiliated stores may also be equipped with a card store terminal device that processes payments for physical credit cards presented to users. In that case, when a credit card payment is executed, the card store terminal device transmits credit card payment information related to the payment to the authorization server 300.

[0015] [Merchant Shopping Server] The merchant shopping server 200 is, for example, an online shopping service provided on a website by a credit card merchant. When the merchant shopping server 200 receives an access request from the browser application 22 installed on the user terminal device 10, it provides the browser application 22 with a service screen for the user to perform online shopping. The merchant shopping server 200 provides a credit payment service (online credit payment service) for settling for goods or services on the online shopping site. When a credit payment is executed on the online shopping site, the merchant shopping server 200 transmits the credit payment information related to that payment to the authorization server 300.

[0016] [Authorization Server] The authorization server 300 is, for example, a server device managed by the merchant's contracting company. The authorization server 300 performs authentication to determine whether or not to authorize a credit payment based on the credit payment information provided by the merchant shopping server 200. If the authorization server 300 authenticates that it will authorize the credit payment, it provides the credit payment information to the payment server 100. The authorization server 300 is an example of the "predetermined fraud detection function" and "authentication server" in the claims.

[0017] [Payment Server] The payment server 100 is, for example, a server device of a credit card issuer. The payment server 100 confirms and executes the credit card payment based on the credit card payment information authenticated as legitimate by the authorization server 300. More specifically, when a predetermined date arrives, the payment server 100 deducts the payment amount indicated by the credit card payment information from the bank account linked to the user's credit card, and deposits the amount minus the payment fee into the merchant's bank account.

[0018] The payment server 100 further 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 merchant server, in which case payment information is transmitted from the POS device to the payment server 100 via the merchant server. In the following description, these will not be specifically distinguished, and it will be assumed that payment information is transmitted from the first store terminal device 50.

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

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

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

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

[0023] [Payment Server Functional Configuration] Figure 4 is a diagram of the configuration of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a 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), GPU (Graphics Processing Unit), and SOC (System On Chip), 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.

[0024] 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 the payment server 100 can access via the network. The storage unit 170 stores information such as user information 172, content information 174, merchant / store information 176, credit card payment information 178, credit card payment information for determination 180, credit card payment history information 182, and credit card payment user information 184. Details of each piece of information will be described later.

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

[0026] The content provider 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 content provider unit 120 reads the necessary content from the 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 the content is being played by the payment application 20 and transmits the aforementioned payment information to the payment server 100. The above content may also be generated by the payment application 20. In this case, the content provider unit 120 provides the payment application 20 with the information necessary for generating the content.

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

[0028] 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, and payment history 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.

[0029] 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 using credit card payments (credit card payments using code information) via the payment app 20, and is set to either "Completed" or "Not Completed". The credit payment limit is the monthly limit for available credit payments, the credit payment amount is the amount of credit payments already made in the current month, and the available credit payment amount is the amount of credit payments available 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 make an electronic payment using the charge balance or a credit payment 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.).

[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 acquires information provided by other server devices and terminal devices. Based on the information acquired from the user terminal device 10 and the second store terminal device 70, the Information Management Unit 140 manages user information 172 and merchant / store information 176. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and merchant / store information 176. The Information Management Unit 140 also manages information acquired from the authorization server 300. Information acquired from the authorization server 300 is managed, for example, as credit payment information 178.

[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 using code information)". Credit payment is a payment method that is carried out 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 donor and allows electronic payment that does not depend on the charge balance within the credit payment limit. In order to use the credit payment service, it may be required to obtain a credit card provided by the operator of the electronic payment service. 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 operator of the credit card company 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] When a user makes a credit card payment, the payment processing unit 130 transmits the credit card payment information related to the payment to the authorization server 300, and the authorization server 300 may perform authentication to determine whether or not to authorize the credit card payment corresponding to the credit card payment information. If the authorization server 300 authenticates that it authorizes the credit card payment, it notifies the payment server 100 of this fact, and the payment processing unit 130 may perform subsequent payment processing.

[0035] The information processing unit 150 performs various information processing. For example, based on the determination credit payment information 180, credit payment history information 182, and credit payment user information 184 stored in the storage unit 170, the information processing unit 150 determines whether there is a possibility of fraud in each credit payment corresponding to the record stored in the determination credit payment information 180. If the information processing unit 150 determines that there is a possibility of fraud in a credit payment, it performs authentication on the user of the credit payment that was determined to be potentially fraudulent. If authentication fails, the information processing unit 150 sends notification information indicating that authentication failed to the administrator terminal of the payment server 100 (i.e., the credit card issuing company). To realize these functions, the information processing unit 150 includes an acquisition unit 152, a determination unit 154, and an authentication unit 156 as functional units, but the details of each function will be described later.

[0036] [overview] Thus, in this embodiment, when a user makes an electronic payment using a credit card at a merchant, there are three patterns: (1) using the online credit payment service on the web screen provided by the merchant shopping server 200, (2) setting the payment method to "credit payment" and making a payment using the payment app 20, and (3) presenting a physical credit card at the merchant's physical store and making a payment using a credit card payment terminal. In any of these patterns, the credit payment information is transmitted to the authorization server 300, and if the transaction is authorized by the authorization server 300, the payment server 100 confirms and executes the credit payment (i.e., when a predetermined date arrives, the payment amount indicated by the credit payment information is deducted from the bank account linked to the user's credit card, and the amount minus the payment fee is deposited into the merchant's bank account).

[0037] By the way, when authorization is performed by the authorization server 300, the user will have to wait for the credit payment, including authorization, to be completed on a web screen (in case (1)) or at the storefront of a merchant (in cases (2) and (3)). Therefore, if the authorization server 300 performs highly accurate fraud detection, it may involve a significant processing load and processing time, which could impair the customer experience. For this reason, with conventional technology, the detection by the authorization server 300 was relatively simple, and as a result, there were cases where credit card fraud occurred repeatedly.

[0038] Against this backdrop, in this embodiment, the information processing unit 150 performs a more accurate fraud detection on credit payment information related to credit payments authorized by the authorization server 300, based on credit payment history information 182 (more precisely, credit payment history covering a longer period than the credit payment history used for fraud detection by the authorization server 300) and credit payment user information 184 representing the user's attributes. Subsequently, if the information processing unit 150 determines that there is a possibility of fraud in the credit payment, it performs identity authentication on the user of the credit payment determined to be potentially fraudulent. If identity authentication fails, it may send notification information indicating that identity authentication failed to the administrator terminal of the payment server 100 (i.e., the credit card issuing company). This makes it possible to prevent continuous damage from fraudulent use by performing highly accurate fraud detection while maintaining the customer experience when using credit cards. The details of this embodiment will be described below.

[0039] [Credit card payment information] Figure 7 shows an example of credit payment information 178. Credit payment information 178 is the transaction details information for each transaction received by the authorization server 300 for all credit payments. Here, "all credit payments" means credit payments made using credit cards issued by credit card issuing companies (i.e., in this embodiment, the operator of the payment server 100), and includes credit payments made by all of the methods (1) to (3) described above. Credit payment information 178 is, for example, a transaction ID associated with information such as the transaction date, merchant code, merchant name, merchant category, credit card number, and credit payment amount.

[0040] [Determination by the authorization server] Figure 8 shows an example of the functional configuration of the authorization server 300. The authorization server 300 determines whether to authorize each transaction in the received credit payment information 178. More specifically, for each transaction in the received credit payment information 178, the authorization server 300 determines a score S = f(p1, p2, ..., p) based on a predetermined fraud detection rule f. n The system calculates a score S, and if the calculated score S is greater than or equal to the first threshold, the transaction is denied. If the calculated score S is greater than or equal to the second threshold but less than the first threshold, the authorization server 300 performs SMS (Short Message Service) authentication, and if SMS authentication is completed, the transaction is permitted. Here, the second threshold is a number greater than zero and less than the first threshold. If the calculated score S is less than the second threshold, the authorization server 300 permits the transaction without performing SMS authentication.

[0041] SMS authentication refers to an authentication method that verifies the user's identity by sending an SMS notification containing a one-time password to a user terminal device 10 linked to the phone number registered when the credit card was created, and then receiving the one-time password input from the user terminal device 10. k (k=1,···n) represents the set of parameters to be input into the fraud detection rule f, and the set of parameters p kThis includes, for example, arbitrary information such as the credit payment amount, merchant identification information (merchant name, merchant category, etc.), and payment time information (transaction date, payment time slot, etc.). If the authorization server 300 uses the access source information for fraud detection, the merchant shopping server 200 will send the access source information to the authorization server 300 in addition to the credit payment information. In this way, to reduce the processing load, the authorization server 300 basically uses information from a short period (for example, at the time of credit payment) to determine whether to permit or deny the transaction. SMS authentication is an example of the "identity verification function" in the patent claims.

[0042] In this embodiment, for the sake of explanation, the authorization server 300 uses a single fraud detection rule f to determine whether to permit or deny a transaction. However, the present invention is not limited to such a configuration, and different fraud detection rules f and different identity authentication may be performed using different data depending on the type of credit payment (i.e., the credit payment methods described in (1), (2), and (3) above). For example, when a user uses an online credit payment service, access source information (IP address, location, etc.) can be obtained, and the authorization server 300 may further determine whether to permit or deny a transaction based on the access source information.

[0043] Figure 9 shows an example of SMS authentication performed by the authorization server 300. As an example, Figure 9 shows a scenario in which a user launches a browser application 22 on the user terminal device 10, accesses the e-commerce site (merchant shopping server 200) of a jewelry store that is a credit card merchant, and attempts to use the online credit payment service. As shown on the left side of Figure 9, the user selects the product they wish to purchase on the e-commerce site, selects credit card as the payment method, and enters necessary information such as the card number and security code. After entering the necessary information, when the user presses the payment button B1, the merchant shopping server 200 sends information such as the transaction date, merchant code, merchant name, merchant category, credit card number (and security code), and credit payment amount to the authorization server 300 as credit payment information corresponding to this transaction.

[0044] When the authorization server 300 receives credit card payment information, it assigns a transaction ID to it and stores it as credit card payment information 178. Next, the authorization server 300 determines whether to permit the transaction, perform SMS authentication, or deny the transaction. More specifically, as described above, the authorization server 300 denies the transaction if the score S calculated according to the fraud detection rule f is equal to or greater than the first threshold. If the calculated score S is between the second threshold and the first threshold, the authorization server 300 performs SMS authentication and permits the transaction if SMS authentication is completed. If the calculated score S is less than the second threshold, the authorization server 300 permits the transaction without performing SMS authentication.

[0045] The right side of Figure 9 shows an example where the calculated score S is above the second threshold but below the first threshold, and the authorization server 300 performs SMS authentication. As shown in the right side of Figure 9, the authorization server 300 sends an SMS notification containing a one-time password to the phone number of the user terminal device 10. At the same time, the authorization server 300 displays an authentication screen on the user terminal device 10 for entering the one-time password. When the user enters the one-time password notified by SMS into the authentication screen and presses the authentication button B2, the user terminal device 10 sends the entered one-time password to the authorization server 300, and the authorization server 300 determines that SMS authentication was successful if the entered one-time password matches the notified one-time password.

[0046] If the SMS authentication shown in Figure 9 is completed and the authorization server 300 authorizes the credit card payment transaction, information indicating this authorization is sent to the payment server 100, and the payment processing unit 130 confirms and executes the credit card payment. On the other hand, if the authorization server 300 does not authorize the credit card payment transaction, the authorization server 300 sends information indicating that the credit card payment for that transaction is not authorized to the merchant shopping server 200, and the merchant shopping server 200 displays notification information indicating that the credit card payment has failed in the browser application 22.

[0047] [Judgment section] As described above, the authorization server 300 basically uses information from a short period (for example, at the time of credit payment) to determine whether to permit or deny a transaction in order to reduce the processing load. Therefore, among transactions for which SMS authentication was not performed by the authorization server 300 and credit payment was permitted, there may be fraudulent credit payment transactions. For this reason, in this embodiment, first, the acquisition unit 152 narrows down the credit payment information 178 to credit payment information related to transactions for which SMS authentication was not performed by the authorization server 300 and credit payment was permitted, and acquires it as judgment credit payment information 180. Based on the acquired judgment credit payment information 180, credit payment history information 182, and credit payment user information 184, the determination unit 154 determines whether or not each transaction in the acquired judgment credit payment information 180 has the potential to be fraudulent.

[0048] [Credit card payment information for evaluation] Figure 10 shows an example of the credit payment information 180 for determination. The credit payment information 180 for determination is payment information narrowed down from the credit payment information 178 to be determined by the determination unit 154, and includes, for example, whether or not SMS authentication was performed and whether the transaction was permitted or not. The credit payment information 180 for determination is an aggregate of records from the credit payment information 178 where the status of whether or not SMS authentication was performed is "no" and the status of whether or not the transaction was permitted or not is "permitted".

[0049] Since the determination by the determination unit 154 is performed a predetermined period (for example, one day) after the credit payment is executed, the payment server 100 generates the determination credit payment information 180 in advance from the credit payment information 178 between the day the credit payment is executed and the following day. In Figure 10, data items such as whether SMS authentication was performed and whether the transaction was permitted or not have been added for clarity, but it is also possible to store the determination credit payment information 180 as simply the information filtered from the credit payment information 178 according to the above criteria without adding these data items. Furthermore, the determination credit payment information 180 only needs to target credit payments for which the transaction has been permitted by the authorization server 300, and may also include credit payments for which SMS authentication has been performed by the authorization server 300.

[0050] [Credit card payment history information] Figure 11 shows an example of credit payment history information 182. Credit payment history information 182 includes information such as transaction date, merchant code, merchant name, merchant category, and credit payment amount. Credit payment history information 182 is recorded for each credit card user for a predetermined period (for example, one month, one year, or the period elapsed since the credit card was created). As described above, the authorization server 300 makes a determination based on short-term information, but the determination unit 154 makes a determination using longer-term information such as credit payment history information 182.

[0051] [Credit card payment user information] Figure 12 shows an example of credit card payment user information 184. Credit card payment user information 184 is information that associates, for example, a credit card number with name, address, gender, date of birth, contract period, and statistical information 1 to statistical information N (where N is any positive integer). Credit card payment user information 184 is information that represents the attributes of the credit card user. Name, address, gender, and date of birth are information registered by the user when the credit card was obtained. The contract period is information that indicates the period from the acquisition of the credit card to the present.

[0052] Statistical information 1 to Statistical information N are information that shows the user's payment trends (features) calculated based on the credit payment history information 182. In Figure 12, as an example, statistical information 1 to Statistical information N include the user's average payment amount, high-frequency merchant categories, and high-frequency payment locations. This statistical information can be aggregated from the credit payment history information 182. For example, the user's average payment amount can be obtained by calculating the average of the payment amounts stored in the credit payment history information 182. Also, for example, the high-frequency merchant categories can be obtained as the merchant categories with the highest frequency of occurrence among the merchant categories stored in the credit payment history information 182. Also, for example, the high-frequency payment locations can be obtained as the location information with the highest frequency of occurrence from the merchant location information identified by the merchant code.

[0053] [Machine learning models] The determination unit 154 determines whether each transaction in the acquired determination credit payment information 180 is potentially fraudulent, based on the determination credit payment information 180, the credit payment history information 182, and the credit payment user information 184. Figure 13 is a diagram illustrating the determination method by the determination unit 154. The determination unit 154 obtains a fraud score by inputting the determination credit payment information 180, the credit payment history information 182, and the credit payment user information 184 into a machine learning model (e.g., a deep neural network) that has been trained to output a fraud score (e.g., a probability value between 0 and 1) indicating the likelihood of fraud in the determination credit payment information 180 when this information is input. More precisely, the determination unit 154 inputs one record of the determination credit payment information 180, the credit payment history information 182 of the user corresponding to that record, and the credit payment user information 184 of the user corresponding to that record into the machine learning model. When training the machine learning model, the operator of the payment server 100 (i.e., the credit card issuing company) collects credit card payment history information 182 and credit card user information 184 in advance for transactions that have been identified as fraudulent credit card payments, and uses this information to train the machine learning model. Note that the input information to the machine learning model is not limited to the above combination, and only information covering a longer period than the information used for judgment by the authorization server 300 is required.

[0054] [Authentication Department] If the determination unit 154 determines that there is a possibility of fraud in a credit card payment, the authentication unit 156 performs identity verification for that credit card payment. Here, identity verification may be SMS authentication as described above, or it may be outputting notification information to a terminal of a call center that cooperates with the credit card issuing company to request identity verification by telephone. In another embodiment, the authentication unit 156 may change the method of identity verification depending on the magnitude of the fraud score obtained by the determination unit 154. For example, if the fraud score obtained by the determination unit 154 is between the third threshold and the fourth threshold, the authentication unit 156 may perform SMS authentication, while if the fraud score obtained by the determination unit 154 is above the fourth threshold, it may output notification information to a terminal of the call center to request identity verification by telephone.

[0055] If user authentication fails, the authentication unit 156 may output information indicating that authentication has failed to the credit card issuer or to a terminal of a call center that cooperates with the credit card issuer, or it may automatically suspend the use of the credit card if user authentication fails. Alternatively, if the authentication unit 156 determines that there is a possibility of fraud in the credit card payment before the authentication is performed, it may automatically suspend the use of the credit card.

[0056] Thus, according to this embodiment, even if a transaction is permitted by the authorization server 300, which determines whether to permit or deny the transaction using information over a short period, after a predetermined period (for example, one day), it is determined whether there is a possibility of fraud in the transaction using information over a longer period. If it is determined that there is a possibility of fraud, authentication may be performed, notification information may be sent to the credit card issuer or call center, or the use of the credit card may be suspended. This makes it possible to prevent repeated damage from fraudulent use by performing highly accurate fraud detection while maintaining the customer experience when using a credit card.

[0057] [Sequence Diagram] Figure 14 is a sequence diagram showing an example of the flow of an online credit payment service executed through the cooperation of a user terminal device 10, a payment server 100, a merchant shopping server 200, and an authorization server 300. As an example, Figure 14 shows the flow when a user uses the online credit payment service and the authorization server 300 authorizes the credit payment.

[0058] First, the user operates a browser application 22 on the user terminal device 10 to access the merchant shopping server 200 and use the online credit payment service (S100). Next, the merchant shopping server 200 sends information such as the transaction date, merchant name, merchant code, merchant category, credit card number (and security code), and credit payment amount to the authorization server 300 as credit payment information and requests authorization (S102).

[0059] When the authorization server 300 receives credit payment information, it adds a transaction ID to the received credit payment information and stores it as credit payment information 178 (S104). Next, the authorization server 300 determines whether or not to authorize the transaction (S106). If the authorization server 300 authorizes the transaction (S108), the settlement server 100 executes the credit payment (S110). Next, the settlement server 100 waits for a predetermined period of time (S112).

[0060] After a predetermined period has elapsed, the payment server 100 determines whether there is a possibility of fraud in the credit card payment authorized by the authorization server 300. If the payment server 100 determines that there is a possibility of fraud, the payment server 100 sends an SMS notification containing a one-time password to the phone number associated with the credit card number included in the credit card payment information 178 (S116). The user checks the one-time password contained in the SMS notification and enters it on the authentication screen displayed in the browser application 22 (S118). If the payment server 100 finds that the one-time password received from the user terminal device 10 matches the one-time password sent, it terminates the process (permits continued use of the credit card).

[0061] [Process flow] Next, with reference to Figure 15, the flow of processing performed by the information processing unit 150 will be explained. Figure 15 is a flowchart showing an example of the flow of processing performed by the information processing unit 150.

[0062] First, the acquisition unit 152 acquires credit information authorized by the authorization server 300 (S200). Next, the determination unit 154 determines whether or not there is a possibility of fraud in the credit payment (S202). If it is determined that there is no possibility of fraud in the credit payment, the information processing unit 150 terminates processing (i.e., permits continued use of the credit card).

[0063] On the other hand, if it is determined that there is a possibility of fraud in the credit card payment, the authentication unit 156 performs identity verification of the user of the credit card payment (S204). If identity verification is successful, the information processing unit 150 terminates processing. On the other hand, if identity verification fails, the authentication unit 156 outputs information indicating that identity verification failed to, for example, to the terminal device of the credit card issuing company. This terminates the processing in this flowchart.

[0064] According to the embodiment described above, when a user makes a credit card payment at a credit card merchant, the system obtains credit card payment information that has been authorized by a predetermined fraud detection function, and determines whether or not there is a possibility of fraud in the credit card payment after a predetermined period has passed since the acquisition of the credit card payment information. This makes it possible to prevent fraudulent use of credit cards and to suppress the costs incurred in preventing such fraud.

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

[0066] 10. User terminal device 20 Payment Apps 22 Browser apps 100 Payment Servers 120 Content Provision Department 130 Payment Processing Unit 140 Information Management Department 150 Information Processing Unit 200 Merchant Shopping Servers 300 authorization servers

Claims

1. A credit card payment information is transmitted when a user makes a credit card payment using a credit card at a credit card merchant, and the acquisition unit acquires credit card payment information for which the credit card payment has been authorized by a predetermined fraud detection function. The system includes a determination unit that determines whether or not there is a possibility of fraud in the credit payment after a predetermined period following the acquisition of the credit payment information. Information processing device.

2. The aforementioned credit payment information includes the payment amount, payment time, and information about the merchant for the aforementioned credit payment. The aforementioned predetermined fraud detection function determines whether or not to permit the credit payment based on the credit payment information. The information processing apparatus according to claim 1.

3. The determination unit determines whether or not there is a possibility of fraud in the credit payment, based on the credit card payment history and the user's attribute information, in addition to the credit payment information. The information processing apparatus according to claim 2.

4. The aforementioned fraud detection function further includes the user authentication function, The determination unit determines whether or not there is a possibility of fraud in a credit card payment for which the identity authentication function was not performed. The information processing apparatus according to claim 1.

5. The aforementioned user authentication function is an SMS authentication method in which, when the credit payment is executed, an SMS (Short Message Service) notification containing a one-time password is sent to the user terminal device of the user who has been registered in advance, and the user terminal device is asked to input the one-time password. The information processing apparatus according to claim 4.

6. If the determination unit determines that there is a possibility of fraud in the credit payment, the system further includes an authentication unit that performs authentication of the user for the credit payment. The information processing apparatus according to claim 1.

7. The authentication unit changes the method of identity authentication according to the degree of the likelihood of fraud determined by the determination unit. The information processing apparatus according to claim 6.

8. Computers Credit card payment information transmitted when a user makes a credit card payment using a credit card at a credit card merchant, and credit card payment information that has been authorized by a predetermined fraud detection function is obtained. After a predetermined period following the acquisition of the aforementioned credit payment information, a determination is made as to whether or not there is a possibility of fraud in the aforementioned credit payment. Information processing methods.

9. On the computer, Credit card payment information transmitted when a user makes a credit card payment using a credit card at a credit card merchant, and the system obtains credit card payment information for which the credit card payment has been authorized by a predetermined fraud detection function. After a predetermined period following the acquisition of the aforementioned credit payment information, a determination is made as to whether or not there is a possibility of fraud in the aforementioned credit payment. program.

10. An authentication server that, upon receiving credit card payment information transmitted when a user makes a credit card payment using a credit card at a credit card merchant, uses a predetermined fraud detection function to determine whether or not to authorize the credit card payment. The system includes an information processing device that obtains credit card payment information for which the credit card payment has been authorized, and determines whether or not there is a possibility of fraud in the credit card payment after a predetermined period has elapsed since the acquisition of the credit card payment information, system.

Images