EP4371052A1

EP4371052A1 - Automated payment system and method

Info

Publication number: EP4371052A1
Application number: EP22736141.7A
Authority: EP
Inventors: Philipp EDLER; Tilo FRITZHANNS
Original assignee: Giesecke and Devrient Currency Technology GmbH
Current assignee: Giesecke and Devrient Currency Technology GmbH
Priority date: 2021-07-15
Filing date: 2022-06-13
Publication date: 2024-05-22
Also published as: WO2023284995A1; CN117642760A; DE102021003664A1

Abstract

The invention relates to an automated payment method for a payment from a customer to a seller for a sequence of multiple purchase transactions, wherein the following steps are performed in a seller unit: a) registering the customer for the sequence of multiple purchase transactions; b) receiving items of billing data for each of the purchase transactions, each item comprising a purchase revenue of the purchase transaction; c) checking-out the customer for the sequence of purchase transactions; d) adding up the purchase revenues; and e) generating payment data from the added-up purchase revenues and from payment service provider data of the customer, wherein in step c) the checking-out of the customer triggers at least step e), and the customer is checked out depending on previously stored seller-specific and/or customer-specific checking-out base data, wherein the checking-out is performed automatically by determining in advance a checking-out time at which the checking-out is performed on the basis of the checking-out base data and/or by checking the plausibility of the billing data as a checking-out criterion on the basis of the checking-out base data.

Description

Automated payment system and

Method The invention relates to an automated payment system and method, preferably using a customer's mobile terminal device.

The process of paying in restaurants has not changed much in the past. Guests enter a restaurant, are usually not known there, and order and consume food and/or drinks. At the end, after they have irreversibly consumed all the products, they receive the bill and pay it, with a voluntary tip usually also being paid in many cultures. Cash, credit or debit card payment can be used - also payment methods with a mobile phone. In rather rare cases, payment is made by bank transfer, e.g. if a larger group was entertained as part of a party and the bill is delivered and paid later, or the restaurateur does not use electronic payment methods for cost reasons. These payment processes are established, accepted worldwide and differ only slightly from country to country and culture to culture.

Nevertheless, there are disadvantages that are generally perceived as annoying: In order to pay the bill, a multi-stage process involving the restaurant staff is necessary (notify the waiter that you want to pay, receive the bill for verification, select the payment method, settle the bill). Depending on the occupancy and service capacity of the restaurant, the payment process can take an undesirably long time, and the bar is closed during this time abandoned, which often leads to trouble or even disputes. The table where the guest is waiting for payment is also blocked for an unnecessarily long time. There is legislation that regulates behavior if no waiter shows up to check out in a reasonable amount of time.

If a guest wants to invite other guests, a somewhat embarrassing situation often arises when paying. Spending an evening with invited guests is often a motivation for going to a restaurant. The inviter will try to complete the payment process with the waiter as discreetly as possible, and the invitees will discreetly look away if necessary. To avoid this, the inviter often tries to find an opportune moment to settle the bill away from the table, unnoticed by the invitee.

When multiple guests split the bill, the checkout process takes a long time and can cause confusion. Guests at a table often want separate bills that reflect individual consumption. In this case, the waiter has to separate the bill by guests, collect them separately and make sure that all items are covered. This is a very cumbersome and therefore lengthy process and often leads to confusion, especially if there are items left over at the end that then have to be offset later.

EP 2081140 A1 and EP 2592584 A1 relate to the protection of wireless payment transactions that are carried out using a mobile terminal device, for example a mobile radio device, and stationary position sensors, for example RFID or NFC tags. WO 2014/105226 A1 discloses a system in which a customer automatically proceeds to process contactless payment in a department store can register, also using fixed tags. A further development of this system is described in WO 2015/034755 A1. A contactless payment method is also known from WO 2016/053975 A1, with which a user can release a payment requested by a seller using a terminal device, for example a mobile phone. In all cases, the cooperation of the customer is required.

The ideal idea of going to a restaurant is to eliminate processes that are disruptive. This includes the payment process with the participation of the guest. Switching on mobile phones and radio communication with databases (see above) does not solve this problem. The same applies to purchases that involve several individual purchase transactions.

The invention is therefore based on the object of simplifying the payment process for a sequence of several purchases, e.g. orders in a restaurant, particularly when a mobile terminal device and radio communication are used.

The invention is defined in the independent claims. The dependent claims relate to advantageous developments.

Provision is made to provide an automated payment method for a payment from a customer to a seller for a sequence of multiple purchase transactions. For this purpose, the following steps are carried out in a sales unit, e.g for the sequence of purchase transactions, d) adding up the purchase transactions, and e) generating payment data from the total purchase transactions and from the customer's payment service provider data, wherein in step c) the customer's debiting triggers at least step e), and wherein in step c) the customer's debiting is dependent on seller-specific and/or customer-specific basic write-off data is executed automatically.

The write-off is carried out automatically by determining a write-off time at which the write-off is to be carried out based on the basic write-off data and/or by checking the plausibility of the accounting data based on the basic write-off data as a write-off criterion.

The booking out is therefore preferably only carried out when the specific booking out time has been reached and/or the booking out criterion, plausibility of the billing data of the sequence of purchase transactions, has been met. Reaching of the previously determined log-off time is monitored and can trigger the log-off, in particular if the billing data received is also plausible.

The write-off time can be determined on the basis of the basic write-off data and the billing data. The automatic write-off time is thus on the one hand determined individually for the customer and/or the seller, but on the other hand is independent of an actual, possibly manual, active write-off by the customer or seller. In particular, the write-off is only carried out automatically if the write-off time has been reached and/or the write-off criterion has been met. If, on the other hand, neither the time of booking out has been reached nor the booking-out criterion has been met, or alternatively either the time of booking out has not been reached or the booking-out criterion has not been met, the customer will not be automatically booked out.

The plausibility of the billing data of the sequence of purchase transactions can be checked as soon as the specific write-off time has been reached. Alternatively or additionally, the plausibility of the billing data is checked as soon as billing data for a purchase transaction are received. In particular, the booking out can take place in this case if it is recognized on the basis of the basic booking out data that there is a sequence of purchase transactions with plausible billing data that triggers the booking out.

The automated procedure books the customer, e.g. in the form of data via his mobile device, into the seller software for several purchase transactions. This constitutes a check-in.

The customer-specific and/or seller-specific log-out base data are of course already stored before the log-in step. They can be made available to the seller unit or the seller software, which can be executed on the seller unit or called on a server.

In addition, payment service provider data is or will be stored for the customer, eg by transmission from the mobile device to the seller software. This may have happened in advance (subscription). Then purchase operations are repeatedly carried out. For each of the purchase processes, billing data, including purchase sales of the respective purchase process, are generated in the vendor software. The billing data can include billing objects (e.g. ordered products/services), prices of the billing objects, order times, etc. They are checked for plausibility using predetermined criteria, and an expected completion time of the sequence of purchase transactions is determined, preferably also on the basis of the billing data. In particular, the purchase sales are only taken from those billing data and added up for which the plausibility check was successful. If the expected completion time is reached, debit data is automatically generated from the total purchase transactions and the payment service provider data, ie without the customer having to be involved, and all purchase transactions taken into account are paid for. At the same time, the customer or his mobile end device is logged out of the seller software.

The automated payment system includes the customer's identification unit, i.e. in particular the mobile device on which executable customer software and, if applicable, the payment service provider data are stored, the seller computer on which the executable seller software is stored or from which the seller software running on a server can be called up is, and has an interface for the transmission of payment data to a payment service provider. The customer software and the seller software are designed to carry out the process mentioned when they are run on the end device or the seller's computer or the server. With the system and method according to the invention, a guest can visit a restaurant, order, eat and drink and then leave without further ado. The payment process takes place completely automatically in the background. Nevertheless, the customer preferably receives an electronic statement of his services and payments, which he can view and check during or after the visit. Ideally, however, this is not necessary at all, since the system proactively largely rules out errors.

The system/procedure has completely pushed the payment process into the background. Only the tip can still require an interaction. Depending on the security needs of the customer, security interaction may be necessary in rare cases, but also (if there is sufficient trust) left to the restaurant to remedy the situation.

The system/procedure simplifies the payment process primarily through a high degree of automation. This fundamentally shifts the risk of the business process away from the provider to the customer. Previously, the entire risk lay with the provider, as they could only check the creditworthiness of their customers when they made the final payment. This is particularly problematic in gastronomy when cheating on a drink. As a result of the invention, the customer agrees to pay in this restaurant as early as the technically supported check-in process. Safeguarding measures are in place to protect customers from incorrect bookings.

These include a plausibility check when ordering/delivering and a prediction of a check-out time for a time-controlled, automatic check-out.

plausibility check After the customer has checked in at his table, each order is checked for plausibility. This protects the customer from incorrect bookings. Predetermined criteria are used for this. For example, ordering a main course after a dessert has already been ordered or ordering new drinks a few minutes after drinks have already been ordered for all guests would be implausible and should be rejected by the system/in the process. Criteria can also be used that the system has learned from the individual customers - eg customer does not drink alcohol, is vegetarian, does not consume dessert, etc. Orders that were sorted out in the plausibility check resulted in a warning and require a separate acknowledgment by waiter and/or guest.

The plausibility check can be based on fixed rules or it can be learned automatically by the system based on individual consumer behavior. There can also be a combination of both approaches. As a basis for these self-learning algorithms, e.g. multivariate classifiers with Bayesian estimates can be used to estimate the probability of an order being correct. Such algorithms are known to the person skilled in the art, e.g ".

Check-out time prediction

When the guest leaves the restaurant, he should be checked out automatically, so that no further booking at the expense of the customer is possible. This also protects him from incorrect bookings, since the waiter does not have any other orders, e.g. those of the next guest, can be assigned to the previous guest intentionally or inadvertently. In order to predict the time of the check-out, i.e. to estimate when the end of the sequence of purchase processes, and therefore the end of the customer visit, is to be expected, preference is given to customer-independent data (e.g. typical length of stay in the restaurant, time, standard ordering processes) and/or customer-specific data (e.g. which products have been ordered so far, customer history) are used. On the basis of this data, an expected time is estimated, preferably with the aid of a model, in particular using machine learning, at which the guest has left the restaurant, ie the sequence of multiple purchases will be completed. For example, after ordering a dessert and possibly a coffee, the check-out time is not far away, as expected, while after ordering an aperitif, the guest will probably stay longer in the restaurant. The same applies to purchase transactions in a non-restaurant environment. When the expected time is reached, the guest is automatically checked out.

The advantage here is that the forecast does not have to be too precise, since the estimated time should be between the last order and shortly after the guest left. In the event of an incorrect assessment, the guest can be checked out or checked in again manually. This optionally requires confirmation by the guest in order to prevent a guest who has checked out correctly from checking in incorrectly or even fraudulently.

A check-in is preferably logged, which means that in case of doubt the entire bill would not be disputed, but only the part from the check-in again. In embodiments, a period of time is calculated from the data after which no further order is expected or the probability of a further order falling below a threshold value. For this purpose, for example, classification trees or regression methods can be used. If another order is received within this predicted period of time, the calculation is updated. Otherwise, the predicted time is reached when the time period expires.

In addition, there are the following optional security mechanisms against fraudulent intentions or incorrect charges:

1. A local presence is required. It is verified by the presence of the smartphone (e.g. scanning the QR code, contact with a Bluetooth beacon, geolocation of the smartphone). If necessary, the (non-cancelled) reservation is sufficient as proof of the customer's presence.

2. A maximum amount can be provided, which cannot be exceeded and can only be changed after a security feature has been checked, e.g. entering a password or checking a biometric feature. The maximum amount can also be determined individually by the system. The customer himself could also carry out a pre-authorization in the system for an amount X, e.g. at the time of reservation. The system can also suggest a default amount for the respective restaurant.

3. An option that increases security even further is a "veto period" for each order, which begins as soon as a push message about the order has been sent to the mobile device. Each order is only canceled after this objection period has expired (e.g. two or three minutes) activated and booked. During this time, the customer can object via his smartphone and cancel the order. The veto status of each order is optionally displayed in the kitchen. The chef can then, at his own risk, begin preparation before the deadline or wait until the deadline to prepare or deliver. In practice, it is very rare for the _kitchen to start preparing the order within two or three minutes of receiving it. Of course, the veto requires the customer to respond to the push message with their smartphone.

The invention achieves a complete relocation of the payment process to the background without a confirmation from the customer, in particular a (manual) invoice verification, being necessary at any point in time. Nevertheless, security mechanisms have been introduced to protect customers from intentional or (which is much more likely) accidental incorrect bookings. The invention provides for the plausibility check of each order to be carried out automatically and for the leaving of the restaurant (and thus the time of the check-out) to be predicted.

The use of a mobile end device that is assigned to the customer is a preferred aspect for both the method and the system, because the automated payment process can be handled particularly easily with the help of this mobile end device. The prerequisite is that the customer participates in an electronic payment system, such as that provided by PayPal, Inc., for example. The seller (the restaurant in the examples given) also participates in this payment system, which ultimately handles the money transfer. Of course, this is known to the skilled man. Insofar as the invention is described and explained here with reference to payment in a restaurant, this is purely by way of example. Rather, the invention is aimed at all payment processes in which several individual products or services are obtained in a sequence of purchase processes over a longer period of time and paid for collectively at the end. As far as a guest is mentioned, this is only to be understood as an example of a customer, and the ordering of food and drinks is only an example of the multiple purchase of individual goods or services.

In this description, “automatically” means that no release is requested and/or waited for by a user.

The invention is directed to a method of paying in such an environment. It also covers a corresponding system consisting of the devices defined in the corresponding system claim. Insofar as the description is explained below using the payment method, this should also not be interpreted as a restriction. As also explained in the exemplary embodiments, the system can handle the corresponding payment method much more.

The invention is explained in more detail below using exemplary embodiments with reference to the accompanying drawings, which also disclose essential features of the invention. These exemplary embodiments are for illustrative purposes only and are not to be construed as restrictive. For example, a description of an embodiment having a plurality of elements or components should not be construed as implying that all of those elements or components are necessary for implementation. Rather, other embodiments also contain alternative elements and components, fewer elements or components or additional elements or components. Elements or components of different exemplary embodiments can be combined with one another unless otherwise stated. Modifications and variations, which are described for one of the embodiments, may also be applicable to other embodiments. To avoid repetition, the same or corresponding elements in different figures are marked with the same reference numbers and are not explained more than once. In the figures show:

Fig. 1 is a flowchart of an embodiment of a method of payment in a restaurant and

Fig. 2 is a schematic representation of a system with which the Bezahlverfah ren is executed.

As already described above, a payment method based on a visit to a restaurant is described without this being restrictive.

1 shows a flow chart of a first embodiment of a payment method. 2 shows the associated system elements. The guest will preparatoryly register with a payment service provider with whom the restaurant also works. An app (software package) also runs on the customer's end device and interacts with a computer 4 in the restaurant.

The procedure consists of three blocks A to C:

A - Check-in: At the beginning, the guest is registered in the restaurant's computer 4 (step S1), preferably with his mobile device (alternatively, another means can also be used, such as a chip card or a machine-readable code, e.g. a QR code). The registration means that the computer 4 has access to the guest's payment service provider data, for example by transmission from the mobile terminal device 8 to the sales computer 4. The guest is usually assigned a location in the restaurant. When using the mobile terminal, messages can be exchanged between computer 4 and terminal 8.

B - Ordering/delivery phase: The guest then orders and consumes (steps S2-S7).

C-Check-out: Finally, the bill is compiled and settled automatically and the guest leaves the restaurant at approximately the same time (step S8).

Check-in (Step Sl)

When the guest enters restaurant 2, he has preferably already reserved a table (e.g. via app/website) and can be checked in by the waiter at this table.

Alternatively, he chooses a free table and checks himself in at this table using a QR code 10 attached there or automatically using a Bluetooth beacon 12 . However, the table number may have to be recorded separately due to insufficient spatial resolution of the beacon 12 .

The following check-in procedures are conceivable: The guest has already been reserved for a specific table. The waiter brings the guest to that table and the guest checks himself in at the table using QR code 10. This process achieves a high level of process security through a plausibility comparison between reservation and check-in.

The guest checks himself in with the waiter, e.g. he shows a QR code that individualizes him, which is scanned by the waiter in order to register in the sales computer 4 . Alternatively, the waiter could also show the guest an individual QR code, which the guest uses to check in. In both variants, errors in table/guest assignments are avoided.

The restaurant books the guest directly onto a table reserved for them. Then no participation of the guest is necessary.

The check-in thus preferentially assigns the guest to a table/place in the restaurant. The "delivery location" for the food, drinks or goods is then automatically determined.

Order/Delivery Phase (Steps S2-S7)

The guest orders quite traditionally from the waiter (step S2) and the waiter books the food/drinks in the sales computer 4 for the guest.

In order to avoid incorrect postings, a plausibility check is optionally provided according to steps S3, S4, which can be based, for example, on intelligent algorithms or models or standard specifications and, if necessary, also uses customer-specific data: Appears in a plausibility sibility check (step S3), the order placed in step S2 is implausible (step S4, "-" branch), the waiter is made aware of this and must confirm the correctness of the booking (step S9), otherwise it is automatically rejected. the guest must participate via his mobile device, so that an implausible booking requires explicit confirmation by the customer Possibilities for this plausibility check will be explained later.

Only if the plausibility check was successful (step S4, ,,+ branch) is the booking credited to the bill and the guest optionally receives a push message confirming the order on his mobile phone 6, but this does not require any interaction.

Check out

When the guest has finished eating and drinking, he leaves the restaurant and is automatically checked out (steps S7, S8). The invoice is created automatically and settled using the stored payment method. He then optionally receives a corresponding push message with the option of giving a tip.

In embodiments, the automatic check-out is initiated in a time-controlled manner on the basis of the orders, so that a check-out time is defined. The expected time of leaving the restaurant is estimated for each customer (step S6)—that is, not just a standard period of time in the sense of a time-out is waited for. The previous behavior of the customer and/or other customers is taken into account. Since the time does not have to be very precise (it should be after the guest's last order and no later than shortly after leaving the restaurant), the Easier to estimate, and avoid errors like checking out too early or late. If the time selected was too early, the guest can either be checked in again (by the waiter or by the guest himself), ie the method starts again in step S1. If the estimated time is reached (step S7, "+" branch), the guest is automatically booked out and the bill is closed (step S8) and the payment service provider is set to pay. In embodiments, based on standard specifications, the either global (e.g. average length of stay of all customers) or customer-specific (e.g. average length of stay of the customer concerned), the time of booking out is specified.

If the time was not reached (step S7, "-" branch), the system jumps back to step S2 (further orders possible). In step S6, the time of the expected end of the visit is repeatedly estimated or an earlier estimate is updated.

In embodiments, the guest can also check himself out after leaving the app, and the waiter can check the guest out in the system when he finds that the guest has left.

As part of step S8, an optional question is asked as to whether a tip should be given. Optionally, a tip is already preconfigured and does not have to be specified explicitly.

Then, in step S8, the total amount is determined (i.e. the invoice is created) and billed using the stored payment method, ie a payment data record is generated and sent to the payment service provider in order to collect the resulting amount of money. To implement the method, the customer preferably installs the app in his mobile phone 8 and stores data there for a payment service provider (PayPal, credit card, instant payments, ...). If he enters a restaurant 2 that supports the app, he is automatically connected to the sales computer 4 of the restaurant 2 (check-in) when the app is opened, or with the cooperation of the waiter. This can be done automatically, for example via geolocation, a Bluetooth beacon, the WLAN or a QR code that is attached to every table.

2 schematically shows a system for processing the described method as a block diagram. The system provides for several units arranged in a guest room 2, which is a concrete example of a sales room. On the one hand, the system includes the sales computer 4, in which the waiter makes a note of the guest's orders. The sales computer 4 is connected to an external central computer 6, which is provided by the payment service provider, for example PayPal, Inc., via an unspecified data connection. This central computer is not part of the system - neither is guest room 2. All that matters is that the sales computer 4 can transmit debit data in order to request a payment transaction for the amount of the final invoice from the central computer 6 . This can even take place offline later, i.e. in relation to the guest's stay.

Next is in the guest room 2 at least one mobile phone 8 of a guest TES, which is an example of a mobile device. It also has a connection to the central computer 6, with the connection not necessarily having to be maintained during the payment process. Rather, it is crucial that the guest is registered with the payment service provider and the sales computer 4 the relevant data, which this to compensate for Final invoice required by the payment service provider.

Optionally, the system also includes the QR code 10 and/or the transponder 12, which in step S2 facilitates or even fully automatically logs into the restaurant software (check-in), in particular including an assignment of the guest to the respective table .

A software package runs on the sales computer 4 and the mobile phone 8, with these software packages being designed in such a way that in communication between the sales computer 4, mobile phone 8 (possibly QR code 10 and/or transponder 12) and central computer 6 in the guest room 2 method described above can be carried out. This software package can also be a server-based web application that does not require any installation.

In order to prevent misuse if the smartphone 8 is stolen, the check-in process (step S2) could be secured using a biometric feature or a password. If necessary, maximum values that can be output per check-in process/day are preset in the system. Optionally, the maximum value depends on a security level of the correspondingly classified check-in method. Reference sign list

2 guest room 4 sales calculator

6 central computer 8 mobile phone

10 QR code

12 transponders S1-S9 step

Claims

P atentclaims 1. Automated payment method for a payment from a customer to a seller for a sequence of multiple purchases, the following steps being carried out in a vendor unit: a) logging in the customer for the sequence of multiple purchases, b) receiving billing data for each of the purchase transactions, each comprising a purchase transaction of the purchase transaction, c) debiting the customer for the sequence of purchase transactions, d) adding up the purchase transactions, and e) generating payment data from the total purchase transactions and from the customer's payment service provider data, characterized in that the customer's checking out triggers at least the step of generating the payment data, and - depending on previously stored seller-specific and/or customer-specific basic booking-out data, the booking-out is carried out automatically by a booking-out time at which the booking-out is to be carried out based on the basic booking-out data b is determined and/or the plausibility of the accounting data is checked on the basis of the basic data for derecognition as a derecognition criterion.

2. Automated payment method according to claim 1, wherein the checkout time is determined on the basis of the checkout basic data and the billing data.

3. Automated payment method according to claim 1 or 2, wherein the de-registration only takes place when the specific de-registration time has been reached and/or the de-registration criterion, plausibility of the billing data of the sequence of purchase transactions, has been met.

4. Automated payment method according to any one of the above claims, wherein

- the plausibility of the billing data of the sequence of purchase transactions is checked as soon as the specific time of booking out is reached, or

- The plausibility of the billing data is checked as soon as billing data of a purchase transaction are received, the booking out preferably only taking place when a booking-out-triggering sequence of purchase processes with plausible billing data is recognized on the basis of the basic booking-out data.

5. Automated payment method according to one of the above claims, wherein the customer is logged in using an identification unit of the customer, in particular using a mobile terminal device, a chip card and/or a machine-readable code, such as a QR code.

6. Automated payment method according to one of the above claims, wherein the following are stored before the logging in step:

- the previously stored customer-specific and/or seller-specific basic deactivation data, and/or - the customer's payment service provider data.

7. Automated payment method according to one of the above claims, wherein the previously stored basic debit data and/or the payment service provider data are provided, in particular are retrieved using a customer ID, optionally from an external server.

8. Automated payment method according to one of the above claims, comprising repeated execution of the following sub-steps in step b) for the individual purchase transactions in the sequence bl) receiving the billing data, comprising purchase transactions of an individual purchase transaction, b2) determining the time of debiting in the form of an expected completion time of the sequence of purchase transactions based on the billing data.

9. Automated payment method according to one of the above claims, wherein the plausibility check of the billing data is carried out using predetermined criteria and in step d) the purchase turnover is automatically added up from those billing data whose plausibility check was successful.

10. Automated payment method according to one of the above claims, wherein the basic debiting data comprises a typical stay in a point of sale, in which the sequence of several purchase transactions is carried out, and/or standard order processes as seller-specific data and/or a history of already purchased items as customer-specific data Products, a history of past sequences of purchase transactions and/or a number of people associated with the billing data.

11. Automated payment method according to one of the above claims, wherein a period of time is calculated on the basis of the billing data to determine the time of booking out, after which no further purchase process is expected or the probability of a further purchase process falls below a predetermined threshold value.

12. Automated payment method according to one of the above claims, wherein the deactivation time is updated after each purchase transaction.

13. Automated payment method according to one of the above claims, wherein the debiting base data is determined using methods of machine learning, such as a classification tree or a regression method.

14. Automated payment method according to one of the above claims, whereby an order for a single purchase transaction is only activated and booked after the expiry of an objection period in which the customer can object via a mobile device (8) and cancel the order .

15. Automated payment method according to one of the above claims, wherein after each purchase a message is transmitted to at least one mobile terminal (8) which contains at least some of the billing data.

16. Automated payment system comprising a mobile identification unit (8), in particular a mobile terminal device on which executable customer software can be called, a seller computer (4) on which executable seller software can be called and which has an interface for transferring transmission of payment data to a payment service provider, wherein the customer software and the seller software, in particular when running on the terminal or the seller computer (4) or a server, are designed to carry out the method according to one of claims 1 to 13.