Store terminals, terminals, transaction management systems, transaction management methods, and transaction management programs

Abstract

To provide a mechanism that suppresses the transmission of radio waves when products are purchased at service stations.SOLUTION: A user terminal according to one aspect of the present disclosure includes at least one processor. The at least one processor generates a two-dimensional code containing setting information to be used for purchasing a product at a service station, and displays the two-dimensional code for purchasing the product at the service station.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] One aspect of the present disclosure relates to Store terminal, terminal a transaction management system, a transaction management method, and a transaction management program.

Background Art

[0002] A mechanism for assisting in the purchase of goods at a service station that sells energy sources is known. For example, Patent Document 1 discloses a technique for performing settlement of a fueling service by registering information necessary for a transaction in an IC tag in advance and reading the IC tag.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The technique described in Patent Document 1 uses wireless communication to read an IC tag. In a service station that handles flammable dangerous goods, it is desired to suppress the transmission of radio waves.

Means for Solving the Problems

[0005] A user terminal according to one aspect of the present disclosure includes at least one processor. The at least one processor generates a two-dimensional code including setting information used for purchasing goods at a service station and displays the two-dimensional code for purchasing goods at the service station.

[0006] A store terminal relating to one aspect of this disclosure is located at a service station and comprises at least one processor. The at least one processor reads a two-dimensional code displayed on a user terminal, obtains configuration information used for purchasing goods at the service station, and performs purchase-related processing based on the configuration information.

[0007] A transaction management system relating to one aspect of this disclosure comprises a user terminal and a service station store terminal. The user terminal generates a two-dimensional code containing configuration information used for purchasing goods at the service station and displays the two-dimensional code for purchasing goods at the service station. The store terminal obtains the configuration information by reading the two-dimensional code displayed on the user terminal and executes purchase-related processing based on the configuration information.

[0008] A transaction management method relating to one aspect of this disclosure is performed by a user terminal having at least one processor. The transaction management method includes the steps of generating a two-dimensional code containing configuration information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at the service station.

[0009] A transaction management program relating to one aspect of this disclosure causes a computer to perform the steps of generating a two-dimensional code containing configuration information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at a service station.

[0010] In this respect, the configuration information used for purchasing products at service stations is displayed as a two-dimensional code. Since reading the two-dimensional code does not require radio waves, it is possible to suppress the transmission of radio waves when purchasing products at service stations. [Effects of the Invention]

[0011] According to one aspect of this disclosure, it is possible to provide a mechanism that suppresses the transmission of radio waves when purchasing goods at a service station. [Brief explanation of the drawing]

[0012] [Figure 1] This figure shows an example of the overall configuration including the transaction management system according to the embodiment. [Figure 2] This figure shows an example of the functional configuration of the transaction management system according to the embodiment. [Figure 3] This figure shows a typical hardware configuration of a computer used in the transaction management system according to this embodiment. [Figure 4] This figure shows an example of a settings screen. [Figure 5] This is a sequence diagram showing an example of the one-time token query process by the transaction management system according to the embodiment. [Figure 6] This is a sequence diagram showing an example of transaction processing by the transaction management system according to the embodiment. [Figure 7] This is a sequence diagram showing an example of closing processing by the transaction management system according to the embodiment. [Figure 8] This is a sequence diagram showing an example of closing processing by the transaction management system according to the embodiment. [Figure 9] This is a sequence diagram showing another example of transaction processing by the transaction management system according to the embodiment. [Figure 10] This is a sequence diagram showing another example of transaction processing by the transaction management system according to the embodiment. [Figure 11] This is a sequence diagram showing another example of transaction processing by the transaction management system according to the embodiment. [Modes for carrying out the invention]

[0013] The embodiments described herein will be described in detail below with reference to the attached drawings. In the description of the drawings, the same or equivalent elements are denoted by the same reference numerals, and redundant descriptions are omitted.

[0014] [Overview of the System] The transaction management system according to the embodiment is a computer system that manages commodity transactions at a service station. A service station refers to a store that sells energy sources. An energy source refers to a resource used to power a power source, and is provided, for example, to move a moving body such as an automobile. Examples of service stations include gas stations, hydrogen stations, charging stations, etc. Hereinafter, a service station is also simply referred to as a "store". A commodity refers to any tangible or intangible thing that is traded有偿 or无偿, and is a concept that includes the provision of services. "Commodity transaction" means the exchange of commodities between two parties. Examples of transactions include sales, loans, and exchanges. The payment means for the transaction is not limited. For example, the payment means may be, in addition to cash, a deferred payment means such as a credit card, a debit card, or electronic money. A deferred payment means refers to a settlement in which a customer makes a payment to the store after purchasing a commodity. More specifically, the transaction management system in this embodiment manages the sale and purchase of commodities using a deferred payment card. A deferred payment card refers to a card used for deferred settlement, which is a settlement method in which a customer pays the price after purchasing a commodity. An example of a deferred payment card is a credit card, but the types of deferred payment cards are not limited to this. The implementation method of the deferred payment card is not limited. For example, it may be provided to the customer as a tangible card like a general credit card, or as a virtual card represented by electronic data. A customer refers to a person who purchases a commodity. A customer can be referred to as a consumer or a user.

[0015] In this disclosure, the expression "transmit data or information from the first computer to the second computer" means transmission for finally delivering the data or information to the second computer. It should be noted that this expression includes the case where another computer or communication device relays the data or information in the transmission.

[0016] [System Configuration] While referring to FIG. 1, the outline of the mechanism of the transaction management system 1 will be described. FIG. 1 is a diagram showing an example of the overall configuration including the transaction management system 1.

[0017] In this embodiment, the customer 90 owns a user terminal 91. The user terminal 91 is a computer used by the customer 90. The type and configuration of the user terminal 91 are not limited. For example, the user terminal 91 may be a mobile terminal such as a smartphone, a tablet terminal, or a wearable terminal (e.g., a smartwatch). The user terminal 91 may be a component of the transaction management system 1 or may not be a component included in the transaction management system 1.

[0018] The user terminal 91 receives, by the operation of the customer 90, the input of setting information used for purchasing a product. The setting information includes at least one of a one-time token used for verification by the customer 90, customer identification information which is an identifier uniquely identifying the customer 90, product information indicating the product, and payment-related information used for payment. The one-time token is electronic data for verifying (authenticating) whether the customer 90 who purchases the product is the person himself / herself. The one-time token is generated, for example, for each purchase of a product and is used for verification only once. For example, the one-time token is generated by the application server 70. The payment-related information indicates at least one of a coupon and a point card. A coupon is electronic data used for discounting a product. For example, the coupon includes information specifying the product to be discounted, the discount amount, the usage limit, and the expiration date, etc. A point card refers to a card for managing points given to the customer 90 corresponding to a product transaction (specifically, a purchase). The customer 90 can save the points and use the points as at least a part of the purchase price of the product. The user terminal 91 generates a two-dimensional code including the setting information. A two-dimensional code is a visible code expressed so as to have information in the horizontal and vertical directions.

[0019] [[ID=The user terminal 91 displays a two-dimensional code for purchasing goods in the store. For example, when a customer 90 visits the store to purchase goods, they bring the user terminal 91 with them. The customer 90 operates the user terminal 91 to display the two-dimensional code and holds the side displaying the code up to the two-dimensional code reader 19. The two-dimensional code reader 19 is a device capable of reading information contained in a two-dimensional code. The two-dimensional code reader 19 is connected to the store terminal 10. The two-dimensional code reader 19 transmits the setting information read from the two-dimensional code to the store terminal 10. In response to this operation, the store terminal 10 performs various processes related to the purchase of goods.

[0020] The store terminal 10 is a computer located in a store that handles goods. The store terminal 10 performs processing related to the purchase of goods. For example, the processing related to the purchase of goods may include the selection or setting of the goods to be purchased, or it may include payment processing. The configuration of the store terminal 10 is not limited. For example, the store terminal 10 may be a general cash register, it may have POS (point of sale) functionality, or it may be another type of device that has cash register functionality or POS functionality. Figure 1 shows only one store terminal 10, but of course the transaction management system 1 can manage transactions at multiple store terminals 10 in multiple stores. Each store terminal 10 may be a component of the transaction management system 1, or it may be a component that is not included in the transaction management system 1.

[0021] The transaction management system 1 comprises a transaction management server 20, which is a computer that manages individual transactions, and an application server 70 that generates one-time tokens. The transaction management server 20 can communicate with each of at least one store terminal 10. The transaction management server 20 can also communicate with the application server 70, a database 30 that stores various information used for individual transactions, and a payment management server 40 of a card company that manages settlements. The application server 70 can also communicate with each of at least one user terminal 91. The store terminal 10 can also communicate with a first sales management server 50 and a second sales management server 60, which comprehensively manage transactions at one or more stores. For example, the first sales management server 50 and the second sales management server 60 perform closing processes to finalize transactions (sales). The first sales management server 50 and the second sales management server 60 may be components of the transaction management system 1, or they may be components not included in the transaction management system 1.

[0022] The configuration and type of communication network used for communication connections between computers are not limited and may be designed according to any policy. For example, the communication network may be constructed as the Internet, an intranet, or a combination thereof. Furthermore, the communication network may be constructed as a wired network, a wireless network, or a combination thereof.

[0023] Referring to Figure 1, an example of the processing flow in a single transaction, i.e., a single purchase procedure, will be explained. The user terminal 91 requests a one-time token inquiry by sending customer identification information to the application server 70 (step S11). In response to the request, the application server 70 generates a one-time token and sends the generated one-time token and customer identification information to the transaction management server 20 (step S12). The transaction management server 20 stores the correspondence between the one-time token and the customer identification information in the database 30. The application server 70 sends a response including the generated one-time token to the user terminal 91 (step S13). A customer 90 who intends to purchase goods at the store operates the user terminal 91 and enters configuration information. The customer 90 may enter the configuration information in advance before entering the store, or may enter the configuration information at the store. The configuration information includes, for example, a one-time token and product information. The user terminal 91 generates a two-dimensional code containing the configuration information.

[0024] In response to customer 90 displaying the two-dimensional code on user terminal 91 and holding user terminal 91 over two-dimensional code reader 19, the two-dimensional code reader 19 begins reading the two-dimensional code. The two-dimensional code reader 19 transmits the configuration information read from the two-dimensional code to store terminal 10. Store terminal 10 transmits the configuration information to transaction management server 20 (step S21). Based on the customer identification information associated with the one-time token indicated by the configuration information, the transaction management server 20 reads the official card number of the deferred payment card and the tokenized card number of the deferred payment card from database 30. The transaction management server 20 also requests a credit check from payment management server 40 by transmitting the official card number to payment management server 40 (step S22). The payment management server 40 responds to the request by performing a credit check and transmits the result (credit result) to transaction management server 20 (step S23). The transaction management server 20 sends a response to the store terminal 10 that includes the credit check result and the tokenized card number of the deferred payment card (step S14). If the credit check result indicates approval of the transaction, the customer 90 can purchase goods at the store using the deferred payment card.

[0025] In this embodiment, the transaction management system 1 uses two types of card numbers as identifiers to uniquely identify a deferred payment card: the official card number and the tokenized card number. The official card number is the number set by the card company when issuing a deferred payment card. The official card number is notified to the customer 90 when the deferred payment card is issued, and therefore the customer 90 can know their official card number. On the other hand, the tokenized card number is a card number obtained by replacing at least a part of the official card number with another string through tokenization. Tokenization is a process that replaces the original string with another string without any mathematical relationship to the original string. Tokenization can be achieved, for example, by generating the other string using random numbers. The original string (string before replacement) and the other string (string after replacement) are associated one-to-one. Since there is no mathematical relationship between these two strings, it is not possible to identify the original string from the other string through mathematical processing. To obtain the original string, it is necessary to know the one-to-one correspondence. Tokenization differs from encryption in that there is no mathematical relationship between the data before and after replacement. Encryption is the process of transforming original data into encrypted data using an encryption algorithm and encryption key. Therefore, a mathematical relationship exists between the original data and the encrypted data, based on the encryption algorithm and encryption key.

[0026] The closing process will be explained with reference to Figure 1. The example in Figure 1 shows two types of closing processes, corresponding to the existence of two types of sales management servers: the first sales management server 50 and the second sales management server 60. The store terminal 10 establishes a communication connection with one of the first sales management server 50 and the second sales management server 60.

[0027] In the first closing process, the first sales management server 50 is used. In this case, the store terminal 10 transmits transaction information indicating one or more transactions to the first sales management server 50 (step S31). The transaction information includes individual tokenized card numbers corresponding to each transaction, but does not include individual official card numbers corresponding to each transaction. The first sales management server 50 transmits one or more tokenized card numbers to the transaction management server 20 (step S32). The transaction management server 20 refers to the database 30 and reads the corresponding official card number for each tokenized card number. Then, the transaction management server 20 transmits one or more official card numbers to the first sales management server 50 (step S33). The first sales management server 50 transmits settlement information corresponding to the transaction information received from the store terminal 10 to the settlement management server 40 (step S34). The settlement information includes individual official card numbers corresponding to each transaction. Subsequently, the card company executes the settlement using a deferred payment card.

[0028] In the second closing process, the second sales management server 60 is used. In this case, the store terminal 10 sends transaction information indicating one or more transactions to the second sales management server 60 (step S41). The transaction information includes individual tokenized card numbers corresponding to each transaction, but does not include individual official card numbers corresponding to each transaction. The second sales management server 60 sends settlement information corresponding to that transaction information to the transaction management server 20 (step S42). The transaction management server 20 refers to the database 30 and reads the corresponding official card number for each tokenized card number. Then, the transaction management server 20 replaces one or more tokenized card numbers in the settlement information with one or more official card numbers and sends the processed settlement information to the settlement management server 40 (step S43). After that, the card company executes the settlement using the deferred payment card.

[0029] The goods to which the transaction management system 1 applies are not limited. For example, the transaction management system 1 may be built for trading energy sources (e.g., gasoline, diesel, hydrogen, electricity, etc.), other goods, or services (e.g., gasoline car refueling services, electric vehicle charging services, car washes, etc.) at a service station. That is, the goods may be fuel oil, hydrogen, etc., and the store may be a gas station or a hydrogen station. In this case, the store terminal 10 may be a gas pump or hydrogen dispenser equipped with a cash register function or a POS function.

[0030] The functional elements related to the transaction management system 1 will be explained with reference to Figure 2. Figure 2 is a diagram showing an example of the functional configuration of the transaction management system 1.

[0031] The user terminal 91 includes a display unit 92 and a generation unit 93 as functional elements. The display unit 92 is a functional element that displays a settings screen for pre-setting setting information used for purchasing products at a service station. The display unit 92 accepts input of setting information. The generation unit 93 is a functional element that generates a two-dimensional code containing the setting information set on the settings screen. The generation unit 93 may generate a two-dimensional code containing some or all of the setting information.

[0032] The store terminal 10 includes a setting information acquisition unit 11 and a purchase processing unit 12 as functional elements. The setting information acquisition unit 11 is a functional element that acquires various types of information sent from the user terminal 91. The purchase processing unit 12 is a functional element that executes processing related to the transaction (specifically, purchase) of goods.

[0033] The transaction management server 20 includes a credit request unit 21, a data acquisition unit 22, and a settlement information processing unit 23 as functional elements. The credit request unit 21 is a functional element that performs processing related to the confirmation of credit for deferred payment methods. The data acquisition unit 22 is a functional element that accesses the database 30 to acquire various types of information. The settlement information processing unit 23 is a functional element that relays the transfer of settlement information from the second sales management server 60 to the settlement management server 40.

[0034] The database 30 is a device that stores various types of information used for individual transactions. For example, the database 30 may store data related to product information, coupon information, and point card information for each customer 90. The database 30 may also store card data related to deferred payment cards. The database 30 may be a component of the transaction management system 1, or it may be a component not included in the transaction management system 1. In this embodiment, the database 30 is a separate device from the transaction management server 20, but it may also be a component of the transaction management server 20.

[0035] Each record in the card data includes customer identification information and a combination of the official card number (card information) and a tokenized card number for the deferred payment card. In other words, this card data associates the customer identification information with the official card number and the tokenized card number. The card data is generated based on the credit card information provided by the customer 90 and stored in the database 30. Each record in the card data may be encrypted to enhance security. The details of the procedure for registering the card data are not limited, and the flow of the procedure may be arbitrarily determined. In any case, when the card data is generated and stored, the official card number of the deferred payment card is tokenized, thereby generating a tokenized card number. In this embodiment, it is assumed that card data corresponding to the customer identification information is stored in the database 30 (hereinafter referred to as "deferred payment card settings").

[0036] The settlement management server 40 includes a credit inquiry unit 41 and a settlement unit 42 as functional elements. The credit inquiry unit 41 is a functional element that performs credit inquiries for each transaction (settlement). The settlement unit 42 is a functional element that performs settlement-related processing.

[0037] The first sales management server 50 includes a detoken unit 51 and a transaction / settlement management unit 52 as functional elements. The detoken unit 51 is a functional element that obtains the official card number from the transaction management server 20. The transaction / settlement management unit 52 is a functional element that obtains transaction information from the store terminal 10 and transmits settlement information to the settlement management server 40.

[0038] The second sales management server 60 includes a transaction / settlement management unit 61 as a functional element. The transaction / settlement management unit 61 is a functional element that acquires transaction information from the store terminal 10 and transmits settlement information to the transaction management server 20.

[0039] The application server 70 includes a token generation unit 71 as a functional element. The token generation unit 71 is a functional element that obtains customer identification information from the user terminal 91 and generates a one-time token.

[0040] Figure 3 shows a typical hardware configuration of a computer 100 that can function as a server or terminal related to the transaction management system 1. For example, the computer 100 comprises a processor 101, main memory 102, auxiliary storage 103, communication control unit 104, input device 105, and output device 106. The processor 101 executes the operating system and application programs. The main memory 102 consists of, for example, ROM and RAM. The auxiliary storage 103 consists of, for example, a hard disk or flash memory and generally stores a larger amount of data than the main memory 102. The auxiliary storage 103 stores a program 110 for causing at least one computer to function as a server or terminal. The communication control unit 104 consists of, for example, a network card or wireless communication module. The input device 105 consists of, for example, a keyboard, mouse, touch panel, etc. The output device 106 consists of, for example, a monitor and speaker.

[0041] Each functional element of each device is realized by loading a program 110 onto the processor 101 or main memory 102 and executing that program. The program 110 includes code for realizing each functional element of the corresponding server or terminal. The processor 101 operates the communication control unit 104, input device 105, or output device 106 according to the program 110, and reads and writes data to the main memory 102 or auxiliary storage 103. Through this process, each functional element of the corresponding server or terminal is realized. The data or database required for processing may be stored in the main memory 102 or auxiliary storage 103.

[0042] Each server may consist of one or more computers. When multiple computers are used, they are connected to each other via a communication network to logically form a single server.

[0043] Program 110 may correspond to a transaction management program. Program 110 may be provided by being permanently recorded on a tangible recording medium such as a CD-ROM, DVD-ROM, or semiconductor memory. Alternatively, Program 110 may be provided via a communication network as a data signal superimposed on a carrier wave.

[0044] Figure 4 shows an example of a settings screen. The settings screen is a screen for configuring settings information. The settings screen may be provided to the user terminal 91 as, for example, a screen of an installed application or a screen of a web application. The user terminal 91 displays the settings screen and accepts input of settings information from the customer 90. The settings screen includes ID settings 911, product settings 912, and payment-related settings 913.

[0045] The user terminal 91 requests a one-time token query from the application server 70 before or during the display of the settings screen and obtains a one-time token. For example, the one-time token query may be performed by background processing before the display of the settings screen. The user terminal 91 may obtain the one-time token automatically, or it may be obtained triggered by an action by the customer 90. The user terminal 91 may or may not display the one-time token on the settings screen. The one-time token is used only once to verify whether the customer 90 is the real person. The one-time token may have an expiration date set.

[0046] ID setting 911 is a screen element for setting customer identification information. For example, the transaction management system 1 may issue customer identification information to a customer 90 registered as a user and send that customer identification information to the user terminal 91. The user terminal 91 may automatically set the customer identification information in ID setting 911.

[0047] Product setting 912 is a screen element for setting product information. Product information may be default values ​​for products that customer 90 usually or frequently purchases. Product information includes, for example, the type of fuel and the amount to be dispensed. Examples of fuel types include premium gasoline, regular gasoline, and diesel fuel. Examples of the amount to be dispensed include quantity (e.g., 3L to 100L) or price (e.g., 300 yen to 14,999 yen). By combining the fuel type and the amount to be dispensed, the product information may be set as, for example, "Premium Gasoline 30L".

[0048] The payment-related settings 913 are screen elements for configuring payment-related information. For example, the payment-related settings 913 include coupon settings 913a for configuring coupons and point card settings 913b for configuring point cards. Coupon settings 913a may accept the selection of coupons that have been pre-distributed to the user terminal 91. Coupons may be distributed to the user terminal 91 from, for example, the transaction management system 1, or from another server, etc. Point card settings 913b may accept the input of, for example, a point card number that uniquely identifies the point card. In this embodiment, the payment-related settings 913 allow the coupon settings 913a and point card settings 913b to be configured individually, but arbitrary constraints may be imposed on the settings. For example, a constraint may be imposed that requires the setting of a deferred payment card when inputting to point card settings 913b.

[0049] The settings screen allows for the configuration of at least one of the following: a one-time token, customer identification information, product information, and payment-related information. For example, customer 90 inputs the settings information by operating at least one of the following: ID setting 911, product setting 912, and payment-related setting 913. The one-time token is automatically obtained using the customer identification information. Regarding the settings information, there are various combinations depending on whether or not each of the ID setting 911, product setting 912, and payment-related setting 913 is configured. The user terminal 91 processes at least one of the one-time token, customer identification information, product information, and payment-related information configured on the settings screen as settings information and generates a two-dimensional code 914 containing the settings information.

[0050] The user terminal 91 may generate a two-dimensional code 914 each time the configuration information is updated. For example, the user terminal 91 may generate a two-dimensional code 914 triggered by the acquisition of a one-time token. Alternatively, the user terminal 91 may display a confirmation screen for confirming the configuration information and generate a two-dimensional code 914 triggered by the customer's confirmation operation. The two-dimensional code 914 may be displayed on the configuration screen or on another screen. The user terminal 91 may send some or all of the configuration information to the transaction management server 20 via the application server 70. The transaction management server 20 may store the configuration information in the database 30. The user terminal 91 may generate a two-dimensional code 914 that includes some or all of the configuration information. For example, if some of the configuration information (e.g., customer identification information) is stored in the database 30, the user terminal 91 may generate a two-dimensional code 914 that does not include the customer identification information. If the two-dimensional code 914 does not include some of the configuration information, the configuration information may be treated as a pattern in which some of the information is not set. If a deferred payment card has been set up (database 30 stores the card data), the user terminal 91 may or may not display the official card number on the settings screen. Even if a deferred payment card has been set up, the user terminal 91 generates a two-dimensional code 914 that does not include the official card number.

[0051] [System operation] The operation of the transaction management system 1 will be explained with reference to Figures 5 to 8, and the transaction management method according to this embodiment will also be described. Figures 5 to 8 are sequence diagrams showing an example of the operation of the transaction management system 1. More specifically, Figure 5 shows the inquiry process for a one-time token, Figure 6 shows the process in a single transaction (a single purchase procedure), and Figures 7 and 8 show examples of closing processes. Figures 5 to 8 also show the correspondence with the steps shown in Figure 1.

[0052] First, referring to Figure 5, the processing related to the one-time token will be explained as the processing flow S1. In step S101, the user terminal 91 requests a one-time token query by sending customer identification information to the application server 70. In one example, the user terminal 91 requests a one-time token query before or during the display of a settings screen as shown in Figure 4.

[0053] In step S102, the token generation unit 71 of the application server 70 generates a one-time token in response to a request for a one-time token query. A one-time token is generated for each one-time token query.

[0054] In step S103, the application server 70 sends a notification to the transaction management server 20 containing the generated one-time token and customer identification information. The transaction management server 20 receives the notification.

[0055] In step S104, the transaction management server 20 stores the correspondence between the one-time token and the customer identification information in the database 30. This allows the transaction management server 20 to derive the customer identification information based on the one-time token.

[0056] In step S105, the application server 70 sends a response containing the generated one-time token to the user terminal 91. The user terminal 91 receives this response and obtains the one-time token.

[0057] Next, referring to Figure 6, the processing in a single transaction will be described as the processing flow S2. In step S201, the display unit 92 of the user terminal 91 displays a settings screen for pre-setting the setting information used for purchasing goods at the service station. For example, the display unit 92 displays a settings screen as shown in Figure 4 and accepts input of setting information from the customer 90. The processing flow S1 shown in Figure 5 may be executed before the processing of step S201, or it may be executed during the processing of step S201.

[0058] In step S202, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 containing the configuration information set on the settings screen. The configuration information includes at least one of a one-time token, customer identification information, product information, and payment-related information. For example, the generation unit 93 generates a two-dimensional code 914 that includes a one-time token, product information, and payment-related information, but does not include customer identification information. In this example, the configuration information corresponds to a pattern where a one-time token, product information, and payment-related information are set, but customer identification information is not.

[0059] In step S203, the user terminal 91 displays a two-dimensional code 914 for purchasing goods in the store. For example, customer 90 operates the user terminal 91 to display the two-dimensional code 914 and holds the side displaying the two-dimensional code 914 over the two-dimensional code reader 19.

[0060] In step S204, the two-dimensional code reader 19 reads the two-dimensional code 914. For example, in response to customer 90 holding user terminal 91 over the two-dimensional code reader 19, the two-dimensional code reader 19 begins reading the two-dimensional code 914 displayed on user terminal 91.

[0061] In step S205, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The two-dimensional code reader 19 reads the two-dimensional code 914 displayed on the user terminal 91 and transmits the read information to the store terminal 10. As a result, the store terminal 10 acquires the setting information. The store terminal 10 stores the acquired setting information.

[0062] In step S206, the purchase processing unit 12 of the store terminal 10 sends a credit check to the transaction management server 20. The credit check is a data signal to check the credit status of a deferred payment card. The credit check includes, for example, the current date and time, a store ID which is an identifier that uniquely identifies the store where the store terminal 10 is located, a one-time token, and a provisional purchase amount. The provisional purchase amount is a purchase amount that is set provisionally in order to perform a credit check on the deferred payment card, and is not the purchase price of the goods. An extremely low amount is set as the provisional purchase amount. For example, the smallest possible value in a transaction (for example, 1 yen in Japanese yen) may be set as the provisional purchase amount. The transaction management server 20 receives the credit check.

[0063] In step S207, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to obtain customer identification information corresponding to the one-time token indicated by the credit check query, and further obtains card data corresponding to the customer identification information. Since customer identification information can be derived from the one-time token, the transaction management server 20 can determine that customer 90 has had the two-dimensional code 914 read by the two-dimensional code reader 19. In other words, the transaction management server 20 can verify whether the customer 90 purchasing the goods is the real person. Through this process, the data acquisition unit 22 obtains two types of card numbers corresponding to the customer identification information, namely the official card number and the tokenized card number.

[0064] In step S208, the credit request unit 21 of the transaction management server 20 sends a credit inquiry request to the settlement management server 40. The credit inquiry request is a data signal that causes the settlement management server 40 to perform a credit check on the deferred payment card corresponding to the customer identification information. The credit inquiry request includes the current date and time, the official card number obtained from the database 30, and the provisional purchase amount indicated in the credit inquiry. The settlement management server 40 receives the credit inquiry request.

[0065] In step S209, the credit inquiry unit 41 of the payment management server 40 performs a credit inquiry on the deferred payment card corresponding to the official card number indicated in the credit inquiry request, and sends the result to the transaction management server 20 as a credit result. The credit inquiry unit 41 determines whether or not the deferred payment card can be used in the transaction at the store by referring to data showing the status of the deferred payment card, the usage limit, etc. Since the hypothetical purchase amount is an extremely low amount (for example, the minimum value that can occur in a transaction), unless there are special circumstances such as the deferred payment card being suspended or the usage limit being exceeded, the credit inquiry unit 41 approves the use of the deferred payment card. The credit inquiry unit 41 sends the result of the credit inquiry to the transaction management server 20 as a credit result. The transaction management server 20 receives the credit result.

[0066] In step S210, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response is a data signal indicating the answer to the credit inquiry. The response includes the credit result and the tokenized card number. The store terminal 10 receives the response. This response does not contain the official card number. That is, the credit request unit 21 sends the tokenized card number to the store terminal 10 without sending the official card number to the store terminal 10. Since the store terminal 10 does not obtain the official card number, the store clerk does not recognize the official card number of customer 90's deferred payment card in the transaction.

[0067] In step S211, the purchase processing unit 12 of the store terminal 10 performs settings related to the purchase of goods. The purchase processing unit 12 performs these settings based on the goods information obtained from the user terminal 91. The specific method for setting up goods for purchase is not limited. For example, if the goods are fuel oil such as gasoline or diesel, the goods information may show pre-set default values ​​for refueling (e.g., type of fuel and amount of fuel). The store terminal 10 displays the goods information (default values) on the monitor and asks the customer 90 whether or not to purchase the goods according to that information. The customer 90 can operate the store terminal 10 to determine the details of the goods to be purchased. For example, the customer 90 can operate a fuel dispenser, which is an example of a store terminal 10, to select refueling based on the default values, or to request refueling after changing the type of fuel or amount of fuel from the default values. As described above, the type of goods is not limited in any way, and correspondingly, the content of the goods information is not limited in any way.

[0068] In step S212, the purchase processing unit 12 of the store terminal 10 executes a purchase process (settlement process) to confirm the transaction. The purchase processing unit 12 executes settlement using a deferred payment card only if the credit check result indicates that the deferred payment card is usable. If a floor limit is set for purchases using a deferred payment card, the purchase processing unit 12 will only accept transactions within the predetermined upper limit. The floor limit refers to a certain standard amount that requires a credit check. If the purchase amount exceeds the floor limit, approval from the card company is required. If the purchase amount is less than or equal to the floor limit, a credit check is not performed. For example, if the floor limit is 15,000 yen, the purchase processing unit 12 will only accept purchases and settlements using a deferred payment card if the purchase amount is 15,000 yen or less. At this point, a credit check using an extremely low amount (for example, the smallest possible value in a transaction) has been completed, so settlement subject to the floor limit is possible. For example, if the store terminal 10 is a gas pump at a gas station, the gas pump controls the amount of fuel dispensed so that the purchase amount does not exceed the floor limit.

[0069] The purchase processing unit 12 may, if there are available coupons, display the coupons on the monitor and ask the customer 90 whether they wish to use at least a portion of the coupons to purchase the goods. The purchase processing unit 12 may calculate the discounted amount from the purchase amount based on the customer 90's selection and the purchase amount. If the customer 90 uses the coupons for the purchase, the purchase processing unit 12 may accept the transaction if the purchase amount is less than or equal to the sum of the floor limit and the discount amount.

[0070] The purchase processing unit 12 may, if there is a point balance on the point card, display the point balance on the monitor and ask the customer 90 whether they want to use at least a portion of the points to purchase goods. The purchase processing unit 12 may add or subtract points from the point card based on the customer 90's selection and the purchase amount. If the customer 90 uses points to make a purchase, the purchase processing unit 12 may accept the transaction if the purchase amount is less than or equal to the sum of the floor limit and the points used.

[0071] Once the purchase process is complete, the purchase processing unit 12 issues a receipt and generates a transaction information record representing a single transaction, and stores that record in a predetermined storage unit. Each transaction information record includes, for example, the date and time of the transaction, the store ID, the tokenized card number, and product information. The product information includes, for example, the name, unit price, quantity, and purchase amount (= unit price × quantity) for each of one or more products.

[0072] In processing flow S2, the store terminal 10 receives a response containing the tokenized card number and executes payment for the goods based on that response. In other words, the store terminal 10 executes payment for the goods without obtaining the official card number.

[0073] Each store terminal 10 executes the processing flow S2 for each individual transaction (settlement), thereby accumulating transaction information at each store terminal 10. The accumulated transaction information is sent to the first sales management server 50 or the second sales management server 60 through a closing process.

[0074] Next, referring to Figure 7, the closing process via the first sales management server 50 will be described as processing flow S3. This closing process is generally a daily process, but the execution timing of processing flow S2 is not limited to this and may be executed at any time.

[0075] In step S301, the purchase processing unit 12 of the store terminal 10 transmits transaction information indicating one or more transactions (more specifically, one or more transactions that occurred after the previous closing process) to the first sales management server 50. The first sales management server 50 receives the transaction information.

[0076] In step S302, the detokenization unit 51 of the first sales management server 50 sends a detokenization request to the transaction management server 20. The detokenization request is a data signal for obtaining the official card number of the deferred payment card and includes one or more tokenized card numbers as indicated in the transaction information. The transaction management server 20 receives the detokenization request.

[0077] In step S303, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 and obtains one or more official card numbers corresponding to one or more tokenized card numbers indicated in the detoken request. Since there is a one-to-one correspondence between official card numbers and tokenized card numbers, the data acquisition unit 22 can obtain an official card number for each of the one or more tokenized card numbers.

[0078] In step S304, the data acquisition unit 22 sends a detoken response to the first sales management server 50. The detoken response is a data signal indicating a response to the detoken request and includes one or more pairs of the official card number and the tokenized card number. The first sales management server 50 receives the detoken response.

[0079] In step S305, the transaction / settlement management unit 52 of the first sales management server 50 transmits settlement information corresponding to the transaction information to the settlement management server 40. Specifically, the transaction / settlement management unit 52 generates settlement information by replacing each of the one or more tokenized card numbers indicated in the transaction information with the official card number. This replacement is called detoxification. The transaction / settlement management unit 52 transmits this settlement information to the settlement management server 40. The settlement management server 40 receives the settlement information, and the settlement unit 42 executes the settlement based on that settlement information. The transmission of settlement information by the first sales management server 50 (step S305) may or may not correspond to the transmission of transaction information by the store terminal 10 (step S301). For example, both the transmission of transaction information and the transmission of settlement information may be daily processes. Alternatively, the transmission of transaction information may be a daily process, and the transmission of settlement information may be a monthly or bi-weekly process.

[0080] Next, referring to Figure 8, the closing process via the second sales management server 60 will be described as processing flow S4. Similar to processing flow S3, this closing process may be performed daily or at any other arbitrary time.

[0081] In step S401, the purchase processing unit 12 of the store terminal 10 sends transaction information indicating one or more transactions (more specifically, one or more transactions that occurred after the previous closing process) to the second sales management server 60. The second sales management server 60 receives the transaction information.

[0082] In step S402, the transaction / settlement management unit 61 of the second sales management server 60 sends the transaction information as settlement information to the transaction management server 20. Unlike the first sales management server 50, the second sales management server 60 (transaction / settlement management unit 61) does not perform detokenization. The transaction management server 20 receives the settlement information. The transmission of settlement information by the second sales management server 60 (step S402) may or may not correspond to the transmission of transaction information by the store terminal 10 (step S401). For example, both the transmission of transaction information and the transmission of settlement information may be daily processes. Alternatively, the transmission of transaction information may be a daily process, while the transmission of settlement information may be a monthly or bi-weekly process.

[0083] In step S403, the data acquisition unit 22 and the settlement information processing unit 23 of the transaction management server 20 work together to replace the tokenized card numbers in the settlement information with the official card numbers. The data acquisition unit 22 accesses the database 30 to obtain one or more official card numbers corresponding to one or more tokenized card numbers indicated in the settlement information. The settlement information processing unit 23 replaces each of the one or more tokenized card numbers indicated in the settlement information with the official card number. In other words, the settlement information processing unit 23 performs detokenization.

[0084] In step S404, the payment information processing unit 23 transmits the processed payment information to the payment management server 40. The payment management server 40 receives the payment information, and the payment unit 42 executes the payment based on that payment information.

[0085] Figure 9 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. Referring to Figure 9, we will mainly explain the differences between the processing in a single transaction and processing flow S2, with processing flow S5 being the processing flow. Processing flow S5 assumes that the database 30 stores product information corresponding to customer identification information. Figure 9 shows an example in which the store terminal 10 queries the transaction management server 20 for product information.

[0086] In step S501, the display unit 92 of the user terminal 91 displays the settings screen. The processing in step S501 is the same as the processing in step S201. The processing flow S1 shown in Figure 5 may be executed before the processing in step S501 or during the processing in step S501.

[0087] In step S502, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 that includes the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 that includes a one-time token and payment-related information, but does not include customer identification information or product information. In this example, the setting information corresponds to a pattern in which a one-time token and payment-related information are set, but customer identification information and product information are not.

[0088] In step S503, the user terminal 91 displays a two-dimensional code 914 for purchasing goods at the store. The process in step S503 is the same as the process in step S203.

[0089] In step S504, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S504 is the same as the process in step S204.

[0090] In step S505, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process in step S505 is the same as the process in step S205.

[0091] In step S506, the purchase processing unit 12 of the store terminal 10 sends a credit check inquiry and a product information inquiry to the transaction management server 20. The product information inquiry is a data signal requesting the acquisition of product information. The product information inquiry may be part of the credit check inquiry or may be a separate data signal.

[0092] In step S507, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to obtain customer identification information corresponding to the one-time token indicated by the credit inquiry, and further obtains product information and card data corresponding to the customer identification information.

[0093] In step S508, the credit request unit 21 of the transaction management server 20 sends a credit inquiry request to the settlement management server 40. The processing in step S508 is the same as the processing in step S208.

[0094] In step S509, the credit inquiry unit 41 of the payment management server 40 performs a credit inquiry on the deferred payment card corresponding to the official card number indicated by the credit inquiry request, and sends the result as a credit result to the transaction management server 20. The processing in step S509 is the same as the processing in step S209.

[0095] In step S510, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response includes the credit result, product information, and tokenized card number. The store terminal 10 receives the response.

[0096] In step S511, the purchase processing unit 12 of the store terminal 10 performs the settings related to the purchase of the product. The purchase processing unit 12 performs these settings based on the product information obtained from the transaction management server 20. The process in step S511 is the same as the process in step S211, except that the method of obtaining the product information is different.

[0097] In step S512, the purchase processing unit 12 of the store terminal 10 executes a purchase process (settlement process) to confirm the transaction. The process in step S512 is the same as the process in step S212.

[0098] After the execution of processing flow S5, processing flow S3 shown in Figure 7 or processing flow S4 shown in Figure 8 may be executed.

[0099] Figure 10 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. Referring to Figure 10, the processing in a single transaction will be referred to as processing flow S6, and the differences from processing flow S2 will be mainly explained. In processing flow S6, processing flow S1 shown in Figure 5 is not executed. Figure 10 shows an example in which customer 90 does not set up a deferred payment card (an example in which the database 30 does not store card data).

[0100] In step S601, the display unit 92 of the user terminal 91 displays the settings screen. The process in step S601 is the same as the process in step S201.

[0101] In step S602, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 that includes the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 that includes product information but does not include a one-time token, customer identification information, or payment-related information. In this example, the setting information corresponds to a pattern where product information is set, but a one-time token, customer identification information, and payment-related information are not set.

[0102] In step S603, the user terminal 91 displays a two-dimensional code 914 for purchasing goods at the store. The process in step S603 is the same as the process in step S203.

[0103] In step S604, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S604 is the same as the process in step S204.

[0104] In step S605, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process in step S605 is the same as the process in step S205.

[0105] In step S606, the purchase processing unit 12 of the store terminal 10 performs settings related to the purchase of goods. The process in step S606 is the same as the process in step S211.

[0106] In step S607, the purchase processing unit 12 of the store terminal 10 performs a purchase process (settlement process) to confirm the transaction. The purchase processing unit 12 may accept a selection of payment method from the customer 90. For example, the purchase processing unit 12 may accept payment by cash, deferred payment method, or prepaid method (e.g., prepaid card).

[0107] Figure 11 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. Referring to Figure 11, the processing in a single transaction will be referred to as processing flow S7, and the differences from processing flow S2 will be mainly explained. Processing flow S7 assumes that the database 30 stores product information corresponding to customer identification information. Also, in processing flow S7, processing flow S1 shown in Figure 5 is not executed. Figure 11 shows an example where customer 90 has not set up a deferred payment card (database 30 does not store card data), and the store terminal 10 queries the transaction management server 20 for product information.

[0108] In step S701, the display unit 92 of the user terminal 91 displays the settings screen. The process in step S701 is the same as the process in step S201.

[0109] In step S702, the generation unit 93 of the user terminal 91 generates a two-dimensional code 914 that includes the setting information set on the setting screen. For example, the generation unit 93 generates a two-dimensional code 914 that includes customer identification information but does not include a one-time token, product information, or payment-related information. In this example, the setting information corresponds to a pattern in which customer identification information is set, but one-time tokens, product information, and payment-related information are not set.

[0110] In step S703, the user terminal 91 displays a two-dimensional code 914 for purchasing goods at the store. The process in step S703 is the same as the process in step S203.

[0111] In step S704, the two-dimensional code reader 19 reads the two-dimensional code 914. The process in step S704 is the same as the process in step S204.

[0112] In step S705, the setting information acquisition unit 11 of the store terminal 10 acquires setting information from the two-dimensional code 914 displayed on the user terminal 91. The process in step S705 is the same as the process in step S205.

[0113] In step S706, the purchase processing unit 12 of the store terminal 10 sends a product information inquiry to the transaction management server 20. The product information inquiry includes customer identification information. The transaction management server 20 receives the product information inquiry.

[0114] In step S707, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 and acquires product information corresponding to the customer identification information indicated by the product information query.

[0115] In step S708, the credit request unit 21 of the transaction management server 20 sends a response to the store terminal 10. The response includes product information. The store terminal 10 receives the response.

[0116] In step S709, the purchase processing unit 12 of the store terminal 10 performs the settings related to the purchase of the product. The process in step S709 is the same as the process in step S511.

[0117] In step S710, the purchase processing unit 12 of the store terminal 10 executes a purchase process (settlement process) to confirm the transaction. The process in step S710 is the same as the process in step S607.

[0118] [effect] As described above, a user terminal relating to one aspect of this disclosure comprises at least one processor. The at least one processor generates a two-dimensional code containing configuration information used for purchasing goods at a service station and displays the two-dimensional code for purchasing goods at a service station.

[0119] A store terminal relating to one aspect of this disclosure is located at a service station and comprises at least one processor. The at least one processor reads a two-dimensional code displayed on a user terminal, obtains configuration information used for purchasing goods at the service station, and performs purchase-related processing based on the configuration information.

[0120] A transaction management system relating to one aspect of this disclosure comprises a user terminal and a service station store terminal. The user terminal generates a two-dimensional code containing configuration information used for purchasing goods at the service station and displays the two-dimensional code for purchasing goods at the service station. The store terminal obtains the configuration information by reading the two-dimensional code displayed on the user terminal and executes purchase-related processing based on the configuration information.

[0121] A transaction management method relating to one aspect of this disclosure is performed by a user terminal having at least one processor. The transaction management method includes the steps of generating a two-dimensional code containing configuration information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at the service station.

[0122] A transaction management program relating to one aspect of this disclosure causes a computer to perform the steps of generating a two-dimensional code containing configuration information used for purchasing goods at a service station, and displaying the two-dimensional code for purchasing goods at a service station.

[0123] In this respect, the configuration information used for purchasing products at service stations is displayed as a two-dimensional code. Since reading the two-dimensional code does not require radio waves, it is possible to suppress the transmission of radio waves when purchasing products at service stations.

[0124] In user terminals related to other aspects, at least one processor displays a settings screen for pre-configuring settings information and generates a two-dimensional code containing the settings information configured on the settings screen. In this case, since the settings information can be configured outside the service station, a flexible mechanism can be provided for purchasing products at the service station.

[0125] In user terminals relating to other aspects, at least one processor may acquire a one-time token used for customer verification at the service station and generate a two-dimensional code containing the one-time token. In this case, the security of the product transaction is enhanced because the customer purchasing the product is verified to be the person they claim to be.

[0126] In store terminals relating to other aspects, the configuration information may include product information that identifies the product. At least one processor may perform purchase-related processing based on the product information. In this case, specifying product information at the store becomes easier or unnecessary, thus improving the convenience of product transactions.

[0127] In store terminals relating to other aspects, the configuration information may include customer identification information that uniquely identifies a customer at the service station. At least one processor may retrieve product information indicating a product from the transaction management server based on the customer identification information, and execute purchase-related processing based on the product information. In this case, pre-configured product information is managed by the transaction management server, and purchase-related processing is executed by the store terminal based on this product information. This improves the convenience of product transactions by simplifying or eliminating the need to specify product information at the store.

[0128] [Differentiation] The embodiments described above have been explained in detail. However, the disclosure is not limited to the embodiments described above. The disclosure can be modified in various ways without departing from its essence.

[0129] In this embodiment, it has been described that the user terminal 91 displays a settings screen and accepts input of settings information, but the settings information may be copied to the user terminal 91 from a different medium. For example, customer 90 may own an NFC tag separate from the user terminal 91 (hereinafter referred to as "another tag"). The other tag may have settings information desired by customer 90 stored in advance. The database 30 may store the correspondence between the identifier of the other tag and the settings information. The transaction management system 1 may also provide the user terminal 91 with a handover screen for copying the settings information. For example, customer 90 may enter the identifier of their own other tag into the handover screen. The transaction management system 1 may read the settings information corresponding to the entered identifier of the other tag from the database 30 and send that settings information to the user terminal 91. The user terminal 91 may store the received settings information in a memory area. In this way, the settings information may be copied from the other tag to the user terminal 91. Alternatively, a copying device (e.g., a reader / writer) may be installed in the store to read configuration information from another tag and write it to the user terminal 91. The configuration information may be copied from the other tag to the user terminal 91 by operating the copying device.

[0130] In this embodiment, it has been described that the user terminal 91 displays a settings screen and accepts input of product information, but the product information may be stored (registered) in advance by the application server 70. For example, the user terminal 91 may send a request for product information to the application server 70 along with a request for one-time token inquiry. The application server 70 may send the product information to the user terminal 91 along with a response to the request for one-time token inquiry. The user terminal 91 may generate a two-dimensional code containing the one-time token and product information obtained from the application server 70.

[0131] In another variation, the point card information may be managed by an external server that manages the points (hereinafter referred to as the "point management server"). The store terminal 10 may transmit the point card number obtained by reading the two-dimensional code to the external point management server. The point management server may determine whether the point card number is valid, identify the point balance corresponding to that point card number, and transmit that point balance to the store terminal 10. If the point card number is valid, the customer 90 can obtain points corresponding to the purchase of goods or use at least a portion of the point balance as at least a portion of the purchase price. Alternatively, the transaction management server 20 may transmit the point card number to the external point management server and obtain the point balance.

[0132] In this disclosure, the expression "at least one processor executes a first process, a second process, ... and the nth process," or a corresponding expression, refers to a concept that includes cases where the entity executing the n processes from the first process to the nth process changes along the way. In other words, this expression refers to a concept that includes both cases where all n processes are executed by the same processor and cases where the processor changes at an arbitrary rate for the n processes.

[0133] The processing steps of the method executed by at least one processor are not limited to the examples in the embodiments. For example, some of the steps (processes) described above may be omitted, or each step may be performed in a different order. Also, any two or more of the steps described above may be combined, or some of the steps may be modified or deleted. Alternatively, other steps may be performed in addition to each of the above steps. [Explanation of Symbols]

[0134] 1...Transaction management system, 10...Store terminal, 11...Setting information acquisition unit, 12...Purchase processing unit, 19...Two-dimensional code reader, 20...Transaction management server, 21...Credit request unit, 22...Data acquisition unit, 23...Settlement information processing unit, 30...Database, 40...Settlement management server, 41...Credit inquiry unit, 42...Settlement unit, 50...First sales management server, 51...Detox unit, 52...Transaction / settlement management unit, 60...Second sales management server, 61...Transaction / settlement management unit, 70...Application server, 71...Token generation unit, 90...Customer, 91...User terminal, 92...Display unit, 93...Generation unit, 911...ID setting, 912...Product setting, 913...Payment-related settings, 914...Two-dimensional code.

Claims

1. A store terminal located at a service station, Equipped with at least one processor, The at least one processor, The one-time token is obtained by reading a two-dimensional code containing a one-time token that is displayed on the customer's terminal at the service station and used for verifying the customer. Based on the aforementioned one-time token, the customer's pre-set product information and tokenized card number are retrieved from the transaction management server. The product information is displayed on the monitor as a default value, and the customer is allowed to change the default value. Then, the settings related to purchasing the product are executed. Using the aforementioned tokenized card number, the payment processing for the aforementioned product is performed without using the official card number. Store terminal.

2. A transaction management system comprising a customer terminal at a service station and a store terminal at the service station, The aforementioned terminal, A two-dimensional code containing a one-time token used for verifying the aforementioned customer is generated, The two-dimensional code is displayed for setting up the purchase of goods at the aforementioned service station. The aforementioned store terminal By reading the two-dimensional code displayed on the customer's terminal, the one-time token is obtained. Based on the aforementioned one-time token, the customer's pre-set product information and tokenized card number are retrieved from the transaction management server. The product information is displayed on the monitor as a default value, and the customer is allowed to change the default value. Then, the settings related to purchasing the product are executed. Using the aforementioned tokenized card number, the payment processing for the aforementioned product is performed without using the official card number. Transaction management system.

3. A transaction management method performed by a store terminal equipped with at least one processor, The steps include: obtaining a one-time token by reading a two-dimensional code containing a one-time token that is displayed on the customer's terminal at the service station and used to verify the customer; Based on the aforementioned one-time token, the customer obtains pre-set product information and tokenized card number from the transaction management server. The steps include: displaying the product information as default values ​​on the monitor, allowing the customer to change the default values, and then performing settings related to purchasing the product; The steps include: using the tokenized card number to perform payment processing for the product without using the official card number; Transaction management methods including

4. The steps include: obtaining a one-time token by reading a two-dimensional code containing a one-time token that is displayed on the customer's terminal at the service station and used to verify the customer; Based on the aforementioned one-time token, the customer obtains pre-set product information and tokenized card number from the transaction management server. The steps include: displaying the product information as default values ​​on the monitor, allowing the customer to change the default values, and then performing settings related to purchasing the product; The steps include: using the tokenized card number to perform payment processing for the product without using the official card number; A transaction management program that causes a computer to execute transactions.

Images