JP2025113464A - Transaction management method, store terminal, and transaction management system - Google Patents

Abstract

[Problem] To provide a mechanism for suppressing radio wave transmission when purchasing a product at a service station. [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 including setting information used to purchase a product at the service station, and displays the two-dimensional code for purchasing the product at the service station. [Selected Figure] Figure 2

Description

One aspect of the present disclosure relates to a user terminal, a store terminal, a transaction management system, a transaction management method, and a transaction management program.

Systems that support the purchase of products at service stations that sell energy sources are known. For example, Patent Document 1 discloses technology in which the information necessary for the transaction is pre-registered on an IC tag, and payment for a refueling service is made by reading the IC tag.

Patent No. 5857332

The technology described in Patent Document 1 uses wireless communication to read IC tags. At service stations that handle flammable and hazardous materials, it is desirable to suppress the transmission of radio waves.

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 to purchase a product at a service station, and displays the two-dimensional code for purchasing the product at the service station.

A store terminal according to one aspect of the present disclosure is located in a service station and includes at least one processor. The at least one processor reads a two-dimensional code displayed on a user terminal, obtains setting information used to purchase products at the service station, and executes processing related to the purchase based on the setting information.

A transaction management system according to one aspect of the present disclosure includes a user terminal and a store terminal at a service station. The user terminal generates a two-dimensional code including setting information used to purchase products at the service station and displays the two-dimensional code for purchasing products at the service station. The store terminal obtains the setting information by reading the two-dimensional code displayed on the user terminal and executes processing related to the purchase based on the setting information.

A transaction management method according to one aspect of the present disclosure is executed by a user terminal having at least one processor. The transaction management method includes the steps of generating a two-dimensional code including setting information used to purchase a product at a service station, and displaying the two-dimensional code for purchasing the product at the service station.

A transaction management program according to one aspect of the present disclosure causes a computer to execute the steps of generating a two-dimensional code including setting information used to purchase products at a service station, and displaying the two-dimensional code for purchasing products at the service station.

In this aspect, the setting information used to purchase products at a service station is displayed as a two-dimensional code. Since radio waves are not required to read the two-dimensional code, radio wave transmission can be suppressed when purchasing products at a service station.

One aspect of the present disclosure provides a mechanism for suppressing radio wave transmission when purchasing products at a service station.

FIG. 1 is a diagram showing an example of the overall configuration including a transaction management system according to an embodiment. FIG. 2 is a diagram illustrating an example of the functional configuration of a transaction management system according to an embodiment. FIG. 1 is a diagram showing a general hardware configuration of a computer used in a transaction management system according to an embodiment. FIG. 10 is a diagram illustrating an example of a setting screen. A sequence diagram showing an example of a one-time token inquiry process by a transaction management system according to an embodiment. A sequence diagram showing an example of transaction processing by the transaction management system according to the embodiment. A sequence diagram showing an example of closing processing by a transaction management system according to an embodiment. A sequence diagram showing an example of closing processing by a transaction management system according to an embodiment. A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment. A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment. A sequence diagram showing another example of transaction processing by the transaction management system of the embodiment.

Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. In the description of the drawings, identical or equivalent elements will be designated by the same reference numerals, and duplicate explanations will be omitted.

[System Overview]
A transaction management system according to an embodiment is a computer system that manages product transactions at a service station. A service station is a store that sells energy sources. An energy source is a resource used to power a power source, such as a vehicle, and is provided to power a vehicle. Examples of service stations include gas stations, hydrogen stations, and charging stations. Hereinafter, a service station will also be referred to simply as a "store." A product refers to any tangible or intangible object traded for or without payment, and is a concept that includes the provision of services. A "product transaction" refers to the exchange of a product between two parties. Examples of transactions include buying and selling, lending, borrowing, and bartering. Payment methods involved in a transaction are not limited. For example, payment methods may include cash, credit cards, debit cards, electronic money, or other deferred payment methods. A deferred payment method refers to a payment method in which a customer purchases a product and then deposits funds into a store. More specifically, the transaction management system according to this embodiment manages the purchase and sale of products using deferred payment cards. A deferred payment card refers to a card used for deferred payment, a payment method in which a customer pays for a product after purchasing it. An example of a deferred payment card is a credit card, but the type of deferred payment card is not limited to this. There are no limitations on how the deferred payment card is implemented; for example, it may be provided to the customer as a tangible card like a general credit card, or it may be provided as a virtual card represented by electronic data. A customer is someone who purchases a product. A customer can be referred to as a consumer or a user.

In this disclosure, the expression "transmitting" data or information from a first computer to a second computer refers to transmission for ultimate delivery of the data or information to the second computer. Note that this expression also includes cases where another computer or communication device relays the data or information during the transmission.

[System configuration]
An overview of the mechanism of the transaction management system 1 will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the overall configuration including the transaction management system 1.

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 be a component not included in the transaction management system 1.

The user terminal 91 accepts input of setting information used to purchase products through operation by the customer 90. The setting information includes at least one of a one-time token used to verify the customer 90, customer identification information which is an identifier that uniquely identifies the customer 90, product information indicating the product, and payment-related information used for payment. The one-time token is electronic data used to verify (authenticate) whether the customer 90 purchasing the product is the customer. The one-time token is generated, for example, for each product purchase and is used only once for verification. 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 to discount products. For example, a coupon includes information such as information identifying the product subject to the discount, the discount amount, the maximum usage limit, and the expiration date. A point card is a card used to manage points awarded to the customer 90 in response to a product transaction (specifically, a purchase). The customer 90 can accumulate these points and use them as at least 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 that contains information in both the horizontal and vertical directions.

The user terminal 91 displays a two-dimensional code for purchasing a product at a store. For example, a customer 90 visits a store with the user terminal 91 to purchase a product. The customer 90 operates the user terminal 91 to display the two-dimensional code, and holds the side with the two-dimensional code displayed over the two-dimensional code reader 19. The two-dimensional code reader 19 is a device capable of reading the information in the 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, various processes related to the purchase of the product are executed in the store terminal 10.

The store terminal 10 is a computer located in a store that handles merchandise. The store terminal 10 executes processes related to the purchase of merchandise. In one example, the process related to the purchase of merchandise may include the selection or setting of the merchandise to be purchased, or 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, may have POS (point of sale) functionality, or may be another type of device with cash register or POS functionality. While FIG. 1 shows only one store terminal 10, the transaction management system 1 can naturally 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 may be a component not included in the transaction management system 1.

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 be connected to at least one store terminal 10. The transaction management server 20 can also be connected to an application server 70, a database 30 that stores various information used in individual transactions, and a card company's payment management server 40 that manages payments. The application server 70 can also be connected to at least one user terminal 91. The store terminal 10 can also be connected to a first sales management server 50 and a second sales management server 60 that manage transactions at one or more stores. For example, the first sales management server 50 and the second sales management server 60 perform closing processing 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.

The configuration and type of the communication network used for communication connections between computers are not limited in any way and may be designed according to any policy. For example, the communication network may be constructed using the Internet, an intranet, or a combination of these. The communication network may also be constructed using a wired network, a wireless network, or a combination of these.

With reference to Figure 1, an example of the processing flow for a single transaction, i.e., a single purchase procedure, will be described. 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 wishes to purchase an item at a store operates the user terminal 91 to input setting information. The customer 90 may input the setting information in advance before entering the store, or may input the setting information at the store. The setting information includes, for example, the one-time token and product information. The user terminal 91 generates a two-dimensional code including the setting information.

In response to the customer 90 displaying the two-dimensional code on the user terminal 91 and holding the user terminal 91 over the 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 setting information read from the two-dimensional code to the store terminal 10. The store terminal 10 transmits the setting information to the transaction management server 20 (step S21). Based on the customer identification information associated with the one-time token indicated by the setting 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 the database 30. The transaction management server 20 also transmits the official card number to the payment management server 40, requesting a credit inquiry (credit inquiry) from the payment management server 40 (step S22). In response to the request, the payment management server 40 performs a credit inquiry and transmits the result (credit result) to the transaction management server 20 (step S23). The transaction management server 20 sends a response including the credit result and the tokenized card number of the deferred payment card to the store terminal 10 (step S14). If the credit result indicates approval of the transaction, the customer 90 can purchase goods at the store using the deferred payment card.

In this embodiment, the transaction management system 1 uses two types of card numbers—a formal card number and a tokenized card number—as identifiers to uniquely identify deferred payment cards. The formal card number is a number assigned by the card company when issuing a deferred payment card. The formal card number is notified to the customer 90 when the deferred payment card is issued, allowing the customer 90 to know their formal card number. On the other hand, the tokenized card number is a card number obtained by replacing at least a portion of the formal card number with a different string through tokenization. Tokenization refers to the process of replacing an original string with a different string that has no mathematical relationship to the original string. Tokenization can be achieved, for example, by generating the different string using random numbers. The original string (the string before replacement) and the different string (the replaced string) are related one-to-one. Because there is no mathematical relationship between these two strings, the original string cannot be identified from the different string through mathematical processing. To obtain the original string, the one-to-one correspondence must be known. Tokenization differs from encryption in that there is no mathematical relationship between the data before and after replacement. Encryption is the process of converting original data into encrypted data using an encryption algorithm and encryption key, so there is a mathematical relationship between the original data and the encrypted data due to the encryption algorithm and encryption key.

The flow of 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: a first sales management server 50 and a second sales management server 60. The store terminal 10 is connected to one of the first sales management server 50 and the second sales management server 60 for communication.

The first sales management server 50 is used in the first closing process. In this case, the store terminal 10 sends 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 sends one or more tokenized card numbers to the transaction management server 20 (step S32). The transaction management server 20 references the database 30 and reads out the corresponding official card number for each tokenized card number. The transaction management server 20 then sends one or more official card numbers to the first sales management server 50 (step S33). The first sales management server 50 sends payment information corresponding to the transaction information received from the store terminal 10 to the payment management server 40 (step S34). The payment information includes individual official card numbers corresponding to each transaction. The card company then executes the payment using the deferred payment card.

The second sales management server 60 is used in the second closing process. 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 payment information corresponding to the transaction information to the transaction management server 20 (step S42). The transaction management server 20 references the database 30 and reads the corresponding official card number for each tokenized card number. The transaction management server 20 then replaces one or more tokenized card numbers in the payment information with one or more official card numbers and sends the processed payment information to the payment management server 40 (step S43). The card company then executes the payment using the deferred payment card.

There are no limitations on the products to which the transaction management system 1 can be applied. For example, the transaction management system 1 may be configured for trading energy sources (e.g., gasoline, diesel, hydrogen, electricity, etc.), other products, or services (e.g., gasoline vehicle refueling services, electric vehicle charging services, car washes, etc.) at service stations. That is, the product may be fuel oil, hydrogen, etc., and the store may be a gas station or hydrogen station. In this case, the store terminal 10 may be a fuel pump or hydrogen dispenser equipped with a cash register function or POS function.

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

The user terminal 91 has functional elements including a display unit 92 and a generation unit 93. The display unit 92 is a functional element that displays a setting screen for pre-setting setting information to be used when 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 that includes the setting information set on the setting screen. The generation unit 93 may generate a two-dimensional code that includes some or all of the setting information.

The store terminal 10 has functional elements including a setting information acquisition unit 11 and a purchase processing unit 12. The setting information acquisition unit 11 is a functional element that acquires various information sent from the user terminal 91. The purchase processing unit 12 is a functional element that executes processing related to product transactions (specifically, purchases).

The transaction management server 20 has the following functional elements: a credit request unit 21, a data acquisition unit 22, and a payment information processing unit 23. The credit request unit 21 is a functional element that executes processing related to the credit confirmation of deferred payment methods. The data acquisition unit 22 is a functional element that accesses the database 30 to acquire various information. The payment information processing unit 23 is a functional element that relays the transfer of payment information from the second sales management server 60 to the payment management server 40.

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

Each record of the card data includes customer identification information and a set of the deferred payment card's official card number (card information) and tokenized card number. In other words, this card data associates customer identification information, the official card number, and the tokenized card number. The card data is generated based on credit card information provided by the customer 90 and stored in database 30. Each record of the card data may be encrypted to improve security. The details of the procedure for registering card data are not limited, and the procedure flow may be determined arbitrarily. In any case, when the card data is generated and stored, the tokenized card number is generated by tokenizing the deferred payment card's official card number. This embodiment assumes that card data corresponding to the customer identification information is stored in database 30 (hereinafter referred to as "postpaid card settings").

The payment management server 40 has two functional elements: a credit inquiry unit 41 and a settlement unit 42. The credit inquiry unit 41 is a functional element that performs credit inquiries for individual transactions (payments). The settlement unit 42 is a functional element that executes processing related to payments.

The first sales management server 50 has the following functional elements: a detoken unit 51 and a transaction/settlement management unit 52. The detoken unit 51 is a functional element that acquires the official card number from the transaction management server 20. The transaction/settlement management unit 52 is a functional element that acquires transaction information from the store terminal 10 and transmits the payment information to the payment management server 40.

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

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

Figure 3 shows the general 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 includes a processor 101, a main memory 102, an auxiliary memory 103, a communication control unit 104, an input device 105, and an output device 106. The processor 101 executes an operating system and application programs. The main memory 102 is composed of, for example, ROM and RAM. The auxiliary memory 103 is composed of, for example, a hard disk or flash memory, and generally stores larger amounts of data than the main memory 102. The auxiliary memory 103 stores a program 110 for causing at least one computer to function as a server or terminal. The communication control unit 104 is composed of, for example, a network card or wireless communication module. The input device 105 is composed of, for example, a keyboard, mouse, touch panel, etc. The output device 106 is composed of, for example, a monitor and speaker.

Each functional element of each device is realized by loading and executing program 110 onto processor 101 or main memory 102. Program 110 includes code for realizing each functional element of the corresponding server or terminal. Processor 101 operates communication control unit 104, input device 105, or output device 106 in accordance with program 110, and reads and writes data from and to main memory 102 or auxiliary memory 103. This processing realizes each functional element of the corresponding server or terminal. Data or databases required for processing may be stored in main memory 102 or auxiliary memory 103.

Each server can be composed of one or more computers. When multiple computers are used, these computers are connected to each other via a communications network to logically form a single server.

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 communications network as a data signal superimposed on a carrier wave.

Figure 4 shows an example of a settings screen. The settings screen is a screen for setting setting information. The settings screen may be provided to the user terminal 91, for example, as 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 setting information from the customer 90. The settings screen includes ID settings 911, product settings 912, and payment-related settings 913.

The user terminal 91 requests a one-time token inquiry from the application server 70 before or while the settings screen is displayed, and obtains the one-time token. For example, the one-time token inquiry may be performed by background processing before the settings screen is displayed. The user terminal 91 may obtain the one-time token automatically, or may obtain it as a trigger of an operation 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 be set to have an expiration date.

ID settings 911 are screen elements 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 transmit the customer identification information to the user terminal 91. The user terminal 91 may automatically set the customer identification information in the ID settings 911.

Product settings 912 are screen elements for setting product information. Product information can be default values for products that the customer 90 normally or frequently purchases. Product information includes, for example, the type of fuel and the amount of fuel to be filled. Examples of fuel types include premium gasoline, regular gasoline, and diesel. The amount of fuel to be filled can be the quantity (e.g., 3L to 100L) or the amount (e.g., 300 yen to 14,999 yen). By combining the type of fuel and the amount of fuel to be filled, the product information can be set, for example, as "30L of premium gasoline."

The payment-related settings 913 are screen elements for setting payment-related information. For example, the payment-related settings 913 include a coupon setting 913a for setting a coupon, and a point card setting 913b for setting a point card. The coupon setting 913a may accept the selection of a coupon that has been distributed in advance to the user terminal 91. The coupon may be distributed to the user terminal 91 from, for example, the transaction management system 1, or may be distributed to the user terminal 91 from another server, etc. The point card setting 913b may accept, for example, the input of a point card number that uniquely identifies the point card. In this embodiment, the payment-related settings 913 can individually set the coupon setting 913a and the point card setting 913b, but any restrictions may also be imposed on the settings. For example, a restriction may be imposed on input to the point card setting 913b that requires the setting of a deferred payment card.

At least one of the one-time token, customer identification information, product information, and payment-related information is set on the settings screen. For example, the customer 90 inputs setting information by operating at least one of the ID settings 911, product settings 912, and payment-related settings 913. The one-time token is automatically obtained using the customer identification information. There are various combinations of setting information depending on whether or not the ID settings 911, product settings 912, and payment-related settings 913 are set. The user terminal 91 processes at least one of the one-time token, customer identification information, product information, and payment-related information set on the settings screen as setting information, and generates a two-dimensional code 914 including the setting information.

The user terminal 91 may generate a two-dimensional code 914 each time the setting information is updated. For example, the user terminal 91 may generate the two-dimensional code 914 when it acquires a one-time token. Alternatively, the user terminal 91 may display a confirmation screen or the like for confirming the setting information, and generate the two-dimensional code 914 when the customer performs a confirmation operation. The two-dimensional code 914 may be displayed on the setting screen or on another screen. The user terminal 91 may send some or all of the setting information to the transaction management server 20 via the application server 70. The transaction management server 20 may store the setting information in the database 30. The user terminal 91 may generate a two-dimensional code 914 that includes some or all of the setting information. In one example, if some of the setting 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 setting information, the setting information may be treated as a pattern in which that part is not set. If a deferred payment card has been set up (card data is stored in database 30), the user terminal 91 may or may not display the official card number on the setting 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.

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

First, referring to Figure 5, processing related to one-time tokens will be described as processing flow S1. In step S101, the user terminal 91 requests a one-time token inquiry by sending customer identification information to the application server 70. In one example, the user terminal 91 requests a one-time token inquiry before or while displaying a settings screen such as that shown in Figure 4.

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

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

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.

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

Next, with reference to Figure 6, the processing for one transaction will be described as process flow S2. In step S201, the display unit 92 of the user terminal 91 displays a setting screen for pre-setting setting information to be used when purchasing products at a service station. For example, the display unit 92 displays a setting screen such as that shown in Figure 4 and accepts input of setting information from the customer 90. Process flow S1 shown in Figure 5 may be executed before or during the processing of step S201.

In step S202, 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. The setting 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 setting information corresponds to a pattern in which a one-time token, product information, and payment-related information are set, but customer identification information is not set.

In step S203, the user terminal 91 displays a two-dimensional code 914 for purchasing a product at the store. For example, the customer 90 operates the user terminal 91 to display the two-dimensional code 914, and holds the side on which the two-dimensional code 914 is displayed over the two-dimensional code reader 19.

In step S204, the two-dimensional code reader 19 reads the two-dimensional code 914. For example, in response to the customer 90 holding the 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 the user terminal 91.

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.

In step S206, the purchase processing unit 12 of the store terminal 10 sends a credit inquiry to the transaction management server 20. The credit inquiry is a data signal for checking the credit status of the deferred payment card. The credit inquiry includes, for example, the current date and time, a store ID which is an identifier for uniquely identifying 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 temporarily set to execute a credit inquiry for the deferred payment card, and is not the purchase amount of the product. An extremely low amount is set as the provisional purchase amount. For example, the minimum possible value for the transaction (for example, 1 yen in Japanese yen) may be set as the provisional purchase amount. The transaction management server 20 receives the credit inquiry.

In step S207, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire customer identification information corresponding to the one-time token indicated in the credit inquiry, and further acquires card data corresponding to the customer identification information. Because the customer identification information can be derived from the one-time token, the transaction management server 20 can determine that the customer 90 has had the two-dimensional code reader 19 read the two-dimensional code 914. In other words, the transaction management server 20 can verify whether the customer 90 purchasing the product is the customer in question. Through this process, the data acquisition unit 22 acquires two types of card numbers corresponding to the customer identification information, namely, the official card number and the tokenized card number.

In step S208, the credit request unit 21 of the transaction management server 20 sends a credit inquiry request to the payment management server 40. The credit inquiry request is a data signal that causes the payment management server 40 to execute a credit inquiry for 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 payment management server 40 receives the credit inquiry request.

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 the deferred payment card can be used for transactions at the store by referencing data indicating the deferred payment card's status, credit limit, etc. Because the provisional purchase amount is extremely low (for example, the minimum amount possible for the transaction), the credit inquiry unit 41 approves the use of the deferred payment card unless there are special circumstances such as the deferred payment card being suspended or the credit limit having already been exceeded. 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.

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 an 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 include the official card number. In other words, 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. Because the store terminal 10 does not obtain the official card number, the store clerk does not recognize the official card number of the customer 90's deferred payment card during the transaction.

In step S211, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of a product. The purchase processing unit 12 executes these settings based on product information acquired from the user terminal 91. The specific method for setting the product purchase is not limited. For example, if the product is a fuel oil such as gasoline or diesel, the product information may indicate pre-set default values related to refueling (e.g., the type of fuel and the amount of fuel to be refueled). The store terminal 10 displays the product information (default values) on the monitor and asks the customer 90 whether or not to purchase the product according to that information. The customer 90 can operate the store terminal 10 to determine the details of the product to be purchased. For example, the customer 90 can operate a fuel pump, which is an example of a store terminal 10, to select refueling based on the default values, or request refueling after changing the type of fuel or the amount of fuel to be refueled from the default values. As described above, the type of product is not limited, and correspondingly, the content of the product information is not limited either.

In step S212, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) to confirm the transaction. The purchase processing unit 12 executes payment using the deferred payment card only if the credit result indicates that the deferred payment card can be used. If a floor limit is set for purchases using deferred payment cards, the purchase processing unit 12 only accepts transactions up to a specified upper limit. The floor limit is a certain amount that requires a credit inquiry. If the purchase amount exceeds the floor limit, approval from the card company is required. If the purchase amount is equal to or less than the floor limit, no credit inquiry is performed. For example, if the floor limit is 15,000 yen, the purchase processing unit 12 will only accept purchases and payments using the deferred payment card if the purchase amount is 15,000 yen or less. At this point, a credit inquiry using an extremely low amount (e.g., the minimum possible value for the transaction) has been completed, so payment subject to the floor limit is possible. For example, if the store terminal 10 is a gas station fuel pump, the fuel pump will control fuel dispensing so that the purchase amount does not exceed the floor limit.

If there is an available coupon, the purchase processing unit 12 may display the coupon on the monitor and ask the customer 90 whether or not to use at least a portion of the coupon to purchase the product. 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 a coupon 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 discount amount.

If the customer 90 has a point balance on the point card, the purchase processing unit 12 may display the point balance on the monitor and ask the customer 90 whether or not to use at least some of the points to purchase a product. 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 total of the floor limit and the points used.

When the purchase process is complete, the purchase processing unit 12 issues a receipt and generates a transaction information record indicating the transaction, and stores the record in a designated memory unit. One transaction information record indicates, for example, the transaction date and time, store ID, tokenized card number, and product information. The product information indicates, for example, the name, unit price, quantity, and purchase amount (= unit price x quantity) for each of one or more products.

In process flow S2, the store terminal 10 receives a response including the tokenized card number and executes payment for the product based on that response. In other words, the store terminal 10 executes payment for the product without obtaining the official card number.

At each store terminal 10, process flow S2 is executed for each transaction (payment), causing transaction information to be accumulated at each store terminal 10. The accumulated transaction information is then sent to the first sales management server 50 or the second sales management server 60 through closing processing.

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

In step S301, 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 first sales management server 50. The first sales management server 50 receives the transaction information.

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

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

In step S304, the data acquisition unit 22 sends a de-token response to the first sales management server 50. The de-token response is a data signal indicating a response to the de-token request, and includes one or more pairs of a formal card number and a tokenized card number. The first sales management server 50 receives the de-token response.

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

Next, referring to Figure 8, the closing process via the second sales management server 60 will be explained as process flow S4. As with process flow S3, this closing process may be performed daily or at any other time.

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.

In step S402, the transaction/settlement management unit 61 of the second sales management server 60 transmits the transaction information as payment 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 execute detokenization. The transaction management server 20 receives the payment information. The transmission of payment 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 payment information may be processed daily. Alternatively, the transmission of transaction information may be processed daily, and the transmission of payment information may be processed monthly or bimonthly.

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

In step S404, the payment information processing unit 23 sends 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 the payment information.

Figure 9 is a sequence diagram showing another example of transaction processing by the transaction management system 1 according to the embodiment. With reference to Figure 9, the processing for one transaction will be referred to as process flow S5, and differences from process flow S2 will be mainly explained. Process flow S5 is based on the premise 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.

In step S501, the display unit 92 of the user terminal 91 displays a setting screen. The processing of step S501 is similar to the processing of step S201. The processing flow S1 shown in FIG. 5 may be executed before the processing of step S501, or may be executed during the processing of step S501.

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 set.

In step S503, the user terminal 91 displays the two-dimensional code 914 for purchasing a product at the store. The processing in step S503 is similar to the processing in step S203.

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

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 processing in step S505 is the same as the processing in step S205.

In step S506, the purchase processing unit 12 of the store terminal 10 sends a credit 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 inquiry or may be a separate data signal.

In step S507, the data acquisition unit 22 of the transaction management server 20 accesses the database 30 to acquire customer identification information corresponding to the one-time token indicated in the credit inquiry, and further acquires product information and card data corresponding to the customer identification information.

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

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 in the credit inquiry request, and transmits the result to the transaction management server 20 as the credit result. The processing of step S509 is the same as the processing of step S209.

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 the tokenized card number. The store terminal 10 receives the response.

In step S511, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of a product. The purchase processing unit 12 executes these settings based on the product information acquired from the transaction management server 20. The processing of step S511 is the same as the processing of step S211, except that the route through which the product information is acquired is different.

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

After execution of process flow S5, process flow S3 shown in Figure 7 or process flow S4 shown in Figure 8 may be executed.

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

In step S601, the display unit 92 of the user terminal 91 displays a settings screen. The processing in step S601 is the same as the processing in step S201.

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 in which product information is set, but a one-time token, customer identification information, and payment-related information are not set.

In step S603, the user terminal 91 displays the two-dimensional code 914 for purchasing a product at the store. The processing in step S603 is similar to the processing in step S203.

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

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 processing of step S605 is the same as the processing of step S205.

In step S606, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of the product. The processing in step S606 is similar to the processing in step S211.

In step S607, the purchase processing unit 12 of the store terminal 10 executes a purchase process (payment process) to finalize 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, or advance payment (e.g., a prepaid card).

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

In step S701, the display unit 92 of the user terminal 91 displays a settings screen. The processing in step S701 is similar to the processing in step S201.

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 a one-time token, product information, and payment-related information are not set.

In step S703, the user terminal 91 displays the two-dimensional code 914 for purchasing a product at the store. The processing in step S703 is similar to the processing in step S203.

In step S704, the two-dimensional code reader 19 reads the two-dimensional code 914. The processing in step S704 is similar to the processing in step S204.

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 processing of step S705 is the same as the processing of step S205.

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.

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.

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.

In step S709, the purchase processing unit 12 of the store terminal 10 executes settings related to the purchase of the product. The processing of step S709 is the same as the processing of step S511.

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

[effect]
As described above, a user terminal according to one aspect of the present disclosure includes at least one processor that generates a two-dimensional code including setting information used to purchase a product at a service station and displays the two-dimensional code for purchasing the product at the service station.

A store terminal according to one aspect of the present disclosure is located in a service station and includes at least one processor. The at least one processor reads a two-dimensional code displayed on a user terminal, obtains setting information used to purchase products at the service station, and executes processing related to the purchase based on the setting information.

A transaction management system according to one aspect of the present disclosure includes a user terminal and a store terminal at a service station. The user terminal generates a two-dimensional code including setting information used to purchase products at the service station and displays the two-dimensional code for purchasing products at the service station. The store terminal obtains the setting information by reading the two-dimensional code displayed on the user terminal and executes processing related to the purchase based on the setting information.

A transaction management method according to one aspect of the present disclosure is executed by a user terminal having at least one processor. The transaction management method includes the steps of generating a two-dimensional code including setting information used to purchase a product at a service station, and displaying the two-dimensional code for purchasing the product at the service station.

A transaction management program according to one aspect of the present disclosure causes a computer to execute the steps of generating a two-dimensional code including setting information used to purchase products at a service station, and displaying the two-dimensional code for purchasing products at the service station.

In this aspect, the setting information used to purchase products at a service station is displayed as a two-dimensional code. Since radio waves are not required to read the two-dimensional code, radio wave transmission can be suppressed when purchasing products at a service station.

In a user terminal according to another aspect, at least one processor displays a setting screen for presetting setting information and generates a two-dimensional code including the setting information set on the setting screen. In this case, the setting information can be set outside the service station, providing a flexible mechanism for purchasing products at the service station.

In a user terminal according to another aspect, at least one processor may acquire a one-time token used to verify the identity of a customer at a service station and generate a two-dimensional code including the one-time token. In this case, the security of merchandise transactions is improved because the identity of the customer purchasing the merchandise is verified.

In a store terminal according to another aspect, the configuration information may include product information indicating a product. At least one processor may execute a purchase-related process based on the product information. In this case, specifying product information at the store is simplified or unnecessary, improving the convenience of product transactions.

In a store terminal according to another aspect, the setting information may include customer identification information that uniquely identifies a customer at the service station. At least one processor may obtain product information indicating the 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-set product information is managed by the transaction management server, and purchase-related processing is executed by the store terminal based on the product information. This simplifies or eliminates the need to specify product information at the store, improving the convenience of product transactions.

[Modification]
The present disclosure has been described in detail above based on the embodiments. However, the present disclosure is not limited to the above embodiments. Various modifications of the present disclosure are possible without departing from the spirit and scope of the present disclosure.

In the embodiment, the user terminal 91 displays a setting screen and accepts input of setting information. However, the setting information may be copied to the user terminal 91 from a different medium. For example, the customer 90 may own an NFC tag (hereinafter referred to as an "another tag") separate from the user terminal 91. The other tag may have the setting information desired by the customer 90 stored in advance. The database 30 may store the correspondence between the identifier of the other tag and the setting information. The transaction management system 1 may also provide the user terminal 91 with a transfer screen for copying the setting information. For example, the customer 90 may input the identifier of the other tag they own into the transfer screen. The transaction management system 1 may read the setting information corresponding to the input identifier of the other tag from the database 30 and transmit the setting information to the user terminal 91. The user terminal 91 may store the received setting information in a memory area. In this manner, the setting information may be copied from the other tag to the user terminal 91. Alternatively, a copy device (e.g., a reader/writer) may be installed in the store to read the setting information from the separate tag and write the setting information to the user terminal 91. The setting information may be copied from the separate tag to the user terminal 91 by operating the copy device.

In the embodiment, 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 product information inquiry to the application server 70 along with a one-time token inquiry request. The application server 70 may send the product information to the user terminal 91 along with a response to the one-time token inquiry request. The user terminal 91 may generate a two-dimensional code including the one-time token and product information acquired from the application server 70.

In another variation, point card information may be managed by an external server that manages points (hereinafter referred to as the "point management server"). The store terminal 10 may send 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 the point card number, and send the point balance to the store terminal 10. If the point card number is valid, the customer 90 may obtain points corresponding to the purchase of the product, 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 send the point card number to the external point management server and obtain the point balance.

In this disclosure, the expression "at least one processor executes a first process, executes a second process, ... executes an nth process," or an equivalent expression, refers to a concept that includes cases where the entity executing the n processes from the first process to the nth process (i.e., the processor) changes midway through. 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 among the n processes according to an arbitrary policy.

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 (processing) described above may be omitted, or the steps may be executed in a different order. Furthermore, 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 executed in addition to the steps described above.

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...payment information processing unit, 30...database, 40...payment management server, 41...credit inquiry unit, 42...payment unit, 50...first sales management server, 51...detoken unit, 52...transaction/payment management unit, 60...second sales management server, 61...transaction/payment 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.

One aspect of the present disclosure relates to a transaction management method, a store terminal, and a transaction management system .

Claims (9)

at least one processor;
the at least one processor:
generating a two-dimensional code including setting information used for purchasing products at a service station;
displaying the two-dimensional code for purchasing the product at the service station;
User terminal. the at least one processor:
displaying a setting screen for presetting the setting information;
generating the two-dimensional code including the setting information set on the setting screen;
The user terminal of claim 1 . the at least one processor:
obtaining a one-time token used to verify a customer at the service station;
generating the two-dimensional code containing the one-time token;
3. A user terminal according to claim 1 or 2. A store terminal located at a service station,
at least one processor;
the at least one processor:
By reading the two-dimensional code displayed on the user terminal, setting information used for purchasing the product at the service station is obtained;
Execute a process related to the purchase based on the setting information.
Store terminal. the setting information includes product information indicating the product,
the at least one processor executes a process related to the purchase based on the product information;
The store terminal according to claim 4. the setting information includes customer identification information that uniquely identifies a customer at the service station;
the at least one processor:
acquiring product information indicating the product from a transaction management server based on the customer identification information;
Execute a process related to the purchase based on the product information.
The store terminal according to claim 4. A transaction management system including a user terminal and a store terminal of a service station,
The user terminal,
generating a two-dimensional code including setting information used for purchasing products at a service station;
Displaying the two-dimensional code for purchasing the product at the service station;
The store terminal,
acquiring the setting information by reading the two-dimensional code displayed on the user terminal;
Execute a process related to the purchase based on the setting information.
Transaction management system. 1. A method of managing transactions executed by a user terminal having at least one processor, comprising:
generating a two-dimensional code including setting information used for purchasing products at a service station;
and displaying the two-dimensional code for purchase of the product at the service station. generating a two-dimensional code including setting information used for purchasing products at a service station;
and displaying the two-dimensional code for purchasing the product at the service station.