JP2020187589A - Information processing device, information processing method and program - Google Patents

Abstract

To provide a technique capable of improving convenience of settlement processing by an MPM.SOLUTION: An information processing device in a system that performs settlement by reading a predetermined code installed in a shop by an application installed in a user terminal used by a user who performs settlement, includes: a reception unit that receives a settlement request that designates a predetermined shop and one settlement business operator allowing a user to perform settlement processing among a plurality of settlement business operators from the user terminal used by the user who performs settlement at the predetermined shop; a request unit that requests settlement processing to a settlement execution device corresponding to the settlement business operator when the reception unit receives the settlement request; an acquisition unit that acquires a processing result of the settlement processing from the settlement execution device corresponding to the settlement business operator; and a notification unit that responds to the user terminal regarding the processing result of the settlement processing.SELECTED DRAWING: Figure 4

Description

The present invention relates to an information processing device, an information processing method and a program.

Currently, a large number of payment companies provide payment services using two-dimensional codes. When making a payment at a store, the user can start the application of the payment service to be used by operating the smartphone and make the payment by performing a predetermined operation.

There are two methods for payment services using two-dimensional codes. The first method is a method in which a two-dimensional code is displayed on the screen of the user's smartphone and the clerk reads the two-dimensional code at a POS cash register or the like. This method is called CPM (Consumer Presented Mode). The second method is a method in which the user's smartphone reads the two-dimensional code fixedly installed in the store. This method is called MPM (Merchant Presented Mode). Patent Document 1 discloses a payment service using a two-dimensional code.

Special Table 2016-522938

Currently, in 2D code payment by MPM, each payment operator provides a 2D code for payment. Therefore, a store that has contracts with a plurality of payment business operators needs to secure a space for installing the same number of two-dimensional codes as the number of contracted payment business operators. Further, the user who makes the payment needs to search for the two-dimensional code corresponding to the payment operator who makes the payment from the plurality of two-dimensional codes, which imposes a heavy burden on the user. There is also the risk that the user will accidentally read the two-dimensional code of a different payment provider. Therefore, the convenience of two-dimensional code payment by MPM is not high at present.

Therefore, an object of the present invention is to provide a technique capable of improving the convenience of payment processing by MPM.

The information processing device according to one aspect of the present invention is an information processing device in a system in which payment is made by reading a predetermined code installed in a store with an application installed in a user terminal used by a user who makes payment. A reception unit that receives a payment request that specifies one of a plurality of payment companies that executes payment processing and a predetermined store from a user terminal used by a user who makes a payment at a predetermined store. When the reception unit receives the payment request, the payment processing result is transmitted from the request unit that requests the payment processing to the payment execution device corresponding to the payment business operator and the payment execution device corresponding to the payment business operator. It has an acquisition unit for acquisition and a notification unit for responding to the processing result of payment processing to the user terminal.

According to the present invention, it is possible to provide a technique capable of improving the convenience of payment processing by MPM.

It is a figure which shows the system configuration example of the payment system which concerns on this embodiment. It is a figure which shows the service provision image of the 2D code settlement by MPM provided by this embodiment. It is a figure which shows the hardware configuration example of a common device. It is a figure which shows the functional block configuration example of a common device. It is a figure which shows an example of the settlement company information, store information, transaction key information and settlement history information. It is a sequence diagram which shows an example of the processing procedure performed by the payment system which concerns on this embodiment.

Embodiments of the present invention will be described with reference to the accompanying drawings. In each figure, those having the same reference numerals have the same or similar configurations.

<System configuration>
FIG. 1 is a diagram showing a system configuration example of the payment system 1 according to the present embodiment. The payment system 1 is a system that provides code payment by MPM. The code used for the code payment may be a one-dimensional code, a two-dimensional code, or a multidimensional code. In the present embodiment, for convenience, it will be described as a two-dimensional code.

The payment system 1 includes a user terminal 10, a store terminal 20, a common device 30 (information processing device), a payment device (Company A) 40-A, a payment device (Company B) 40-B, and a payment device ( Company Z) 40-Z and included. The user terminal 10, the store terminal 20, and the common device 30 are connected to each other via a wireless or wired communication network N1 and can communicate with each other. Further, the common device 30, the payment device (Company A) 40-A, the payment device (Company B) 40-B, and the payment device (Company Z) 40-Z are connected to each other via a wireless or wired communication network N2. Can be connected and communicate with each other.

In the following description, when the payment device (Company A) 40-A, the payment device (Company B) 40-B, and the payment device (Company Z) 40-Z are not distinguished, the payment device 40 (payment execution device) ). In FIG. 1, a payment device (Company A) 40-A, a payment device (Company B) 40-B, and a payment device (Company Z) 40-Z are shown, but the number of payment devices 40 is increased. There is no limit.

The user terminal 10 is a terminal used by a user who makes a payment for a product or service at a store. In the present embodiment, "payment" means not only the actual completion of withdrawal of money, electronic money, points, etc. and payment to the other party, but also money, electronic money, points, etc., such as payment by credit card. It also includes post-pay payments in which the withdrawal and / or payment to the other party is made after the fact. Further, the "store" is intended to be a store (that is, synonymous with a member store) in which payment (settlement) of consideration for the provision of goods and services performed at the store can be performed using the payment system 1. .. Further, the "store" may be an actual store or an online store existing on the Internet.

As the user terminal 10, any terminal having a communication function, such as a smartphone, a tablet terminal, a mobile phone, a personal computer (PC), a notebook PC, a mobile information terminal (PDA), and a home game device, should be used. Can be done. Although one user terminal 10 is shown in FIG. 1, there is no limit to the number of user terminals 10 included in the payment system 1.

The store terminal 20 is a terminal used by the store. For the store terminal 20, any terminal having a communication function, such as a smartphone, a tablet terminal, a mobile phone, a personal computer (PC), a notebook PC, a mobile information terminal (PDA), and a home game device, should be used. Can be done. Although one store terminal 20 is shown in FIG. 1, there is no limit to the number of store terminals 20 included in the payment system 1.

The common device 30 is a device that receives a payment request from a user terminal 10 of a user who receives a product or service at a store, and controls the appropriate payment device 40 to process the received payment request. The common device 30 may be composed of one or a plurality of physical servers or the like, or may be configured by using a virtual server operating on a hypervisor. The common device 30 is a device managed by a business operator different from the payment business operator related to the payment device 40.

The payment device 40 is a device for a payment business operator that provides a payment service using a two-dimensional code to perform payment processing. For example, the payment device (Company A) 40-A is a payment device 40 that processes a payment service provided by Company A. Similarly, the payment device (Company B) 40-B is a payment device 40 that processes a payment service provided by Company B. The two-dimensional code payment service referred to here is a payment service using an application, and in order to receive the payment service, the user uses the user terminal 10 of each application issued by each payment company. You need to install at least one. Further, the application referred to here may be one that can provide a plurality of service contents by using one application such as a web browser or an SNS application. In this case, each service content is the present embodiment. Corresponds to each application mentioned in. Hereinafter, the application is also referred to as a payment application.

The above-mentioned common device 30 causes the payment device (Company A) 40-A to process the payment request received from the user terminal 10 of the user when the user wishes to use the payment service provided by the company A. To control. Further, for example, when the user wishes to use the payment service provided by the company B, the payment device (company B) 40-B is controlled to process the payment request received from the user terminal 10 of the user. ..

FIG. 2 is a diagram showing an image of providing a payment service for a two-dimensional code by MPM provided by the present embodiment. As shown in FIG. 2A, conventionally, in the two-dimensional code payment by MPM, each payment business operator provides the one on which the two-dimensional code for the payment service is printed. Therefore, as shown in Fig. 2A, stores that have contracts with multiple payment business operators are installed with the same number of two-dimensional codes printed as the number of contracted payment business operators. It is necessary to secure an installation space for this. Further, the user needs to start an application corresponding to the payment service to be used on the user terminal 10 and use the application to read a two-dimensional code corresponding to the payment service to be used to make a payment. The payment service application is issued by each payment business operator corresponding to each payment device 40.

On the other hand, in the present embodiment, each payment operator does not provide a two-dimensional code for payment, but assigns a common two-dimensional code commonly used by each payment operator as shown in B of FIG. The distribution company prepares one common two-dimensional code issued and issued by the distribution company for each store. In addition, the common two-dimensional code should be readable by each application issued by the payment operator. As a result, the user can make a payment by starting an application corresponding to the payment service to be used on the user terminal 10 and reading the common two-dimensional code using the application. That is, by using an application corresponding to the payment service that the user wants to use, a common two-dimensional code different from the two-dimensional code that can be used only by the application can be read, and the payment of the payment service that the user wants to use can be settled without discomfort.

According to the present embodiment, even in a store having contracts with a plurality of payment operators, it is sufficient to prepare one having a common two-dimensional code printed on it. Since the user does not need to search for the two-dimensional code corresponding to the payment service he / she wants to use, the payment can be performed quickly. Further, regarding the installation of the one on which the two-dimensional code is printed, in the present embodiment, one one on which the common two-dimensional code is printed is prepared, but the present invention is not limited to this. For example, the common two-dimensional code may be displayed on a display unit such as a POS cash register. In this case, it is not necessary to separately install the one on which the common two-dimensional code is printed. Further, when displaying the common two-dimensional code on a display unit such as a POS cash register, it is possible to prevent a mistake in the type of the two-dimensional code to be displayed.

<Outline of operation>
Before executing payment, the common device 30 transmits / receives data to / from the user terminal in advance to confirm the validity of the common two-dimensional code installed in the store for the purpose of improving security. More specifically, the user terminal 10 transmits a message requesting confirmation of information about the store where the payment is made (hereinafter, referred to as "confirmation request" or "prior confirmation request message") to the common device 30. Upon receiving the confirmation request, the common device 30 transmits information (store name, store address, etc.) about the store to be settled to the user terminal 10. The user terminal 10 displays the information received from the common device 30 on the screen.

Subsequently, when the user instructs the execution of payment, the user terminal 10 transmits a message requesting execution of payment (hereinafter, referred to as "payment request" or "payment request message") to the common device 30. The common device 30 that has received the payment request requests the payment device 40 that processes the payment to execute the payment. When the common device 30 receives a notification from the payment device 40 that the payment has been completed, the common device 30 notifies the user terminal 10 that the payment has been completed.

When the common device 30 that has received the confirmation request transmits information about the store that makes the payment to the user terminal 10, a series of messages related to the payment process transmitted and received between the user terminal 10 and the common device 30 ( Information for associating a transaction) (hereinafter referred to as a "transaction key") may be transmitted to the user terminal 10. Further, when transmitting the payment request to the common device 30, the user terminal 10 may include the received transaction key in the payment request and transmit it.

Further, when the common device 30 receives the payment request, it confirms that the transaction key same as the transaction key transmitted to the user terminal 10 is included in the payment request, and when the confirmation is obtained, the common device 40 sends the payment device 40. It may be requested to execute the settlement.

<Hardware configuration>
FIG. 3 is a diagram showing a hardware configuration example of the common device 30. The common device 30 includes a processor 11 such as a CPU (Central Processing Unit) and a GPU (Graphical processing unit), a memory, a storage device 12 such as an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), and wired or wireless communication. It has a communication IF (Interface) 13, an input device 14 that accepts input operations, and an output device 15 that outputs information. The input device 14 is, for example, a keyboard, a touch panel, a mouse and / or a microphone. The output device 15 is, for example, a display and / or a speaker.

<Functional block configuration>
FIG. 4 is a diagram showing an example of a functional block configuration of the common device 30. The common device 30 includes a storage unit 100, a reception unit 101, an issue unit 102, an authentication unit 103, a request unit 104, an acquisition unit 105, and a notification unit 106. The storage unit 100 can be realized by using the storage device 12 included in the common device 30. Further, the reception unit 101, the issuing unit 102, the authentication unit 103, the request unit 104, the acquisition unit 105, and the notification unit 106 are the processors 11 of the common device 30, which store the programs stored in the storage device 12. It can be realized by executing it. In addition, the program can be stored in a storage medium. The storage medium in which the program is stored may be a non-transitory computer readable medium. The non-temporary storage medium is not particularly limited, but may be, for example, a storage medium such as a USB memory or a CD-ROM.

The storage unit 100 stores payment company information, store information, transaction key information, and payment history information. The portion of the storage unit 100 that stores store information may be referred to as a first storage unit. Further, a portion of the storage unit 100 that stores payment history information may be referred to as a second storage unit.

The settlement business information includes various information (such as the payment business name) related to the payment business. The store information includes information that associates information related to the store (store name, store location information, etc.) with the store identifier that identifies the store. The transaction key information includes information for recording the transaction key issued by the common device 30. The payment history information includes a history of payments made by the payment device 40. Further, the payment history information may include at least a user who makes a payment, a payment business operator, a store, and a payment amount.

FIG. 5A shows an example of payment operator information. The "payment business operator ID" is an identifier for uniquely identifying the payment business operator. "Settlement business name" indicates the name of the payment business. The "access destination information" indicates address information (IP address, URL, etc.) when the common device 30 communicates with the payment device.

FIG. 5B shows an example of store information. The "store ID" is an identifier for uniquely identifying a store. "Store information" is various information about a store, and includes, for example, a store name and a store location. The "store name" indicates the name of the store, the brand name, and the like. The "store location" indicates information indicating the location of the store (the address may be used, or the latitude / longitude of the location where the store is located). The "payment business ID" indicates the payment business ID of the payment business that provides the payment service that can be used at each store. For example, aaaa, bbbb, and cccc are stored in the settlement business ID of "A convenience store B station square store". This indicates that the A convenience store B station square store can use the two-dimensional code payment services of companies A, B, and C. "Settlement amount" indicates a settlement amount when a settlement method in which the settlement amount is fixed is used. In the code payment by MPM, a payment method in which the payment amount can be arbitrarily specified is also prepared, and when the payment method is used, nothing is stored in the "payment amount".

C in FIG. 5 shows an example of transaction key information. The transaction key issued by the common device 30 is stored in the "transaction key". The "issue date and time" indicates the date and time when the common device 30 issued the transaction key. The "payment content" indicates the content of the payment performed by the user (for example, the payment business ID of the business operator that provides the payment service used by the user, the store ID of the store that performs the payment, the user ID of the user who performs the payment, etc.). ..

FIG. 5D shows an example of payment history information. The "user ID" indicates an identifier that identifies the user who made the payment. The "payment business ID" indicates a payment business ID of a payment business that provides a payment service used for payment. The "store ID" indicates the store ID of the store where the user has made a payment. "Settlement date and time" indicates the date and time when payment was made. "Settlement amount" indicates the amount settled.

The reception unit 101 includes a payment business operator (more specifically, a payment business operator ID) that executes payment processing among a plurality of payment business operators from a user terminal 10 used by a user who makes payments at a predetermined store. It has a function of accepting a payment request message that specifies a predetermined store (more specifically, a store ID).

Further, the reception unit 101 may receive a prior confirmation request message for designating a predetermined store (more specifically, a store ID) from the user terminal 10 before executing the payment. In addition, the reception unit 101 provides information indicating one payment business operator among a plurality of payment business operators to execute payment from the user terminal 10 before executing payment, and a predetermined store (more specifically, a store ID). ) May be accepted, including information indicating. Further, the reception unit 101 may accept a settlement request message further including a transaction key (transaction information). Further, the reception unit 101 receives a payment request message including a token paid out to the user terminal 10 in advance from the payment device 40 corresponding to one payment business operator that executes the payment processing from the user terminal 10. You may. Further, the reception unit 101 may accept a request for reference of the payment history from the store terminal 20 used by the predetermined store.

The issuing unit 102 has a function of issuing a transaction key when the receiving unit 101 receives a confirmation request from the user terminal 10. In addition, the issuing unit 102 stores the issued transaction key in the transaction key information.

When the reception unit 101 receives a payment request from the user terminal 10, the authentication unit 103 has a function of confirming whether or not the transaction key included in the payment request is the same as the transaction key issued by the issuing unit 102. Have.

The request unit 104 has a function of requesting a payment process from the payment device 40 corresponding to the payment business operator designated by the payment request when the reception unit 101 receives the payment request from the user terminal 10. Further, the requesting unit 104 determines which payment service the payment application the user used at the time of the prior confirmation request, and at the time of the payment request, the payment device corresponding to the payment business operator who issued the determined payment application. It also has a function of requesting payment processing from 40. When the authentication unit 103 confirms that the transaction key included in the payment request and the transaction key issued by the issuing unit 102 are the same, the requesting unit 104 makes a payment to the payment device 40 corresponding to the payment operator. You may request processing. Further, when requesting the payment process from the payment device 40 corresponding to the payment business operator, the request unit 104 transmits the token included in the payment request message received by the reception unit 101 to the payment device 40 corresponding to the payment business operator. You may try to do it.

The acquisition unit 105 has a function of acquiring the processing result of the payment process from the payment device 40 for which the request unit 104 has requested the payment.

The notification unit 106 has a function of notifying the user terminal 10 of the processing result of the payment processing acquired by the acquisition unit 105. Further, when the reception unit 101 receives the advance confirmation request message from the user terminal 10, the notification unit 106 acquires the information related to the predetermined store corresponding to the store ID included in the advance confirmation request message from the store information. The user terminal 10 may be notified.

Further, the notification unit 106 may notify the user terminal 10 of the transaction key issued by the issuing unit 102. At this time, the notification unit 106 may notify the user terminal 10 of the transaction key together with the information related to the predetermined store.

Further, when the reception unit 101 receives the request for reference of the payment history from the store terminal 20 used by the predetermined store, the notification unit 106 acquires the payment history related to the predetermined store from the payment history information. Then, the store terminal 20 may be notified. Further, the notification unit 106 may notify the store terminal 20 used by the predetermined store of the processing result of the payment processing. Further, when the reception unit 101 receives the prior confirmation request message, the notification unit 106 causes the user terminal 10 to return information indicating one payment operator based on the prior confirmation request message and information regarding a predetermined store. It may be.

<Processing procedure>
FIG. 6 is a sequence diagram showing an example of a processing procedure performed by the payment system 1 according to the present embodiment. Hereinafter, the description will be made on the premise that the user purchases a product at the store A and makes a payment by reading the common two-dimensional code (common code) installed at the store A.

In step S100, the user terminal 10 receives from the user the activation of the payment application corresponding to the payment service used for payment. The payment application is an application provided by a payment business operator, and in the present embodiment, it is different for each payment service. Further, it is assumed that the payment business ID is stored in the payment application in advance. However, the present invention is not limited to this, and may be a payment application that can be commonly used by a plurality of payment services. In this case, the user specifies which payment service to use on the screen of the payment application.

In the example of FIG. 6, it is assumed that the payment application corresponding to the payment service provided by Company A is started. In addition, the user logs in to the started payment application by entering his / her user ID and password. It should be noted that the user ID and password of the user may be stored in advance so that automatic login can be performed.

In step S101, the payment application of the user terminal 10 reads the common two-dimensional code installed in the store A based on the instruction from the user. The user terminal 10 acquires the information included in the common two-dimensional code by decoding the read common two-dimensional code. In the present embodiment, it is assumed that the common two-dimensional code stores the store ID and information (URL, IP address, etc.) indicating the access destination of the common device 30, but is not limited to this. ..

In step S102, the payment application of the user terminal 10 sets the payment operator ID stored in the payment application, the store ID obtained by reading the common two-dimensional code, and the user ID that the user inputs at the time of login. A prior confirmation request message including the above is transmitted to the common device 30. The reception unit 101 of the common device 30 receives the prior confirmation request message transmitted from the user terminal 10.

In step S103, the issuing unit 102 of the common device 30 issues a transaction key. Further, the issuing unit 102 stores the issued transaction key in the transaction key information in association with the issuing date and time and the settlement company ID, the store ID, and the user ID included in the prior confirmation request message received by the receiving unit 101. .. Further, the acquisition unit 105 or the notification unit 106 acquires the store information and the settlement amount corresponding to the store ID received in step S102 from the store information. If the payment amount is not stored in the store information (that is, the payment amount is not fixed), the payment amount is not acquired.

In step S104, the notification unit 106 of the common device 30 notifies the user terminal 10 of a prior confirmation response message including the store information, the payment amount, and the transaction key. If the payment amount is not stored in the store information, the payment amount is not included in the prior confirmation response message. In addition, the prior confirmation response message may include the settlement company ID.

In step S105, the payment application of the user terminal 10 displays the received store information (for example, store name, store location, etc.) on the screen. By confirming that the store information displayed on the screen is the same as the store in which the user is trying to purchase the product, the user can confirm that the code is not an illegally installed common two-dimensional code. ..

In step S106 and step S107, the payment application of the user terminal 10 acquires a payment token from the payment device (Company A) 40-A by accessing the payment device (Company A) 40-A. The payment token is, for example, information used for the payment device 40 to confirm whether or not an illegal payment request has been transmitted from the common device 30 to the payment device 40.

In step S108, the payment application of the user terminal 10 displays the payment amount on the screen when the confirmation response message includes the payment amount, and inputs the payment amount when the confirmation response message does not include the payment amount. Accept. When the payment amount is fixed, the user confirms that the payment amount reported by the clerk at the store matches the payment amount displayed on the screen, so that the payment is made at the correct amount. Can be recognized.

In step S109, the payment application of the user terminal 10 receives a selection from the user as to whether or not to execute the payment. If the user chooses not to perform the payment, the payment application ends the process without making the payment. If the user chooses to perform the payment, the process proceeds to step S110.

In step S110, the payment application of the user terminal 10 transmits a payment request message including a payment operator ID, a store ID, a user ID, a transaction key, a payment token, and a payment amount to the common device 30. The reception unit 101 of the common device 30 receives the payment request message transmitted from the user terminal 10.

In step S111, the authentication unit 103 of the common device 30 confirms whether or not the transaction key included in the settlement request message is stored in the transaction key information. If it is stored, the process proceeds to step S112, and if it is not stored, it is regarded as an invalid payment request message, and the reception unit 101 is instructed to discard the payment request message. When the transaction key included in the settlement request message is stored in the transaction key information, the authentication unit 103 further determines the date and time when the settlement request message is received and the "issue date and time" of the transaction key information. You may want to check if it is in time. If it is within the predetermined time, the process proceeds to step S112, and if it is not within the predetermined time, it is regarded as an invalid payment request message and the reception unit 101 is requested to discard the payment request message. You may also instruct.

Further, when the transaction key included in the payment request message is stored in the transaction key information, the authentication unit 103 further indicates that the payment operator ID, the store ID, and the user ID included in the payment request message are the transaction key information. It may be confirmed whether or not it matches the "payment details" of. If they match, the process proceeds to step S112, and if they do not match, the reception unit 101 may be instructed to discard the payment request message by regarding it as an invalid payment request message. ..

In step S112, the request unit 104 of the common device 30 transmits a payment request message including a user ID, a store ID, a payment token, and a payment amount to the payment device (Company A) 40-A.

In step S113, the payment device (Company A) 40-A performs payment processing based on the received payment request message.

In step S114, the payment device (Company A) 40-A notifies the common device 30 of the processing result of the payment process (for example, payment is completed, payment is not possible due to insufficient balance, payment is not possible due to mismatch of payment tokens, etc.). The acquisition unit 105 of the common device 30 acquires the processing result of the payment process notified from the payment device (Company A) 40-A.

In step S115, the notification unit 106 of the common device 30 notifies the store terminal 20 of the store where the payment was made (that is, the store terminal 20 corresponding to the store ID included in the payment request message) of the processing result of the payment processing. To do.

In step S116, the store terminal 20 displays on the screen whether or not the payment made by the user is completed. The store clerk can prevent the product from being illegally exploited by confirming that the payment has been completed on the screen of the store terminal 20 and then handing the product to the user.

The clerk can also confirm that the payment has been completed by referring to the screen of the user terminal 10. However, in this case, there is a possibility that the user may perform fraud such as showing a screenshot of the successful payment to the clerk. In the present embodiment, the store clerk can directly confirm that the payment has been completed on the screen of the store terminal 20, so that such fraud can be eliminated.

In step S117, the notification unit 106 of the common device 30 notifies the user terminal 10 of the processing result of the payment processing. The processing result of the settlement processing may include the settlement business ID in addition to the settlement processing result.

In step S118, the payment application of the user terminal 10 displays the processing result of the payment process on the screen.

In step S119, the payment device (Company A) 40-A directly transmits a message (for example, SMS, e-mail, etc.) indicating the processing result of the payment process to the user terminal 10.

In step S120, the user terminal 10 displays the received SMS or mail. The user can directly confirm that the payment process has been executed by the payment device (Company A) 40-A by referring to the SMS or the mail.

Each processing procedure in the sequence described above can be arbitrarily replaced as long as there is no contradiction in the processing. For example, the order of the processing procedures of step S105, step S106, and step S108 can be arbitrarily changed. Further, the processing procedures of steps S115 and S117 can be interchanged. Further, the processing procedure of step S106 and step S107 may be omitted to simplify the processing man-hours. In this case, in the processing procedure after step S107, the correspondence regarding the settlement token is omitted.

<Summary>
According to the embodiment described above, in the payment processing by MPM, one common two-dimensional code commonly used by each payment business operator is prepared for each store, and the common device 30 makes a payment request by the user. It is set to be transmitted to the payment device 40 of the payment company that provides the payment service to be used. This eliminates the need for the user to search for a two-dimensional code corresponding to the payment service at the store, and makes it possible to improve the convenience of payment processing by MPN. Further, by using the common two-dimensional code, the payment device 40 of each payment business operator does not need to manage the store ID independently, and the resources of the storage device can be reduced.

Further, according to the embodiment described above, after the common two-dimensional code is read by the user terminal 10, the name and location of the store corresponding to the common two-dimensional code are displayed on the screen of the user terminal 10 before accepting the execution of payment. It was made to be displayed in. As a result, the user confirms that the store in which he / she is trying to make a payment matches the store name, store address, etc. displayed on the screen of the user terminal 10, and is installed in the store. It is possible to recognize that the common two-dimensional code is a regular two-dimensional code and not an illegally installed two-dimensional code.

Further, according to the embodiment described above, when the common device 30 receives the payment request message, it confirms that the transaction key included in the payment request message is the same as the transaction key issued in advance. did. As a result, it is possible to prevent the payment device 40 from processing an illegally generated payment request, and it is possible to improve security.

Further, according to the embodiment described above, the payment operator ID is included in the prior confirmation request message and the payment request message transmitted and received between the user terminal 10 and the common device 30. As a result, the common device 30 can recognize which payment service the message received from the user terminal 10 corresponds to, so that the processing content performed by the common device 30 can be changed for each payment service. It will be possible. For example, in the common device 30, when the payment company ID is company A, only the store name is included in the store information included in the prior confirmation response, and when the payment company ID is company B, prior confirmation is made. It is possible to change the processing content performed by the common device 30 for each payment service, such as including both the store name and the store location in the store information included in the response.

Further, according to the above-described embodiment, the common device 30 notifies the store on behalf of the payment operator (payment device 40) that the payment processing has been completed normally, and the payment application and the payment device 40. Mediates payment processing performed with. On the other hand, to the user, it is possible to make it appear that the common device 30 does not mediate the payment processing, but the payment application directly performs the payment processing with the payment operator (payment device 40). it can. As a result, by using one common two-dimensional code, it becomes possible to execute the payment processing corresponding to each of the plurality of payment operators with one common device 30.

Further, according to the above-described embodiment, "settlement" using money, electronic money, points, or the like is targeted, but the present invention is not limited to this. For example, it may be related to "marketing" such as coupons, or it may be related to "payment" such as money, electronic money, points, etc., and related to "marketing" such as coupons. May be combined.

The embodiments described above are for facilitating the understanding of the present invention, and are not for limiting and interpreting the present invention. The flowchart, sequence, each element included in the embodiment, its arrangement, material, condition, shape, size, and the like described in the embodiment are not limited to those exemplified, and can be appropriately changed. In addition, the configurations shown in different embodiments can be partially replaced or combined.

1 ... Payment system, 10 ... User terminal, 11 ... Processor, 12 ... Storage device, 13 ... Communication IF, 14 ... Input device, 15 ... Output device, 20 ... Store terminal, 30 ... Common device, 40 ... Payment device, 100 ... Storage unit, 101 ... Reception department, 102 ... Issuing department, 103 ... Authentication department, 104 ... Request department, 105 ... Acquisition department, 106 ... Notification department

Claims (10)

An information processing device in a system in which payment is made by reading a predetermined code installed in a store with an application installed on a user terminal used by a user who makes payment.
From a user terminal used by a user who makes a payment at a predetermined store, one payment business operator that executes payment processing among a plurality of payment business operators, a reception unit that receives a payment request that specifies the predetermined store, and a reception unit.
When the reception unit receives the payment request, the request unit that requests the payment processing from the payment execution device corresponding to the payment business operator, and the request unit.
An acquisition unit that acquires the processing result of the payment processing from the payment execution device corresponding to the payment business operator,
A notification unit that responds to the user terminal with the processing result of the payment processing,
Information processing device with. When the reception unit receives a prior confirmation request from the user terminal, it has a issuing unit that issues transaction information associated with a transaction related to the payment process.
The notification unit notifies the user terminal of the transaction information issued by the issuing unit.
The reception unit receives the payment request including transaction information, and receives the payment request.
When the transaction information included in the payment request is the same as the transaction information issued by the issuing unit, the requesting unit requests the payment execution device corresponding to the payment business operator to perform the payment processing.
The information processing device according to claim 1. The reception unit receives the payment request including the token paid out to the user terminal in advance by the payment execution device corresponding to the payment business operator from the user terminal.
When requesting the payment process from the payment execution device corresponding to the payment business operator, the requesting unit transmits the token to the payment execution device corresponding to the payment business operator.
The information processing device according to claim 1 or 2. The notification unit notifies the store terminal corresponding to the predetermined store of the processing result of the payment processing.
The information processing device according to any one of claims 1 to 3. It has at least a second storage unit that stores a payment history including a user who makes a payment, a payment business operator, a store, and a payment amount.
The reception unit receives a request for reference to the payment history from the store terminal used by the predetermined store.
The notification unit acquires the payment history related to the predetermined store from the second storage unit and notifies the store terminal.
The information processing device according to any one of claims 1 to 4. The predetermined code installed at the storefront is a common code that is commonly used by the plurality of payment operators and can be read by each application issued by each payment operator.
The information processing device according to any one of claims 1 to 5. An information processing device in a system in which payment is made by reading a predetermined code installed in a store with an application installed on a user terminal used by a user who makes payment.
A reception unit that receives a prior confirmation request including information between one payment business operator that executes payment processing among a plurality of payment business operators and the predetermined store from a user terminal used by a user who makes a payment at a predetermined store. When,
The user terminal has a notification unit that responds with information between the one settlement business operator and the predetermined store based on the prior confirmation request.
The predetermined code is a common code commonly used by the plurality of payment operators and can be read by each application issued by each payment operator.
Information processing device. The information processing device is a device managed by a business operator different from the payment business operator.
The information processing device according to claim 7. It is an information processing method performed by an information processing device in a system in which payment is made by reading a predetermined code installed in a store with an application installed in a user terminal used by a user who makes payment.
A step of accepting a payment request for designating one payment business operator among a plurality of payment business operators to execute payment processing and the predetermined store from a user terminal used by a user who makes a payment at a predetermined store.
When the payment request is received, the step of requesting the payment processing from the payment execution device corresponding to the payment business operator and
A step of acquiring the processing result of the payment processing from the payment execution device corresponding to the payment business operator, and
A step of responding to the user terminal with the processing result of the payment processing,
Information processing methods including. A computer in a system where payment is made by reading a predetermined code installed in a store with an application installed on a user terminal used by a user who makes payment.
A step of accepting a payment request for designating one payment business operator among a plurality of payment business operators to execute payment processing and the predetermined store from a user terminal used by a user who makes a payment at a predetermined store.
When the payment request is received, the step of requesting the payment processing from the payment execution device corresponding to the payment business operator and
A step of acquiring the processing result of the payment processing from the payment execution device corresponding to the payment business operator, and
A step of responding to the user terminal with the processing result of the payment processing,
A program to execute.

Images