DE20220745U1

DE20220745U1 - Sicheres Online-Zahlungssystem

Info

Publication number: DE20220745U1
Application number: DE20220745U
Authority: DE
Original assignee: EUROP TAX FREE SHOPPING Ltd GA; European Tax Free Shopping Ltd
Current assignee: EUROP TAX FREE SHOPPING Ltd GA; European Tax Free Shopping Ltd
Priority date: 2001-06-01
Filing date: 2002-06-04
Publication date: 2004-03-04
Anticipated expiration: 2012-06-05
Also published as: CA2462398C; CN1556972A; EA200301199A1; EA005835B1; MXPA03011016A; BG66353B1; HUP0500520A2; IES20020450A2; ZA200300887B; HU227081B1; IS7053A; CN101630390A; IES20010524A2; TR200302226T1; US8219488B2; EP1430455A2; BR0205535A; KR20030019646A; WO2002097752A3; WO2002097752A2

Abstract

Online-Zahlungssystem mit einer Verbindung zum Internet und einer weiteren Verbindung über ein lokales Netzwerk zum Anschluss eines Karteninhabers, umfassend:
eine Empfangseinrichtung zum Empfangen einer Verbindungsanforderung von einem Karteninhaber, wobei die Anforderung ein Passwort des Karteninhabers einschließt,
eine Authentifizierungseinrichtung zur Authentifizierung der Anforderung des Karteninhabers und zum Ermöglichen des Zugangs für den Karteninhaber in das Netzwerk,
eine Empfangseinrichtung zum Empfangen einer ersten Transaktionsanforderung, die einer Transaktion zwischen einem Händler und dem Karteninhaber zugeordnet ist,
eine Abrufeinrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einer Datenbank,
eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die Zahlkartendetails, wobei die Authorisierungsanforderung einen System-Händlercode und einen Transaktionswert einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion, und
eine Transaktionseinrichtung, die auf den Empfang einer Authorisierung von dem Authorisierungshost reagiert und geeignet ist, dem Händler eine Transaktionsanforderung zu übermitteln, wobei die Anforderung einen Mastercode für das Konto des Karteninhabers einschließt.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft das Gebiet des e-Handels und insbesondere das Durchführen von Online-Käufen unter Verwendung von Zahlkarten, zum Beispiel Debit-, Belastungs- oder Kreditkarten.
Hintergrund der Erfindung
Es wurden beträchtliche Forschungen und Ressourcen für die Entwicklung, Implementierung und Aufrechterhaltung von sicheren Zahlungssystemen eingesetzt, die die Verwendung von Kredit-/Belastungskarten durch Karteninhaber in Handelstransaktionen, die über das Internet abgewickelt werden, erleichtern.
All diese sicheren Systeme basieren darauf, dass Karteninhaber ihre Kartennummer jedes mal "verarbeiten" lassen müssen, was Hackern und/oder anderen Betrügern die Möglichkeit gibt, Kartennummern und zugehörige Informationen, die zum Zeitpunkt des Kaufs übertragen werden, abzufangen, so dass diese dann Zugang zu Kartennummern und Ablaufdaten erlangen können.
Eine Lösung besteht darin, sichere (verschlüsselte) Verfahren der Kommunikation zu verwenden, wenn einem Händler beim Kauf über das Internet Kreditkartendetails geschickt werden. Beispiele für derartige sichere Verfahren schließen das Secure Socket Layer (SSL) und das Secure Electronic (SET) Protokoll ein. Diese Verfahren wurden speziell für den Zweck der Durchführung einer elektronischen Übertragung von Kreditkartendetails über das Internet von führenden Computerfirmen und -geschäften der Kreditkartenindustrie entwickelt. Es gibt jedoch keine Garantie, dass die Kredit-/Belastungskartendetails bei der einigermaßen sicheren Übertragung nicht für Angriffe anfällig sind, wenn sie auf dem System des Händlers gespeichert sind. Es besteht sehr wohl die Möglichkeit, dass auf die Kartendetails unberechtigt zugegriffen werden könnte oder diese von einem Händler oder einem Angestellten des Händlers für Betrugszwecke verwendet werden könnten.
Ein weiteres Bedenken gegen den Online-Handel, wie es von den Karteninhabern empfunden wird, ist die Verlässlichkeit der e-Händler und die fehlende Regressmöglichkeit der Karteninhaber, die einen Kauf getätigt haben. Der Karteninhaber hat keine Garantie, dass bestellte Posten pünktlich und in angemessener Qualität und/oder Menge usw. geliefert werden. Es kann für einen Karteninhaber schwierig sein, wenn einmal die Kartendetails übermittelt wurden und das Konto des Karteninhabers mit der entsprechenden Summe belastet wurde, von dem Händler angemessen zufriedengestellt zu werden.
Ein weiteres Bedenken besteht darin, dass es keine Garantie gibt, dass ein Händler oder sein Personal, die Zugriff auf die Details des Karteninhabers haben können, nicht die Kartendetails des Karteninhabers in anschließenden nicht befugten Transaktionen benutzen oder die Informationen für kriminelle Zwecke an Dritte weitergeben.
Andererseits bestehen wesentliche Bedenken der Händler darin, dass Posten vor dem Versand definitiv bezahlt werden, d. h., dass die Kartendetails und der Betrag zur Begleichung durch den Käufer, der über das Kartensystem zahlt, gebilligt wurden und dass die Informationen der Kartendetails und des Karteninhabers stimmen.
Die EP 0801479 offenbart einen sicheren Kommunikationsmechanismus zum Übertragen von Kreditkarten- oder anderen vertraulichen Informationen zwischen dem Anschluss eines Karteninhabers und einem Server, die über ein Datennetzwerk (z.B. Internet) kommunizieren. Für eine sichere oder private Übertragung von vertraulichen Informationen über ein Datennetzwerk wird eine Telefonverbindung zwischen dem Server des Ursprungs-Internet Service Providers (ISP), mit dem der Karteninhaber verbunden ist, um auf das Datennetzwerk zuzugreifen, und dem Serverprovider, an den die vertraulichen Informationen geleitet werden, hergestellt. Alle Kommunikationen oder Transaktionen zu einem ISP-Serveranschluss, die Informationen über Kreditkarten oder andere vertrauliche Informationen beinhalten, erfolgen jedoch über eine zweite Verbindung durch einen Telefonanruf, der an eine Telefonnummer des ISP- Serveranschlusses gerichtet ist. Nach Eingang eines Anrufs und durch Zuordnen eines derartigen Anrufs zu der Anforderung durch den Karteninhaber von Informationen und/oder interaktiven Dienstleistungen und/oder nicht elektronisch lieferbaren Waren oder Dienstleistungen, übergibt der ISP dem Karteninhaber die erbetene Information und/oder Dienstleistung, oder er billigt die Lieferung der nicht elektronisch lieferbaren Waren oder Dienstleistungen. Bei dieser Anordnung erfolgt die Zahlung ohne das Übergeben von Kreditkarten-Informationen über die Leitserver im Internet und ohne Herstellen einer finanziellen Beziehung mit dem ISP. Vorzugsweise unterliegt die Übertragung von Informationen über die Telefonleitung zwischen dem Ursprungsserver und dem ISP-Serveranschluss auch einer Verschlüsselung. Das Problem bei diesem Ansatz besteht darin, dass es für die ISPs und die Händler wesentlich ist, das Konzept und die Installation zusätzlicher Kommunikationsausrüstung zu beantragen, um die sichere Kommunikation auf dem sekundären Kanal zu erleichtern. Des Weiteren kommen durch die Notwendigkeit eines separaten Telefonanrufs zusätzliche Kosten zu dem Verfahren hinzu und es gibt für den Karteninhaber immer noch keine Garantie.
Die WO97/03410 offenbart ein Verfahren zur Rechnungsstellung über das Internet, aufweisend das Schließen eines Vertrags zwischen einem Internet-Zugangsprovider und einem Kunden und eines Vertrags zwischen dem Internet-Zugangsprovider und einem Verkäufer, wobei der Internet-Zugangsprovider mit dem Kunden und dem Verkäufer vereinbart, dem Kunden die Rechnung zu stellen und dem Verkäufer das Geld für Produkte und Dienstleistungen zu überweisen, die durch den Kunden vom Verkäufer über das Internet erworben wurden. Der Provider ermöglicht dem Kunden Zugang zum Internet. Wenn der Kunde von einem Verkäufer ein Produkt oder eine Dienstleistung über das Internet bestellt, werden Informationen zur Transaktion, die zwischen dem Kunden und dem Verkäufer übermittelt werden, auch dem Provider übermittelt. Der Provider stellt dann dem Kunden den Transaktionsbetrag in Rechnung und überweist einen Teil des Transaktionsbetrags an den Verkäufer und behält den Differenzbetrag als eine Gebühr für das zur Verfügung stellen der Dienstleistung. Aus diesem Verfahren ergibt sich, dass keine Kundenkontonummern oder Verkäuferkontonummern über das Internet übertragen werden müssen, wodurch die Sicherheit dieser Informationen erhalten bleibt. Eine erhebliche Schwierigkeit bei diesem Ansatz besteht darin, dass Verträge zwischen den ISPs und den Händlern erforderlich sind, bevor Transaktionen stattfinden können.
Die US5,905,736 offenbart ein Verfahren zur zentralisierten Rechnungsstellung für Transaktionen, die über das Internet zwischen einem Karteninhaber und einem Internet Service Provider durch einen Internet-Zugangsprovider (IAP) abgewickelt werden. Nach der Verbindung des Anschlusses des Karteninhabers mit dem IAP überträgt der IAP eine Nachricht an eine Rechnungsstellungsplattform, die die Identität des Karteninhabers und die temporäre Internet Protocol (IP) Adresse zuordnet, welche der Sitzung des Karteninhabers zur Verwendung vom Anschluss des Karteninhabers vom IAP zugewiesen wird. Als Antwort auf eine zu berechnende Transaktion mit einem ISP überträgt der ISP die IP-Adresse des Karteninhabers, der die Transaktion abwickelt, und die Gebühr für die Transaktion an die Rechnungsstellungsplattform. Die Gebühren für alle derartigen Transaktionen werden von einem Transaktionsserver gesammelt und auf einem Konto in einer zugeordneten Datenbank gespeichert, die durch die IP-Adresse des anfordernden Anschlusses identifiziert ist. Am Ende der Sitzung des Karteninhabers werden die Gebühren für alle Transaktionen während der Sitzung, die auf der Transaktionsserverdatenbank auf dem durch die IP-Adresse identifizierten Konto gespeichert sind, einem Konto belastet, das der Identität des Karteninhabers zugeordnet ist, die in einer Datenbank eines Rechnungsstellungsservers gespeichert ist, was durch Querverweisen der IP-Adresse zur Identität des Karteninhabers von der zuvor erhaltenen und gespeicherten Nachricht geschieht.
Angesichts des Stands der Technik wäre es vorteilhaft, wenn ein Verfahren zum Online-Kauf von Waren zur Verfügung gestellt werden könnte, welches dem Karteninhaber einen einfachen und wirksamen Rückgriff auf den e-Händler ermöglichen würde, falls es zu einer Reklamation kommt.
Es wäre ferner wünschenswert, wenn ein Verfahren zur Verfügung gestellt werden könnte, welches es dem Verbraucher ermöglichen würde, einen Online-Kauf zu tätigen, ohne einem Dritten seine Kartendetails zu offenbaren.
Zusammenfassung der Erfindung
Das Konzept der vorliegenden Erfindung übernimmt einen alternativen Ansatz bei Sicherheitsverfahren, die derzeit verwendet werden, um Karteninhaber zu schützen. Das Konzept vermeidet die Notwendigkeit, dass der Karteninhaber zum Zeitpunkt des Erwerbs zusammen mit anderen Kaufdetails Kartennummern übermitteln muss und verbindet dies mit der Verwendung einer Passwortfunktion. Dadurch ähnelt die Transaktion einer Barabhebung bei der Bank, womit Banken und Kartensysteme bezüglich der Sicherheit vollkommen zufrieden sind, sie verweigern jedoch dem e-Handel und/oder Anderen Zugriff auf ihr "Netzwerk", um die Sicherheit zu gewährleisten.
In einer Ausführungsform wird ein System zum Verarbeiten einer Online-Zahlungstransaktion zur Verfügung gestellt, wobei das System eine Verbindung mit dem Internet und eine weitere Verbindung über ein lokales Netzwerk mit dem Anschluss eines Karteninhabers hat, aufweisend:

eine Empfangseinrichtung zum Empfangen einer Anforderung von einem Karteninhaber, ihn mit einem Netzwerk zu verbinden, wobei die Anforderung ein Passwort des Karteninhabers umfasst,
eine Authentifizierungseinrichtung zum Authentifizieren der Karteninhaberanforderung und zum Ermöglichen des Zugangs für den Karteninhaber in das Netzwerk,
eine Empfangseinrichtung zum Empfangen einer ersten Transaktionsanforderung, die einer Transaktion zwischen einem Händler und dem Karteninhaber zugeordnet ist,
eine Abrufeinrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einer Datenbank, eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die Zahlkartendetails, wobei die Authorisierungsanforderung einen System-Händlercode und einen Transaktionswert einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion,
und eine Transaktionseinrichtung, die auf den Empfang einer Authorisierung von dem Authorisierungshost reagiert und geeignet ist, dem Händler eine Transaktionsanforderung zu übermitteln, wobei die Anforderung einen System-Karteninhaberkontocode umfasst.

In dieser Ausführungsform kann das System ferner eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler aufweisen. Das System kann eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion einschließen. In diesem Fall verzögert die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung, bis eine Lieferbestätigung erhalten wurde.
Gegebenenfalls kann das System eine Verifizierungseinrichtung einschließen, die geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die Karteninhaberinformationen, die einem Händler zur Verfügung gestellt wurden, mit den Karteninhaberinformationen, die in der Datenbank gespeichert sind, übereinstimmen.
In einer weiteren Ausführungsform ist ein Zahlungsverarbeitungssystem zum Verarbeiten einer Online-Zahlungstransaktion zwischen einem Händler und einem Karteninhaber zur Verfügung gestellt, aufweisend:

eine Einrichtung zum Empfangen einer Zahlungstransaktionsanforderung, wobei die Zahlungsanforderung die Händlerinformationen identifiziert, einschließlich eines Händlercodekennzeichens und eines Transaktionswerts, eine Zuordnungseinrichtung zum Zuordnen eines Karteninhabers zu der erhaltenen Zahlungsanforderung, eine Einrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einem Datenspeicher von Karteninhaberkartendetails,
eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die abgerufenen Zahlkartendetails, wobei die Zahlungsauthorisierungsanforderung die abgerufenen Zahlkartendetails, den Händlercode der Zahlungsanforderung und den Transaktionswert der Zahlungsanforderung einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion, eine Bestätigungseinrichtung, die geeignet ist, eine Bestätigung einer als Antwort auf eine übermittelte Zahlungsauthorisierungsanforderung erhaltene Authorisierung zu übermitteln.

In dieser Ausführungsform kann das System ferner eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler aufweisen. Das System kann eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion einschließen. In diesem Fall verzögert die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung, bis eine Lieferbestätigung erhalten wurde.
Gegebenenfalls kann das System eine Verifizierungseinrichtung einschließen, die geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die Karteninhaberinformationen, die einem Händler zur Verfügung gestellt wurden, mit den Karteninhaberinformationen, die in der Datenbank gespeichert sind, übereinstimmen.
In noch einer weiteren Ausführungsform ist ein Zahlungsverarbeitungssystem zum Verarbeiten einer Online-Zahlungstransaktion zwischen einem Händler und einem Karteninhaber zur Verfügung gestellt, aufweisend:

seine Einrichtung zum Empfangen einer Zahlungstransaktionsanforderung, wobei die Zahlungsanforderung die Händlerinformationen identifiziert, einschließend ein Händlercodekennzeichen und einen Transaktionswert, eine Zuordnungseinrichtung zum Zuordnen eines Karteninhabers zu der erhaltenen Zahlungsanforderung, eine Einrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einem Datenspeicher von Karteninhaberkartendetails,
eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die abgerufenen Zahlkartendetails, wobei die Zahlungsauthorisierungsanforderung die abgerufenen Zahlkartendetails, einen System-Händlercode und den Transaktionswert der Zahlungsanforderung einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion,
eine Antworteinrichtung, die auf den Empfang einer Authorisierung reagiert und geeignet ist, dem Händler eine Transaktionsanforderung zu übermitteln, wobei die Anforderung einen System-Karteninhaberkontencode einschließt.

In dieser Ausführungsform kann das System ferner eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler aufweisen. Das System kann eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion einschließen. In diesem Fall verzögert die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung, bis eine Lieferbestätigung erhalten wurde.
Gegebenenfalls kann das System eine Verifizierungseinrichtung einschließen, die geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die Karteninhaberinformationen, die einem Händler zur Verfügung gestellt wurden, mit den Karteninhaberinformationen, die in der Datenbank gespeichert sind, übereinstimmen.
In einer Ausführungsform werden der erste Informationssatz, der einen Karteninhaber identifiziert, und der zweite Informationssatz, der den Händler identifiziert, unter Verwendung eines Internetübertragungsprotokolls, zum Beispiel der POST-Aktion im Zusammenhang mit HTML-Formularen, erhalten.
Diese und andere Ausführungsformen der Erfindung werden durch Verweis auf die im Folgenden beschriebene(n) Ausführungsformen) offensichtlich und werden durch diese erklärt.
Kurze Beschreibung der Zeichnungen
Die Erfindung wird nun genauer nur beispielhaft anhand der beigefügten Zeichnungen beschrieben. Es zeigen:
1 eine bildliche Darstellung der Anordnung eines Zahlungstransaktionssystems gemäß der Erfindung,
2 eine genauere Darstellung der Anordnung aus 1,
3 ein Schema einer beispielhaften Datenbank zur Verwendung der vorliegenden Erfindung,
4 ein Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform der Erfindung,
5 eine Darstellung eines Formulars zur Verwendung mit der vorliegenden Erfindung, und
6 ein Flussdiagramm eines Verfahrens gemäß einer zweiten Ausführungsform der Erfindung.
Genaue Beschreibung der Zeichnungen
Eine Anordnung des Online-Transaktionssystems gemäß der Erfindung, die in 1 gezeigt ist, umfasst eine Anzahl von verschiedenen Parteien an verschiedenen Knoten in einem Netzwerk. Insbesondere befasst sich das Verfahren mit einer Online (e-Handel)-Transaktion zwischen einem Karteninhaber 4 einer Zahlkarte (typischerweise einer Debit-, Kredit- oder Belastungskarte) und einem Händler 2.
Die Kommunikation zwischen dem Händler und dem Karteninhaber erfolgt über ein Netzwerk 3 (das Internet). Der Händler, oder genauer der Server 2 des Händlers, ist normalerweise ständig mit dem Netzwerk verbunden, um Verbrauchern einen ungehinderten Zugang zur Website des Händlers zu gewähren.
Der Computer des Karteninhabers kann andererseits so konfiguriert sein, dass er sich nur nach Bedarf mit dem Internet 3 verbindet. Typischerweise wird der Computer des Karteninhabers über einen Internet Service Provider (ISP) 5 mit dem Internet 3 verbunden. Die Verbindung mit dem ISP kann unter Verwendung eines Modems über eine herkömmliche oder eine ISDN-Telefonleitung oder durch andere geeignete Kommunikationsmittel erfolgen.
Nach Herstellung der Verbindung mit dem ISP 5 kann es erforderlich sein, dass der Karteninhaber einen Karteninhabernamen und/oder ein Karteninhaberpasswort eingibt. Eine Authentifizierungseinrichtung, zum Beispiel ein Sicherheitssoftwaremodul, führt ein Verifizierungsverfahren durch, das typischennreise den eingegebenen Namen und das eingegebene Passwort des Karteninhabers mit einer Karteninhaber-Sicherheitsdatenbank von gültigen Karteninhabernamen und Passwörtern vergleicht, die lokal auf dem ISP-Server oder einem zugeordneten Server oder Netzwerk des ISP-Servers gespeichert sind. Nach der Verifizierung des Namens und Passworts des Karteninhabers wird dem Computer des Karteninhabers durch das ISP-Netzwerk Zugang zum Internet gewährt.
Typischerweise können die ISP-Server 5 unter Verwendung von Routern und anderen zugeordneten Hardware-Vorrichtungen mit dem Internet 3 verbunden werden. Die Sicherheit und der Schutz für den ISP-Server und das zugeordnete lokale Netzwerk können durch Firewall-Vorrichtungen oder -Software zur Verfügung gestellt werden. Diese Kombination der Router-Technologie und Sicherheitsmerkmalen ermöglicht es den ISPs, Dienstleistungen auf den ISP-Servern verfügbar zu machen, die den Karteninhabern, die durch den ISP verbunden sind, direkt zugänglich gemacht werden können, ohne dass die Übertragung von Karteninhaberanforderungen und Serverantworten über das Internet notwendig sind. Auf diese Weise können Kommunikationen zwischen einem Server in dem ISP-Netzwerk und dem Computer eines Karteninhabers, der durch das ISP-Netzwerk mit dem Internet verbunden ist, im Allgemeinen nicht durch Dritte im Internet abgefangen werden.
Eine beispielhafte Struktur für ein ISP-System, um dem Karteninhaber Zugang in das Internet zu gewähren, und ein zugeordnetes Zahlungs-/Validierungs-Verarbeitungssystem zum Verarbeiten einer Online-Transaktion zwischen dem Karteninhaber und einem Händler nach einer Ausführungsform der Erfindung ist in 2 veranschaulicht. Das zugeordnete Zahlungsverarbeitungssystem kann innerhalb des ISP integriert sein oder in einem separaten System in Zuordnung zu dem ISP gehalten werden. In dieser beispielhaften Struktur wird die Karteninhaber-Datenbank 100, 101 des oben beschriebenen ISP erweitert, so dass sie weitere Karteninhaberinformationen enthält, wie in der beispielhaften Datenbank-Struktur aus 3 veranschaulicht ist, die die Namen 12, Adressen 13 und Zahlkartendetails von Karteninhabern 14, 15, 16 einschließen kann. Die Zahlkarten-Schlüsseldetails können typischerweise Details des Kartenzahlungssystems 14 (z. B. VISA^TM, AMERICAN EXPRESS^TM, DINERS CLUB^TM, MASTER CARD^TM, usw.), die Kartennummer 15 und das Ablaufdatum 16 der einzelnen Karteninhaber einschließen.
Diese Schlüssel-Zahlkartendetails könnten erstellt werden, wenn der Karteninhaber sein Konto bei dem ISP einrichtet, oder irgendwann anschließend, wenn es für den Karteninhaber und den ISP günstig ist. Aus Sicherheitsgründen wird vorgeschlagen, dass die Schlüsseldetails vom Karteninhaber in einem schriftlichen Antrag an den ISP übergeben werden. In einer anderen Ausführungsform können diese Schlüsseldetails durch einen Telefonanruf beim ISP mitgeteilt werden. Die Verwendung eines dieser Verfahren würde gewährleisten, dass die Schlüsseldetails eines Karteninhabers nicht über das Internet übertragen werden. Eine weniger bevorzugte Ausführungsform würde es einem Karteninhaber ermöglichen, seine Schlüsseldetails online einzugeben.
Es ist selbstverständlich, dass die Datenbank-Struktur unter Verwendung von einer oder mehreren Tabellen 100, 101 in eine relationale Datenbank implementiert werden kann. Jedes Karteninhaberkonto kann mehr als einen zugeordneten Satz von Schlüsselkartendetails haben, d. h. wenn ein Karteninhaber mehr als eine Kreditkarte hat. In diesem Fall ist es für die Fachleute selbstverständlich, dass eine Datenbank mit mehreren Tabellen geeignet wäre, die eine erste Tabelle hat, die die Karteninhaber und ihre Passwörter identifiziert, wobei eine zweite Tabelle verwendet wird, die die Karteninhaberdetails enthält. Es könnte ein zusätzliches Feld verwendet werden, um die Tabellen zu verknüpfen, z. B. eine Karteninhabernummer, die zum Zeitpunkt des Eintrags des Karteninhabers in die Datenbank kreiert wird und für jeden Karteninhaber einmalig ist. Es ist ferner selbstverständlich, dass die gesamten Karteninhaber-Kartendetails 101 in einem separaten System in dem Karteninhaber-Sicherheitsdatenspeicher 100 gespeichert werden kann, insbesondere, wenn das Transaktionsverarbeitungssystem von dem ISP getrennt ist.
Im Allgemeinen beginnen die Verfahren der Erfindung damit, dass ein Karteninhaber über einen ISP eine Verbindung mit dem Internet herstellt 20, einschließend die herkömmlichen Schritte der Karteninhaber-Verifizierung (Authentifizierung) 21. Zum Zeitpunkt der Verbindung kann der ISP dem Karteninhaber die Verbindungs-ID (z. B. die zugeordnete IP-Nummer) des Computers des Karteninhabers zuordnen. Diese kann anschließend von dem ISP verwendet werden, um den Karteninhaber in einer Transaktion zu identifizieren. Sobald ein Karteninhaber über den ISP eine Verbindung mit dem Internet hergestellt hat 22, kann der Karteninhaber eine geeignete Browsersoftware, z. B. NETSCAPE NAVIGATOR oder MICROSOFT INTERNET EXPLORER, verwenden, um sich im Internet zu bewegen und die Webseiten des Händlers zu durchsuchen.
Eine erste Wirkungsweise der Erfindung ist in 4 gezeigt. In dieser Ausführungsform hat der Händler direkt oder indirekt einen Vertrag mit dem ISP abgeschlossen, der im Zusammenhang mit der vorliegenden Erfindung so aussehen sollte, dass ein ISP mit einem zugeordneten Zahlungsprozessor das Transaktionssystem der vorliegenden Erfindung verwendet.
Es beginnt damit, dass ein Karteninhaber auf die Website eines Händlers zugreift. Der Karteninhaber kann, je nach Konfiguration der Website des Händlers, Beschreibungen von Waren oder Dienstleistungen, die zum Verkauf stehen, ansehen, Bilder von diesen Waren oder Dienstleistungen ansehen und Posten zum Kaufen auswählen 23.
Techniken für die Implementierung dieser Möglichkeiten auf einem Website-Server sind in der Technik bekannt.
Nach Erhalt einer Anforderung vom Karteninhaber, einen Posten zu kaufen, kann der Server des Händlers antworten, indem er ein Formular verschickt, das von dem Karteninhaber ausgefüllt werden muss. Das Formular kann ein Hyper Text Mark-Up Language (HTML)-Dokument sein, das ein kleines JAVASCRIPT-Programm beinhaltet, um sicher zu gehen, dass die erforderlichen Felder angemessen ausgefüllt werden, obwohl auch jedes von einem Browser lesbare Formular verwendet werden kann.
HTML-Formulare sind in der Technik bekannt und ermöglichen das Einbeziehen einer Anzahl von Feldern, die der Browser-Software anzeigen, welche Aktion mit dem Formular durchgeführt werden muss, wie und wohin die von einem Karteninhaber in einem Formular eingegeben Informationen geschickt werden sollen.
Ein Beispielformular 40 ist in 5 gezeigt. Das Formular ermöglicht es dem Karteninhaber, unter Verwendung seiner Browser-Software einige Informationen einzugeben, z. B. seinen Namen 44a, Adresse 44b und Telefonnummer 44c.
Das Formular 40 kann auch Informationen enthalten, die die Transaktion genau wiedergeben, einschließend zum Beispiel eine Beschreibung der Waren 43b, die Mengen 43c, Preise 43d und eine Referenznummer 43a des Händlers für die Transaktion. All diese Informationen können als Felder in dem Formular gespeichert werden. Bestimmte Felder können als versteckt gekennzeichnet sein, z. B. die Referenznummer des Händlers für die Transaktion.
Sobald der Karteninhaber das Formular 24 ausgefüllt und die entsprechende Schaltfläche 41 angeklickt hat, wird das Formular 40 durch die Browser-Software an einen Ort geschickt, der im Formular selber definiert ist. Ein geeignetes Skript, das in dem HTML-Dokument eingebettet ist, kann die Gültigkeit der ausgefüllten Felder und Werte überprüfen. Zum Beispiel kann ein Skript den Karteninhaber auffordern, seine Details erneut einzugeben, wenn das Namenfeld leer gelassen wurde.
Das Verfahren der Erfindung kann so konfiguriert werden, dass es auf viele verschiedene Weisen zu bedienen ist. In einer ersten Ausführungsform, in der das System des Händlers geeignet ist, mit dem Transaktionssystem des ISP zu kooperieren, stellt das System des Händlers dem ISP den Händlercode des Händlers für ein Kartensystem zur Verfügung.
Dies kann dadurch geschehen, dass der Händler eine Zahlungsoption für den Kauf 45 zur Verfügung stellt, die dem Service des ISP entspricht. Zum Beispiel kann der Karteninhaber in der Lage sein, das Zahlungssystem des ISP oder eines Partners aus einer Dropdown-Liste in einem Formular auszuwählen oder ein Optionsfeld zu verwenden.
In einer Ausführungsform, in der der Karteninhaber das Zahlungsverfahren auswählt, bevor er das oben beschriebene Formular ausfüllt, wird das oben beschriebene Formular nach Auswahl der Option, dass der Karteninhaber einen Kauf unter Verwendung der Kreditkartendetails des Karteninhabers, die auf seinem ISP oder einem Partner gespeichert sind, tätigen möchte, dem Karteninhaber vom Händler zum Ausfüllen zugeschickt: Das Formular enthält Felder, die versteckt sein können und die die Karteninformationen des Händlers identifizieren, z. B. den Händlercode des Händlers, ein Kennzeichen des Kartensystems.
Nach Ausfüllen des Formulars durch den Karteninhaber wird das Formular dem ISP-Server oder einem zugeordneten Server, der den Transaktionsprozessor 102 hostet, übermittelt 25. Der Transaktionsprozessor 102, der eine Empfangseinrichtung zum Empfangen des Formulars einschließt, extrahiert 26 Informationen aus dem Formular, einschließlich des Händlercodes des Händlers und des Betrags der Transaktion.
Der Transaktionsprozessor umfasst eine Zuordnungseinrichtung, die bestimmt, von welchem Karteninhaber das Formular übermittelt wurde, zum Beispiel unter Verwendung der IP-Adresse des Computers, von dem die Anforderung geschickt wurde, und ordnet die Transaktion diesem Karteninhaber zu.
Sobald der Transaktionsprozessor die Identität des Karteninhabers bestimmt hat, ruft der Transaktionsprozessor unter Verwendung einer geeigneten Abrufeinrichtung Kartendetails des Karteninhabers für den zugeordneten Karteninhaber von der Karteninhaber-Karteninformationsdatenbank ab 26. Der Transaktionsprozessor 102 (oder eine zugeordnete Authorisierungsvorrichtung) stellt dann (wenn dies nicht bereits geschehen ist) eine Verbindung mit einem Kartensystem-Authorisierungshost 7 her und übermittelt 27 die Zahlkartendetails, den Händlercode und den Transaktionswert zur Bestätigung. Die Verbindung mit dem Authorisierungshost kann zum Beispiel über ein eigenständiges Sicherheitsnetzwerk oder eine Telefonleitung erfolgen.
Falls der Authorisierungshost die Transaktion ablehnt, antwortet der Transaktionsprozessor, indem er eine entsprechende Nachricht an den Karteninhaber und/oder den Händler schickt und die Transaktion wird abgebrochen.
Wenn die Transaktion bestätigt wird, liefert der Authorisierungshost dem Transaktionsprozessor 102 eine Transaktionsauthorisierungsnummer gemäß der herkömmlichen Zahlungstransaktion. Der Transaktionsprozessor, der eine Bestätigungseinrichtung verwendet, übermittelt 28 dann eine Bestätigung der Authorisierung, zum Beispiel durch Eingeben des Authorisierungscodes als ein Feld, wobei die Formulardetails bereits von dem Karteninhaber ausgefüllt wurden, an den Server des Händlers.
Die Details der Transaktion einschließlich der Händlerinformationen, Karteninhaberinformationen und Transaktionsdetails können vom Transaktionsprozessor oder in einem Transaktionsdatenspeicher entweder lokal oder auf einem zugeordneten Server für die anschließende Verarbeitung 29 gespeichert werden (z. B. durch eine Postingeinrichtung des Transaktionsprozessors, der die Transaktionsinformationen an ein Kartenzahlungssystem sendet, um die Transaktion zu verarbeiten). Trotzdem kann dieser Schritt gleichzeitig mit der Authorisierung erfolgen.
Nach Erhalt einer Bestätigung, z. B. eines Authorisierungscodes, mit den Transaktionsdetails hat der Händler eine wirksame Garantie, dass die Transaktion gültig sein wird und dass der Händler vom Kartensystem zeitgerecht die Begleichung erhalten wird. Mit dieser Garantie kann der Händler die Transaktion bewilligen, zum Beispiel die Anforderung, mit der Lieferung von Waren oder Dienstleistungen fortzufahren.
Es ist selbstverständlich, dass die Kartenschlüsseldetails des Karteninhabers dem Händler in der gesamten Transaktion nicht offengelegt wurden.
In einer weiteren Ausführungsform speichert der Transaktionsprozessor die Details der Transaktion, behält jedoch die Transaktionen zum Posten bis zur Bestätigung der Verarbeitung eines Auftrags durch einen Händler oder des Erhalts der Waren durch einen Karteninhaber zurück. Zum Beispiel kann der Transaktionsprozessor die Transaktion bis zum Erhalt einer Nachricht vom Händler zurückhalten, die genaue Angaben zu einer Lieferdienstleistungsfirma und ihrem Transaktionsbericht der Lieferung macht. Nach Erhalt und gegebenenfalls einer Verifizierung einer derartigen Information würde der Transaktionsprozessor die Transaktion zur Verarbeitung durch das passende Kartensystem freigeben.
Es wird für die Fachleute offensichtlich sein, dass eine Anzahl von verschiedenen Verfahren und Techniken verwendet werden kann, um es dem Karteninhaber zu ermöglichen, die Informationen zu übermitteln, und um es dem Transaktionsprozessor zu ermöglichen, die Details des Kartensystems des Händlers zu erhalten. Zum Beispiel kann der Händler oder die Serversoftware des Händlers einfach die Domain des ISP-Gateway aus der Kopfzeileninformation identifizieren, die durch die Browser-Software des Karteninhabers gesendet wird, wenn er sich mit dem Händler verbindet. Der Händler oder die Serversoftware des Händlers kann eine Transaktionsanforderung an eine zuvor bestimmte Subdomain (die dem Händler zuvor von dem ISP angegeben wurde) oder eine vorbestimmte Standarddomain übermitteln. Wenn zum Beispiel die Kopfzeileninformationen, die von dem Karteninhaber erhalten werden, anzeigten, dass sie von der Domain TESTISP.COM geschickt wurden, kann die Händlersoftware die Standard-Subdomain PAYMENT.TESTISP.COM auswählen, um dort die Anforderung hinzuschicken.
In einer zweiten Ausführungsform muss der Händler keinen Vertrag mit dem ISP oder einem zugeordneten Transaktionsprozessor haben, um die Verwendung des oben beschriebenen Verfahrens zu erleichtern. In dieser zweiten Ausführungsform fängt der Transaktionsprozessor das Transaktionsformular ab 31, das vom Karteninhaber ausgefüllt wurde 30. Dieses Abfangen kann zum Beispiel dadurch erfolgen, dass der Karteninhaber eine Schaltfläche auf seiner graphischen Oberfläche anklickt, wobei die Auswahl das Laufen eines Softwaremoduls bewirkt, das das ausgefüllte Formular an den ISP-Transaktionsprozessor richtet.
Nach Erhalt des Formulars kann der Transaktionsprozessor 102 zunächst eine Überprüfung durchführen, um zu bestimmen, ob der Händler zur Verwendung mit dem ISP oder einem zugeordneten Transaktionssystem entweder direkt oder über eine andere Partei zugelassen ist. Die Zulassung kann auch negativ ausfallen, wobei Händlern verboten ist, das System zu benutzen, z. B. wenn der Händler zuvor seine Leistung des Lieferns von Waren oder Dienstleistungen nicht zufriedenstellend erbracht hat. Auf diese Weise kann ein Verlässlichkeitsfaktor einbezogen werden, wenn Karteninhaber mit Händlern Geschäfte machen. Ein Händler könnte auf eine Verbotsliste gesetzt werden, nachdem sich ein Karteninhaber erfolgreich beschwert hat.
Der Transaktionsprozessor kann auch unter Verwendung einer Händleranforderungseinrichtung versuchen, eine Nachricht an den Händler zu übermitteln, in der der Händler aufgefordert wird, seine Händlerdetails anzugeben, um eine weitere Verarbeitung der Transaktion zu ermöglichen. Zum Beispiel kann die Nachricht übermittelt werden, indem die Nachricht in Felder des Transaktionsformulars eingegeben und diese Details dem Server des Händlers übermittelt werden. Dies ist insbesondere für Situationen geeignet, in denen die Transaktionsverarbeitung auf der Website des Händlers manuell durchgeführt wird, d. h. in Situationen, in denen eine Person übermittelte Karteninformationen über einen Point of Sale (POS) oder eine virtuelle POS-Zahlkartenvorrichtung manuell wieder eingibt. In Situationen, in denen der Zahlungstransaktionsteil einer Website automatisiert ist, ist es möglich, dass der Server des Händlers eine Fehlermeldung erzeugen würde.
In dem Fall, dass der Händler auf eine derartige Anforderung antwortet und seine Händler-Kartensystemdetails angibt, kann die Transaktion wie oben in Bezug auf die Verarbeitung der Transaktionsanforderung in der ersten Ausführungsform beschrieben verarbeitet werden.
In dem Fall, dass ein Händler negativ antwortet oder innerhalb eines Zeitraums gar nicht antwortet, schreitet das Verfahren folgendermaßen fort:
Wie oben in Bezug auf die erste Ausführungsform beschrieben, bestimmt der Transaktionsprozessor die Identität des Karteninhabers und extrahiert 32 die Karteninhaberinformationen für den Karteninhaber von dem Kartenschlüsseldetail-Datenspeicher des Karteninhabers.
Gegebenenfalls kann der Transaktionsprozessor eine Verifizierungseinrichtung einschließen, die geeignet ist, eine Prüfung durchzuführen, um sicher zu gehen, dass der Name und/oder die Adresse usw. in der Datenbank mit denjenigen übereinstimmen, die der Karteninhaber in dem Transaktionsformular übermittelt hat.
In dieser zweiten Ausführungsform besitzt der Transaktionsprozessor nicht die Händlercodeinformationen des Händlers. Daraus ergibt sich, dass es vielleicht nicht möglich ist, die Transaktion direkt zu verarbeiten, wie im Fall der ersten beschriebenen Ausführungsform.
Um dieses Problem zu überwinden, verwendet der Zahlungsprozessor einen eigenen Händlercode, d. h. einen Händlercode, der dem Transaktionsprozessoroperator (z. B.
dem ISP) zugeordnet ist, im Folgenden als System-Händlercode bezeichnet. Der Transaktionsprozessor überträgt 33 dann eine Zahlungsauthorisierungsanforderung an einen geeigneten Authorisierungshost, wobei der System-Händlercode, der Betrag der Transaktion (extrahiert aus dem Formular) und die Zahlkartendetails des Karteninhabers (Kartennummer und Ablaufdatum) übermittelt werden.
Wenn der Authorisierungshost die Transaktion ablehnt, wird eine geeignete Nachricht an den Karteninhaber verschickt und die Transaktion wird wie zuvor beschrieben abgebrochen.
Wenn der Authorisierungshost die Transaktion genehmigt, übermittelt er einen Authorisierungscode an den Transaktionsprozessor 102.
Nach Erhalt des Authorisierungscodes speichert der Transaktionsprozessor diesen zusammen mit den anderen Details der Transaktionen in dem Transaktionsdatenspeicher zur weiteren Verarbeitung (z. B. Zahlung) 35.
Es ist selbstverständlich, dass, sobald diese Transaktion zur Begleichung mit dem Kartensystem verarbeitet wurde, der Betrag der Transaktion dem Karteninhaber belastet und dem Konto des System-Händlers (Transaktionsprozessorsystemoperator), das dem System-Händlercode entspricht, gutgeschrieben wird. Diese erste Transaktion betrifft nicht den Händler, sondern nur den Transaktionsprozessorsystemoperator und den Karteninhaber.
Um die Begleichung (von dem Transaktionsprozessorsystemoperator) an den Händler weiterzugeben, stellt der Transaktionsprozessor dem Händler die Karteninhaberinformationen, Kartennummer und das Ablaufdatum entsprechend einem Konto des Transaktionsprozessoroperators, nachstehend als das System-Karteninhaberkonto bezeichnet, zur Verfügung. Der Händler kann diese System-Karteninhaberinformationen auf herkömmliche Weise verarbeiten. In dieser zweiten Transaktion wird das Karteninhaberkonto des Transaktionsprozessoroperatorsystems belastet und das Konto des Händlers erhält eine Gutschrift. In Kombination mit der ersten Transaktion erfolgt eine wirksame Lastschrift von dem Konto des Karteninhabers und der Händler erhält den Transaktionsbetrag. Die Transaktionsprozessorsegmente der beiden Transaktionen werden wirksam beendet.
Ein Verfahren, in dem der Transaktionsprozessor dem Händler seine System-Karteninhaberinformationen zur Verfügung stellen kann, besteht im Einfügen 34 der relevanten System-Karteninhaberkarteninformationen in die passenden Felder des Formulars, das zuvor vom Karteninhaber ausgefüllt und dem Transaktionsprozessor übermittelt worden war, und im Übermitteln dieses überarbeiteten Formulars an den Server des Händlers.
Nach Erhalt des Formulars verarbeitet der Server des Händlers das Formular auf herkömmliche Weise. In diesem Fall übermittelt jedoch der Server des Händlers eine Authorisierungs- und (anschließende) Zahlungsanforderung für die System-Karteninhaber-Kartennummer und nicht die Kartennummerdetails des Karteninhabers.
Der Transaktionsprozessor wiederum übermittelt eine Bestätigung der Annahme der Transaktion zusammen mit dem Authorisierungscode an den Händler. Dem Händler werden nicht die Zahlkartendetails des Karteninhabers übermittelt.
Der Transaktionsprozessor speichert die Details der Transaktion und postet anschließend die Transaktion (z. B. in einem Posting am Ende des Tages) zur Zahlung gemäß herkömmlichen Verfahren. In einer anderen Ausführungsform könnte die Transaktion zum Zeitpunkt der Authorisierung gepostet werden.
In dieser zweiten Ausführungsform gibt es zwei Transaktionen gleichen Wertes. Die erste Transaktion findet zwischen dem Transaktionsprozessorsystemoperator und dem Karteninhaber statt. Die zweite Transaktion findet zwischen dem Transaktionsprozessorsystemoperator und dem Händler statt. Um einen Betrug zu vermeiden, kann der Transaktionsprozessor geeigneterweise geeignet sein, Abstimmungen zwischen den beiden Sätzen von Transaktionen durchzuführen, wobei die Transaktionen identifiziert werden, die ungewöhnlich sind.
In einer weiteren Ausführungsform können Karteninhaber mehr als eine Karte haben, die zu einem oder mehreren Kartensystem gehören. In dieser Ausführungsform können die Details jeder einzelnen Karte in der Datenbank gespeichert werden. Zum Zeitpunkt der Eingabe des Namens und des Passwortes des Karteninhabers, wenn er eine Verbindung mit dem ISP herstellt oder zu einem anderen geeigneten Zeitpunkt, kann der Karteninhaber aufgefordert werden, anzugeben, welche Karte er für diese Sitzung verwenden möchte.
In einer anderen Ausführungsform kann der Karteninhaber beim Übermitteln des Formulars eine besondere Karte für eine Transaktion angeben, z. B. durch Wählen einer passenden Schaltfläche. Um eine höhere Sicherheit zu gewährleisten, kann jeder Karte zum Zeitpunkt der Übermittlung der Details an den ISP vom Karteninhaber ein Referenzkennzeichen zugeordnet werden. Zum Beispiel kann ein Karteninhaber einer VISA^TM-Kreditkarte, die in erster Linie für Einkäufe für den Haushalt verwendet wird, einen Namen "VISA – Haushalt", oder "AMEX-Geschäft" einer AMERICAN EXPRESS^TM-Karte zuordnen, die für Geschäftszwecke verwendet wird. Durch zur Verfügung stellen einer Liste für den Karteninhaber, aus der er Kartenkennzeichen wählen kann, kann der Karteninhaber die Karte angeben, die er verwenden möchte, ohne dass der Karteninhaber oder der Transaktionsprozessor Daten übermitteln muss, die die Kartendetails des Karteninhabers offenbaren.
Häufig wird ein Karteninhaber mehr als eine Adresse haben, die einer oder mehreren Karten zugeordnet ist. Zum Beispiel kann ein Karteninhaber eine Geschäftsadresse für eine Karte, die der Arbeit zugeordnet ist, und eine Heimatadresse für andere Karten haben. Außerdem kann ein Karteninhaber häufig wünschen, dass Waren an eine Adresse geliefert werden, die nicht die aktuelle Adresse des Karteninhabers ist, z. B. ein Geschenk an einen Bekannten.
In einer weiteren Ausführungsform des vorliegenden Systems ist die Kartenschlüsseldetail-Datenbank des Karteninhabers so strukturiert, dass mehr als eine Adresse einem besonderen Karten- oder Karteninhaberkonto zugeordnet werden können. Diese Adressen könnten gleichzeitig eingegeben werden, wenn der Karteninhaber dem ISP-Server Kartendetails übergibt, oder sie können an einem späteren Tag geändert werden, um Adressen zu entfernen oder hinzuzufügen.
Zum Zeitpunkt des Durchführens einer Gültigkeitsprüfung könnte der Transaktionsprozessor eine Überprüfung durchführen, um zu bestätigen, dass die von dem Karteninhaber zum Zeitpunkt der Transaktion abgegebene Adresse mit einer Adresse aus der Datenbank für die besondere Karte oder den Karteninhaber übereinstimmt.
Obwohl die vorliegende Erfindung in Bezug auf HTML-Formulare beschrieben wurde, ist es für Personen des Fachgebiets ersichtlich, dass eine Vielfalt von verschiedenen Verfahren verwendet werden könnte, die nicht vom Geist oder Rahmen der Erfindung abweichen würde, um die vorliegende Erfindung zu implementieren. Zum Beispiel könnten Karteninhaber ein besonderes Add-in für ihre Browser herunterladen, das bei Erkennung einer Auswahl durch einen Karteninhaber oder einer Antwort von einem Händlerserver, z. B. wenn der Händler bei Erhalt einer Kaufanforderung von dem Karteninhaber mit einem besonderen Dateiformat antwortet, automatisch läuft.
Wie sie hier beschrieben ist, ist die vorliegende Erfindung auf das Routing einer Zahlungstransaktion durch einen ISP abgestellt, wobei der Zugriff nur einem Karteninhaber genehmigt wird, der ein Passwort verwendet, es umfasst die Möglichkeit der Korrelation/Verifizierung, dass der Name/die Adresse usw. des Karteninhabers in der Datenbank mit dem Namen/der Adresse des Transaktionsauftrags übereinstimmen und erlaubt das Erhalten einer Zahlungsauthorisierung unabhängig von einem, aber im Auftrag eines Händlers. Wenn dies abgelehnt wird, wird die Ablehnung dem Karteninhaber mitgeteilt und die Transaktion wird nicht verarbeitet. Wenn dies genehmigt wird, wird dem Karteninhaber und dem Händler eine Bestätigung geschickt.
Als eine weitere, Vertrauen aufbauende Maßnahme kann die Begleichung der Transaktion gegenüber dem Händler verzögert werden, bis eine unabhängige Versandbestätigung erhalten wurde.
Der Programmcode zur Durchführung des Computer-gestützten Zahlungsverfahrens zwischen einem Karteninhaber und einem Händler ist vorzugsweise auf einem Datenträger gespeichert. Das Programm ermöglicht insbesondere eine Authentifizierung und Herstellung der Verbindung zu einem Netzwerk für den Karteninhaber, die Einholung einer Authorisierung einer Transaktionsanforderung für die Zahlkartendetails des Karteninhabers, wobei die Transaktionsanforderung einen Händlercode und einen Transaktionswert enthält, von einem Authorisierungshost und die Übermittlung einer Authorisierung an den Händler Die Wörter "weist auf/aufweisend" und die Wörter "hat/schließt ein" werden, wenn sie in Bezug auf die vorliegende Erfindung verwendet werden, verwendet, um das Vorliegen von angegebenen Merkmalen, Einheiten, Schritten oder Bestandteilen zu spezifizieren, dies schließt jedoch nicht das Vorliegen oder das Hinzukommen von einem oder mehreren anderen Merkmalen, Einheiten, Schritten, Bestandteilen oder Gruppen davon aus.

Claims

Online-Zahlungssystem mit einer Verbindung zum Internet und einer weiteren Verbindung über ein lokales Netzwerk zum Anschluss eines Karteninhabers, umfassend: eine Empfangseinrichtung zum Empfangen einer Verbindungsanforderung von einem Karteninhaber, wobei die Anforderung ein Passwort des Karteninhabers einschließt, eine Authentifizierungseinrichtung zur Authentifizierung der Anforderung des Karteninhabers und zum Ermöglichen des Zugangs für den Karteninhaber in das Netzwerk, eine Empfangseinrichtung zum Empfangen einer ersten Transaktionsanforderung, die einer Transaktion zwischen einem Händler und dem Karteninhaber zugeordnet ist, eine Abrufeinrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einer Datenbank, eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die Zahlkartendetails, wobei die Authorisierungsanforderung einen System-Händlercode und einen Transaktionswert einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion, und eine Transaktionseinrichtung, die auf den Empfang einer Authorisierung von dem Authorisierungshost reagiert und geeignet ist, dem Händler eine Transaktionsanforderung zu übermitteln, wobei die Anforderung einen Mastercode für das Konto des Karteninhabers einschließt.
System nach Anspruch 1, des Weiteren aufweisend eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler.
System nach Anspruch 1 oder Anspruch 2, des Weiteren aufweisend eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion.
System nach Anspruch 3, wobei die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung verzögert, bis eine Versandbestätigung erhalten wurde.
System nach einem der Ansprüche 1 bis 4, wobei die Verifizierungseinrichtung geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die einem Händler zur Verfügung gestellten Karteninhaberinformationen mit den in der Datenbank gespeicherten Karteninhaberinformationen übereinstimmen.
Zahlungsverarbeitungssystem zum Verarbeiten einer Online-Zahlungstransaktion zwischen einem Händler und einem Karteninhaber, aufweisend: eine Einrichtung zum Empfangen einer Zahlungstransaktionsanforderung, wobei die Zahlungsanforderung die Händlerinformationen identifiziert, einschließend ein Händlercodekennzeichen und einen Transaktionswert, eine Zuordnungseinrichtung zum Zuordnen eines Karteninhabers zu der erhaltenen Zahlungsanforderung, eine Einrichtung zum Abrufen von Zahlkartenangaben für den Karteninhaber von einem Datenspeicher von Karteninhaberkartenangaben, eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die abgerufenen Zahlkartenangaben, wobei die Zahlungsauthorisierungsanforderung die abgerufenen Zahlkartenangaben, den Händlercode der Zahlungsanforderung und den Transaktionswert der Zahlungsanforderung einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion, und eine Bestätigungseinrichtung, die geeignet ist, eine Authorisierungsbestätigung zu übermitteln, die als Antwort auf eine übermittelte Zahlungsauthorisierungsanforderung erhalten wurde.
System nach Anspruch 6, des Weiteren aufweisend eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler.
System nach Anspruch 6 oder Anspruch 7, des Weiteren aufweisend eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion.
System nach Anspruch 8, wobei die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung verzögert, bis eine Versandbestätigung erhalten wurde.
System nach einem der Ansprüche 6 bis 9, wobei die Verifizierungseinrichtung geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die einem Händler zur Verfügung gestellten Karteninhaberinformationen mit den in der Datenbank gespeicherten Karteninhaberinformationen übereinstimmen.
Zahlungsverarbeitungssystem zum Verarbeiten einer Online-Zahlungstransaktion zwischen einem Händler und einem Karteninhaber, aufweisend: eine Einrichtung zum Empfangen einer Zahlungstransaktionsanforderung, wobei die Zahlungsanforderung die Händlerinformationen identifiziert, einschließend ein Händlercodekennzeichen und einen Transaktionswert, eine Zuordnungseinrichtung zum Zuordnen eines Karteninhabers zu der erhaltenen Zahlungsanforderung, eine Einrichtung zum Abrufen von Zahlkartendetails für den Karteninhaber von einem Datenspeicher von Karteninhaberkartenangaben, eine Authorisierungseinrichtung zum Übermitteln einer Zahlungsauthorisierungsanforderung für die abgerufenen Zahlkartendetails, wobei die Zahlungsauthorisierungsanforderung die abgerufenen Zahlkartendetails, einen System-Händlercode und den Transaktionswert der Zahlungsanforderung einschließt, an einen Authorisierungshost zum Authorisieren der Transaktion, und eine Antworteinrichtung, die auf den Erhalt einer Authorisierung reagiert und geeignet ist, dem Händler eine Zahlungsanforderung zu übermitteln, wobei die Anforderung einen Systemcode des Kontos des Karteninhabers einschließt.
System nach Anspruch 11, des Weiteren aufweisend eine Händleranforderungseinrichtung zum Anfordern eines Händlercodekennzeichens vom Händler.
System nach Anspruch 11 oder Anspruch 12, des Weiteren aufweisend eine Zahlungspostingeinrichtung zum Posten der Zahlungsanforderung an einen Zahlungshost zum Verarbeiten der Zahlungstransaktion.
System nach Anspruch 13, wobei die Zahlungspostingeinrichtung das Posten der Zahlungsanforderung verzögert, bis eine Versandbestätigung erhalten wurde.
System nach einem der Ansprüche 11 bis 14, wobei die Verifizierungseinrichtung geeignet ist, eine zweite Verifizierung durchzuführen, um sicher zu gehen, dass die einem Händler zur Verfügung gestellten Karteninhaberinformationen mit den in der Datenbank gespeicherten Karteninhaberinformationen übereinstimmen.
Transaktionsprozessor für den Online-Handel zwischen einem Karteninhaber und einem Händler, wobei der Transaktionsprozessor mit dem Karteninhaber und dem Händler und außerdem mit einem Authorisierungshost verbunden ist, umfassend: eine Verbindungseinrichtung zur Authentifizierung und Herstellung einer Verbindung zu dem Händler für den Karteninhaber, einer Transaktionsauthorisationseinrichtung zur Einholung einer Authorisierung einer Transaktionsanforderung für die Zahlkartendetails des Karteninhabers von dem Authorisierungshost, wobei die Transaktionsanforderung einen Händlercode und einen Transaktionswert enthält, und eine Übermittlungseinrichtung zur Übertragung einer Authorisierung an den Händler.
Datenträger mit einem Programmcode zur Durchführung eines Computergestützten Zahlungsvertahrens zwischen einem Karteninhaber und einem Händler zur Authentifizierung und Herstellung einer Verbindung zu dem Händler für den Karteninhaber, zur Einholung einer Authorisierung einer Transaktionsanforderung für die Zahlkartendetails des Karteninhabers von einem Authorisierungshost, wobei die Transaktionsanforderung einen Händlercode und einen Transaktionswert enthält, und zur Übermittlung einer Authorisierung an den Händler.