Sales data processing apparatus, system, and non-transitory computer readable medium

Abstract

To suppress deterioration of convenience.SOLUTION: A sales data processor includes setting means and settlement processing means. The setting means sets a plurality of types of settlement media in one transaction. The settlement processing means sequentially performs settlement processing based on the plurality of kinds of settlement media set by the setting means. The settlement processing means stops settlement processing based on another settlement medium different from one settlement medium when the settlement processing based on the one settlement medium cannot be executed.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to a sales data processing device, a system, and a program. [Background technology]

[0002] Conventionally, cash registers used in stores and the like are capable of processing payments for various payment types. The various payment types include not only non-communication-type payments such as cash payments, but also communication-type payments using payment media such as prepaid cards (see, for example, Patent Document 1). Furthermore, recent cash registers are also capable of multi-type payments (split type) using multiple types of payment media in a single transaction. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7066904 Summary of the Invention [Problem to be solved by the invention]

[0004] However, with conventional technology, if an error occurs with one of the multiple types of payment media, the transaction cannot be completed quickly, which can reduce convenience.

[0005] The present invention has been made in view of the above circumstances, and its object is to provide a technique that can prevent a decrease in convenience. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems, one aspect of the present invention is a sales data processing device that comprises a setting means for setting multiple types of payment media in a single transaction, and a payment processing means for sequentially performing payment processing based on the multiple types of payment media set by the setting means, wherein the payment processing means is configured to, if payment processing based on one payment medium cannot be executed, cancel payment processing based on other payment media different from the one payment medium.

[0007] In order to solve the above-mentioned problems, another aspect of the present invention is a system comprising a setting unit that sets multiple types of payment media for a single transaction, and a payment processing unit that sequentially performs payment processing based on the multiple types of payment media set by the setting unit, wherein if payment processing based on one payment medium cannot be executed, the payment processing unit cancels payment processing based on other payment media different from the one payment medium.

[0008] In order to solve the above-mentioned problems, another aspect of the present invention is a program that causes a computer of a sales data processing device to function as a setting means for setting multiple types of payment media in a single transaction, and a payment processing means for sequentially performing payment processing based on the multiple types of payment media set by the setting means, and is characterized in that if payment processing based on one payment medium cannot be executed, the payment processing means cancels payment processing based on other payment media different from the one payment medium. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram illustrating an example of a network configuration of a sales data processing system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram showing an example of the appearance of the registration and settlement device as seen from the customer side. [Figure 3] FIG. 2 is a diagram illustrating an example of the hardware configuration of a registration and settlement device. [Figure 4] FIG. 2 is a diagram showing an example of prepaid information stored in a prepaid information DB (database). [Figure 5] FIG. 2 is a block diagram including an example of the functional configuration of a registration settlement device. [Figure 6] 10A and 10B are diagrams showing examples of screens relating to multi-payment settings displayed on the store clerk's display unit and payment processing based on those settings. [Figure 7] 10A and 10B are diagrams showing examples of screens relating to multi-payment settings displayed on the store clerk's display unit and payment processing based on those settings. [Figure 8] 10 is a flowchart showing an example of a payment type setting process performed by a registered settlement device. [Figure 9] 10 is a flowchart showing an example of a payment execution process performed by a registered settlement device. [Figure 10] 10 is a flowchart showing a first modification of the payment type setting process relating to setting of the payment type. [Figure 11] 10 is a flowchart showing a first modification of the payment execution process relating to the execution of a payment type. [Figure 12] FIG. 10 is a diagram showing an example of a maintenance screen displayed on a settlement device according to Modification 1. DETAILED DESCRIPTION OF THE INVENTION

[0010] (Embodiment) (Network configuration of sales data processing system St) FIG. 1 is a diagram showing an example of the network configuration of a sales data processing system St according to this embodiment. The sales data processing system St is installed in various stores. The various stores include, for example, retail stores and restaurants. The retail stores include, for example, supermarkets, convenience stores, drug stores, discount stores, department stores, and various supply stores. The restaurants include, for example, fast food restaurants, restaurants, izakayas, coffee shops, cafeterias, and food courts.

[0011] The sales data processing system St shown in Fig. 1 includes a prepaid management server Sv, a store controller 10, a transaction status management device 11, a registration and settlement device 20, and a mobile terminal 30. Each device is communicatively connected via a network 55. Each device is a computer device equipped with a CPU (Central Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), a communication unit, etc. The network 55 is a LAN (Local Area Network) or WAN (Wide Area Network), and may be wired or wireless.

[0012] The prepaid management server Sv is a server device managed by a payment service provider (for example, prepaid service provider A) that handles payments using communications. The prepaid management server Sv is a payment server that manages the balances of prepaid cards and prepaid apps, and handles payments using prepaid cards and prepaid apps (hereinafter referred to as "prepaid payments"). A prepaid card is a company-specific distribution card that can be used at affiliated stores such as chain stores. A prepaid app is application software that is installed on a customer's mobile terminal 30 and can be used at affiliated stores such as chain stores. Prepaid cards and prepaid apps are each assigned prepaid identification information (customer identification information).

[0013] The prepayment management server Sv stores information including prepayment identification information and available remaining balance. The prepayment management server Sv includes a communication unit. When the communication unit receives prepayment identification information from the registered settlement device 20 (payment terminal 208), it performs payment based on the prepayment identification information and transmits the payment result to the registered settlement device 20. The communication unit may also communicate with the registered settlement device 20 via other devices such as the store controller 10 or the transaction status management device 11.

[0014] The store controller 10 stores various types of information necessary for transactions. The various types of information include a product master. The product master is a file that stores product information such as product identification information (e.g., JAN (Japanese Article Number) code), product name, and sales price for each product. The product master also includes product identification information for products that require weighing (variable weight products), product name, unit price (unit price per gram) of variable weight products, in addition to fixed-price products. In addition to the product master, the store controller 10 also stores various types of information such as inventory status, sales history, and deposit and withdrawal records. The store controller 10 also stores information related to special sales and member information.

[0015] The transaction status management device 11 displays the processing status of the registered settlement devices 20 that operate in a self-service mode, and controls the registered settlement devices 20. For example, a store clerk (monitoring store clerk) is stationed at the transaction status management device 11, and the registered settlement devices 20 are monitored by the monitoring store clerk. The transaction status management device 11 displays the status of each of the multiple registered settlement devices 20. Specifically, the transaction status management device 11 displays a split screen showing each registered settlement device 20, and displays the status of each registered settlement device 20. The monitoring store clerk supports customers who operate the registered settlement devices 20, and, when an age verification product such as alcoholic beverages is registered at the registered settlement device 20, verifies the age of the customer.

[0016] The registration and settlement device 20 is an example of a sales data processing device. The registration and settlement device 20 is a cash register device that can register and settle products. Specifically, the registration and settlement device 20 comprises a registration unit and a settlement unit. The registration unit executes a registration process to register products. In the registration process, registration information for products purchased by customers is generated. The settlement unit executes a settlement process based on the registration information generated in the registration process. Note that multiple registration and settlement devices 20 are installed in a store, but it is also possible to install only one in a store.

[0017] The registration and settlement device 20 can switch between different operation modes. The operation modes include (A) a full self-service mode, (B) a store clerk registration mode, and (C) a transaction-only mode. Each operation mode is described below.

[0018] (A) Full self-service mode is an operating mode in which the customer registers products on the device (self-service registration) and pays for the items on the device (self-service checkout). (B) The clerk registration mode is an operating mode in which a clerk registers the product and performs face-to-face or self-checkout. In face-to-face settlement, the customer faces a store clerk at the device and the settlement is performed based on the customer's operation. Note that the registered settlement device 20 can also be equipped with a change dispenser on the store clerk side. In this case, in the store clerk registration mode, instead of or in addition to face-to-face settlement, the store clerk may receive cash or the like from the customer and perform the settlement.

[0019] Self-payment is a payment process performed based on customer operation at another registered payment device 20, different from the device itself. For this reason, a registered payment device 20 in clerk registration mode outputs registration information. Outputting the registration information means transmitting the registration information to the other registered payment device 20. However, outputting the registration information may also be done by encoding the registration information and displaying it on a display medium. The display medium may be, for example, a paper medium or an electronic medium such as a smartphone. The other registered payment device 20 acquires the registration information by receiving the registration information or by reading the encoded registration information.

[0020] (C) The checkout-only mode is a mode in which self-checkout is performed by obtaining the registration information registered by the registration and settlement device 20 in the clerk registration mode. Specifically, the registration and settlement device 20 in the checkout-only mode obtains the registration information by receiving the registration information or by reading a code displayed on a display medium.

[0021] The registration and settlement device 20 may not be able to switch operating modes. For example, the registration and settlement device 20 may be a registration and settlement device that only has the function of a store clerk registration mode. Alternatively, the registration and settlement device 20 may be a settlement device that only has the function of a checkout-only mode. Alternatively, the registration and settlement device 20 may be a registration and settlement device that only has the function of a full self-service mode.

[0022] The mobile terminal 30 is a terminal device carried by a customer. For example, the mobile terminal 30 is a smartphone, a mobile phone, a tablet terminal, a wearable terminal, etc. A prepaid application is installed on the mobile terminal 30.

[0023] The sales data processing system St may also include a clerk terminal carried by a clerk. The clerk terminal may be capable of displaying a screen similar to that of the transaction status management device 11. The clerk terminal may also notify a clerk when a customer calls the clerk at the registration settlement device 20 or when fraud by a customer is detected.

[0024] In the following description, it is assumed that the registration and settlement device 20 operates in the store clerk registration mode, and that the settlement is performed face-to-face.

[0025] (Configuration example of registration and settlement device 20) Next, the configuration of the registration and settlement device 20 will be described with reference to FIGS. FIG. 2 is a diagram showing an example of the appearance of the registration and settlement device 20 as seen from the customer side. 3 is a diagram showing an example of the hardware configuration of the registration and settlement device 20. On one or both sides of the registration and settlement device 20, a counter is arranged on which a shopping basket is placed.

[0026] Registration and settlement device 20 includes CPU 201, ROM 202, RAM 203, hard disk 204, customer display unit 205, customer scanner unit 206, payment terminal 208, change dispenser 209, clerk display unit 210, key operation unit 211, clerk scanner unit 212, printing unit 213, audio output unit 214, communication unit 215, camera 216, and sign pole 220. Each unit is connected to each other via a bus so that they can communicate with each other.

[0027] The CPU 201 is a central processing unit that reads and executes various programs stored in the ROM 202 to control the operation of the registration and settlement device 20. The various programs include a sales data processing program according to this embodiment. The ROM 202 is a read-only memory that stores various programs and various other information used by the CPU 201.

[0028] The RAM 203 is a readable and writable memory that stores various information. For example, the RAM 203 stores information acquired from the outside (e.g., a product master acquired from the store controller 10) and information generated during processing. This information also includes registration information indicating registered products and payment information generated during payment.

[0029] Hard disk 204 stores various types of information. For example, hard disk 204 stores (records) imaging results (e.g., video) captured by camera 216. Hard disk 204 may store various programs executed by CPU 201, instead of ROM 202. Furthermore, hard disk 204 may store information acquired from the outside and information generated during processing, instead of RAM 203.

[0030] The customer-side display unit 205 is a touch display for customers. The customer-side display unit 205 faces the customer and displays various information related to registration and settlement. The customer-side display unit 205 also accepts various inputs related to registration and settlement from the customer. For example, when registering a product, the customer-side display unit 205 displays a preset key corresponding to the product and accepts pressing of the preset key. When paying, the customer-side display unit 205 displays multiple payment type selection buttons corresponding to multiple payment types and accepts selection of one button (one payment type) from the multiple payment type selection buttons.

[0031] The customer-side scanner unit 206 is a scanner unit for customers. Specifically, the customer-side scanner unit 206 includes an imaging unit. The imaging unit is an image sensor having an imaging element such as a CCD (Charge Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor). The imaging unit reads (images) the product. When the operator holds the product over the customer-side scanner unit 206, the imaging unit captures an image of the product. The imaging unit optically captures a code symbol (such as a barcode or two-dimensional code attached to the product) held over the imaging window, or the whole or part of the product (object).

[0032] The code symbol includes a barcode attached to the product and a store clerk code attached to the store clerk's name tag. The barcode attached to the product is a code for identifying the product, such as a JAN code, a PLU (Price Look Up) code, or an in-store code. The customer-side scanner unit 206 reads the barcode attached to the product, and the registration and settlement device 20 registers the product. Note that the reading method used by the customer-side scanner unit 206 is not limited to CCD or CMOS, and laser or pen methods are also possible.

[0033] The payment terminal 208 is a payment terminal that reads information stored on various payment media such as various cards and the mobile terminal 30, and performs various payments based on the read information. The payment terminal 208's reading methods include contact and contactless methods. Various cards include prepaid cards. The payment terminal 208 is capable of performing prepaid payments based on prepaid cards. The payment terminal 208 is also capable of performing prepaid payments using a prepaid app installed on the mobile terminal 30. For prepaid payments, the payment terminal 208 communicates with the prepaid management server Sv.

[0034] For example, in prepaid payment using a prepaid app, the mobile terminal 30 displays prepaid identification information as a payment code on the display unit of the mobile terminal. The operator (customer) has the payment terminal 208 read the payment code. Upon reading the payment code, the payment terminal 208 requests the prepaid management server Sv to deduct the amount from the balance corresponding to the prepaid identification information. When the payment is made by the prepaid management server Sv, a settlement completion notice is sent from the prepaid management server Sv to the payment terminal 208. The payment code may also be read by the customer-side scanner unit 206.

[0035] Furthermore, payments made by the payment terminal 208 are not limited to prepaid payments, but also include credit card payments, charging medium payments, code payments, etc. Credit card payments are payments based on credit cards and require inquiries (communication) with a credit card company server. Charge medium payments are payments made based on the remaining balance stored on a charging medium. Charge mediums include, for example, electronic money cards (transportation IC cards and retail IC cards) and mobile terminals. In the following, charge medium payments are referred to as electronic money payments. In electronic money payments, the payment terminal 208 sends a payment completion notification to the payment server that manages electronic money payments after the transaction is completed.

[0036] In code payment, customer identification information is displayed as a payment code such as a QR (registered trademark) code on the display of the mobile terminal 30. The operator (customer) has the customer scanner unit 206 (or store clerk scanner unit 212) read the payment code. When the registered settlement device 20 reads the payment code, it requests the code payment server to deduct the amount from the balance corresponding to the customer identification information. When the settlement is made at the code payment server, a settlement completion notification is sent from the code payment server to the registered settlement device 20 and the mobile terminal 30.

[0037] Prepaid payments, credit card payments, electronic money payments, and code payments all require communication via the network 55. Therefore, if a communication error such as a communication failure occurs on the network 55, none of these payments can be executed.

[0038] The change machine 209 is a cash settlement mechanism and performs cash settlement. The change machine 209 faces the customer side and accepts various operations and cash insertions from customers. Specifically, the change machine 209 has an insertion slot and an ejection slot for banknotes and coins. The change machine 209 calculates the amount inserted into the insertion slot, calculates the change amount, which is the difference between the inserted amount and the purchase amount, and ejects the change from the ejection slot. Note that the change machine 209 may be installed on the store clerk side in addition to being installed on the customer side. In this case, the change machine 209 may be configured to accept various operations and cash insertions from the store clerk.

[0039] The clerk-side display unit 210 is a touch display for the clerk. The clerk-side display unit 210 faces the clerk and displays various information and accepts various inputs from the clerk. The clerk-side display unit 210 displays preset keys corresponding to products and accepts product registration when the clerk operates the preset keys.

[0040] The key operation unit 211 is provided on the store clerk's side and includes various keys (hardware keys, buttons). The key operation unit 211 accepts various inputs from the store clerk. The key operation unit 211 includes registration buttons corresponding to products, and accepts product registration when the registration buttons are operated by the store clerk.

[0041] The store clerk-side scanner unit 212 is a scanner unit for use by store clerks. Specifically, the store clerk-side scanner unit 212 includes an imaging unit. The imaging unit is an image sensor having an imaging element such as a CCD or CMOS. The imaging unit reads (captures) a product. When an operator holds a product over the store clerk-side scanner unit 212, the imaging unit captures an image of the product. The imaging unit optically captures a code symbol (such as a barcode or two-dimensional code attached to the product) held over an imaging window, or the entire product or a part of the product (object). Note that the reading method used by the store clerk-side scanner unit 212 is not limited to CCD or CMOS, and laser or pen methods are also possible.

[0042] The registration and settlement device 20 performs processing based on the code read by the customer-side scanner unit 206 or the store clerk-side scanner unit 212. The registration and settlement device 20 determines the type of the read code (product code, store clerk code, payment code, etc.) by checking the value of a flag or other value indicated by a specific digit in the code, the number of digits read, etc. For example, if the registration and settlement device 20 determines that the read code is a product code, it performs product registration processing. Furthermore, if the registration and settlement device 20 determines that the read code is a store clerk code, it performs login processing.

[0043] The printing unit 213 prints and outputs various media (receipts, invoices, etc.). The printing unit 213 has a rotatable mechanism and is configured so that the media issuing port faces from the store clerk side to the customer side, and from the customer side to the store clerk side.

[0044] The audio output unit 214 outputs sounds. For example, the audio output unit 214 outputs a reading sound (scanning sound) when various codes are scanned, a sound indicating registered products (registration information), various audio guidance, warning sounds, etc. These sounds are related to product registration and payment.

[0045] The communication unit 215 is an interface for transmitting and receiving information to and from other devices (such as the prepaid management server Sv, the store controller 10, and the transaction status management device 11).

[0046] Camera 216 is attached above customer-side display unit 205. Camera 216 is a camera that continuously captures moving or still images. A CCD camera or a CMOS camera can be used for camera 216. Camera 216 captures images of customer registration and payment operations. Camera 216 also captures images of merchandise being registered and inserted bills.

[0047] The sign pole 220 is equipped with, for example, a light emitting unit (e.g., an LED (light emitting diode)) and can be illuminated in a predetermined illumination mode. The illumination mode includes color and blinking modes. The sign pole 220 can issue various notifications depending on the illumination mode. The various notifications include, for example, notifications indicating status such as in use, notifications to call a store clerk, and notifications of fraudulent activity by a customer.

[0048] (Regarding prepaid information stored in the prepaid management server) 4 is a diagram showing an example of prepaid information stored in a prepaid information DB (database). The prepaid information DB is a database that can be accessed by the prepaid management server Sv. In a store where a registered settlement device 20 according to this embodiment is installed, prepaid payments can be made using a prepaid card and a prepaid app.

[0049] As shown in FIG. 4, the prepaid information 400 includes a payment medium, prepaid identification information, and a prepaid balance. The payment medium indicates the type of payment medium used for prepaid payments. Specifically, payment mediums include prepaid cards and prepaid apps.

[0050] The prepaid identification information is identification information that identifies the prepaid card and the prepaid application. In the case of a prepaid card, the prepaid identification information is stored in a storage medium provided in the prepaid card. The storage medium is, for example, a magnetic stripe or an IC (Integrated Circuit) chip.

[0051] The prepaid balance indicates the remaining balance of the prepaid card and the prepaid app. Note that the prepaid card is, for example, a disposable card and the balance cannot be recharged (topped up). On the other hand, the prepaid app can be recharged. However, the prepaid card may also be recharged.

[0052] In addition to this information, the prepaid information DB may also include the serial number of the completed transaction, the user's name, the user's contact information, and so on.

[0053] (Regarding non-communication-based payments and communication-based payments) The registered settlement device 20 is capable of making payments. Payments include non-communication-based payments that do not use communication, and communication-based payments that do use communication. Non-communication-based payment types include cash payments and payment types such as gift certificates. Communication-based payment types (hereinafter sometimes referred to as "communication payment types") include prepaid payments, credit card payments, electronic money payments, and code payments. Communication-based payments include payments using payment media such as gift certificates and point cards, as long as they are made using communication. In this case, the registered settlement device 20 inputs an identification number assigned to a payment medium such as a gift certificate, and communicates with a payment server that makes payments based on that payment medium to inquire whether that payment medium can be used.

[0054] (About communication payment types) The communication payment type is a type corresponding to a payment provider. A payment provider is a business (company) that makes payments using communication. For example, payment providers are prepaid provider A, prepaid provider B, credit card company C1, and credit card company C2. Each payment provider has a payment server. Therefore, during payment processing, the registered settlement device 20 requests payment from a different payment server for each payment provider.

[0055] (Regarding correspondence between communication payment types and payment servers) The prepaid card a1 of prepaid company A and the prepaid card a2 of prepaid company A have the same communication payment type. When the communication payment type is the same (i.e., when the payment company is the same), the payment request is made to the same payment server (prepaid management server Sv). On the other hand, the prepaid card a1 of prepaid company A and the prepaid card b1 of prepaid company B have different communication payment types. When the communication payment types are different (i.e., when the payment companies are different), payment requests are made to different payment servers (prepaid management servers Sv). In this way, the communication payment type indicates a classification corresponding to the payment server that is the request destination (inquiry destination) in the payment process.

[0056] (Single payment and multi-payment) The registered settlement device 20 performs settlement for one transaction. Settlement includes single-item settlement and multi-item settlement. A single payment is a payment made by one payment type (e.g., cash) in the case of a non-communication-based payment. Also, a single payment is a payment made by one payment medium in the case of a communication-based payment.

[0057] Multi-kind payments include payments in which multiple types of payment media are used. Each payment media is assigned an identification number that can uniquely identify the payment media. Therefore, the multiple types of payment media used in multi-kind payments each have a different identification number. Payment media are issued by the payment service provider that provides the payment-related service. Note that multi-kind payments may also include payment types for non-communication payments (e.g., cash payments). Specifically, multi-kind payments may include, for example, cash payments and payments that use payment media.

[0058] Here, if a communication error occurs in one of the multiple payment media in a multi-type payment due to poor communication or the like, the transaction cannot be completed quickly, which can reduce convenience. Therefore, in this embodiment, even if a communication error occurs in one of the multiple payment media, the transaction can be completed quickly. Below, the functional configuration of the registration settlement device 20 according to this embodiment will be described using Figure 5.

[0059] (An example of the functional configuration of the registration settlement device 20) Fig. 5 is a block diagram showing an example of the functional configuration of the registration and settlement device 20. As shown in Fig. 5, the registration and settlement device 20 has the following functional units: a setting unit 501, a payment processing unit 502, and a display control unit 503. Each functional unit is realized by the CPU 201. That is, the CPU 201 realizes each functional unit by executing the sales data processing program according to this embodiment.

[0060] (Setting unit 501) The setting unit 501 performs various settings related to the payment of one transaction. The various settings include whether it is a single payment or a multi-item payment, and whether it is a non-communication type or a communication type. In the case of a multi-item payment, the setting unit 501 also sets the payment type and the order of payments for each payment medium.

[0061] (Single payment) The following two modes are exemplified as single payment modes set by the setting unit 501. (1) Non-communication type: In the case of a single payment of non-communication type, the setting unit 501 sets the payment type of non-communication type (for example, cash payment). (2) Communication type: In the case of a single communication type payment, the setting unit 501 sets the communication payment type (for example, prepaid company A). In setting the communication payment type, the setting unit 501 sets the payment medium (prepaid identification information) and the payment amount.

[0062] (Multiple payment methods) The following three modes are exemplified as multi-kind payment modes that can be set by the setting unit 501. (1) Non-communication type + non-communication type: When the multi-item payment includes only non-communication type payments, the setting unit 501 sets multiple non-communication type payment types (for example, cash payment and gift certificates). Note that in the multi-item payment including only non-communication type payments, the setting unit 501 can also set three or more payment types.

[0063] (2) Non-communication type + communication type: When a multi-type payment includes both communication-type and non-communication-type payments, the setting unit 501 sets the non-communication type payment type (e.g., cash payment) and the payment medium. For the payment medium, the setting unit 501 sets the identification information of the payment medium and the payment amount. Note that in a multi-type payment including both non-communication type and communication-type payments, the setting unit 501 can also set two or more non-communication type payment types and payment mediums.

[0064] (3) Communication type + communication type: When the multi-type payment includes only communication type payment, the setting unit 501 sets multiple payment media (for example, two prepaid cards). For multiple payment media, the setting unit 501 sets identification information and payment amount for each payment medium. For communication type multi-type payment, the setting unit 501 can also set three or more types of payment media.

[0065] (Multiple payment methods) In this embodiment, the multiple types of payment media are of the same communication payment type (prepaid service provider A). The multiple types of payment media are payment media with different identification information. The multiple types of payment media may be cards (prepaid cards) with different identification information, multiple types of apps (prepaid apps) with different identification information, or a combination of these.

[0066] (The order of settings is: Prepaid payment settings → Cash payment settings) When multiple types of payment media and a non-communication type of payment (e.g., cash payment) are set for multi-type payment, the setting unit 501 first accepts the settings for the multiple types of payment media. Specifically, when setting prepaid payment related to multiple types of payment media and cash payment, the setting unit 501 first accepts the settings for prepaid payment related to multiple types of payment media, and then accepts the settings for cash payment for the shortfall.

[0067] (Payment processing order: Cash payment → Prepaid payment) However, the setting unit 501 sets the execution order of the payment process so that cash payment is performed first. This makes it possible to prevent cash from being overlooked. If communication payment were performed first, there is a risk that a customer may mistakenly believe that the transaction is complete upon completion of communication payment and leave the premises. Therefore, in this embodiment, in order to prevent such a situation, cash payment is performed first in the order of payment process.

[0068] (An example of multi-payment) In this embodiment, the setting unit 501 sets the multi-kind payment methods exemplified below. Payment method 1: "Cash payment → 1st prepaid payment → 2nd prepaid payment". Payment method 2: Cash payment → First prepaid payment → Credit card payment + Second prepaid payment + Electronic money payment. The first prepaid payment and the second prepaid payment are payments related to prepaid service provider A, i.e., they are the same type of communication payment type. Furthermore, the first prepaid payment and the second prepaid payment use payment media with different prepaid identification information.

[0069] (Payment processing unit 502) The payment processing unit 502 executes payment processing based on the payment type and payment medium set by the setting unit 501. In the case of cash payment, the payment processing includes processing for inserting cash and dispensing change. In the case of communication payment, the payment processing includes processing for requesting (inquiring) payment from a predetermined payment server. In the case of multi-type payment, the payment processing unit 502 executes payment for each payment type, each payment medium, each payment amount, and in the order set by the setting unit 501. For example, the setting unit 501 executes payment processing in the order shown in payment mode 1 or payment mode 2 above.

[0070] In particular, if the payment processing unit 502 is unable to execute the payment processing (previous prepaid payment) based on one payment medium, it will suspend the payment processing (subsequent prepaid payments) based on other communication media of the same type of communication payment type as the one payment medium. Note that the same type of communication payment type corresponds to the fact that the same payment server (prepaid management server Sv) is the destination for inquiries regarding the payment, as described above.

[0071] A case where the payment process cannot be executed is a case where a payment error occurs. A payment error occurs when the payment process cannot be completed due to a communication problem such as a communication failure or a lock on the prepaid management server Sv. Specifically, if a payment error occurs in the payment process based on the first payment medium (prepaid payment), the payment processing unit 502 will stop subsequent payment processes based on the payment medium (prepaid payment).

[0072] The condition for canceling the suspension is that the transaction is completed. That is, in the transaction of the next customer, the setting unit 501 can set the payment medium to prepaid payment.

[0073] (Example of multiple payment type settings and payment screens based on those settings) Here, examples of screens displayed on the store clerk display unit 210 by the display control unit 503 will be described with reference to FIGS. 6 and 7 are diagrams showing example screens related to the multi-payment settings displayed on the store clerk display unit 210 and the payment process based on those settings. Figures 6 and 7 explain an example of the above-mentioned payment mode 1 (cash payment + first prepaid payment + second prepaid payment). In the following, the payment medium related to the prepaid payment will be explained as a prepaid card.

[0074] (Multiple payment settings) 6(A) shows the checkout screen 610. The checkout screen 610 is displayed when a specific button indicating the start of payment (for example, the subtotal button 613) is pressed. The checkout screen 610 includes a total amount field 611 and a payment type selection button 612. The total amount field 611 indicates the total amount the customer will pay in the transaction.

[0075] The payment type selection button 612 includes multiple buttons corresponding to multiple payment types, and the payment type requested by the customer is pressed. For example, the payment type selection button 612 includes a button corresponding to prepaid payment by prepaid company A and a button corresponding to prepaid payment by prepaid company B. Suppose the customer requests a prepaid card (prepaid card by prepaid company A: communication payment type) as the payment type. In this case, the store clerk presses the prepaid card button 612a corresponding to the prepaid card among the payment type selection buttons 612. When the registered settlement device 20 accepts the pressing of the prepaid card button 612a, the screen transitions to the reading notification screen 620 shown in FIG. 6(B).

[0076] FIG. 6(B) shows a read notification screen 620. The read notification screen 620 displays a notification prompting the user to read the prepaid identification information. The operator (store clerk or customer) has the payment terminal 208 read the prepaid identification information of the payment medium for the initial prepaid payment (first prepaid payment). If the payment type is a prepaid card from prepaid company A, the operator has the payment terminal 208 read the prepaid card from prepaid company A. If the payment type is a prepaid app from prepaid company A, the operator has the payment terminal 208 read the payment code (prepaid identification information) from prepaid company A displayed on the mobile terminal. The registered settlement device 20 thereby acquires and stores the prepaid identification information. The registered settlement device 20 then transitions to the quantity input screen 630 shown in FIG. 6(C).

[0077] 6(C) shows a quantity input screen 630. The quantity input screen 630 is a screen that accepts input of the payment amount for the first prepaid payment (first prepaid payment). The quantity input screen 630 includes a quantity input field 631, a payment balance field 632, a deficit amount field 633, a setting field 634, a multi-payment acceptance button 635, and a medium identification information field 636.

[0078] The quantity input field 631 is a field in which the input amount (e.g., 200 yen) is displayed as the payment amount based on the initial prepaid payment. The input amount is performed, for example, from the key operation unit 211. Specifically, the store clerk inputs the amount requested by the customer into the key operation unit 211. Note that this input may also be performed from the customer side display unit 205 based on the customer's operation.

[0079] The remaining payment amount column 632 indicates the remaining payment amount (total amount: 1,000 yen). The balance due column 633 shows the amount (¥800) obtained by subtracting the input amount (¥200) from the remaining payment amount. The setting field 634 is an area that shows the total amount (¥1,000), the set payment type (prepaid payment), and the entered payment amount (¥200).

[0080] The multi-payment acceptance button 635 is a button that accepts payment types related to multi-payment, and includes multiple buttons corresponding to the payment types. In the illustration, the multi-payment acceptance button 635 displays prepaid card payment and cash payment as selectable, but it can also display other payment types (such as prepaid app payment or credit card payment depending on the payment provider) as selectable.

[0081] The medium identification information field 636 shows the prepaid identification information (e.g., "AA0001") of the payment medium read on the reading notification screen 620 (FIG. 6(B)). If the read payment medium is a prepaid application, the medium identification information field 636 may display the customer's name instead of or in addition to the prepaid identification information.

[0082] When the registered settlement apparatus 20 receives a press of the prepaid card button 635a corresponding to a prepaid card among the multi-payment acceptance buttons 635, for example, the screen transitions to the read notification screen 640 of FIG. 6(D).

[0083] FIG. 6(D) shows a read notification screen 640. The read notification screen 640 displays a notification prompting the user to read the prepaid identification information of the payment medium related to the next prepaid payment (second prepaid payment). The operator (store clerk or customer) has the payment terminal 208 read the next prepaid identification information (prepaid identification information related to prepaid company A). As a result, the registered settlement device 20 acquires and stores the next prepaid identification information. The registered settlement device 20 also transitions to the quantity input screen 710 of FIG. 7(A).

[0084] 7(A) shows a quantity input screen 710 for inputting the payment amount of the second prepaid payment. On the quantity input screen 710, the quantity input field 631 is a field where the input amount (e.g., ¥300) is displayed as the payment amount of the second prepaid payment.

[0085] The remaining payment amount field 632 shows the remaining payment amount (total amount: ¥800). Specifically, the remaining payment amount field 632 shows the total amount (¥1,000) minus the initial prepaid payment amount (¥200). The balance due column 633 shows the amount (¥500) obtained by subtracting the input amount (¥300) from the remaining payment amount (¥800).

[0086] The setting field 634 is an area that shows the total amount (¥1,000), the set payment type (prepaid payment), and the entered payment amounts (¥200, ¥300). The medium identification information field 636 shows the prepaid identification information (for example, "AA0002") of the payment medium read on the read notification screen 640 (FIG. 6(D)).

[0087] When the registered settlement apparatus 20 receives a press of the cash button 635b corresponding to cash among the multi-kind payment reception buttons 635, for example, the screen transitions to the quantity input screen 720 of FIG. 7(B).

[0088] 7(B) shows a cash quantity input screen 720. On the quantity input screen 720, the quantity input field 631 is a field where the input amount (for example, 500 yen) is displayed as the cash payment amount.

[0089] The remaining payment amount field 632 shows the remaining payment amount (total amount: ¥500). Specifically, the remaining payment amount field 632 shows the total amount (¥1,000) minus the first prepaid payment amount (¥200) and the second prepaid payment amount (¥300). The balance due column 633 shows the amount (0 yen) obtained by subtracting the input amount (500 yen) from the remaining payment amount (500 yen). The setting field 634 is an area that shows the total amount (¥1,000), the set payment type (prepaid payment and cash payment), and the entered payment amount (¥200, ¥300, ¥500).

[0090] In this way, the setting related to the multi-item payment is completed by the setting unit 501. As described above, when the multi-item payment includes a cash payment, the setting unit 501 sets the order of execution of the payment process so that the cash payment is performed first.

[0091] (Payment processing) The payment processing unit 502 starts cash payment when 500 yen in cash is inserted into the change dispenser 209. The condition for starting cash payment may be the insertion of cash into the change dispenser 209, or may be the acceptance of a button operation to accept the start of cash payment.

[0092] Once the cash payment is complete, the payment processing unit 502 performs the first prepaid payment. Specifically, the payment processing unit 502 reads the prepaid identification information of the first prepaid payment stored earlier, and sends the prepaid identification information to the prepaid management server Sv to request the first prepaid payment. Once the payment is completed in the prepaid management server Sv, the payment processing unit 502 receives a payment completion notice from the prepaid management server Sv indicating that the payment is complete. Then, once the first prepaid payment is complete, the payment processing unit 502 performs the next prepaid payment (second prepaid payment) in the same manner. Then, once all payment processing is complete, a receipt is issued and the transaction is completed.

[0093] (If the first prepaid payment fails) If the first prepaid payment results in a payment error, i.e., if a payment completion notice is not received within a predetermined period after the first prepaid payment is requested, a similar payment error is expected for the next prepaid payment (second prepaid payment) because the same payment server (prepaid management server Sv) is used. Therefore, the registration settlement device 20 does not carry out (cancels) the next prepaid payment and transitions to a payment error screen 730 shown in Figure 7(C).

[0094] Figure 7(C) shows a payment error screen 730. The payment error screen 730 indicates a payment error related to prepaid payment. The registered settlement device 20 then transitions to the accounting screen 740 shown in Figure 7(D). The transition may be triggered by accepting a predetermined button operation or the passage of a predetermined time.

[0095] FIG. 7(D) shows a checkout screen 740 similar to FIG. 6(A). When transitioning to the checkout screen 740, the registered settlement device 20 cancels the set payment mode 1. Furthermore, when transitioning to the checkout screen 740, the registered settlement device 20 dispenses the amount of the previous cash payment (¥500) from the change dispenser 209. This allows the registered settlement device 20 to reset the payment mode without making a second prepaid payment. Note that the registered settlement device 20 may not perform the above-mentioned dispensing. Specifically, while waiting for payment, the registered settlement device 20 may retain the amount of the previous cash payment (¥500) for use in the reset payment.

[0096] (If the first prepaid payment is successful, but the second prepaid payment results in a payment error) Furthermore, if a payment error occurs with the second prepaid payment, the registered settlement device 20 displays the payment error screen 730 in Figure 7(C). Note that even if a payment error occurs, the first prepaid payment has already been completed, so payment mode 1 is not canceled. In other words, the cash payment amount (¥500) is not paid out, and the initial prepaid payment (¥200) is not canceled.

[0097] If the second prepaid payment results in a payment error, the registered settlement device 20 displays the accounting screen 750 of the outstanding amount shown in Figure 7 (E) and processes the outstanding amount corresponding to the second prepaid payment using another payment type (e.g., cash payment, credit card payment, electronic money payment).

[0098] 7(E) shows the checkout screen 750 for the outstanding amount. On the checkout screen 750, the registered settlement device 20 accepts other payment types. For example, the registered settlement device 20 accepts cash payment by pressing the cash button 635b. The amount entered as the cash payment amount (the outstanding amount of 300 yen) is entered in the quantity input field 631.

[0099] The remaining payment amount field 632 shows the remaining payment amount (total amount: ¥300), which is the unpaid amount. Specifically, the remaining payment amount field 632 shows the total amount (¥1,000) minus the payment amount of the cash payment (¥500) and the payment amount of the first prepaid payment (¥200) that have already been processed. The shortage amount column 633 shows the amount (¥0) obtained by subtracting the input amount (¥300) from the outstanding amount (¥300).

[0100] The setting field 634 shows the result of the payment performed by the payment processing unit 502. Specifically, the setting field 634 displays the payment types (and payment media) for which the payment processing has been completed as is, and displays a strikethrough indicating a payment error for a payment type for which a payment error occurred (second prepaid payment). Instead of displaying the strikethrough, the display control unit 503 may hide the item for the payment type for which a payment error occurred. Instead of or in addition to displaying the strikethrough, the display control unit 503 may display the payment type for which a payment error occurred in a display format (characters, symbols, color, size) indicating that fact. The display control unit 503 may display the payment types for which a payment error occurred (first prepaid payment and cash payment) in a display format (characters, symbols, color, size) indicating that fact.

[0101] (An example of a process related to settlement performed by the registration settlement device 20) Next, the process relating to the settlement performed by the registration and settlement apparatus 20 will be described with reference to FIGS. Figure 8 is a flowchart showing an example of the payment type setting process performed by the registration settlement device 20. In Figure 8, the registration settlement device 20 displays the accounting screen 610 (Figure 6(A)) (step S801) by accepting the pressing of a predetermined button (e.g., the subtotal button 613) indicating the start of payment. The registration settlement device 20 then accepts the payment type from the payment type selection button 612 (step S802).

[0102] Next, the registration and settlement device 20 determines whether the accepted payment type is a prepaid payment (for example, a payment based on a prepaid card or a payment based on a prepaid application) (step S803). Note that the prepaid payments in Figures 8 and 9 are prepaid payments of the same communication payment type (prepaid operator A). If the accepted payment type is not a prepaid payment (step S803: NO), for example, if cash payment, electronic money payment, or credit card payment is accepted, the registration and settlement device 20 proceeds to step S805.

[0103] On the other hand, if the accepted payment type is prepaid payment (step S803: YES), the registered settlement device 20 displays the reading notification screen 620 of Figure 6 (B) and reads the prepaid identification information from the payment medium (prepaid card or prepaid app) (step S804).

[0104] 6(C) and accepts input of the payment amount for prepaid payment (step S805). Note that even if cash payment, electronic money payment, or credit card payment is accepted in step S803, input of the payment amount for prepaid payment is also accepted in step S805.

[0105] Next, the registration settlement device 20 determines whether a deficit will occur when the input quantity amount is subtracted from the total amount (remaining payment amount) (step S806). If a deficit will occur (step S806: YES), the registration settlement device 20 returns to step S802 and repeats steps S802 to S806 until no more deficit will occur. On the other hand, if no deficit will occur in step S806 (step S806: NO), the registration settlement device 20 completes setting of the payment type (step S807) and ends the series of processes.

[0106] (Multiple payment methods) As shown in steps S802 to S806, the registered settlement device 20 accepts settings for prepaid payment and other payments until the balance is cleared. This makes it possible to set up multiple payment methods, such as those shown in payment modes 1 and 2 above. When setting up multiple payment methods, a declaration that multiple payment methods are to be set up may be accepted first (for example, before step S802).

[0107] (Single payment) Furthermore, when multiple payment methods are not used, in other words, when a single payment method is used, the registered settlement device 20 can accept the specification of the full amount after the payment method is selected (for example, immediately after step S802). This eliminates the need for the operator to input the number of items to be paid. Therefore, a single payment method (for example, cash payment only, or only one type of communication payment method (prepaid payment only, credit card payment only)) can be set with a simple operation.

[0108] (Payment execution process performed by the registered settlement device 20) 9 is a flowchart showing an example of a payment execution process performed by the registered settlement device 20. In the following, multi-item payment will be explained by appropriately exemplifying the above-mentioned payment mode 1: "cash payment + first prepaid payment + second prepaid payment."

[0109] 9, the registered settlement device 20 determines whether the payment mode set in the payment type setting process (FIG. 8) is a multi-type payment (multiple payment modes) (step S901). If it is not a multi-type payment (step S901: NO), that is, if it is a single payment, the registered settlement device 20 executes the payment process with the payment type indicated by the single payment (step S902).

[0110] The registration and settlement device 20 then determines whether the settlement process has been completed successfully (step S903). A settlement error related to a single settlement (single-type settlement type) is, for example, an error indicating that the change is full (full capacity) or end (empty) in the case of a cash settlement. Also, for example, in the case of a credit card settlement or electronic money settlement, the settlement error is an error indicating poor contact or poor reading.

[0111] In step S903, if the payment process is completed normally (step S903: YES), i.e., if a payment error does not occur, the registration and settlement device 20 ends the series of processes. On the other hand, if the payment process is not completed normally (step S903: NO), i.e., if a payment error occurs, the registration and settlement device 20 notifies the payment error for the single payment (step S904). After notifying the payment error in step S904, the registration and settlement device 20 resets the payment type (step S905) and returns to step S901. The reset payment type may be, for example, a different payment type from the payment process that resulted in the payment error, or the same payment type.

[0112] In step S901, if it is a multi-item payment (step S901: YES), the registered settlement device 20 determines whether the multi-item payment includes a cash payment (step S906). If the multi-item payment does not include a cash payment (step S906: NO), the registered settlement device 20 proceeds to processing in step S908. If the multi-item payment includes a cash payment (step S906: YES), the registered settlement device 20 accepts the insertion of cash, i.e., executes the cash payment (step S907). It is assumed that the cash payment is completed normally.

[0113] The registered settlement device 20 then executes the settlement process using the next set payment type (payment medium: for example, first prepaid payment) in the multi-item settlement (step S908). Furthermore, the registered settlement device 20 determines whether the settlement process has been completed successfully (step S909).

[0114] If the payment process is completed successfully (step S909: YES), that is, if there is no payment error, it is determined whether the next payment type (payment medium: for example, second prepaid payment) in the multi-item payment has been set (step S910). If the next payment type has not been set (step S910: NO), or if there is no balance due (if the entire payment amount has been paid), the registered settlement device 20 ends the series of processes. On the other hand, if the next payment type (payment medium) has been set (step S910: YES), the registered settlement device 20 returns to step S908 and executes the payment using the next set payment type (payment medium).

[0115] As shown in steps S908 to S910, if no payment errors occur for any payment type in a multi-type payment, the registered settlement device 20 will loop through steps S908 to S910, and once it has completed payment processing for all payment types, it will terminate the processing related to this flowchart.

[0116] In step S909, if the payment process is not completed normally (step S909: NO), that is, if a payment error occurs, the registered settlement device 20 determines whether the payment type that caused the payment error is prepaid payment (step S911).

[0117] In step S911, if the payment type that caused the payment error is not prepaid payment (step S911: NO), that is, if the payment type that caused the payment error is electronic money payment or credit card payment, the registration and settlement apparatus 20 proceeds to step S919.

[0118] On the other hand, if the payment type that caused the payment error in step S911 is prepaid payment (step S911: YES), that is, if the prepaid payment was not completed due to a communication error or the like, the registered settlement device 20 displays the payment error screen 730 of Figure 7 (C) and notifies the user of the payment error (step S912).

[0119] The registered settlement device 20 then determines whether the payment type that resulted in the payment error is the first prepaid payment (step S913). If the payment type that resulted in the payment error is the first prepaid payment (step S913: YES), the registered settlement device 20 determines whether the set multi-payment method includes cash payment (step S914).

[0120] If the multi-item payment does not include cash payment (step S914: NO), the registered settlement device 20 proceeds to step S916. On the other hand, if the multi-item payment includes cash payment (step S914: YES), that is, if cash payment has already been executed in step S907, the registered settlement device 20 dispenses cash (step S915). Furthermore, the registered settlement device 20 cancels subsequent prepaid payments (e.g., second prepaid payments) (step S916).

[0121] The registration and settlement device 20 then determines whether there are any other payment types (e.g., credit card payment or electronic money payment) that have been executed in addition to cash payment (step S917). If there are any other payment types that have been executed (step S917: YES), the registration and settlement device 20 proceeds to the processing of step S919.

[0122] On the other hand, if no other payment types have been executed in step S917 (step S917: NO), the registered settlement device 20 returns to the payment type setting process in Figure 8 (step S918) and ends the series of processes. In other words, if the first prepaid payment results in an error, the registered settlement device 20 cancels subsequent prepaid payments and returns to the payment setting process.

[0123] When returning to the payment setting process, the registered settlement device 20 may include a process different from the previous payment setting process because a payment error occurred in the prepaid payment (prepaid payment by prepaid company A). The different process may be, for example, a process that makes it impossible to select the prepaid payment (prepaid payment by prepaid company A) or a process that notifies the user that a payment error may occur in the prepaid payment (prepaid payment by prepaid company A).

[0124] In step S913, if the payment type that caused the payment error is not the initial prepaid payment (step S913: NO), for example, if the payment error is a second prepaid payment, the registered settlement device 20 displays the accounting screen 750 (Figure 7(E)) showing the balance remaining excluding the amount already paid (e.g., cash payment and initial prepaid payment) (step S919).

[0125] Then, under the operation of the store clerk, the registered settlement device 20 executes the settlement process for the remaining amount using another payment type (for example, cash payment, credit card payment, electronic money payment, etc.) (step S920), and ends the series of processes. Note that the other payment types may include the payment type of prepaid payment excluding prepaid company A (prepaid payment by prepaid company B).

[0126] (Regarding cash withdrawal) In the above-described process, steps S914 and S915 may be omitted. Specifically, if a payment error occurs in the first prepaid payment (step S913: Yes), cash may not be dispensed. In other words, cash may not be dispensed regardless of whether the payment error occurs in the first prepaid payment or in the next prepaid payment.

[0127] (About gift certificates) A further note on gift certificates: When using a gift certificate, the payment type is registered by reading the barcode information printed on the face of the gift certificate or by pressing a preset button on the gift certificate. Unlike cash, gift certificates are not inserted into the change dispenser 209, but are handed to a store clerk. Therefore, the gift certificate is in the hands of the store clerk when the barcode information is read or the preset button is pressed. Therefore, even if a communication-based payment cannot be executed due to an error or the like, the payment does not need to be canceled (withdrawn). Therefore, once a gift certificate is registered as a payment type, the registration of the gift certificate should be maintained regardless of the results of payment processing for other payment types. In other words, the registration settlement device 20 simply resets the payment type, assuming that the gift certificate will be used as is.

[0128] As explained above, the registered settlement device 20 according to this embodiment sets multiple types of prepaid cards (payment media) for the same type of communication payment type (prepaid provider A) in one transaction and sequentially performs payment processing based on the set prepaid cards. If the registered settlement device 20 is unable to execute payment processing based on one prepaid card (previous prepaid payment), it determines that there is an abnormality in the prepaid management server Sv, which is the communication destination of that prepaid payment, and suspends payment processing based on other payment media (subsequent prepaid payments) for the same type of communication payment type (prepaid payment by prepaid provider A). This eliminates the need to repeatedly attempt communication with the prepaid management server Sv where an abnormality is suspected, thereby eliminating the time required for communication and error determination and reducing transaction waiting time. Therefore, with the registration settlement device 20 according to this embodiment, even if an error occurs in a multi-type payment including a communication payment type, the transaction can be completed quickly, thereby minimizing the decrease in convenience.

[0129] In this embodiment, the multiple types of payment media include payment types (e.g., cash payment, credit card payment, electronic money payment) and payment media different from the payment type (prepaid payment). If prepaid payment based on one communication medium cannot be executed, the registered settlement device 20 performs another payment process of a different payment type (cash payment, credit card payment, electronic money payment). This means that when prepaid payment is included in the multi-type payment, even if a payment error occurs in the prepaid payment, payment processing can be performed using other payment types, allowing the transaction to be completed quickly.

[0130] In addition, in this embodiment, the registration settlement apparatus 20 displays the result of the settlement process (for example, in the setting field 634 in FIG. 7(E)). This allows the operator (store clerk) to easily grasp the results of the payment process (payment media for which payment processing has been completed and payment media for which payment processing has not been completed). Therefore, the operator can prompt the payment processing for incomplete payment media. This allows the transaction to be completed quickly and easily.

[0131] (Modification of the embodiment) Next, modified examples of the embodiment will be described. Note that in the following modified examples, the contents described in the above-mentioned embodiment will be omitted as appropriate. It is also possible to combine the respective configurations of the following modified examples and the embodiments.

[0132] (Modification 1: Example of self-payment at the registered payment device 20 in the payment-only mode) First, we will explain variant 1. In the above-mentioned embodiment, we have explained an example in which face-to-face settlement is performed at a registered settlement device 20 in clerk registration mode. In variant 1, we will explain an example in which self-settlement is performed at a registered settlement device 20 in checkout-only mode. In variant 1, the registered settlement device 20 in clerk registration mode is referred to as the "registered device," and the registered settlement device 20 in checkout-only mode is referred to as the "settlement device."

[0133] In the first modification, the sales data processing system St includes a registration device and a settlement device. The setting unit 501 (FIG. 5) is provided in the registration device. That is, the registration device sets the payment type and payment medium. The payment processing unit 502 and the display control unit 503 are provided in the settlement device. That is, the settlement device performs payment processing based on the settings of the payment type and the like set in the registration device. The settlement device also displays the results of the payment processing performed by the payment processing unit 502.

[0134] (Payment type setting process related to setting of payment type performed by registration device) Each process related to the settlement performed by the registration device and the settlement device according to the first modification will be described with reference to FIGS. Fig. 10 is a flowchart showing a first modification of the payment type setting process for setting the payment type. The process shown in Fig. 10 differs from the process shown in Fig. 8 in that steps S1001 and S1002 are added.

[0135] Step S1001: Once the registration device has completed setting the payment type (step S807), it designates a settlement device (step S1001). The registration device may designate a settlement device automatically, or may designate a settlement device by accepting an operation from a store clerk. The automatically designated settlement device may be, for example, a settlement device that is close to the registration device and is not in use.

[0136] Step S1002: The registration device transmits setting information indicating the setting of the payment type to the specified settlement device (step S1002), and ends the series of processes.

[0137] (Payment execution process related to the execution of payment performed by the settlement device) 11 is a flowchart showing a first variation of the payment execution process related to the execution of a payment type. The process shown in FIG. 11 differs from the process shown in FIG. 9 in the following points. - The processing of step S1101 has been added. The processing of step S1102 is performed instead of the processing of step S918. The processing of step S1103 is performed instead of the processing of step S919. The processing of step S1104 is performed instead of the processing of step S905.

[0138] Step S1101: The settlement device receives setting information from the registration device (Step S1101). Based on the received setting information, the settlement device determines whether the payment set in the payment type setting process (FIG. 10) is a multi-item payment (Step S901).

[0139] Step S1102: If, in step S917, there are no other payment types (e.g., credit card payment or electronic money payment) other than cash payment (step S917: NO), the settlement device prints an interruption receipt (step S1102).The settlement device then returns to the standby screen and ends the series of processes.

[0140] The interrupted receipt has transaction identification information (code information) printed on it that identifies the transaction. The customer goes to the registration device and presents the interrupted receipt to the store clerk at the registration device. The store clerk then inputs the transaction identification information printed on the interrupted receipt into the registration device using a scanning operation or the like. This allows the registration device to display the setting screen again (the setting screen before the settlement device was specified) and reset the payment type (the payment type setting process in Figure 10). Alternatively, instead of printing the interrupted receipt, it is also possible to call a store clerk and perform the settlement process on the maintenance screen.

[0141] Step S1103: If the payment type that caused the error in step S913 is not the initial prepaid payment (step S913: NO), for example, if the payment type (payment medium) that caused the error is a second prepaid payment, the settlement device calls a store clerk and displays the maintenance screen (FIG. 12) upon entry of a store clerk code (store clerk identification information) (step S1103). Then, based on the store clerk's operation, the settlement device executes payment processing for another payment type (e.g., cash payment, credit card payment, electronic money payment) for the remaining amount minus the paid amount (e.g., cash payment and initial prepaid payment), and ends the series of processes. Alternatively, instead of the process in step S1103, it is possible to print an interruption receipt and then reset the payment type on the registration device.

[0142] Step S1104: After the notification of the payment error in step S904, the registered settlement device 20 calls a store clerk and displays the maintenance screen upon entry of the store clerk code (store clerk identification information) (step S1104), ending the series of processes. Furthermore, based on the store clerk's operation on the maintenance screen, the settlement device executes the payment process for the remaining payment amount using the desired payment type. Note that instead of the process in step S1104, it is also possible to print a suspended receipt and then reset the payment type on the registration device.

[0143] (Example of maintenance screen) FIG. 12 is a diagram showing an example of a maintenance screen displayed on the settlement device according to Variation 1. The maintenance screen may be displayed on the customer display unit 205 or the store clerk display unit 210. FIG. 12(A) shows a maintenance screen 1210 when a payment error occurs in the second prepaid payment in the above-mentioned payment mode 1: "cash payment + first prepaid payment + second prepaid payment." If a payment error occurs in the first prepaid payment, an interruption receipt is printed and the maintenance screen 1210 is not displayed (step S1102 in FIG. 11).

[0144] The maintenance screen 1210 includes a payment result field 1211. The payment result field 1211 shows the result of the payment process performed by the payment processing unit 502. The payment result field 1211 indicates that the payment process has been completed for the cash payment and the first prepaid payment. Furthermore, the payment result field 1211 displays a strikethrough indicating a payment error for the payment type that resulted in a payment error (second prepaid payment). The settlement device may hide the payment type that resulted in a payment error by displaying the strikethrough. Instead of or in addition to the strikethrough, the settlement device may display the payment type that resulted in a payment error in a manner that indicates this (characters, symbols, color, size). The settlement device may also display the payment types that have been settled (first prepaid payment and cash payment) in a manner that indicates this (characters, symbols, color, size).

[0145] FIG. 12(B) shows a maintenance screen 1220 when a payment error occurs in the second prepaid payment in the above (payment mode 2: "cash + first prepaid payment + credit card payment + second prepaid payment + electronic money payment").

[0146] The payment result field 1211 indicates that the payment process has been completed for each of the cash payment, first prepaid payment, and credit card payment. Furthermore, in the payment result field 1211, a strikethrough indicating a payment error is displayed for the payment type that resulted in a payment error (second prepaid payment). Furthermore, in the payment result field 1211, for electronic money payments, "Not yet" is displayed, indicating that the payment process is not yet completed (not yet paid). The display mode indicating incompletion is not limited to simply displaying "Not yet," and other display modes (e.g., color, size) may be used to indicate this. Furthermore, the payment types that are not yet completed and the payment types for which the payment process has been completed may not be displayed separately, and may be displayed without distinction.

[0147] These maintenance screens 1210 and 1220 allow the store clerk to easily understand the payment types for which the payment process has been completed, the payment types for which a payment error has occurred, and the payment types for which the payment process has not been completed.

[0148] According to Variation 1, if a payment error occurs in the first prepaid payment, subsequent prepaid payments are stopped and an interruption receipt is issued. Therefore, the settlement device can start resetting the payment mode at the registration device or call a store clerk by reporting a payment error (step S912 in Figure 11) without waiting for the results of the payment processing of subsequent prepaid payments. Therefore, even if a payment error occurs in a multi-item payment including multiple prepaid payments, the transaction can be completed quickly.

[0149] (Example of receiving transaction identification information instead of an interruption receipt) In the first variant, the registration device acquires the transaction identification information from the suspended receipt, but this configuration is not limited to this. Instead of or in addition to this configuration, the registration device may receive the transaction identification information from the settlement device via communication. In this case, the settlement device transmits the transaction identification information to the registration device without issuing a suspended receipt. This eliminates the need for the customer to present the suspended receipt to the clerk at the registration device.

[0150] (Example in which the payment processing unit 502 is provided in the registration device) In addition, in Modification 1, the payment processing unit 502 may be provided in the registration device in addition to being provided in the settlement device. If the payment types in the multi-type settlement do not include cash payment, for example, if all payment types in the multi-type settlement are communication payment types, the payment processing unit 502 of the registered settlement device 20 can complete the payment processing. This allows the settlement to be completed without the customer having to go to the settlement device.

[0151] In addition, if the payment types in the multi-payment include cash payment, as in the above-mentioned variant example 1, the settlement device can perform the cash payment and then the communication payment type payment.

[0152] (Example of a portable registration device) In the sales data processing system St according to the first modification, the registration device is not limited to a stationary type (registration settlement device 20) but can also be a portable type. The portable registration device may be a rental terminal device prepared by the store, or a customer's terminal device (for example, a smartphone) with predetermined application software installed.

[0153] The procedure from registration to settlement when using a portable registration device is shown below. (1) The portable registration device scans the product code in response to the customer's operation. (2) The portable registration device transmits the scanned product registration information to the registration server. (3) Upon receiving the registration information, the registration server stores the registration information. (4) When the portable registration device completes the registration of the product, it accepts the selection of the payment method. (5) When the portable registration device accepts the start of settlement, it displays a two-dimensional code including identification information that identifies the registration information. (6) The settlement device scans the two-dimensional code displayed on the portable registration device and obtains the identification information. (7) The settlement device obtains registration information including identification information from the registration server and starts settlement.

[0154] Regarding (4) above, the portable registration device is equipped with a setting unit 501 (FIG. 5), which, upon completion of product registration, sets various settings related to the payment type (payment medium, payment amount, payment order, etc.). Regarding (6) and (7) above, the settlement device, upon reading the two-dimensional code, acquires the setting information set in the portable registration device. If the setting information is contained in the two-dimensional code, the settlement device may read it from the two-dimensional code, or if the setting information is stored in the registration server, may receive it from the registration server.

[0155] For example, assume that the setting information indicates payment mode 1. If the first prepaid payment results in a payment error, the settlement device (payment processing unit 502) will stop subsequent prepaid payments and issue an aborted receipt. Therefore, the settlement device can start resetting the payment mode using the portable registration device or call a store clerk by reporting a payment error (step S912 in Figure 11) without waiting for the results of the payment processing of subsequent prepaid payments. Therefore, even if a payment error occurs in a multi-item payment including multiple prepaid payments, the transaction can be completed quickly.

[0156] (Modification 2: Full Self-Service Mode Registration and Settlement Device 20) Next, Variation 2 will be described. In the above embodiment, an example in which face-to-face settlement is performed in a registered settlement device 20 in clerk registration mode is described. In Variation 2, an example in which self-payment is performed in a registered settlement device 20 in full self-service mode is described. When making a multi-item payment, the registered settlement device 20 in full self-service mode may call a clerk and perform a payment type setting process (Figure 8) based on the clerk's operation. In other words, when making a single payment, the registered settlement device 20 in full self-service mode does not call a clerk but performs settlement processing based on the customer's operation. The payment execution process (Figure 9) in full self-service mode is the same as in the embodiment.

[0157] In this way, even in full self-service mode, if a payment error occurs in a prepaid payment, a store clerk can be called by notifying the user of the payment error (step S912 in FIG. 11) without having to wait for the results of the subsequent prepaid payment processing. Therefore, by quickly calling a store clerk, the user can start resetting the payment mode or process the outstanding amount using a different payment type, thereby quickly completing the transaction.

[0158] (Variation 3: Example of canceling credit card payment if prepaid payment results in a payment error) Next, Variation 3 will be described. In the above-described embodiment, an example was described in which, if a prepaid payment results in a payment error, subsequent communication payment types of the same type (prepaid payment by prepaid service provider A) are suspended. Variation 3 will describe an example in which, if a prepaid payment results in a payment error, subsequent communication payment types of different types (e.g., credit card payment) are also suspended. In other words, if payment processing based on one payment medium is not executable, the payment processing unit 502 suspends payment processing based on a payment medium other than the one payment medium. Note that the different communication payment type is not limited to credit card payment, and can also be prepaid payment by prepaid service provider B.

[0159] In Variation 3, the setting unit 501 sets different types of communication payment types for one transaction. The communication payment types set by the setting unit 501 are, for example, prepaid payment (e.g., prepaid payment by prepaid company A) and credit payment (e.g., credit payment by credit card company C1). In Variation 3, for example, the setting unit 501 sets payment mode 3: "cash → first prepaid payment → credit payment → second prepaid payment."

[0160] If a payment based on one communication payment type results in a payment error, the payment processing unit 502 will cancel payments based on other communication payment types different from the one communication payment type. Specifically, for example, suppose a first prepaid payment results in a payment error. In this case, if there is poor communication within the store, a similar payment error is likely to occur for credit card payments. Therefore, if a first prepaid payment results in a payment error, the payment processing unit 502 will cancel subsequent credit card payments and second prepaid payments.

[0161] As described above, in a transaction, if a payment error occurs in the payment process based on a communication payment type (prepaid payment), the registered settlement device 20 according to Variation 3 suspends payments based on other communication payment types (credit card payments). In other words, if the payment process based on one payment medium cannot be executed, the registered settlement device 20 suspends payment processes based on other payment media different from the one payment medium. This eliminates the need to repeatedly attempt communication with the prepaid management server Sv where an abnormality is suspected, and also the need to attempt communication with the payment server related to credit card payments, thereby eliminating the time required for communication and error determination and reducing transaction waiting time. Therefore, with the registration settlement device 20 according to this embodiment, even if an error occurs in a multi-type payment including a communication payment type, the transaction can be completed quickly, thereby minimizing the decrease in convenience.

[0162] In the third modification, if a payment error occurs in the first prepaid payment, both the credit card payment and the second prepaid payment are cancelled, but this is not limiting, and at least one of the credit card payment and the second prepaid payment may be cancelled. Even in this case, it is not necessary to wait for the result of the payment process for the cancelled communication payment type, which can speed up the start of resetting the payment mode or the start of payment process for another payment type for the unpaid amount.

[0163] Furthermore, in the third modification, credit card payments and prepaid payments are used as examples of communication payment types, but the present invention is not limited to these. Communication payment types also include electronic money that uses communication.

[0164] (Variation 4: Example of canceling the next customer's transaction for the same communication payment type that resulted in a payment error) Next, Modification 4 will be described. In the above-described embodiment, an example was described in which, if a prepaid payment error occurs, subsequent prepaid payments in a transaction are canceled. In Modification 4, an example will be described in which, if a prepaid payment error occurs, prepaid payments in the next customer's transaction are canceled.

[0165] In Variation 4, if a payment error occurs for one communication payment type (e.g., prepaid payment) in a previous transaction, the setting unit 501 cancels the setting (selection) of prepaid payment in the next transaction. The communication payment type to be canceled may be the same communication payment type as the communication payment type that caused the payment error (e.g., prepaid payment by prepaid service provider A), or alternatively or in addition, it may be a communication payment type different from the communication payment type that caused the payment error (e.g., prepaid payment by prepaid service provider B or credit card payment).

[0166] The timing for canceling the suspension may be, for example, one of the following: When communication is restored. - A specified time has elapsed. Completion of a predetermined number of transactions.

[0167] While the setting of the communication payment type (prepaid payment) is suspended, the registered settlement device 20 will suspend the setting of that communication payment type regardless of whether it is a multi-type payment or a single payment. Note that the registered settlement device 20 may notify the user of the suspension of the communication payment type on the accounting screen 610 (FIG. 6(A)), for example.

[0168] According to the fourth modification, the setting of the communication payment type that caused the payment error in the previous transaction can be canceled for subsequent transactions of the next customer. Therefore, subsequent transactions of the next customer can be processed based on the non-communication payment type, allowing the subsequent transactions to be completed quickly.

[0169] (Variation 5: Example of manually canceling prepaid payment in the event of a payment error) Next, Modification 5 will be described. In the above-described embodiment, an example was described in which prepaid payment is automatically stopped when a payment error occurs. In Modification 5, an example will be described in which prepaid payment is manually stopped when a payment error occurs.

[0170] For example, in payment mode 1 "cash payment → first prepaid payment → second prepaid payment," if a payment error occurs in the first prepaid payment, the registered settlement device 20 will, for example, notify the operator of the payment error and also notify the operator of whether or not to make a subsequent prepaid payment (second prepaid payment).The registered settlement device 20 will cancel the subsequent prepaid payments in accordance with the selection received from the operator in the notification.

[0171] According to Variation 5, the prepaid payment is manually suspended in the event of a payment error, allowing the operator to decide whether to suspend or continue the prepaid payment. Therefore, for example, if the store clerk determines that a payment error occurred due to a temporary problem, the prepaid payment can be continued. Therefore, if the store clerk determines that the error has been resolved, the multi-item payment can be completed without having to reset the payment mode or perform payment processing for the outstanding amount using another payment type. Therefore, even if a payment error occurs, the transaction can be completed quickly.

[0172] (Variation 6: Example of including errors due to insufficient balance in payment errors) Next, we will explain Variation 6. In the above-mentioned embodiment, we have explained an example in which a payment error is an error due to poor communication. In Variation 6, instead of or in addition to this example, we will explain an example in which a payment error is an error due to insufficient balance.

[0173] In variant 6, if a previous communication payment type (first prepaid payment) in a transaction results in a payment error due to insufficient balance, the payment processing unit 502 cancels any subsequent communication payment type of the same type (second prepaid payment).

[0174] According to Variation 6, in multi-item payments, subsequent prepaid payments are canceled due to an insufficient balance in the payment medium, so the customer can be encouraged to check their balance in advance. In other words, the customer can be encouraged to check their payment medium balance at a time other than the time of payment. This has the effect of deterring customers from presenting a payment medium with an insufficient balance, thereby speeding up transactions.

[0175] (An example of not canceling a prepaid payment if the balance shortage can be covered by the next prepaid payment.) In addition, even if a previous prepaid payment (first prepaid payment) results in a payment error due to insufficient balance, the payment processing unit 502 may not cancel subsequent prepaid payments if the next prepaid payment (first prepaid payment) can make up the payment amount of the first prepaid payment.

[0176] Specifically, the payment processing unit 502 performs a first determination as to whether the cause of the payment error related to the previous prepaid payment is poor communication or insufficient balance. If the result of the first determination is poor communication, the payment processing unit 502 cancels the subsequent prepaid payment. On the other hand, if the result of the first determination is insufficient balance, the payment processing unit 502 does not immediately cancel the subsequent prepaid payment.

[0177] In this case, the payment processing unit 502 performs a second determination as to whether the shortfall in the balance can be made up in the next prepaid payment (second prepaid payment). If the result of the second determination is negative, the payment processing unit 502 cancels subsequent prepaid payments. On the other hand, if the result of the second determination is positive, the payment processing unit 502 does not cancel subsequent prepaid payments, and performs payment processing for the payment amount of the first prepaid payment in the second prepaid payment.

[0178] This allows the multi-item payment to be completed by making the second prepaid payment without having to reset the payment mode or perform payment processing for the outstanding amount for another payment type. Therefore, even if a payment error occurs due to insufficient balance, the transaction can be completed quickly.

[0179] (Variation 7: Example of checking the prepaid balance when scanning the payment medium) Next, Variation 7 will be described. In addition to Variation 6 above, Variation 7 describes an example in which the prepaid balance is checked when the payment medium is read. In Variation 7, when the registered settlement device 20 reads the prepaid identification information (step S804 in FIG. 8), it checks the prepaid balance with the prepaid management server Sv. If, upon checking the balance, the balance is found to be 0 yen, the registered settlement device 20 prohibits the use of the payment medium, i.e., it does not set up prepaid payment based on the payment medium.

[0180] The setting unit 501 also allows the prepaid settlement amount to be set with the prepaid balance as the upper limit. If the prepaid balance is equal to or greater than 1 yen, the registration and settlement device 20 may display options indicating, for example, "Cancel," "Use," and "Charge." In this case, if "Use" is selected, the registration and settlement device 20 may transition to the quantity input screen 630, which accepts input of the settlement amount.

[0181] Note that confirmation of the prepaid balance does not necessarily have to be done by inquiring of the prepaid management server Sv. For example, if the balance is stored on a prepaid card, the registration settlement device 20 can read the balance from the prepaid card. Also, if the mobile terminal 30 is configured to display the remaining balance included in the payment code, the registration settlement device 20 can read the remaining balance from the payment code. When including the remaining balance in the payment code, the mobile terminal 30 can inquire of the prepaid management server Sv about the remaining balance, or if the remaining balance is stored in its own memory, can read the remaining balance from the memory.

[0182] According to the seventh modification, it is possible to prevent payment errors caused by a small prepaid balance during payment processing. Therefore, it is possible to prevent payment errors during payment processing, and thus to complete transactions quickly.

[0183] (Variation 8: Example of different types of communication settlement to be cancelled depending on the type of communication error) Next, we will explain Variation 8. In the above-mentioned embodiment, we have explained an example in which, if an error occurs in a prepaid payment, subsequent payments of the same type of communication payment type (prepaid payment) are canceled regardless of the type of payment error. In Variation 8, we will explain an example in which, if an error occurs in a previously performed communication payment type, subsequent payments of the communication payment type are canceled depending on the type of error.

[0184] For example, suppose the payment mode is "first prepaid payment → credit card payment → second prepaid payment → cash payment → electronic money payment." For example, suppose a payment error occurs in the first prepaid payment. The registration settlement device 20 according to variant 8 determines the type of communication error in the payment error. The types of communication errors include, for example, (1) those caused by the network itself, (2) those caused by the prepaid management server Sv, and (3) those caused by the credit card payment settlement server.

[0185] In the case of (1) above, that is, if it is determined that the cause of the communication error is the network itself, since payments other than cash are made via communication, the registered settlement device 20 will cancel payments other than cash and will carry out cash payments. In the case of (2) above, that is, if it is determined that the cause of the communication error is the prepaid management server Sv, the registered settlement device 20 will cancel the first prepaid payment and the second prepaid payment, but will carry out all other payments. In the case of (3) above, that is, if it is determined that the cause of the communication error is the credit card company server, the registration and settlement apparatus 20 will cancel only the credit card settlement and will carry out the other settlements.

[0186] According to the eighth modification, even if a communication error occurs, the payment according to the available communication payment types can be executed, so that the transaction can be completed quickly.

[0187] The embodiments will be summarized below. [Title of invention] Sales data processing device, system, and program [Technical Field] The present invention relates to a sales data processing device, system, and program. [Background technology]

[0188] Conventionally, cash registers used in stores and the like are capable of processing payments for various payment types. The various payment types include not only non-communication-type payments such as cash payments, but also communication-type payments using payment media such as prepaid cards (see, for example, Patent Document 1). Furthermore, recent cash registers are also capable of multi-type payments (split type) using multiple types of payment media in a single transaction. [Prior art document] [Patent documents] [Patent Document 1] Patent No. 7066904 [Summary of the Invention] [Problem to be solved by the invention] However, with conventional technology, if an error occurs with one of the multiple types of payment media, the transaction cannot be completed quickly, which can reduce convenience. The present invention has been made in view of the above circumstances, and its object is to provide a technique that can prevent a decrease in convenience.

[0189] [Means for solving the problem] (1) In order to solve the above-mentioned problems, one aspect of the present invention is a sales data processing device comprising: a setting means for setting multiple types of payment media in a single transaction; and a payment processing means for sequentially performing payment processing based on the multiple types of payment media set by the setting means, wherein the payment processing means is configured to, if payment processing based on one payment medium cannot be executed, suspend payment processing based on other payment media different from the one payment medium. According to the above configuration, since communication with the prepaid management server Sv where an abnormality is suspected is not repeatedly attempted, the time required for communication and error determination is not incurred, and the waiting time for the transaction can be reduced. Therefore, according to the registration settlement device 20 of this embodiment, even if an error occurs in a multi-type payment including a communication payment type, the transaction can be completed quickly, and therefore a decrease in convenience can be suppressed.

[0190] (2) In the configuration of (1) above, the setting means sets a payment type corresponding to a payment service provider that makes payments using communication, and the multiple types of payment media include payment media of the same type, and the payment processing means may be configured to cancel payment processing based on other payment media of the same type if payment processing based on one payment medium is not executable. With this configuration, it is possible to start resetting the payment mode or process the outstanding amount using another payment type without waiting for the results of the subsequent prepaid payment processing. Therefore, even if a payment error occurs in a multi-type payment including multiple prepaid payments, the transaction can be completed quickly. Therefore, the registered settlement device 20 can prevent a decrease in convenience related to multi-type payments.

[0191] (3) In the configuration of (1) or (2) above, the setting means may set a payment type corresponding to a payment service provider that makes payments using communication, and the multiple types of payment media may include payment media with different payment types, and if payment processing based on one of the payment media cannot be executed, the payment processing means may perform another payment processing with a different payment type. According to the above configuration, when prepaid payment is included in the multi-type payment, even if a payment error occurs in the prepaid payment, payment processing can be performed using other payment types, so the transaction can be completed quickly.

[0192] (4) In the configuration of (1) or (2) above, a display control means may be provided for displaying the result of the payment processing performed by the payment processing means. With the above configuration, the operator (store clerk) can easily grasp the results of the payment process (payment media for which the payment process has been completed and payment media for which the payment process has not been completed). Therefore, the operator can prompt the payment process for the incomplete payment media. This allows the transaction to be completed quickly and easily.

[0193] (5) In order to solve the above-mentioned problems, another aspect of the present invention is a system comprising a setting unit that sets multiple types of payment media for a single transaction, and a payment processing unit that sequentially performs payment processing based on the multiple types of payment media set by the setting unit, wherein the payment processing unit is characterized in that, if payment processing based on one payment medium cannot be executed, it cancels payment processing based on other payment media different from the one payment medium. According to the above configuration, since communication with the prepaid management server Sv where an abnormality is suspected is not repeatedly attempted, the time required for communication and error determination is not incurred, and the waiting time for the transaction can be reduced. Therefore, according to the registration settlement device 20 of this embodiment, even if an error occurs in a multi-type payment including a communication payment type, the transaction can be completed quickly, and therefore a decrease in convenience can be suppressed.

[0194] (6) In order to solve the above-mentioned problems, another aspect of the present invention is a program that causes a computer of a sales data processing device to function as a setting means for setting multiple types of payment media in a single transaction, and a payment processing means for sequentially performing payment processing based on the multiple types of payment media set by the setting means, and the payment processing means is characterized in that, if payment processing based on one payment medium cannot be executed, it cancels payment processing based on other payment media different from the one payment medium. According to the above configuration, since communication with the prepaid management server Sv where an abnormality is suspected is not repeatedly attempted, the time required for communication and error determination is not incurred, and the waiting time for the transaction can be reduced. Therefore, according to the registration settlement device 20 of this embodiment, even if an error occurs in a multi-type payment including a communication payment type, the transaction can be completed quickly, and therefore a decrease in convenience can be suppressed.

[0195] In addition, all or part of the functions (input / output, storage, processing (including judgment)) of the registration and settlement device 20 described above may be realized by a device other than the device described as the entity that executes the function.

[0196] Specifically, in the above description, the registration and settlement device 20 has been described as having the functional units of the setting unit 501, the payment processing unit 502, and the display control unit 503. All or some of these functional units may be provided in another computer device. For example, all or some of these functional units may be provided in the store controller 10, an external server device, or another computer device. Furthermore, the number of computer devices provided with these functional units is not limited to multiple, and may be one.

[0197] Specifically, for example, instead of the registered settlement device 20, the store controller 10 or an external server device may cancel payments based on other payment media (credit card payments or prepaid payments) if a payment error occurs in the payment process based on one payment medium (prepaid payment).

[0198] In relation to the above, the registration and settlement device 20 may function as a so-called thin client specialized in the input / output interface portion with respect to product registration and settlement. In other words, the registration and settlement device 20 may accept various inputs (operation by an operator, detection by a device such as a scanner), transmit the input information (operation information, scan information, etc.) to a cloud server, receive the processing results of the cloud server based on the input information (updated screen information, device control information, etc.), and perform various outputs (display on a display unit, control of a device).

[0199] The programs for implementing the sales data processing system St and the registration and settlement device 20 described above may be recorded on a computer-readable recording medium and loaded into a computer system for execution. The term "computer system" as used herein includes hardware such as an OS and peripheral devices. The term "computer-readable recording medium" also refers to portable media such as USB (Universal Serial Bus) flash memory, SSD (Solid State Drive), flexible disk, optical magnetic disk, ROM, and CD-ROM, as well as storage devices such as hard disks built into computer systems. The term "computer-readable recording medium" also includes devices that retain a program for a certain period of time, such as volatile memory (RAM) within a computer system that acts as a server or client when the program is transmitted via a network such as the Internet or a communication line such as a telephone line. The program may also be transmitted from a computer system storing the program to another computer system via a transmission medium or by transmission waves within the transmission medium. The term "transmission medium" used to transmit the program refers to a medium capable of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The program may also be a program for implementing some of the functions described above, or may be a so-called differential file (differential program) that can implement the functions described above in combination with a program already stored in the computer system. [Explanation of symbols]

[0200] St...sales data processing system, Sv...prepaid management server, 10...store controller, 20...registration and settlement device, 201...CPU, 202...ROM, 203...RAM, 204...hard disk, 205...customer side display unit, 206...customer side scanner unit, 208...payment terminal, 209...change dispenser, 210...clerk side display unit, 211...key operation unit, 212...clerk side scanner unit, 215...communication unit, 216...camera, 501...setting unit, 502...payment processing unit, 503...display control unit

Claims

1. A setting means for setting multiple types of payment media for one transaction; a payment processing means for sequentially performing payment processing based on the plurality of types of payment media set by the setting means; Equipped with When the payment processing means is unable to execute the payment processing based on one payment medium, it suspends the payment processing based on another payment medium different from the one payment medium. A sales data processing device comprising:

2. The setting means sets a payment type corresponding to a payment business operator that performs payment using communication, The plurality of types of payment media include payment media of the same payment type, When the payment processing means is unable to execute the payment processing based on the one payment medium, it suspends the payment processing based on the other payment medium of the same type.

2. The sales data processing device according to claim 1.

3. The setting means sets a payment type corresponding to a payment business operator that performs payment using communication, The plurality of types of payment media include payment media with different payment types, the payment processing means, when it is not possible to execute the payment processing based on the one payment medium, executes another payment processing that is different from the payment type; The sales data processing device according to claim 1 or 2.

4. a display control means for displaying a result of the payment processing performed by the payment processing means; The sales data processing device according to claim 1 or 2.

5. a setting unit for setting multiple types of payment media for one transaction; a payment processing unit that sequentially performs payment processing based on the plurality of types of payment media set by the setting unit; Equipped with When the payment processing unit is unable to execute the payment processing based on one payment medium, the payment processing unit suspends the payment processing based on another payment medium different from the one payment medium. A system characterized by:

6. The computer of the sales data processing device, A setting means for setting multiple types of payment media for one transaction; a payment processing means for sequentially performing payment processing based on the plurality of types of payment media set by the setting means; It functions as When the payment processing means is unable to execute the payment processing based on one payment medium, it suspends the payment processing based on another payment medium different from the one payment medium. A program characterized by:

Images