Credit card payment management system, credit card payment management device, interoperable system, credit card payment management method, and program

The credit payment management system dynamically adjusts authentication methods based on user status, optimizing the authentication process and reducing costs by shifting from SMS to app authentication, addressing the inflexibility of conventional methods.

JP7858123B1Active Publication Date: 2026-05-13PAYPAY CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2025188989
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2025-11-10
Publication Date
2026-05-13
Estimated Expiration
2045-11-10

AI Technical Summary

Technical Problem

Conventional credit card authentication methods are inflexible and do not adapt to the user's status, leading to inefficiencies and increased operational costs, particularly with SMS authentication.

Method used

A credit payment management system that dynamically adjusts authentication methods based on user information, allowing for flexible switching between options such as app authentication and SMS, and incorporates real-time risk scoring to optimize the authentication process.

Benefits of technology

Enhances usability and reduces operational costs by providing an optimal authentication experience tailored to the user's status, promoting a shift from costly SMS to low-cost app authentication and improving engagement.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007858123000001_ABST
    Figure 0007858123000001_ABST
Patent Text Reader

Abstract

Flexible switching of authentication methods depending on the user's status. [Solution] A credit card payment management system for managing payments by credit card, comprising: an information management unit that manages information of credit card users using a storage unit; and an authentication processing unit that, when it receives notification from an electronic payment service management device provided by a business other than the credit card business operator that the user has registered the credit card as a means of payment for an electronic payment service provided by a business other than the credit card business operator, sends back a list of authentication methods to the management device, wherein the authentication processing unit changes the list of authentication methods according to the user information stored in the storage unit.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0004] , , , , ,

[0005] , , ,

[0003] , , ,

[0001] The present invention relates to a credit settlement management system, a credit settlement management device, a cooperation system, a credit settlement management method, and a program.

Background Art

[0002] Conventionally, there has been disclosed an invention of an authentication system that transmits an encrypted one-time password including a user's location method to the user's email address, and performs authentication by comparing the location information transmitted from the user's terminal device again with the location information used as the basis for encryption.

Prior Art Document

Patent Document

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the conventional technology, there has been a delivery cost when transmitting an email or a short message to the user's terminal device. In recent years, a method of performing authentication mainly by an application program (cooperation application) provided in relation to a credit card service has also been adopted, but even in that case, consideration has not been given to changing the authentication method proposed according to the usage status of the cooperation application. Thus, in the conventional technology, there are cases where the authentication method cannot be flexibly switched according to the user's state.

[0005] The present invention has been made in consideration of such circumstances, and one of the objects is to provide a credit settlement management system, a credit settlement management device, a cooperation system, a credit settlement management method, and a program capable of flexibly switching the authentication method according to the user's state. [[ID=

[0006] One aspect of the present invention is a credit payment management system for managing payments by credit card, comprising: an information management unit that manages information of credit card users using a storage unit; and an authentication processing unit that, when it receives notification from an electronic payment service management device provided by a business other than the credit card business operator that the user has performed an operation to register the credit card as a means of payment for an electronic payment service provided by a business other than the credit card business operator, sends back a list of authentication methods to the management device, wherein the authentication processing unit modifies the list of authentication methods according to the user information stored in the storage unit. [Effects of the Invention]

[0007] According to one aspect of the present invention, the authentication method can be flexibly switched depending on the user's status. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the basic forms of in-store electronic payment. [Figure 2] This diagram shows an example of a configuration for performing electronic payments (terminal payments) using a payment app. [Figure 3] This figure shows an example of the contents of user information 172. [Figure 4] This diagram shows an example of the contents of merchant / store information 174. [Figure 5] This diagram shows an overview of the processing flow when a user scan is performed. [Figure 6] This diagram shows an overview of the processing flow when a store scan is performed. [Figure 7] This diagram shows an example of a configuration for performing electronic payments (card payments) using payment cards. [Figure 8] This figure shows an example of the contents of card user information 272. [Figure 9]This figure shows an example of a configuration related to provisioning. [Figure 10] This figure shows an example of screen transitions related to provisioning. [Figure 11] This is a sequence diagram showing an example of the processing flow related to provisioning. [Figure 12] This figure shows an example of the relationship between the list of authentication methods and the interface screen IF1-3. [Figure 13] This figure shows an image of the list of authentication methods and another example of its relationship to the interface screen IF1-3. [Modes for carrying out the invention]

[0009] [overview] The following describes embodiments of the credit payment management system, credit payment management device, interoperability system, credit payment management method, and program according to the present invention, with reference to the drawings. The credit payment management system is implemented by one or more processors. The credit payment management system includes at least the credit card server described below. The credit payment management device includes exclusively the credit card server. The application program, payment server, and credit card server cooperate to provide an electronic payment service (first electronic payment service). In the following description, the application program will be referred to as a 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. The 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 the virtual store, the system is controlled to transition 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 electronic payment when a purchase is made at a store is mainly made between the user and the merchant. Alternatively, electronic payment may be made between the user and the store.

[0010] [Types of in-store electronic payment methods] Figure 1 shows a basic configuration of in-store electronic payment. Basically, electronic payment is executed by three parties: a medium M held by the user U, store equipment E, and a payment system S. The medium M is a portable computer device such as a smartphone or a credit card. Store equipment E is located in a physical store (hereinafter simply referred to as "store") in the real world and includes POS devices, wireless communication devices, credit card readers, printed materials with code images such as QR codes (registered trademarks), or display devices that show code images. In in-store electronic payment, first, user identification information and payment amount information are shared unidirectionally or bidirectionally between the medium M and the store equipment E. During this process, one of the medium M or store equipment E optically reads various information from the code image displayed by the other, provides information via NFC (Near Field Communication), or reads the PAN (Primary Account Number) by a credit card reader. Then, one of the medium M or store equipment E (the one that received information from the other) transmits the payment information necessary for payment to the payment system S via the network NW. Furthermore, both the medium M and the store equipment E may transmit some information to the payment system S. The payment system S manages various information of the user U and performs electronic payments between the store and the user U in various ways. Electronic payments are made using either a prepaid system or a post-paid system, or both, or by other methods. In addition, electronic payments may also include forms of so-called online shopping, which are performed by both the user's terminal device and the payment system. The network NW includes, for example, the internet, LAN (Local Area Network), wireless base stations, and provider equipment. Various devices that communicate via the network NW, as described later, are assumed to have communication devices such as network cards and wireless communication modules.

[0011] [Configuration (Terminal Payment)] FIG. 2 is a diagram showing an example of a configuration for performing electronic payment (terminal payment) using a payment application. This electronic payment is executed centering around a payment application 20 operating on a user terminal device 10 which is one of the media M, one or more store payment terminals 30 which are one of the store facilities E, one or more store code images 40, a payment server 100 which constitutes part of the payment system S, and the like. The payment server 100 communicates with the user terminal device 10, the store payment terminals 30, and one or more information terminals 50 via a network NW.

[0012] 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 1, the payment application 20 is executed by a processor such as a CPU, and operates to provide an electronic payment service to the user in cooperation with the payment server 100. The payment application 20 is installed in the user terminal device 10 from, for example, an application distribution server (not shown), and controls the camera, communication device, touch panel, etc. of the user terminal device 10. In the following description, there may be a mixture of cases described as "transmitting information to the user terminal device 10 (or receiving / acquiring information from the user terminal device 10)" and cases described as "transmitting information to the payment application 20 (or receiving / acquiring information from the payment application 20)", but these are only differences in expression and are not intended to distinguish anything.

[0013] The store payment terminal 30 is installed, for example, in a store. The store payment terminal 30 is a computer device (or an aggregate thereof) having at least a commodity price acquisition function, an optical reading function, a program execution function, and a communication function. The store payment terminal 30 includes a so-called POS (Point of Sale) device, and the POS device may have a commodity price acquisition function or an optical reading function.

[0014] The store code image 40 is placed in the store and is a code image such as a QR code (registered trademark) printed on a medium such as paper or plastic. Note that the store code image 40 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone or a tablet terminal).

[0015] The information terminal 50 is used by the operator of the franchise that oversees the store. In an electronic payment service, a customer as a provider of goods or services is treated as a franchise (brand), and there are one or more stores under its umbrella. There may be a franchise that operates only one store. The information terminal 50 is a smartphone, a tablet terminal, a personal computer, or the like. The information terminal 50 operates a franchise interface 55. The franchise interface 55 may be a franchise application or a web page displayed by a general-purpose browser. The franchise interface 55 accepts settings of coupons, etc. by the operator of the franchise and transmits them to the payment server 100. The information terminal 50 may have a function of displaying a code image corresponding to the store code image 40 or reading a code image displayed by the user terminal device 10 by executing the franchise interface 55 (in the latter case, an optical reading function is required).

[0016] The payment server 100 communicates with the credit card server 200 via the network NW. The payment server 100 has, for example, a content providing unit 110, an information management unit 120, a payment processing unit 130, and a storage unit 170. Components other than 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 are LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable The program may be implemented by hardware (including circuitry) such as a Gate Array or a GPU (Graphics Processing Unit), or by the collaboration 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 a drive device.

[0017] 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 and merchant / store information 174.

[0018] The content provider unit 110, 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 110 provides content to the user terminal device 10 in the form of a web page, or provides the user terminal device 10 with parameters necessary for the payment application 20 to render images.

[0019] The Information Management Department 120 edits, adds, and deletes user information 172 and merchant / store information 174, and manages these.

[0020] Figure 3 shows an example of the contents of User Information 172. User Information 172 is a collection of information such as User URL, Account ID, Phone Number, Password, Registration Date, Charge Balance, Electronic Money Type, Terminal Payment Method, Credit Card Information, Various History Information, Identity Verification Flag, Name, Address, Date of Birth, Email Address, Bank Account, Postpay Settings, and Postpay Conditions Information, all of which are linked to each other. Hereafter, the instance of a user (electronic payment account) to which this information is linked may be referred to as an account. In the figure, items indicated by "-" indicate that they are not set.

[0021] The user URL is used for processing transfers between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100. The registration date is the date the user registered for the electronic payment service (the date the account was created). The charge balance is information indicating the balance of electronic money set by the user sending money to their account in advance. Transfer methods include depositing money into an ATM (Automatic Teller Machine) of a designated company (bank) and transferring money from a registered bank account. The type of electronic money indicates, for example, whether the electronic money can be withdrawn or can only be used for electronic payments. The terminal payment method is setting information indicating whether the user will make an electronic payment using the charge balance (balance payment) or a deferred payment in terminal payments. Credit card information is information such as the credit card number that will be the fund source (payment source) in the case of "deferred payment" described later. Various types of transaction history information include charge history, which shows the history of users sending money to electronic payment services in advance to increase their balance, and payment history, which shows the details of each transaction made by the user (date and time, store ID of the store where the purchase was made, merchant ID, payment amount, payment method, etc.).

[0022] The "Verified" flag indicates whether the user has completed identity verification using an identification document. Post-payment is only available if identity verification is complete and a credit card is registered. The user with account ID "002" in the diagram has not completed identity verification and therefore can only select balance payment as their terminal payment method. The bank account is the account number of a bank account into which funds can be deposited for the electronic payment service. The "Post-payment Settings" indicates whether the settings necessary to enable post-payment have been completed. The "Post-payment Conditions" information shows various conditions for post-payment, such as the limit and the current month's usage amount.

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

[0024] The payment processing unit 130 performs various processes for electronic payment. There are two methods for terminal payment, which are described below: the first method (user scan) and the second method (store scan).

[0025] Figure 5 shows an overview of the processing flow when a user scan is performed. First, the user terminal device 10, with the payment application 20 running, reads and decodes the store code image 40 using its optical reading function (S1). The store code image 40 contains information about the store URL. The payment application 20 sends first payment information, including the store URL and the user's account ID, to the payment server 100 (S2). The payment server 100 searches for merchant / store information 174 using 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 payment application 20 on the screen where the merchant name and store name are displayed (S5). Then, the payment application 20 generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6).

[0026] The payment processing unit 130 of the payment server 100 performs electronic payment based on the received second payment information if the "terminal payment method" in the user information 172 of the user is set to "balance payment" (S7-1). At this time, the payment processing unit 130 performs electronic payment by, for example, decreasing the charge balance managed in association with the user ID and increasing the item value of the merchant's sales proceeds. The item value of the merchant's sales proceeds is not used as electronic money itself, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service. On the other hand, if the "terminal payment method" is set to "post-payment", the payment processing unit 130 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S7-2). The credit card server 200 performs electronic payment by adding the payment amount to the user's monthly usage amount based on the received information and deducting the monthly usage amount from the user's bank account after the closing date (S7-3).

[0027] Then, the payment processing unit 130 sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 via the content provision unit 110 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 40 is displayed on a display placed in the store, the store code image 40 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.

[0028] Figure 6 shows an overview of the processing flow when a store scan is performed. First, 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 processing unit 130 of 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 store payment terminal 30, and the store payment terminal 30 reads and decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the store payment terminal 30 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). Payment amount information is obtained in advance through methods such as barcode scanning or manual entry.

[0029] The payment processing unit 130 of the payment server 100 identifies the user corresponding to the one-time code based on the received information, and if the "terminal payment method" in the user information 172 of that user is set to "balance payment", it performs electronic payment based on the received second payment information (S17-1). The content of the processing at this time is the same as the processing in S7-1 in Figure 5. On the other hand, if the "terminal payment method" is set to "post-payment", the payment server 100 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S17-2). The credit card server 200 adds the payment amount to the user's monthly usage amount based on the received information and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date (S17-3).

[0030] Then, the payment processing unit 130 sends a payment completion notification to the payment application 20 via the content provision unit 110 (S18), and the payment application 20 displays a payment completion screen (S19).

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

[0032] Furthermore, instead of managing the "post-payment" settlement through the credit card server 200, it may be handled internally by the payment server 100. In this case, the configuration of the payment card 60, credit card server 200, etc., may be omitted.

[0033] [Configuration (Card Payment)] Figure 7 shows an example of a configuration for electronic payment (card payment) using a payment card. This electronic payment is executed around a payment card 60, which is one of the media Ms; a credit processing terminal 70, which is one of the store equipment Es; and a payment server 100 and a credit card server 200, which constitute part of the payment system S. The credit card server 200 communicates with the credit processing terminal 70 via a network NW.

[0034] The credit processing terminal 70 is installed in the store, similar to the store payment terminal 30. The credit processing terminal 70 includes, for example, a credit payment terminal (credit card reader) and a POS device. The credit payment terminal reads the PIN (Personal Identification Number) from the inserted or scanned credit card and verifies it against the PIN entered by the user, or transmits the PAN (Primary Account Number) read from the credit card to the credit card server 200 via the POS device. The POS device works with the credit payment terminal to transmit information such as the payment amount to the credit card server 200. An acquisitioner server may be interposed between the credit processing terminal 70 and the credit card server 200, but for the sake of simplicity, the description of the acquisitioner server will be omitted below. The payment card 60 is, for example, similar in form to a commonly used credit card, with a communication chip embedded in the card base material. The communication chip contains a storage medium that stores the PIN and communicates with an external device via a contactor (or wireless antenna). Alternatively, the payment card 60 may be a magnetic stripe card. Note that the information (messages) transmitted and received when using a credit card includes an authorization message for authentication and a sales message to convey the payment amount; however, a detailed explanation distinguishing between these will be omitted below.

[0035] The credit card server 200 communicates with the settlement server 100 via a network NW. The credit card server 200 includes, for example, an information management unit 210, a credit interface 220, a settlement distribution unit 230, a credit settlement processing unit 240, an authentication processing unit 250, and a storage unit 270. Components other than the storage unit 270 are implemented, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted in a drive device. The storage unit 270 stores information such as card user information 272.

[0036] The information management unit 210 edits, adds, and deletes card user information 272 and manages it. Figure 8 shows an example of the contents of card user information 272. Card user information 272 is information that associates, for example, information unique to the user (e.g., PAN), identity verification information (name, address, contact information, etc.), the user's membership type, and, if the user is an app member (see below), the account ID in the electronic payment service (used by the payment server 100) and the card payment method with each other. Among the users of the payment card 60, there are users who are not members of the electronic payment service provided using the payment app 20 and the payment server 100. Hereinafter, such users will be referred to as non-app members, and users who are members of the electronic payment service will be referred to as app members. Since the owner of the payment app 20 is synonymous with a member of the electronic payment service, it is also defined that app members own the payment app 20, and non-app members do not own the payment app 20. The payment app 20 is an example of a "linked app" in the claims. Furthermore, the linked app is not limited to application programs related to electronic payment services provided by separate businesses that link electronic payment services and credit card services, but may also be application programs provided by businesses that only provide credit card services to provide services related to credit card services. In addition, the linked app may be an application program provided by a business that provides electronic payment services where the use of the app is not mandatory (a business different from the business that provides credit cards) to provide services related to electronic payment services. In these cases, since there may be users who have an account (for credit card services or electronic payment services) but do not use the app, "non-app members" may be defined as users who do not use the linked app. In that case, information indicating whether or not the linked app is being used is obtained by reading from the card user information 272 or by querying the linked service. The card payment method is setting information that indicates whether the user makes an electronic payment using the charged balance (balance payment) or a deferred payment in card payments.Card user information 272 is an example of "user information" in the claims.

[0037] The credit interface 220 determines whether the BIN (Bank Identification Number) in the PAN included in the message received from the credit processing terminal 70 is a code for the company. If it is a code for the company, it passes the message received from the credit processing terminal 70 to the settlement distribution unit 230. If it is not a code for the company, it discards the received message.

[0038] The settlement distribution unit 230 refers to the user's card user information 272 corresponding to the message obtained from the credit interface 220 and determines whether the "card payment method" is set to "post-payment". If the "card payment method" is set to "post-payment", the settlement distribution unit 230 notifies the credit interface 220 of this and passes the message obtained from the credit interface 220 to the credit payment processing unit 240. On the other hand, if the "card payment method" is set to "balance payment", the settlement distribution unit 230 adds the user's account ID to the message obtained from the credit interface 220 and sends it to the settlement server 100 to request electronic payment. The settlement server 100, upon receiving the request for electronic payment, performs the same processing as in S7-1 in Figure 5 and S17-1 in Figure 6.

[0039] Alternatively, when the credit card server 200 receives payment information from the payment card 60, if the account ID of the electronic payment service corresponding to the user-specific information included in the payment information is registered, the credit card payment may be processed in the following manner: (1) First, the payment information is transmitted to the payment server 100; (2) The payment server 100 determines whether it is a "post-payment" or "balance payment"; (3) If it is a "post-payment," the payment information is returned to the credit card server 200, and the credit card server 200 processes the payment; if it is a "balance payment," the payment server 100 processes the payment, such as deducting from the charge balance, and returns the result to the credit card server 200. In either case, by allowing the user to select the "card payment method," they can freely decide whether to pay by credit card or by balance payment of the linked electronic payment service.

[0040] The credit interface 220 also checks the PAN and expiration date, and verifies whether the cumulative payment amount exceeds the monthly limit. The credit payment processing unit 230 adds the payment amount to the user's monthly usage amount based on the information contained in the message obtained from the credit interface 220, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date.

[0041] [Provisioning process] The following describes the provisioning process, which is mainly performed by the credit card server 200. Figure 9 shows an example of a configuration related to provisioning. The terminal device 90 is a terminal device used by a user, and may be the same as or different from the user terminal device 10 on which the payment application 20 is installed. The management device 300 is a management device for the second electronic payment service. The second electronic payment service is an electronic payment service provided by a different business operator than the business operator of the first electronic payment service provided using the payment application 20 and the payment server 100, and is provided by a business operator other than the credit card business operator. The second electronic payment service may broadly include so-called e-commerce (shopping, auctions, flea markets, etc.), or it may include electronic payments exclusively using code images or NFC. The credit card server 200 and the management device 300 together are an example of the "cooperation system" in the claims. Furthermore, some of the processing of the credit card server 200 related to provisioning, which will be described below, may be shared by the payment server 100. In other words, the "credit payment management system" in the claims may include not only the credit card server 200 but also the payment server 100.

[0042] Payments using payment card 60 can be registered as a payment method (fund source) for the second electronic payment service. In this case, the user operates terminal device 90 to input various information such as the PAN of payment card 60 into the interface screen provided by management device 300 and applies for registration. The interface screen provided by management device 300 may be a screen provided by a browser or a screen provided by a dedicated application. The credit card server 200 receives notification from management device 300 that the user has performed the operation to register payment card 60 as a payment method for the second electronic payment service. When the authentication processing unit 250 receives this notification, it returns a list of authentication methods to management device 300. This will be explained below.

[0043] Figure 10 shows an example of screen transitions related to provisioning. Here, terminal device 90 is the same as user terminal device 10, and the interface screen provided by management device 300 is the screen provided by the dedicated application. In the figure, IF1-1 to IF1-3 are interface screens provided by management device 300, and IF2 is the interface screen of payment application 20. First, a user who is applying for provisioning (hereinafter simply referred to as "user") operates terminal device 90 to display interface screen IF1-1. When the user performs the operation to add a credit card on interface screen IF1-1, interface screen IF1-2 is displayed. On interface screen IF1-2, the user enters various credit card information (including at least the card number, and may include some or all of the following: name, address, expiration date, security code, etc.).

[0044] Next, for example, (1) an interface screen (not shown) requesting agreement to the terms of service is displayed, and when the user agrees, (2) a notification is sent from the management device 300 to the credit card server 200 indicating that a provisioning registration application has been received. The credit card server 200 sends a list of authentication information to the management device 300. Based on the list of authentication information, the management device 300 displays interface screen IF1-3 on the terminal device 90. In the diagram, "AAA" is the logo of the business group that operates the payment server 100 and the credit card server 200. When "AAA app" is selected (app authentication is selected), the credit card service mini-app in the payment app 20 is launched via deep link, which launches the payment app 20 and starts accessing the credit card server 200. If the terminal device 90 and the user terminal device 10 are different, information that app authentication has been selected may be first transmitted to the credit card server 200 via the management device 300, and the credit card server 200 may remotely launch the payment app 20.

[0045] The payment application 20 activates the authentication function (such as facial recognition, fingerprint recognition, or passcode recognition) held by the terminal device 90 in response to instructions from the credit card server 200, and notifies the credit card server 200 if authentication is successful. Subsequently, the credit card server 200 and the management device 300 share the information that authentication was successful, and provisioning is completed. Note that the source, destination, and order of information communication from the start to the completion of authentication may be changed as appropriate.

[0046] Figure 11 is a sequence diagram showing an example of the processing flow related to provisioning. First, as shown in Figure 10, the user performs an operation to add a credit card to the terminal device 90 (S100), enters various credit card information (S102), and performs an operation to agree to the terms of service (S104). Information from these operations is entered into the management device 300. The management device sends a notification to the credit card server 200 that a provisioning registration application has been received and requests the transmission of a list of authentication information using an API or the like (S106). The credit card server 200 refers to the card user information 272 to determine the contents of the list of authentication information and sends it back to the management device 300 (S108). Based on the list of authentication information, the management device 300 displays the interface screen IF1-3 described above on the terminal device 90 (S110). Here, it is assumed that app authentication is selected. In response to the user's operation, the payment app 20 is launched on the terminal device 90 (S112), and the user is authenticated using a method specific to the terminal device 90 (S114). If authentication is successful, the terminal device 90 sends information indicating successful authentication to the credit card server 200 (S116). Subsequently, information sharing for provisioning takes place between the management device 300 and the credit card server 200. After S110, if an authentication method other than app authentication is selected, the authentication process is performed using the selected authentication method.

[0047] The following describes the process for determining the contents of the authentication information list and related screen transitions. The authentication processing unit 250 refers to the card user information 272 stored in the storage unit 270 and changes the authentication method list based on whether or not the user has a linked application (in this case, a payment application 20) that works with credit card services.

[0048] Figure 12 shows an example of the relationship between the list of authentication methods and the interface screen IF1-3. The list of authentication methods includes information such as the name, authentication code, display text to be shown on the interface screen IF1-3, and necessary links for each authentication method. For example, the authentication processing unit 250 includes app authentication in the list of authentication information if the user is an app member, and does not include app authentication in the list of authentication information if the user is not an app member. As a result, as shown in the lower part of Figure 12, app authentication is not displayed as an option for authentication methods on the interface screen IF1-3.

[0049] Figure 13 shows an image of the list of authentication methods and another example of its relationship with the interface screen IF1-3. In this example, the authentication processing unit 250 includes app authentication in the list of authentication information whether the user is an app member or not, and the display text for users who are not app members includes text indicating that they will be redirected to the download screen of the payment app 20, such as "The download page will open." If a user who is not an app member selects app authentication, the terminal device 90 displays the download screen of the payment app 20 via a deep link, rather than the payment app 20 itself.

[0050] These processes allow the credit card server 200 to flexibly switch authentication methods depending on the user's status. While SMS authentication was previously the dominant method, the increasing number of provisioned items resulted in continuous SMS delivery costs, which represented a direct operational cost burden for businesses. Furthermore, SMS authentication required users to perform multiple steps, making it cumbersome, and there was a risk of reception delays or failures depending on the communication environment. This could potentially contribute to users abandoning the card setup process.

[0051] Furthermore, providing a uniform interface that does not take into account the user's status can lead to inefficiencies such as presenting unnecessary options to non-app users, causing confusion, and failing to provide an optimal authentication experience for app users. In contrast, this embodiment allows for flexible switching of authentication methods according to the user's status by changing the list of authentication methods according to the card user information 272. This improves the usability of the authentication process while simultaneously promoting a shift from costly SMS authentication to low-cost app authentication, thereby achieving cost reductions.

[0052] In the above embodiment, the authentication method may be dynamically changed by scoring the risk of fraudulent use in real time based on the user's usage status and modifying the list of authentication information according to that score. For example, the authentication method may be switched to app authentication only, with the addition of SMS authentication, or by enforcing step-up authentication.

[0053] Furthermore, the engagement level of the payment app 20, such as its usage frequency, can be evaluated. For heavy users whose engagement level exceeds a threshold, the authentication method selection screen can be omitted, and they can be directly transitioned to app authentication, thereby providing the ultimate seamless experience.

[0054] Furthermore, when a non-app member applies for provisioning, a notification (email or SMS) containing information about the convenience and benefits of the payment app 20 may be automatically sent to that non-app member. This allows for encouraging migration to the app at the optimal time when interest in the service is high.

[0055] Furthermore, if authentication using one method fails, the system may automatically switch to another authentication method. For example, if app authentication fails, the system may detect the reason and immediately suggest an alternative method such as SMS authentication. In addition, the system may learn from failure patterns and prioritize suggesting authentication methods that are less likely to fail in the future.

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

[0057] U User E. Store facilities M medium S Payment System 10. User terminal device 20 Payment Apps 30 Store Payment Terminals 40 Store Code Images 60 Payment Cards 70 Credit card processing terminal 90 Terminal devices 100 Payment Servers 130 Payment Processing Unit 200 credit card servers 210 Information Management Department 250 Authentication Processing Unit 272 Cardholder Information 300 Management device

Claims

1. A credit card payment management system for managing payments made by credit card, An information management unit that manages the information of the credit card user using a memory unit, An authentication processing unit, upon receiving notification from the management device of the electronic payment service provided by the other business operator that a user has registered the credit card as a means of payment for an electronic payment service provided by a business operator other than the credit card business operator, returns a list of authentication methods to the management device. Equipped with, The authentication processing unit refers to the user information stored in the storage unit and modifies the list of authentication methods based on whether or not the user possesses a linked application that works with the credit card service. Credit card payment management system.

2. The authentication processing unit, If the user possesses a linked app that works in conjunction with the credit card service, the authentication method initiated by the linked app shall be included in the list of authentication methods. If the user does not possess a linked app that works with the credit card service, the authentication method initiated by the linked app will not be included in the list of authentication methods. The credit payment management system according to claim 1.

3. The authentication processing unit, Whether or not the user possesses a linked app that works in conjunction with the credit card service, the authentication method initiated by the linked app shall be included in the list of authentication methods. If the user does not possess a linked app that works with the credit card service, the display text included in the list of authentication methods shall include a message indicating that if the user selects an authentication method led by the linked app, they will be redirected to the app's download screen. The credit payment management system according to claim 1.

4. A credit card payment management device that manages payments made by credit card, An information management unit that manages the information of the credit card user using a memory unit, An authentication processing unit, upon receiving notification from the management device of the electronic payment service provided by the other business operator that a user has registered the credit card as a means of payment for an electronic payment service provided by a business operator other than the credit card business operator, returns a list of authentication methods to the management device. Equipped with, The authentication processing unit refers to the user information stored in the storage unit and modifies the list of authentication methods based on whether or not the user possesses a linked application that works with the credit card service. Credit card payment management device.

5. The credit payment management system according to claim 1, The aforementioned control device, A collaborative system equipped with these features.

6. A credit card payment management system that manages payments made by credit card, The memory unit is used to manage the information of the credit card user, When notification is received from the management device of the electronic payment service provided by the other business operator that the user has registered the credit card as a means of payment for an electronic payment service provided by the other business operator, the system returns a list of authentication methods to the management device. The system refers to the user information stored in the storage unit and modifies the list of authentication methods based on whether or not the user possesses a linked application that works with the credit card service. Credit card payment management methods.

7. The processor in the credit payment management system that manages credit card payments, The memory unit is used to manage the information of the credit card user. When notification is received from the management device of the electronic payment service provided by the other business operator that the user has registered the credit card as a means of payment for an electronic payment service provided by the other business operator, the management device is instructed to return a list of authentication methods to the management device. The system references the user information stored in the memory unit and modifies the list of authentication methods based on whether or not the user possesses a linked application that works with the credit card service. A program for that purpose.