DE102021000753A1

DE102021000753A1 - Payment method with the option of transaction-specific rights control

Info

Publication number: DE102021000753A1
Application number: DE102021000753.0A
Authority: DE
Inventors: gleich Anmelder Erfinder
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-02-13
Filing date: 2021-02-13
Publication date: 2022-08-18

Abstract

Zusammenfassung: Ein Verfahren und ein System zur Bezahlung von Waren und Dienstleistungen mit der Möglichkeit zur transaktionsspezifischen Rechtesteuerung. Zum Beispiel kann eine Transaktion eines Nutzers (A) erstellt werden und dabei mit spezifischen Rechten ausgestattet sein, wie der Einschränkung auf eine bestimmte Zeit und einen bestimmten Ort, an welchem die Transaktion durch einen anderen Nutzer (B) zur Zahlung einer Ware oder Dienstleistungen genutzt werden kann. Wenn über die Bedingungen der Transaktion Einigkeit zwischen den Nutzern besteht und beide Mitglieder des Bezahldienstes sind, kann die Bezahlung über das System abwickelt werden und dem transaktionsgebenden Nutzer in Rechnung gestellt werden. Die Bezahlung einer Ware oder Dienstleistungen durch einen Nutzer (B) kann dabei in Abhängigkeit von den Rechten der Transaktion sowohl online mittels virtueller Karte als auch physisch mittels virtueller Karte auf einem mobilen Endgerät erfolgen. Weiterhin sind Transfers und Überweisungen mit transaktionsspezifischen Rechten möglich.Abstract: A procedure and a system for the payment of goods and services with the possibility of transaction-specific rights control. For example, a transaction of a user (A) can be created and be equipped with specific rights, such as the restriction to a specific time and place at which the transaction can be used by another user (B) to pay for goods or services can be. If the users agree on the terms of the transaction and both are members of the payment service, the payment can be processed via the system and the transaction-giving user can be billed. Depending on the rights of the transaction, a user (B) can pay for goods or services either online using a virtual card or physically using a virtual card on a mobile device. Transfers and bank transfers with transaction-specific rights are also possible.

Description

Technisches Gebiettechnical field

Die vorliegende Erfindung betrifft allgemein das technische Gebiet von transaktionsbasierten Zahlungen. In verschiedenen spezifischen Beispielen wird ein Verfahren und System beschrieben, welches Einschränkung von Transaktionen und Einsatzrechte zur Durchführung von Bezahlungen zu Lasten Dritter, sowohl bei physischen als auch bei onlinebasierenden Transaktionen, ermöglicht.The present invention relates generally to the technical field of transaction-based payments. In various specific examples, a method and system is described that allows for the restriction of transactions and rights of use to make payments at the expense of third parties, both in physical and online-based transactions.

Hintergrundbackground

Das Bezahlen von Waren und Dienstleistungen ist ein zentraler Bestandteil unseres täglichen wirtschaftlichen Handelns. Beschränkte sich das Bezahlen zunächst rein auf den Austausch von Geld in Form von Bargeld, hat mit Beginn der 1970er Jahr der elektronische Zahlungsverkehr zunehmend an Bedeutung gewonnen. Seit den 2010er Jahren konnten sich darüber hinaus Bezahlverfahren mit mobilen Endgeräten unter Nutzung z. B.: der NFC-Schnittstellen eines Smartphones etablieren. Im Unterschied zu baren Transaktionen setzt der Austausch von Zahlungen im elektronischen Zahlungsverkehr die Einbindung von entsprechenden regulierten Banken oder banknahen Dienstleistern voraus. Diese wickeln dabei die eigentliche Transaktion zwischen den beteiligten Parteien ab. In 2021 stehen dem Nutzer somit sowohl offline, als auch online eine Vielzahl verschiedener Zahlungsmöglichkeiten zur Verfügung, welche jedoch stets auf dem System des Transfers einer direkt Zahlung von einem Zahlungsgeber zu einem Zahlungsempfänger basieren.Paying for goods and services is a central part of our daily economic activities. While payment was initially limited to the exchange of money in the form of cash, electronic payment transactions became increasingly important at the beginning of the 1970s. Since the 2010s, payment methods with mobile devices using e.g. B.: establishing the NFC interfaces of a smartphone. In contrast to cash transactions, the exchange of payments in electronic payment transactions requires the involvement of appropriate regulated banks or bank-related service providers. They handle the actual transaction between the parties involved. In 2021, the user will have a large number of different payment options available both offline and online, which, however, are always based on the system of transferring a direct payment from a payer to a payee.

Stand der TechnikState of the art

Mit Zahlungen per Smartphone wird seit den 2010er Jahren versucht das Bezahlen am Point-of-Sale (POS) im analogen Handeln sowie online weiter zu vereinfachen und zu beschleunigen. Die eigentliche Transaktion der Zahlung hat sich durch den Einsatz der Technik jedoch nicht weiterentwickelt und beruht weiterhin auf dem direkten Geldtransfer einer (juristischen) Person zu einer anderen unter Einbeziehung der notwendigen Kreditinstitute bzw. banknahen Dienstleister. Das sogenannte Zahlungsverfahren (Payment-Schema) regelt dabei die am Prozess beteiligten Partner und den Ablauf der Transaktion. Die bestehenden Mobile-Payment-Lösungen funktionieren dabei wie folgt:

1. Der Nutzer hinterlegt in seinem Smartphone eine bestehende Kontoverbindung oder Kreditkarte zur Zahlung
2. Bei der Zahlung wird das mobile Endgerät an das Zahlungsterminal gehalten und es findet ein Austausch der Transaktionsdaten über Funk - bspw. über Near-Field-Communication (NFC) statt.
3. Die Zahlung wird über die betroffene Bank des Zahlungsgebers an den Zahlungsempfänger transferiert. Das eigentliche Zahlungsverfahren (Payment-Schema) unterscheidet sich dabei nicht grundlegend von einer Zahlung mittels Debitkarte, bspw. einer Maestro-Karte oder einer Kreditkarte. Eine Einschränkung der Zahlung auf eine spezifische Anwendung, bestimmte Uhrzeiten, Verwendungszwecke oder andere Eigenschaften ist jedoch mit dem aktuellen Stand der Technik nicht möglich.

With payments by smartphone, attempts have been made since the 2010s to further simplify and accelerate payment at the point of sale (POS) in analogue trading and online. However, the actual transaction of the payment has not developed further through the use of technology and is still based on the direct transfer of money from one (legal) person to another, involving the necessary credit institutions or bank-related service providers. The so-called payment procedure (payment scheme) regulates the partners involved in the process and the course of the transaction. The existing mobile payment solutions work as follows:

1. The user stores an existing bank account or credit card in his smartphone for payment
2. When making a payment, the mobile device is held up to the payment terminal and the transaction data is exchanged wirelessly - e.g. via Near Field Communication (NFC).
3. The payment is transferred to the payee via the payer's bank concerned. The actual payment procedure (payment scheme) does not differ fundamentally from a payment using a debit card, e.g. a Maestro card or a credit card. However, with the current state of the art, it is not possible to limit the payment to a specific application, certain times, purposes of use or other properties.

Mit diesem Antrag wird ein technisches Verfahren beschrieben, welche die Möglichkeit zur spezifischen Einschränkung von Zahlungen und den Zahlungsablauf beschreibt.This application describes a technical procedure that describes the possibility of specifically restricting payments and the payment process.

Zu lösende technische HerausforderungTechnical challenge to solve

Das Dokument beschreibt ein technisches Verfahren, mit welchem Zahlungen innerhalb eines geschlossenen Systems eingeschränkt und kontrolliert werden können. Das System baut dabei auf die heute gängigen Bezahlverfahren auf und kombiniert diese mit dem vorliegenden beschriebenen Prozess zu einem neuen Bezahlverfahren.The document describes a technical procedure with which payments can be restricted and controlled within a closed system. The system builds on the current payment methods and combines them with the process described here to create a new payment method.

Offenbarung der ErfindungDisclosure of Invention

Die Erfindung wird durch die beigefügten unabhängigen Ansprüche definiert. Zusätzliche Merkmale und Vorteile der hier offenbarten Konzepte sind in der folgenden Beschreibung dargelegt. Teilweise werden sie auch durch die Beschreibung nahegelegt oder können aus der Praxis der beschriebenen Technologien gelernt werden. Die Merkmale und Vorteile der Konzepte lassen sich mittels der in den beigefügten Ansprüchen herausgestellten Instrumente und Kombinationen umsetzen und erzielen.The invention is defined by the appended independent claims. Additional features and advantages of the concepts disclosed herein are set forth in the following description. In some cases, they are also suggested by the description or can be learned from the practice of the technologies described. The features and advantages of the concepts can be implemented and attained by means of the instruments and combinations set forth in the appended claims.

Die vorliegende Offenbarung beschreibt ein Verfahren und eine Anordnung zur Einschränkung von Zahlungen auf spezifische Merkmale. Die Zahlungen können in dem Verfahren dabei auf die folgenden Parameter bzw. Bedingungen beschränkt werden:

• Geographischer Ort (Umkreis oder genauer Ort)
• Spezifische Zeit oder Zeitspanne
• Freigabe bestimmter Rechnungen / Zahlungen mit Nachweis (Beleganforderung)
• Bestimmte Dienstleistungen / Händler / Branchen
• Bestimmte Webadresse
• Auswahl zwischen Online / Offline-Zahlungen
• (Definition der) Betragshöhe
• Frequenz der Zahlung (wiederkehrende oder einmalige Transaktion)
• Währung der Transaktion
• Bestimmte Empfängerdaten für eine Überweisung - mindestens die Kontonummer (im SEPA-Raum: IBAN) und Daten der Bank (im SEPA-Raum optional: BIC)

The present disclosure describes a method and an arrangement for restricting payments to specific characteristics. The payments can be limited to the following parameters or conditions in the process:

• Geographical location (radius or exact location)
• Specific time or period of time
• Approval of certain invoices / payments with proof (request for receipt)
• Certain services / merchants / industries
• Specific web address
• Choice between online / offline payments
• (Definition of) amount
• Frequency of payment (recurring or one-off transaction)
• Transaction currency
• Certain recipient data for a transfer - at least the account number (in the SEPA area: IBAN) and data of the bank (in the SEPA area optional: BIC)

Der Nutzer hat dabei die Möglichkeit nur einzelne Einschränkungen durchzuführen, oder auch mehrere Einschränkungen (Bedingungen) parallel zu wählen - bspw. durch die Auswahl einer Uhrzeit und eines bestimmten Ortes.The user has the option of only carrying out individual restrictions, or of selecting several restrictions (conditions) at the same time - e.g. by selecting a time and a specific location.

Das Verfahren kann dabei sowohl bei Zahlungen am Point-of-Sale als auch bei reinen Onlinetransaktionen und Geldtransfers / Überweisungen durchgeführt werden.The procedure can be carried out both for payments at the point of sale and for purely online transactions and money transfers / transfers.

Der Nutzer muss sich einmalig auf einer Plattform anmelden und registrieren. Das Verfahren gleicht dabei dem Autorisierungsprozess einer Bank und setzt die Vorlage und Speicherung der essentiellen persönlichen Daten nach der aktuellen Gesetzgebung voraus, was aktuell u.a. die Meldeadresse und eine Ausweisung mittels Ausweisdokument umfasst. Dieser Prozess dauert nur wenige Minuten.The user has to log in and register once on a platform. The procedure is similar to the authorization process of a bank and requires the submission and storage of the essential personal data in accordance with current legislation, which currently includes the registration address and identification by means of an identification document. This process only takes a few minutes.

Nach der Registrierung des Kunden wird ein eigenes Konto eröffnet. Dieses Konto umfasst ein Zahlungsverkehrskonto und eine virtuelle Kreditkarte bzw. Debitkarte zur Bezahlungen von Warte und Dienstleistungen.After the customer has registered, their own account will be opened. This account includes a payment transaction account and a virtual credit card or debit card for the payment of waiting and services.

Der Nutzer koppelt sein nun eröffnetes Konto der Lösung mit einem eigenen Zahlungsmittel, z. B.: einem Konto oder einer eigenen Kreditkarte. Dieses Konto wird als mögliches Abrechnungskonto benötigt und ermöglicht die Nutzung der Lösung auch als klassische (Mobile)-Payment-Lösung.The user couples the solution account that has now been opened with their own means of payment, e.g. E.g.: an account or your own credit card. This account is required as a possible billing account and also enables the solution to be used as a classic (mobile) payment solution.

Nach der Einrichtung stehen dem Nutzer die Möglichkeiten der Lösung offen. Jeder Anwender kann innerhalb des Systems einem anderen Anwender Rechte zur Nutzung seiner Konten mittels einer rechtegesteuerten Transaktion einräumen oder diese beanspruchen.After the setup, the user has the options of the solution. Each user can grant or claim rights to another user to use their accounts within the system by means of a rights-controlled transaction.

Figurenlistecharacter list

Um bestmöglich darzustellen, wie die oben beschriebenen Ausführungsformen umgesetzt werden, und um weitere Vorteile und Merkmale der Offenbarung zu definieren, folgt nachstehend eine detailliertere Beschreibung, die durch die beigefügten Zeichnungen veranschaulicht wird. Diese Zeichnungen geben nur exemplarische Ausführungsformen der Erfindung wieder und sind daher nicht als in ihrem Umfang einschränkend aufzufassen. Die Beispiele werden anhand der beigefügten Zeichnungen mit zusätzlichen Angaben und Details beschrieben und erläutert:

1 zeigt eine beispielhafte Umsetzung in einem Vier-Parteien-Bezahlverfahren
2 zeigt eine beispielhafte Umsetzung in einem Drei-Parteien-Bezahlverfahren
3A zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät
3B zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Ortsbeschränkung
3C zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät- Eingabe Zeitbeschränkung
3D zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät- Eingabe Händlerbeschränkung
3E zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Branchenbeschränkung
3F zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Besondere Ereignisse / Aktionsbeschränkungen
3F zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Online / Offline Beschränkungen
3G zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Online / Offline Beschränkungen
3H zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Bestätigung mittels 2-Faktor Authentifizierung
4 zeigt die Einrichtung einer Bezahlung mit transaktionsspezifischer Rechtesteuerung
5 zeigt die Bezahlung am Point of Sales mit einer rechtegesteuerten Transaktion
6 zeigt die Onlinebezahlung mit einer rechtegesteuerten Transaktion
] 7 zeigt ein Ablaufdiagramm einer Transaktion nach 4
8 zeigt eine Datentabelle einer Transaktion
9 zeigt die Zusammenführung mehrerer rechtegesteuerter Transaktionen zu einer gemeinsamen Transaktion
10 zeigt ein Ablaufdiagramm einer Transaktion nach 4 mit der Notwendigkeit eines Belegnachweises zur Zahlung
11 zeigt eine Beispielhafte Umsetzung bei einem Geldtransfer / Übertrag / Überweisung
12 zeigt ein Ablaufdiagramm bei einer Transaktion nach 11

In order to best illustrate how the embodiments described above are implemented and to define further advantages and features of the disclosure, a more detailed description follows below, illustrated by the accompanying drawings. These drawings represent only exemplary embodiments of the invention and are therefore not to be construed as limiting its scope. The examples are described and explained using the attached drawings with additional information and details:

1 shows an exemplary implementation in a four-party payment method
2 shows an exemplary implementation in a three-party payment method
3A shows an exemplary embodiment of the input mask of a rights-controlled transaction on a mobile device
3B shows an exemplary embodiment of the input mask of a rights-controlled transaction on a mobile device - input location restriction
3C shows an exemplary embodiment of the input mask of a rights-controlled transaction on a mobile device - input time limit
3D shows an exemplary embodiment of the input mask of a rights-controlled transaction on a mobile terminal device entry dealer restriction
3E shows an exemplary execution of the input mask of a rights-controlled transaction on a mobile device - input sector restriction
3F shows an exemplary embodiment of the input mask of a rights-controlled transaction on a mobile device - input of special events / action restrictions
3F shows an exemplary execution of the input mask of a rights-controlled transaction on a mobile device - input online / offline restrictions
3G shows an exemplary execution of the input mask of a rights-controlled transaction on a mobile device - input online / offline restrictions
3H shows an exemplary execution of the input mask of a rights-controlled transaction on a mobile device - confirmation using 2-factor authentication
4 shows how to set up a payment with transaction-specific rights control
5 shows payment at the point of sale with a rights-controlled transaction
6 shows online payment with a rights-controlled transaction
] 7 shows a flow chart of a transaction 4
8th shows a data table of a transaction
9 shows the merging of several rights-controlled transactions into a common transaction
10 shows a flow chart of a transaction 4 with the need for proof of payment
11 shows an exemplary implementation for a money transfer / transfer / transfer
12 shows a flowchart for a transaction 11

1 Darstellung des Bezahlverfahrens am Beispiel eines Vier-Parteien-Bezahlsystems

(101) Mobiles Endgerät inkl. Lösungs-Applikation (Nutzer A) - mit Hilfe der mobilen Applikation und unter Nutzung einer virtuellen Bezahlkarte wird eine Bezahlung an einem Kartenterminal getätigt. Optional kann in der mobilen Applikation der Beleg der Transaktion mittels eines Fotos erfasst und mit der Transaktion verknüpft werden. Weiterhin erfasst das Gerät nach Zustimmung des Nutzers den genauen geographischen Standort und die Geräteuhrzeit.
(102) OCR-Server - Bei Nutzung der Beleg-Archivierung wird der fotografierte Beleg an den OCR-Server zur Erkennung der Daten gesendet und dort analysiert.
(103) System Server - Der System Server stellt das zentrale Kommunikationselement dar und übernimmt die zentralen Koordination für die Freigabe der Zahlungen. Der System Server verarbeitet die von der mobilen Applikation oder dem Portal übertragenen Bezahldaten sowie die geographischen Daten und die Geräteuhrzeit. Eine Kommunikation des System Servers erfolgt mit der Invoice Database (106) zum Abgleich der Bezahldaten nach Abschluss der Transaktion, wobei in der Invoice Database der Zahlbeleg mit der hinterlegten Zahlung abgeglichen wird. Bei einer Zahlung mit den Bankdaten einer Drittperson mittels einer rechtegesteuerten Transaktion wird über den PUSH Server (126) der Zahlbeleg an das Benutzerkonto von Nutzer B (Mobile Device 125 / Webportal 128) gesendet. Weiterhin kommuniziert der System Server mit dem Transaktionsserver (107) zum Abgleich der Bezahlanfrage mit bestehenden rechtegesteuerte Transaktionen und Erlaubnissen. Daneben verfügt der System Server über eine zentralen Schnittstelle - Dritt API (129) zur Übergabe von Daten an mögliche Drittsysteme. Für die Hinterlegung von eigenen Bankdaten und Kreditkartendaten des Nutzers A und zur Verknüpfung mit dem Nutzer A verfügt der System Server darüber hinaus über eine direkte Verbindung zum Payment Server (114)
(104) Customer Database - Vom System Server wird über die Customer Database abgefragt, ob es sich bei der Anfrage um ein gültiges Konto handelt und gleicht diese mit den hinterlegten Nutzerdaten ab. Alle relevanten Nutzer-Stammdaten werden dabei in der Customer Database gespeichert. Im Falle einer nichterfolgreichen Abfrage wird über den System Server an den PUSH Server (126) eine Nachricht gesendet, dass die Transaktion aufgrund fehlender Kundendaten nicht möglich ist.
(105) Fraud Database - Nach einer erfolgreichen Abfrage der Kundendaten in der Customer Database wird eine Abfrage der Fraud Datenbank durchgeführt. In dieser werden bekannte Betrugsfälle und Betrugsversuche sowohl von Händlern als auch von Kunden gespeichert. Im Falle eines Betrugsfalls werden die Daten der Anfrage in der Datenbank gespeichert und über den System Server (103) an den Push Server (126) eine Zahlungsablehnung gemeldet. Diese Ablehnung wird dem Nutzer A inklusiver einer kurzen Nachricht in der Applikation (101) angezeigt.
(106) Invoice Database - In der Invoice Database werden alle Rechnungsbelege als Bilddatei und in die ausgelesenen Informationen als Datenbankeinträge gespeichert.
(107) Transaktionsserver - Auf dem Transaktionsserver werden alle rechtegesteuerte Transaktionen gespeichert und verarbeitet. Der Transaktionsserver spricht dabei sowohl mit dem System Server (103) als auch dem Payment Server (114). Der Transaktionsserver gleicht alle relevanten Informationen der Zahlungsanfrage mit den hinterlegten Datenbanken ab. Hierzu zählen die folgenden Datenbanken: Location Database (108), Merchant Database (109), Customer Location Database (110), Industry Database (111) und rechtegesteuerte Transaktion Database (112)
(108) Location Database - Die Location Database gleicht die Daten abgespeicherter rechtegesteuerter Transaktion-Zahlungen mit der Hinterlegung eines Ortes ab und überprüft dabei die Ortsdaten mit einem unabhängigen Geolocation Server (113) auf Übereinstimmungen. Weiterhin wird mit Hilfe des Geolocation Servers (113) ein regelmäßiger Abgleich von Ortsdaten von Händlern aus Merchant Database (109) durchgeführt.
(109) Merchant Database - In der Merchant Database sind Händler, Dienstleiter und sonstige Unternehmungen mit Bezahlmöglichkeiten gelistet bei welchem eine rechtegesteuerte Transaktion-Bezahlmöglichkeit eingerichtet wurde. Die Bezahldaten werden dabei standartgemäß mit hinterlegten, erlaubten Zahlungen bei spezifischen Händlern hinterfragt und bei Bedarf autorisiert.
(110) Customer Location Database - Mit Hilfe der Customer Location Database werden die Ortsdaten des Nutzers gespeichert und zur Verbesserung der Genauigkeit von Transaktionen wiederkehrenden Zahlungen aus Sicherheitsgründen gespeichert. Weiterhin erfolgt hier ein regelmäßiger Abgleich der gemeldeten Ortsdaten mit dem Geolocation Server (113)
(111) Industry Database - Die Industry Database enthält eine Liste von Industrien/ Branchen und gleicht diese regelmäßig mit der Merchant Database (110) ab. Weiterhin werden die Bezahldaten auch hier mit einer bestehenden rechtegesteuerten Transaktion überprüft, so dass bspw. ein Kunden an einer beliebigen Tankstelle mit der rechtegesteuerte Transaktion zahlen kann.
(112) Rechtegesteuerte Transaktion Database - In der rechtegesteuerten Transaktion Database werden alle rechtegesteuerten Transaktion Dateien von Nutzern gespeichert, inklusive ihrer Gültigkeit und aller relevanten Datenfelder. Dabei erfolgt ein regelmäßiger Abgleich mit den anderen Datenbanken des Transaktionsservers, über welchen dabei die Kommunikation erfolgt.
(113) Geolocation Database - Die Geolocation Database ist ein unabhängiger Server eines anderen Anbieters, welcher dem Abgleich von Geodaten dient. Er kommuniziert dabei sowohl direkt mit der mobilen Applikation (101) als auch mit der Customer Location Database (110) und der Location Database (108)
(114) Payment Server - Der Payment Server dient der eigentlichen Durchführung der Bezahlung. Er kommuniziert dabei mit dem Transaktionsserver (107), dem Payment Gateway (117) und dem Push Server (126). Auf Basis der Informationen der Vorsysteme wird eine der hinterlegten Bankdaten der Bank Account Database (115) bzw. Kreditkarten in der Credit Card Database (116) als Bezahlverfahren ausgewählt und über das Payment Gateway (117) durchgeführt. In Abhängigkeit der Nutzung einer rechtegesteuerten Transaktion wird dabei ein eigenes Konto oder eine eigene Kreditkarte des Nutzers A oder eine Konto bzw. eine Karte eines spezifischen andern Nutzers - Nutzer B - für die Durchführung der Zahlung genutzt.
(115) Bank Account Database - In der Bank Account Database werden alle Bankverbindungen der Kunden gespeichert. Die Kommunikation erfolgt ausschließlich mit dem Payment Server (114). Alle Transaktionsdaten werden hier ebenfalls innerhalb des Systems gespeichert.
(116) Credit Card Database - In der Credit Card Database werden alle Kreditkartendaten der Nutzer gespeichert und hinterlegt. Weiterhin besteht die Möglichkeit eine sogenannte „Smart Pre-Authorization Credit Line“ für den Kunden auf Antrag zu hinterlegen. Mit Hilfe dieser Kurzzeit-Kreditlinie mit einer frei-definierbaren, von der Bonität des Kunden abhängigen Kurzzeit-Kreditlinie mit einer Laufzeit unter 48 Stunden können Zahlungen sofort autorisiert werden und bis zu 48 Stunden nach Zahlungen entweder systemseitig oder händisch einer rechtegesteuerte Transaktion oder einem Bankkonto bzw. einer Kreditkarte zur Zahlung zugeordnet werden. Es besteht ausschließlich eine Kommunikation zum Payment Server (114)
(117) Payment Gateway - Das Payment Gateway stellt die Schnittstelle zu Banksystemen dar und dient der Kommunikation mit Banken und Finanzinstituten. Es handelt sich dabei um eine Plattform welche verschiedene definierte Kommunikationsschnittstellen zu Banken nutzt, hierzu zählt bspw. die Kommunikation mittels PSD2 oder auch FinTS als Standard in Deutschland. Das Payment Gateway kommuniziert sowohl mit den Schnittstellen der Banken (119 oder 130) als auch mit dem Payment Server (114)
(118) Fee Server - Der Fee Server dient der Speicherung von Transaktionsentgelten von Finanzinstituten und Banken. Er kommuniziert dabei mit dem Payment Server (114) zum Abgleich der Zahlungen mit den eingehenden Transaktionsgebühren, welche über das Payment Gateway (117) gemeldet werden.
(119) Bank Payment Gateway - Issuing Bank - Das Bank Payment Gateway stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Payment Gateway (117) und dem zu belastenden Kundenkontos eines Nutzers bei einem spezifischen Institut.
(120) Financial Processor / ACH Server - Issuing Bank - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(121) Bank Payment Gateway - Acquiring Bank - Das Bank Payment Gateway stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Bank Payment Gateway - Issuing Bank (119) und dem Bank Payment Gateway - Acquiring Bank (121)
(122) Flnancial Processor / ACH Server - Acquiring Bank - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(123) POS Operating Server - Der Server dient der Verarbeitung der Kundenzahlung des Händlers und ist mit dem Acquirer Bank Payment Gateway (121 oder 130) verbunden.
(124) POS Terminal - Bezahlterminal bei einem Händler zur Durchführung von Kartenzahlungen.
(125) Mobile Endgerät inkl. Lösungs-Applikation (Nutzer B) - Im Falle einer Zahlung mittels rechtegesteuerter Transaktion wird der Kunde dessen Konto bzw. Karte belastet wurde über die Transkation informiert und erhält eine Push Nachricht vom Push Server (126)
(126) Push Server - Der Push Server stellt einen Kommunikationsserver dar der standardisierte verschlüsselte Informationen zu einer Zielapplikation von Nutzern (101, 125 oder 128) in Abhängigkeit von der Transaktion sendet.
(127) Webportal (Nutzer A) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(128) Webportal (Nutzer B) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(129) Dritt API - Schnittstelle zur Kommunikation und zum Datenaustausch mit anderen Drittsystemen.
(130) Online Payment Gateway - Bei einer Zahlung über das Internet wird statt eines POS-Terminals ein Online Payment Gateway des Händlers für die Durchführung der Bezahlung genutzt.

1 Representation of the payment process using the example of a four-party payment system

(101) Mobile device including solution application (user A) - with the help of the mobile application and using a virtual payment card, a payment is made at a card terminal. Optionally, the receipt of the transaction can be captured in the mobile application using a photo and linked to the transaction. Furthermore, the device records the exact geographic location and the device time with the consent of the user.
(102) OCR server - When using document archiving, the photographed document is sent to the OCR server to recognize the data and analyzed there.
(103) System Server - The System Server represents the central communication element and takes over the central coordination for the release of payments. The system server processes the payment data transmitted by the mobile application or the portal as well as the geographic data and the device time. The system server communicates with the invoice database (106) to compare the payment data after the transaction has been completed, with the payment slip being compared with the payment deposited in the invoice database. When paying with the bank details of a third party using a rights-controlled transaction, the payment receipt is sent to the user account of user B (mobile device 125 / web portal 128) via the PUSH server (126). Furthermore, the system server communicates with the transaction server (107) to compare the payment request with existing rights-controlled transactions and permissions. In addition, the system server has a central interface - third-party API (129) for transferring data to possible third-party systems. The system server also has a direct connection to the payment server (114) for storing user A’s own bank details and credit card details and for linking to user A.
(104) Customer Database - The system server uses the customer database to query whether the request is for a valid account and compares it with the stored user data. All relevant user master data is stored in the customer database. In the event of an unsuccessful query, a message is sent via the system server to the PUSH server (126) that the transaction is not possible due to missing customer data.
(105) Fraud Database - After a successful query of the customer data in the customer database, the fraud database is queried. Known cases of fraud and fraud attempts by both retailers and customers are stored in this. In the event of fraud, the request data is stored in the database and a payment refusal is reported to the push server (126) via the system server (103). This refusal is displayed to user A, including a short message, in the application (101).
(106) Invoice Database - In the Invoice Database, all invoice documents are saved as image files and the information read out as database entries.
(107) Transaction server - All rights-controlled transactions are stored and processed on the transaction server. The transaction server speaks to both the system server (103) and the payment server (114). The transaction server compares all relevant information of the payment request with the stored databases. This includes the following databases: Location Database (108), Merchant Database (109), Customer Location Database (110), Industry Database (111) and Rights-Controlled Transaction Database (112)
(108) Location Database - The location database compares the data of saved rights-controlled transaction payments with the deposit of a location and checks the location data with an independent geolocation server (113) for matches. Furthermore, with the help of the geolocation server (113), a regular comparison of location data from merchants from the merchant database (109) is carried out.
(109) Merchant Database - The Merchant Database contains dealers, service providers and other companies with payment options listed for which a rights-controlled transaction payment option has been set up. The payment data are scrutinized as standard with stored, permitted payments at specific retailers and authorized if necessary.
(110) Customer Location Database - With the help of the Customer Location Database, the user's location data is saved and saved to improve the accuracy of transactions and recurring payments for security reasons. Furthermore, there is a regular comparison of the reported location data with the geolocation server (113)
(111) Industry Database - The Industry Database contains a list of industries/sectors and regularly compares this with the Merchant Database (110). Furthermore, the payment data is also checked here with an existing rights-controlled transaction, so that, for example, a customer can pay at any gas station with the rights-controlled transaction.
(112) Rights-controlled transaction database - In the rights-controlled transaction database, all rights-controlled transaction files are stored by users, including their validity and all relevant data fields. There is a regular comparison with the other databases of the transaction server, via which the communication takes place.
(113) Geolocation Database - The Geolocation Database is an independent server from another provider, which is used to compare geodata. It communicates directly with the mobile application (101) as well as with the customer location database (110) and the location database (108).
(114) Payment Server - The payment server is used to actually carry out the payment. It communicates with the transaction server (107), the payment gateway (117) and the push server (126). Based on the information from the upstream systems, one of the bank data stored in the bank account database (115) or credit cards in the credit card database (116) is selected as the payment method and carried out via the payment gateway (117). Depending on the use of a rights-controlled transaction, user A's own account or credit card or an account or card of a specific other user - user B - is used to make the payment.
(115) Bank Account Database - All customer bank details are stored in the Bank Account Database. Communication takes place exclusively with the payment server (114). All transaction data is also stored here within the system.
(116) Credit Card Database - All of the user's credit card data is saved and stored in the Credit Card Database. There is also the option of depositing a so-called "Smart Pre-Authorization Credit Line" for the customer upon request. With the help of this short-term credit line with a freely definable short-term credit line dependent on the creditworthiness of the customer and with a term of less than 48 hours, payments can be authorized immediately and up to 48 hours after payment either by the system or manually in a rights-controlled transaction or a bank account or .assigned to a credit card for payment. There is only communication with the payment server (114)
(117) Payment Gateway - The payment gateway represents the interface to bank systems and is used for communication with banks and financial institutions. It is a platform that uses various defined communication interfaces to banks, including, for example, communication using PSD2 or FinTS as the standard in Germany. The payment gateway communicates with the interfaces of the banks (119 or 130) as well as with the payment server (114)
(118) Fee Server - The fee server is used to store transaction fees from financial institutions and banks. It communicates with the payment server (114) to match the payments with the incoming transaction fees, which are reported via the payment gateway (117).
(119) Bank Payment Gateway - Issuing Bank - The Bank Payment Gateway represents a standardized interface of a bank or financial institution and is used for communication between the Payment Gateway (117) and the customer account to be debited from a user at a specific institution.
(120) Financial Processor / ACH Server - Issuing Bank - The server is used to process the customer payment of the specific institute and to compare the customer data.
(121) Bank Payment Gateway - Acquiring Bank - The Bank Payment Gateway represents a standardized interface of a bank or a financial institution and is used for communication between the Bank Payment Gateway - Issuing Bank (119) and the Bank Payment Gateway - Acquiring Bank (121)
(122) Flnancial Processor / ACH Server - Acquiring Bank - The server is used to process the customer payment of the specific institute and to compare the customer data.
(123) POS Operating Server - The server is used to process the merchant's customer payment and is connected to the acquirer bank payment gateway (121 or 130).
(124) POS terminal - payment terminal at a retailer for making card payments.
(125) Mobile device including solution application (user B) - In the case of a payment using a rights-controlled transaction, the customer whose account or card was debited is informed about the transaction and receives a push message from the push server (126)
(126) Push Server - The push server represents a communication server that sends standardized encrypted information to a target application of users (101, 125 or 128) depending on the transaction.
(127) Web portal (user A) - Additional option to view transactions and set up payments via a web portal.
(128) Web portal (user B) - Additional option to view transactions and set up payments via a web portal.
(129) Third-party API - interface for communication and data exchange with other third-party systems.
(130) Online Payment Gateway - In the case of a payment via the Internet, the retailer's online payment gateway is used to carry out the payment instead of a POS terminal.

FIG 2 (Drei-Parteien-System)FIG 2 (three party system)

Darstellung des Bezahlverfahrens am Beispiel eines Drei-Parteien-Systems (200)

(201) Mobiles Endgerät inkl. Lösungs-Applikation (Nutzer A) - mit Hilfe der mobilen Applikation und unter Nutzung einer virtuellen Bezahlkarte wird eine Bezahlung an einem Kartenterminal getätigt. Optional kann in der mobilen Applikation der Beleg der Transaktion mittels eines Fotos erfasst und mit der Transaktion verknüpft werden. Weiterhin erfasst das Gerät nach Zustimmung des Nutzers den genauen geographischen Standort und die Geräteuhrzeit.
(202) OCR-Server - Bei Nutzung der Beleg-Archivierung wird der fotografierte Beleg an den OCR-Server zur Erkennung der Daten gesendet und dort analysiert.
(203) System Server - Der System Server stellt das zentrale Kommunikationselement dar und übernimmt die zentralen Koordination für die Freigabe der Zahlungen. Der System Server verarbeitet die von der Applikation übertragenen Bezahldaten sowie geographische Daten und Geräteuhrzeit. Eine Kommunikation des System Servers erfolgt mit der Invoice Database (206) zum Abgleich der Bezahldaten nach Abschluss der Transaktion, wobei in der Invoice Database der Zahlbeleg mit der hinterlegten Zahlungen abgeglichen wird. Bei einer Zahlung mit den Bankdaten einer Drittperson mittels einer rechtegesteuerte Transaktion wird über den PUSH Server (226) der Zahlbeleg an das Benutzerkonto von Nutzer B (Mobile Device 225 / Webportal 228) gesendet. Weiterhin kommuniziert der System Server mit dem Transaktionsserver (207) zum Abgleich der Bezahlanfrage mit bestehenden rechtegesteuerten Transaktionen und Erlaubnissen. Daneben verfügt der System Server über eine zentrale Schnittstelle - Dritt API (229) zur Übergabe von Daten an mögliche Drittsysteme. Für die Hinterlegung von eigenen Bankdaten und Kreditkartendaten des Nutzers A und zur Verknüpfung mit dem Nutzer A verfügt der System Server darüber hinaus auch über eine direkte Verbindung zum Payment Server (214)
(204) Customer Database - Vom System Server wird über die Customer Database abgefragt, ob es sich bei der Anfrage um ein gültiges Konto handelt und gleicht diese mit den hinterlegten Nutzerdaten ab. Alle relevanten Nutzer-Stammdaten werden dabei in der Customer Database gespeichert. Im Falle einer nichterfolgreichen Abfrage wird über den System Server an den PUSH Server (226) eine Nachricht gesendet, dass die Transaktion aufgrund fehlender Kundendaten nicht möglich ist.
(205) Fraud Database - Nach einer erfolgreichen Abfrage der Kundendaten in der Customer Database wird eine Abfrage der Fraud Datenbank durchgeführt. In dieser werden bekannte Betrugsfälle und Betrugsversuche sowohl von Händlern als auch von Kunden gespeichert. Im Falle eines Betrugsfalls werden die Daten der Anfrage in der Datenbank gespeichert und über den System Server (203) an den Push Server (226) eine Zahlungsablehnung gemeldet. Diese Ablehnung wird dem Nutzer A inklusiver einer kurzen Nachricht in der Applikation (201) angezeigt.
(206) Invoice Database - In der Invoice Database werden alle Rechnungsbelege sowohl als Bilddatei als auch in die ausgelesenen Informationen als Datenbankeinträge gespeichert.
(207) Transaktionsserver - Auf dem Transaktionsserver werden alle „enriched Transactions“ (rechtegesteuerte Transaktion) gespeichert und verarbeitet. Der Transaktionsserver spricht dabei sowohl mit dem System Server (203) als auch dem Payment Server (214). Der Transaktionsserver gleicht alle relevanten Informationen der Zahlungsanfrage mit den hinterlegten Datenbanken ab. Hierzu zählen die folgenden Datenbanken: Location Database (208), Merchant Database (209), Customer Location Database (210), Industry Database (211) und rechtegesteuerte Transaktion Database (212)
(208) Location Database - Die Location Database gleicht die Daten abgespeicherter rechtegesteuerter Transaktion-Zahlungen mit Hinterlegung eines Ortes ab und überprüft die Ortsdaten mit einem unabhängigen Geolocation Server (213) auf Übereinstimmung. Weiterhin wird mit Hilfe des Geolocation Servers (213) ein regelmäßiger Abgleich von Ortsdaten von Händlern aus Merchant Database (209) durchgeführt.
(209) Merchant Database - In der Merchant Database sind Händler, Dienstleiter und sonstige Unternehmungen mit Bezahlmöglichkeiten gelistet bei welchem eine rechtegesteuerte Transaktion-Bezahlmöglichkeit eingerichtet wurde. Die Bezahldaten werden dabei standartgemäß mit hinterlegten, erlaubten Zahlungen bei spezifischen Händlern hinterfragt und bei Bedarf autorisiert.
(210) Customer Location Database - Mit Hilfe der Customer Loaction Database werden die Ortsdaten des Nutzers gespeichert und zur Verbesserung der Genauigkeit von Transaktionen, wiederkehrenden Zahlungen und aus Sicherheitsgründen gespeichert. Weiterhin erfolgt hier ein regelmäßiger Abgleich der gemeldeten Ortsdaten mit dem Geolocation Server (113)
(211) Industry Database - Die Industry Database enthält eine Liste von Industrien/ Branchen und gleicht diese regelmäßig mit der Merchant Database (110) ab. Weiterhin werden die Bezahldaten auch hier mit einer bestehenden rechtegesteuerte Transaktion überprüft, so dass bspw. ein Kunden an einer beliebigen Tankstelle mit der rechtegesteuerte Transaktion zahlen kann.
(212) Rechtegesteuerte Transaktion Database - In der rechtegesteuerte Transaktion Database werden alle rechtegesteuerten Transaktion Dateien von Nutzern gespeichert, inklusive ihrer Gültigkeit und aller relevanten Datenfeldern. Dabei erfolgt ein regelmäßiger Abgleich mit den anderen Datenbanken des Transaktionsservers, über welchen dabei die Kommunikation erfolgt.
(213) Geolocation Database - Die Geolocation Database ist ein unabhängiger Server eines anderen Anbieters, welcher dem Abgleich von Geodaten dient. Er kommuniziert sowohl direkt mit der mobilen Applikation (201), wie auch mit der Customer Location Database (210) und der Location Database (208)
(214) Payment Server - Der Payment Server dient der eigentlichen Durchführung der Bezahlung. Er kommuniziert mit dem Transaktionsserver (207), dem Payment Gateway (217) und dem Push Server (226). Auf Basis der Informationen der Vorsysteme wird eine der hinterlegten Bankdaten der Bank Account Database (215) bzw. Kreditkarten in der Credit Card Database (216) als Bezahlverfahren ausgewählt und über das Payment Gateway (217) durchgeführt. In Abhängigkeit der Nutzung einer rechtegesteuerte Transaktion wird ein eigenes Konto oder eine eigene Kreditkarte des Nutzers A oder ein Konto bzw. eine Karte eines spezifischen, andern Nutzers - Nutzer B - für die Durchführung der Zahlung genutzt.
(215) Bank Account Database - In der Bank Account Database werden alle Bankverbindungen der Kunden gespeichert. Die Kommunikation erfolgt ausschließlich mit dem Payment Server (214). Alle Transaktionsdaten werden hier ebenfalls innerhalb des Systems gespeichert.
(216) Credit Card Database - In der Credit Card Database werden alle Kreditkartendaten der Nutzer gespeichert und hinterlegt. Weiterhin besteht die Möglichkeit eine sogenannte „Smart Pre-Authorization Credit Line“ für den Kunden auf Antrag zu hinterlegen. Mit Hilfe dieser Kurzzeitkreditlinie mit einer freidefinierbaren, von der Bonität des Kunden abhängigen Kurzzeit-Kreditlinie mit einer Laufzeit unter 48 Stunden können Zahlungen sofort autorisiert und bis zu 48 Stunden nach Zahlungen entweder systemseitig oder händisch einer rechtegesteuerten Transaktion oder einem Bankkonto bzw. einer Kreditkarte zur Zahlung zugeordnet werden. Es besteht ausschließlich eine Kommunikation zum Payment Server (214)
(217) Payment Gateway - Das Payment Gateway stellt die Schnittstelle zu Banksystemen dar und dient der Kommunikation mit Banken und Finanzinstituten. Es handelt sich dabei um eine Plattform, welche verschiedene definierte Kommunikationsschnittstellen zu Banken nutzt. Hierzu zählt bspw. die Kommunikation mittels PSD2 oder auch FinTS als Standard in Deutschland. Das Payment Gateway kommuniziert sowohl mit den Schnittstellen der Banken (219 oder 230) als auch mit dem Payment Server (214)
(218) Fee Server - Der Fee Server dient der Speicherung von Transaktionsentgelten von Finanzinstituten und Banken. Er kommuniziert mit dem Payment Server (214) zum Abgleich der Zahlungen mit den eingehenden Transaktionsgebühren, welche über das Payment Gateway (217) gemeldet werden.
(219) Bank Payment Gateway - Franchisee / Issuer & Acquirer - Das Bank Payment Gateway stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Bank Payment Gateway und dem Payment Gateway (117)
(220) Financial Processor / ACH Server - Franchisee / Issuer & Acquirer - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(221) POS Operating Server - Der Server dient der Verarbeitung der Kundenzahlung des Händlers und ist mit dem Acquirer Bank Payment Gateway (121 oder 130) verbunden.
(222) POS Terminal - Bezahlterminal bei einem Händler zur Durchführung von Kartenzahlungen.
(223) Mobile Endgerät inkl. Lösungs-Applikation (Nutzer B) - Im Falle einer Zahlung mittels rechtegesteuerter Transaktion wird der Kunde dessen Konto bzw. Karte belastet wurde über die Transkation informiert und erhält eine Push Nachricht vom Push Server (126)
(224) Push Server - Der Push Server stellt einen Kommunikationsserver dar der standardisierte verschlüsselte Informationen zu einer Zielapplikation von Nutzern (101, 125 oder 128) in Abhängigkeit von der Transaktion sendet.
(225) Webportal (Nutzer A) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal
(226) Webportal (Nutzer B) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal
(227) Dritt API - Schnittstelle zur Kommunikation und zum Datenaustausch mit anderen Drittsystemen
(228) Online Payment Gateway - Bei einer Zahlung über das Internet wird statt eines POS-Terminals ein Online Payment Gateway des Händlers für die Durchführung der Bezahlung genutzt.

Representation of the payment method using the example of a three-party system (200)

(201) Mobile device including solution application (user A) - with the help of the mobile application and using a virtual payment card, a payment is made at a card terminal. Optionally, the receipt of the transaction can be captured in the mobile application using a photo and linked to the transaction. Furthermore, the device records the exact geographic location and the device time with the consent of the user.
(202) OCR server - When using document archiving, the photographed document is sent to the OCR server to recognize the data and analyzed there.
(203) System Server - The System Server represents the central communication element and takes over the central coordination for the release of payments. The system server processes the payment data transmitted by the application as well as geographic data and device time. The system server communicates with the invoice database (206) to compare the payment data after the transaction has been completed, with the payment receipt being compared with the deposited payment in the invoice database. When paying with the bank details of a third party using a rights-controlled transaction, the payment receipt is sent to the user account of user B (mobile device 225 / web portal 228) via the PUSH server (226). Furthermore, the system server communicates with the transaction server (207) to compare the payment request with existing rights-controlled transactions and permissions. In addition, the system server has a central interface - third-party API (229) for transferring data to possible third-party systems. The system server also has a direct connection to the payment server (214) for storing user A's own bank details and credit card details and for linking to user A.
(204) Customer Database - The system server uses the customer database to query whether the request is for a valid account and compares it with the stored user data. All relevant user master data is stored in the customer database. In the event of an unsuccessful query, a message is sent via the system server to the PUSH server (226) that the transaction is not possible due to missing customer data.
(205) Fraud Database - After a successful query of the customer data in the customer database, the fraud database is queried. Known cases of fraud and fraud attempts by both retailers and customers are stored in this. In the event of fraud, the request data is stored in the database and a payment refusal is reported to the push server (226) via the system server (203). This refusal is displayed to user A, including a short message, in the application (201).
(206) Invoice Database - In the Invoice Database, all invoice documents are saved both as image files and in the information read out as database entries.
(207) Transaction server - All "enriched transactions" (rights-controlled transactions) are stored and processed on the transaction server. The transaction server speaks to both the system server (203) and the payment server (214). The transaction server compares all relevant information of the payment request with the stored databases. This includes the following databases: Location Database (208), Merchant Database (209), Customer Location Database (210), Industry Database (211) and Rights-Controlled Transaction Database (212)
(208) Location Database - The location database compares the data of saved rights-controlled transaction payments with a location and checks the location data with an independent geolocation server (213) for consistency. Furthermore, with the help of the geolocation server (213), a regular comparison of location data from merchants from the merchant database (209) is carried out.
(209) Merchant Database - The Merchant Database lists dealers, service providers and other companies with payment options for which a rights-controlled transaction payment option has been set up. The payment data are scrutinized as standard with stored, permitted payments at specific retailers and authorized if necessary.
(210) Customer Location Database - With the help of the Customer Loaction Database, the user's location data is stored and stored to improve the accuracy of transactions, recurring payments and for security reasons. Furthermore, there is a regular comparison of the reported location data with the geolocation server (113)
(211) Industry Database - The Industry Database contains a list of industries/sectors and regularly compares this with the Merchant Database (110). Furthermore, the payment data is also checked here with an existing rights-controlled transaction, so that, for example, a customer can pay at any gas station with the rights-controlled transaction.
(212) Rights-controlled transaction database - In the rights-controlled transaction database, all rights-controlled transaction files are stored by users, including their validity and all relevant data fields. There is a regular comparison with the other databases of the transaction server, via which the communication takes place.
(213) Geolocation Database - The Geolocation Database is an independent server from another provider, which is used to compare geodata. It communicates directly with the mobile application (201) as well as with the Customer Location Database (210) and the Location Database (208)
(214) Payment server - The payment server is used to actually carry out the payment. It communicates with the transaction server (207), the payment gateway (217) and the push server (226). Based on the information from the upstream systems, one of the bank data stored in the bank account database (215) or credit cards in the credit card database (216) is selected as the payment method and carried out via the payment gateway (217). Depending on the use of a rights-controlled transaction, User A's own account or credit card or an account or card of a specific, different user - User B - is used to make the payment.
(215) Bank Account Database - All customer bank details are stored in the Bank Account Database. Communication takes place exclusively with the payment server (214). All transaction data is also stored here within the system.
(216) Credit Card Database - All of the user's credit card data is saved and stored in the Credit Card Database. There is also the option of depositing a so-called "Smart Pre-Authorization Credit Line" for the customer upon request. With the help of this short-term credit line with a freely definable short-term credit line dependent on the creditworthiness of the customer with a term of less than 48 hours, payments can be authorized immediately and up to 48 hours after payments either by the system or manually using a rights-controlled transaction or a bank account or credit card for payment be assigned. There is only communication with the payment server (214)
(217) Payment Gateway - The payment gateway represents the interface to bank systems and is used for communication with banks and financial institutions. It is a platform that uses various defined communication interfaces to banks. This includes, for example, communication using PSD2 or FinTS as the standard in Germany. The payment gateway communicates with the interfaces of the banks (219 or 230) as well as with the payment server (214)
(218) Fee Server - The fee server is used to store transaction fees from financial institutions and banks. It communicates with the payment server (214) to match the payments with the incoming transaction fees, which are reported via the payment gateway (217).
(219) Bank Payment Gateway - Franchisee / Issuer & Acquirer - The Bank Payment Gateway represents a standardized interface of a bank or a financial institution and is used for communication between the Bank Payment Gateway and the Payment Gateway (117)
(220) Financial Processor / ACH Server - Franchisee / Issuer & Acquirer - The server is used to process the customer payment of the specific institution and to compare customer data.
(221) POS Operating Server - The server is used to process the merchant's customer payment and is connected to the acquirer bank payment gateway (121 or 130).
(222) POS terminal - payment terminal at a retailer for making card payments.
(223) Mobile device including solution application (user B) - In the case of a payment using a rights-controlled transaction, the customer whose account or card was debited is informed about the transaction and receives a push message from the push server (126)
(224) Push Server - The push server represents a communication server that sends standardized encrypted information to a target application of users (101, 125 or 128) depending on the transaction.
(225) Web portal (user A) - Additional option to view transactions and set up payments via a web portal
(226) Web portal (user B) - Additional option to view transactions and set up payments via a web portal
(227) Third-party API - interface for communication and data exchange with other third-party systems
(228) Online Payment Gateway - In the case of a payment via the Internet, the retailer's online payment gateway is used to carry out the payment instead of a POS terminal.

3A Eingabemaske einer rechtegesteuerte Transaktion-Zahlung in ein mobiles Endgerät

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(301) Eingabemaske initiale Eingabe - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Informationen zur Durchführung einer Transaktion. Dies umfasst die Auswahlmöglichkeit des Abbuchungskontos, die Anzeige des aktuellen Guthaben / der aktuellen Verfügbarkeit, eine Auswahl des Empfängers, der Betragshöhe und des Verwendungszwecks. Weiterhin besteht ergänzend die Möglichkeit die Zahlungen nach Ort, Zeit, bestimmten Händlern / Unternehmen, Branchen, Aktionen oder auch nach Online- und Offline-Bezahlmöglichkeiten einzuschränken.

3A Input mask of a rights-controlled transaction payment in a mobile device

(103) System Server - Example of a system server for storing data and querying master data
(301) Input mask for initial input - Exemplary representation of an input mask with the necessary information to carry out a transaction. This includes the option of selecting the debit account, displaying the current credit/availability, selecting the recipient, the amount and the purpose. There is also the additional option of restricting payments by location, time, specific dealers/companies, industries, campaigns or by online and offline payment options.

3B zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerten Transaktion - Eingabe Ortsbeschränkung

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(302) Eingabemaske Ortsbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Ortsinformationen und zur Einstellung von möglichen Radien / Umkreisen um einen Ort

3B shows an exemplary embodiment of the input mask of a mobile rights-controlled transaction - input location restriction

(103) System Server - Example of a system server for storing data and querying master data
(302) Location restriction input mask - Exemplary representation of an input mask with the necessary location information and for setting possible radii / radius around a location

3C zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Zeitbeschränkung

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(303) Eingabemaske Zeitbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Zeitinformationen

3C shows an exemplary embodiment of the input mask of a mobile rights-controlled transaction - input time limit

(103) System Server - Example of a system server for storing data and querying master data
(303) Time limit input mask - Exemplary representation of an input mask with the necessary time information

3D zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Händlerbeschränkung

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(304) Eingabemaske Händlerbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Händlerinformationen

3D shows an exemplary embodiment of the input mask of a mobile, rights-controlled transaction - input dealer restriction

(103) System Server - Example of a system server for storing data and querying master data
(304) Retailer restriction input mask - Exemplary representation of an input mask with the necessary dealer information

3E zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Branchenbeschränkung

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(305) Eingabemaske Branchenbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Brancheninformationen

3E shows an exemplary execution of the input mask of a mobile rights-controlled transaction - input branch restriction

(103) System Server - Example of a system server for storing data and querying master data
(305) Industry restriction input mask - Exemplary representation of an input mask with the necessary industry information

3F zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Besondere Ereignisse / Aktionsbeschränkungen

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(306) Eingabemaske Zeitbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Ereignissen / Aktionen

3F shows an exemplary implementation of the input mask of a mobile rights-controlled transaction - input special events / action restrictions

(103) System Server - Example of a system server for storing data and querying master data
(306) Input mask time limit - Exemplary representation of an input mask with the necessary events / actions

3G zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Online / Offline Beschränkungen

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(307) Eingabemaske Online / Offine Beschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Informationen

3G shows an example execution of the input mask of a mobile rights-controlled transaction - input online / offline restrictions

(103) System Server - Example of a system server for storing data and querying master data
(307) Input mask online / offline restriction - Exemplary representation of an input mask with the necessary information

3H zeigt eine beispielhafte Ausführung der Zusammenfassungsseite einer mobilen rechtegesteuerte Transaktion-Zahlung und Bestätigung mittels 2-Faktor Authentifizierung

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten
(126) Push Server - Beispielhafte Darstellung eines Push Servers zur Übermittelung eines 2-Faktors zur Freigabe der Zahlung
(308) Zusammenfassung rechtegesteuerte Transaktion - Beispielhafte Darstellung einer Zusammenfassungsmaske mit den notwendigen Informationen
(309) Eingabeseite 2-Faktor-Authentifizierung - Beispielhafte Darstellung einer Bestätigung einer Zahlung mittels zweitem Faktor

3H shows an exemplary execution of the summary page of a mobile rights-controlled transaction payment and confirmation using 2-factor authentication

(103) System Server - Example of a system server for storing data and querying master data
(126) Push Server - Exemplary representation of a push server for the transmission of a 2-factor to release the payment
(308) Summary rights-controlled transaction - Exemplary representation of a summary mask with the necessary information
(309) Entry page 2-factor authentication - exemplary representation of a confirmation of a payment using a second factor

4 zeigt die Bezahlung mit einer rechtegesteuerten Transaktion und das Zusammenspiel zwischen Nutzer (Warenempfänger), System und Nutzer (Zahlender)

(401) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung
(402) Zur Zahlung wählt der Kunde eine spezifische, eingeschränkte Transaktion aus und nutzt diese für den Bezahlvorgang
(403) Überprüfung ob die ausgewählten und eingeschränkten Bedingungen aus (402) bzw. (405) vorliegen. Wenn ja, dann wird der Prozess bei (404) fortgesetzt. Liegen die Bedingungen bei der Zahlung nicht vor, wird das eigenen Konto des Nutzers belastet (406)
(404) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet
(405) Der Nutzer wählt für die Zahlung die virtuelle Standardeinstellung des Bezahlverfahrens
(406) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (403) an, andernfalls wird das eigene Konto (407) belastet
(407) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet

4 shows the payment with a rights-controlled transaction and the interaction between user (goods recipient), system and user (payer)

(401) A user acquires a good or service and is the recipient of this action
(402) To pay, the customer selects a specific, restricted transaction and uses it for the payment process
(403) Check whether the selected and restricted conditions from (402) or (405) are present. If so, then the process continues at (404). If the payment conditions are not met, the user's own account will be debited (406)
(404) If all conditions of the rights-controlled transaction are met, the account of the transaction provider is debited
(405) The user selects the virtual standard setting of the payment method for the payment
(406) By default, the system checks whether there is a suitable restricted transaction, if so, process steps (403) follow, otherwise your own account (407) is debited
(407) If there is no restricted payment, the user's own account (goods recipient) will be debited

5 zeigt die Onlinebezahlung mit einer rechtegesteuerten Transaktion

(501) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung
(502) Zur Zahlung wählt der Kunde ein mobiles Bezahlverfahren mittels hinterlegter virtueller Kreditkarte bspw. Apple Pay
(503) Zur Zahlung hinterlegt der Kunde seine virtuellen Kreditkartendaten der Lösung und gibt diese Kartendaten zur Belastung an
(504) Die Zahlungsdaten der virtuellen Kreditkarte werden durch das System auf ihre Gültigkeit und Verfügbarkeit geprüft. Zur Autorisierung kann die Bestätigung mittels eines weiteren Faktors möglich sein - Mehr-Faktor-Authentifizierung. Ist diese gegeben wird der Prozess bei (506) zur Überprüfung einer vorliegenden eingeschränkt Zahlung fortgesetzt. Sind die Daten nicht gültig, ist das Konto gesperrt oder liegt ein anderer die Zahlung verhindernder Grund vor, wird die Zahlung abgelehnt (505)
(505) Ablehnung der Transaktion und Beendigung des Prozesses
(506) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (507) an, andernfalls wird das eigene Konto (509) belastet
(507) Überprüfung ob die Bedingungen ausgewählte, eingeschränkte der Transaktion vorliegen. Wenn ja, dann wird der Prozess bei (508) fortgesetzt. Liegen die Bedingungen bei der Zahlung nicht vor, wird das eigenen Konto des Nutzers belastet (509)
(508) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet
(509) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet

5 shows online payment with a rights-controlled transaction

(501) A user acquires a good or service and is the recipient of this action
(502) To pay, the customer selects a mobile payment method using a stored virtual credit card, e.g. Apple Pay
(503) For payment, the customer stores his virtual credit card data in the solution and enters this card data for debiting
(504) The payment data of the virtual credit card are checked by the system for their validity and availability. For authorization, confirmation using another factor may be possible - multi-factor authentication. If so, the process continues at (506) to check for pending restricted payment. If the data is not valid, the account is blocked or there is another reason preventing payment, the payment is rejected (505)
(505) Rejection of the transaction and termination of the process
(506) By default, the system checks whether there is a suitable restricted transaction, if so, process steps (507) follow, otherwise your own account (509) is debited
(507) Check whether the conditions of the selected, restricted transaction are present. If so, then the process continues at (508). Are the conditions at the If payment is not made, the user's own account will be charged (509)
(508) If all the conditions of the rights-based transaction are met, the transaction sender's account will be debited
(509) If there is no restricted payment, the user's own account (goods recipient) will be debited

6 zeigt die Bezahlung am Point of Sales mit einer rechtegesteuerten Transaktion mit einem Belegnachweis

(601) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung
(602) Zur Zahlung wählt der Kunde eine spezifische, eingeschränkte Transaktion aus und nutzt diese für den Bezahlvorgang
(603) Überprüfung ob die ausgewählten und eingeschränkten Bedingungen aus (602) bzw. (605) vorliegen. Liegt keine eingeschränkte Zahlung vor wird der Prozess bei (607) mit der Belastung des eigenen Kontos fortgesetzt. Bei Erfüllung aller Bedingungen endet der Prozess mit der Abbuchung von einem Fremdkonto (604). Für den Fall dass die Fremdkonto-Belastung erst nach Belegnachweis autorisiert werden kann, wird der Prozess bei (608) fortgesetzt
(604) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet
(605) Der Nutzer wählt für die Zahlung die virtuelle Standardeinstellung des Bezahlverfahrens
(606) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (403) an, andernfalls wird das eigene Konto (407) belastet
(607) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet
(608) Die Zahlung des Kunden wird auf der virtuellen Kreditkarte vorautorisiert und zunächst genehmigt - ein Beleg muss innerhalb einer zu definierten Frist hinzugefügt werden (609)
(609) Der Nutzer muss entweder per integrierter Kamera des Geräts ein Foto des Belegs machen oder diesen als Anhang in das System laden, sodass der Beleg mit den Bedingungen der Zahlungen (610) im nächsten Schritt überprüft werden kann.
(610) Der Beleg wird automatisch auf die Bedingungen der Zahlung überprüft. Liegen diese vor, wird das Fremdkonto (604) belastet und der Beleg dem Zahler übermittelt. Liegen die Bedingungen nicht vor, wird das eigene Konto belastet (607)

6 shows payment at the point of sale with a rights-controlled transaction with proof of receipt

(601) A user acquires a good or service and is the recipient of this action
(602) To pay, the customer selects a specific, restricted transaction and uses it for the payment process
(603) Check whether the selected and restricted conditions from (602) or (605) are present. If there is no restricted payment, the process continues at (607) with debiting own account. If all conditions are met, the process ends with the debit from an external account (604). In the event that the third-party account debit can only be authorized after supporting evidence, the process continues at (608).
(604) If all conditions of the rights-controlled transaction are met, the account of the transaction provider is debited
(605) The user selects the virtual standard setting of the payment method for the payment
(606) By default, the system checks whether there is a suitable restricted transaction, if so, process steps (403) follow, otherwise your own account (407) is debited
(607) If there is no restricted payment, the user's own account (goods recipient) will be debited
(608) The customer's payment is pre-authorized on the virtual credit card and initially approved - a receipt must be added within a defined period (609)
(609) The user must either take a photo of the receipt using the device's built-in camera or upload it to the system as an attachment so that the receipt with the terms of the payments (610) can be checked in the next step.
(610) The receipt is automatically checked for the conditions of payment. If these exist, the third-party account (604) is debited and the receipt is sent to the payer. If the conditions are not met, your own account will be debited (607)

7 zeigt den Datenfluss der Einrichtung einer rechtegesteuerten Transaktion

(701) Auswahl des Empfänger-Namen - der Empfänger-Name stellt dabei den Benutzernamen des Empfängers im System oder alternativ die Mobiltelefonnummer oder E-Mail bzw. ein anderes den Empfänger eindeutig im System zu identifizierendes Merkmal dar.
(702) Eingabe des Betragshöhe der Transaktion - hier wird die Währung des Nutzers als Default-Währung genutzt
(703) Auswahl ob es sich um eine einmalige, mehrmalige oder dauerhafte Transaktion handelt. Bei einer einmaligen Transaktion handelt es sich um eine Transaktion die in der ausgewählten Betragshöhe einmalig zu einem Kauf berichtigt. Bei einer mehrmaligen Transaktion kann eine Transaktion unter Einhaltung der Berechtigungen beliebig häufig bis zur Erreichung des Betrags wiederholt werden. Bei einer dauerhaften Transaktion wird durch den Nutzer eine Art Kreditfunktion in dieser Höhe gewährt, welche abhängig von der gewählten Zeit immer wieder bis zur Erreichung der Betragshöhe in einer definierten Zeitspanne zur Verfügung steht. Die kleinste mögliche Zeiteinheit stellt dabei eine Minuteneinheit dar und kann dann variabel über Stunden, Tage, Wochen, Monate oder Jahre angepasst werden
(704) Auswahl oder Änderung der Währung der Transaktion - per Default ist die Währung des Zahlenden hinterlegt
(705) Verpflichtende Bezeichnung der Transaktion. Diese Bezeichnung dient der Übersichtlichkeit und wird Anzeige bei der Transaktion stets angezeigt, zum Beispiel in der Übersichtseite der Transaktionen
(706) Freitext-Feld mit bis zu 400 Zeichen zur (Detail-)Beschreibung der Transaktion
(707) Hier wählt von welchem Zahlungsmittel die Transaktion gezahlt wird
(708) Auswahlmöglichkeit in wie weit zusätzlich Rechte eingeschränkt werden sollen. Bei einer Rechte-Einschränkung geht der Prozess bei (709) weiter, soll die Zahlung einfach als Transaktion ohne bestimmte Rechte-Einschränkung durchgeführt werden, ist der Prozessschritt Freigabe (716) der nächste Schritt
(709) Hier kann der Nutzer auswählen an welchen Orten die Transaktion gültig sein soll. Die Erfassungsmöglichkeit stellt sowohl einzelne Orte, mehrere Orte, wie auch definierte Strecken dar. Es besteht jeweils auch die Möglichkeit zusätzlich einen Radius innerhalb dessen die Zahlung möglich ist, einzustellen. Anbei eine Veranschaulichung an einem Beispiel: Der Nutzer wählt die Adresse „Musterstraße 1, Musterstadt“ mit einem Radius von 4km aus und ermöglicht damit eine Zahlung an dieser Anschrift und in einer Luftlinie von 4 km aus, an welchem die Bedingung zur Zahlung erfüllt ist
(710) Durch Auswahl der Zeit kann die Gültigkeit und Anwendung der Transaktion ebenfalls eingeschränkt werden. Zu den Auswahlmöglichkeiten zählen, das Datum, Tage, Monate, Jahre, zu definierende Zeitspannen und die Uhrzeit. Der Nutzer hat die Möglichkeit sowohl den Start- und Endpunkt der Einschränkung auszuwählen, wie auch mehrere Ereignisse zu verknüpfen und einen übergreifenden Start- und Endpunkt zu wählen. An einem Beispiel ist dies verständlicher: Der Nutzer gibt an, dass eine Zahlung immer Montags von 8 - 9 Uhr möglich ist und wählt zusätzlich als übergreifenden Start- und Endpunkt, dass diese Regelung vom 01.01. bis zum 31.03. gültig ist
(711) Eine weitere Möglichkeit der Rechtsteuerung besteht in der Eingabe bestimmter Bedingung die zur Auswahl erfüllt sein müssen. Zu diesen Rechten zählen beispielhaft die Freigabe der Zahlung erst nach erneuter Freigabe durch den Nutzer, die Freigabe der Zahlung erst nach Upload eines Zahlungsnachweises oder die sofortige Freigabe der Zahlung und einen Widerruf der Zahlung wenn nicht innerhalb einer spezifischen Zeit eine Zahlungsnachweis geuploaded wird. Die zeitversetzte Freigabe setzt eine Kreditfunktion oder Vorfinanzierung über ein anderes Konto auf dem Empfänger-Konto zur Zahlung der Transaktion voraus
(712) Weiterhin besteht die Möglichkeit verschiedene systemseitige Ereignisse / Beispieleinstellungen für bestimmte Events zu übernehmen. Zu diesen Ereignissen zählen Geburtstag, Hochzeitstag oder sonstige spezifische Events. Hier wird der Nutzer zusätzlich an das spezifische Event systemseitig erinnert
(713) Durch die Auswahl bestimmter Händler kann die Zahlungsmöglichkeit auf diese Orte eingeschränkt werden. Überprüft wird diese u.a. durch den Abgleich der Händlerliste mit den geographischen Daten des Endgeräts bei einer mobilen Transaktion
(714) Weiterhin besteht die Auswahlmöglichkeit bestimmter Branchen für Zahlungen. In diesem Fall werden automatische Händler der bestehenden Branche bei der Zahlung autorisiert
(715) Zuletzt besteht die Möglichkeit der Auswahl ob die Zahlung Online, nur-Offline oder Online + Offline durchgeführt werden kann. Zusätzlich kann der Kunde bestimmte Websiten zur Freigabe einrichten oder sperren. Per Default ist die Auswahl „nur-Offline“
(716) Abschluss des Prozesses durch Bestätigung der Auswahl - anschließend erfolgt eine 2-Faktor-Authenfizierung der Transaktion, ähnlich dem in 3H dargestellten Beispiel

7 shows the data flow of setting up a rights-controlled transaction

(701) Selection of the recipient name - the recipient name represents the user name of the recipient in the system or alternatively the mobile phone number or e-mail or another feature to uniquely identify the recipient in the system.
(702) Enter the amount of the transaction - here the user's currency is used as the default currency
(703) Selection whether it is a one-time, multiple or permanent transaction. A one-time transaction is a transaction that is corrected once to a purchase in the selected amount. In the case of a multiple transaction, a transaction can be repeated as often as desired until the amount is reached, subject to compliance with the authorizations. In the case of a permanent transaction, the user grants a type of credit function in this amount, which, depending on the selected time, is available again and again in a defined period of time until the amount is reached. The smallest possible unit of time is a unit of minutes and can then be variably adjusted over hours, days, weeks, months or years
(704) Selection or change of the currency of the transaction - the currency of the payer is stored by default
(705) Mandatory description of the transaction. This designation is used for clarity and is always displayed during the transaction, for example on the transaction overview page
(706) Free text field with up to 400 characters for a (detailed) description of the transaction
(707) Here you select the payment method used to pay for the transaction
(708) Choice of the extent to which additional rights are to be restricted. In the case of a rights restriction, the process continues at (709), if the payment is to be carried out simply as a transaction without specific rights restrictions, the process step Approval (716) is the next step
(709) Here the user can select the locations at which the transaction should be valid. The possibility of recording represents both individual locations, multiple locations, as well as defined streaks It is also possible to set a radius within which payment is possible. Here is an example: The user selects the address "Sample Street 1, Sample City" with a radius of 4 km and thus enables payment to be made at this address and within a linear distance of 4 km, at which the condition for payment is met
(710) By selecting the time, the validity and application of the transaction can also be limited. The selection options include the date, days, months, years, time periods to be defined and the time. The user has the option of selecting the start and end point of the restriction, as well as linking several events and choosing an overarching start and end point. This is more understandable with an example: The user states that payment is always possible on Mondays from 8 a.m. to 9 a.m. and also selects as the general start and end point that this regulation applies from 01.01. until 31.03. is valid
(711) Another option for right-hand control is to enter certain conditions that must be met for the selection. These rights include, for example, releasing payment only after re-release by the user, releasing payment only after uploading proof of payment, or releasing payment immediately and revocation of payment if proof of payment is not uploaded within a specific time. Deferred release requires a credit facility or pre-funding through another account on the recipient's account to pay for the transaction
(712) There is also the option of adopting various system events/sample settings for specific events. These events include birthdays, wedding anniversaries or other specific events. Here the user is also reminded of the specific event by the system
(713) By selecting certain dealers, the payment option can be restricted to these locations. This is checked, among other things, by comparing the dealer list with the geographic data of the end device in a mobile transaction
(714) There is also the option of selecting certain sectors for payments. In this case, automatic traders of the existing branch are authorized upon payment
(715) Finally, there is the option of selecting whether the payment can be made online, only offline or online + offline. In addition, the customer can set up or block certain websites for approval. By default, the selection is "offline only"
(716) Completion of the process by confirming the selection - then a 2-factor authentication of the transaction takes place, similar to that in 3H example shown

8 zeigt die Felder einer bespielhaften Transaktion 8th shows the fields of an example transaction

9 zeigt die Zusammenführung mehrerer rechtegleicher Transaktionen zu einer gemeinsamen Transaktion

(901) Der Nutzer verfügt über verschiedene eingeschränkte Zahlungen mit gleichen Rechten
(902) Der Nutzer wählt mehrere dieser Transaktionen aus und möchte diese zu einer Gesamttransaktion zusammenführen, beispielweise bei einem Geburtstagsgeschenk
(903) Systemseitig werden die Einzelrechte der Transaktionen überprüft und abgeglichen. Sofern die Transaktionen kombinierbar sind werden die Einzelrechte in einer Datenbank gespeichert und mit der neuen übergreifenden Transaktion verknüpft (906) und dem Nutzer eine neue zusammengeführte Transaktion übermittelt (905). Sind die Transaktionen nicht kombinierbar wird die Zusammenführung abgelehnt (904) bzw. einzelne Transaktionsbestandteile abgelehnt.
(904) Dem Nutzer werden die einzelnen abgelehnten Transaktionen angezeigt
(905) Dem Nutzer wird die neue Transaktion angezeigt. Diese Transaktion wird regelmäßig auf Veränderungen der einzelnen Transaktionen geprüft (906)
(906) In der Systemdatenbank werden sowohl die Recht der einzelnen Transaktion, wie auch die Rechte der neuen gemeinsamen Transaktion gespeichert. Dem Nutzer wird nur noch die neue Gesamttransaktion (905) angezeigt, die Einzeltransaktionen bleiben lediglich systemseitig bestehen und werden regelmäßig auf ihre Gültigkeit überprüft. Bei einer Zahlung mit der neuen Transaktion kann der Nutzer jedoch wählen, ob er eine bestimmte (Unter-) Transaktion belasten möchte oder den Rechnungsbetrag in einer beliebig zu wählenden Form aufteilt

9 shows the merging of several transactions with the same rights into one joint transaction

(901) The user has various restricted payments with equal rights
(902) The user selects several of these transactions and wants to merge them into one overall transaction, for example a birthday present
(903) The individual rights of the transactions are checked and compared on the system side. If the transactions can be combined, the individual rights are stored in a database and linked to the new overall transaction (906) and a new combined transaction is sent to the user (905). If the transactions cannot be combined, the merger is rejected (904) or individual transaction components are rejected.
(904) The individual rejected transactions are displayed to the user
(905) The new transaction is displayed to the user. This transaction is regularly checked for changes in the individual transactions (906)
(906) Both the rights of the individual transaction and the rights of the new joint transaction are stored in the system database. Only the new overall transaction (905) is displayed to the user, the individual transactions only remain in the system and are regularly checked for validity. When paying with the new transaction, however, the user can choose whether he wants to debit a specific (sub)transaction or split the invoice amount in any form that can be chosen

10 zeigt die Bezahlung einer Überweisung unter Nutzung einer rechtegesteuerten Zahlung

(1001) Der Nutzer wählt im Menü eine Überweisung als gewünschte Handlung aus
(1002) Auswahl einer bestimmten rechtegesteuerten Transaktion zur Überweisung - Vorausfüllung aller relevanten Informationen. Anschließend kommt es zur Überprüfung der Rechteeinhaltung (1003)
(1003) Überprüfung ob die Rechte einer spezifischen Transaktion für die Überweisung eingehalten wurden und anschließend Abschluss der Zahlung durch Eingabe einer Autorisierung (1004)
(1004) Die Autorisierung einer Überweisung erfolgt durch einen weiteren Faktor. In Abhängigkeit ob eine fremde Transaktionserlaubnis vorliegt (1006 bzw. 1002) und diese erfolgreich bestätigt wurde in Prozessschritt (1003) wird die entsprechende spezifische Transaktion als Mittel für die Zahlung hinterlegt und das entsprechende Fremdkonto (1008) belastet. Andernfalls kann der Nutzer nur eines seiner eigenen Bankverbindungen auswählen und die Bezahlung durchführen (1007)
(1005) Der Nutzer gibt mindestens eine IBAN, einen Empfängername und eine Betragssumme an, der Verwendungszweck und das Mittel der Überweisung (z. B.: Regulär oder als Instant Payment Zahlung) sind optional. Anhand dieser Informationen wird das Vorhandensein einer passenden rechtegesteuerten Zahlung geprüft (1006)
(1006) Standardgemäß wird bei jeder Überweisung überprüft ob die Merkmale der Überweisung mit einer bestehenden rechtegesteuerten Transaktion übereinstimmen. Ist dies der Fall wird eine Überprüfung der Bedingungen angestoßen (1003), andernfalls wird die Zahlung zur Freigabe mittels Eingabe eines weiteren Faktors (1004) freigegeben
(1007) Im Falle einer nichtvorliegenden spezifischen Transaktion wird ein eigenes Konto des Nutzers belastet
(1008) Sofern alle Bedingungen einer spezifischen Transaktion für eine Überweisung erfüllt sind wird ein Fremdkonto belastet

10 shows the payment of a transfer using a rights-controlled payment

(1001) The user selects a transfer from the menu as a desired action
(1002) Selection of a specific rights-controlled transaction for transfer - pre-filling of all relevant information. This is followed by a verification of rights compliance (1003)
(1003) Check whether the rights of a specific transaction for the transfer have been complied with and then complete the payment by entering an authorization (1004)
(1004) A transfer is authorized by another factor. Depending on whether an external transaction permit is available (1006 or 1002) and this has been successfully confirmed in process step (1003), the corresponding specific transaction is deposited as a means of payment and the corresponding external account (1008) is debited. Otherwise, the user can only select one of his own bank details and make the payment (1007)
(1005) The user enters at least an IBAN, a recipient name and an amount, the intended purpose and the means of transfer (e.g. regular or instant payment) are optional. Based on this information, the existence of a suitable rights-controlled payment is checked (1006)
(1006) According to the standard, every transfer is checked to see whether the characteristics of the transfer match an existing rights-controlled transaction. If this is the case, the conditions are checked (1003), otherwise the payment is released for release by entering another factor (1004).
(1007) If there is no specific transaction, the user's own account will be debited
(1008) If all conditions of a specific transaction for a transfer are met, a third-party account will be debited

11 zeigt eine Beispielhafte Umsetzung bei einem Geldtransfer / Übertrag / Überweisung

(1101) Der Nutzer erfasst in der mobilen Applikation eine Überweisung an einen andere Empfänger (1122). Neben der händischen Erfassung einer Bezahlung kann ein Überweisungsträger oder Zahlungsauftrag mittels Foto erfasst und durch Sendung an den OCR Server (1112) abgeglichen werden und somit die notwendigen Zahlungsdaten erfasst werden. Die Transaktion wird bei der Erfassung an den Systemserver (1103) übermittelt
(1102) Der Nutzer erfasst in der Web-Applikation eine Überweisung an einen anderen Empfänger (1122). Die Transaktion wird bei der Erfassung an den Systemserver (1103) übermittelt
(1103) Der Systemserver prüft die Transaktionen auf die Korrektheit der Kundendaten (1104) und gegen die Betrugsdatenbank (1105). Im Falle einer Fehlermeldung wird der Kunde über eine abgebrochene Transaktion über den PUSH Server (1115) informiert. Andernfalls wird die Transaktion an den Transaktions-Server (1106) übergeben
(1104) Die Kunden-Datenbank enthält alle wesentlichen Kundendaten des Nutzers
(1105) In der Betrugs-Datenbank werden auffällige IBANs und Betrugsfälle gespeichert
(1106) Der Transaktions-Server überprüft ob für die Transaktion eine passende rechtegesteuerte Transaktion vorliegt, hierzu wird die IBAN / BIC-Datenbank nach passenden Einträgen überprüft. Bei einer passenden Transaktion wird die dort hinterlegte Bankverbindung an den Payment Server (1109) übertragen, andernfalls wird die Standard-Kontoverbindung des Nutzers an den Payment Server (1109) übergeben. Die Transaktion wird in der Transaktions-Datenbank (1107) gespeichert
(1107) In der Transaktions-Datenbank wird jede Zahlung dauerhaft gespeichert und so für den Nutzer jederzeit einsehbar
(1108) In der IBAN / BIC Datenbank werden alle relevanten Informationen einer rechtegesteuerten Transaktion gespeichert
(1109) Der Payment Server dient der Verarbeitung der Zahlungen und zur Übergabe der Zahlung an das Payment Gateway (1114) zur Kommunikation mit den Fremdbanken. Weiterhin wird nach der Hinterlegung der korrekten Bankverbindung aus der Bankaccount Datenbank (1110) oder der Kreditkarten-Datenbank (1111) eine Nachricht an den PUSH Server (1115) zur Sendung einer Zahlungsfreigabe gesendet. Bei Nutzung einer Bankverbindung eines anderen Nutzers durch Nutzung einer rechtegesteuerten Transaktion wird der entsprechende Nutzer über die Transaktion auf dem mobilen Endgerät (1116) oder dem Portal (1117) informiert
(1110) In der Bankaccount-Datenbank sind alle relevanten Daten einer Bankverbindung gespeichert
(1111) In der Kreditkarten-Datenbank sind alle relevanten Kreditkartendaten eines Nutzers gespeichert
(1112) Der OCR Server dient der Erkennung und Erfassung eines physischen Zahlungsauftrags aus der mobilen Applikation (1101). Der Beleg wird auf der Rechnungs-Datenbank (1113) gespeichert
(1113) In der Rechnungs-Datenbank werden alle über ein mobiles Endgerät erfassten Zahlungsaufträge erfasst
(1114) Das Payment Gateway verbindet die Lösung mit allen Drittbanken und anderen Zahlungsverkehrsdienstleistern mittels Standard-Schnittstellen
(1115) Der PUSH Server erfüllt mehrere Zwecke. Er sendet zum einen den Nutzer einen transaktionsspezifischen Code zur Ausführung einer Zahlung als Zweitfaktor. Weiterhin wird der aktuelle Status der Zahlung über den PUSH Server an die mobile Applikation (1101) übertragen
(1116) Sofern ein Nutzer eine Fremdbankverbindung mittels einer rechtegesteuerten Transaktion nutzt, wird der entsprechende Zahlender in der mobilen Applikation über die Transaktion informiert
(1117) Sofern ein Nutzer eine Fremdbankverbindung mittels einer rechtegesteuerten Transaktion nutzt, wird der entsprechende Zahlender im Portal über die Transaktion informiert
(1118) Standard-Schnittstelle der Bank des Zahlungspflichtigen zur Kommunikation mit dem Payment Gateway (1114) und der Kommunikation mit der Bank des Zahlungsempfängers (1120)
(1119) Zentraler Bank-Server der Bank des Zahlungspflichtigen
(1120) Standard-Schnittstelle der Bank des Zahlungsempfänger zur Kommunikation mit der Bank des Zahlungspflichtigen (1118)
(1121) Zentraler Bank-Server der Bank des Zahlungsempfängers
(1122) Zahlungsbeleg für den Zahlungsempfänger

11 shows an exemplary implementation for a money transfer / transfer / transfer

(1101) The user enters a transfer to another recipient (1122) in the mobile application. In addition to the manual entry of a payment, a transfer slip or payment order can be captured by means of a photo and matched by being sent to the OCR server (1112), and the necessary payment data can thus be entered. The transaction is sent to the system server (1103) upon capture
(1102) The user enters a transfer to another recipient (1122) in the web application. The transaction is sent to the system server (1103) upon capture
(1103) The system server checks the transactions for the correctness of the customer data (1104) and against the fraud database (1105). In the event of an error message, the customer will be informed about a canceled transaction via the PUSH server (1115). Otherwise, the transaction is committed to the transaction server (1106).
(1104) The customer database contains all of the user's key customer data
(1105) Conspicuous IBANs and cases of fraud are stored in the fraud database
(1106) The transaction server checks whether there is a suitable rights-controlled transaction for the transaction; the IBAN/BIC database is checked for suitable entries for this purpose. In the case of a suitable transaction, the bank details stored there are transferred to the payment server (1109), otherwise the user's standard account details are transferred to the payment server (1109). The transaction is stored in the transaction database (1107).
(1107) Every payment is permanently stored in the transaction database and can therefore be viewed by the user at any time
(1108) All relevant information of a rights-controlled transaction is stored in the IBAN / BIC database
(1109) The payment server is used to process the payments and to transfer the payment to the payment gateway (1114) for communication with the third-party banks. Furthermore, after the correct bank details have been deposited from the bank account database (1110) or the credit card database (1111), a message is sent to the PUSH server (1115) to send a payment release. When using another user's bank details by using a rights-controlled transaction, the relevant user is informed about the transaction on the mobile device (1116) or the portal (1117).
(1110) All relevant bank details are stored in the bank account database
(1111) All of a user's relevant credit card data are stored in the credit card database
(1112) The OCR server is used to recognize and record a physical payment order from the mobile application (1101). The receipt is stored on the invoice database (1113).
(1113) All payment orders recorded via a mobile device are recorded in the invoice database
(1114) The payment gateway connects the solution to all third-party banks and other payment transaction service providers using standard interfaces
(1115) The PUSH server serves several purposes. On the one hand, it sends the user a transaction-specific code to make a payment as a second factor. Furthermore, the current status of the payment is transmitted to the mobile application (1101) via the PUSH server
(1116) If a user uses a third-party bank connection by means of a rights-controlled transaction, the corresponding payer is informed about the transaction in the mobile application
(1117) If a user uses a third-party bank connection by means of a rights-controlled transaction, the corresponding payer is informed about the transaction in the portal
(1118) Standard interface of the payer's bank for communication with the payment gateway (1114) and communication with the payee's bank (1120)
(1119) Central bank server of the payer's bank
(1120) Standard interface of the payee's bank for communication with the payer's bank (1118)
(1121) Central bank server of the payee's bank
(1122) Payment receipt for the payee

12 zeigt ein Ablaufdiagramm bei einer Transaktion nach 11

(1201) Der Nutzer erfasst eine Zahlung durch manuelle Eingabe oder Erfassung mittels Photo und Analyse mittels OCR
(1202) Auswahl der Betragshöhe für die Überweisung
(1203) Auswahl ob es sich um eine einmalige oder wiederkehrende Zahlung handelt
(1204) Auswahl der Währung
(1205) Name der Transaktion / Verwendungszweck
(1206) Beschreibung der Transaktion (Optionales Feld) für weitere Informationen
(1207) Das System überprüft das Vorliegen einer passenden, rechtegesteuerten Zahlung
(1208) Bei Vorliegen einer passenden Transaktion wird ein Fremdkonto ausgewählt und dem Nutzer angezeigt
(1209) Sofern keine passende, rechtegesteuerte Transaktion vorliegt, wird das eigene Standardkonto ausgewählt - der Nutzer kann dieses auch in ein anderes eigenes Konto ändern
(1210) Bestätigung der Zahlung und Anzeige aller relevanten Informationen der Zahlunge
(1211) Freigabe der Zahlung mittels eines zweiten Faktors (z. B.: Eingabe eines Codes)
(1212) Das ausgewählte Konto wird belastet

12 shows a flowchart for a transaction 11

(1201) The user captures a payment by entering it manually or capturing it using a photo and analyzing it using OCR
(1202) Selection of the amount to be transferred
(1203) Selection whether it is a one-time or recurring payment
(1204) Currency selection
(1205) Transaction name / purpose
(1206) Transaction Description (Optional field) for more information
(1207) The system checks the existence of a suitable, rights-controlled payment
(1208) If there is a suitable transaction, a third-party account is selected and displayed to the user
(1209) If there is no suitable, rights-controlled transaction, the user's own standard account is selected - the user can also change this to another personal account
(1210) Confirmation of the payment and display of all relevant information of the payments
(1211) Approval of the payment using a second factor (e.g. entering a code)
(1212) The selected account will be debited

Beschreibung wenigstens eines Weges zur UmsetzungDescription of at least one way of implementation

Nachstehend wird eine Ausführungsform der offenbarten Verfahren und Anordnung ausführlich erörtert. Auch wenn eine spezifische Umsetzung diskutiert wird, erfolgt dies nur zu Veranschaulichungszwecken. Ein Fachmann wird erkennen, dass andere Komponenten, Konfigurationen und Schritte verwendet werden können, ohne von der Lehre und vom Umfang der Offenbarung abzuweichen.An embodiment of the disclosed methods and arrangement is discussed in detail below. Although a specific implementation is discussed, it is for illustrative purposes only. One skilled in the art will recognize that other components, configurations, and steps can be used without departing from the spirit and scope of the disclosure.

In 1 ist die beispielhafte Anordnung von verschiedenen Komponenten in dem Bezahlsystem anzeigt. Das gezeigte mobile Endgerät (101) bzw. die mobile Webseite (127) kann dabei tragbar oder stationär sein und mit weiteren mobilen Endgeräten kombiniert werden.In 1 shows the exemplary arrangement of various components in the payment system. The mobile terminal (101) or the mobile website (127) shown can be portable or stationary and can be combined with other mobile terminals.

Die computerausführbare Anweisung wird in das Softwareprogramm auf dem mobilen Endgerät eingegeben und von dort an das System zur Verarbeitung übergeben.The computer-executable instruction is entered into the software program on the mobile terminal and from there transferred to the system for processing.

Fachleute werden erkennen, dass weitere Ausführungsformen der Erfindung vorstellbar sind, hierzu zählen andere tragbare Geräte, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputer und der Gleichen.Those skilled in the art will recognize that other embodiments of the invention are conceivable, including other portable devices, programmable consumer electronics, network PCs, minicomputers, and the like.

Schutzanspruchprotection claim

Elektronisches Bezahlverfahren mit der Möglichkeit zur Einschränkung und Regelung der Gültigkeit von Zahlungen.

1. Verfahren zur Eingabe und Verarbeitung von rechtegesteuerten Zahlungen Das Verfahren umfasst die Eingabe von Zahlungen inklusive Zahlungseinschränkungen (Bedingungen) auf bestimmte Orte, Zeiten und spezifische Ereignisse und weiterhin die Möglichkeit zur Verarbeitung einer solchen rechtegesteuerten Zahlung in einem Vier-Parteien-Bezahlsystem wie in der 1 beschrieben
2. Verfahren zur Eingabe und Verarbeitung von rechtegesteuerten Zahlungen Das Verfahren umfasst die Eingabe von Zahlungen inklusive Zahlungs-einschränkungen auf bestimmte Orte, Zeiten und spezifische Ereignisse und weiterhin die Möglichkeit zur Verarbeitung einer solchen rechtegesteuerten Zahlung in einem Drei-Parteien-Bezahlsystem wie in der 2 beschrieben
3. Computerprogrammprodukt zur Eingabe und Erfassung einer solchen Zahlungen nach Anspruch 1 und Anspruch 2 dieses Verfahrens wie in der 3A - 3H beschrieben

Electronic payment method with the option of restricting and regulating the validity of payments.

1. Procedure for entering and processing rights-controlled payments The procedure includes entering payments including payment restrictions (conditions) on certain places, times and specific events and further the possibility of processing such rights-controlled payment in a four-party payment system as in the 1 described
2. Procedure for entering and processing rights-controlled payments The procedure includes the entry of payments including payment restrictions to certain places, times and specific events and also the possibility of processing such a rights-controlled payment in a three-party payment system as in the 2 described
3. Computer program product for entering and recording such a payment according to claim 1 and claim 2 of this method as in 3A - 3H described

Claims

Procedure for entering and processing rights-controlled payments The procedure includes entering payments including payment restrictions (conditions) on certain places, times and specific events and further the possibility of processing such rights-controlled payment in a four-party payment system as in the 1 described

Procedure for entering and processing rights-controlled payments The procedure includes the entry of payments including payment restrictions to certain places, times and specific events and further the possibility of processing such a rights-controlled payment in a three-party payment system as in the 2 described

Computer program product for entering and recording such payments claim 1 and claim 2 this procedure as in the 3A - 3H described