Payment management server, payment management method, and program

Abstract

To provide an online settlement service without using a credit card.SOLUTION: The payment management server includes a token issuing unit that transmits a token associated with a consumer and a seller to a seller device used by the seller, a first receiving unit that receives a withdrawal request for a purchase price and the token from the seller device when the consumer purchases a product or a service from the seller, and a first fund transfer unit that executes processing for transferring at least a part of the purchase price from an account of the consumer to an account of a payment service provider when the received token is associated with the consumer and the seller. And a second fund transfer means for executing processing for transferring at least a part of the purchase price.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] JP 2003-518305 A (Patent Document 1) is a document disclosing background art in this technical field. This publication states that "the instant payment system for credit card member stores according to the present invention comprises a branch office dedicated server connected to a branch office, a bank dedicated server connected to a bank company, a withdrawal information server, a bank dedicated server connected to a bank, a card dedicated server connected to a credit card company, a settlement dedicated server, and an inquiry processing server that manages a history database, a member database, and a banking database, and is characterized by the following: the server is connected to a plurality of credit card member store terminals, and manages information on transactions made at credit card member stores; the server is connected to a bank, and controls withdrawals to settle the amount immediately to the credit card member store when a transaction is made at a credit card member store; and the server is connected to a credit card company via the bank company, and checks whether card use is approved and collects the amount immediately" (see abstract). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2003-518305 Summary of the Invention [Problem to be solved by the invention]

[0004] The above publication describes a payment system using a credit card. However, some consumers do not want to use credit cards or do not own credit cards at all. An online payment service for such consumers is desired. The present invention has been made in view of such circumstances, and provides an online payment service that does not require the use of a credit card. [Means for solving the problem]

[0005] In order to solve the above problems, for example, the configurations described in the claims are adopted. The present application includes multiple means for solving the above problem, and one example is a payment management server having: a token issuing means for sending a token associated with a consumer and a seller to a seller device used by the seller; a first accepting means for accepting a request to debit the purchase price and the token from the seller device when the consumer purchases a product or service from the seller; a first funds transfer means for executing a process to transfer at least a portion of the purchase price from the consumer's account to the account of a payment service provider when the accepted token is associated with the consumer and the seller; and a second funds transfer means for executing a process to transfer at least a portion of the purchase price from the account of the payment service provider to the seller's account. [Effects of the Invention]

[0006] According to the present invention, it is possible to provide an online payment service that does not require a credit card. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example of a business model according to an embodiment. [Figure 2]FIG. 2 shows an example of the configuration of a payment system 200. [Figure 3] FIG. 3 shows an example of the configuration of the payment management server 201. [Figure 4] FIG. 4 shows an example of the configuration of the payment server 202. [Figure 5] FIG. 5 shows an example of the configuration of the user device 203. [Figure 6] FIG. 6 shows an example of the configuration of the affiliated store server 204. [Figure 7] FIG. 7 shows an example of user information 700. [Figure 8] FIG. 8 shows an example of affiliated store information 800. [Figure 9] FIG. 9 shows an example of token information 900. [Figure 10] FIG. 10 shows an example of a user-initiated payment process. [Figure 11] FIG. 11 shows an example of the payment method (1) "token issuance and immediate deduction." [Figure 12] FIG. 12 shows an example of the payment method (1) "token issuance and immediate deduction." [Figure 13] FIG. 13 shows an example of the payment method (2) "token issued, no immediate deduction." [Figure 14] FIG. 14 shows an example of the payment method (2) "Token issued, no immediate deduction." [Figure 15] FIG. 15 shows an example of the payment method (3) "no token issuance, immediate deduction." [Figure 16] FIG. 16 shows an example of the payment method (3) "no token issuance, immediate deduction." [Figure 17] FIG. 17 shows an example of (4) "authentication and payment each time." [Figure 18] FIG. 18 shows an example of (4) "authentication and payment each time." [Figure 19] FIG. 19 shows an example of a payment process initiated by a service member store. [Figure 20] FIG. 20 shows an example of a processing flow for debiting. [Figure 21]FIG. 21 shows an example of the payment method selection screen. [Figure 22] FIG. 22 shows an example of a login / sign-in screen. [Figure 23] FIG. 23 shows an example of the payment / linking completion screen. DETAILED DESCRIPTION OF THE INVENTION

[0008] 1. Example Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0009] Overview This embodiment provides an online payment service that does not require a credit card, which has the following advantages: Online businesses can attract cash-preferring users. Users can pay for online services directly from their bank accounts. -It can handle not only one-time payments like e-commerce, but also subscription payments. - By having the payment service provider perform personal authentication of the consumer, the service member store does not have to go through the trouble of performing personal authentication. When setting up payments from a bank account for a new service, users do not need to go through the bank's approval process each time, and can register payments with simple authentication (such as facial recognition). When online businesses receive payments from multiple banks, they do not need to connect their systems to each bank; they can simply connect to a payment service provider and handle payments from multiple banks.

[0010] FIG. 1 shows an example of a business model according to this embodiment. In the business model 100 shown in the figure, first, a consumer 101 authorizes a payment service provider 102 to debit his / her bank account (S1). Then, the consumer 101 purchases a product or service from a service member store 103. In this case, the service member store 103 transfers a trade receivable for the purchase price to the payment service provider 102 (S2). In return, the payment service provider 102 pays the purchase price to the service member store 103 after deducting a handling fee (S3).

[0011] The payment service provider 102 that has acquired the trade receivable transfers the acquired trade receivable to the settlement agent 104 (S4). In return, the payment service provider 102 receives payment of the purchase price, minus a handling fee, from the settlement agent 104 (S5).

[0012] The settlement agent 104, who has acquired the sales credit, withdraws the purchase price from the bank account of the consumer 101 and collects the credit (S6).

[0013] In this embodiment, the following three payment methods are assumed. (1) Recurring billing This is a payment method in which a consumer authorizes the use of this payment service to make payments to service affiliated stores only once, and subsequent payments are made without the consumer's presence. This payment method is intended for subscription payments, for example.

[0014] (2) One-Click Pay This is a payment method in which a consumer authorizes the use of this payment service to make payments to a service member store only once, and no additional authentication is required for subsequent payments. This payment method is intended for e-commerce payments, for example.

[0015] (3) One-time authentication payment This is a payment method that requires user authentication for all payments. This payment method is intended for, for example, e-commerce payments (especially payments for high-value or rare products).

[0016] 1-2.Configuration FIG. 2 shows an example of the configuration of a payment system 200 according to this embodiment. The payment system 200 shown in the figure includes a payment management server 201, a payment server 202, multiple user devices 203, and multiple affiliated store servers 204. Each device is connected via a wired or wireless network and can send and receive information via the network.

[0017] Here, the payment management server 201 is a server managed by a payment service provider, and provides an online payment service that does not require a credit card. The settlement server 202 is a server managed by a settlement agent. When a user registers, the settlement server 202 receives a comprehensive withdrawal request between the user and the service provider from the registration module 321, performs various authentications, and then issues a unique bank access key that enables withdrawal from the user's account. When a payment is made, the settlement server 202 receives a request from the settlement management server 201 and transfers the purchase amount from the consumer's bank account to the bank account of the settlement service provider.

[0018] Each of the plurality of user devices 203 is an information processing device used by a consumer. The multiple member store servers 204 are servers managed by respective service member stores. Note that the service member stores referred to here are businesses that are members of the online payment service provided by the payment service provider.

[0019] Each device constituting the payment system 200 may be, for example, a portable terminal (mobile terminal) such as a smartphone, tablet, mobile phone, or personal digital assistant (PDA), or a wearable terminal such as glasses, a wristwatch, or clothing. Each device may also be a stationary or portable computer, or a server located on the cloud or a network. Each device may also function as a VR (Virtual Reality) terminal, an AR (Augmented Reality) terminal, or an MR (Mixed Reality) terminal. Alternatively, a combination of multiple of these terminals may be used. For example, a combination of one smartphone and one wearable terminal may logically function as a single terminal. Other information processing terminals may also be used.

[0020] Each device includes a processor that executes an operating system, applications, programs, etc., a main storage device such as RAM (Random Access Memory), an auxiliary storage device such as an IC card, hard disk drive, SSD (Solid State Drive), flash memory, etc., a communication control unit such as a network card, wireless communication module, or mobile communication module, an input device such as a touch panel, keyboard, mouse, voice input, or input based on motion detection captured by a camera unit, and an output device such as a monitor or display. The output device may also be a device or terminal that transmits information to be output to an external monitor, display, printer, or device.

[0021] The main memory stores various programs, applications, etc. (modules), and the processor executes these programs and applications to realize the various functional elements of the overall system. These modules may be implemented in hardware, such as by integration. Each module may be an independent program or application, or may be implemented as a subprogram or function within a single integrated program or application.

[0022] In this specification, each module is described as a subject that performs processing, but in reality, the processing is performed by a processor that processes various programs, applications, etc. (modules). Various databases (DBs) are stored in the auxiliary storage device. A "database" is a functional element (storage unit) that stores a set of data so that it can accommodate any data manipulation (e.g., extraction, addition, deletion, overwriting, etc.) from a processor or an external computer. There are no limitations on how the database is implemented; for example, it can be a database management system, spreadsheet software, or a text file such as XML or JSON.

[0023] 1-2-1. Payment management server 201 FIG. 3 shows an example of the configuration of the payment management server 201. The payment management server 201 is configured, for example, by one or more servers arranged on the cloud.

[0024] The server's main memory device 301 stores programs and applications such as a UI module 310, a first receiving module 311, a second receiving module 312, a first authentication module 313, a second authentication module 314, a determination module 315, a third authentication module 316, a token issuing module 317, a first funds transfer module 318, a second funds transfer module 319, a cookie generation module 320, and a registration module 321. These programs and applications are executed by the processor 303 to realize the various functional elements of the payment management server 201. Each module will be described below.

[0025] The UI module 310 provides various screens to the user device 203 . When a consumer purchases a product or service from a service member store, the first reception module 311 receives a login request from the user device 203 used by the consumer.

[0026] When a consumer purchases a product or service from a service member store, the second accepting module 312 accepts a withdrawal request for the purchase price from the member store server 204 used by the service member store. At that time, if a token is included in the withdrawal request, the module verifies the token. Specifically, the module references token information 900 (described below) to determine whether the holder of the token matches the sender of the withdrawal request. If the result of this determination is that the two match, the first funds transfer module 318 performs processing based on the withdrawal request.

[0027] The first authentication module 313 performs passkey authentication for the consumer. This passkey authentication is an authentication method using public key cryptography. The specific procedure is as follows:

[0028] <Registration flow> (1) The server sends the client a random string (challenge) that is used only in that flow. (2) The client creates a public key pair within the device. (3) The client stores the passkey (FIDO authentication credentials including the private key) in a secure area within the device. When generating the FIDO authentication credentials, the client performs user authentication (fingerprint authentication, face authentication, PIN, etc.) within the device. (4) The client sends the public key, the challenge, and the signature data to the server. (5) The server verifies the challenge and signature data using the received public key. (6) If the verification is successful, the server associates the public key with the user account and stores it.

[0029] <Authentication flow> (1) The server sends the client a random string (challenge) that is used only in that flow. (2) The client selects a passkey associated with the user account. (3) The client signs the challenge with the private key contained in the passkey and sends it to the server. When signing, the user is authenticated on the device (using fingerprint authentication, face authentication, PIN, etc.). (4) The server verifies the received signature data using the stored public key. (5) If the verification is successful, the server considers the authentication successful.

[0030] With this passkey authentication, users do not need to remember passwords. In addition, it is difficult for a third party to spoof, reducing the threat of phishing and man-in-the-middle attacks. Furthermore, because passwords are not stored on the server side, the risk of password leaks on the provider side can be avoided.

[0031] The second authentication module 314 performs SMS authentication on the consumer. This SMS authentication is an authentication method using short messages. Specifically, the server first sends a short message to the client. The sent short message contains an authentication code, such as a string of numbers. The user then enters the notified authentication code into a web page. If the entered authentication code matches the notified one, authentication is successful.

[0032] The determination module 315 determines whether eKYC authentication is required. Specifically, this module determines that eKYC authentication is required when the execution of eKYC authentication is requested in the withdrawal request received from the affiliated store server 204 and when the purchase price is a predetermined amount (e.g., 10,000 yen) or more.

[0033] The third authentication module 316 performs eKYC authentication for the consumer. This eKYC authentication is an authentication method using an identity verification document such as a driver's license. Specifically, the client first sends the user's identity verification document, personal information (IC chip information or manually entered information), and a combination of facial images (in accordance with the method stipulated in the Act on Prevention of Transfer of Criminal Proceeds) to the server. Note that the identity verification document referred to here is an identity verification document with a photograph, such as a driver's license, My Number card, or passport. The determination method follows the method stipulated in the Act on Prevention of Transfer of Criminal Proceeds, and if the consistency of the various documents is confirmed, the authentication is determined to be successful.

[0034] The token issuance module 317 issues a token to the affiliated store server 204 when a withdrawal request is received from the affiliated store server 204, the payment method is recurring billing or one-click pay, and a token has not yet been issued. The issued token consists of a random string of characters and is used as authentication information. Each token is linked to a specific consumer and service affiliated store, and the service affiliated store linked to the token (i.e., the token holder) can request a withdrawal from the bank account of the consumer linked to the token. The token is activated after necessary user authentication, and an activation notification is sent to the affiliated store server 204.

[0035] The first funds transfer module 318 executes a funds transfer process when a withdrawal request is received from the affiliated store server 204 and various user authentications are successful. This funds transfer process involves deducting the purchase price from the consumer's bank account and transferring the remaining amount, minus the payment agent's fee, to the payment service provider's bank account. In performing this process, the module generates a payment message instructing these fund transfers and sends it to the payment server 202. The payment server 202 receives this payment message and executes the above-mentioned fund transfer.

[0036] If the withdrawal request includes a token, the module withdraws the purchase price from the consumer's bank account linked to the token.

[0037] After executing the above-mentioned fund transfer process, the module notifies the user device 203 used by the consumer and the affiliated store server 204 that the payment for the purchase price to the service affiliated store has been completed.

[0038] The second funds transfer module 319 transfers the purchase amount, minus the payment service provider's fee, from the consumer's bank account to the payment service provider's bank account. This process is executed on a preset date (e.g., the 15th of each month). The second funds transfer module 319 may perform the funds transfer process via the settlement server 202 or may perform it directly.

[0039] The cookie generation module 320 generates a session cookie and sends it to the user device 203 when the user device 203 accesses the payment management server 201. This session cookie is, so to speak, history information that indicates the usage history of the payment service. Whether or not this session cookie is present determines whether SMS authentication and passkey authentication are required for the consumer. Specifically, if a valid session cookie is stored in the user cookie 520 when a login request is accepted from the user device 203, SMS authentication and passkey authentication for the consumer are omitted.

[0040] The registration module 321 executes the new consumer registration process. Specifically, this module displays various input screens on the user device 203 and registers the input information as user information. After the user inputs their bank information, the payment service provider issues a comprehensive transfer authorization using the coordination method specified by each bank. If successful, a unique bank access key for the user's bank account required for debiting is issued and saved in the user information.

[0041] Next, we will explain the auxiliary storage device 302 of the payment management server 201. The auxiliary storage device 302 stores user information 700, affiliated store information 800, token information 900, payment history DB 320, and the like.

[0042] Of these, user information 700 is information about consumers. Figure 7 shows an example of this user information 700. The user information 700 shown in the figure includes a user ID, financial institution, branch name, account type, account number, account holder name, gender, date of birth, email address, and unique bank access key. This user information 700 is configured such that values ​​such as those shown in sample values ​​730 are associated with each field name 720. This user information 700 is registered by the registration module 321 .

[0043] Member store information 800 is information about service member stores. Figure 8 shows an example of this member store information 800. The member store information 800 shown in the figure includes a member store ID, financial institution, branch name, account type, account number, account holder name, member store name, and email address. This member store information 800 is configured by associating each field name 820 with a value such as that shown in sample value 830.

[0044] Token information 900 is information that indicates the correspondence between tokens, consumers, and service affiliated stores. FIG. 9 shows an example of this token information 900. The token information 900 shown in the figure includes a token, a user ID, an affiliated store ID, and a token status. This token information 900 is configured such that values ​​such as those shown in sample values ​​930 are associated with each field name 920. This token information 900 is registered by the token issuing module 317 .

[0045] The payment history DB 320 is a database for recording the success or failure of payments. A payment ID is issued when a withdrawal request is made from the member store server 204 to the payment management server 201. The payment history DB 320 manages information indicating the success or failure of the payment in association with the payment ID.

[0046] Next, the chargeback function of the settlement management server 201 will be described. This chargeback function is a function for refunding money to consumers in the event of fraudulent payments or defective services. The payment management server 201 accepts reports of fraudulent payments or defective services from consumers via an inquiry form, and if the reported fraud is confirmed, the payment management server 201 will carry out refund procedures for the consumer.

[0047] 1-2-2. Payment server 202 FIG. 4 shows an example of the configuration of the payment server 202. The payment server 202 is configured, for example, by one or more servers arranged on the cloud. The main memory device 401 of the payment server 202 stores programs and applications such as a payment module 410. The processor 403 executes these programs and applications to realize the respective functional elements of the payment server 202.

[0048] The payment module 410 of the payment server 202 receives the payment message sent from the payment management server 201 and executes the fund transfer. Specifically, the module debits the specified purchase amount from the specified consumer's bank account and transfers the amount, minus the payment agent's commission, to the bank account of the specified payment service provider.

[0049] The payment message 420 is temporarily stored in the auxiliary storage device 402 of the payment server 202 .

[0050] 1-2-3. User device 203 FIG. 5 shows an example of the configuration of the user device 203. The user device 203 is, for example, a terminal device such as a smartphone, a tablet terminal, a notebook PC, or a desktop PC. Programs and applications such as a browser module 510 are stored in the main memory device 501 of the user device 203. The processor 503 executes these programs and applications to realize the various functional elements of the user device 203.

[0051] The browser module 510 of the user device 203 communicates with the payment management server 201 and the affiliated store server 204, obtains a screen in response to the user's operation, and displays it on the display. The auxiliary storage device 502 of the user device 203 stores a cookie 520 provided by the payment management server 201 .

[0052] 1-2-4. Affiliated store server 204 FIG. 6 shows an example of the configuration of the affiliated store server 204. The affiliated store server 204 is configured, for example, by one or more servers deployed on the cloud. The main memory device 601 of the affiliated store server 204 stores programs and applications such as a UI module 610 and a withdrawal request module 611. The processor 603 executes these programs and applications to realize each functional element of the affiliated store server 204.

[0053] The UI module 610 of the affiliated store server 204 provides various screens to the user device 203. On the other hand, when the consumer selects the payment service according to this embodiment as the payment method, the debit request module 611 generates a debit request and sends it to the payment management server 201. The debit request sent includes the following information:

[0054] Token (if a token has already been issued for the associated user) (Optional) Flag for specifying one-time authentication payment (if not specified, it is determined not to be one-time authentication payment) Withdrawal details (amount and currency) Redirect URL (for success and failure) (not required for merchant-initiated payments) (Optional) Expiration time (default is 90 minutes, so optional) (Optional) User registration information (Optional) Forced execution flag for eKYC authentication (Optional) Free use items of service member stores

[0055] OAuth2.0 is used when sending a withdrawal request to the settlement management server 201. Specifically, the withdrawal request is sent in the following procedure. (1) The affiliated store server 204 sends an authorization token issuance request to the authorization server, and if the request is approved, an access token is issued. The authorization token can be used for a predetermined time (for example, one hour). (2) The affiliated store server 204 sends a withdrawal request to the payment management server 201 together with the authorization token. (3) The settlement management server 201 inquires of the authorization server about the validity of the received authorization token, and if the authorization token is valid, accepts the withdrawal request.

[0056] The auxiliary storage device 602 of the affiliated store server 204 stores various screen data 620 provided to the user device 203 and a token 621 provided by the payment management server 201.

[0057] 1-3.Operation Next, the payment process executed in the payment system 200 will be described. First, the user-initiated payment process will be described, and then the service member store-initiated payment process will be described.

[0058] 1-3-1. User-driven payment processing 10 to 18 show an example of a user-initiated payment process. First, in step 1001 of Figure 10, a consumer selects a payment method when purchasing a product or service at a service member store. At that time, a payment method selection screen is displayed on the user device 203 used by the consumer. This payment method selection screen is provided by the member store server 204 managed by the service member store.

[0059] An example of this payment method selection screen is shown in Figure 21. Screen 2100 shown in the figure displays multiple selectable payment methods 2101 to 2108. When the payment service according to this embodiment ("this payment service") is selected, the subsequent payment process begins.

[0060] When "This payment service" is selected on the above screen, the withdrawal request module 611 of the affiliated store server 204 generates a withdrawal request and sends it to the payment management server 201. The sent withdrawal request is accepted by the second acceptance module 312 of the payment management server 201 (step 1002).

[0061] The second reception module 312 determines the payment method based on the received withdrawal request (step 1003). The determined payment method is one of the following four types of payment methods. (1) Payment method with "token issuance and immediate deduction" (2) Payment method: "Token issuance, no immediate withdrawal" (3) Payment method: "No token issuance, immediate withdrawal" (4) "One-time authentication payment"

[0062] If the withdrawal request contains the following information, the module determines that the payment method is (1) "token issuance, immediate withdrawal." Withdrawal details (amount and currency) Redirect URLs (for success and failure) (Optional items are omitted.)

[0063] If the withdrawal request contains the following information, the module determines that the payment method is (2) "token issuance, no immediate withdrawal." Redirect URLs (for success and failure) (Optional items are omitted.)

[0064] If the withdrawal request contains the following information, the module determines that the payment method is (3) "no token issuance, immediate withdrawal." ·token Withdrawal details (amount and currency) Redirect URLs (for success and failure) (Optional items are omitted.)

[0065] If the withdrawal request contains the following information, the module determines that it is (4) "authenticated payment each time." - One-time authentication payment specification flag Withdrawal details (amount and currency) Redirect URLs (for success and failure) (Optional items are omitted.)

[0066] Incidentally, in the case of subscription payments with immediate deduction, the first time the service is used, the payment method (1) "token issuance with immediate deduction" is used. From the second time onwards, the service member store-led payment process, which will be described later, is used.

[0067] For subscription payments without immediate deduction, the first time the service is used, payment method (2) "Token issued, no immediate deduction" will be used. From the second time onwards, payment processing initiated by the service member store, which will be described later, will be used.

[0068] This is a one-click pay service, and the first time you use it, the payment method (1) "token issued, immediate deduction" will be used. From the second time onwards, the payment method (3) "no token issued, immediate deduction" will be used.

[0069] For one-time authentication payments, (4) "One-time authentication payment" is used.

[0070] Next, the (1) "token issuance and immediate deduction" payment method (step 1004) will be described. Figures 11 and 12 show an example of the processing flow of this payment method.

[0071] In flow 1100 shown in the figure, first, a redirect URL and a token are issued to the affiliated store. At this point, the token is not yet validated (step 1101). The user device 203 is redirected to the redirect URL shared by the payment service provider with the service affiliated store (step 1102). As a result, a login / sign-in screen is displayed on the user device 203.

[0072] An example of this login / sign-in screen is shown in Fig. 22. A screen 2200 shown in the figure includes a new registration button 2201 and a login button 2202.

[0073] When the new registration button 2201 is selected on this screen 2200 (YES in step 1103), the registration module 321 of the payment management server 201 executes new registration processing. Specifically, the module displays various input screens on the user device 203 and registers the input information as user information (step 1104). Note that passkey authentication registration, SMS authentication, and eKYC authentication may also be executed during the new registration processing.

[0074] When the login button 2202 is selected on the above screen 2200 (NO in step 1103 ), the browser module 510 of the user device 203 sends a login request to the payment management server 201 .

[0075] When a login request is received, the first reception module 311 of the payment management server 201 checks the user cookie 520 and determines whether a valid session cookie is stored (step 1105). If the result of this determination is that a valid session cookie is not stored (NO in step 1105), the second authentication module 314 performs SMS authentication on the consumer (step 1106). Furthermore, the first authentication module 313 performs passkey authentication on the consumer (step 1107). If these authentications are successful, the consumer is permitted to log in. On the other hand, if any of these authentications fail, the consumer's login is denied.

[0076] If the result of the determination in step 1105 above is that a valid session cookie is stored (YES in step 1105), that is, if the login is from the same device and the same browser, SMS authentication and passkey authentication are omitted.

[0077] Next, the UI module 310 displays a token authentication screen (not shown) on the user device 203 (step 1108). When the authentication button is selected on this token authentication screen, the first authentication module 313 performs passkey authentication for the consumer. If this passkey authentication fails (NO in step 1109), the process proceeds to step 1124, which will be described later. On the other hand, if this passkey authentication is successful (YES in step 1109), the determination module 315 then determines whether eKYC authentication is required. At that time, the module determines that eKYC authentication is required if the withdrawal request includes a forced execution flag for eKYC authentication, or if the purchase price is a predetermined amount (e.g., 10,000 yen) or more.

[0078] If this determination shows that eKYC authentication is required (YES in step 1110), the third authentication module 316 performs eKYC authentication on the consumer (step 1111). If the authentication fails (NO in step 1112), the module sends a payment failure message to the affiliated store server 204 (step 1113) and a payment failure email to the user device 203 (step 1114). On the other hand, if the authentication is successful (YES in step 1112), the module determines whether the authentication was completed within the payment valid time (step 1115). The payment valid time here is determined based on the expiration time specified in the withdrawal request.

[0079] If the result of this determination is that the authentication was not completed within the payment valid time (NO in step 1115), the module sends a payment failure message to the affiliated store server 204 (step 1116) and sends a payment failure email to the user device 203 (step 1117).

[0080] On the other hand, if the determination result shows that the authentication was completed within the valid settlement time (YES in step 1115), the first funds transfer module 318 generates a settlement message instructing the funds transfer and sends it to the settlement server 202 (step 1118). As a result of this process, the purchase price is debited from the consumer's bank account, and the amount obtained by deducting the settlement agent's fee from the debited purchase price is credited to the bank account of the settlement service provider. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0081] If the fund transfer fails (NO in step 1119), the module sends a payment failure message to the affiliated store server 204 (step 1116) and sends a payment failure email to the user device 203 (step 1117).

[0082] On the other hand, if the fund transfer is successful (YES in step 1119), the first fund transfer module 318 sends a payment success message and a token validation notification to the affiliated store server 204 (step 1120), and sends a payment completion email to the user device 203 (step 1121). The message sent to the affiliated store server 204 includes a notification of validation of the token issued by the token issuance module 317.

[0083] If the result of the determination in step 1110 above is that eKYC authentication is not required (NO in step 1110), the first funds transfer module 318 generates a payment message instructing the funds transfer and sends it to the payment server 202 (step 1122). As a result of this process, the purchase price is deducted from the consumer's bank account, and the amount obtained by deducting the payment agent's fee from the deducted purchase price is transferred to the payment service provider's bank account. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0084] If the fund transfer fails (NO in step 1123), the module sends a payment failure message to the affiliated store server 204 (step 1124) and redirects the user device 203 to a URL for failure (step 1125). On the other hand, if the fund transfer is successful (YES in step 1123), the module displays a payment and linkage completion screen on the user device 203 (step 1126), sends a payment success message and a token activation notification to the affiliated store server 204 (step 1127), and redirects the user device 203 to a URL for success (step 1128).

[0085] An example of the payment / linking completion screen is shown in Fig. 23. The screen 2300 shown in the figure displays the withdrawal transaction ID, affiliated store ID, affiliated store name, account information, and withdrawal amount. This concludes the explanation of the (1) "token issuance, immediate deduction" payment method.

[0086] Next, the (2) "token issued, no immediate withdrawal" payment method (step 1005) will be described. Figures 13 and 14 show an example of the processing flow of this payment method.

[0087] In flow 1300 shown in the figure, first, a redirect URL and a token are issued to the affiliated store. At this point, the token is not yet validated (step 1301). The user device 203 is redirected to the redirect URL shared by the payment service provider with the service affiliated store (step 1302). As a result, a login / sign-in screen is displayed on the user device 203. An example of this login / sign-in screen is shown in FIG. 22.

[0088] 22 (YES in step 1303), the registration module 321 of the payment management server 201 executes new registration processing. Specifically, the module displays various input screens on the user device 203 and registers the input information as user information (step 1304). Note that passkey authentication registration, SMS authentication, and eKYC authentication may also be performed during the new registration processing.

[0089] When the login button 2202 is selected on the above screen 2200 (NO in step 1303 ), the browser module 510 of the user device 203 sends a login request to the payment management server 201 .

[0090] When a login request is received, the first reception module 311 of the payment management server 201 checks the user cookie 520 and determines whether a valid session cookie is stored (step 1305). If the result of this determination is that a valid session cookie is not stored (NO in step 1305), the second authentication module 314 performs SMS authentication on the consumer (step 1306). Furthermore, the first authentication module 313 performs passkey authentication on the consumer (step 1307). If these authentications are successful, the consumer is permitted to log in. On the other hand, if any of these authentications fail, the consumer's login is denied.

[0091] If the result of the determination in step 1305 above is that a valid session cookie is stored (YES in step 1305), that is, if the login is from the same device and the same browser, SMS authentication and passkey authentication are omitted.

[0092] Next, the UI module 310 displays a token authentication screen (not shown) on the user device 203 (step 1308). When the authentication button is selected on this token authentication screen, the first authentication module 313 performs passkey authentication for the consumer. If this passkey authentication fails (NO in step 1309), the module sends a payment failure message to the affiliated store server 204 (step 1320) and redirects the user device 203 to a failure URL (step 1321).

[0093] On the other hand, if the passkey authentication is successful (YES in step 1309), the determination module 315 then determines whether eKYC authentication is required (step 1310). At that time, the module determines that eKYC authentication is required if the withdrawal request includes a forced execution flag for eKYC authentication or if the purchase price is a predetermined amount (e.g., 10,000 yen) or more.

[0094] If this determination shows that eKYC authentication is required (YES in step 1310), the third authentication module 316 performs eKYC authentication on the consumer (step 1311). If the authentication fails (NO in step 1312), the module sends a linkage failure message to the affiliated store server 204 (step 1313) and sends a linkage failure email to the user device 203 (step 1314). On the other hand, if the authentication is successful (YES in step 1312), the module sends an activation notification of the token issued by the token issuance module 317 to the affiliated store server 204 (step 1315) and sends a linkage completion email to the user device 203 (step 1316).

[0095] If the result of the determination in step 1310 above is that eKYC authentication is not required (NO in step 1310), the UI module 310 displays a link completion screen (not shown) on the user device 203 (step 1317). In addition, the token issuance module 317 sends a token validation notification to the affiliated store server 204 (step 1318). Then, the user device 203 is redirected to a success URL (step 1319). This concludes the explanation of the (2) “token issuance, no immediate deduction” payment method.

[0096] Next, the (3) "no token issuance, immediate deduction" payment method (step 1006) will be described. Figures 15 and 16 show an example of the processing flow of this payment method.

[0097] In flow 1500 shown in the figure, first, the user device 203 is redirected to a redirect URL shared by the payment service provider with the service member store (step 1501). As a result, a login / sign-in screen is displayed on the user device 203. An example of this login / sign-in screen is shown in FIG. 22. In the case of this payment method, since the new registration process has already been completed, the new registration button 2201 may be omitted from the screen 2200 shown in FIG.

[0098] When the login button 2202 is selected on the screen 2200 shown in FIG. 22, the browser module 510 of the user device 203 sends a login request to the payment management server 201.

[0099] When a login request is received, the first reception module 311 of the payment management server 201 checks the user cookie 520 and determines whether a valid session cookie is stored (step 1502). If the result of this determination is that a valid session cookie is not stored (NO in step 1502), the second authentication module 314 performs SMS authentication on the consumer (step 1503). Furthermore, the first authentication module 313 performs passkey authentication on the consumer (step 1504). If these authentications are successful, the consumer is permitted to log in. On the other hand, if any of these authentications fail, the consumer's login is denied.

[0100] If the result of the determination in step 1502 above is that a valid session cookie is stored (YES in step 1502), that is, if the login is from the same device and the same browser, SMS authentication and passkey authentication are omitted.

[0101] Next, the payment management server 201 determines whether the holder of the token included in the withdrawal request matches the sender of the withdrawal request (step 1505). In doing so, the payment management server 201 references the affiliated store information 800 and the token information 900. If the result of this determination is that the token holder and the sender do not match, or the token is invalid (NO in step 1505), step 1520, described below, is executed. On the other hand, if the result of this determination is that the token holder and the sender match (YES in step 1505), the determination module 315 then determines whether eKYC authentication is required (step 1506). In this case, the module determines that eKYC authentication is required if the withdrawal request includes a forced execution flag for eKYC authentication, or if the purchase price is equal to or greater than a predetermined amount (e.g., 10,000 yen).

[0102] If this determination indicates that eKYC authentication is required (YES in step 1506), the third authentication module 316 performs eKYC authentication on the consumer (step 1507). If the authentication fails (NO in step 1508), the module sends a payment failure message to the affiliated store server 204 (step 1509) and a payment failure email to the user device 203 (step 1510). On the other hand, if the authentication is successful (YES in step 1508), the module determines whether the authentication was completed within the payment valid time (step 1511). The payment valid time here is determined based on the expiration time specified in the withdrawal request.

[0103] If the result of this determination is that the authentication was not completed within the payment valid time (NO in step 1511), the module sends a payment failure message to the affiliated store server 204 (step 1512) and sends a payment failure email to the user device 203 (step 1513).

[0104] On the other hand, if the determination result shows that the authentication was completed within the valid settlement time (YES in step 1511), the first funds transfer module 318 generates a settlement message instructing the funds transfer and sends it to the settlement server 202 (step 1514). As a result of this process, the purchase price is debited from the consumer's bank account, and the amount obtained by deducting the settlement agent's fee from the debited purchase price is transferred to the bank account of the settlement service provider. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0105] If the fund transfer fails (NO in step 1515), the module sends a payment failure message to the affiliated store server 204 (step 1512) and sends a payment failure email to the user device 203 (step 1513).

[0106] On the other hand, if the first funds transfer module 318 succeeds in transferring funds (YES in step 1515), it sends a payment success message to the affiliated store server 204 (step 1516) and sends a payment completion email to the user device 203 (step 1517).

[0107] If the result of the determination in step 1506 above is that eKYC authentication is not required (NO in step 1506), the first funds transfer module 318 generates a payment message instructing the funds transfer and sends it to the payment server 202 (step 1518). As a result of this process, the purchase price is deducted from the consumer's bank account, and the amount remaining after deducting the payment agent's fee is deposited into the payment service provider's bank account. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0108] If the fund transfer fails (NO in step 1519), the module sends a payment failure message to the affiliated store server 204 (step 1520) and redirects the user device 203 to a URL for failure (step 1521). On the other hand, if the fund transfer is successful (YES in step 1519), the module displays a payment completion screen on the user device 203 (step 1522), sends a payment success message to the affiliated store server 204 (step 1523), and redirects the user device 203 to a URL for success (step 1524). An example of the payment completion screen is shown in FIG. This concludes the explanation of the (3) “no token issuance, immediate deduction” payment method.

[0109] Next, (4) "Payment with authentication each time" (step 1007) will be explained. Figures 17 and 18 show an example of the processing flow of this payment method.

[0110] In flow 1700 shown in the figure, first, the user device 203 is redirected to a redirect URL shared by the payment service provider with the service member store (step 1701). As a result, a login / sign-in screen is displayed on the user device 203. An example of this login / sign-in screen is shown in FIG. 22.

[0111] 22 (YES in step 1702), the registration module 321 of the payment management server 201 executes new registration processing. Specifically, the module displays various input screens on the user device 203 and registers the input information as user information (step 1703). Note that passkey authentication registration, SMS authentication, and eKYC authentication may also be performed during the new registration processing.

[0112] When the login button 2202 is selected on the above screen 2200 (NO in step 1702 ), the browser module 510 of the user device 203 sends a login request to the payment management server 201 .

[0113] When a login request is received, the first reception module 311 of the payment management server 201 checks the user cookie 520 and determines whether a valid session cookie is stored (step 1704). If the result of this determination is that a valid session cookie is not stored (NO in step 1704), the second authentication module 314 performs SMS authentication on the consumer (step 1705). Furthermore, the first authentication module 313 performs passkey authentication on the consumer (step 1706). If these authentications are successful, the consumer is permitted to log in. On the other hand, if any of these authentications fail, the consumer's login is denied.

[0114] If the result of the determination in step 1704 above is that a valid session cookie is stored (YES in step 1704), that is, if the login is from the same device and the same browser, SMS authentication and passkey authentication are omitted.

[0115] Next, the UI module 310 displays a payment authentication screen (not shown) on the user device 203 (step 1707). When the authentication button is selected on this token authentication screen, the first authentication module 313 performs passkey authentication for the consumer. If this passkey authentication fails (NO in step 1708), the process proceeds to step 1723, which will be described later. On the other hand, if this passkey authentication is successful (YES in step 1708), the determination module 315 then determines whether eKYC authentication is required (step 1709). At that time, the module determines that eKYC authentication is required if the withdrawal request includes a forced execution flag for eKYC authentication, or if the purchase price is equal to or greater than a predetermined amount (for example, 10,000 yen).

[0116] If this determination shows that eKYC authentication is required (YES in step 1709), the third authentication module 316 performs eKYC authentication on the consumer (step 1710). If the authentication fails (NO in step 1711), the module sends a payment failure message to the affiliated store server 204 (step 1712) and a payment failure email to the user device 203 (step 1713). On the other hand, if the authentication is successful (YES in step 1711), the module determines whether the authentication was completed within the payment valid time (step 1714). Note that the payment valid time here is determined based on the expiration time specified in the withdrawal request.

[0117] If the result of this determination is that the authentication was not completed within the payment valid time (NO in step 1714), the module sends a payment failure message to the affiliated store server 204 (step 1715) and sends a payment failure email to the user device 203 (step 1716).

[0118] On the other hand, if the determination result shows that the authentication was completed within the valid settlement time (YES in step 1714), the first funds transfer module 318 generates a settlement message instructing the funds transfer and sends it to the settlement server 202 (step 1717). As a result of this process, the purchase price is debited from the consumer's bank account, and the amount obtained by deducting the settlement agent's fee from the debited purchase price is transferred to the bank account of the settlement service provider. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0119] If the fund transfer fails (NO in step 1718), the module sends a payment failure message to the affiliated store server 204 (step 1715) and sends a payment failure email to the user device 203 (step 1716).

[0120] On the other hand, if the first funds transfer module 318 succeeds in transferring funds (YES in step 1718), it sends a payment success message to the affiliated store server 204 (step 1719) and sends a payment completion email to the user device 203 (step 1720).

[0121] If the result of the determination in step 1709 above is that eKYC authentication is not required (NO in step 1709), the first funds transfer module 318 generates a payment message instructing the funds transfer and sends it to the payment server 202 (step 1721). As a result of this process, the purchase price is deducted from the consumer's bank account, and the amount remaining after deducting the payment agent's fee is deposited into the payment service provider's bank account. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0122] If the fund transfer fails (NO in step 1722), the module sends a payment failure message to the affiliated store server 204 (step 1723) and redirects the user device 203 to a URL for failure (step 1724). On the other hand, if the fund transfer is successful (YES in step 1722), the module displays a payment completion screen on the user device 203 (step 1725), sends a payment success message to the affiliated store server 204 (step 1726), and redirects the user device 203 to a URL for success (step 1727). An example of the payment completion screen is shown in FIG. This concludes the explanation of (4) “Payment with authentication each time.”

[0123] 1-3-2. Merchant-led payment processing 19 and 20 show an example of a payment process initiated by a service member store. In this process 1900, first, the debit request module 611 of the affiliated store server 204 generates a debit request and sends it to the settlement management server 201. The sent debit request contains the following information: ·token Withdrawal details (amount and currency)

[0124] The transmitted withdrawal request is accepted by the second acceptance module 312 of the payment management server 201 (step 1901). As a result, the payment management server 201 executes the withdrawal (step 1902).

[0125] FIG. 20 shows an example of a debit processing flow to be executed. In flow 2000 shown in the figure, first, the payment management server 201 determines whether the holder of the token included in the debit request matches the sender of the debit request (step 2008). In doing so, the payment management server 201 references the affiliated store information 800 and the token information 900. As a result of this determination, if the token holder and the sender do not match or the token is invalid (NO in step 2008), step 2006, described below, is executed. On the other hand, if the result of this determination is that the token holder and the sender match (YES in step 2008), the determination module 315 then determines whether eKYC authentication is required (step 2001). In this case, the module determines that eKYC authentication is required if the purchase price is equal to or greater than a predetermined amount (e.g., 10,000 yen).

[0126] If the result of this determination is that eKYC authentication is required (YES in step 2001), the module sends an eKYC incompletion notification email to the user device 203 (step 2002), and sends a payment failure message to the affiliated store server 204 (step 2003). On the other hand, if the result of this determination is that eKYC authentication is not required (NO in step 2001), the first funds transfer module 318 generates a payment message instructing the transfer of funds and sends it to the payment server 202 (step 2004). As a result of this process, the purchase price is deducted from the consumer's bank account, and the amount remaining after deducting the payment agent's fee is deposited into the bank account of the payment service provider. The amount of the purchase price to be debited will be determined based on the debit details (amount and currency) specified in the debit request.

[0127] If the fund transfer fails (NO in step 2005), the module sends a payment failure message to the affiliated store server 204 (step 2006), and if the fund transfer is successful (YES in step 2005), the module sends a payment success message to the affiliated store server 204 (step 2007). This concludes the explanation of the service member store initiated payment processing 1900.

[0128] The above-described payment system 200 enables an online payment service that does not require a credit card. As described above, this payment service has the following advantages. Online businesses can attract cash-preferring users. Users can pay for online services directly from their bank accounts. -It can handle not only one-time payments like e-commerce, but also subscription payments. - By having the payment service provider perform personal authentication of the consumer, the service member store does not have to go through the trouble of performing personal authentication.

[0129] 2. Variations The above embodiment may be modified as follows: The following modifications may be combined with each other.

[0130] (1) Method of fund transfer In the above embodiment, the first funds transfer module 318 debits the purchase price from the consumer's bank account via the payment server 202. However, the use of the payment server 202 is not required. For example, the first funds transfer module 318 may directly execute the purchase price debit process. Such a process is also included in the process for transferring the purchase price from the consumer's bank account to the payment service provider's bank account.

[0131] (2) Account type In the above embodiment, bank accounts are assumed as the accounts of consumers, service affiliates, and payment service providers. However, bank accounts are merely an example, and accounts at other financial institutions (e.g., credit unions and credit associations) may also be used.

[0132] (3) Notification of fund transfer In the above embodiment, the second funds transfer module 319 may notify the service member store and the consumer involved in the funds transfer process of the completion of the settlement after completing its own funds transfer process. Note that the service member store and the consumer involved in the funds transfer process here refer to the service member store whose bank account the purchase price is deposited into and the consumer whose bank account the purchase price is debited from in the process.

[0133] (4) Types of certification In the above embodiment, eKYC authentication is performed when the purchase price exceeds a predetermined amount. However, eKYC authentication is merely one example of user authentication. If the legitimacy of the user can be guaranteed, other user authentication (for example, SMS authentication or passkey authentication) may be performed.

[0134] In the above embodiment, if a cookie is not included in the login request sent by the consumer, SMS authentication and passkey authentication are performed. However, these authentications are merely examples of user authentication. If the legitimacy of the user can be guaranteed, other user authentication (e.g., eKYC authentication) may also be performed.

[0135] (5) Certification body In the above embodiment, passkey authentication, SMS authentication, and eKYC authentication are performed by the payment management server 201. However, the execution entity of each type of authentication does not necessarily have to be the payment management server 201. These authentications may be outsourced to another authentication server.

[0136] (6) Method of fund transfer (part 2) In the above embodiment, all fund transfers from the consumer to the payment service provider are performed via the payment server 202. However, if the payment management server 201 can directly access the system of the bank where the consumer holds a bank account, fund transfers may be performed without going through the payment server 202. In this case, the first fund transfer module 318 of the payment management server 201 sends a payment message instructing the fund transfer to the system of the bank where the consumer holds a bank account. The bank system that receives the payment message carries out the instructed fund transfer. The first funds transfer module 318 determines, based on the consumer's bank account, whether to transfer funds via the settlement server 202 or by directly accessing the bank system.

[0137] (7) Other The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0138] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0139] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. The above-described embodiments disclose at least the configurations described in the claims. [Explanation of symbols]

[0140] 100... business model, 101... consumer, 102... payment service provider, 103... service affiliated store, 104... payment agent, 200... payment system, 201... payment management server, 202... payment server, 203... user device, 204... affiliated store server

Claims

1. A payment management server, a token issuing means for transmitting a token associated with a consumer and a seller to a seller device used by the seller; a first receiving means for receiving a withdrawal request for the purchase price and the token from the seller device when the consumer purchases a product or service from the seller; a first funds transfer means for executing a process to transfer at least a portion of the purchase price from the consumer's account to a payment service provider's account when the accepted token is associated with the consumer and the seller; a second funds transfer means for executing a process to transfer at least a portion of the purchase price from the payment service provider's account to the seller's account; A payment management server having the above configuration.

2. further comprising an authentication means for executing user authentication for the consumer when the purchase price is equal to or greater than a predetermined amount; the first funds transfer means, when the accepted token is associated with the consumer and the seller and the user authentication is successful, executes a process to transfer at least a portion of the purchase price from the consumer's account to an account of a payment service provider; The payment management server according to claim 1 .

3. authentication means for performing user authentication for said consumer; a second receiving means for receiving history information indicating a usage history of the payment service from the consumer device used by the consumer; and the first funds transfer means, when the accepted token is associated with the consumer and the seller and the history information is accepted from the consumer device, executes a process to transfer at least a portion of the purchase price from the consumer's account to the payment service provider's account without executing the user authentication; The payment management server according to claim 1 .

4. The payment management server of claim 1, wherein the first funds transfer means, after executing the processing, notifies the consumer device used by the consumer that payment of the purchase price to the seller has been completed.

5. 1. A computer-implemented method for managing payments, comprising: a token issuing step of transmitting a token associated with a consumer and a merchant to a merchant device used by the merchant; a first receiving step of receiving, from the seller device, a request for withdrawal of the purchase price and the token when the consumer purchases a product or service from the seller; a first funds transfer step of executing a process to transfer at least a portion of the purchase price from the consumer's account to a payment service provider's account if the accepted token is associated with the consumer and the seller; a second funds transfer step of executing a process to transfer at least a portion of the purchase price from the payment service provider's account to the seller's account; A payment management method including:

6. further comprising an authentication step of performing user authentication for the consumer if the purchase price is equal to or greater than a predetermined amount; the first funds transfer step is a step of executing a process to transfer at least a portion of the purchase price from the consumer's account to a payment service provider's account when the accepted token is associated with the consumer and the seller and the user authentication is successful; 6. The payment management method according to claim 5.

7. an authentication step for performing user authentication for the consumer; a second receiving step of receiving history information indicating a usage history of the payment service from the consumer device used by the consumer; further comprising the first fund transfer step is a step of executing a process to transfer at least a portion of the purchase price from the consumer's account to a payment service provider's account without performing the user authentication when the accepted token is associated with the consumer and the seller and the history information is accepted from the consumer device; 6. The payment management method according to claim 5.

8. 6. The payment management method of claim 5, wherein the first fund transfer step includes a step of notifying a consumer device used by the consumer that payment of the purchase price to the seller has been completed after executing the processing.

9. A program for causing a computer to execute each step of the settlement management method according to any one of claims 5 to 8.

Images