JP7700490B2 - Trading systems and automated trading devices - Google Patents

Description

The present invention relates to a trading system, a server, an automated trading device, and a trading method, for example, to purchase and return procedures for transactions such as internet shopping.

Systems and methods are disclosed that allow users to withdraw cash from an ATM (Automated Teller Machine) without carrying a cash card. For example, Patent Document 1 discloses a technology in which a transaction center server compares link information generated by an ATM with link information received from a user's terminal that reads the link information from the ATM. This allows users to make deposits and withdrawals via an ATM using their own terminals, without the need to carry a card.

Patent Document 2 discloses a deposit/withdrawal agent system that enables a transaction to be executed at an ATM linked to a transaction server, based on a transaction requested by a customer of an affiliate that provides a deposit/withdrawal service to the affiliate's server. Patent Documents 3 and 4 disclose cardless withdrawal using a one-time password.

JP 2020-17306 A JP 2019-87063 A JP 2012-113341 A JP 2004-303057 A

The technologies described in Patent Documents 1 and 2 both allow users to withdraw cash from their own accounts. The technology described in Patent Document 1 requires users to have a mobile phone, as it is designed to read a two-dimensional code displayed on an ATM. The technology described in Patent Document 3 requires users to specify the account from which the money is to be withdrawn and to notify the consumers of the specified account number each time a store issues refunds to a large number of consumers due to the cancellation of an event, etc. Furthermore, a large amount of information must be entered during a transaction, which is time-consuming and increases the risk of incorrect input. The technology described in Patent Document 4 specifies a number that uniquely identifies a transaction at the ATM, rather than an account number, but does not perform password authentication at that time, creating a risk of fraudulent transactions.

An object of the present invention is to provide a transaction system and an automated transaction device that allow deposits and withdrawals by inputting operations into the automated transaction device.

In order to solve the above problem , the transaction system (100) of the first invention comprises a server (20, 30, 50) that registers first authentication information input at a user terminal when a payment procedure to a store or a refund procedure from the store occurs, and assigns a first procedure identification number that identifies the procedure, and an automated transaction device (40) that performs deposit and withdrawal processing based on the content of the procedure associated with the first procedure identification number, and the automated transaction device displays a screen that allows a user to input a second procedure identification number and second authentication information, and receives from the server the first authentication information that corresponds to the second procedure identification number and is registered, and performs authentication using the received first authentication information and the inputted second authentication information. A transaction system according to a second aspect of the present invention includes a server that registers first authentication information for identifying a user and assigns a first procedure identification number for identifying the procedure when a payment procedure to a store or a refund procedure from the store occurs, and an automated transaction device that accepts an input operation of a second procedure identification number and second authentication information by the user and performs a deposit/withdrawal process based on the content of the procedure associated with the first procedure identification number, wherein the registered first authentication information is a password or biometric authentication information input by a user terminal communicably connected to the server, and the server displays a selection screen on the user terminal that allows the user to select whether to deposit or withdraw money by cash or a credit card . Note that the symbols and letters in parentheses are symbols or the like added in the embodiments and do not limit the present invention.

According to the present invention, deposits and withdrawals can be made by inputting information into an automated transaction device.

1 is a configuration diagram of a trading system according to a first embodiment of the present invention; 1 is a flowchart for explaining a trading method executed by a trading system according to a first embodiment of the present invention. FIG. 13 is a diagram showing an example of an order completion email. 11 is a table showing an example of procedure request reception data. FIG. 13 is a diagram showing an example of a procedure application screen on a terminal. FIG. 13 is a diagram showing an example of a procedure application acceptance completion screen on the terminal. 11 is a table showing an example of procedure data. FIG. 13 is a diagram showing an example of a procedure ID notification email. FIG. 13 is a diagram showing an example of a transaction menu screen in an automated transaction device. FIG. 13 is a diagram showing an example of a procedure ID input screen at an automated transaction device. FIG. 13 is a diagram showing an example of a password input screen in an automated transaction device. 11 is a table showing an example of deposit/withdrawal request data. FIG. 13 is a diagram showing an example of a refund receipt screen at an automated transaction device. 13 is a table illustrating an example of completion notification data. 13 is a flowchart illustrating a trading method according to a third embodiment of the present invention.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that each figure is merely a schematic illustration to allow a sufficient understanding of this embodiment. Therefore, the present invention is not limited to the illustrated examples. In addition, in each figure, common or similar components are given the same reference numerals, and duplicate explanations thereof will be omitted.

First Embodiment
FIG. 1 is a diagram showing the configuration of a trading system according to a first embodiment of the present invention.
The transaction system 100 is configured by connecting a terminal 10, an order management server 20, a deposit/withdrawal management server 30, an ATM 40 as an automated transaction device, and a transaction server 50 via a network. Here, the terminal 10 and the ATM 40 are devices operated by a user. The transaction system 100 has a function of allowing a user to purchase a product (e.g., a concert ticket) and pay the price at the ATM 40, and to refund the purchase price in cash (currency) via the ATM 40 when the store cancels the purchase. Here, the payment of the purchase price will be described in the second embodiment, and the refund will be described in the first embodiment.

In the transaction system 100 of this embodiment, when a payment or refund is made at the ATM 40, authentication is performed using both the procedure identification number (hereinafter referred to as the procedure ID) set by the deposit/withdrawal management server 30 and the authentication information (password) set by the user on the terminal 10.

The terminal 10 is a PC (Personal Computer), mobile phone, or smartphone owned by the user. The order management server 20 is owned by a store that sells products and manages user order information. When a payment or refund procedure occurs, the order management server 20 sends the store identifier (e.g., shop number), order information (e.g., order number and amount), user information (e.g., name, email address, mobile phone number), and procedure details (payment or refund) to the deposit and withdrawal management server 30.

The deposit and withdrawal management server 30 is owned by a store (including a settlement agency) or a financial institution (bank) and manages payment procedures and refund procedures based on the user's order information, as well as account information used in the procedures. The deposit and withdrawal management server 30 also collates the user information stored in the order management server 20 with the user information received from the terminal 10 to identify the user of the terminal 10. The deposit and withdrawal management server 30 also assigns a number to identify the procedure (procedure identification number (procedure ID)) based on the order information, user information, and procedure content of the order management server 20, and notifies the terminal 10 of the procedure ID by email or the like. The deposit and withdrawal management server 30 authenticates the assigned procedure ID and the password received from the terminal 3 by collating it with the procedure ID and password entered on the display operation unit (not shown) of the ATM 40. After authentication, the deposit and withdrawal management server 30 requests the ATM 40 to make a deposit or withdrawal. If there is no password and only the procedure ID, a third party who receives the procedure ID by email can make a refund. Conversely, if there is only a password and no procedure ID, when the same user performs multiple procedures, the procedures cannot be identified.

The ATM 40 is owned by a financial institution (bank) and performs transactions such as depositing and withdrawing cash (coins). The ATM 40 accepts input of a procedure ID and password on the operation display unit. The transaction server 50 is owned by the financial institution (bank) and manages the transactions performed by the ATM 40.

(Explanation of operation)
FIG. 2 is a flowchart for explaining a trading method executed by the trading system according to the first embodiment of the present invention.
In this embodiment, a case will be described where a store cancels a product purchased by a user and the user receives a refund. In other words, it is assumed that the user has completed ordering the product and paying for it, and has received an order completion email 310 (FIG. 3) from the store. The payment can be made in cash using an ATM 40 or by credit card.

The order completion email 310 includes a "Purchaser name" field 218, a "Shop number" field 213, an "Order number" field 217, an "Amount" field 221, a "Product name" field 223, and a link URL 302. Here, the "Amount" field 221 displays the amount paid. The "Shop number" display field 213, the "Order number" display field 217, the "Amount paid" display field 221, and the "Product name" display field 223 make up the order information. The link URL 302 indicates the link for the return procedure.

In the flowchart of FIG. 2, the order management server 20 sends the order information (shop number, order number, amount, etc.), user information (purchaser name, email address, phone number, etc.), and procedure details (refund) to the cash management server 30 (SP1). This causes the store to make a request for a refund procedure for the order. After processing SP1, the cash management server 30 identifies the account to be used in the procedure ("account number" data 216 (FIG. 4)) from the identifier that identifies the store received from the order management server 20 ("shop number" data 213 (FIG. 4)), and generates and stores the procedure request acceptance data 210 (FIG. 4) that includes the "account number" data 216 (SP2).

FIG. 4 is a table showing an example of procedure request acceptance data.
The procedure request receipt data 210 is made up of a "shop number" item 213, a "store number" item 214, a "subject" item 215, an "account number" item 216, an "order number" item 217, a "purchaser name" item 218, an "email address" item 219, a "telephone number" item 220, an "amount" item 221, a "procedure content" item 222, and a "product name" item 223. Each item is made up of an "item name" column 231, a "data example" column 232, and an "explanation" column 233.

"Shop number" is an identifier that identifies the retailer (including the payment agency). "Store number" and "account" are identifiers that specify the bank account to be used. "Order number" is an order number managed by the retailer or payment agency. "Purchaser name", "email address", and "phone number" are user information, and for example, "Oki Taro", "abc@oki.com", and "090-111-2222" are entered in the "data example" column 232. "Amount" is the amount that is the subject of the procedure, and for example, "10,000" yen is entered in the "data example" column 232. "Procedure content" is either "payment" or "refund". In this case, the procedure that the user will carry out is indicated, so "refund" is entered in the "data example" column 232. "Product name" is the name of the product.

Returning to the flowchart in Figure 2, the user uses the user terminal 10 to access the link URL 302 (Figure 3) notified by the store, and enters the order information (shop number, order number, amount, etc.), user information (purchaser name, email address, phone number, etc.), procedure details (refund), and an arbitrary password to be set on a dedicated web page (procedure application screen 320 (Figure 5)).

FIG. 5 is a diagram showing an example of a procedure application screen on the terminal 10.
The procedure application screen 320 is a screen used by the user when carrying out the refund procedure on the terminal 10, and is a screen that the deposit/withdrawal management server 30 sends to the terminal 10 when the user accesses the linked URL 302 (FIG. 3). The procedure application screen 320 is configured with a "shop number" input field 213a, an "order number" input field 217a, a "payment amount" input field 221a for inputting order information, a "name" input field 218a, a "phone number" input field 220a, an "email address" input field 219a for inputting purchaser information, a pull-down menu 321 for selecting a refund method, password input fields 227a, 227b for inputting a password and a confirmation password, and a "refund application" button 328.

Here, the user fills in the order information described in the order completion email 310 (Figure 3) and fills in the purchaser information of the user himself (at the time of purchase). In addition to the option of "Receive at ATM," the pull-down menu 321 also offers, for example, "Receive by credit card (refund)." Here, "Receive at ATM" is selected. It is preferable to enter the password used at the time of purchase in the password input fields 227a and 227b, but a different password from the password used at the time of purchase may be used. Entering the password sets the password for receiving the refund. The user terminal 10 sends the entered data to the deposit/withdrawal management server 30 (SP3). As a result, the deposit/withdrawal management server 30 obtains the password set by the user.

The deposit/withdrawal management server 30 performs identity authentication by comparing the procedure request acceptance data 210 (Fig. 4) generated and stored based on the order information and user information received from the order management server 20 with the order information (e.g., order number) and user information (e.g., name, email address, mobile phone number) received from the terminal 10 (SP4). If the authentication result is OK, the password set by the user is registered as "password" data 227 (Fig. 7) and the procedure data 230 (Fig. 7) is updated (SP5). The deposit/withdrawal management server 30 sends an acceptance completion notification to the terminal 10 (SP6).

FIG. 6 is a diagram showing an example of a procedure application acceptance completion screen on terminal 10.
The procedure application acceptance completion screen 330 is a screen that the deposit/withdrawal management server 30 sends to the terminal 10 when it receives order information, user information, refund method, and password from the terminal 10. The procedure application acceptance completion screen 330 is composed of the character string "We will inform you of the ID required for the procedure when the refund is ready" and a "Close" button 331.

Returning to the flowchart in Figure 2, when the deposit/withdrawal management server 30 finishes sending the acceptance completion notification (SP6), it assigns a procedure ID (SP7) and stores it as the "Procedure ID" item 224 in the procedure request acceptance data 230 (Figure 7).

FIG. 7 is a table showing an example of procedure data.
The procedure data 230 is made up of a "Procedure ID" item 224, a "Status" item 225, a "Shop number" item 213, a "Store number" item 214, a "Subject" item 215, an "Account number" item 216, an "Order number" item 217, a "Purchaser name" item 218, an "Email address" item 219, a "Telephone number" item 220, an "Amount" item 221, a "Procedure details" item 222, a "Password" item 227, and a "Product name" item 223. Each item is made up of an "Item name" column 231, a "Data example" column 232, and a "Explanation" column 233.

Compared to the procedure request receipt data 210 (Figure 4), the procedure data 230 includes the addition of a "Procedure ID" item 224, a "Status" item 225, and a "Password" item 227.

When the deposit/withdrawal management server 30 has finished allocating the procedure ID (SP7), it notifies the terminal 10 of the procedure ID (SP8). At this time, for example, in the case of email, an email address is used, and in the case of SMS (Short Message Service), a telephone number is used.

FIG. 8 is a diagram showing an example of the procedure ID notification email.
The procedure ID notification email 340 is composed of the ``Purchaser name'' item 218, the string ``Please enter the following information and the password you set at the time of application into the ATM to receive your payment,'' the ``Procedure ID'' item 224, and the ``Refund method'' item 341.

The "Procedure ID" field 224 lists the procedure ID assigned in SP7. The "Refund Method" field 341 lists the method specified in the pull-down menu 321 on the procedure application screen 320 (Figure 5).

Returning to the flowchart of FIG. 2, when the user is notified of the procedure ID by email or the like, he/she enters the procedure ID and password on the display operation unit (not shown) of the ATM 40 serving as an automated transaction device (SP9).

FIG. 9 is a diagram showing an example of a transaction menu screen in an automated transaction device.
The transaction menu screen 350 is a menu screen displayed on the display operation section (not shown) of the ATM 40, and includes, for example, a "Deposit" button 351, a "Balance Inquiry" button 352, a "Withdrawal" button 353, a "Transfer" button 354, a "○○ Service" button 355, and a "XX Service" button 356.

FIG. 10 is a diagram showing an example of a procedure ID input screen in an automated transaction device.
The procedure ID input screen 360 is a screen that is displayed on the display operation unit of the ATM 40 when the "XX service" button 356 is touched on the transaction menu screen 350 (FIG. 9). The procedure ID input screen 360 includes a "Procedure ID" input field 224a and a "Next" button 361, and is a screen that allows the user to input a procedure ID.

FIG. 11 is a diagram showing an example of a password input screen in an automated transaction device.
The password input screen 370 is a screen that is displayed on the display operation unit of the ATM 40 when the "Next" button 361 on the procedure ID input screen 360 (FIG. 10) is touched. The password input screen 370 includes a "Password" input field 227c and a "Next" button 371, and is a screen that allows the user to input a password. The password input in the "Password" input field 227c is the same as the password input in the "Password" input fields 227a and 227b (FIG. 5).

Returning to the flowchart of FIG. 2, when the procedure ID and password are entered using the procedure ID input screen 360 (FIG. 10) and the password input screen 370 (FIG. 11) (SP9), the ATM 40 transmits the entered procedure ID and password to the deposit/withdrawal management server 30 (SP10). The deposit/withdrawal management server 30 collates (matches) the procedure ID and password received from the ATM 40 with the procedure ID numbered in SP7 and the password entered in SP3, and performs authentication (SP11). Furthermore, when the "status" item 225 (FIG. 7) of the procedure data 230 (FIG. 7) is "unprocessed" and the "procedure content" item 222 (FIG. 7) is "refund", the deposit/withdrawal management server 30 generates deposit/withdrawal request data 250 (FIG. 12) with the "processing" item 228 (FIG. 12) set to "withdrawal" (SP12). The deposit/withdrawal management server 30 transmits the generated deposit/withdrawal request data 250 to the ATM 40 (SP13).

FIG. 12 is a table showing an example of deposit/withdrawal request data.
Deposit/withdrawal request data 250 comprises a "branch number" item 214, a "subject" item 215, an "account number" item 216, a "transaction" item 228, and a "processing amount" item 229. "Branch number", "subject", and "account number" are identifiers for identifying the bank account to be processed. "Transaction" stores either a deposit or withdrawal, and in this case, "withdrawal" is stored. "Processing amount" is the amount to be processed, which in this case is the refund amount of "10,000" yen.

Returning to the flowchart in FIG. 2, when the ATM 40 receives the deposit/withdrawal request data 250 (SP13), it makes a withdrawal request to the transaction server 50 (SP14). The transaction server 50 then makes a withdrawal request to the ATM 40 (SP15). This causes the ATM 40 to display the refund receipt screen 380 (FIG. 13) on the display operation unit.

FIG. 13 is a diagram showing an example of a refund receipt screen in the automated transaction device.
The refund receipt screen 380 is a screen that is displayed on the display operation section of the ATM 40 when the "Next" button 371 is touched on the password entry screen 370 (FIG. 11). The refund receipt screen 380 comprises a "Store name" field 381, an "Amount" field 382, and a "Receive payment" button 383. The "Store name" field 381 displays the "Store name" that corresponds to the "Shop number" item 213 (FIG. 7). The "Amount" field 382 displays the refund amount (here, "\10,000").

When the user confirms the "merchant name" and "amount" and touches the "Receive payment" button 383, the ATM 40 dispenses (withdraws) cash (currency) to the user (SP16b). After dispensing the cash, the ATM 40 sends the processing result to the transaction server 50 (SP17). The transaction server 50 updates the accounting process (SP18) and sends a completion notice (e.g., procedure ID) to the ATM 40 (SP19). The ATM 40 sends the received completion notice to the deposit/withdrawal management server 30 (SP20). Based on the received completion notice, the deposit/withdrawal management server 30 updates the status item 225 (Figure 7) from "unprocessed" to "processed" (SP21). The deposit/withdrawal management server 30 then sends the received completion notice (e.g., order number, name, email address, phone number, status) to the order management server 20 (SP22), and the flow of this embodiment ends.

(Explanation of effects)
As described above, according to the transaction system 100 of this embodiment, when an ordered item is canceled, the user only needs to input an identifier for identifying the procedure (e.g., a procedure ID) and a password for identity verification into the display operation unit of the ATM 40 when receiving a refund for the item price from the ATM 40. This reduces the input burden on the user while ensuring secure transactions. Therefore, after the user sets the password, the user can receive cash (currency) from the ATM 40 empty-handed at any time, improving convenience. In addition, since existing technology is used for the method of depositing and withdrawing money from the account, modifications to the ATM 40 can be minimized.

In addition, when a store issues refunds to a large number of consumers due to the cancellation of an event, etc., it is easy to specify the account to which the money will be withdrawn and to notify consumers of the specified account number. In addition, the information entered during a transaction is automated, eliminating the hassle (e.g., checking whether an account number is correct) and reducing the risk of entering information incorrectly.

Second Embodiment
In the first embodiment, the case where a store cancels an ordered product has been described. However, the case where a product is ordered through the terminal 10 and the price of the product is paid through the ATM 40 will be described.

In the flowchart of FIG. 2, the order management server 20 sends user information and order information to the deposit/withdrawal management server 30 (SP1). The deposit/withdrawal management server 30 generates and stores data (SP2) and receives order information, user information, and a password from the terminal 10 (SP3). The deposit/withdrawal management server 30 collates the user information and order information (SP4), updates the data (SP5), sends a receipt completion notification (SP6), assigns a procedure ID (SP7), and notifies the terminal 10 of the procedure ID (SP8).

The user inputs the notified procedure ID and password into the display operation section of the ATM 40 (SP9). The ATM 40 transmits the input procedure ID and password to the deposit/withdrawal management server 30 (SP10). The deposit/withdrawal management server 30 compares and authenticates the received procedure ID and password against the password received from the terminal 10 at SP3 and the procedure ID numbered at SP7 (SP11). The deposit/withdrawal management server 30 generates deposit/withdrawal request data (SP12) and transmits it to the ATM 40 (SP13).

The ATM 40 makes a deposit request to the transaction server 50 (SP14) and receives a deposit request from the transaction server 50 (SP15). The ATM 40 accepts cash inserted by the user (SP16a) and transmits the processing result to the transaction server 50 (SP17). Thereafter, as in the first embodiment, updates (SP18), completion notices (SP19, SP20), status updates (SP21), and completion notices (SP22) are executed.

As described above, according to the transaction method of this embodiment, the user can pay for the product ordered at the terminal 10 in cash (currency) using the ATM 40. In addition, by combining this with the transaction method (refund method) of the first embodiment, the price of a canceled product can be refunded in cash (currency) using the ATM 40. In other words, it enables two-way settlement of sales and refunds in cash.

Third Embodiment
In the first embodiment, the store cancels the order, but the user can also cancel the order.

FIG. 15 is a flowchart for explaining a transaction method according to the third embodiment of the present invention, showing a flow for a user to cancel a transaction.
The user uses the terminal 10 to make a request to the order management server 20 to cancel the order (SP101). When the order management server 20 receives the order cancellation request (SP101), it makes a screen display request to the deposit/withdrawal management server 30 (SP102). When the deposit/withdrawal management server 30 receives the screen display request (SP102), it sends a refund order information registration screen to the terminal 10 (SP103). The user uses the refund order information registration screen displayed on the terminal 10 to input refund order information (order information, user information, password, etc.), and the terminal 10 transmits the input information to the deposit/withdrawal management server 30 (SP104). As a result, the deposit/withdrawal management server 30 generates and stores procedure data in a state of waiting for approval (SP105), and transmits cancellation request information to the order management server 20 (SP106). The order management server 20 confirms that the user is the one who made the purchase, approves the cancellation (SP107), and sends the cancellation approval result (order number, name, amount, etc.) to the deposit/withdrawal management server 30 (SP108). The deposit/withdrawal management server 30 compares the received cancellation approval result with the refund order information received in SP104 (SP109), assigns a procedure ID (SP110), and notifies the terminal 10 of the procedure ID by email or the like. The processing after notification of the procedure ID is the same as that after SP9 in the flowchart of FIG. 2.

As described above, according to the transaction method of this embodiment, even if a user cancels an ordered item, the deposit management server 30 can perform authentication when making a deposit or withdrawal at the automated transaction device.

(Modification)
The present invention is not limited to the above-described embodiment, and the following modifications are possible, for example.
(1) In the above embodiments, personal authentication is performed using a password, but personal authentication can also be performed using biometric authentication. In the above embodiments, payment and refund in cash (currency) are described, but the present invention can also be applied to payment and refund (charging) in electronic currency (electronic money).

(2) In each of the above embodiments, the deposit/withdrawal server 30 receives and stores (updates data) the password from the terminal 10 (SP3, SP5), assigns a procedure ID (SP7), and performs authentication by comparing these with the procedure ID and password received from the ATM 40. The ATM 40 may receive the procedure ID and password from the deposit/withdrawal server 30, and perform authentication by comparing the received procedure ID and password with the procedure ID and password entered.

(3) In the previous embodiments, the order management server 20, the deposit/withdrawal management server 30, and the trading server 50 were distinguished, but a single server may be used.

(4) In the above embodiment, the payment and refund procedures for shopping transactions were described, but by using a procedure ID and password to withdraw funds from one's own account, one can also withdraw cash (currency) from one's own account empty-handed in the event of a disaster, etc.

10 Terminal 20 Order management server 30 Deposit/withdrawal management server 40 ATM (automated transaction machine)
50 Trading server 100 Trading system 210 Procedure request reception data 222 "Procedure content" item 224 "Procedure ID" item ("Procedure identification number" item)
227 "Password" item 230 Procedure data 250 Deposit/withdrawal request data 260 Completion notification data 310 Order completion email 320 Procedure application screen 330 Procedure application acceptance completion screen 340 Procedure ID notification email (procedure identification number notification email)
350 Transaction menu screen 360 Procedure ID input screen (procedure identification number input screen)
370 Password entry screen 380 Refund receipt screen

Claims (4)

a server that registers first authentication information inputted into a user terminal when a payment procedure to a store or a refund procedure from the store occurs, and assigns a first procedure identification number for identifying the procedure;
an automated teller machine that performs deposit and withdrawal processing based on the content of the procedure associated with the first procedure identification number,
A trading system characterized in that the automated transaction device displays a screen that allows a user to input a second procedure identification number and second authentication information, receives the first authentication information that corresponds to the second procedure identification number and is registered from the server, and performs authentication using the received first authentication information and the entered second authentication information. a server that, when a payment procedure to a store or a refund procedure from a store occurs, registers first authentication information that identifies a user and assigns a first procedure identification number that identifies the procedure;
an automated teller machine that accepts an input operation of a second procedure identification number and second authentication information by the user and performs a deposit/withdrawal process based on the content of the procedure associated with the first procedure identification number,
the registered first authentication information is a password or biometric authentication information inputted by a user terminal communicably connected to the server,
A transaction system characterized in that the server displays a selection screen on the user terminal, which allows the user to select whether to deposit or withdraw money by cash or by credit card. A trading system according to claim 1 or 2 ,
A transaction system characterized in that the automated transaction device executes the payment procedure or the refund procedure using cash or electronic currency. An automated transaction device that displays a screen that allows a user to input a first procedure identification number and first authentication information, receives from a server second authentication information that corresponds to the first procedure identification number and is registered by the user, performs authentication using the received second authentication information and the first authentication information entered by the user, receives from the server the details of a procedure associated with the first procedure identification number, and performs deposit and withdrawal processing based on the received details of the procedure.

Images