WO2004034343A2 - Verfahren zur abwicklung eines zahlungsvorganges im elektronischen handel - Google Patents

Verfahren zur abwicklung eines zahlungsvorganges im elektronischen handel Download PDF

Info

Publication number
WO2004034343A2
WO2004034343A2 PCT/EP2003/008516 EP0308516W WO2004034343A2 WO 2004034343 A2 WO2004034343 A2 WO 2004034343A2 EP 0308516 W EP0308516 W EP 0308516W WO 2004034343 A2 WO2004034343 A2 WO 2004034343A2
Authority
WO
WIPO (PCT)
Prior art keywords
credit card
buyer
service provider
financial service
transaction code
Prior art date
Application number
PCT/EP2003/008516
Other languages
English (en)
French (fr)
Other versions
WO2004034343A3 (de
Inventor
Qi Guan
Markus Lenger
Marcel Vencour
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2004034343A2 publication Critical patent/WO2004034343A2/de
Publication of WO2004034343A3 publication Critical patent/WO2004034343A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the invention relates to a method for processing a payment transaction in electronic commerce in a communication network, in particular the Internet, between a buyer and a dealer via a credit card financial service provider.
  • Credit card payments are common.
  • the credit card is currently the only payment method that is accepted worldwide.
  • Teen paying with a credit card does not need a PIN, physical possession and a signature are sufficient.
  • Credit card payments are also increasingly being processed in public networks, such as the Internet, or in mobile radio networks.
  • public networks such as the Internet, or in mobile radio networks.
  • the openness and transparency of the Internet entails the risk that sensitive data may be overheard and possibly misused.
  • the processing of business transactions on the Internet can only work satisfactorily if the payment process is largely protected against misuse for both the buyer and the seller. Wide acceptance of electronic payments can only be expected if there is a relationship of trust between the parties involved and the payment process is as free as possible from risk.
  • the transmission of confidential data via the Internet is a central security problem for the buyer.
  • the number of complaints about credit card transactions via the Internet is also an enormous economic risk for the credit institutions involved in the processing of an online payment process.
  • SSL Secure Socket Layer
  • SSL Secure Socket Layer
  • SET Secure Electronic Transaction
  • SET is a specification specifically designed for financial transactions. Authentication is carried out using an electronic one Signature, the so-called digital signature.
  • SET guarantees both the confidentiality and the encryption of the transmitted information. This means that, on the one hand, it is ensured that nobody in the virtual world gets access to information that is not intended for them.
  • the transmitted information is made illegible for third parties using a cryptographic process. The consequence of this is that the merchant does not have access to the customer's account data or his card status. Conversely, the institution dealing with the financial transaction receives no information about the type and content of the order.
  • the present invention is based on the object of specifying a method for handling a payment transaction in an open network in such a way that a maximum degree of security is guaranteed for the parties involved without the need for complex changes to the communication devices.
  • a credit card financial service provider that is an institution dealing with the financial transaction or a conventional credit card system, generates at least one transaction code at the request of a buyer and transmits it to the buyer and the buyer transmits this to at least one transaction Code used against a merchant instead of a credit card number. So it won't be one
  • the transaction code is only intended for processing a financial transaction and is only valid for the trader who is involved in the transaction.
  • the transaction code is the most common Transaction number, the so-called "TAN", as it is sent from time to time in the form of lists in tele-banking applications from a bank to its customers for the processing of banking transactions, is very similar in the processing of the payment transaction.
  • the buyer Since the buyer does not transmit the number of his credit card to the seller via the insecure internet to the seller, there can be no misuse with the actual number of the credit card customer. For the buyer, the use of this unique number means that the risk of processing payments is minimal.
  • the method according to the invention improves trust in the execution of a business. The advantage here is that neither at the buyer nor at the
  • the credit card provider acts as an agent between the credit card company and the end customer, the buyer.
  • the time limit can be simply that the time interval begins with the request of the buyer and ends after a session time between the credit card financial service provider and the buyer.
  • the credit card financial service provider limits the time interval to less than an hour.
  • the security in requesting and transmitting the transaction code between the buyer and the credit institution can advantageously be increased if the credit card financial service provider transmits the transaction code to the buyer via a cryptographic protocol. It is advantageous here if the transmission of the transaction code is encrypted and the authentication of the buyer is carried out using a digital signature. It is also conceivable that the credibility of the buyer with the credit card financial service provider is established by entering a user name and / or password.
  • the credit card financial service provider is an Internet service provider. This opens up the possibility that on the basis of existing business relationships between the buyer and the Interent Service Provider, a payment process can also be carried out if the buyer has no contractual relationship with any of the merchant's credit card institutions.
  • FIG. 1 shows a schematic representation of the known handling of a payment transaction on the Internet, in which the buyer uses his credit card number in the network,
  • FIG. 2 shows the sequence of a first exemplary embodiment of the method according to the invention in a schematic representation, in which the buyer has the corresponding credit card of the retailer,
  • Figure 3 shows the sequence of a second embodiment of the inventive method in a schematic
  • FIG. 1 shows the sequence of a payment process as is usually the case in an open network ON, such as the Internet, when a credit card number is entered more developed, is shown schematically. The process is identified by arrows with the reference numerals 1 to 5.
  • a customer C sends his credit card number, name, billing address and other information related to the financial transaction to ON via the Internet
  • the trader M sends the information relevant to the financial transaction to his bank MB (2).
  • This merchant bank MB forwards the information via a credit card / bank network BN to a bank IB which has issued the credit card of the customer C (3).
  • this card-issuing bank IB After a verification process, this card-issuing bank IB notifies the dealer MB of the bank via the credit card / bank network BN whether it confirms the transaction (4).
  • the dealer M is informed by his bank MB (5) when this confirmation is available. If this is the case, dealer M executes the purchase requisition.
  • the dealer M After a predetermined unit of time, the dealer M asks his bank MB to charge the customer's bank IB with the corresponding amount of money from the transaction. This takes place again through a request via the bank network BN to the bank IB of the customer C.
  • the transaction comes to an end when the card-issuing bank IB of the customer books the price of the goods less the bank or service fees to the dealer bank MB.
  • the account of the card issuing bank IB of the customer C now shows the amount debited to the dealer M, which, however, is actually only paid by the customer C at a later point in time.
  • FIG. 2 a first embodiment of the invention is shown schematically in the sequence.
  • the buyer C in the illustration in FIG. 1, it is the “end user”, has loaded in his virtual shopping cart products that he would like to pay for at the retailer M, “e-seller” in FIG. 1. He has a CC1 credit card.
  • Buyer C is with a credit card Financial service provider CC-FD, "Credit Card Company" in Figure 1, registered.
  • the course of communication in the processing of the payment process is shown in Figure 2 by arrows with the reference numerals al) to a5).
  • the buyer chooses C in the The merchant's website uses the credit card payment mode, according to which he offers the acceptance of various credit cards, the credit cards of the card institutes CC1 and CC2 in Figure 2.
  • the Internet buyer is a customer of a suitable credit card company CC1
  • the Internet buyer now creates a transaction code (al TAN request) from his credit card company (CGI).
  • the credit card institute CC1 determines the identity of the requesting person and their authorization to carry out a financial transaction upon this request (Authentication)
  • the End-Us he has recognized in Figure 2, it generates a transaction code. Either each character of the credit card number is converted into another character of a different alphabet, or a new set of images is created.
  • the transaction code is generated, it is transmitted to the buyer (a2 TAN). Both the request from the Internet user and the transmission of the transaction code from
  • the S-HTTP protocol is particularly suitable for this. This protocol allows authentication through digital signatures and encryption of the messages to be transmitted in both directions.
  • the S-HTTP protocol is a standard of the Internet Engineering Task Force.
  • the Internet buyer C transmits the transaction code to the seller M in a third step d (a3 TAN) he acts exactly as if it were a
  • the merchant M also handles the transaction code like a credit card number and transmits the invoice amount together with the transaction code (a4 Bill + TAN) to the credit card company.
  • the credit card financial service provider CC-FD When the credit card financial service provider CC-FD has paid the invoice amount to the seller, the seller M arranges the delivery of the goods.
  • the credit card company informs the Internet buyer of the invoice amount to be paid. If the internet buyer recognizes the order process that has been initiated and confirms it, the payment process is over.
  • the credit card financial service provider CC-FD pays the invoice amount to the seller M.
  • Characteristic of the method according to the invention is therefore the use of a transaction code generated during the payment process, which acts like a “temporary credit card number”. Because this transaction code misuse is largely ruled out, and since its use is treated like a credit card number, it is not necessary for trading partners C and M to be certified or to have certified software installed on their communication facilities of seller M to that
  • Credit card companies do not require any new procedures, but take place in a conventional manner. The only difference is that instead of the usual credit card number, the transaction code now appears on the invoice. The credit card company can use this transaction code to assign the end customer. The further billing of the credit card company to the end customer is handled in a conventional manner. Buyer C's account is usually debited at a later date. It should be noted that the buyer can also order several TANs from the credit card company in advance. This has the advantage that there is no need to make a single request to the credit card company for every purchase.
  • a so-called credit card provider, credit card provider CCP is interposed between the end customer C and the credit card company, the credit card company.
  • the credit card financial service provider consists of the credit card provider and the credit card company.
  • the credit card provider CCP can be, for example, an Internet service provider ISP.
  • customer C would like a product or service that he selected over the Internet from
  • Pay dealer M To do this, he chooses the payment method via a certain credit card company, but he does not need to be a customer. It is only necessary for the payment processing that the buyer C is a CCP customer with a credit card provider who either offers a corresponding credit card in his range or handles the contractual relationship with the buyer C.
  • the credit card provider CCP itself acts as a customer towards a credit card company, Credit Card Company.
  • the payment process is carried out similarly to that explained in FIG. 2: the buyer, that is to say the end customer, orders (BL TAN request) from his credit card provider a transaction code which is only valid for a one-time financial transaction.
  • the credit card provider CCP in turn orders (b2 TAN request) a one-time transaction code from a credit card company with which it, but not the buyer, is a customer.
  • This credit card company authenticates the credit card provider CCP. If the authenticity, that is the authenticity, of the Credit card provider CCP is established, the credit card company generates a transaction code valid for payment processing and transmits (b3 TAN) this code to the credit card provider.
  • the credit card provider receives this information and in turn sends it (b4 TAN) to the end customer, buyer C.
  • the end customer C uses this forwarded character set instead of the conventional credit card number for the payment process on the website of the seller M. For this purpose, he transmits (b5 TAN) the transaction code to the
  • the seller M bills the credit card company, Credit Card Company, again in the conventional way, with the only difference that instead of the usual credit card number, the transaction code and the invoice are now transmitted (b ⁇ Bill + TAN).
  • the credit card company can use the transaction code to determine the credit card provider.
  • the credit card company can then be billed to the credit card provider in a known manner (b7 Bill + TAN).
  • the transaction code is used to assign the end customer to the credit card provider.
  • Another possibility is a B2B, that is, a business to business interface.
  • the credit card provider uses the transaction code to determine the end customer.
  • the accounting takes place from
  • the buyer can also request several TANs from the credit card provider in advance. This has the advantage that a TAN request does not have to be sent to the CCP for every purchase.
  • the credit card provider CCP can request several TANs from the credit card company in advance. It is also advantageous here that a connection for a single TAN request to the credit card company does not have to be established for every TAN request of the buyer.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Abstract

Verfahren zur Abwicklung eines Zahlungsvorganges über einen Kreditkarten-Finanzdienstleister im elektronischen Handel in einem offenen Netz, insbesondere dem Internet, zwischen einem Käufer und einem Händler, wobei der KreditkartenFinanzdienstleister auf Anforderung des Käufers an diesen einen für einen Zahlungsvorgang gültigen Transaktions-Code übermittelt und der Käufer diesen Transaktions-Code an Stelle seiner Kreditkartennummer bei der Abwicklung des. Zahlungsvorganges mit den Händlern verwendet.

Description

Verfahren zur Abwicklung eines Zahlungsvorganges im elektronischen Handel
Bezeichnung der Erfindung
Die Erfindung betrifft ein Verfahren zur Abwicklung eines Zahlungsvorganges im elektronischen Handel in einem Kommunikationsnetz, insbesondere dem Internet, zwischen einem Käufer und einem Händler über einen Kreditkarten- Finanzdienstleister .
Stand der Technik
Zahlungen mit Kreditkarten sind weit verbreitet. Die Kreditkarte ist zur Zeit die einzige Zahlungsart, die weltweit akzeptiert wird. Wer mit einer Kreditkarte zahlt, benötigt keine Geheimzahl, der physische Besitz und die Unterschrift genügt. Zunehmend werden Zahlungen mit Kreditkarten auch in öffentlichen Netzen, wie dem Internet, oder in Mobilfunknetzen, abgewickelt. Die Offenheit und Transparenz des Internets birgt aber die Gefahr in sich, dass sensible Daten belauscht und möglicherweise missbräuchlich verwendet werden. Die Abwicklung geschäftlicher Transaktionen im Internet kann aber nur dann zufriedenstellend funktionieren, wenn der Bezahlvorgang sowohl für den Käufer, als auch für den Verkäufer, weitgehend vor Missbrauch geschützt ist. Mit einer breiten Akzeptanz des elektronischen Zahlungsverkehrs kann nur dann gerechnet werden, wenn zwischen den Beteiligten ein Vertrauensverhältnis besteht und der Vorgang der Bezahlung möglichst frei von Risiko ist.
Wird beispielsweise die Kreditkartennummer im Internet abgefangen, kann der Lauscher problemlos überall dort einkaufen, wo er anonym bleibt. Der Besitzer der Kreditkarte hat im Falle eines erkannten Missbrauchs zwar meist die Möglichkeit die Zahlung zu stornieren. Für den Händler verbleibt aber das Risiko, dass er, für eine erbrachte Leistung, die möglicherweise direkt konsumiert wurde, vom Karteninstitut keine Bezahlung erhält.
Insbesondere die Übermittlung vertraulicher Daten über des Internet, wie beispielsweise die Nummer der Kreditkarte, empfindet der Käufer als zentrales Sicherheitsproblem. Die Zahl von Reklamationen zu Kreditkartentransaktionen über das Internet ist auch für die an der Abwicklung eines Online- Zahlungsvorganges beteiligten Kreditinstitute ein enormes wirtschaftliches Risiko.
Auf Grund der mangelnden technischen Sicherheit der Transaktion stehen daher alle Beteiligten einer finanziellen Online-Transaktion im Internet noch immer kritisch gegenüber.
Zur sicheren Übertragung von Daten sind verschiedene Verschlüsselungsverfahren bekannt geworden. Weit verbreitet ist das Protokoll SSL (Secure Socket Layer) . SSL ist ein Standard für die Übertragung von vertraulichen Daten in
Netzwerken. Er bietet zwar ausreichenden Schutz gegen das Abfangen von vertraulichen Daten, wie der Kreditkartendaten, oder gegen das Verändern von Daten durch Dritte. Von zentraler Bedeutung für eine sichere Zahlung im Internet ist aber, dass Gewissheit darüber herrscht, dass sowohl der Käufer als auch der Händler überhaupt berechtigt sind Zahlungen mit einer Karte abwickeln zu dürfen, sowie deren Rechtsverbindlichkeit. SSL ermöglicht aber keine Authentifizierung der Teilnehmer.
Als das derzeit sicherste Bezahlungsverfahren für Käufer und Händler in einem offenen Netz gilt der Sicherheitsstandard SET (Secure Electronic Transaction) . SET ist eine speziell auf finanzielle Transaktionen ausgerichtete Spezifikation. Die Authentifizierung erfolgt mittels einer elektronischen Unterschrift, der sogenannten digitalen Signatur. SET gewährleistet sowohl die Vertraulichkeit als auch die Verschlüsselung der übertragenen Informationen. Diese bedeutet, dass einerseits sichergestellt ist , dass in der virtuellen Welt niemand Informationen zur Einsicht bekommt, die nicht für ihn bestimmt sind. Andererseits werden die übermittelten Informationen mittels eines kryptographischen Verfahrens für Dritte unlesbar gemacht. Folge davon ist, dass der Händler weder die Kontodaten des Kunden noch dessen Kartenstatus zur Einsicht bekommt. Umgekehrt erhält die mit der finanziellen Transaktion befasste Institution keine Informationen über Art und Inhalt der Bestellung. Die Durchführung eines SET-Bezahlungsverfahrens ist aber im Internet an eine Reihe von Voraussetzungen gebunden. Zum einen sind spezielle Software-Komponenten erforderlich, die an der Schnittstelle zum öffentlichen Netz installiert sein müssen. D.h., sowohl der Käufer, wie auch der Händler, benötigen sog. Plug-ins im Browser, oder spezielle Software- Komponenten, die in das Betriebssystem eingebunden werden müssen.
Zum anderen wird von den Beteiligten vorausgesetzt, dass sie eine zentrale Zertifizierungsstelle akzeptieren, welche die Marktpartner eindeutig identifiziert und alle eingesetzten Softwareprodukte auf Akzeptanz überprüft, um den Sicherheits- und Qualitätsstandard des SST-Bezahlungsverfahren zu gewährleisten .
Als Nachteil von SET wird gesehen, dass es technisch komplex und finanziell ungünstig ist. In besonderem Maße ist dies im Internet für den sogenannten „Mikro-,, und „Pikopayment- Bereich", das sind Beträge unter € 5,- bzw. 1 €, von
Nachteil. Dieser Zahlungsbereich hat aber im Internet hohe Zuwachsraten. Die Komplexität des Systems verhindert auch die Integration in vielen in Banken und bei Kreditkartensystemen vorhandenen Altsystemen. Insbesondere wird die Notwendigkeit, sowohl auf der Seite des Käufers als auch auf der Seite des Verkäufers eine spezielle, oft kostenplichtige Software installieren zu müssen, von den Beteiligten als nachteilig empfunden.
Darstellung der Erfindung
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Abwicklung eines Zahlungsvorganges in einem offenen Netz so anzugeben, dass für die Beteiligten ein Höchstmaß an Sicherheit gewährleistet ist ohne dass an den Kommunikationseinrichtungen aufwändige Änderungen erforderlich sind.
Diese Aufgabe wird erfindungsgemäß durch die Merkmale des Patentanspruchs 1 gelöst. Auf vorteilhafte Ausgestaltungen der Erfindung nehmen die Unteransprüche Bezug.
Charakteristisch für die Erfindung ist mithin, dass ein Kreditkarten-Finanzdienstleister, das ist eine mit der finanziellen Transaktion befasste Institution bzw. ein herkömmliches Kreditkartensystem, auf Anforderung eines Käufers zumindest einen Transaktions-Code erzeugt und an den Käufer übermittelt und der Käufer diesen zumindest einen Transaktions-Code gegenüber einem Händler an Stelle einer Kreditkartennummer verwendet. Es wird also nicht eine
Kreditkartennummer, sondern eine umgesetzte Form davon im Netz für den Zahlvorgang verwendet. Der Transaktions-Code ist nur für die Abwicklung eines finanziellen Geschäftes bestimmt und nur gegenüber dem Händler, der am Geschäft beteiligt ist, gültig. Der Transaktions-Code ist der gebräuchlichen Transaktionsnummer, der sogenannten „TAN", wie sie bei Tele- Banking-Anwendungen in Form von Listen von Zeit zu Zeit von einer Bank an ihre Kunden zur Abwicklung von Bankgeschäften zugeschickt wird, in der Abwicklung des Zahlungsvorgangs sehr ähnlich.
Da der Käufer nicht die Nummer seiner Kreditkarte an den Verkäufer über das unsichere Internet an den Verkäufer übermittelt, kann kein Missbrauch mit der eigentlichen Nummer des Kreditkartenkunden entstehen. Für den Käufer ist durch die Verwendung dieser einmalig gültigen Nummer das Risiko bei einer Zahlungsabwicklung minimal. Zwischen dem Käufer und dem Internet-Shop bzw. einem Content-Provider wird durch das erfindungsgemäße Verfahren das Vertrauen in die Abwicklung eines Geschäftes verbessert. Von Vorteil ist dabei, dass weder beim Käufer noch beim
Händler zusätzlich neue Software installiert werden muss bzw. keine neuen Verträge mit Kreditkartenunternehmen abgeschlossen werden müssen. Da der Transaktions-Code wie eine Kreditkartennummer gehandhabt wird, ist die Interoperabilität zwischen unterschiedlichen Hardware- und Software-Systemen gesichert. Dadurch eröffnen sich für die entsprechenden Kreditkartenunternehmen, insbesondere aber für den Kreditkarten-Provider oder ggf. dem Internet-Service- Provider, zusätzliche Geschäftsmöglichkeiten.
Der Kreditkarten-Provider tritt in der Rolle eines Agenten zwischen dem Kreditkartenunternehmen und dem Endkunden, dem Käufer, auf.
Da der Transaktions-Code nur innerhalb eines begrenzten Zeitintervalls, vom Kreditkarten-Finanzdienstleister als gültig anerkannt wird, verbessert sich weiterhin die Sicherheit bei der Abwicklung der finanziellen Transaktion. Obwohl grundsätzlich jeder Algorithmus einer Verschlüsselung durch einfaches Ausprobieren mit allen möglichen Schlüsseln β zu knacken ist, ist auf Grund der vorliegenden, vergleichsweise geringen Zeit, das Risiko des Missbrauchs des Transaktions-Code sehr gering.
Die zeitliche Begrenzung kann einfach dadurch geschehen, dass das Zeitintervall mit der Anforderung des Kaufers beginnt und nach Ablauf einer Sitzungszeit zwischen dem Kreditkarten- Finanzdienstleister und dem Kaufer endet.
Besonders gunstig ist, wenn der Kreditkarten- Finanzdienstleister das Zeitintervall auf kleiner als eine Stunde begrenzt.
Die Sicherheit bei der Anforderung und Übermittlung des Transaktionscodes zwischen Kaufer und Kreditinstitut kann vorteilhaft dadurch erhöht werden, wenn der Kreditkarten- Finanzdienstleister den Transaktions-Code an den Kaufer über ein kryptographisches Protokoll übermittelt. Hierbei ist es gunstig, wenn die Übermittlung des Transaktions-Codes verschlüsselt und die Authentifizierung des Kaufers durch eine digitale Signatur erfolgt. Es ist auch denkbar, dass die Glaubwürdigkeit des Kaufers beim Kreditkarten-Finanzdienstleister durch Eingabe von Benutzernamen und/oder Kennwort hergestellt wird.
Es ist von besonderem Vorteil, wenn der Kreditkarten- Finanzdienstleister ein Internet Service Provider ist. Dies eröffnet die Möglichkeit, dass auf der Grundlage bestehender Geschaftsbeziehungen zwischen Kaufer und Interent-Service- Provider auch dann ein Bezahlvorgang abgewickelt werden kann, wenn der Kaufer mit keiner der Kreditkarteninstitute des Handlers in einer Vertragsbeziehung steht.
Die Integration in bestehsehende Systeme ist insbesondere dann einfach, wenn der Transaktions-Code aus einer Folge von Ziffern besteht, deren Zahl der Ziffernzahl gebräuchlicher Kreditkartennummern entspricht.
Kurzbeschreibung der Zeichnungen
Zur weiteren Erläuterung der Erfindung wird auf die Zeichnungen Bezug genommen, in deren Figuren zwei Ausführungsformen des erfindungsgemäßen Verfahrens im Ablauf schematisch dargestellt sind. Es zeigen:
Figur 1 in einer schematischen Darstellung die bekannte Abwicklung eines Bezahlungsvorganges im Internet, bei der der Käufer seine Kreditkartennummer im Netz verwendet,
Figur 2 den Ablauf eines ersten Ausführungsbeispiels des erfindungsgemäßen Verfahrens in einer schematischen Darstellung, bei der der Käufer die entsprechende Kreditkarte des Händlers besitzt,
Figur 3 den Ablauf eines zweiten Ausführungsbeispiels des erfindungsgemäßen Verfahrens in einer schematischen
Darstellung, bei der der Käufer die entsprechende Kreditkarte des Händlers nicht besitzt.
Ausführung der Erfindung
In Figur 1 ist der Ablauf eines Zahlungsvorganges wie er üblicherweise in einem offenen Netz ON, wie beispielsweise dem Internet, mit der Eingabe einer Kreditkartennummer abgewickelter wird, schematisch dargestellt. Der Ablauf ist durch Pfeile mit den Bezugszeichen 1 bis 5 gekennzeichnet. Ein Kunde C sendet seine Kreditkartennummer, seinen Namen, seine Rechnungsanschrift und andere Informationen betreffend die finanzielle Transaktion über das Internet ON an den
Händler M (1) . Der Händler M schickt die für die finanzielle Transaktion relevanten Informationen an seine Bank MB (2) . Diese Händlerbank MB leitet die Information über ein Kreditkarten/Banken-Netzwerk BN an eine Bank IB weiter, welche die Kreditkarte des Kunden C ausgegeben hat (3) .
Nach einem Prüfvorgang teilt diese kartenausgebende Bank IB über das Kreditkarten/Banken-Netzwerk BN der Bank des Händlers MB ihre Entscheidung mit, ob sie die Transaktion bestätigt (4) . Der Händler M wird von seiner Bank MB informiert (5), wenn diese Bestätigung vorliegt. Ist dies der Fall, führt der Händler M die Bestellanforderung aus. Nach einer vorgegebenen Zeiteinheit fordert der Händler M sein Kreditinstitut MB auf, die Bank IB des Kunden mit dem entsprechenden Geldbetrag der Transaktion zu belasten. Dies erfolgt wieder durch eine Anforderung über das Bankennetzwerk BN an die Bank IB des Kunden C. Die Transaktion kommt zu Ende, wenn die kartenausgebende Bank IB des Kunden an die Händlerbank MB den Preis der Ware abzüglich der Bank- bzw. Service-Gebühren verbucht. Das Konto der kartenausgebenden Bank IB des Kunden C zeigt nun den an den Händler M abgebuchten Betrag, der allerdings zu einem späteren Zeitpunkt erst vom Kunden C tatsächlich bezahlt wird.
In der Figur 2, ist eine erste Ausführung der Erfindung schematisch im Ablauf dargestellt. Der Käufer C, in der Darstellung der Figur 1 ist es der „end user", hat in seinem virtuellen Warenkorb Produkte geladen die er beim Händler M, „e-seller" in Figur 1, bezahlen möchte. Er besitzt die Kreditkarte CC1. Der Käufer C ist bei einem Kreditkarten- Finanzdienstleister CC-FD, „Credit Card Company" in Figur 1, registriert. Der Ablauf der Kommunikation bei der Abwicklung des Zahlungsvorganges ist in Figur 2 durch Pfeile mit den Bezugszeichen al) bis a5) dargestellt. Bei der Bezahlung wählt der Käufer C in der Web-Seite des Händlers den Zahlungsmodus Kreditkarte, wonach dieser die Akzeptanz verschiedener Kreditkarten, in Figur 2 sind es die Kreditkarten der Karteninstitute CC1 und CC2, anbietet. In unserem Beispiel ist der Internet-Käufer Kunde eines passenden Kreditkartenunternehmens CC1. Zur Abwicklung des Zahlvorganges beantragt nun der Internet-Käufer von seiner Credit-Card-Company (CGI) gemäß der Erfindung einen Transaktions-Code (al TAN Request) . Das Kreditkarteninstitut CC1 stellt auf diese Anfrage hin die Identität der anfragenden Person und deren Berechtigung zur Durchführung einer finanziellen Transaktion fest (Authentifizierung) . Sobald das Kreditkartenunternehmen CC1 die Berechtigung seines Kunden, des End-User in Figur 2, erkannt hat, generiert es einen Transaktions-Code. Dabei wird entweder jedes Zeichen der Kreditkartennummer in ein anderes Zeichen eines anderen Alphabets umgesetzt, oder eine neue Bildmenge erzeugt. Nachdem der Transaktions-Code erzeugt ist, wird dieser an den Käufer übermittelt (a2 TAN) . Sowohl die Anfrage seitens des Internet-Benutzers als auch die Übermittlung des Transaktions-Codes vom
Kreditkartenunternehmen an den Internet-Nutzer wird bevorzugt über ein kryptographisches Protokoll abgewickelt. Geeignet hierfür ist insbesondere das Protokoll S-HTTP. Dieses Protokoll erlaubt die Authentifizierung durch digitale Signaturen sowie die Verschlüsselung der zu übertragenden Nachrichten in beiden Richtungen. Das Protokoll S-HTTP ist ein Standard der Internet Engineering Task Force. Im weiteren Verlauf der Abwicklung des Bezahlvorganges übermittelt der Internet-Käufer C in einem dritten Schritt d(a3 TAN) den Transaktions-Code an den Verkäufer M. Dabei verfährt er genauso, als ob es sich um eine
Kreditkartennummer handeln würde. Auch der Händler M handhabt den Transaktions-Code wie eine Kreditkartennummer, und übermittelt an das Kreditkartenunternehmen den Rechnungsbetrag samt des Transaktions-Code (a4 Bill + TAN) . Wenn der Kreditkarten-Finanzdienstleister CC-FD den Rechnungsbetrag an den Verkäufer bezahlt hat, veranlasst der Verkäufer M die Lieferung der Ware. Das Kreditkartenunternehmen informiert in einem fünften Schritt (a5 Bill(+TAN)) den Internet-Käufer über den zu zahlenden Rechnungsbetrag. Wenn der Internet-Käufer darin seinen eingeleiteten Bestellvorgang wieder erkennt und diesen quittiert, ist der Zahlungsvorgang zu Ende. Der Kreditkarten-Finanzdienstleister CC-FD bezahlt den Rechnungsbetrag an den Verkäufer M. Charakteristisch für das erfindungsgemäße Verfahren ist mithin, die Verwendung eines während des Bezahlvorganges generierten Transaktions-Codes, der wie eine „temporary credit card number" wirkt. Da dieser Transaktions-Code nur eine sehr kurze Lebensdauer besitzt, ist ein Missbrauch weitgehend ausgeschlossen. Da ihr Gebrauch wie eine Kreditkartennummer gehandhabt wird, ist es nicht erforderlich, dass die Handelspartner C und M zertifiziert sein müssen bzw. auf ihren Kommunikationseinrichtungen eine zertifizierte Software installieren müssen. Auch die Rechnungslegung des Verkäufers M an das
Kreditkartenunternehmen (Credit Card Company) erfordert keine neuen Handlungsabläufen, sondern erfolgt auf herkömmliche Art und Weise. Es existiert nur insofern ein Unterschied, dass statt der üblichen Kreditkartennummer nun der Transaktions- Code auf der Rechnung erscheint. Das Kreditkartenunternehmen kann über diesen Transaktions-Code den Endkunden zuordnen. Auch die weitere Rechnungslegung des Kreditkartenunternehmens an den Endkunden wird auf herkömmliche Art und Weise abgewickelt. Die Belastung des Kontos des Käufers C erfolgt üblicherweise zu einem späteren Zeitpunkt. Es sei angemerkt, dass der Käufer auch mehrere TANs im voraus vom Kreditkartenunternehmen ordern kann. Dies hat den Vorteil, dass nicht für jeden Kauf eine einzelne Anforderung zum Kreditkartenunternehmen erfolgen muss.
In einem zweiten Ausführungsbeispiel der Erfindung, dessen schematischer Ablauf in Figur 3 dargestellt ist, ist zwischen dem Endkunden C und dem Kreditkartenunternehmen, der Credit Card Company, ein sog. Kreditkarten-Provider, Credit Card Provider CCP, dazwischen geschaltet. Der Kreditkarten- Finanzdienstleister besteht hier also aus dem Credit Card Provider und der Credit Card Company. Der Credit Card Provider CCP kann zum Beispiel ein Internet-Service-Provider ISP sein. Auch hier möchte der Kunde C eine Ware oder eine Dienstleistung, die er über das Internet auswählte, beim
Händler M bezahlen. Er wählt dazu die Zahlungsmethode über ein bestimmtes Kreditkartenunternehmen, dessen Kunde er jedoch nicht zu sein braucht. Notwendig für die Zahlungsabwicklung ist lediglich, dass der Käufer C bei einem Kreditkarten Provider CCP Kunde ist, der entweder eine entsprechende Kreditkarte in seinem Sortiment anbietet oder über die Vertragsbeziehung zum Käufer C abwickelt. Der Kreditkartenprovider CCP tritt in diesem Ausführungsbeispiel also selbst als Kunde gegenüber einem Kreditkartenunternehmen, Credit Card Company, auf. Die
Abwicklung des Bezahlvorganges erfolgt ähnlich wie in Figur 2 erläutert: der Käufer, das heißt der Endkunde, bestellt (bl TAN Request) von seinem Kreditkartenprovider einen nur für eine einmalige finanzielle Transaktion gültigen Transaktions- Code. Der Kreditkartenprovider CCP bestellt (b2 TAN Request) seinerseits einen nur einmal gültigen Transaktions-Code bei einem Kreditkartenunternehmen bei dem er, nicht aber der Käufer, Kunde ist. Dieses Kreditkartenunternehmen führt eine Authentifizierung des Kreditkartenproviders CCP durch. Wenn die Echtheit, das heißt die Authentizität, des Kreditkartenproviders CCP festgestellt ist, erzeugt das Kreditkartenunternehmen einen für eine Zahlungsabwicklung gültigen Transaktions-Code und übermittelt (b3 TAN) diesen Code an den Kreditkartenprovider. Der Kreditkartenprovider empfängt diese Information und sendet (b4 TAN) sie seinerseits an den Endkunden, den Käufer C weiter. Der Endkunde C verwendet diesen weitergereichten Zeichensatz an Stelle der herkömmlichen Kreditkartennummer für den Bezahlvorgang auf der Web-Seite des Verkäufers M. Dazu übermittelt (b5 TAN) er den Transaktions-Code an den
Verkäufer M. Die Rechnungslegung des Verkäufers M an das Kreditkartenunternehmen, Credit Card Company, erfolgt wieder auf herkömmliche Weise, nur mit dem Unterschied, dass statt der üblichen Kreditkartennummer nun der Transaktions-Code samt der Rechnung übermittelt wird (bβ Bill + TAN) . Durch den Transaktions-Code kann das Kreditkartenunternehmen den Kreditkartenprovider ermitteln. Die Rechnungslegung des Kreditkartenunternehmens an den Kreditkarten Provider kann dann wiederum in bekannter Weise erfolgen (b7 Bill + TAN) . Hierbei wird der Transaktions-Code für die Zuordnung des Endkunden beim Kreditkarten Provider herangezogen. Eine andere Möglichkeit besteht durch eine B2B, das heißt eine Business to Business Schnittstelle. In einem letzten Schritt ermittelt der Kreditkarten-Provider über den Transaktions- Code den Endkunden. Die Rechnungslegung erfolgt vom
Kreditkarten Provider an den Endkunden genau in derselben Weise wie sie zwischen einem Kreditkartenunternehmen und einem Endkunden erfolgt ( (b8 Bill (+TAN) ) .
Der Käufer kann vom Kreditkarten-Provider im voraus auch mehrere TANs anfordern. Dies hat den Vorteil, dass nicht für jeden Kauf eine TAN Request an den CCP ausgesendet werden muss . Selbstverständlich kann der Credit Card Provider CCP auch mehrere TANs im voraus vom Kreditkartenunternehmen anfordern. Auch hier ist von Vorteil, dass nicht bei jeder TAN- Anforderung des Käufers eine Verbindung für eine einzelne TAN Anforderung zum Kreditkartenunternehmen aufgebaut werden muss .

Claims

Patentansprüche
1. Verfahren zur Abwicklung eines Zahlungsvorganges im elektronischen Handel in einem Kommunikationsnetz, insbesondere dem Internet, zwischen einem Käufer und einem Händler über einen Kreditkarten- Finanzdienstleister, dadurch gekennzeichnet, dass der Kreditkarten-Finanzdienstleister auf Anforderung des Käufers zumindest einen Transaktions-Code erzeugt und an den Käufer übermittelt und der Käufer diesen zumindest einen Transaktions-Code gegenüber dem Händler an Stelle einer Kreditkartennummer verwendet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Kreditkarten-Finanzdienstleister eine Kreditkartenfirma ist.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Kreditkarten-Finanzdienstleister ein Kreditkarten- Provider ist.
4. Verfahren nach Anspruch 2 oder nach 3, dadurch gekennzeichnet, dass der Kreditkarten- Finanzdienstleister den Transaktions-Code nur innerhalb eines vorgebbaren Zeitintervalls für die Abwicklung des Zahlungsvorganges als gültig anerkennt.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Zeitintervall mit der Anforderung des Käufers beginnt und nach Ablauf einer Sitzungszeit zwischen dem Kreditkarten-Finanzdienstleister und dem Käufer endet.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass der Kreditkarten- Finanzdienstleister das Zeitintervall auf kleiner als eine Stunde begrenzt.
7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Kreditkarten- Finanzdienstleister den Transaktions-Code an den Käufer über ein kryptographisches Protokoll übermittelt.
8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Übermittlung des Transaktions- Codes verschlüsselt und die Authentifizierung des Käufers durch eine digitale Signatur oder durch Eingabe von Benutzernamen und Kennwort erfolgt.
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Kreditkarten- Finanzdienstleister ein Internet Service Provider ist.
10. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Transaktions-Code aus einer Folge von Ziffern besteht.
PCT/EP2003/008516 2002-09-13 2003-08-01 Verfahren zur abwicklung eines zahlungsvorganges im elektronischen handel WO2004034343A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/242,660 US20040054624A1 (en) 2002-09-13 2002-09-13 Procedure for the completion of an electronic payment
US10/242,660 2002-09-13

Publications (2)

Publication Number Publication Date
WO2004034343A2 true WO2004034343A2 (de) 2004-04-22
WO2004034343A3 WO2004034343A3 (de) 2004-08-12

Family

ID=31991459

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/008516 WO2004034343A2 (de) 2002-09-13 2003-08-01 Verfahren zur abwicklung eines zahlungsvorganges im elektronischen handel

Country Status (2)

Country Link
US (1) US20040054624A1 (de)
WO (1) WO2004034343A2 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7493284B2 (en) * 2002-12-19 2009-02-17 International Business Machines Corporation Using visual images transferred from wireless computing device display screens
US20040122768A1 (en) * 2002-12-19 2004-06-24 International Business Machines Corporation Electronic wallet for wireless computing device
EP1828866A1 (de) * 2004-11-15 2007-09-05 Runtime AB Vorrichtung und verfahren für eine sichere kreditkarten-bearbeitungsinfrastruktur
EP1703479A1 (de) * 2005-03-18 2006-09-20 Hewlett-Packard Development Company, L.P. Computersystem und Benutzervorrichtung
WO2006125266A2 (en) * 2005-05-26 2006-11-30 Shane Eric John Prince A payment system
WO2007032657A1 (en) * 2005-09-16 2007-03-22 Juris Retenais Payment card security system and payment method using anonymous payment cards
EA011546B1 (ru) * 2005-11-11 2009-04-28 Михайло Комиссарук Система и способ осуществления безналичных платежей
EP1821249A1 (de) 2006-02-14 2007-08-22 Lufthansa AirPlus Servicekarten GmbH Verfahren zur Verbindung von Kartenzahlungsnetzen
FR2898711A1 (fr) * 2006-03-20 2007-09-21 Stephane Givin Systeme de securisation d'operations bancaires, financieres ou autres avec identification precise du client suivi du parametrage des operations et des codes secrets d'operations obtenus
HUP0600652A2 (en) * 2006-08-16 2008-04-28 Debitcode Kft Method and system for electronic financial transactions
CZ2007504A3 (cs) * 2007-07-26 2008-07-02 Direct Pay, S.R.O. Zpusob provádení platební transakce s využitím mobilního terminálu
US20100125510A1 (en) * 2008-11-17 2010-05-20 Smith Steven M System and method of conducting transactions using a mobile wallet system
WO2011063024A2 (en) * 2009-11-18 2011-05-26 Magid Joseph Mina Anonymous transaction payment systems and methods
WO2012012545A1 (en) * 2010-07-20 2012-01-26 Wi-Mexx International Limited System and methods for transferring money
US20120253989A1 (en) * 2011-03-30 2012-10-04 CPS Holdings, LLC System and method for payment by virtual credit card
EP2698737A4 (de) 2011-04-12 2014-09-24 Panasonic Corp Authentifizierungssystem, system zum registrieren von informationen, server, programm und authentifizierungsverfahren dafür
JP5950691B2 (ja) 2012-02-09 2016-07-13 シャープ株式会社 情報処理システム、情報処理装置、及び通信接続方法
WO2016070295A1 (es) * 2014-11-06 2016-05-12 Toc S.A. Método de autenticación de dos factores para aumentar la seguridad de las transacciones entre un usuario y un punto o sistema de transacción
CN106529952B (zh) * 2015-09-09 2021-09-17 腾讯科技（深圳）有限公司 数据转移中的验证实现方法及系统
US10861002B2 (en) * 2016-05-27 2020-12-08 Afero, Inc. Internet of things (IoT) credit card tracking system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
GB2352861A (en) * 1999-08-04 2001-02-07 Int Computers Ltd Payment transaction system
GB2361790A (en) * 2000-04-28 2001-10-31 Cast Technologies Ltd Making secure payments using a limited use credit card number
CA2309013A1 (en) * 2000-05-23 2001-11-23 Twingate System Inc. Secure online transaction method

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
GB2352861A (en) * 1999-08-04 2001-02-07 Int Computers Ltd Payment transaction system
GB2361790A (en) * 2000-04-28 2001-10-31 Cast Technologies Ltd Making secure payments using a limited use credit card number
CA2309013A1 (en) * 2000-05-23 2001-11-23 Twingate System Inc. Secure online transaction method

Also Published As

Publication number Publication date
US20040054624A1 (en) 2004-03-18
WO2004034343A3 (de) 2004-08-12

Similar Documents

Publication Publication Date Title
WO2004034343A2 (de) Verfahren zur abwicklung eines zahlungsvorganges im elektronischen handel
DE60124893T2 (de) Sicherheitsmodul für ein Kontenverwaltungssystem
US7941370B2 (en) Systems and methods for funding payback requests for financial transactions
US8442880B1 (en) Systems, methods and computer readable medium providing automated third-party confirmations
DE212010000059U1 (de) Veränderbarer Sicherheitswert
WO2018051847A1 (ja) 仮想通貨アドレスを含む預金口座情報開示システム
JP2005517252A (ja) 認証局が発行したデジタル証明書の保持者の権限を検証するための方法およびシステム
EP2776999A1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
WO2010089049A1 (de) Mobiles zahlungsverfahren und vorrichtungen
WO2013011043A1 (de) Mobiles system für finanztransaktionen
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
DE60122912T2 (de) Verfahren zum liefern von identifikationsdaten einer bezahlkarte an einen anwender
EP0907134A1 (de) Verfahren zur rechnergestützten Zahlungsabwicklung über Zahlungssysteme
EP1437668B1 (de) Verfahren zur bargeldlosen Zahlung von Waren oder Dienstleistungen unter Verwendung eines Mobilfunkendgerätes
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
DE102019006333A1 (de) Gerät zum Erzeugen und Verwenden einer Schnittstelle zwischen Realwelt-Transaktionen und virtuellen Kontrakten
EP1047028A1 (de) Kommunikationssytem und Verfahren zur effizienten Durchführung von elektronischen Transaktionen in mobilen Kommunikationsnetzen
DE10229619A1 (de) Verfahren zur Durchführung eines Zahlungsvorganges
DE10218729B4 (de) Verfahren zum Authentifizieren und/oder Autorisieren von Personen
DE102005044953A1 (de) Tragbare Verschlüsselungsvorrichtung für Finanz-Transferaktionen und Verfahren unter deren Verwendung
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
EP3283999A1 (de) Elektronisches system zur erzeugung eines zertifikats
WO2016045788A1 (de) Transaktionsverfahren
DE10207932A1 (de) Datenverarbeitungssystem und Verfahren zur elektronischen Zahlungsvermittlung
Ballen et al. Electronic Banking Products and Services: The New Legal Issues

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CN

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase